[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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:srh@us.ibm.com] > Sent: Thursday, August 09, 2001 2:40 PM > To: Burdett, David > Cc: 'Arvola Chan'; Catherine H Crawford; ebxml-msg@lists.oasis-open.org > 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) > srh@us.ibm.com, Fax: 512-838-1074 > > "Burdett, David" <david.burdett@commerceone.com> on 08/09/2001 01:27:06 PM > > To: Scott Hinkelman/Austin/IBM@IBMUS > cc: "'Arvola Chan'" <arvola@tibco.com>, Catherine H > Crawford/Poughkeepsie/IBM@IBMUS, ebxml-msg@lists.oasis-open.org > 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:srh@us.ibm.com] > Sent: Thursday, August 09, 2001 12:05 PM > To: Burdett, David > Cc: 'Arvola Chan'; Catherine H Crawford; ebxml-msg@lists.oasis-open.org > 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) > srh@us.ibm.com, Fax: 512-838-1074 > > "Burdett, David" <david.burdett@commerceone.com> on 08/09/2001 10:29:33 AM > > To: "'Arvola Chan'" <arvola@tibco.com>, Catherine H > Crawford/Poughkeepsie/IBM@IBMUS, ebxml-msg@lists.oasis-open.org > 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:arvola@tibco.com] > Sent: Wednesday, August 08, 2001 6:59 PM > To: Burdett, David; 'Dr Crawford'; ebxml-msg@lists.oasis-open.org > 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 <david.burdett@commerceone.com> > To: 'Dr Crawford' <catcraw@us.ibm.com>; ebxml-msg@lists.oasis-open.org < > ebxml-msg@lists.oasis-open.org> > 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:catcraw@us.ibm.com] > >Sent: Monday, August 06, 2001 8:11 AM > >To: ebxml-msg@lists.oasis-open.org > >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 > >catcraw@us.ibm.COM > > > > > >------------------------------------------------------------------ > >To unsubscribe from this elist send a message with the single word > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org > > > >------------------------------------------------------------------ > >To unsubscribe from this elist send a message with the single word > >"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
begin:vcard n:Ferris;Christopher tel;cell:508-667-0402 tel;work:781-442-3063 x-mozilla-html:FALSE org:Sun Microsystems, Inc;XTC Advanced Development adr:;;;;;; version:2.1 email;internet:chris.ferris@east.sun.com title:Sr. Staff Engineer fn:Christopher Ferris end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC