Re: Correlation Requirements

David, I perfectly agree with all these three options and the fact that 
there's no right one.

In all three cases, if I read them correctly, it seems that you would be 
doing different activities depending on which path you follow. It may be 
a different choreography (hence different activity) or different 
activities in the same larger (composed or not) choreography. So it's 
easy to associate a different operation with each activity, and build 
these operations using a common set of types.

For example, you can define a generic type for a PO, a specific type for 
a local PO and a specific type for an export PO (extended to include 
export-related information). You then use the appropriate type when 
defining the operation to perform as part of a particular flow. So you 
get a lot of commonality which helps the implementation - you can have 
one way to handle billing or item allocation for both cases - but you 
also have specific knowledge of which message type is used where.

Would this approach be consistent with what you had in mind?

arkin

Burdett, David wrote:

>Assaf said ...
>
>  
>
>>>>Are you saying that a choreography would select one of two alternative
>>>>        
>>>>
>flows based on this state, or that there are two different choreographies,
>depending on which type of order is being sent?<<<
>
>It all depends, for example I can think of three ways of solving this
>problem all of which could be appropriate depending on the circumstances.
>
>1. IT's A BUSINESS PROCESS
>You could imagine a business process (i.e. it's under the control of a
>single entity) that decides independently which of two choreographies to
>use. In this case, the decision would probably be part of a BPEL or some
>other process-oriented language and not in the choreography
>
>2. IT's A COMPOSED CHOREOGRAPHY
>In this case you have two separate choreographies one for
>"export-restricted" and one for "non-export restricted" orders. These
>separately defined choreographies are then referenced by a third higher
>level choreography that uses "choreography composition" to combine them.
>
>3. IT's ONE BIG CHOREOGRAPHY
>This is similar to the second example above, except that all the
>interactions in the choreoraphy are in one single choreography definition so
>there is no referencing of separately defined choreographies.
>
>Which style you use is a choreography design decision that depends on such
>things as:
>a) Whether all the parties involved need to know about combined choreography
>or can treat them as separate. If they don't then you can do the BPEL
>approach, if they do, then you need to do have one big choreography of
>compose two choreographies.
>b) The degree of commonality between the choreographies, if they are
>similar, then you might want to do one big choreography to avoid the
>duplication.
>c) Whether or not there are some pre-existing choreographies that you can
>just reuse. If they already exist then a composed choreography could be the
>way to go.
>
>As in all design decisions, there is rarely one right way of doing things
>that applies to all situations ...
>
>Hope this helps
>
>David
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com]
>Sent: Wednesday, August 20, 2003 4:49 PM
>To: Burdett, David
>Cc: Keith Swenson; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon';
>jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
>Subject: Re: Correlation Requirements
>
>
>Burdett, David wrote:
>
>  
>
>>Assaf
>>
>>You said ...
>>
>> 
>>
>>    
>>
>>>>>You have very specific structures like RN vs OAG and you want to avoid
>>>>>       
>>>>>
>>>>>          
>>>>>
>>dependency on those so as to allow multiple over-the-wire formats (as you
>>discuss below). But there's also the content model or information structure
>>that is important to convey. If you send me some message that is
>>semantically a PO, that's not very helpful if I can't find some line items,
>>billing address, etc in there.<<<
>>
>>I totally agree. But I would separate this problem into three parts:
>>1. Define the relevant states - by specifying in the choreography, *what*
>>"states" are relevant. For example the fact that an order contained goods
>>that had export restrictions, might have a substantive effect on the flow
>>    
>>
>of
>  
>
>>the choreography. In this case, the state "ExportRestrictedOrder", or
>>something like it, would need to be defined.
>>
>>    
>>
>Are you saying that a choreography would select one of two alternative 
>flows based on this state, or that there are two different 
>choreographies, depending on which type of order is being sent?
>
>arkin
>
>  
>
>>2. Determine document formats compatible with the choreography. For
>>    
>>
>example,
>  
>
>>there will be rules that uses information about an order and the parties
>>involved to determine whether or not it is export restricted. This means
>>that, before you can use a particular choreography, you need to make sure
>>that the order document format (or information derivable from eleswhere
>>using data in the document) contains the required information. Once you
>>    
>>
>have
>  
>
>>done that analysis, you can specify which choreographies can be used which
>>document formats.
>>3. Define the choreography binding. Finally, once you have identified
>>compatible combinations of document format and choreography, you can build
>>an implementation and specify exactly which choreography, document formats,
>>message formats, security, RM protocol, etc. as well as the services you
>>    
>>
>are
>  
>
>>going to use. You can also bind the state, e.g. "ExportRestrictedOrder" to
>>an executable set of conditions that allows the value of the state to be
>>determined for any order instance. At this point, you are specifying the
>>"how".
>>
>>David
>> 
>>
>>    
>>
>
>  
>

Received on Friday, 22 August 2003 22:15:01 UTC