Change request to ebXML TRP.

["Kasi, Jay" <jay.kasi@commerceone.com>]

Hello. 

My name is Jay Kasi. I am the platform architect for commerceone and am
responsible for ebXML 
TRP compliance of the commerceone platform. 

LINE RANGE ------>

I dont really have a line range since what I want to talk about is not
addressed by the specification. 

COMMENT ------>

Need some support in ebXML TRP for sync messages. 

RATIONALE ------>

My definition of a sync request is that the issuing thread blocks until
there is a response (application or error) or timeout. This parallels the
concept of an RPC paradigm that SOAP does support. 
 
SOAP says the following: 
"Processing a message or a part of a message requires that the SOAP
processor understands, among other things, the exchange pattern being used
(one way, request/response, multicast, etc.), the role of the recipient in
that pattern, the employment (if any) of RPC mechanisms such as the one
documented in section 7, the representation or encoding of data, as well as
other semantics necessary for correct processing."
This basically implies that there is no SOAP specified indication of a sync
request and a sync response in the envelope, but this is semantics that is
implied by the message and understood by the endpoints.  
This causes problems when a sync response has to be routed across multiple
routers (Like the Global Trading Web supported by Commerceone). This is not
a problem if the transport is HTTP where the response is returned in the
same connection. The problem here is that we supports a MOM transport
(SonicMQ). Every MSH/router visited has a blocked thread waiting for a
response. This thread may timeout (based on time to live) and disappear
before the response arrives. When the response arrives in the MOM transport
later, there is no indication that this is a sync response. If we knew this
is a sync response, we could see if there is a thread waiting for this
response (by matching conversaion ID, from, to combination) and discard the
message if there was not. Without this knowledge, we would route the message
back as a SOAP oneway response if there is no blocked thread. We also have
to assume that any message may be a sync response and check for a blocked
threads waiting. Thi is not desireable.   
It also causes problems for gateways (for example a BIZTALK gateway which is
also based on SOAP) that has to figure out if a gateway thread should block
waiting for a ebXML response using a MOM transport because this is a sync
request. 
We plan to solve the sync request gateway problem by having the commerceone
directory specify if the target service/action is supported synchronously by
the receiving service. Ideally this information should be added to the
CPP/CPA. 
For the sync response problem, we need a change to ebXML TRP. 
PROPOSAL:  
I dont think the VIA clause (where syncreply can be specified) is the right
place for this because mu perception is that VIA
is not targeted towards routers in the path. The routers in the path if any
should be invisible to the sender. Also syncreply in the VIA clause is only
supported for a sync transport like HTTPS. What I am trying to do is
implement the application semantic of a sync request/response without using
a sync transport.  

I suggest making the action for a sync response be a ebXML predefined
action. This gives us a clear way to determine if a message is a sync
response and we are then free to support sync request/response with many
kinds of async transports (SMTP, FTP, MQSeries, Sonic/MQ, etc) besides sync
transports (HTTP). 

A possible action is: 

uri:www.ebxml.org/messageAction/SyncResponse