New InOut (with fault replacing message rule) WSDL 2.0 example illustrat

ebXML CPPA 3.0 adds on an approach to extensibility of both CPPs and CPAs that conserves previous CPP/CPA 2.0 instances after only namespace and prefix changes.

The TC has also indicated an interest in “flattening” the XML structure (that is, in allowing a choice between the old highly nested version and a flatter variant) and increasing opportunities for reuse, especially for BusinessTransactionCharacteristics and MesssagingCharacteristics.

A number of extensions have been added to accommodate alternative messaging systems, business process descriptions, and collaboration protocol features such as WSDL descriptions, ws-policy extensions, and more generalized transport descriptions.

In order to check some of these features I have prepared a lengthy example illustrating some proposed enhancements, and I am seeking TC feedback on some details as well as the overall approach.

1. flattened CollaborationRole

2. reuse of BusinessTransactionCharacteristics and MessagingCharacteristics

3. support for WS request response and faults

4. support for BPSS 2.0 with OperationMapping

5. support for WSDL 2.0

I am enclosing a zip file (renamed with zzz extension) with the schema versions needed for checking the examples, wsdls, and the various instances. Only one CPP for the web service is provided. I also have uploaded the zip file to the Document area of the TC.

Before completing the examples (adding the service invoker CPP and a CPA) and rechecking details, I want to pose several questions that emerged while testing the new enhancements.

1. The flattening dropped an @action attribute on the new ActionBinding element. The action value is now in the ActionContext2/@requestOrResponseAction information item. Should an @action attribute be added to ActionBinding? Should the use of ActionContext2 be reconsidered, and possibly remove the requestOrResponseAction attribute? Is the BTA id value sufficient to define action context, except for cases involving reuse of BusinessCollaborations?

2. When faults are used in WSDL and used in “synchronous” MEPs, should an explict ActionBinding be provided for the fault (so it is treated as a distinct information item with its own channel properties)?

3. Should the @faultRef on WSDLOperation element, be a list of URIReference type? [WSDL 2 leaves a lot of room for inventing new MEPs that might not fit smoothly into the CanSend/CanReceive pairs we now use to describe each channel. Should we try to accommodate this generality?]

4. Also, at the moment, the faultRef values point to the main fault and ignore the infault/outfault distinction (because CPP context makes clear in what direction the fault flows). Should we permit the faultRef’s URIReferences to an infault or an outfault (then these wsdl information items enable referencing the actual fault message using its ref attribute)?

[Note that several schema location values point to a local filesystem directory and will probably need to be changed to work in another environment.]

ebxml-cppa message