Re: [ebxml-bp] WSBinding and WSDLOperation in CPPA 2.1, and a proposalfor BPSS OperationMapping syntax

[David RR Webber <david@drrw.info>]

Dale,

Thinking about this - there's nothing to stop someone creating several 
WSDL to map to the ebMS CPPA requirements,
and then just having different ports actioning those on the WSDL side. 
It's not as convenient as doing everything
through one port - but does allow what we need to function. however - 
its quite typical for people to have
separate input and output services and ports, to keep those two things 
distinct. This would just add additional
ports depending on service level and application. These then map to 
descreet steps within the BPSS BTA as
needed.

For example - urgent shipping notices may be received on a different 
channel from parts availability requests, and
then payment authorization would be on another, and so on.

Otherwise - your notes below all make sense. Are we at the point where 
we can draft a Technical Note - or at
least an outline for one, on all this? And then a supplemental question 
- that TN would want to include the
stuff JJ has been working on in parallel too...

Thanks, DW

=================================================
Dale Moberg wrote:

> Hi
>
> I recently made some updates to the maintenance CPPA version that 
> provides support for WSDL configuration information for CPPA.
>
> It may be of interest to consider how this works in CPPA, because CPPA 
> is about taking the business level description of process and relating 
> it to the technical messaging protocol and security details that are 
> needed for full configuration of the interfaces of the business 
> participants.
>
> The server receiver only needs to indicate the “interface” aspects of 
> WSDL. These aspects are found within the wsdl:portType (v1.1) (or 
> wsdl:Interface v2.0), its included wsdl:operations and referenced 
> wsdl:message, wsdl:type, or wsdl:part elements (the precise elements 
> needed differ in WSDL versions). For each /ActionBinding, /the 
> interface’s operation needs to be identified. The 
> */WSDLOperation/@operationRef /*uses a URI-Reference to identify the 
> operation. This reference is constructed by appending a fragment 
> identifier to the targetNamespace URI. The fragment is constructed 
> using a syntax similar to that of XPointer that is documented in 
> [AppendixC WSDL 2.0 Core]
>
> For example, if the */WSDLOperation /*contains
>
> <tp:DocExchange docExchangeId="docExchangeA1">
>
> <tp:WSReceiverBinding version="2.1">
>
> <tp:WSDLOperation version="1.1" 
> operationRef="http://hello.org/hello1#operation(Hello/sayHello)" >
>
> <wsdl:definitions xmlns:tns="http://hello.org/hello1"; 
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/";
>
> targetNamespace="http://hello.org/hello1"; name="HelloWorld">
>
> <types/>
>
> <message name="Hello">
>
> <part name="String_1" type="xsd:string"/>
>
> </message>
>
> <wsdl:portType name="Hello">
>
> <operation name="sayHello" parameterOrder="String_1">
>
> <input message="tns:Hello"/>
>
> </operation>
>
> </wsdl:portType>
>
> </wsdl:definitions>
>
> </tp:WSDLOperation>
>
> </tp:WSReceiverBinding>
>
> </tp:DocExchange>
>
> then the URI-Reference
>
> http://hello.org/hello1#operation(Hello/sayHello 
> <http://hello.org/hello1#operation%28Hello/sayHello>)
>
> would select the wsdl:operation that has been previously referred to 
> in a */ServiceBinding /*
>
> *//*
>
> <tp:ServiceBinding>
>
> <tp:Service>urn:w3c:wsd:hello</tp:Service>
>
> <tp:CanReceive>
>
> <tp:ThisPartyActionBinding id="companyA_TPAB2" action="OneWay" 
> packageId="PlainSOAP">
>
> <tp:BusinessTransactionCharacteristics 
> isNonRepudiationRequired="false" 
> isNonRepudiationReceiptRequired="false" isConfidential="none" 
> isAuthenticated="none"
>
> isTamperProof="none" isAuthorizationRequired="false"/>
>
> <tp:ChannelId>ChannelA1</tp:ChannelId>
>
> </tp:ThisPartyActionBinding>
>
> </tp:CanReceive>
>
> </tp:ServiceBinding>
>
> One problem has been that picking out what is relevant in the 
> operation varies depending on whether the DocExchange aspect of the 
> DeliveryChannel is in a CanSend, a CanReceive, or a nested 
> CanReceive/CanSend context. ebXML has chosen to have a separate 
> configuration for each message sent and received. That is, there are 
> separably configurable "sides" for each message sent. Each sent 
> message is considered an Action. For WS, an operation can span several 
> ebXML actions. In addition, fault messages are defined that can be 
> sent instead of a message or in reaction to a message. That means that 
> for WS MEPs beyond the In-Only and Out-Only, there really needs to be 
> something that points to the "part" of the operation that is being 
> configured. To do this, additional URI-References are required that 
> point to the input, output or fault messages that make up the ebXML 
> Action.
>
> Unfortunately, inputs and outputs don't have names in WSDL so the 
> previous way of referring does not work. In WSDL 1.1, the input and 
> output references a message, so message references works for this 
> version. For WSDL 2.0, however, the message construct is removed, and 
> the corresponding link to the type is made using the value of an 
> attribute named "element"-- the value is the qname of the globally 
> declared element.
>
> I was going to make some updates to the schema for CPPA to solve the 
> above problem, when the following idea occurred to me:
>
> Since CPPA and BPSS have the same granularity of its basic Actions, 
> (the parts of the BT) something like the above apparatus will be 
> needed in our BPSS 2.0 OperationMapping construct.
>
> What I propose is that however we chose to do this mapping in BPSS, we 
> make it congruent with CPPA. This would mean that in generating a CPP 
> when given a BPSS instance that contains OperationMapping elements, 
> the CPP can derive from the BPSS instance the precise details needed 
> in the WSDLOperation section of its configuration for a Delivery Channel.
>