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

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.  Much of this can be 
fixed by appropriately adding DeliveryReceipt to section 10.

 

Marty is right, a phone call will not do.  We have to have 
end-to-end RM FIRST and then add IM RM.

 

Regards,

 

David Fischer

Drummond Group.

  
-----Original Message-----
From: Arvola Chan 
  [mailto:]
Sent: Thursday, August 09, 2001 5:28 
  PM
To: Burdett David; 'Dr Crawford'; 
  
Subject: 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: