T2 Items August 1 to 10 that are missing from the list you publishedlast week

David:

 

Here is a retransmission in HTML format.

 

Regards,

-Arvola

 

Request Date: 8/6/2001
 
Request Source: 
e-mail

 

Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00038.html

 

Change Type: MinorTechnical

 

Requested By: Cait Crawford

 

Issue: Reliable Messaging section should be expanded to 
include the POINT-TO-POINT option where no Via or Acknowledgment elements are 
used

 

I have a comments/questions regarding POINT-TO-POINT reliable 
messaging
implementation for ebXML MS 1.0.

 

First, lets assume that Party A is sending a message reliably 
-- that the
deliverySemantics have been set to OnceAndOnlyOnce 
and
deliveryReceiptRequested to Unsigned (I don't think that 
Signed/Unsigned
makes a difference for the example, actually) in the 
QualityOfService
element in the MessageHeader.  I am sending this 
message w/out
intermediaries, so I am not making use of the Via or 
Acknowledgment
elements, although I am populating the TraceHeader element as 
appropriate.

 

Now, Party B receives the message.  Now assume that there 
is NO REPLY from
the application.  Party B is required to send an 
"Acknowledgement Message"
(section 10.3.2) which at a minimum has a 
MessageData element with a
RefToMessageId of the received message.  
Since a deliveryReceipt is also
requested, the MSH must also generate the 
DeliveryReceipt element in the
ack message.  My question concerns the 
service and action elements of this
ack.  Clearly, as there is no 
business-level reply, the service and action
should not reflect any business 
or application level service & action.  In
section 10.3.3, the spec 
says that if an Acknowledgment element is being
sent on its own then service 
MUST be set to:
uri:www.ebxml.org/messageService and action MUST be set to 
Acknowledgment.
What is the equivalent service/action for a DeliveryReceipt 
element being
sent on its own?? (as set in the MessageHeader element for this 
ack
message)??  Is this described in the CPP/BPSS since this is one of 
the
"signals" that need to be processed by the MSH-application 
interface??

 

What would happen if the deliveryReceiptRequested was false, 
but the
semantics were set to OnceAndOnlyOnce??  The minimal 
acknowledgement
required only a RefToMessageId within the MessageData element 
-- any
guidelines as to what should be used in the Service and Action 
elements in
the MessageHeader?

 

In general, I think that the Reliable Messaging section should 
be expanded
to include the POINT-TO-POINT option where no Via or 
Acknowledgment
elements are used, but deliveryReceiptRequested attributes are 
turned on.
(i.e. there is no information about whether the reply is sync or 
not in the
message header).

 

============================================================================

 

Request Date: 8/6/2001
 
Request Source: 
e-mail

 

Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00045.html

 

Change Type: MinorTechnical

 

Requested By: David Fischer

 

Issue: SyncReply and ReliableMessagingMethod should also be in 
QualityOfServiceInfo

 

There should be nothing in the Via which is not also in other 
headers.  Via
should only be used for multi-hop intermediaries.  In 
the case of SyncReply,
there is no single-hop way of requesting 
SyncReply=true.

 

Attributes SyncReply and ReliableMessagingMethod should also 
be in
QualityOfServiceInfo.  They should retain their current 
defaults.

 

============================================================================

 

Request Date: 8/9/2001
 
Request Source: 
e-mail

 

Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00095.html

 

Change Type: MSG/CPPA Alignment

 

Requested By: Himagiri Mukkamala

 

Issue: Schema element in Manifest 

 

Reference element has a schema element in it.
Where does 
this come from?

 

I could'nt find it in the CPA from the packaging 
element?

 

============================================================================

 

Request Date: 8/9/2001
 
Request Source: 
e-mail

 

Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00096.html

 

Change Type: MinorTechnical

 

Requested By: David Burdett

 

Issue: Need to change Service and Action for Errors, Delivery 
Receip ts etc. 

 

