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

["Pim van der Eijk" <lists@sonnenglanz.net>]

Yes, there is a proposal for CPA 3.0 where channels for
messages can be associated with anonymous endpoints.  This
means that these messages cannot be sent as standalone
messages on connections initiated for their transmission,
but only on (backchannels) of some existing connection.
Then, there is a concept of "related channels" for typed
links between channels, expressing that one channel is
associated with another channel that the synchronous
response can be sent over. I believe this is an improvement
over using nesting for synchronous responses. 

Another drawback of nesting is that you cannot easily list
synchronous and synchronous transmission of responses as
alternatives, and use the CPP intersection to select one or
the other. 

Pim 

-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com] 
Sent: 18 January 2011 18:50
To: Sigbjørn Berntzen; ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] Transport elements in CPP & CPA

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