[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Note that "pull" above is always "synchronous" (uses a SOAP Request-response). (Does it make sense to have an "asynchronous" pull ? ) Jacques ------_=_NextPart_001_01C49F78.B11D8410 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>more about MEPs</TITLE> </HEAD> <BODY> <P><FONT FACE=3D"Arial">An observation about ebMS MEPs, based on some = comments from Kenji Nagahashi (in ebBP) noting that = "pull"</FONT> <BR><FONT FACE=3D"Arial">may be needed for Request-responses as well = :</FONT> </P> <P><FONT FACE=3D"Arial">The idea behind is that the mode of initiating = the transfer a message (push / pull ) is orthogonal to the notion of = request / response.</FONT></P> <P><FONT FACE=3D"Arial">Meaning that combinations of these aspects will = produce potentially the following MEPs that we need to consider, = </FONT> <BR><FONT FACE=3D"Arial">and possibly select from based on usage = value:</FONT> </P> <P><FONT FACE=3D"Arial">(I use the term "Single"below = instead of One-way to denote an ebMS message that does not expect = a (business) response, </FONT></P> <P><FONT FACE=3D"Arial">due to orthogonality of this notion with = "One-way" as usually understood - see = "pull")</FONT> </P> <P><FONT FACE=3D"Arial">1- Single / push MEP. (maps to a regular = SOAP One-way)</FONT> </P> <P><FONT FACE=3D"Arial">2- Single / pull MEP (or "pull = message" MEP. maps to a SOAP Request-response MEP, request being = an ebMS signal)</FONT> </P> <P><FONT FACE=3D"Arial">3- Request-response / round-trip MEP (or = commonly synchronous Request-response, maps to a SOAP = Request-response MEP)</FONT> </P> <P><FONT FACE=3D"Arial">4- Request-response / push-push MEP (or = asynchronous Request-response where each leg is = "pushed", maps to two SOAP One-way)</FONT></P> <P><FONT FACE=3D"Arial">5- Request-response / push-pull MEP = ("asynchronous", Sender will initiate all calls and fetch its = responses, e.g. cannot accept inbound calls. Maps to SOAP One-way (push = the request) and SOAP Request-response (signal to get = response))</FONT></P> <P><FONT FACE=3D"Arial">6- Request-response / pull-push MEP = ("asynchronous", Receiver will initiate all calls and fetch = its requests, e.g. cannot accept inbound calls. Maps to SOAP = Request-response (signal to get request) plus SOAP One-way (push the = response))</FONT></P> <P><FONT FACE=3D"Arial">7- Request-response / pull-pull MEP (not sure = if that one would add much value)</FONT> </P> <P><FONT FACE=3D"Arial">Until now we have been talking of (1)(2)(3) and = (4).</FONT> <BR><FONT FACE=3D"Arial">If we dissociate the concepts of = pushing/pulling from Request-response and "Single", it may = (not sure of this) be as easy to support (5)(6).</FONT></P> <P><FONT FACE=3D"Arial">From a reliability point of view, all these = still boil down to the same two cases:</FONT> <BR><FONT FACE=3D"Arial">- reliability of SOAP One-ways</FONT> <BR><FONT FACE=3D"Arial">- reliability of SOAP Request-response</FONT> </P> <P><FONT FACE=3D"Arial">Note that "pull" above is always = "synchronous" (uses a SOAP Request-response). </FONT> <BR><FONT FACE=3D"Arial">(Does it make sense to have an = "asynchronous" pull ? )</FONT> </P> <P><FONT FACE=3D"Arial">Jacques</FONT> </P> <BR> </BODY> </HTML> ------_=_NextPart_001_01C49F78.B11D8410--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]