RE: Questions prompted by the publication of WS-ReliableMessaging

Questions prompted by the publication of WS-ReliableMessaging
  The primary difference is political. The authors of WS-ReliableMessaging
have not signed up to participate in the WS-RM TC. I'm not sure that it's a
given that the authors will submit it to the WS-RM TC. I'd say that it bodes
badly for the standardization effort. 

  I think it bodes badly for WS in general.

  My customers have the expectations that WS lowers their costs by removing
artificial barriers that existed in the pre-WS world due to a variety of
different protocols that never interoperated. The complexity of integrating
CORBA with DCOM with CICS was taking up much of their time preventing them
from building better solutions that address their real business problem.

  If we're creating a variety of standardized or non-standardized
overlapping specification we go full circle to where we were before.
Businesses will spend most of their time trying to get some system that
talks WS-RM(1) to interface with some system that talks WS-RM(2), and I'm
not even talking about the possibility of using WS-Routing, TRP or the
garden variety of vendor-specific specs.

  So as an industry, have we (again) promised something that we have
absolutely no intent on delivering?

  arkin

  Anne
    -----Original Message-----
    From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
    Sent: Saturday, March 15, 2003 4:05 PM
    To: www-ws-arch-request@w3.org; 'Ugo Corda'; www-ws-arch@w3.org
    Subject: RE: Questions prompted by the publication of
WS-ReliableMessaging


    I agree with Ugo. Reading through the abstract it's obvious that we have
two specifications that solve the same problem. Is there a value in that?

    I actually dug deeper into the specs and I can tell that there are some
differences. But most of us don't have the time to compare green apples to
red apples. It would have been much easier if someone could present a list
of the difference. If WS-ReliableMessaging does something better than WS-RM
then clearly it could be summarized in two pages and presented to the WS
community so we can judge.

    Maybe they are so different that we need to have both. I don't see that,
but a more educated explanation would help. Maybe the changes are minor, in
which case such a comparison could help the OASIS TC in addressing the
problem of reliable messaging in a much better way.

    Am I the only one interested in seeing such a comparison?

    arkin
      -----Original Message-----
      From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
      Sent: Saturday, March 15, 2003 12:46 PM
      To: 'Ugo Corda'; www-ws-arch@w3.org
      Subject: RE: Questions prompted by the publication of
WS-ReliableMessaging


      I suggest you need to read the specs slower rather than quicker :-)
        -----Original Message-----
        From: www-ws-arch-request@w3.org
[mailto:www-ws-arch-request@w3.org]On Behalf Of Ugo Corda
        Sent: Saturday, March 15, 2003 12:44 PM
        To: www-ws-arch@w3.org
        Subject: Questions prompted by the publication of
WS-ReliableMessaging


        Probably most people in the group have had a chance by now to see
this week's announcement of the publication of WS-ReliableMessaging (see
[1]).

        After a quick reading of the spec, I have to say that I don't see
any major architectural/technical differences compared to the OASIS
WS-ReliableMessaging TC activity and its input document WS-Reliability (or
at least differences big enough to justify going a completely separate way).


        I really hope that some WSA members whose companies published the
new reliability spec can help me clarify the previous point and provide some
architectural/technical rationale for the separate publication.

        Thank you, 
        Ugo 

        P.S. No need to answer if the rationale for publication is a
political one (I can figure that out by myself ...). 

        [1] http://xml.coverpages.org/ni2003-03-13-a.html 

Received on Saturday, 15 March 2003 22:09:26 UTC