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