Re: Abstract messages [Was: Multi-Party Binding Scenario]

+1

arkin

William Eidson wrote:

>  Tony -
>
>  I think you hit the nail on the head when you described EDI and ASN.1 as
>syntaxes.  I strongly believe that we should tie ourselves to WSDL/Schema,
>but that does not mean that we are tied to the XML syntax in the actual
>messages exchanged.
>  Both schema and WSDL both operate at the xml information level not the xml
>syntax level, so, for example, a WSDL interface can easily be used to
>describe an EDI or ASN.1 message.  What is missing right now are standard
>bindings to EDI/ASN.1/name-your-favorite-encoding+transport, however, there
>are plenty of companies already providing and using EDI<->XML converters.  A
>processor is, of course, able internally to represent the data however it
>chooses, provided it can logically present it as XML when needed.
>  I think the cost of adding a level of indirection above WSDL/Schema would
>be enormous in terms of extra complexity and user-confusion.  Instead, we
>should work to leverage the extensibility and openness already in WSDL and
>the richness and expressiveness already in schema.
>
>  Thanks,
>
>  - Bill
>
>
>  
>
>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>[mailto:public-ws-chor-request@w3.org]On Behalf Of Fletcher, Tony
>>Sent: Wednesday, April 02, 2003 3:43 AM
>>To: jdart@tibco.com; public-ws-chor@w3.org
>>Subject: RE: Abstract messages [Was: Multi-Party Binding Scenario]
>>
>>
>>
>>Thank you to Jon and the others in this group for doing this work and
>>compiling this summary and returning it to the main group.
>>
>>As we are all aware I am sure, there are many different groups that are
>>doing message design - UN/CEFACT Forum trade groups, OASIS UBL, OAG,
>>OTA, RosettaNet and UCC to name but a few (and there are many others,
>>particularly more industry specific ones).  Therefore I think we should
>>take it as given that this WS-Choreography group should not get into
>>message design (a requirement on what we should not do, if you like).
>>
>>Although XML is very popular at the moment, there are other syntaxes
>>such as the various flavours of EDI and ASN.1 plus the various
>>constrained forms such as XHTML and WML - and I am sure there will be
>>others in the future.  To me this argues for defining a choreography
>>dependent only on message type / purpose rather than detailed content as
>>far as possible (may be a 'best practice') and expressing any dependence
>>on data in terms of the abstract data content (/meaning).  Then have a
>>separate binding to actual messages, specific WSDL, transport details
>>and so on.  This should allow the generation of re-usable 'prototype'
>>choreographies that can be particularised to specific circumstances
>>(parties requirements) with a specific binding.
>>
>>So my personal inclination at present (not a considered company
>>position!) is to say:
>>
>>1.   Yes
>>
>>2.   Yes
>>
>>3.   No (not for the Choreography itself, but have a binding to WSDL and
>>XML message schema)
>>
>>Best Regards     Tony
>>A M Fletcher
>>
>>Cohesions 1.0 (TM)
>>
>>Business transaction management software for application coordination
>>
>>Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
>>Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
>>7801 948219
>>tony.fletcher@choreology.com     (Home: amfletcher@iee.org)
>>
>>
>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>[mailto:public-ws-chor-request@w3.org] On Behalf Of Jon Dart
>>Sent: 01 April 2003 19:48
>>To: public-ws-chor@w3.org
>>Subject: RE: Abstract messages [Was: Multi-Party Binding Scenario]
>>
>>
>>
>>As David Burdett suggested, we've taken some discussion of the WSDL
>>dependency issue discussed in the "Abstract messages" thread off-line.
>>Participants in this off-line discussion included David, myself, Assaf
>>Arkin, William Eidson, Ricky Ho, and Patil Sanjaykumar.
>>
>>I'd like to summarize this discussion, which concluded with a conference
>>call yesterday.
>>
>>The original issue was whether it is a requirement or not to decouple
>>the public (aka external) view of the choreography from WSDL.
>>
>>The motiviation for decoupling the choreography from WSDL was to be able
>>to support general choreography definitions that can work with a variety
>>of message formats (representing, for example, standards that are
>>specific to certain industries). There was some discussion of how real a
>>use case this is, but David's input is that at least for Commerce One,
>>it is a common case (Assaf concurs).
>>
>>This raises a difficulty in cases where the choreography flow depends on
>>the message contents. In those cases, you need to be able to extract the
>>relevant parts of the message in order to make a test. The logic behind
>>the test could be opaque (i.e. not specified in the external
>>definition), but if it is not opaque, then it does need to reference
>>message contents somehow and therefore (it seems) must assume something
>>about the schema.
>>
>>David's original proposed solution was to separate the input and output
>>schemas of the messages in the choreography from the choreography
>>definition itself, and also to have the requirement that decision points
>>based on message contents could be abstractly specified, and later bound
>>to a particular schema. E.g. suppose we are testing the contents of an
>>address, but it might be in a "USAddress" element or "UKAddress"
>>element. In that case we may want to not specify the test (e.g. XPath
>>expression) in the choreography, but instead put it in an external
>>binding.
>>
>>Bill pointed out that WSDL definitions can vary in degree of
>>abstractness. We could say it is necesary to specify a schema for the
>>messages, but that schema could specify very little about the message
>>structure, could define variant structures, and could leave places where
>>extensions can be made. This being the case, it is possible that a
>>single schema could express a range of possible message types. Also this
>>allows tests to be be made on those portions of the message that are
>>specified, without requiring that the message schema be made totally
>>specific in the choreography.
>>
>>Finally, the issue was discussed, whether it is ever necessary to
>>specify message definitions in such an abstract form that they may not
>>even be XML, i.e. do we want to eliminate not only dependence on WSDL,
>>but also dependence on XML Schema? Or, on the contrary, can we assume
>>that at least at the point where the choreography is evaluating the
>>message contents, that they are XML?
>>
>>IMO we could at this point just say that there's a requirement to
>>support use of the same choreography definition with varying message
>>schemas, and let it go at that. This is after all the requirements
>>phase.
>>
>>However, at a lower level of detail (and closer to implementation) we
>>have these questions:
>>
>>1. Do we need, or want, to support external binding of the message
>>schemas to the choreography definition, so that you can distinguish
>>between the abstract operation you are performing as written
>>in the choregraphy, and the actual service with which you communicate?
>>(Thanks to Assaf for helping phrase this clearly. N.b. BPEL4WS does
>>this, through the concepts of partners, roles, and serviceLinkTypes).
>>
>>2. Do we need to allow external binding of decision points (based on
>>message content) to specific decision logic, or it is sufficient to
>>encode decisions in the choreography, given that they can be based on a
>>partially abstract schema?
>>
>>3. (Most fundamental) Should the choreography definition explicitly
>>assume that metadata exists in the form of WSDL and XML Schema?
>>
>>David has an action item to further examine WSDL and XML Schema (esp.
>>the latter) to see if its abstraction capabilities could be made use of
>>to allow a solution to the message-independence requirement different
>>from the one he originally proposed (in particular: Bill's alternative).
>>
>>IMHO: 1. may be desirable just as a good design principle as it furthers
>>re-use; 2. external binding is probably not necessary but we might vote
>>to allow it as an optional feature (I don't think it should be
>>required); 3. My preference would be to use WSDL + XML Schema, if these
>>are sufficiently expressive to meet the use cases (David's further input
>>needed here).
>>
>>--Jon
>>
>>
>>
>>
>>    
>>
>
>  
>


-- 
"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 Wednesday, 2 April 2003 14:56:56 UTC