RE: Approaches to Web Services Choreography [was Same model for both Public and Private process ??]

Without a doubt the probability of two things defined in isolation to work
is very low (but if you put enough monkeys on the problem ...) For example,
stitching together two BPSS business transactions and presuming the process
would be correct.

What you claim is a limitation of WSCI is actually made worse in the BPSS
model. As we've already established in your approach you need to do n x m
stitchings of CPP/CPAs for n suppliers and m buyers (contrast to WSCI's n+m)
and that's quite a lot of monkeys ;-)

I wrote quite a lengthy e-mail explaining how people actually model
choreographies and why they work, basically just repeating what is already
well expressed in the WSCI spec in text, example and diagrams. Would it
really hurt to quote me in full?

arkin


> Since this email where Assaf was asking me to reconsider my position I
> exchanged multiple emails with him to try to come to a common
> understanding and maybe a consensus.
>
> In the blitz of messages that we exchanged (though it would be worth to
> summarize it at some point), one comment from Assaf puzzled me. My main
> point of contention with WSCI is that it models the choreography (c12y)
> of APIs and then via a global model stiches them together leaving little
> hope to get an overall view of the collaboration itself. Assaf admitted
> that if the APIs were truly designed in isolation the probability of
> being able to choreograph them together would be close to zero plus a
> few monkeys.
>
> If you take a closer look at BPEL and WSCI, they both take the approach
> to use what would be otherwise an "internal business process definition"
> to describe how a collaboration operates. The only reason for that is
> because they are taking WSDL as a starting point and not as and end
> point. BPEL claims without saying it that the "other" services are
> mirror to the one they choreograph, therefore, no need to really talk
> about the "other" side. Hence the concept of serviceLink which is just a
> point to the "other" mirror service. WSCI goes a little futher and allow
> for a little more flexibility by allowing somewhat differently designed
> web services to work together but admitting that these services cannot
> of course widely differ from each other.
>
> In my opinion, using the concept of an "internal business process
> definition" to choreograph a collaboration is a bad idea because you
> then need to articulate how this special "internal business process
> definition" (often labelled as abstract) works with my "concrete"
> internal business process definition which I especially don't want to
> share with my partners.
>
> Now if the ws-chor group would consider an alternative approach of using
> WSDL as an end point and not a starting point, I think it would greatly
> simplify the "web service choreography" problem. In order to take it as
> an end point, you need to invent a new concept that I call a message
> exchange and what BPSS calls a business transaction. I mention message
> exchange to show how close this is to the concept of message exchange
> pattern being considered by WSDL. Of course in BPSS, a business
> transaction is both a business message exchange (e.g. Request/Response)
> and a series of signals as part of the business collaboration protocol.
>
> It is relatively easy to choreograph these MEPs or Business
> transactions. BPSS is one example. Can be we do a better job? Of course.
> The patterns of Prof. Van der Aalst could help up close on the control
> flow once and for all for instance. Once this is done, this is were WSDL
> comes to play (one for each side) and where you bind this choreographed
> messaged exchange with each side's WSDL. A message exchange would
> typically be bound to a port.
>
> As I mentioned several times on this list and others I believe that
> there are 3 entities that need to be modeled (at least):
> - Collaboration (between business partners)
> - Internal business processes
> - long running behavior of components (such as order entry) when
> participating in business processes and collaborations.
>
> I have shown in a paper that this concept of "choreography of message
> exchange" allows you to efficiently model collaboration and internal
> business processes. Once you do that, specifications such as BPEL or
> BPML can be used to model the long running behavior of components.
>
> Respectfully,
>
> Jean-Jacques Dubray,
>
>
> >>-----Original Message-----
> >>From: Assaf Arkin [mailto:arkin@intalio.com]
> >>Sent: Tuesday, February 04, 2003 2:07 PM
> >>To: Jean-Jacques Dubray; 'Ricky Ho'
> >>Cc: public-ws-chor@w3.org
> >>Subject: RE: Same model for both Public and Private process ??
> >>
> >>
> >>> -----Original Message-----
> >>> From: public-ws-chor-request@w3.org
> >>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques
> Dubray
> >>> Sent: Tuesday, February 04, 2003 3:26 AM
> >>> To: 'Ricky Ho'
> >>> Cc: public-ws-chor@w3.org
> >>> Subject: RE: Same model for both Public and Private process ??
> >>>
> >>> [JJ] I assume you think of states in terms of "getting ready to
> >>> send/receive a given message", otherwise, clearly notions like "this
> >>> order is the approved state" is not necessarily part of the state of
> >>> public processes as BPEL or BPML think about it, let alone WSCI and
> >>> WSCL. You may want to read the eBTWG - Business Entity Types
> Technical
> >>> Specification
> (http://www.collaborativedomain.com/standards/index.htm
> >>> under the BETL section). These guys are working on modeling these
> kinds
> >>> of states. I find the concepts of this specification quite
> fascinating
> >>> actually.
> >>
> >>Yet, both BPEL and BPML allow you to model the "this order is the
> approved
> >>state", whether it is the distinct context in which you perform
> actions,
> >>or
> >>a value expressed in that context which you can communicate
> >>(send/receive),
> >>evaluate, correlate, etc.
> >>
> >>
> >>> [JJ] This is actually incorrect. In BPSS for instance, you clearly
> have
> >>> business rules that allow you to specify that if a particular
> document
> >>> contains a certain value, then the collaboration ought to continue
> that
> >>> way, otherwise, it will continue this way. The key though (and of
> >>> course) is that the condition expression can only apply to a
> document
> >>> that both parties already successfully exchanged. You cannot specify
> >>> conditions expressions that only one party can evaluate. One big
> >>> difference between public and private processes is that public
> processes
> >>> do not have an underlying engine. It is merely the interaction
> between
> >>> the private processes that advances the state of the public process
> (aka
> >>> collaboration). However, one can formally demonstrate that a
> >>> collaboration is also a finite state machine.
> >>
> >>In other words, if the buyer and supplier agree that an order is >
> $500 as
> >>can be calculated from the message (if the schema was known) the buyer
> can
> >>reject the message and the supplier will accept a reject message. But
> if
> >>the
> >>supplier has determined that the buyer does not have sufficient credit
> to
> >>purchase the product, the supplier proceed to accept the order since
> the
> >>buyer may have a different opinion on the matter ("what do you mean
> >>rejected? you know I'm good for it! I might not have money right now,
> but
> >>I
> >>promise to pay you back!").
> >>
> >>
> >>> Once you have established such a model, one can think of how to
> >>> choreograph message exchange, work being done, user interactions,
> and
> >>> what not. Please, note that these will never express "states" but
> rather
> >>> "pseudo-state" since the same public/private definition will not
> refer
> >>> to a given state of the company but rather to the way state advances
> >>> within the company. It is only when a process instance is created
> that
> >>> in effect a "real" state is bound to the process definition, which
> then
> >>> controls how this "state" advances.
> >>
> >>Very well said!
> >>
> >>
> >>> b) it enables unit of work to be more than "request/response"
> agents. In
> >>> the example I provide which is very realistic, the Order entry
> component
> >>> manages 4 messages as part of the same business process definition,
> not
> >>> just request/response.
> >>
> >>Not everyone has reached the conclusion that a choreography language
> >>should
> >>allow you to manage 4 messages as part of the same business process
> >>definition, but at least the languages we are talking about allow you
> to
> >>do
> >>that. I think that's a base requirement for all of these languages. At
> >>least
> >>something we all have in common ;-)
> >>
> >>
> >>> c) user interactions are part of the process definition (BPEL/BPML
> >>> completely ignore user interactions).
> >>
> >>I like to think of Web services as presenting a model for user
> >>interaction,
> >>I like to think of BPEL/BPML/WSCI as supporting any and all kinds of
> Web
> >>services, in particular those representing user interactions, I know
> of a
> >>few products that actually do that and so far with great success. So
> my
> >>limited experience with the usage of this languages seems to
> contradict
> >>this
> >>statement, but again YMMV.
> >>
> >>
> >>> IMHO, this approach is much closer to Pi-calculus than BPML or BPEL
> will
> >>> ever be as it models the business process as an exchange of message
> >>> between independent components (running in their own system
> process).
> >>> Other specs like BPEL and BPEL use Pi-calculus in the inter-process
> >>> context not the inter-component context. I am not a specialist of
> >>> Pi-calculus so I'll leave this statement more as a question than a
> fact.
> >>
> >>Very interesting.
> >>
> >>In a previous e-mail I provided an example showing where pi-calculus
> is
> >>used
> >>for inter-component context. I think that using pi-calculus in the
> >>inter-process context brings tremendous value, so I highlighted that
> >>possibility, but clearly the example illustrated two independent
> processes
> >>executing at two different systems (trading partners, if you want to
> call
> >>it
> >>that).
> >>
> >>Will you consider revisiting that e-mail and commenting on that fact?
> >>
> >>arkin
> >>
> >>
> >>>
> >>> If the approach I suggest is proven correct, it could change the
> scope
> >>> of the WS-Chor group since it will result in a specification that
> spans
> >>> from (BPEL/WSCI/WSCL/BPSS) to (BPEL/BPML). In my opinion, it will
> also
> >>> yield significant simplification to the overall space.
> >>>
> >>> Best regards,
> >>>
> >>> Jean-Jacques Dubray,
> >>>
> >>>
> >>>
> >>> Correct me if I misunderstand, it
> >>> >>seems
> >>> >>HP's WS-Conversation-Language is taking this approach.
> >>> >>
> >>> >>But I also hear that "public process" can be described as a subset
> of
> >>> a
> >>> >>"private process".  If you take out the "process variable",
> "assign
> >>> >>statements", and the "conditions" in the switch blocks and loops
> ...
> >>> etc
> >>> >>from the "private process", then you will have the "public
> process".
> >>> In
> >>> >>other words, public process can be just use the same model of
> "private
> >>> >>process".  It seems WSCI and BPEL-private process is taking this
> >>> approach.
> >>> >>
> >>> >>I also heard that the "flow-chart" is equivalent to "state
> diagram".
> >>> They
> >>> >>are just a dual-representation to each other.
> >>> >>
> >>> >>Any comments and thoughts ... ?
> >>> >>
> >>> >>Best regards,
> >>> >>Ricky
> >>>

Received on Monday, 10 February 2003 21:36:39 UTC