Another change request to ebXML TRP.

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

Hello. 

This is Jay Kasi again. I have one more change request to ebXML TRP. This
was hinted at by David Burdett, 
but I wanted to give a more indepth analysis. 

LINE RANGE: 

None, because this talks about something not addressed in the specification.


COMMENT: 

Support sending service in the header. 

RATIONALE: 

It is very important to support the sending service in the header for the
following reasons. 

1. It is useful for any kind of persisted data like send or receive side
persisted data for ebXML reliability, 
    Billing log, Audit log, Data warehouse, Business intelligence, etc. 
2. It is important to support the concept of a Trading partner using
multiple MSHs as endpoints. This is 
    mappable to the service concept where the service could be the
distributeable entity. However this is not 
    supported for response messages like error messages, syncreplys, ack
messages, status responses, etc. 
    It is important to be able to route these responses to the right MSH
that issues the original message. This 
    can best be done by including the sending service in the original
message, and address the response to 
    a predefined action in that service. Example of a distributed trading
partner is a TP who is both a buyer 
    buying from his site and a hosted supplier hosted at a marketplace. 
3. Commerceone has many use cases where a single MSH is shared by multiple
"applications". The same 
    Trading Partner may be hosting all these applications so we cannot
distinguish the application from the 
    addressed trading partner. By the term application here, I am loosely
refering to a set of services that are 
    related like "procurement" or "order management". These are typically
seperately developed. It is important 
    that these applications be able to handle errors independently instead
of with a shared application or MSH 
    component. This can best be achieved by addressing the response to a
service in the original message.
4. It is therotically possible to handle 1. and 2. by using the
senderURI/receiverURI for routing purposes as transport
    addresses, however it gets very complicated to string these references
properly with persistence at every router 
    in the path. The message has to retrace back the path the original
message followed with the correlationID/
    from/to combination used to correlated persisted original message at
every hop with the response message
    to figure out the next transport address. However I think this is highly
undesireable and unneeded complexity.
5. It intutively makes sense to make the service addressing symmetric.

PROPOSAL: 

I would like to propose the following: 

1. Sending service is in the header. 
2. All error, status, ack and sync responses have this as the receiving
service with the action being a predefined 
    ebXML action. 
3. I would suggest ebXML recommending to Biztalk to also support the concept
of a sending, receiving service 
    and action. Currently in Biztalk 2.0, we have to overload From, To with
service semantics which is not the 
    intent of Biztalk (It should be a business trading partner), and also
the topic with action semantics (it should
    be a document type). This will aligh Biztalk with ebXML very nicely so a
Biztalk ebXML gateway can be built.