RE: TPA and ebXML Header question

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

Rik and Marty,

Concerning: 
> The messaging service should not have to know anything about 
> the sequencing
> requirements of the application.  The question is only whether the
> messaging service can provide a (possibly optional) valuable 
> service to the
> application by maintaining ordered delivery.  For an application using
> one-way messages (see subsequent posting for example) and 
> needing ordered
> delivery, providing ordered delivery in the messaging service 
> avoids the
> need for the application services layer to buffer a 
> (possibly) large number
> of sequence-numbered messages in order to correct any 
> mis-ordering before
> passing them to the application.

I think that session level aggregation of messages as Marty's
example may illustrate is just one of a large number of
BPs that benefit from a more general idea of keeping track
of the business conversation. The session level is above
where TRP has scoped itself to be. 

I agree with Marty, though, that unless applications have
been specially created with ebXML BP ordering requirements
in mind (and there are probably none of these), it would be interesting
to offer session level services on behalf of the application.
The session level would then talk to the TRP layer and TRP would
route to session (so the session layer would in effect be part of the
application layer from TRP's point of view).

But what should ebXML do about this spec-ing out this layer?
I think the May deadline means that nothing more than a few
session layer error messages (ebXML format) might be defined, such as

"Unexpected BP message arrival. BP message arrived before prerequisites
established."
"Message Arrived Too Late"
"Message has no Application Service registered to handle it."
"Message Refused because of Failures in other Required Documents"

and probably several more of this type. Notice that a strict
TRP MSH would treat these as business messages. (If they are
undeliverable, the suggestion would be log it and stop.)

How does this impact TRP? Only place I see is in the yet to
be written (and possibly not to be written) API interfacing
of the MSH with the layers below and the layers above at a
given node (that is, the node's protocol stack interfaces).


 

and so on.