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 PLEAE READ - Suggested solution to RM Issues


Arvola

I think I agree with your analysis. The main concern I have is that you do
not necessarily KNOW whether an intermediary is involved (see Chris Ferris's
email on the mail room use case at
http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00412.html).
Furthermore I think it is highly desirable that a sender of a message does
not NEED to know if intermediaries are being involved.

Let's look at this a bit more closely. Chris included the following diagram
in his email ...

	   MSH              MSH     MSH
  App-->A--->|--------->|->B->|-->B1-->App
             |          |     |
A's intranet | internet | DMZ | B's intranet
             |          |     |
        firewall    firewall firewall

If there is a CPA between A and B which covers all interactions, then as you
say below, the message is delivered with "Best Effort" semantics between A
and B. B however might, as a default for example, ALWAYS send messages from
B to B1 using ebXML O&O1 semantics. I can see no reason why B could not add
a Via/NAD to the message before forwarding it to B1 where the CPAId in the
Via over-rides, where relevant, the values for the CPA in the Message
Header.

Let's also look at the third party intermediary use case. Altering Chris's
diagram slightly gives ...

	   MSH                MSH                  MSH
  App-->A--->|--------->|--->B---> |--------->|-->C-->App
             |          |          |          |
A's intranet | internet | Redirect | internet | C's intranet
             |          |          |          |
        firewall                           firewall

In this case A sends a message with a "message level" CPA with C that
specifes the transport/messaging parameters required to send messages to B.
There is no Via/Nad element as A does not know that C is receiving messages
via B. B also has a CPA with C and references this CPA in the Via/NAD that B
adds to the message when they send it to C.

Yes I think this works.

David

-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Thursday, September 06, 2001 6:06 PM
To: Burdett, David; ebXML Messaging (E-mail)
Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues


David:

You asked me to check the contents of the Via element to see if the
Via element can be omitted when QOS is BestEffort for the single-hop
case:

><db>Not sure this works. There are additional attributes in the NAD (Via)
>element that are currently required such as syncReply. Arvola. Can you
ckeck
>the spec and determine which is optional which is required and specify what
>the default semantic should be for each of these elements/attributes if the
>NAD/Via is not present.</db>

Your proposed change #11 calls for having syncReply both under
MessageHeader and Via, so for the single-hop BestEffort case, the
information can be obtained from the MessageHeader.

The elements and attributes under Via are:

- CPAId -- not needed for single-hop
- Service -- not needed for single-hop
- Action -- not needed for single-hop
- id -- not needed when Via is not present
- version -- not needed when Via is not present
- actor -- not needed when Via is not present
- syncReply -- can be obtained from MessageHeader
- reliableMessagingMethod - not needed when QOS is BestEffort
- ackRequested -- not needed when QOS is BestEffort

Therefore, my conclusion remains that the Via element is not
needed when QOS is BestEffort and no intermediary is involved.

Regards,
-Arvola

-----Original Message-----
From: Burdett, David <david.burdett@commerceone.com>
To: ebXML Messaging (E-mail) <ebxml-msg@lists.oasis-open.org>
Cc: 'Arvola Chan' <arvola@tibco.com>
Date: Thursday, September 06, 2001 5:23 PM
Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues


