Re: [ebxml-cppa] New InOut (with fault replacing message rule) WSDL2.0 example illustrating 3.0 features

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>moberg: 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?
>
mm1:  I think my response would be we need both (similar to my response 
in your previous message). Conversely we have roles, how those roles are 
related to patterns and requests or responses, then the binding of those 
roles to specific activities.

> 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?
>  
>
mm1: I think we should maintain the separation of this - actual BTA to 
the actions associated with the patterns (in ebBP sense).

>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)?
>
mm1: Yes, so there is differentiation.

>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?]
>  
>
mm1: Yes, because we've provided that flexibility elsewhere and likely 
will need it even though we may currently only envision we may.

>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)?
>  
>
mm1: Yes.

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