[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [Fwd: FW: failure notice]
-------- Original Message -------- Subject: FW: failure notice Date: Sun, 6 Apr 2003 14:30:53 -0700 From: "Matthew MacKenzie" <matt@mac-kenzie.net> To: <tom@coastin.com> Tom, I'm listed as an "Observer", but my intention has always been to be a member. I missed the telecom(s) due to travel. Please interpret this as a signal of intent to become a voting member of WSRM. At any rate, the issue is that Observer's cannot post to the list. I'd recommend that you place Observers as "non-voting members", as that is actually closer to how this used to work pre-kavi. I believe UBL is doing things this way now as well. I responded to a recent post by Paolo, which is below. Could you forward it to the list in the meantime? Thanks, Matthew MacKenzie Editor, OASIS ebXML Messaging TC -----Original Message----- From: MAILER-DAEMON@mail.oasis-open.org [mailto:MAILER-DAEMON@mail.oasis-open.org] Sent: Sunday, April 06, 2003 1:13 PM To: matt@mac-kenzie.net Subject: failure notice Hi. This is the qmail-send program at mail.oasis-open.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <wsrm@lists.oasis-open.org>: Sorry, only contributing members may post. If you are a contributing member, please forward this message to administration@lists.oasis-open.org to get your new address included (#5.7.2) --- Below this line is a copy of the message. Return-Path: <matt@mac-kenzie.net> Received: (qmail 23056 invoked by uid 60881); 6 Apr 2003 21:13:18 -0000 Received: from matt@mac-kenzie.net by hermes by uid 0 with qmail-scanner-1.15 (spamassassin: 2.43. Clear:SA:0(0.9/8.0):. Processed in 0.552334 secs); 06 Apr 2003 21:13:18 -0000 X-Spam-Status: No, hits=0.9 required=8.0 Received: from unknown (HELO priv-edtnes44.telusplanet.net) (199.185.220.224) by mail.oasis-open.org with SMTP; 6 Apr 2003 21:13:18 -0000 Received: from yvr.mac-kenzie.net ([142.179.66.22]) by priv-edtnes44.telusplanet.net (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP id <20030406212228.XYCQ3906.priv-edtnes44.telusplanet.net@yvr.mac-kenzie.ne t>; Sun, 6 Apr 2003 15:22:28 -0600 Received: from matt ([192.168.0.41]) (authenticated bits=0) by yvr.mac-kenzie.net (8.12.8/8.12.5) with ESMTP id h36LNn9f017977; Sun, 6 Apr 2003 14:23:49 -0700 From: "Matthew MacKenzie" <matt@mac-kenzie.net> To: "'Paolo Romano'" <romanop@dis.uniroma1.it>, <wsrm@lists.oasis-open.org> Subject: RE: [wsrm] comments and ideas Date: Sun, 6 Apr 2003 14:22:25 -0700 MIME-Version: 1.0 Message-ID: <000b01c2fc82$9ed01420$2900a8c0@matt> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-Type: multipart/signed; boundary="----=_NextPart_000_0003_01C2FC47.F1272FF0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <Pine.GSO.4.44.0304062208180.8802-100000@hermes.dis.uniroma1.it> This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C2FC47.F1272FF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0004_01C2FC47.F131DE50" ------=_NextPart_001_0004_01C2FC47.F131DE50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit <paolo> 1) Sending one acknowledgment for every single message exchanged results in a not minimal overhead, expecially if you keep into account XML verbosity. The natural, definitely not original solution is allowing a single acknowledgment for multiple messages. Did you see any other advantages, apart from implementation simplicity, in a one-one relation between message and ack? One issue may be that IBM&MS (et co.) WS-Reliable Messaging already proposes a similar mechanism, just like TCP does with well-known "sliding windows". I hope that neither TCP's authors, nor IBM & Microsoft will start a legal action if this TC should choose an analogous mechanism. </paolo> A SOAP message is typically not analogous to a packet, except in cases where an application built using SOAP defines a message as being a piece of a larger unit. (e.g. ebXML Messaging's Message Order module). How would you group the acks? What if batching acks slows down the execution of a business process which is waiting for an acknowledgement before proceeding to its next step? "Ack!" is right, bad pun intended. <paolo> 2) Also keeping on re-sending the same message as long as an acknowledgment is received is an expensive mechanism, whose advantage is simplicity, but which may lead to severe overheads in case of loss of acknoledgments for large messages. One solution may be defining an apposite "inquiry" message, which could be sent in case of failure suspect by any indoubt part. Note that such a message could also be useful in order to ensure end-hosts state synchronization: e.g. it could be used in a request-response mep to let the requester acknowledge the responder upon the receiption of the response message (see pag.10 Nokia_WebServicesReliability "Because Responder depends on Step 6, MEP must be extended for delivering information to Responder after step 4.") What do you think about it? </paolo> ebMS' StatusRequest service does this, more or less. <snip /> <paolo> 4 - I believe that having several specifications around for reliable messaging may only confuse ultimate users and therefore slow down the Web-Services market. My (naive) hope is that since this is the first proposal for a WS Reliable Messaging Protocol to have been submitted to a standardization organization, any other alternative idea or proposal is openly discussed, compared and possibly integrated within this protocol. On the other hand I see that Web Services and ebXML model are currently not interoperable, but I look forward for hearing any idea about the possible integration of the 2 messaging protocols. </paolo> ebMS messages are valid SOAP w/ Attachments messages (therefore, technically interoperable with 'web services'), so I assume what you mean is that: "ebXML already has a working solution for much of what these RM specifications are just starting on, but ebXML is bad PR right now, so we have to characterize the issue as being 'interoperability', and do the work over again with a 'WS-' prefix." This is a bit of a sticky subject for me, as you can probably see, because no one has given me a really good reason (beyond the WS-* label's ability to help TC participants round up funding to participate) for re-inventing this wheel. I think it would have been more appropriate for the ebMS group to release an abstract, standalone RM spec based on their RM mechanism, which works reasonably well. <paolo> I think that a common ground does exist between ebXML MS and WS-RM and I am a supporter of future collaborations with the ebXML MS TC. First of all because the ebXML MS is a mature protocol which can not simply be ignored by this TC, second because I think the overlapping between the 2 protocols should be clear to everybody. Moreover, I think it would be a strenght for this protocol to be possibly integrated into a wider context, i.e. ebXML. My personal opinion about the possible integration between ebXML MS and WS-RM is to use a modular approach: WS-RM should clearly define the interface to the supported messaging features. Such functionalities are also required (and actually already provided) by ebXML MS. This way WS-RM could be used as it is in Web Services scenarios and as a module of ebXML-MS in the ebXML context. </paolo> If you look at this TC's roster, I think you'll notice that there is a preponderance of members who are also long time members of the ebMS TC, myself included. I think that the likelihood of WSRM meeting the ebMS requirements for its Reliable Messaging protocol are extremely high, and I think its nearly a foregone conclusion that should requirements match up, WSRM will be adopted by ebMS. Best Regards, Matthew MacKenzie Editor, OASIS ebXML Messaging TC ------=_NextPart_001_0004_01C2FC47.F131DE50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DProgId content=3DWord.Document> <meta name=3DGenerator content=3D"Microsoft Word 10"> <meta name=3DOriginator content=3D"Microsoft Word 10"> <link rel=3DFile-List href=3D"cid:filelist.xml@01C2FC47.EEC6F8D0"> <!--[if gte mso 9]><xml> <o:OfficeDocumentSettings> <o:DoNotRelyOnCSS/> </o:OfficeDocumentSettings> </xml><![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:SpellingState>Clean</w:SpellingState> <w:GrammarState>Clean</w:GrammarState> <w:DocumentKind>DocumentEmail</w:DocumentKind> <w:EnvelopeVis/> <w:Compatibility> <w:BreakWrappedTables/> <w:SnapToGridInCell/> <w:WrapTextWithPunct/> <w:UseAsianBreakRules/> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--> <style> <!-- /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:"Times New Roman"; mso-fareast-font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline; text-underline:single;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline; text-underline:single;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Courier New"; mso-fareast-font-family:"Times New Roman";} span.SpellE {mso-style-name:""; mso-spl-e:yes;} span.GramE {mso-style-name:""; mso-gram-e:yes;} @page Section1 {size:8.5in 11.0in; margin:1.0in 77.95pt 1.0in 77.95pt; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 10]> <style> /* Style Definitions */=20 table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";} </style> <![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple = style=3D'tab-interval:.5in'> <div class=3DSection1> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><<span class=3DSpellE><span = class=3DGramE>paolo</span></span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><span style=3D'mso-spacerun:yes'> </span>1) Sending one acknowledgment for every single message exchanged = results<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>in a not minimal overhead, expecially if you keep into account = XML<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>verbosity. The natural, definitely not original solution is = allowing a<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>single acknowledgment for multiple messages. Did you see any = other<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>advantages, apart from implementation simplicity, in a one-one = relation<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>between message and ack? One issue may be that IBM&MS (et = co.)<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>WS-Reliable Messaging already proposes a similar mechanism, just = like TCP<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>does with well-known "sliding windows". I hope that = neither TCP's authors,<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>nor IBM & Microsoft will start a legal action if this TC = should choose an<o:p></o:p></span></font></p> <p class=3DMsoPlainText><span class=3DGramE><font size=3D2 = face=3D"Courier New"><span style=3D'font-size:10.0pt'>analogous</span></font></span> = mechanism.<o:p></o:p></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'></<span = class=3DSpellE>paolo</span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'><o:p> </o:p></span></font></ p= > <p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:red'>A SOAP message is typically not = analogous to a packet, except in cases where an application built using SOAP defines = a message as being a piece of a larger unit. (<span = class=3DGramE>e.g</span>. <span class=3DSpellE>ebXML</span> <span class=3DSpellE>Messaging's</span> = Message Order module).<span style=3D'mso-spacerun:yes'> </span>How would you = group the <span class=3DSpellE>acks</span>?<span style=3D'mso-spacerun:yes'> = </span>What if batching <span class=3DSpellE>acks</span> slows down the execution of a = business process which is waiting for an acknowledgement before proceeding to its = next step? "<span class=3DSpellE>Ack</span>!” is right, bad pun = intended.<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'><o:p> </o:p></span></font></ p= > <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'><<span class=3DSpellE><span = class=3DGramE>paolo</span></span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>2) Also keeping on re-sending the same message as long as = an<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>acknowledgment is received is an expensive mechanism, whose = advantage is<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>simplicity, but which may lead to severe overheads in case of = loss of<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>acknoledgments for large messages.<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><span style=3D'mso-spacerun:yes'> </span>One solution may = be defining an apposite "inquiry" message, which = could<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>be sent in case of failure suspect by any indoubt part. Note = that such a<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>message could also be useful in order to ensure end-hosts = state<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>synchronization: e.g. it could be used in a request-response mep = to let<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>the requester acknowledge the responder upon the receiption of = the<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>response message (see pag.10 Nokia_WebServicesReliability = "Because<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>Responder depends on Step 6, MEP must be extended for = delivering<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>information to Responder after step 4.") What do you think = about it?<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'></<span = class=3DSpellE>paolo</span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'><o:p> </o:p></span></font></ p= > <p class=3DMsoPlainText><span class=3DSpellE><span class=3DGramE><font = size=3D2 color=3Dred face=3D"Courier New"><span = style=3D'font-size:10.0pt;color:red'>ebMS</span></font></span></span><fo n= t color=3Dred><span style=3D'color:red'>' <span = class=3DSpellE>StatusRequest</span> service does this, more or less.<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><snip /><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'><<span class=3DSpellE><span = class=3DGramE>paolo</span></span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>4 - I believe that having several specifications around for = reliable<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>messaging may only confuse ultimate users and therefore slow = down the<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>Web-Services market. My (naive) hope is that since this is the = first<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>proposal for a WS Reliable Messaging Protocol to have been = submitted to a<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>standardization organization, any other alternative idea or = proposal is<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>openly discussed, compared and possibly integrated within this protocol.<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>On the other hand I see that Web Services and ebXML model are = currently<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>not interoperable, but I look forward for hearing any idea about = the<o:p></o:p></span></font></p> <p class=3DMsoPlainText><span class=3DGramE><font size=3D2 = face=3D"Courier New"><span style=3D'font-size:10.0pt'>possible</span></font></span> integration of = the 2 messaging protocols. <o:p></o:p></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'></<span = class=3DSpellE>paolo</span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><span class=3DSpellE><font size=3D2 color=3Dred face=3D"Courier New"><span = style=3D'font-size:10.0pt;color:red'>ebMS</span></font></span><font color=3Dred><span style=3D'color:red'> messages are valid SOAP w/ = Attachments messages (therefore, technically interoperable with ‘web = services’), so I assume what you mean is that: "<span = class=3DSpellE>ebXML</span> already has a working solution for much of what these RM specifications = are just starting on, but <span class=3DSpellE>ebXML</span> is bad PR right = now, so we have to characterize the issue as being 'interoperability', and do = the work over again with a 'WS-' prefix."<span = style=3D'mso-spacerun:yes'> </span>This is a bit of a sticky subject for me, as you can probably = see, because no one has given me a really good reason (beyond the WS-* = label's ability to help TC participants round up funding to participate) for = re-inventing this wheel. <span style=3D'mso-spacerun:yes'> </span>I think it = would have been more appropriate for the <span class=3DSpellE>ebMS</span> group to = release an abstract, standalone RM spec based on their RM mechanism, which works reasonably well.<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><<span class=3DSpellE><span = class=3DGramE>paolo</span></span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>I think that a common<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>ground does exist between ebXML MS and WS-RM and I am a = supporter of<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>future collaborations with the ebXML MS TC. First of all because = the ebXML<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>MS is a mature protocol which can not simply be ignored by this = TC, second<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>because I think the overlapping between the 2 protocols should = be clear to<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>everybody. Moreover, I think it would be a strenght for this = protocol to<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>be possibly integrated into a wider context, i.e. ebXML. My = personal<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>opinion about the possible integration between ebXML MS and = WS-RM is to<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>use a modular approach: WS-RM should clearly define the = interface to the<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>supported messaging features. Such functionalities are also = required<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>(and actually already provided) by ebXML MS. This way WS-RM = could be used<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'>as it is in Web Services scenarios and as a module of ebXML-MS = in the<o:p></o:p></span></font></p> <p class=3DMsoPlainText><span class=3DGramE><font size=3D2 = face=3D"Courier New"><span style=3D'font-size:10.0pt'>ebXML</span></font></span> = context.<o:p></o:p></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'></<span = class=3DSpellE>paolo</span>><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'><o:p> </o:p></span></font></ p= > <p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:red'>If you look at this <span = class=3DSpellE>TC's</span> roster, I think you'll notice that there is a preponderance of members = who are also long time members of the <span class=3DSpellE>ebMS</span> TC, = myself included.<span style=3D'mso-spacerun:yes'> </span>I think that the likelihood of WSRM meeting the <span class=3DSpellE>ebMS</span> = requirements for its Reliable Messaging protocol are extremely high, and I think <span class=3DGramE>its</span> nearly a foregone conclusion that should = requirements match up, WSRM will be adopted by <span = class=3DSpellE>ebMS</span>.<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dred face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:red'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'>Best = Regards,<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'><o:p> </o:p></span></font></ p= > <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'>Matthew <span = class=3DSpellE>MacKenzie</span><o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 color=3Dblack face=3D"Courier = New"><span style=3D'font-size:10.0pt;color:black'>Editor, OASIS <span = class=3DSpellE>ebXML</span> Messaging TC<o:p></o:p></span></font></p> <p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span = style=3D'font-size: 10.0pt'><o:p> </o:p></span></font></p> </div> </body> </html> ------=_NextPart_001_0004_01C2FC47.F131DE50-- ------=_NextPart_000_0003_01C2FC47.F1272FF0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIEDCC A2Iw ggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMC VVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmlt YXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1 OVow gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g Qnkg UmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2 aWR1 YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQAD gY0A MIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNW LccI 4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqO f2ok kuP84GW6p7F+78nbN2rISsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNV HSAE QDA+MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVw b3Np dG9yeS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNh MS5j cmwwCwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQAC fZ5v RUs4oLje6VNkIbzkTCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH 56jY UulbLarh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudA MZrT ssSr51a+i+P7FTCCBKYwggQPoAMCAQICEDBEBi9mnHIzywmVSVSn8tEwDQYJKoZIhvcNAQEE BQAw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g Qnkg UmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2 aWR1 YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMwNDA1MDAwMDAwWhcN MDQw MjA1MjM1OTU5WjCCARgxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2ln biBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkv UlBB IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxp ZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNl cnZp Y2UxGjAYBgNVBAMUEUNoYWQgTS4gTWFjS2VuemllMSIwIAYJKoZIhvcNAQkBFhNtYXR0QG1h Yy1r ZW56aWUubmV0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCffKb7loYrv4/NtK121qN6 mqr2 Gf7zw3LnF5EeeFPecYrfJTSkxWeYQvX8IPDKS6iaXYWe3nGvKeBQGAyU/6Zgj9ElT8Om4Q+3 /jKa 7CY6ucmhWwBOhHh5IZ0dBYT3EUkiE2RTr3eZ2ZSPql/0L3WItQhXTGyDuiG9VdPieSotqQID AQAB o4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAo Bggr BgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUW DlZl cmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNl IGxp YWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDAGCmCGSAGG+EUB BgcE IhYgNjliOTAyZmRmOTM1MDU2OTdiNzg4YTljNDUyZjg0YjEwMwYDVR0fBCwwKjAooCagJIYi aHR0 cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG9w0BAQQFAAOBgQCiP4t/ Ub42 kyVNL+3pbzf9WktXmzOlwqFMTUqTx7tWhQ26iIGuIv/imS5ZpCFu8EzotgMy7G1D3LQXmP/R 3M17 KO0FWT5wbiTutN0bXbfgeo/x0OoiRYT/+KsJJI3cXzfj+HAO6LPgTvBEA0MaeECX5dV+Hl6M 3OD1 ODe0EVIKhTGCBD4wggQ6AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVk AhAwRAYvZpxyM8sJlUlUp/LRMAkGBSsOAwIaBQCgggKyMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDQwNjIxMjIyM1owIwYJKoZIhvcNAQkEMRYEFE84U85j rrFW UxFS0Q5jUlNz+li2MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYFKw4DAhowDgYI KoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqG SIb3 DQIFMIHyBgkrBgEEAYI3EAQxgeQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3Jl cG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9W ZXJp U2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxp ZGF0 ZWQCEDBEBi9mnHIzywmVSVSn8tEwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQK Ew5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQo Yyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIt UGVyc29uYSBOb3QgVmFsaWRhdGVkAhAwRAYvZpxyM8sJlUlUp/LRMA0GCSqGSIb3DQEBAQUA BIGA MVKp0xIz2/r1Ih1M4hjfxxQIempZZMwkd4Tb/Ngt93jG+Lsjrnq/orWBPF+lXkXHj+oIcMTn jSPc qNybm49QbxDD0DiNYUUMQmlvaoIeakeTCOXmHryXkRDJ/DqBu/r7uydiJ0XDioRVpvlvLQ8k PlTN Qp9KH3JcNnQSCeyrPZEAAAAAAAA= ------=_NextPart_000_0003_01C2FC47.F1272FF0-- -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]