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

Precisely.

The process-meta-models and specific process definitions based on the 
meta-models that have seen acceptance in the industry in terms of 
production use thus far have been based on top-down approach. You start 
with a business process that you like to accomplish (B2B/B2C/A2A) such 
as inventory-managment, order-processing etc., available at a business 
definition level that you model in terms of the parties, messages 
(documents/schemas) that are exchanged in a well-defined and controlled 
order (choreography). We should expect this to be predominent and more 
pragmatic case as it supports automating a business process that is 
accomplished otherwise (partially or fully manual) in the industry.

It is also possible to take the bottom-up approach where existing Web 
services can be composed into higher lever composite Web services and 
choreographies, the approach taken by WSCI and BPEL mainly.

I have always imagined though that a higher level collaborative process 
modeling language descriptions (e.g. BPSS or PIP definitions) can be put 
through a tool that can generate the BPEL or WSCI defintions either 
fully or partially. Business will need a way to model their partners 
(parties) and interactions with partners in a business process in a way 
that is independent of how it is implemented in terms of Web services 
(or the full blown details there in). It is more meaningful for them to 
speak interms of sending a RequestForQuote and receiving a Quote rather 
than a Web service port and operation etc. 

Hence the question for us is, if we want to define a language that 
facilitates modeling at the business-level and then break-it down into a 
Web service based choreography or limit to the latter only and leave it 
upto the tools to bridge the gap.

I guess questions have been raised on the need to model internal or 
private processes, which have been mainly flow oriented. I think we need 
to accommodate both to facilitate end-end process modeling, though IMO 
they need to be clearly separted out and treated separtely instead of 
mingling both aspects into one unified model as it seems to have been 
done in some of the specs we have been looking at.

Regards, Prasad

Martin Chapman wrote:

>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
>>>>>>>              
>>>>>>>
>>    
>>
>
>  
>