[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: One issue pertaining to Arvola response to Marty to Hima onv1question4
Dale: My new comments are bracketed by <ac2> and </ac2>. -Arvola -----Original Message----- From: Dale Moberg <dmoberg@cyclonecommerce.com> To: Arvola Chan <arvola@tibco.com>; Martin W Sachs <mwsachs@us.ibm.com>; Himagiri Mukkamala <himagiri@sybase.com> Cc: ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org> Date: Friday, August 24, 2001 2:24 PM Subject: One issue pertaining to Arvola response to Marty to Hima on v1question4 >4) What are the endpoints used for Ping, Pong, StatusRequest, >StatusRepsonse, DeliveryReceipt, Acknowledgment, MessageError >Ping -> "request"? >Pong -> "response"? >StatusRequest -> "request"? >StatusResponse -> "response"? >Acknowledgement -> "response"? >DeliveryReceipt -> "response"? >MessageError (ErrorList)-> "error"? > >MWS: Any of the above which are application-defined may be associated >with whatever endpoints the business wants to use. The ones you suggest >are one possibility. Signals and MSH to MSH messages are outside the >scope of the CPA. Addressing of those messages should be defined in >the Message Service specification. > <ac> I believe Signals, as they are defined in BPSS, are considered application level messages. The CPP/A attribute syncReplyMode can take on values like signalsOnly, signalsAndResponse, etc. Therefore, I don't think they are outside of the scope of the CPA. Intermediate acknowledgements and end-to-end delivery receipts, used to implement the exactly once delivery semantics of reliable messaging are purely MSH to MSH, but they can also be piggybacked on top of application level messages. I particularly would like to see some clarifications on the circumstances under which piggybacking can be done in conjunction with synchronous and asynchronous reply modes. </ac> <dalemoberg> We intended to handle the specification of the agreement on how piggybacking was to be done via packaging. This has not yet occurred. Here are some issues needing resolution on the way to getting this done: 1. When we have signalsAndResponse true, and syncResponse true, then the packaging should describe how the signal and Response (payload) are arranged in a SOAP with attachments package. 2. When we have signalsOnly, we need to be able to indicate that there are in effect two communication channels used in responding. The signal will be returned on the requesting connection as a HTTP reply. The payload (business response) needs a URL to specify the endpoint that it is returned to. At the moment, we do not have enough apparatus available to express these facts. In addition, two different packaging formats need to be available to reflect the message containing the signal and the one containing the business response. <ac2> If the business response is to be returned over a separate connection, then shouldn't that connection be determined by the delivery channel that is selected on the basis of the responder's role, Service, and Action? I don't see why it is necessary to specify the return URL explicitly for the above (signalsOnly) scenario. </ac2> Under the current XML modeling conventions, the ServiceBinding element has two attributes associating a channel with a package. The channel in turn specifies an association of a transport with a docexchange. On the face of it, the conventions do not have a natural way to store all the related information that needs to be grouped together. <ac2> If the default delivery channel is to be used for multiple actions, is it the assumption that all of these actions will share the same packaging format? If so, the existing schema may be adequate. </ac2> If we could find a conservative way to extend the conventions to accomodate the additional grouping, it would be a 1.1 matter. Proposals welcome. If not, it may wait until 2.x. </dalemoberg> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC