RE: [ebxml-dev] Transport elements in CPP & CPA

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

The treatment of "synchronous reply mode" is targeted for quite a few changes in the gradually emerging CPPA v 3.0, and several are needed to deal with ebMS 3. A number of conventions used in CPPA v 2.0 have been identified as needing modification, clarification or alternative simplified treatment. Maintenance of CPPA is done in the OASIS TC ebCore. The CPPA TC is finished. I will forward your message to the ebCore group.

There are a variety of considerations that will impact V 3 CPPA. One is reduction in the "nested" elements so that using the same connection for back and forth exchanges will not require placing an action binding for the response under the element for request. Transport elements are to allow HTTP methods and include HTTP response as a "method" for its use as a backchannel. The reduction of ad hoc attributes and values is also pending.

The motivation for having both elements present was, I think, connected with building a CPA by matching tests made on the types and values of information items in the CPPs. Support for simplicity in the tests sometimes seemed to promote uniformity of structure, at the expense of economy. Unfortunately I have not located any notes, or list messages that document the tangle you mention in your message. 

It does seem that something is misleading in the passage:

"For a synchronous response, the "response" endpoint is ignored if
present. A synchronous response is always returned on the existing
connection, i.e. to the URI that is identified as the source of the
connection."

If, as a matter of definition, when CPPs have TransportSender and TransportReceiver elements they are called "bi-directional," and for synchronous messages the CPP  must have a bi-directional transport, it would be true that the responding side's endpoint would be ignored. What seems misleading is in saying the return message is "to the URI that is identified as the source of the connection" I am not certain what the editor meant there, but since one URI is to be ignored, the only non-ignored URI is that of the Receiver which I guess can be described as the "source of the connection." [It is what the TCP connection request contacts, and makes use of the socket that is listening...]
	
I am sympathetic with your objections, but at this point, it is probably best to do something about your concerns in CPPA v 3, rather than smooth out CPPA v 2. I will forward this to the ebCore's CPPA subcommittee chair for his consideration.

Thanks for your comments.


-----Original Message-----
From: Sigbjørn Berntzen [mailto:sberntz@gmail.com] 
Sent: Thursday, January 13, 2011 8:27 AM
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] Transport elements in CPP & CPA

We are setting up CPP's and CPA's for synchronuos ebXML communication
and are wondering about a portion of the spec (ebXML CPP/A
specification v2.0 chapter 8.4.24) where it says.
"A Transport that contains both TransportSender and TransportReceiver
elements is said to be bi-directional in that it can be used for send
and receiving messages.
If the Party prefers to communicate in synchronous mode (where replies
are returned over the same TCP connections messages are sent on; see
Section 8.4.23.1),
its CPP MUST provide a ServiceBinding that contains ActionBindings
that are bound to a DeliveryChannel that uses a bi-directional
Transport."

but later in 8.4.38.1 it states
"For a synchronous response, the "response" endpoint is ignored if
present. A synchronous response is always returned on the existing
connection, i.e. to the URI that is identified as the source of the
connection."

Thus in order to have a synchonous response you have to include an
TransportReceiver with an endpoint that is explicitely never used.
 Wouldn't it be better to not include the TransportReceiver at all and
thus show directly in the CPP that the endpoint in TransportReceiver
is never used.
As it is now you have to include an endpoint even for an
implementation where no incoming traffic is possible or allowed except
as a direct response in the outgoing session.

What is the purpose of this?  And is this how the specification should
be or is this an error that should be corrected?

---
Sigbjorn Berntzen
BAR Consult AS