[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
The bottom line is a rather optimistic summary: - the definitions of reliability used for a Request message cannot be applied to a Response message (in "synchronous" Request-response MEPs): they need be adjusted. - once adjusted, Response reliability appears to involve and leverage the reliability of the Request leg. This makes it easy to implement Response reliability at MSH level, without duplicating RMP functions. ------_=_NextPart_001_01C49709.D4974600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2654.45"> <TITLE>general reliability of ebMS MEPs</TITLE> </HEAD> <BODY> <P><FONT SIZE=3D2 FACE=3D"Courier New">This is an outline on how = different ebMS 3.0 MEPs would be handled by a reliability component. = </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">This goes beyond the MEPs from = Jeff that were related only to asynchronous Request-response = MEP.</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">I do not detail here how = the RM-Reply is sent back, (Jeff did it for the async = Request-response), but instead focus on the </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">way the ebMS MEPs map to RMP = operations, the reliability features supported, and in particular, on = the meaning of reliability for the response leg of Request-response = MEPs. Note in particular MEP #3.</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">Assuming three ebMS MEPs below, = the following exchanges and reliability support apply:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">1- ebMS One-way MEP (a SOAP = One-way MEP with ebMS headers)</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">SOAP One-way MEP: Payload (PO = BOD, etc.) ------> S-RMP.Submit -------> R-RMP.Deliver -----> = Payload(PO BOD, etc.)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">Reply patterns allowed: = [callback, poll] </FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">2- ebMS Request-response = MEP:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">(a) asynchronous (maps to = two SOAP One-way MEPs)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">SOAP One-way MEP: Payload (PO = BOD, etc.) ------> S-RMP.Submit ----> R-RMP.Deliver ---> = Payload(PO BOD, etc.)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">SOAP One-way MEP: Payload (PO = Ack BOD, etc.) <--- S-RMP.Deliver <---- (Payload + RM-Reply) = R-RMP.Submit <--- Payload(PO Ack )</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">Reply patterns allowed in = request: [callback, poll](also in response, if it is a reliable message = too)</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">(b) synchronous (maps to SOAP = Request-response MEP, assuming binding to a request-response = transport)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">SOAP Request-response MEP = [request]: Payload (PO BOD, etc.) ---> S-RMP.Submit ----> = R-RMP.Deliver --> Payload(PO BOD, etc.)</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">SOAP Request-response MEP = [response]: Payload (POAck BOD, etc.) <--- S-RMP.Notify <--- = R-RMP.Respond <--- Payload(POAck BOD, etc.)</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">Reply patterns allowed in the = request: [response, callback, poll]</FONT> </P> <BR> <P><FONT SIZE=3D2 FACE=3D"Courier New">3- ebMS Pull-Message MEP: (we = assume here a signal is sent requesting the message to be = "pulled")</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">(a) asynchronous. (same pattern = as for 2.a)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">(b) synchronous (actually maps = to a SOAP Request-response MEP, not a SOAP Response MEP as defined in = SOAP 1.2 Part 2,</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">because of an ebMS header in = the request which is a "signal" - only intended to MSH - to = pull a message.)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">SOAP Request-response MEP = [request]: ("pull" header element, no payload.) ---> = S-RMP.Submit ---> R-RMP.Deliver ---> pull signal to = MSH</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">SOAP Request-response MEP = [response]: Payload (PO BOD, etc.) <--- S-RMP.Notify <--- = R-RMP.Respond <--- Payload(PO BOD, etc.)</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">Reply patterns allowed in the = *request*: [response, callback, poll] (see explanation below)</FONT> </P> <BR> <P><FONT SIZE=3D2 FACE=3D"Courier New">Comments on the above:</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">----------------------</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">- there is no consensus on the = exact meaning of the term "synchronous", which in the above = case means</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">a binding of SOAP = Request-response to a "synchronous" underlying protocol. For = the lack of better term, I am using</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">"synchronous" in this = sense for now. (in some other definition - e.g. in some RosettaNet = literature, synchrony is not a transport property</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">but rather is a serialization of = several request-response instances)</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">- All exchanges that map to SOAP = One-way, can be subject to full Reliability features as defined in = WS-R.</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">(except for for those features = that don't apply to One-way, like "response" reply pattern) = </FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">- If poll is used (synchronous = ), that would require an additional SOAP Request-response MEPs not = mentioned here.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">- finally, there has to be a way = to indicate in an ebMS header which type of MEP a message belongs to. = </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">The usage of RefToMessageId = will help</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">correlate a = "response" to a "request", but there has to be a = way to tell if a request belongs to an ebMS One-way or = Request-response.</FONT></P> <BR> <BR> <P><FONT SIZE=3D2 FACE=3D"Courier New">Proposal for "Response = reliability":</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier = New">------------------------------------</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">There are two cases where = reliability features as described in WS-R would not apply</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">to an ebMS business message : = these are the cases above where the message is submitted via = "Respond" to the RMP (2.b and 3.b) </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">However, I propose that, *in = ebMS* we refine the notion of reliability of "ebMS Response = messages" (at least for the synchronous</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">case). </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">Indeed it does not make sense = to apply the same reliability definition to Request messages and = Response messages, </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">as the mechanisms used for = Requests don't apply (e.g. you can't just "resend" a response = if no Ack is obtained, due to</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">tranport binding constraints, = and duplicates simply won't occur unless the Request was duplicated = too, for the same reasons)</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">The Reliability of a Response = (response leg of SOAP Request-response) is defined as follows:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">.(r1) the guaranteed delivery = contract for an ebMS synchronous Response, is that when a Request has = been sent, </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">a Response should be obtained = by the Sender, or else an error is notified to the request Producer = (sender side). </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">(so no Ack is used for the = Response leg, and no independent automatic resending of the response = will be done.</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">But guaranteed delivery of the = Request would greatly ensure success for the Response, so should be = part of this contract.)</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">.(r2) the duplicate elimination = contract for an ebMS synchronous Response, simply includes the = duplicate elimination of </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">the Request, combined with a = Sender behavior that "once a response received for a request has = been delivered to the </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">Request producer (sender side), = then no other response correlating to the same request will ever be = delivered </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">to the Request = producer".</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">.(r3) the ordering contract for = an ebMS synchronous Response, would be based on the order of Request = submission, NOT of</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">Response submission: Response = payloads would be delivered to Producer (sender side) in the same order = as the Requests </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">have been submitted by this = same Producer (to the MSH). A simple way to enforce this, is to not = send an ebMS Request message </FONT></P> <P><FONT SIZE=3D2 FACE=3D"Courier New">before the previous Response was = received. </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">A second option, more = efficient, would have the MSH enforce pipe-lining on Sender side: = Response messages would be </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">delivered by MSH in same order = as the requests have been submitted to this MSH.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">These definitions of Reliability = for Responses can be enforced by the Sender MSH with very little = effort: </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">they mostly leverage the = reliability of the Request which is supported by the RMP </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">(even when the request is just = a signal like in 3.b)</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">From an implementation = viewpoint, (r1)(r2) and (r3simple option) all can be implemented in MSH = without duplicating </FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">RMP functionality. Even (r2) = does not require persistence of IDs beyond the ones of current on-going = Request-responses</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">which have by definition a = short lifespan if synchronous.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Courier New">The bottom line is a rather = optimistic summary:</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">- the definitions of = reliability used for a Request message cannot be applied to a Response = message (in "synchronous"</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">Request-response MEPs): they = need be adjusted.</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">- once adjusted, Response = reliability appears to involve and leverage the reliability of the = Request leg. This makes</FONT> <BR><FONT SIZE=3D2 FACE=3D"Courier New">it easy to implement Response = reliability at MSH level, without duplicating RMP functions.</FONT> </P> <BR> <BR> </BODY> </HTML> ------_=_NextPart_001_01C49709.D4974600--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]