Sample Transport elements for One Way, Pull Mode for ebMS 3.0 in CPPA 2.

This is the first in a series of examples illustrating ebMS 3.0 MEPs using the newly proposed classification by Jacques Durand (I will supply a URL for this document when Jacques posts it)

Remember that these ebMS MEPs are not SOAP MEPs or WSDL 2.0 MEPs but are aligned with the abstraction layers of ebXML.

Brief terminology tutorial: Sender is the participant that sends the ebMS User message to the Receiver. In CPPA terms, the ebMS Sender announces capabilities in a “CanSend” element and the corresponding ebMS Receiver announces capabilities in a CanReceive element. [Note that the values used are just invented and not yet agreed to by TC.]

<AccessAuthentication>basic</AccessAuthentication>

<EncryptionAlgorithm minimumStrength="168"

w3c="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" >des_EDE3_CBC</EncryptionAlgorithm>

</TransportServerSecurity>

</TransportSender>

</Transport>

Notice that in this use of Transport information, the “method” of the TransportProtocol has been extended to include HTTP-Response as a method. This is because the HTTP response is being used to send the UserMessage, and not a method like GET or POST. This is the “back channel” identified by the anonymous EPR in WS-speak. Should we borrow some of the WS speak in describing this or not? (I wonder whether these figures of speech will eventually be replaced.) Notice also that we still need to use the Endpoint element to identify the URL to be used by the TransportReceiver (who initiates the HTTP interaction and so needs to be informed what URL to contact).

Next is the corresponding Transport element for the user message Receiver

<TransportProtocol version="1.0" mep="ebMS-Pull" method="POST">HTTPS</TransportProtocol>

<AccessAuthentication>basic</AccessAuthentication>

</TransportServerSecurity>

</TransportReceiver>

</Transport>

Note that in the attached schema, there is a mep attribute that in effect provides use case information for the way in which the HTTP transfer protocol is being used. I raised the issue today for the TC members of whether this mep attribute should be on the Transport protocol or rather should occur in either

1. an updated MessageCharacteristics content model?

2. a new DocumentExchange element that collects this new MEP related information?

For the last 5 years or so, we have attempted to collect CollaborationProtocol information in parts of the CPP or CPA that roughly follow widely recognized layers of wire formats. However, transport may not really be a good place for a “mep” value because the mep value is about reading/writing coordination (what kinds of payloads are expected for what parts of the protocol message exchange). The way these expectations were documented in ebMS 2.0 was partly with the synchReplyMode values in MessageCharacteristics. But those enumerated values are probably being displaced by the PMode options being defined for ebMS 3.0.

So, while the above Transport changes accommodate the Transport basics for One Way, Pull Mode, we still have to agree upon a place to indicate

1. mep information (assuming it is needed or useful for display tools)

2. the agreement on MPF values used in the signal.

3. the fact that a Pull signal message is provided by the Receiver (I think that having a MPF value would imply this, however).

4. the various PMode flavors that indicate what Reliability (and other) conventions are in place.

The charts Jacques is working on should help a lot in enumerating all the sensible configuration options.

We need to consider what groupings of the new bits of information make sense in accommodating ebMS 3.0 in the next couple of months.

ebxml-cppa message