W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

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

From: Abbie Barbir <abbieb@nortelnetworks.com>
Date: Wed, 2 Apr 2003 14:01:01 -0500
Message-ID: <87609AFB433BD5118D5E0002A52CD75405562F8E@zcard0k6.ca.nortel.com>
To: Mayilraj Krishnan <mkrishna@cisco.com>, William Eidson <weidson@tibco.com>
Cc: Fletcher Tony <Tony.Fletcher@choreology.com>, public-ws-chor@w3.org

+1

abbie

> -----Original Message-----
> From: Mayilraj Krishnan [mailto:mkrishna@cisco.com] 
> Sent: Wednesday, April 02, 2003 1:57 PM
> To: William Eidson
> Cc: Fletcher Tony; public-ws-chor@w3.org
> Subject: RE: Abstract messages [Was: Multi-Party Binding Scenario]
> 
> 
> 
> +1.
> Then this group will nicely align with other specifications 
> in the web 
> services world
> with less complexity. I am not opposed to creating an 
> indirection layer 
> above WSDL
> if it is not complex and does not prevent using other web service 
> specifications (eg. security,
> transaction, callback etc)
> 
> Thanks
> Mayilraj
> At 09:56 AM 4/2/2003 -0800, 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
> > >
> > >
> > >
> > >
> 
> 
Received on Wednesday, 2 April 2003 14:01:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:14 GMT