RE: T2 PLEAE READ - Suggested solution to RM Issues

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

Title: RE: T2 PLEAE READ - Suggested solution to RM Issues

Bob

 

See comments below. However I would like to repeate one point you made and my response up here ...

Change 11
---------
Summary: Include syncReply at both the Message Header and the NAD/Via
elements

MILR: IMO, this is a substantive change (not V1.1)

[David B] I think this is a bug. Without this the spec does not work properly when a message is sent through an intermediary as the TO Party cannot know whether to put the Delivery Receipt in the same message as the Business Response or separately. It is also, IMO not that substantive. Remember the criteria for including something in v 1.1 was that it should be a bug or a clarification. If we need to make "substantive" changes to fix a bug then we still have to make the changes.

 

 

David

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Friday, September 07, 2001 6:51 AM
To: Burdett, David; ebXML Messaging (E-mail)
Subject: RE: T2 PLEAE READ - Suggested solution to RM Issues

David,

My comments and concerns are imbedded.

Cheers,
         Bob

-----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.

MILR: No thank you.  I call that a substantive change, and 'Via' is a fine element name.

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.

Change 2
--------
Summary: Data in the Next Actor Data (Via) element is for the Next Actor
only

MILR: Yes, that sounds like a good editorial clarification of the purpose of the Via construct.

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.
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.

Change 3
--------
Summary: Make Next Actor Data (was Via) a required element.

MILR: No thank you.  I would support an editorial change that defined a default
for ReliableMessagingMethod in the absence of Via.  Of coure, in the editorial
changes, one could then make it clear that Via was required in some instances,
as when the specified ReliableMessagingMethod was not the default value.
[David B] I think I am coming to the same conclusion (see recent reply to Arvola). My concern was that there was some element in the Via/NAD that was always required. I will probably withdraw this change but would like some more time to think about it as there just might be a "gotcha" in there. 

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.

Change 4
--------
Summary: Make the return of a Delivery Receipt required if
deliverySemantics=OnceAndOnlyOnce
Change 5
--------

MILR: I support the default.  I do not understand why "None" would be removed
as an option ( I assume None and false are synonymous ).
[David B] Putting in "false" was a mistake. It should have said "Unsigned". 

Summary: Remove "None" as an option for deliveryReceiptRequested and make
deliveryReceiptRequested=false the default. IMO, removal of None is a
substantive change.

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.

Change 6
--------
Summary: Make the return of an Acknowledgment element in a message required
if the ebXML RM protocol is being used

Change 7
--------
Summary: Remove "None" as an option for ackRequested and make
ackRequested=false the default.

MILR: I support the default.  I do not understand why "None" would be removed
as an option ( I assume None and false are synonyms )  IMO, removal of None
is a substantive change.
[David B] See comment on change 5. 

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).

Change 8
--------
Summary: Include automated retry by the original sender (From Party) if no
Delivery Receipt is returned
Change 9
--------
Summary: Include a "MessageRetryCount" in the NAD (was Via) element in the
Message Header

MILR: IMO, this is a substantive change (not V1.1).
[David B] I think you are perhaps right and I know we set our criteria to include bugs and clarifications.  However you could argue that without this you do not get true "end-to-end" relilability and therefore it is a "bug". I will flag this separately on an email.

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.

Change 11
---------
Summary: Include syncReply at both the Message Header and the NAD/Via
elements

MILR: IMO, this is a substantive change (not V1.1)
[David B] I think this is a bug. Without this the spec does not work properly when a message is sent through an intermediary as the TO Party cannot know whether to put the Delivery Receipt in the same message as the Business Response or separately. It is also, IMO not that substantive. Remember the criteria for including something in v 1.1 was that it should be a bug or a clarification. If we need to make "substantive" changes to fix a bug then we have to make the changes.

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).

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.

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>