WSBinding and WSDLOperation in CPPA 2.1, and a proposal for BPSS OperationMapping syntax

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Title: Message

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)

 

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.