- From: Ricky Ho <riho@cisco.com>
- Date: Thu, 27 Mar 2003 12:29:15 -0800
- To: Assaf Arkin <arkin@intalio.com>
- Cc: public-ws-chor@w3.org
Assaf, I think (1) is sufficient if we push PortType inheritance in WSDL. Rgds, Ricky At 11:55 AM 3/27/2003 -0800, Assaf Arkin wrote: >+1 > >In my experience only a subset of what is contained in the message is >important to the choreography. So there's no need to know everything that >is in the message, which is helpful in terms of abstraction. > >And yes, being able to define the choreography in terms of properties, not >message parts is a better approach for a variety of reasons (including >anticipating same properties in different abstract messages). In fact, >that's the only way you can do it in WSCI, and you can do it the same way >in BPEL (selectors and property aliases respectively). > >So my preferred choice would be to express the choreography in terms of >properties. The express how properties map to abstract (never concrete) >messages using something like selectors. You only need a selector for the >message format you intend to support, and different systems/contexts can >use different message formats with different selectors, while still >talking about the same properties as part of the same choreography. > >But, there's a lot of utility in being able to express a choreography in >terms of WSDL abstract operations (not concrete services). It's the >benefit of being able to utilize not just WSDL itself, but all the other >specifications around it. > >There are two ways to do it: > >1.1 Write the choreography by referencing the abstract WSDL operations >performed by each activity. (Abstract but requires WSDL as normative spec) > >1.2 At run-time bind it to specific WSDL services (end-points and protocols). > >2.1 Write the choreography without referencing any abstract WSDL >operation. (More abstract, can support other languages than WSDL) > >2.2 At run-time bind it to specific WSDL services (end-points and >protocols). Cross your finger and hopes everyone would use the same >abstract operations as intended by the activities being performed since >you can't predict that up front. > >3.1 Write the choreography without referencing any abstract WSDL >operation. (More abstract, can support other languages than WSDL) > >3.2 Write a mapping from the choreography to WSDL operations. (Only if you >elect to use WSDL, you can have different mappings for other languages) > >3.3 At run-time bind it to specific WSDL services (end-points and protocols). > >I don't see 2 (2.1+2.2) as even being able to work. If I send message X >using operation Y, and you receive message X using operation Z, there's no >way we can work with each other. By just looking at the choreography I can >imagine that we could work together, only to be surprised it doesn't pan >out at run-time. So I consider that only 1 and 3 are valid options. > >The question is, is there any technical justification for doing 3 instead >of 1 because at the end of the day inspite the additional layer introduced >by 3 it makes our job easier? > >arkin > > >Patil, Sanjaykumar wrote: > >>Shall we first identify the dependency of choreography definition on >>message definitions? >> >>Yes, messages are essential as they are the vehicles of delivering >>information. >> >>However, how much of the information embedded in a message is controlled >>by the choreography? I guess only a small subset and the rest of the >>parts of the message would be controlled by the end services producing >>and consuming the messages. >> >>Would it be fair to say that a choreography definition includes >>specification of a set of properties (ex. billing address, shipping >>address) as part of its logic. Some of the properties have relationship >>(direct or derived) with parts of the messages, that are defined by the >>end services. And perhaps the entire task of associating the properties >>with the message definitions falls out of the scope for the choreography >>specification. >>Of course, in order to define the association of properties with message >>definitions, there has to be a semantic association between the two. But >>wouldn't it be sufficient for the choreography to (some how?) define the >>semantics of the properties alone and leave the mapping of the properties >>to the messages out of scope. And therefore whether messages definitions >>are abstract or specific would not matter at all. >> >>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: Assaf Arkin [mailto:arkin@intalio.com] >>Sent: Thursday, March 27, 2003 10:57 AM >>To: Burdett, David >>Cc: 'jdart@tibco.com'; 'Ricky Ho'; public-ws-chor@w3.org >>Subject: Abstract messages [Was: Multi-Party Binding Scenario] >> >> >> >>David, >> >>I changed the title of this threadThe issue we're discussing does have an >>affect on the usability of choreography, but is not specific to >>choreography but deal with abstract and extension of messages. It's a >>problem for any interface definition, stateful or stateless, that has to >>be reused in a large number of contexts. Obviously it becomes more of an >>issue for choreography which contains more building blocks than say a >>WSDL operation. >> >>There are two points I assume we agree upon: >> >>1. Messages need to be abstract and not specific to a given protocol. >> >>Specific message formats that are protocol dependent (e.g. SOAP vs EDI) >>are also important but should be address by the protocol binding so we >>can have one choreography independent of the protocol we use. >> >>2. Messages need to be generalized and adapted to different contexts. >> >>Specific message formats that are context dependent (e.g. US or Europe) >>are also important and there must be a way to construct such messages, >>but at the choreography level we get more utility if we can express it in >>terms of generalized messages. >> >>The question is, do we have a framework for achieving #1 and #2 within >>Web services which we can utilize when writing choreographies, or do we >>need to create such a framework? And if we need to create such a >>framework, would it be useful to use it outside the context of >>choreography as well (e.g. for WSDL)? >> >>I want to show that such a framework does exist, and how it can easily be >>used with the choreography to identify message parts that are generic >>(context independent) while allowing more specific (context dependent) >>formats to be used in the actual message. For this particular example I >>only use addresses for billing and shipping with two formats for US and UK. >> >>1. I define a generic type called Address which signifies an address. I >>know that I can forward messages to an address. It only contains the very >>basic information that is common to all addresses, e.g. a country name. >>It may even be empty, but I want to show that it can contain some minimum >>information. It does not anticipate all the things that an address may >>possibly contain. >> >>2. I can create any number of variants of Address. I can have USAddress >>as a variant that includes the state. I can have a UKAddress variant that >>includes the county. All of these variants extend Address, so at the >>abstract level I could treat them all as addressed. They both have zip >>codes, but different type of zip codes (digits only in US, alphanumeric >>in UK). The variant is typed, so I can determine what the variant >>contains when I actually get a message with that variant. >> >>3. In the abstract message I have an element called BillingAddress of >>type Address (US, UK, or other) and an element called ShippingAddess of >>type Address. For the same of this example I assume all POs always >>contain both billing and shipping, but not specific formats of either >>addresses. >> >>4. All invoices are sent to address form the element BillingAddress. An >>expression of the form 'send invoice to po/BillingAddress' says that >>without forcing me to determine which specific address format will be >>used (it works equally well for US and UK addresses), but it >>distinguished the billing address from the shipping address (the later >>would be 'po/ShippingAddress'). >> >>5. One thing that will not work because it's context dependent is an >>expression of the form: ''po/BillingAddress/state", since the state >>element if specific to USAddress while BillingAddress is defined of type >>Address which does not include 'state'. Similarly >>"po/BillingAddress/county" will not work since 'county' is only used in >>UKAddress. >> >>Does that look like a reasonable way to achieve abstract message >>definitions that support different formats depending on the actual >>context, while allowing some things to be expressed in terms of the >>abstract message? >> >>arkin >> >> >>Burdett, David wrote: >> >> >> >>>Assaf >>> >>>I think we are both agreeind and disagreeing ;) >>> >>>I agree with you about the idea of having optional information in a business >>>document. The only reason I was pointing out the futility of relying on this >>>is that tying ANY *widely usable* choreography *definition* to a specific >>>document format will result in multiple choreography definitions that are >>>*identical* apart from the fact that they use different documents. I don't >>>think that defining the same thing multiple times is ever a good idea. >>> >>>The only way around this, as far as I know, is to make choreographies >>>reference an *abstract* message definitions which, in an implementation can >>>be bound to a specific message format or formats. For example you could have >>>the abstract idea of an order "message family" that can represent any order, >>>in any format. You could then express the choreography using message >>>families instead of specific message formats. >>> >>>I also recognize that you need, as part of a choreography, to interrogate >>>information in a message in order to control the flow of the choreography. >>>However, if the message definition in the choreography is abstract, this is >>>hard to do. >>> >>>One way around this is make decision in a choreography dependent on the >>>state of the role, where the state is affected by: the sending of a message, >>>the receiving of a message or the processing of a message. For example you >>>could have a state value of "USInvoice" in the choreography. This could then >>>be mapped to an XPath expression, for example, when the abstract message was >>>bound to the specific message format. >>> >>>Thoughts? >>> >>>Additional comments inline ... >>> >>>David >>> >>> >>> > > >-- >"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, 27 March 2003 15:29:37 UTC