Subject: Change request to ebXML TRP.
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
Powered by eList eXpress LLC