>Arvola
>
>See comments in line.
>
>David
>
>-----Original Message-----
>From: Arvola Chan [mailto:arvola@tibco.com]
>Sent: Thursday, September 06, 2001 4:47 PM
>To: ebXML Messaging (E-mail)
>Subject: Re: T2 PLEAE READ - Suggested solution to RM Issues
>
>
>David and David:
>
>I don't have any major objection to the proposed changes.
>My comments are in tandem with David Fischer's bracketed
>by <ac> and </ac>.
>
>Regards,
>-Arvola
>
>-----Original Message-----
>From: David Fischer <david@drummondgroup.com>
>To: Burdett, David <david.burdett@commerceone.com>; ebXML Messaging
(E-mail)
><ebxml-msg@lists.oasis-open.org>
>Date: Thursday, September 06, 2001 3:19 PM
>Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues
>
>
>David,
>
>Looks pretty good.
><df>Comments inline</df>
>
>Regards,
>
>David.
>
>-----Original Message-----
>From: Burdett, David [mailto:david.burdett@commerceone.com]
>Sent: Thursday, September 06, 2001 1:44 PM
>To: ebXML Messaging (E-mail)
>Subject: T2 PLEAE READ - Suggested solution to RM Issues
>
>
>Folks
>
>If you do not respond to this email then, as chair of the T2 effort, I AM
>GOING TO ASSUME YOUR SUPPORT. So please read at least the first part of
this
>email which explains why I am doing this ...
>
>There has been a LOT of discussion about Reliable Messaging on the list. I
>also sense that different people's views are gradually aligning. However to
>move forward we HAVE to come up with constructive suggestions. I first did
>this a nearly a month ago see ...
>
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00125.html
>
>Although there were a lot of replies to this email few of them were about
>the actual suggestions I made. Those that were received (Arvola Chan &
David
>Fischer) were generally in agreement although both suggested worthwhile
>improvements. So in order to focus on the solution I have restated the
>approach in my earlier email below with a few tweaks to reflect more recent
>discussions.
>
>What I think will be really constructive is if we use this suggested
>solution as the basis for discussion so that we can refine it and hopefully
>finalize it in the F2F on October 3-5. Once we get agreement we can then
>start making changes.
>
>Furthermore, AS CHAIR OF THE T2 EFFORT I AM GOING TO ASSUME THAT NO COMMENT
>MEANS ACCEPTANCE. I don't like doing this but unless we start talking about
>solutions rather than problems we will not make progress.
>
>Does this makes sense?
>
>Finally, I've missed some of the detail of the discussions in order to make
>the suggested solution (fairly) brief. This does not mean they are not
>included ... they definitely will need to be ... and if they are important,
>I am sure you will make your views known ;)
>
>Best wishes to everyone.
>
>David
>SUGGESTED CHANGES TO SOLVE RM ISSUES
>
>Change 1
>--------
>Summary: Rename the Via element as "Next Actor Data" or similar.
>
>Rationale: There can always be "intermediaries" in a message transfer even
>if you are going point-to-point. For example consider the two example
>message flows that I recently posted that cover the following use cases:
>1. A genuine intermediary who is a third party that is running a MSH and
>forwards messages to the final destination.
>2. A Party which has a MSH that acts as a "mailroom" that forwards the
>message internally using ebXML RM to another MSH that then forwards it to
>the application. The "mailroom" MSH ia an intermediary. Chris Ferris
>provided an example of this use case at
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00412.html
>
>I think we need to support both use cases. By renaming the Via element as
>"Next Actor Data". We are simply saying that the data contained within the
>element is for the Next Actor **only** and does not need to be forwarded.
>The Next Actor recreates the data as they need to if they are forwarding
the
>message. If we think of the data in the Via as being for the "Next Actor"
>then we are also more closely aligned with SOAP. It also removes the
problem
>of treating intermediaries as "something special" and allows an internal
MSH
>to forward the message to another MSH without the original sender needing
to
>know and without having to re-create the complete message.
>
><df>I agree with all your rationale.  My only question is backward
>compatibility
>issues with 1.0 implementations due to the name changes.</df>
>
><ac>
>I am ambivalent about the name change. Clarification of the intent of the
>element and its usage rule is sufficient for me.
></ac>
><db>We might need to vote on this.</db>
>
>Change 2
>--------
>Summary: Data in the Next Actor Data (Via) element is for the Next Actor
>only
>
>Rationale: What Change 1 means is that we must carefully review the
existing
>elements in the header and check to see whether they are needed by the
>ultimate destination/endpoint or the next actor. I think that this will
>require the following changes:
>1. CPAId. The CPAId in the Message Header identifies parameters that apply
>"end-to-end", e.g. business process level stuff, whereas the CPAId in the
>NAD/Via element applies to the transport over a single hop, e.g. transport
>level stuff. I realise this will require changes to the CPP/A ... and
>probably more discussion.
>
><df>Agreed.  This may not require any CPA change at all since, as Marty put
>it,
>multi-hop is just a set of binary collaborations.  There is a CPA with the
>end
>and a CPA with the next hop.  This is perfect.  What is the value if there
>is no
>IM?  Needs to be optional or allowed to be empty.</df>
>
><ac>
>I agree with David Fischer.
></ac>
>
>2. Acknowledgment Element. This should be part of the NAD/Via element as
>acknowledgments are between two MSHs and are not propogated to the original
>sending party.
>
><df>No, if we move Acknowledgement to Via then we remove it from the
>Signature.
>This is OK if we don't want signed Acknowledgements.
>
><ac>
>I suppose it is possible that the CPA between two intermediate MSH
>calls for non repudiation of receipt in which case the Acknowledgement
>would have to be signed. I vote for keeping the Acknowledgement
>element outside of the Via element.
></ac>
><db>I agree with this also and have withdrawn this suggested change.</db>
>
>If we are going to make this massive a change, then let's go all the way
and
>move TraceHeaderList to Via and simplify the ds:Signature Transform.
>TraceHeaderList must be modified by each hop and then passed to the next.
>TraceHeaderList is intended for the next hop so it also should be part of
>Via.
>
><ac>
>I agree that it makes logical sense to move the TraceHeaderList
>under the Via/NAD element.
></ac>
><db>I've a change of view here in that we should not move it unless there
is
>a real reason. We just need to make it clear what the "next" and "to"
actors
>need to do with each SOAP extension</db>
></df>
>
>Change 3
>--------
>Summary: Make Next Actor Data (was Via) a required element.
>
>Rationale: There are two reasons for this:
>1. The current Via element contains data that is REQUIRED for
>point-to-point, e.g. ReliableMessagingMethod.
>2. There are two levels of reliability, that need to be covered:
>point-to-point (P2P) as well as end-to-end (E2E).
>
>Currently Via is optional. If we are doing point-to-point, then you would
>have to have ReliableMessagingMethod duplicated at the header level in
order
>to solve the problem. This does not make sense. Making NAD required solves
>this problem.
>
>The layering problem of P2P vs E2E is similar to the problem that TCP/IP
>solves as was clearly stated by Dan Weinreb at
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00225.html. Marty
>Sachs, David Fischer and others have also repeatedly said that unless you
>have end-to-end acknowledgement then there is no certainty. I think we need
>to recognize that there can always be two levels and therefore need to
>recognize both these levels in the header.
>
>Now TCP/IP does this as two SEPARATE layers. The current spec puts both
>layers in one spec with one header. I don't think we NEED to radically
>change the spec in this area but would like peoples views.
>
><df>Agreed.  What is the value of Via CPAId if there is no IM?</df>
>
><ac>
>The CPAId under the Via element is optional according to the XSD.
>If the QOS is BestEffort and no intermediary MSH is involved, there
>is no need for the Via/NAD element. I think it can remain optional as
>long as we can clearly articulate the circumstances under which it must
>be present.
></ac>
><db>Not sure this works. There are additional attributes in the NAD (Via)
>element that are currently required such as syncReply. Arvola. Can you
ckeck
>the spec and determine which is optional which is required and specify what
>the default semantic should be for each of these elements/attributes if the
>NAD/Via is not present.</db>
>
>Change 4
>--------
>Summary: Make the return of a Delivery Receipt required if
>deliverySemantics=OnceAndOnlyOnce
>
><df>Agreed</df>
>
><ac>
>I agree. Even if the incoming reliable message does not have
>the DeliveryReceiptRequested attribute set, the receiver MSH
>should still return a DeliveryReceipt.
></ac>
><db>I agree but is should be unsigned. This is the default value. See
>below.</db>
>
>Change 5
>--------
>Summary: Remove "None" as an option for deliveryReceiptRequested and make
>deliveryReceiptRequested=false the default.
>
>Rationale: As the return of a Delivery Receipt is the only sure way that
you
>know a message was delivered suggests that it will be a simpler solution if
>we make this always the case. Therefore we can make the return of a
delivery
>required if the deliverySemantics are OnceAndOnlyOnce. However you still
>need to know if the receipt must be signed.
>
><df>Agree with removing "None" but would prefer to leave as "Signed |
>Unsigned"
>for backward compatibility.  Default is "Unsigned".</df>
>
><ac>
>I agree with David Fischer.
></ac>
><db>So did I!</db>
>
>Change 6
>--------
>Summary: Make the return of an Acknowledgment element in a message required
>if the ebXML RM protocol is being used
>
><df>Agreed, but isn't this already true?</df>
>
><ac>
>I agree with David Burdett. The current spec does not required the
>Acknowledgement element to be present in an Acknowledgement
>message.
></ac>
><db>I agree with you and me ;)</db>
>
>Change 7
>--------
>Summary: Remove "None" as an option for ackRequested and make
>ackRequested=false the default.
>
>Rationale: The rationale for doing this is similar to changes 4 and 5. It
>simply gives the rule that if you are doing ebXML RM then you must include
>an Acknowledgment element in the response. The response can be synchronous
>or asynchronous (see change 11 below).
>
><df>Agree with removing "None" but would prefer to leave as "Signed |
>Unsigned"
>for backward compatibility.  Default is "Unsigned". (same as Change 5)</df>
>
><ac>
>I agree with David Fischer.
></ac>
>
>Change 8
>--------
>Summary: Include automated retry by the original sender (From Party) if no
>Delivery Receipt is returned
>
><df>Agreed</df>
>
><ac>
>Do we need to give some guideline on the selection of retry interval
>for hop-to-hop vs retry interval for end-to-end?  I think the former
>interval
>should be shorter than the latter.
></ac>
><db>Agree this would need to be included in the revised spec.</db>
>
>Change 9
>--------
>Summary: Include a "MessageRetryCount" in the NAD (was Via) element in the
>Message Header
>
>Rationale: There is a need for automated retry by the original sender (From
>party) if a Delivery Receipt is not received. However, the original sender
>wants to send the **identical** message yet not have it treated as a
>duplicate and by any intermediate MSH that has previously received it. To
>solve this problem you can add a "MessageRetryCount" to the NAD which
>indicates to the MSH that even though they have received the message before
>they must still forward it.In this case even if the resend is received
first
>and the original appears some time later, the ToParty will be able to
>recognize that the message has already been processed by comparing
MessagIds
>only and therefore the original should be ignored. This logic needs to be
>included in section 10 and will need to include another level of
>RetryCounts/RetryIntervals to work at the end-to-end rather than the
>point-to-point level.
>
><df>Agree on MessageRetryCount.  No need for another level of
>Retries/RetryInterval since it already exists -- there is one set in the
>end-to-end CPA (MessageHeader CPAId) and another in the Sender-FirstHop CPA
>(Via
>CPAId).</df>
>
><ac>
>I agree with David Fischer.
></ac>
>
>Change 11
>---------
>Summary: Include syncReply at both the Message Header and the NAD/Via
>elements
>
>The To Party needs to know whether the From Party wants the Delivery
Receipt
>and Business Payload assembled into one message.The next MSH needs to know
>whether to send back an Acknowledgment synchronously or wait for the
>Business Payload before sending it. The Delivery Receipt and Business
>Payload can be sent asynchronously and the Acknowledgment sent
synchronously
>and vice versa as they are independent of each other.
>
>As you can't easily cover both requirements in a single element, they need
>to be included separately in the header and in the NAD(Via).
>
><df>Agreed</df>
>
><ac>
>I agree in general.
>
>The semantics of syncReply need to be aligned with the CPP/A spec.
>The notions of signalsOnly, signalsAndResponse, and responseOnly
>in the CPP/A spec need to be expanded to cover Acknowledgements
>and DeliveryReceipt. Signals are application level messages according
>to the BPSS spec.
></ac>
><db>I agree that the MS and CPPA specs need to be aligned.</db>
>
>Change 12
>---------
>Summary: Clearly explain the relationship between applications, MSHs and
>partys and the need for notification.
>
>Rationale: Marty Sachs has clearly demonstrated the absolute need to be
>clear about stating the requirement that the From Party "knows" that the
>message has been delivered. We need to clarify the spec to make sure that
>this is clear.
>
><df>Agreed.</df>
>
><ac>
>I agree.
>
>I also like to propose a Change 13. If ackRequested is implied whenever
>deliverySemantics is onceAndOnlyOnce and reliableMessagingMethod
>is ebXML, then there is no real need for an ackRequested attribute
>(under the Via element).
><db>Disagree. You need to indicate whether it is signed or unsigned. With
>the changes above, if it is absent, then it implies that it is
>unsigned.</db>
>
>If end-to-end reliable messaging does not imply hop-to-hop reliable
>messaging, then we should clearly state that in the spec.
><db>Yes and no. I think that reliability works at two levels the hop and
>point-to-point. They can actually work independently of each other as Dan
>Weinreb has described.</db>
>
>Also, I believe in earlier discussions we have said that a Delivery
>Failure Notification message from an intermediate MSH to the
>sending MSH should be sent using reliable messaging. Such a
>statement and the rationale for doing so should be incorporated into
>section 10 as well.
><db>Agreed. Does the text contained in the email to Marty at
>http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00365.html meet
the
>need? It proposes a revision to section 10.4</db>
></ac>
>
>
>Product Manager, xCBL, XML Standards
>Solution Strategy, Commerce One
>4400 Rosewood Drive, Pleasanton, CA 94588, USA
>Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
>mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>----------------------------------------------------------------
>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