Re: Definition of Terms

Burdett, David wrote:

> Christoph
>  
> See comments inline below.
>  
> David
>
>     -----Original Message-----
>     *From:* ChBussler@aol.com [mailto:ChBussler@aol.com]
>     *Sent:* Monday, March 17, 2003 9:44 PM
>     *To:* david.burdett@commerceone.com; sanjay.patil@iona.com;
>     public-ws-chor@w3.org
>     *Cc:* ChBussler@aol.com
>     *Subject:* Re: Definition of Terms
>
>     Hi,
>
>     a remark on 'control' (or maybe a question). I assume that your
>     definition of 'message' is abstract, i.e. does not imply
>     asynchronous transmission between sender and receiver.
>     [David Burdett] Right. A message is completely abstract. It is
>     simple the transmission of information from one location to
>     another (e.g. from one service to another). How this transmission
>     is achieved is immaterial, i.e. it can be eith synchronous or
>     asynchronous - whatever those words mean. In fact on the WSA group
>     there has been great difficulty and debate around defining what
>     synchronous and asynchronous actuall mean [1].
>
I would tend to define a message as a container of information. The 
container notion is important because it lets you compose different bits 
of information that can be reused in different messages, and different 
bits of information may have different significance (e.g. the business 
request, the topic of request, the requesting party). WSDL does that 
pretty well.

The message definition is that of a message at rest. It says nothing 
about which direction it goes on, or which service can consume or 
produce it. That information is provided by the operation. The operation 
tells you whether that message is an input or an output, and in fact 
what it signifies. The action then tells you which service is 
responsible for performing that operation either as the requestor or 
provider, and in relation to all other actions.


>     The definition of 'control' in general is difficult. Maybe a
>     distinction has to be made between controlling the definition vs.
>     controlling the execution (i.e., type vs. instance).
>     [David Burdett] Very true. A choreography definition (the type)
>     is, IMO, something that MUST have an independent existence and be
>     agreed by all the roles involved before interoperable solutions
>     can occur. The actually choreography *definition* must also be
>     owned by someone as it is a single definition that describes what
>     all the roles must do. For example, in B2B, the owner of a
>     choreography definition could be: a) an 800lb Gorrilla, e.g
>     Walmart telling all its suppliers follow the Walmart choreography
>     or you don't do business, b) a trade association, e.g. RosettaNet
>     with their PIPS, or  c) an international standards organization,
>     e.g. UN/CEFACT.
>     On the other hand, the execution of a choreography can be owned by
>     no one and HAS to be handled by mutual agreement, even if it
>     is the SME agreeing to do business the way Walmart wants them to!
>
I think that the use of the term 'domain of control' depends on context. 
We can talk about who owns the definition, who runs the instance, even 
who serves the coffee. But I think there's a very clear and precise 
meaning in terms of choreography.

Let's say that some service X sends a message (request) to service Y, 
service Y receives that message, does something and then sends back a 
response. Service X performs some activity A1 which sends the message. 
Service Y performs some activity A2 which receives the message, and 
later on some activity A3 which sends back a response. Service X and 
service Y belong to different domains of control.

Service X can't just start an activity in service Y by wishful thinking. 
And ESP technology is not proven yet. So service X "coerces" service Y 
to start an activity by sending it a message. Service Y needs to perform 
two activities one after the other. Service Y has some unspecified means 
to do that, maybe because it has a big piece of Java code, or because it 
uses some internal mechanism to chain these activities together. But 
it's not important to express how these activities are chained together 
in the context of a choreography.

So in the choreography we would say something like:

service X
  activity A1 send request

service Y
  activity A2 receive request

We show the relation between two activities executing in different 
domains of control by expressing how they communicate, which is 
important information for both services to understand.

On the other hand, the choreography definition of service Y could say 
something like:

service Y
  activity A2 receive request
  activity A3 send response

Exactly how service Y chains these two activities together is not 
interesting for service X (or any other service in the choreography). 
It's an implementation detail. Service Y may have some other message 
that is send by A2 to start A3, or it may update some record in the 
database, of have some person flicking switches on a big panel. That's 
not important.

We show the relation between two activities executing in the same domain 
of control using some form of sequencing that does not require explicit 
form of communication, e.g. in a procedural way, using state transition 
diagrams, or by expressing a process flow

(WSCI takes the third approach since it makes it easier to model 
activities that occur in parallel. Unfortunately, due to the choice of 
syntax - and I'll be first to take the blame - it is often confused with 
being procedural and non-cyclic despite the intent of the authors)

arkin

>
>     Thanks,
>
>     Christoph
>
>     [David Burdett] [1]See, for just one example, the thread starting
>     at http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0074.html
>      
>     In a message dated 3/17/03 4:55:50 PM Pacific Standard Time,
>     david.burdett@commerceone.com writes:
>
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700

Received on Tuesday, 18 March 2003 02:58:30 UTC