I agree that the spec is quite specific. However I think that 
having just one value for Service and Action for a Delivery Receipt makes it 
hard a MSH which receives a Delivery Receipt to work out which application to 
notify. For normal messages, Service and Action contain some useful name, e.g 
Service=SupplierOrderManagement, Action=NewPurchase order. This can be used to 
route the message to the application that supports 
OrderManagement.
 
On a Delivery Receipt, Service contains 
"uri:www.ebXML.org/messageService" and Action "DeliveryReceipt" as you quote 
below and the MSH is given no clue on which application to forward the message 
to.
 
This means that the MSH has to look up the original message 
sent to work out where the DR was sent to.
 
There is an IDENTICAL 
problem with Error Messages as the MSH will not know which the application to 
forward the message to. This time though, it is worse as the message may not 
have been saved if it was sent with RM as BestEffort. If we don't change the 
spec then a Sending MSH will have to PERSIST ALL MESSAGES whether sent reliably 
or not so that they can work out which applicatioon to notify if there is an 
error.
 
The better alternative I propose is to make Action hold all 
the information, e.g. 
    Action 
=uri:www.ebXML.org/messageService/MessageError
 
Then Service could 
contain "BuyerOrderManagement" so that the MSH could work out which application 
to notify of the error. However this requires that you know what to put in the 
Service when an error or other similar message is returned to the sender of a 
message. To solve this you also need to specify the Sending "From Service" in 
the original 
message.
 
============================================================================

 

Request Date: 8/9/2001
 
Request Source: 
e-mail

 

Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00107.html

 

Change Type: minorTechnical

 

Requested By: David Smiley

 

Issue: Use of Message Status Requests

 

Being relatively new to the ebXML world, but learning more 
every day, I have
been hesitant to jump in where those even more experienced 
may fear to
tread, but here I go...

 

I have extracted a relevant paragraph from the large body of 
the "T2
SyncReply and ReliableMessagingMethod in
QualityOfServiceI nfo" 
thread.

 

<Martin W Sachs>
The problem about this use case is 
that the intermediary is neither a
participant in the business process nor 
strictly a
pass through.  I suspect that means that it does participate 
in the
business process though "not much".
</Martin W 
Sachs>

 

From a business perspective, please help me understand how any 
intermediary
is not a participant in the business process? If they are only a 
"pass
through", why are they used? If they are involved, but "not much", is 
that
like being "a little pregnant" ;-)? It seems to me that any party 
which
handles my business transactions, intelligently, persistently or 
otherwise,
is part of the business process.

 

In the discussion of acks, delivery receipts, reliable 
messaging and floods,
no mention is made of the use of Message Status 
Requests. I realize that
this capability is optional in the implementation of 
a Message Service
Handler, but wouldn't it be useful in some of the scenarios 
mentioned? In
lieu of always resending a message whose delivery status is 
unknown, use of
Message Status Requests could reduce the number of large 
messages that are
resent unnecessarily. This may result in a very high tide, 
but floods may be
avoided.

 

============================================================================

 

Request Date: 8/10/2001
 
Request Source: 
e-mail

 

Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00125.html

 

Change Type: MajorTechnical

 

Requested By: David Burdett

 

Issue: Proposed solution for various issues related to 
reliable messaging

 

I have some ideas for a few changes that might solve the 
problems raised in
this thread so the rest of this email contains:
1. 
Extracts from a number of recent emails from you both and analysis of 
the
issues/requirements they raise
2. Some additional further analysis of 
the issues to identify a few more
requirements
3. A proposed solution to 
meeting the identified requirements which
hopefully will solve the problem 
... and who knows perhaps bring this email
thread to an end :-)

 

So please let me know if:
a) I've missed a 
requirement
b) You (or anyone else) think the proposed solutiuon is wrong or 
could be
improved ... but then I know you will anyway ;)

 

Details below

 

David
******************************
EMAIL THREAD and 
ISSUES/REQUIREMENTS
====================================

 

Arvola Chan: Thu 8/9/2001 3:28 
PM
---------------------------------
>>I am of the opinion that the 
DeliveryReceipt element should be used by the
ToParty MSH to inform the 
FromParty MSH that a reliable message has been
received. ... It is the 
non-arrival of a DeliveryReceipt that requries the
MSH to notify the 
application. In this case, it must rely on persistent
information to 
determine the application service that must be notified.<<

 

>>I think end to end acknowledgement is always needed to 
support reliable
messaging, so it is unnecessary to explicitly set 
deliveryReceiptRequested
to true, it should always be implied by 
deliverySemantics of
OnceAndOnlyOnce. On the other hand, if intermediary acks 
are optional, then
ackRequested needs to be an explicit attribute at the QOS 
level and it
should apply to all intermediaries.<<

 

[DavidB]This highlights a number of 
issues/requirements:
Req 1. A positive Ack sent back to the sender of a 
message by the ultimate
destination is the only sure way the sender can be 
certain the message was
delivered. If no Delivery Receipt is sent, then the 
sender cannot be so
certain.
Req 2. If end-to-end Delivery Receipts are 
always required for the sender to
be certain, then it would be simpler if 
there was a rule that
deliverySemantics of OnceAndOnlyOnce implies a Delivery 
Receipt is sent. The
only remaining issue is whether or not the Delivery 
Receipt should be
signed.

 

David Fischer: Thu 8/9/2001 7:31 
PM
-----------------------------------
>>Question 1 ... the 
end-to-end MUST be able to do RM as if it does not know
(which it probably 
doesn't) what the IM(s) are doing.  The end-to-end
probably doesn't care 
if the IM(s) are doing RM at all (even though each IM
might care very 
much)<<

 

>>On the issue of Sender time outs and retries, their 
are two kinds:  1) a
timeout to the first IM and 2) a timeout getting to 
the end.  The first is
easy and obvious so we don't need to discuss 
it.  The second is a timeframe
that is usually contractually guaranteed 
...<<

 

>>While the Sender/Receiver may not have any idea what 
path or IM transport
the message is taking (and they really don't need to) 
they must have an idea
about delivery times to the end.  We MUST 
generate some kind of an
end-to-end Ack allowing the ends to do 
RM.<<

 

>>Proposal:
1) We need to update section 10 with 
end-to-end RM (deliveryReceipt or
something new that is similar to 
Acknowledgement).
2) We need to put in the spec somewhere that ALL 
MessageHeaders (including
Via) MUST be passed to the next hop, including the 
end.<<

 

>>Question 2 ... I agree that it doesn't matter if 
ackRequested gets changed
because an Ack gets sent based upon 
DeliverySemantics (This was my second
solution to Question 2).  Why then 
do we have ackRequested?  The only way it
would change is if there was 
some kind of local CPA overriding ackRequested.
If RM is requested and an IM 
can do RM then it MUST, right?  Then why have
this parameter?  (I 
see from your comments that you are considering this.)
<<

 

[DavidB]This highlights a number of 
issues/requirements:
Req 3. The sender should not know nor care if an IM is 
being used and
whether or not they are doing RM with the next IM.
Req 4. 
There are two different types of "acks" that are useful:
  a) It's been 
accepted by the postal system (i.e. the next MSH has
received, this is the 
Acknowledgement Message)
  b) It's been received by the final 
destination (i.e. the To Party has
received it, this is the Delivery 
Receipt)
Req 5. Even if the initial Ack (i.e. Acknowledgment Message) is 
received
there needs to be some method of automated retry if the Delivery 
Receipt is
not received within the expected timeframe.
Req 6. If you a 
doing reliable messaging between two hops, then you do not
need ackReqeusted 
as an acknowledgment must be sent if the ebXML RM protocol
is being sent and 
not needed if it isn't.

 

David Fischer: Thu 8/9/2001 8:02 
PM
-----------------------------------
>>I am concerned that 
end-to-end RM is taking a back seat to IM RM.  This is
the opposite of 
how it should be.  Most transactions will be single-hop.
Many other 
cases will be single IM where the sender or receiver may not even
know there 
is an IM so it still appears to be single-hop.  The ends should
not even 
have to know about the IMs.  Ends will always do automatic retries.
RM 
should work for the ends in exactly the same manner whether or not there
are 
IMs.<<

 

[DavidB]This really just provides further support for 
issues/requirements
numbered 3 and 5 above.

 

Arvola Chan: Fri 8/10/2001 12:23 
AM
-----------------------------------
>>Even if you have a channel 
that calls for the use of synchronous reply
mode, the syncReply attribute 
still has to be set. In other words, it is
still necessary to use the Via 
element if the syncReply attribute is present
only there, but this 
constradicts the assumption that the Via element is
only used when 
intermediaries are involved.<<

 

[DavidB]This highlights a number of 
issues/requirements:
Req 7. The syncReply needs to be set at the message 
level whether or not an
intermediary is being used
Req 8. There is a 
contradiction in the spec (which therefore needs to be
removed) that the Via 
element is only for intermediaries when it is actually
also needed for 
non-intermediaries.

 

DAVID BURDETT's COMMENTS
========================
Before 
proposing a resolution to all these requirements I'd like to make a
few 
comments and identify an additional couple of requirements.

 

Firstly on Requirement 6 above (you don't need ackRequested). 
There could be
benefit in gettingan acknowledgement element back even if you 
are using a
reliable messaging protocol such as MQ Series as you then have 
evidence
(especially if it is signed) that the next MSH has received the 
message. I'm
not convinced though that this is a huge benefit.

 

Secondly if we put syncReply at the message level then there 
is an
additional requirement ...
Req 9. The next recipient of a message 
needs to know whether or not to
return an acknowledgement message 
synchronously or not.

 

Now for the proposed solution. 

 

PROPOSED SOLUTION
=================
The solution 
dsecribed below refers to the requirements identified above ...

 

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 (also posted here) 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.

 

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 we think of 
the data
in the Via as being for the "Next Actor" then we are 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.

 

This change addresses Req 3 and 8.

 

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

 

This change addresses Req 3, 4a

 

Change 3
--------
Summary: Make the return of a Delivery 
Receipt required if
deliverySemantics=OnceAndOnlyOnce
Change 
4
--------
Summary: Replace deliveryReceiptRequested by 
deliverReceiptSigned=true or
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.

 

These changes address Reqs 1, 2, 4b

 

Change 5
--------
Summary: Make the return of an 
Acknowledgment element in a message required
if the ebXML RM protocol is 
being used
Change 6
--------
Summary: Replace ackRequested by 
ackSigned=true or false(the default)

 

Rationale: The rationale for doing this is similar to changes 
3 and 4. 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 9 below).

 

Change 7
--------
Summary: Include automated retry by 
the original sender (From Party) if no
Delivery Receipt is returned
Change 
8
--------
Summary: Include "ResendOfMessageId" 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
cannot send the **identical** message as it will be treated 
as a duplicate
and therefore ignored by any intermediate MSH that has 
previously received
it. To solve this problem the from party needs to use a 
different MessageId.
However there is now a need to stop the message being 
treated as a
completely new message. To solve this problem we could add 
a
"ResendOfMessageId" element that identifies which message the new message 
is
a resend of. 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 and therefore the original should 
be
ignored. This logic needs to be included in section 10 and probably needs 
a
bit more thinking through.

 

These changes addresses Req 5

 

Change 9
--------
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 via.

 

This change adresses Reqs 7 and 9.

 

============================================================================

 

Request Date: 8/10/2001
 
Request Source: 
e-mail

 

Source Reference: http://lists.oasis-open.org/archives/ebxml-msg/200108/msg00127.html

 

Change Type: Editorial

 

Requested By: David Fischer

 

Issue: Inconsistent SERVICE specification 

 

The Service for an Acknowledgement should match between 10.3.2 
number 1 and
10.3.3 second bullet set, first bullet.  Action is 
correct.

 

Service=uri:www.ebxml.org/messageService/