[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]