[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Behavior of IM and non IM MSH,was RE: T2 PLEAE READ -Suggested solution to RM Issues
All, I'm not sure where all this discussion about unreliable links comes from. I suspect it is tied to the idea that links might not support ebXML Reliable Messaging. This has always been a part of the multi-hop design. This does NOT mean these links are "Unreliable". They may support their own type of RM (HTTP/R, MQSeries -- reliableMessagingMethod="Transport"). This may, or may not, be translatable into ebXML-RM. This is an important distinction. The question then is: What happens if a request is made for ebXML-RM on a link which does not support ebXML-RM (perhaps supports MQSeries instead). Again, this does NOT mean these links are "Unreliable". Regards, David Fischer Drummond Group -----Original Message----- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Friday, September 14, 2001 11:40 AM To: David Fischer; Dan Weinreb; david.burdett@commerceone.com; mwsachs@us.ibm.com; chris.ferris@east.sun.com; arvola@tibco.com Cc: ebxml-msg@lists.oasis-open.org Subject: RE: T2 Behavior of IM and non IM MSH,was RE: T2 PLEAE READ - Sugges ted solution to RM Issues Dan Weinreb (I hope) said: "I think that someone reading the current ebXML MS spec, as it is currently worded, could easily be forgiven for thinking that there is no such concept as a "non-ebXML link in the path between two intermediaries". I don't think the existing spec, as currently worded, gives the reader any warning that such a thing is being contemplated." I agree that this idea is new to me. If there are such links, I think that they should have as much relevance as the fact that routers are routing IP packets between autonomous systems! We should be concerned with ebXML MS speakers, and the protocols for their message exchange(s). Dan continues: "And here's a question I don't think we've asked before. Marty said: Consider this: A----B----C----D Clearly, A and D have to communicate end to end via ebXML messaging, CPA (virtual or real), and BPSS (virtual or real). The problem is that there is nothing requiring that the link between B and C be an ebXML path. Therefore both of our previous comments that all IM nodes must have two MSHs are not correct. OK, let's say there's nothing requiring that the link between B and C be an ebXML path." I really don't think TRP/MSG should be concerned with issues involving sub-protocol or trans-protocol traffic. If two MSHes communicate "out of 'ebXML MS' band" they are not talking or conforming with the ebXML spec. Definitely out of scope in my opinion. Dan continues: "Is there anything requiring that the link between A and B be an ebXML path? Clearly A and D have to communicate using ebXML, but if B and C are free to do their own thing, why not A and B? Is there some special rule about hops to which the endspoints are parties, that makes those hops different from IM-to-IM hops?" [arpanet analogy deleted though it is interesting but involves the above out of scope concerns] Dan notes: "We have said that in the A-B-C-D example, A would have "two CPA's", one being a CPA between A and B, and the other being a CPA between A and D. But think about what's actually in the CPA. Some of the information in the CPA is meaningful for the A - D communication, but entirely meaningless for the A - B communication (e.g. the Process Specification and Packaging elements)," If you are using "meaningless" to mean that it won't be relevant to the operations of the MSH, I agree, for the most part. This is because the intermediaries are mainly just forwarding. If they go beyond forwarding, I believe we should prescribe that they are now into a new BP (segment), and have their own BP descriptions. We are probably at that point into multiparty BPs, and we want this to be a 2.0 matter. So for 1.1, only forwarding intermediaries are under discussion. And I agree that your observation is accurate for these. Same thought applies to this from Dan "whereas other information in the CPA is meaningful for A - B but meaningless for A - D (e.g. the Transport element)." Dan states: "To me this seems like a clear sign that something is wrong." A peer to peer protocol definition is not really geared to discuss intermediaries typically. For analogies of what would really be involved to have a community of forwarders meshed with peer endpoints, I would recommend looking at the APEX protocol for ideas and people who have already been there. (APEX rides on top of BEEP by a standard BEEP profiling mechanism). But only for 2.0! I think that ebXML in general will provide a proper treatment of intermediaries once both BPSS and CPA evolve to handle multiparty conversations. If we can confine TRP MSG to handle standard MSH to MSH and the additional case of forwarders, that would be sufficient for 1.1. CPAs were not intended to govern agreements involving forwarding, and you are right that they would have superfluous elements when applied to the forwarding scenarios. Dan says: "The CPA does not seem to be intended for use between two entities (A and B, in this case) that are only talking to each other about hops, and not talking to each other about business processes at all." Agreed. "It would be clearer and more elegant if an explicit distinction were made between the two layers, i.e. separating the subject material suitable for the A - B discourse from the material suitable for the A - D discourse, both in the MS spec and in the CPA spec. I realize that we can't do that as part of a 1.1 release, but maybe it should be considered for 2.0." But we already do this! The BPSS layer is that higher layer! The CPA does say what has been agreed upon how to relate that higher layer to its implementation details (details that need to be agreed upon for interoperability at several levels). The CPA is not really a layer at all, but more like a map of one layer BPSS onto a lower layer (ebXML MSG, for example). ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC