RE: Dubray paper comments + questions

> I am curious why you'd regard these as requirements. The use case of,
> for example, bargaining over the terms of a transaction before
> completing it, has been contemplated and there is standardization work
> going on in that area in the context of ebXML. However, this is probably
> beyond what most people now deploying B2B are doing. Real B2B in my
> experience currently tends to involve parties that have pre-existing
> relationships (established non-electronically) and pre-negotiated terms.
> If we want to enable people to move beyond that model and make the
> process more dynamic, that may be desirable, but let's be sure that
> there is a real business use case for it. Also I think the problem set
> that something like the ebXML CPA addresses may be a different problem
> than what this group is chartered to do.

It's really a matter of scope.

Personally, I'm not interested in redoing the work done at ebXML, I don't
see the value in having two specifications for expressing business
collaborations that are pre-negotiated. Do you see a value in having two
such specifications?

On the other hand, if you have services that do advertising, discovery,
negotiation, would you not want to describe interactions that range over
these services as well?

So we're really talking about two different scopes here.

On the one hand we have B2B, that's what ebXML is charted to do, and a very
specific scope of pre-negotiated collaborations, that's what BPSS
accomplishes. Personally, I feel more comfortable if that work is done under
the ebXML umbrella.

On the other hand we have all kind of services and a generic SOA that
defines them all without exclusion, and that's where I see value for a WS
choreography language.

There are some requirements that are met by the first quite well, there are
other requirements that belong to the second. I only focus on those that are
important for the second.

For me it's appealing to have a language that can describe the choreography
of services and be part of the WS SOA. It's also appealing to have a
language that described pre-negotiated business collaborations. And it's
even more appealing if the service interaction resulting from a combination
of BPSS, RSS, CPA negotiation, etc could be described in terms of a service
choreography.

arkin

>
> --Jon
>
> Assaf Arkin wrote:
>
> > I definitely agree and would like to add to further requirements:
> >
> > * A conversation may involve more than one participant
> > * Conversation rules usually allow participants to join and leave
> > * A conversation may range over multiple participants but involve only a
> > subset at any sub-conversation
> > * A participation in one conversation could be identical to a
> participation
> > in another conversation
> > * Negotiating a script is also a conversation, so a
> conversation that leads
> > to a conversation needs to be described
> >
> > arkin
> >
> >
> >>-Bob Haugen
> >
> >
> >
> >
>
>

Received on Thursday, 27 February 2003 16:35:06 UTC