[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: FW: T2 SyncReply and ReliableMessagingMethod inQualityOfServiceInfo
Dan, you're correct. There can be a problem here if the IM does not already know where to forward a message. The only way this will work in the current spec is if there is a URI/URL in the To+PartyID. This might be in the form of HTTP://www... or it might be mailto://... Since there can be multiple PartyID elements in the To. I would suggest this one SHOULD be first. On Routing, there are two kinds: Message Level and Workflow. We are not doing Workflow right now, maybe in v2.0 (SOAP-RP). On IMs, yes, both ends probably need to know about their adjacent IMs (although the sending MSH might not know that they are sending to the Receiver's IM rather than direct, and visa versa). However, there is no need for the ends to know how those adjacent IMs communicate, as long as there is enough information in the headers for that communication to occur (like the URL in PartyID and other info found in Via). OTOH, I don't really see this as dynamic. The route, except for perhaps a failure situation, will probably be static. There would be MUCH more overhead in requiring complete knowledge of some prescriptive route. I don't think this is much of an issue since when we talk about more than one IM we are probably talking about the one percentile (or less) situation. Regards, David Fischer Drummond Group. -----Original Message----- From: Dan Weinreb [mailto:dlw@exceloncorp.com] Sent: Tuesday, August 14, 2001 8:37 AM To: ebxml-msg@lists.oasis-open.org Subject: Re: FW: T2 SyncReply and ReliableMessagingMethod inQualityOfServiceInfo I recently read the 73 previous emails in this thread. As a newcomer to the discussion, I apologize in advance if I backtrack over ground that was already covered before I started listening, but I hope my perspective as a newcomer might be helpful. I found some of the points made in the discussion difficult to evaluate, because I don't feel that I understand the scope of what intermediaries are about. Is there a set of "use cases" illustrating the ways in which it is anticipated that intermediaries would be used? In each case, it would be helpful to understand the extent to which use of the intermediary would have to be pre-arranged and/or understood by the From and To parties, both at the MSH level and at the business level. I'd also like to better understanding the question of "routing": if an intermediary receives a message destined for some party, how does it determine which communications protocol to use and what communications-level address to use? There were two interesting use cases mentioned earlier in the thread. One was in Chris F.'s mail (of Wed, 08 Aug 2001 20:02:22), where one endpoint party, which doesn't have a permanent presence on the Internet, "uses an intermediary as a way station between itself and another intermittently connected partner". Here, the payload is unaffected, and the intermediary is being used entirely at the MSH level. Another was in David B.'s mail (of Wed, 08 Aug 2001 18:35:13), in which the intermediary translates payloads between RosettaNet and EDI formats, and uses ebXML without RM over MQSeries on one hop, and ebXML RM on the other. Are these considered representative? Is there a requirements statement somewhere that explains what sorts of use cases the Message Service is supposed to support? In both cases, I would think that the use of the intermediary would have to be pre-agreed by both sides, rather than being "invisible" to either, and rather than being determined entirely dynamically (at runtime after all pre-agreements). In both cases, I'm not sure how the intermediary knows where to send a message to, once it has received the message. The From MSH sends out the original message specifying the ultimate destination in the MessageHeader/To/PartyID, and sending the message to a communications address (e.g. an HTTP URL, an email address, or an MQSeries queue name) that specifies the intermediary. How does the intermediary know what communications protocol and what communications address to use in order to get to the final destination? Even if the From and To parties agreed in advance on this, and put it in their common CPA (even though I don't see how the existing CPA format could represent this), would the intermediary be expected to have a copy of that CPA? David B.'s mail says: The intermediary has separate agreements with each party What this means is that there two types of agreements in place: 1. Between the From or To Party and the Intermediary which covers how messages are sent but NOT the business process. 2. Between the From and To Party directly that cover the business process they will follow but not how messages are sent. This sounds right to me. And it explains how the intermediary knows where to send a message to. It implies that there really need to be two kinds of pre-agreement, rather than just one (the CPA). That seems to be a rather important implication, which was not followed up on in subsequent mail. Shouldn't this receive more attention? Digression about layering (please take with a grain of salt): There has also been discussion of having two kinds of acknowledgments, two kinds of message ID's (either in the form of David B.'s proposed ResendOfMessageId or David F.'s retry-number), etc. My immediate reaction to all this, which I realize is rather radical, is that perhaps what's needed is to separate the whole protocol into two layers: a lower layer at which intermediaries are fully visible, and a higher layer at which the intermediaries are invisible. Protocol layering has been used extensively in real networks with a lot of success. For example, each layer would have its own concept of acknowledgement. An acknowledgement at the higher layer (similar to the current Delivery Receipt) would look, to the lower layer, like just another message to be delivered, since the lower layer would not interpret the higher layer. We would not have to ask questions about how Acknowledge's and Delivery Receipt's interact with each other, such as in Arvola C.'s mail (of Sun, 12 Aug 2001 11:15:43). Each layer would have its own way to do duplicate elimination and retransmitting where necessary (just as the next layer down, TCP, has its own duplicate elimination and retransmitting!). And each layer would have its own form of pre-agreement, the CPA being the one for the higher layer, and a new one being introduced for the lower layer. I realize that it's late in the game to suggest something like this, and I apologize if I'm sounding presumptuous, but it's possible that thinking in terms of this kind of layering might suggest useful approaches. ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC