RE: T2 PLEAE READ - Suggested solution to RM Issues

["Burdett, David" <david.burdett@commerceone.com>]

Dan

We discussed this on the conference call earlier today. However for the
record, here's the thinking.

1. We cannot assume that everyone will be using ebXML for all nodes in a
message path as there is a lot of legacy stuff out there. Eventually
perhaps, but not in the short term. This means that anything that REQUIRES
ebXML at all nodes in a message path will only have limited use.
2. In the use case I am proposing the first hop (A to B) is using ebXML but
the second hop (B to C) is not.
3. If C does not support a delivery receipt, then it can still work as B
will have to report failure to A if it cannot reliably delilver the document
to C.
4. If A requests a delivery receipt but C can't deliver it, then B would
return a "NotSupported" error on receipt of the message from A as B knows
that C cannot deliver the receipt.

MORE THAN TWO INTERMEDIARIES
The same approach still works even if we are going from A to B to C to D, as
follow where ebXML is used for A to B and B to C and something else for C to
D:
1. A sends the message to B. 
2. B knows C supports ebXML so C forwards the message
3. C knows that D doesn't support delivery receipts so returns a
"NotSupported" error.

REVERSE MESSAGE FLOW
It also works the other way round, suppose D is sending a message to A where
D to C is not ebXML, and C to B and B to A are ebXML. In this case:
1. D sends a message to C reliably by some non ebXML protocol
2. C converts the message to ebXML and sends it to B reliably.
3. B sends the message to A.

David

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Friday, September 07, 2001 9:29 PM
To: Burdett, David
Cc: chris.ferris@east.sun.com; arvola@tibco.com;
ebxml-msg@lists.oasis-open.org
Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues


   Date: Fri, 07 Sep 2001 16:07:05 -0700
   From: "Burdett, David" <david.burdett@commerceone.com>

   Suppose you have three parties, A, B and C. B is an intermediary. A & B
   agree to use ebXML. B and C agree to use the BizTalk Framework (which
also
   supports reliable messaging). So you can get end-to-end reliable
messaging
   as all hops are reliable. I think your words would not allow this use
case
   because the second hop is not ebXML. How would you make this use case
work?"

I don't understand how this kind of use case works at all.  Are you
saying that A and C are conducting a business transaction with each
other, and B is acting as an intermediary, and yet A and C aren't
in any sense using the same protocol?

Is there an ebXML CPA between A and C?  Is there a BPSS that A and C
have agreed upon?  If so, I would say that A and C are both using
ebXML.  B and C might agree to use BizTalk Framework as an underlying
communications protocol; that is, they might use BizTalk Framework in
place of HTTP or SMTP.  Then they would not need to use ebXML-style
"retry if you don't get an Acknowledgment" because they have an
underlying reliable protocol.  (Ditto if they communicate using
MQSeries.)  But, C is definitely running an ebXML MSH.

Or are you sahing that A is conducting a business transaction with B,
and the business process on B is simultaneously engaging in business
processes with both A and C?  That's fine, but in that case there
isn't any concept of messages being sent from A to C or C to A; A and
C would not even know about each other.


-- Dan