OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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