W3C home > Mailing lists > Public > www-ws-arch@w3.org > December 2002

RE: Next Steps in Reliable Messaging (was RE: Different Levels of Rel iable Messaging)

From: Assaf Arkin <arkin@intalio.com>
Date: Tue, 17 Dec 2002 13:17:21 -0800
To: "Burdett, David" <david.burdett@commerceone.com>, "Cutler, Roger \(RogerCutler\)" <RogerCutler@ChevronTexaco.com>, "Champion, Mike" <Mike.Champion@softwareag-usa.com>, <www-ws-arch@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNGEBICPAA.arkin@intalio.com>
MessageDavid,

That would work as well.

Though, I am not convienced the scope of the work is too big for XMLP to
tackle or that such a feature should be left out of XMLP.

XMLP should define from an abstract point of view how an input message is
received and an ack is sent back. SOAP would then define what the SOAP
message looks like over the wire. XMLP does not deal with the over-the-wire
message format, only the abstract definition.

While SOAP may well use modules/features to meet the XMLP requirements, the
XMLP specification does not need to use either modules or features to
describe these requirements since they are not SOAP specific.

Many SOAP implementations will not need to receive an ack back from the
receiver. But if the sender wants an ack, would the receiver ack or ignore
the sender? If enough senders out there start asking for acks, there will be
significantly more receivers that support it, since that would allow them to
support all senders rather than a limited subset. If you follow that logic
you get to the point where X% of services request ack, but 100% of services
support it. Would you not agree that is something XMLP need to address?

There is a difference between non-acked and acked message receipt. In the
first case the message is simply received - that is already covered by XMLP.
In the second case the message is received, persisted and then an ack is
sent - that pattern is not covered by XMLP. In my opinion it is possible
that introducing a standardized ack pattern would affect the patters that
XMLP handles right now.

So all things considered I think XMLP should look into the problem and see
where they fit in the solution. They might decide that they already do
everything and all that remains is for SOAP features/modules to bring these
features to light. They decide realize that the problem is best solved
outside XMLP. They decide realize that in order to standardize the solution
and not specifically for SOAP 1.1/1.2, there would be a need to introduce
some additional language in the XMLP spec

arkin

  -----Original Message-----
  From: Burdett, David [mailto:david.burdett@commerceone.com]
  Sent: Tuesday, December 17, 2002 12:51 PM
  To: 'Assaf Arkin'; Cutler, Roger (RogerCutler); Champion, Mike;
www-ws-arch@w3.org
  Subject: RE: Next Steps in Reliable Messaging (was RE: Different Levels of
Rel iable Messaging)


  Assaf

  You're advocating including the acknowledgement capability into XMLP. I
don't think this will fly and I don't think we should as:
  1. Acknowledgements would be implemented as a SOAP Module/Feature
  2. XMLP does not (I think) include ANY SOAP Modules/Features at the moment
so it would set a huge change of objectives
  3. Many SOAP implementations will not need acknowledgements. Therefore
including it in the XMLP spec is unnecessary scope creep.

  I agree though that an acknowledgement spec is needed. What I would
suggest is:
  1. Developing an Acknowledgement spec that can be layered on top of XMLP
as a SOAP Module
  2. Developing a RM spec (covering levels 1 to 4 in [1]) on top

  But this only works if there is a group that can do the architectural work
to decide:
  1. What features are required
  2. How those features are related one-to-another
  3. How they can be used in combination.

  Shoult the WS Architecture group do this or should it be done elsewhere?

  David
  [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0083.html
    -----Original Message-----
    From: Assaf Arkin [mailto:arkin@intalio.com]
    Sent: Monday, December 16, 2002 11:06 AM
    To: Cutler, Roger (RogerCutler); Champion, Mike; www-ws-arch@w3.org
    Subject: RE: Next Steps in Reliable Messaging (was RE: Different Levels
of Rel iable Messaging)


    Roger,

    I acknoweldge a mistake on my part. I was referring to David's Level 0-5
but not putting that in the proper context.

    I believe an optimal architecture for developing high-level ("business")
applications that perform reliable asynchronous messaging requires RMs that
deal with repeated retries, repeated acks, and once-only message delivery.
Such RMs are widely available and deployed today (MOMs), and throughout the
discussion I assumed developers would opt to use such RMs.

    From the perspective of XMLP, the "application" is the RM, not the
high-level application that uses the RM. XMLP needs to provide those
capabilities that an RM would require in order to interoperate with any
other RM. The minimal requirement here is to standardize the headers and the
ack message.

    So by standardizing on Level 0 at the XMLP level, and selecting to use
an RM that does additional levels, we get reliable messaging for the
high-level application.

    arkin

      -----Original Message-----
      From: Cutler, Roger (RogerCutler)
[mailto:RogerCutler@ChevronTexaco.com]
      Sent: Sunday, December 15, 2002 9:43 PM
      To: Champion, Mike; Assaf Arkin; www-ws-arch@w3.org
      Subject: RE: Next Steps in Reliable Messaging (was RE: Different
Levels of Rel iable Messaging)


      I believe that this is
http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0083.html, as
referenced in my summary.

      Although I am obviously far less expert than the people having this
technical discussion, perhaps I could comment that it worries me that they,
or someone, is talking about sending level 0 of this stack to XMLP and
defering the higher levels.  This does not seem right to me because level
zero does not seem to include the basics contained in the ebXML RM spec --
which I consider to be somewhat minimal.  Aspects that do not seem to be
contained are repeated tries at delivery by the sender and handling by the
receiver of repeated receptions of the same message.

      -----Original Message-----
      From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
      Sent: Saturday, December 14, 2002 8:18 PM
      To: Assaf Arkin; Champion, Mike; www-ws-arch@w3.org
      Subject: RE: Next Steps in Reliable Messaging (was RE: Different
Levels of Rel iable Messaging)



        -----Original Message-----
        From: Assaf Arkin [mailto:arkin@intalio.com]
        Sent: Saturday, December 14, 2002 8:39 PM
        To: Champion, Mike; www-ws-arch@w3.org
        Subject: RE: Next Steps in Reliable Messaging (was RE: Different
Levels of Rel iable Messaging)


        I apologize for any lengthy discussion on my part.

      Not at all!  I'm not trying to stifle the discussion, just make sure
that we touch on the topics that the working group will ultimately have to
deal with to push the idea forward.

      Can someone point us to David's "6 levels" ... recall that not all of
us have read the whole thread.

      Thanks again!
Received on Tuesday, 17 December 2002 16:18:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:11 GMT