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

Prasad:

 

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.



[JJ] Yes I agree with you, RN and Start/XML are two very good example of
this, and there are plenty more. It is very efficient for an industry as
a whole to define its collaboration definitions.


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. 

[JJ] Yes, I think also that this can work reasonably well. Mega has done
a lot of work in this direction. I am sure other tool vendors have too.

 

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.

[JJ] It is important to note that BPSS choreographies can rely on a
business protocol which guaranties that the business documents are
effectively processed by the receiver. On the other hand, a standard
like BPEL does not allow you to express that an "invoke" has to happen
within a certain time. The authors may have forgotten to assign a
timeout element (while it is available on other aspects of the spec).
These two kinds of exceptions, including also transport level exception
(message could not be delivered) are an integral part of the
collaboration definition and shape its ultimate path. I would even
content that without the ability to express a sufficient set of
exception directly related to the choreography definition,
collaboration's value is greatly diminished.


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