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

Jean-Jacques,

I really think it depends on the use case.

If I am starting from scratch and designing a new businees process, I
would start from the process defintion
and end up with the WSDL for each participant.

However, if I already have the WSDL defined and need to intgerate them
via a process then cleary the process comes second.

IMHO I think we should accomadate both approaches, and neither one
should be the sole design centre for our work.

Martin

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of 
> Jean-Jacques Dubray
> Sent: Sunday, February 09, 2003 9:42 AM
> To: 'Assaf Arkin'; 'Jean-Jacques Dubray'; 'Ricky Ho'
> Cc: public-ws-chor@w3.org
> Subject: Approaches to Web Services Choreography [was Same 
> model for both Public and Private process ??]
> 
> 
> 
> 
> 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 19:38:22 UTC