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

+1

The idea of an layer above WSDL is good, I think.
I hope it would not be complex, as Mayilraj pointed out.

Yoko

> Abbie Barbir wrote:
> 
> +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 20:38:37 UTC