[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.
I want to follow up on this idea with another suggestion. Consider the use case illustrated by the attached PDF File titled "MSH Ping on multiple MSHs for a Party". In this use case Party A wants to "Ping" Party B's MSH. The problem is that Party B operates at two different locations: location 1 and 2 and each location has its own separate MSH which then routes to messages to a couple of services that run at each location. There are two potential problems here: 1. How will the sending MSH that is requesting the service know where to send the PING to, and 2. Even if you get a positive PING back, it does not mean that messages sent to that MSH can be processed. Each of these is discussed in turn: WHERE DO YOU SEND THE PING TO ----------------------------- The sending MSH needs to determine the URL that the PING must be sent to. However, the messageHeader would look something like ... PartyId=urn:PartyB Service=uri:www.ebxml.org/messageService Action=Ping The issue is that these fields will look identical no matter which location is being pinged. If the message is being sent indirectly this is a real problem as the intermediary MSH will not know which URL to use and has no information that can be used to decide. The suggested solution is that we make the header look like ... PartyId=urn:PartyB Service=OrderManagement Action=uri:www.ebxml.org/messageService/Ping The intervening MSH can than work out where to send the message to. A POSITIVE PING DOESN'T MEAN THA MESSAGES CAN BE PROCESSED ---------------------------------------------------------- The current spec says that the PING checks to see if the MSH is awake. However it is possible that the services behind the MSH (e.g. at Location 2 for Party B) are both down. This means that even though you get a positive PING any messages sent won't be processed. The suggested change is if we make the PING mean "Is the Service working" rather than "Is the MSH working" then we will get back much more meaningful results. The changes suggested for "Where do you send the ping to" change would easily allow this to happen. Thoughts? David -----Original Message----- From: Burdett, David Sent: Thursday, August 09, 2001 3:15 PM To: 'Scott Hinkelman' 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. 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. 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
MSH Ping on multiple MSHs for a Party.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC