MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] Propsals from Shan Harter
Title: RE: [ebxml-msg] Propsals from Shan Harter
Ian:
Interesting use case. My comments:
First a few comments on conformance to ebMS2:
(a)- there are several Acks going on, yet there is no apparent use of the Reliability feature (e.g. no AckRequested element, but introduction of header extension (non normative):
<eb:QualityofServiceInfo eb:deliverySemantics="OnceAndOnlyOnce"/>
(b)- the Acknowledgement element does not contain RefToMessageID (not conforming). Instead, the Response message presents itself as an (empty) business message that is referring to the previous one, and just acting as an business-level Ack - see the "Upload / Response" [Service/Action] message. The contained Ack element seems to be just as a way to distinguish from error cases.
General comments:
(c)- these acks and other Receipts (see the "Download/CompleteRequest" and "Download/CompleteResponse" messages) are driven at application level. With Reliable messaging, they should not have to. Unless some business receipt is needed.
(d)- The scenario is indeed a case of Push-and-Pull MEP, although not the most straightforward: one where there may be many responses. The pulling demonstrated here is a 2-step pull, with step1 to get a list of DocumentIDs ("Directory/Request"), step2 to fetch each Doc individually ("Download/Request") all this implemented outside ebMS2 because it does not support queuing/pulling. (It seems that it is the best alternative.)
(e)- We can speculate that users would not need to do this with ebMS3: the "Server" would just post 1 by 1 all its response docs, each as a separate message. The Client MSH would then either pull these 1 by 1, but not based on DocumentID (nor on messageID), just FIFO. This is not even a case for pull-by-messageID, since once posted by the Server app, there is no rationale for pulling the responses based on messageID (the client can't make the association messageID-documentID).
(f)- Talking of support for such a Push-and-(multiple)Pull MEP: at MSH level, the correlation between all these responses and the initial request, would only appear via RefToMessageId. Although we might make the case that the client MSH has the ability to selectively pull (based on RefToMessageId ) these responses from Server (e.g. to satisfy a "GetResponseFrom" API call from its app) I would not go there: I believe it is again up to the queuing at Client MSH to support such API calls. Does not have to translate into selective pulling between MSHs.
So I see this use case as indeed a good case for Pulling (here, Push-and-Pull MEP), the "Server" being only able to respond to protocol requests. I think a lot of what the use case is implementing on top of ebMS2 can be supported by ebMS3.
Jacques