[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: TPA and ebXML Header question
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC