Re: Need to change Service and Action for Errors,Delivery Receipts etc.

David:

 

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. Therefore, it is moot as to which application needs to be 
notified when a standalone message is received containing a single 
DeliveryReceipt element (because it is really intended for the sending MSH). 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. This is one point that the spec 
needs to clarify.

 

By the way, I find the reliable messaging section in 0.93 
version of the TRP spec

 

http://lists.ebxml.org/archives/ebxml-transport/200102/msg00019.html

 

much more logical than the one in the 1.0 spec. At least, it 
explicitly covers the scenario of multi-hop reliable messaging and talks about 
the possibility of reliable messaging with or without intermediary acks. In 
particular, it distinguishes two types of acknowledgements, one used by 
intermediary MSHs to the previous hop MSH and the other used by the ToParty MSH 
to the FromParty MSH. I am curious as to how RM ends up in the current broken 
state in the 1.0 spec.

 

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. When an intermediary uses non 
ebXML reliable messaging methods that still guarantees delivery, then 
ackRequested simply does not apply to such intermediaries.

 

I agree with you that the problem is more serious for error 
messages. In the case of the RosettaNet message header, both the from service 
and the to service are included. Therefore, in case of errors, it is easy to 
figure out which service at the sender should be notified. I am in favor of your 
proposal to add the from service to the ebXML message header.

 

Thanks,

-Arvola

  
-----Original Message-----
From: 
  Burdett, David <>
To: 
  'Arvola Chan' <>; 'Dr Crawford' <>;  
  <>
Date: 
  Thursday, August 09, 2001 10:29 AM
Subject: T2: Need to change 
  Service and Action for Errors, Delivery Receipts etc.

  
Arvola

  
 

  
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.

  
 

  
Thoughts?

  
 

  
David

  
    
-----Original Message-----
From: Arvola Chan 
    [mailto:]
Sent: Wednesday, August 08, 2001 6:59 
    PM
To: Burdett, David; 'Dr Crawford'; 
    
Subject: Re: T2: Reliable Messaging 
    (point-to-point)

    
Sorry for the delayed response. I was tied up the last 
    couple of days attending to some personal matters.

    
 

    

    
To answer Cait's original question about the Service and Action 
    elements that should be used when a message containing a DeliveryReceipt 
    element is to be sent not in conjunction with any business level reply, the 
    following excerpt from the 1.0 spec clearly states:

    
If there are no errors in the message received and a DeliveryReceipt is being sent on its own, not as part 848

    
of message containing payload data, then the Service and Action 
    MUST be set as follows: 
    849

    
· 
    the Service element MUST be set to uri:www.ebXML.org/messageService/ 850

    
· 
    the Action element MUST be set to DeliveryReceipt 851

    
Unfortunately, the above information is located in section 8.4.7.1 
    deliveyReceiptRequested attribute, rather than in section 8.14 
    DeliveryReceipt element.

    
 

    
I believe the spec is currently quite specific about the Service and 
    Action elements to use when Acknowledgement, DeliveryReceipt, Error, 
    StatusRequest, StatusResponse, and Ping elements are sent on their own (not 
    in conjunction with business payloads).

    
 

    
-Arvola

    
 

    
-----Original Message-----
From: Burdett, 
    David <>
To: 
    'Dr Crawford' <>;  
    <>
Date: 
    Monday, August 06, 2001 6:39 PM
Subject: RE: T2: Reliable Messaging 
    (point-to-point)

    
>I think that this is a bug in the spec.
>

    
 

    
>To solve this problem I think we should include in every message 
    that is
>sent, an identifier for Service that is sending it. You can 
    then use this
>Service when returning a message if there is no 
    business process specific
>one to use instead. You would then use the 
    Action element to identify why
>the message is being 
    sent.
>
>If we make this approach the rule for returning errors, 
    for example, then it
>fixes the problem that a MSH does not know which 
    application it should
>notify if the original message was not 
    persisted (which it shouldn't be if
>it was not sent 
    reliably).
>
>I also think we should follow the same approach 
    for the Message Status and
>Ping transactions for the same 
    reasons.
>
>Thoughts?
>
>David
>
>-----Original 
    Message-----
>From: Dr Crawford [mailto:]
>Sent: 
    Monday, August 06, 2001 8:11 AM
>To: 
>Subject: 
    T2: Reliable Messaging 
    (point-to-point)
>
>
>
>
>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).
>
>Your 
    guidance is greatly 
    appreciated.
>
>Regards,
>Cait
>
>Cait 
    Crawford
>B2B Integration
>IBM Research
>Hawthorne, 
    NY
>
>
>
>------------------------------------------------------------------
>To 
    unsubscribe from this elist send a message with the single 
    word
>"unsubscribe" in the body to: 
>
>------------------------------------------------------------------
>To 
    unsubscribe from this elist send a message with the single 
    word
>"unsubscribe" in the body to: