- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 03 Apr 2003 10:45:26 -0800
- To: Ricky Ho <riho@cisco.com>
- CC: "Patil, Sanjaykumar" <sanjay.patil@iona.com>, public-ws-chor@w3.org
Ricky Ho wrote: > > At 12:06 AM 4/3/2003 -0800, Assaf Arkin wrote: > >> Patil, Sanjaykumar wrote: >> >>> Ricky, I agree with all of your points. >>> >>> I also see how your design is more modular, but I guess I need to >>> understand a bit more the practical motivations behind/benefits of >>> this design. >>> >>> Personally I was assuming the reason behind an abstract process in >>> your example was to support the choreography between multiple >>> participants. I guess a choreography between multiple participants >>> can be defined by laying out the sequence, the direction of message >>> exchanges and the few properties that drive the exchange of >>> messages, etc (that is without depending much on the service >>> descriptions), and hence I thought the abstraction in your example >>> justifiable. >>> >> Can't that be achieved by defining the choreography in terms of WSDL >> operations which are not specific to one particular service? > > > Are you talking a future form of WSDL which support inheritance and > parameter overloading ? I'm talking about WSDL as it currently stands. If you add inheritence and parameter overloading you get more reuse and that's a good thing. You can do more compositions by extending existing definitions (and implementations) instead of rewriting everything from scratch. But you can get a lot done with WSDL as it stands. > Or are you talking about an arbitrary WSDL which has an XSL/T > transformation attached to it. In this case, the WSDL doesn't need to > be non-specific to particular service ? I'm talking about the WSDL abstract definitions. There is no XSL/T transformation attached to it. As part of binding to a specific protocol you may want encoding rules and some of these rules can be expressed in XSL/T but there are other oprtions. As part of binding to a specific implementation you may also want transformation, but that's an implementation detail. For example, the abstract message may define the message as containing: shipTo billTo All buyers and sellers agree that this is the information carried in the message and they can all reference it in the same way. Some implementation may have an internal structure defined as: shipAddr billAddr Internally that implementation may use XSL/T (or other means) to map to/from the abstract message, so it can talk in one language with everyone else, yet retain its implementation independence. You don't care about what the implementation does, only about the lingua franca. Some protocol may decide to structure things differently, for example: addresses billing shipping So only those services that use that protocol would convert the abstract message to that particular representation when they send/receive messages over that protocol. But if they happen to use other protocols they could encode the abstract message in other ways. You are still talking lingua france since you're talking to others in terms of the abstract message, even if you choose to encode it differently for different protocols. So the abstraction lets you define the common language that everybody talks, while allowing varience of implementations and allowing multiple different protocols to be supported at the same time. arkin > > > >> arkin >> >>> However if the above was not precisely your motivation, then may I >>> ask :- >>> a> Do you have other scenarios in mind that would justify the >>> additional layer as necessary and not an unnecessary complexity. >>> b> Whether the separation of choreography from orchestration would >>> require a similar kind of abstraction? Answering this one should >>> probably be my own exercise as it was my own doubt, but perhaps you >>> have some comments! >>> >>> Sanjay Patil >>> Distinguished Engineer >>> sanjay.patil@iona.com >>> ------------------------------------------------------- >>> IONA Technologies >>> 2350 Mission College Blvd. Suite 650 >>> Santa Clara, CA 95054 >>> Tel: (408) 350 9619 >>> Fax: (408) 350 9501 >>> ------------------------------------------------------- >>> Making Software Work Together TM >>> >>> >>> -----Original Message----- >>> From: Ricky Ho [mailto:riho@cisco.com] >>> Sent: Wednesday, April 02, 2003 5:28 PM >>> To: Patil, Sanjaykumar; public-ws-chor@w3.org >>> Subject: RE: Progressive Concreteness of Choreography binding >>> >>> >>> Inline. >>> >>> At 02:04 PM 4/2/2003 -0800, Patil, Sanjaykumar wrote: >>> >>> >>> >>>> This is good. With the example, we can now make the abstract >>>> discussion more concrete :-) >>>> >>>> Questions: >>>> a> Do we need message definitions in the choreography? Wouldn't >>>> message properties be sufficient? >>>> >>> >>> At the abstract choreography level, No for 1st question and Yes for >>> the 2nd >>> >>> >>> >>>> b> Is our model to define the choreography with POHandlingProcess >>>> at the center of the universe? Based on whether we define it as a >>>> collaboration or as individual role's process, the language will >>>> change. >>>> For example, if we were to follow a collaboration model, the >>>> first statement in the Process construct will be something like >>>> 'Partner "seller" to receive "PO" from partner "purchaser"' instead >>>> of 'receive "PO" from partner "purchaser"' >>>> >>> >>> You are absolutely correct. So I use the term "Orchestration" >>> rather than "Choreography" in my pseudo code. Lets separate out the >>> debate of "Orchestration" vs "Choreography". >>> >>> >>> >>>> c> What is the purpose of "Message binding" in the Implementation >>>> Binding? Perhaps this is related to question a> above. Wouldn't >>>> Message Property binding be sufficient? >>>> >>> >>> Message properties doesn't define all elements of the message. It >>> only define a subset of information that the orchestration use for >>> evaluating conditions. For example, the PO message may need to >>> contain an element "poNumber", but you don't have a message property >>> "PO.poNumber" because you don't use that for evaluating condition. >>> So at the implementation binding level, you need to bind both the >>> message as well as message properties. >>> >>> >>> >>>> d> Assuming that there is an individual Implementation Binding for >>>> each role involved in the shared collaboration, the Partner binding >>>> can be to identify the choreography interface of each partner. The >>>> choreography interface of "mySelf" may not be needed as it becomes >>>> part of the other roles' implementation binding. >>>> >>> >>> You are right ! My example is based on the WSCI/BPEL model which >>> the process itself play a specific central role. If we take a more >>> symmetric representation, then we'll end up something you describe >>> here. My example tries to illustrate the abstractness of the >>> process, but not the 1st person view vs the neutral view. >>> >>> Ricky >>> >>> >> >> >> -- >> "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 >> >> >> This message is intended only for the use of the Addressee and >> may contain information that is PRIVILEGED and CONFIDENTIAL. >> If you are not the intended recipient, dissemination of this >> communication is prohibited. If you have received this communication >> in error, please erase all copies of the message and its attachments >> and notify us immediately. >> >> -- "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 This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient, dissemination of this communication is prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
Received on Thursday, 3 April 2003 13:46:54 UTC