Re: Use Cases & Requirements

Yaron Y. Goland wrote:

>The purpose of the cDl is to describe the message choreography. WSDL 1.2's
>role is to specify the exact messages and MEPs being used in the
>choreography.
>  
>
The way I read some of the e-mails in this discussion they seemed to 
assume that the cDl may do other things by being even more abstract. 
That's why I asked for the clarification.

The term prose is also confusing. Let's say I have a choreography which 
defines that I send you some message X, get some business activity to 
occur at your end, and receive a response Y (let's say it's a single 
operation). That definition is not executable in the sense that it's 
insufficient to get the activity to occur on your side. Without the 
business logic nothing will happen. I prefer to think of it as simply 
being "not an implementation". You will still need an implementation of 
that operation on your side, which is the subject of other 
specifications (BPEL, Java, etc).

On the other hand, if I want the activity to be executed all I need to 
do is perform that operation by sending you message X. So as far as I am 
concerned the operation definition is "executable". If I know your 
end-point I can get it to execute. But this is a different part of 
execution than an implementation, I still need an implementation on my 
side to invoke it and one on your side to perform it. The term prose 
implies that even this kind of execution is not possible.

(And I know the term execution is controversial, for some people 
execution=implementation and for others implementation is an expansion 
of execution)

>So the choreography would say something like: "Foo sends message BLAH to
>Bar" where 'message BLAH' would be a reference to a WSDL
>service/porttype/operation (or whatever the hell they call it now in WSDL
>1.2).
>
In that case, what is the issue with languages like WSCI and BPEL?

I know you can define implementations using BPEL which is out of scope, 
but can't you just use abstracts in this case to get a definition of the 
message choreography? What is missing? Similarly with WSCI. Perhaps it 
treads into the possible use as an implementation language (the cPl), 
but can't we just ignore these capabilities for now and simply exclude 
them from any resulting specification? So far the only thing I 
understood needs to be changed is removing XPaths.

arkin

>
>		Yaron
>
>  
>
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Tuesday, May 20, 2003 11:19 AM
>>To: Burdett, David
>>Cc: 'Yaron Y. Goland'; WS Chor Public
>>Subject: Re: Use Cases & Requirements
>>
>>
>>
>>    
>>
>>>So, how about this as the layers that are required:
>>>
>>>1. Template Choroegraphy Definition.
>>>  This is written in a CDl and is something that an organization like
>>>RosettaNet could develop, but is not specific on detailed message content
>>>(as it varies), or the service instances that are used
>>>
>>>2. (Actual) Choreography Definition.
>>> This is optionally based (by reference) on a Template Choreography
>>>Definition but includes the specific message formats, services,
>>>      
>>>
>>etc that are
>>    
>>
>>>used. An open question is whether this is single document or,
>>>      
>>>
>>alternatively
>>    
>>
>>>a Template Choreography Definition with a binding to an instance
>>>
>>>3. Segmented Choreography Definition
>>> This is a single roles view of a Template (?) Choreography
>>>      
>>>
>>Definition and
>>    
>>
>>>could be used as the starting point for a business process to support the
>>>choreography
>>>
>>>
>>>      
>>>
>> From what I recall RosettaNet has a finite set of patterns (four that I
>>can recall) and a lot of different PIPs. Each PIP is defined
>>individually because it relates to different set of operations. Each
>>operation defines which messages are being used, hopefully generically
>>enough to allow some variety. But you won't be plugging an RFQ message
>>into a cancel PO PIP, even if the pattern of interaction is the same
>>(request/response).
>>
>>To me this seems to tie well to the recommended use of WSDL for
>>abstraction, but I'm beating the same drum over and over ;-)
>>
>>
>>The question I have is what is exactly suggested by the use case. The
>>term prose as I read it means a cDl that is not necessarily machine
>>processable, just an artifact that you can use to build machine
>>processable definitions. In that case you can get as much abstraction as
>>you want, either by binding things to it or simply by not specifying
>>them. We can imagine a language where you just write templates and
>>there's no need for binding. Since a lot of people like to see that,
>>that's an option for us to discuss.
>>
>>But if that's the case, can't we just ignore WSDL? Let other languages
>>or standards deal with how to use WSDL for choreographies and let's
>>focus on those abstract templates. Use a cDl language not based on WSDL
>>to write choreographies, and a language based on WSDL to write actual
>>choreography MEPs.
>>
>>Yaron, if that's what you intended than I need one clarification
>>regarding your statement that our deliverables should be based on WSDL
>>1.2. Do you mean that we should identify some non-prose cPl language
>>that is based on WSDL and adopt it? Develop both the prose cDl and
>>non-prose cPl and the later should use WSDL 1.2? Provide mapping between
>>the cDl and some cPl language that does use WSDL and incorporate
>>appropriate rules into that mapping?
>>
>>In short, where does WSDL come into play with respect to the cDl and cPl?
>>
>>arkin
>>
>>
>>
>>
>>    
>>

Received on Friday, 23 May 2003 14:43:52 UTC