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

"Burdett, David" wrote:
> 
> Scott
> 
> Message Type went ages ago. The problem is that for errors, delivery
> receipts, message status responses, MSH Pong messages. etc, there is not
> enough information in the header for a MSH to work out which
> service/application forward the message to. Really these messages need to
> contain the id of Service that sent the original message or made the
> request. This information is not in the request at the moment. Hence the
> bug.

In the absence of a CPA, and without any manner of state associated
with a conversation, this may be true. 

> 
> David
> 
> -----Original Message-----
> From: Scott Hinkelman [mailto:]
> Sent: Thursday, August 09, 2001 2:40 PM
> To: Burdett, David
> Cc: 'Arvola Chan'; Catherine H Crawford; 
> Subject: RE: T2: Need to change Service and Action for Errors, Delivery
> Re ceip ts etc.
> 
> Ok, glad you agree on further thinking about the 2 level invocation. Back
> to the issue:
> 
> >notify. For normal  messages, Service and Action contain some useful name,
> e.g  Service=SupplierOrderManagement, Action=NewPurchase order. This can be
> 
> Is the problem that we do not decouple the invocation semantics from the
> message type ("Normal", etc)
> in the message structure?
> 
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> , Fax: 512-838-1074
> 
> "Burdett, David" <> on 08/09/2001 01:27:06 PM
> 
> To:   Scott Hinkelman/Austin/IBM@IBMUS
> cc:   "'Arvola Chan'" <>, Catherine H
>       Crawford/Poughkeepsie/IBM@IBMUS, 
> Subject:  RE: T2: Need to change Service and Action for Errors, Delivery Re
>       ceip     ts etc.
> 
> Scott
> 
> I agree that having more than two items to identify the invocation
> semantics
> is a version 2 activity, but the inability of a receiving MSH to forward an
> error message to the correct application without logging EVERY message its
> sends whether reliable messaging is being used or not is a bug and should
> be
> fixed in 1.1.
> 
> David
> 
> -----Original Message-----
> From: Scott Hinkelman [mailto:]
> Sent: Thursday, August 09, 2001 12:05 PM
> To: Burdett, David
> Cc: 'Arvola Chan'; Catherine H Crawford; 
> Subject: Re: T2: Need to change Service and Action for Errors, Delivery
> Receip ts etc.
> 
> Why have a fixed depth (2) to these invocation semantics at all? It still
> seems to me that the
> upper level environment that is mapping down to the Message Service
> (RosettaNet,OAG,etc)
> should have the flexibility to profile the invocation. Some envirnments may
> need 2, some may
> need 3. The Mail Room actually underlines this. In different places, a
> varying number
> of qualifications (country, street, apartment, ?) are need to actually
> determine the correct upper
> level handoff.
> 
> This is a version2 concept for discussion, but I believe it better
> seperates the concerns of
> the Message Service.
> 
> Scott Hinkelman, Senior Software Engineer
> XML Industry Enablement
> IBM e-business Standards Strategy
> 512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
> , Fax: 512-838-1074
> 
> "Burdett, David" <> on 08/09/2001 10:29:33 AM
> 
> To:   "'Arvola Chan'" <>, Catherine H
>       Crawford/Poughkeepsie/IBM@IBMUS, 
> cc:
> Subject:  T2: Need to change Service and Action for Errors, Delivery Receip
>       ts 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: 
> 
> ------------------------------------------------------------------
> 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: