RE: Web services messaging

+1

And another +1 for deciding that "defining the behavior of Web services
messaging relative to software agents" is what the WSA should discuss before
delving into the particular way in which various protocols would enable
that.

arkin
  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Newcomer, Eric
  Sent: Sunday, March 16, 2003 11:04 AM
  To: www-ws-arch@w3.org
  Subject: Web services messaging


  If we can agree to discuss Web services messaging from the application or
"actor" viewpoint rather than the viewpoint of the transport, I think we
have a better chance of gaining agreement and adding useful text to the
document.

  Defining such terms as "synchronous" and "asynchronous" are not likely to
be viewed as much of a contribution to industry, whereas defining the
behavior of Web services messaging relative to software "agents"  probably
would be.

  In the context of application to application communication paradigms, Web
services are basically a peer-to-peer system since the agents perform
operations to send and receive messages in various patterns.  Web services
do not perform RPCs since there is no equivalent of a local procedure call.
Web services also do not define queueing, although persisting messages can
be viewed as the same thing.

  Eric
    -----Original Message-----
    From: Newcomer, Eric
    Sent: Sunday, March 16, 2003 11:58 AM
    To: Champion, Mike; www-ws-arch@w3.org
    Subject: RE: Friendly amendment to friendly amendment (was RE: Friendly
amendm ent #2c [Re: Straw poll on "synchronous" definitions]


    I'd like to say that I'm not sure that defining synchronous and
asynchronous are going to help us very much.  I'd like to offer a quote from
a book Phil Bernstein and I wrote in 1997 on transaction processing
("Principles of Transaction Processing," page 74):

    "TP application programs communicate with each other when they run in a
distributed setting on different computers.  Even on a single computer, for
modularity reasons, it's often convenient to break up the application
programs into separate processes.  Application programs therefore have to
communicate between processes, which means the programs have to exchange
messages.  There are three ways to do this:

    1.  Use remote procedure calls, which mimic the behavior of local
procedure calls within a single process.  When a program in one process
calls a program in another process (in another address space), it does so by
calling a procedure and getting a value returned just as if the two
procedures were running within a single address space.

    2.  Explicitly send and receive messages, called peer-to-peer messaging.
Rather than use a procedure call with a return, application programs issue
operations that send and receive messages.

    3.  Move messages among queues.  An application sends a message from one
program to another by putting the message in a queue.  The queue is a third
object, with which both programs communicate.  One program enqueues the
message to the queue, and sometime later the receiver program dequeues the
message from the queue.

    These communication paradigms apply to all distributed applications, not
just in TP. ..."

    I think this approach is much clearer and more helpful than trying to
define how the technology works under the covers, or describing the
messaging systems on which these paradigms are based.  It's clearly possible
to use a synchronous protocol to implement a message queuing paradigm, and
possible to implement a remote procedure call paradigm using peer-to-peer.
If we look at the capability of Web services based communication technology
from this perspective, we can fairly easily decide which of these paradigms
it really supports, and how, rather than argue over synchronous vs.
asynchronous, which is really a detail rather than an indication of
application level behavior.

    Eric
      -----Original Message-----
      From: Champion, Mike
      Sent: Sunday, March 16, 2003 11:18 AM
      To: www-ws-arch@w3.org
      Subject: Friendly amendment to friendly amendment (was RE: Friendly
amendm ent #2c [Re: Straw poll on "synchronous" definitions]



        -----Original Message-----
        From: Anne Thomas Manes [mailto:anne@manes.net]
        Sent: Saturday, March 15, 2003 6:12 PM
        To: Walden Mathews; Christopher B Ferris; www-ws-arch@w3.org
        Subject: RE: Friendly amendment #2c [Re: Straw poll on "synchronous"
definitions]


        The biggest issue I have with Ugo's definition (and all the others)
is that they tie synchrony with blocking versus non-blocking. Synchronous
means "at the same time". Asynchronous means "not at the same time". Whether
or not the sender has to wait idly for a response is a separate issue.

        An interaction (one-way, two-way, or multi-way) is synchronous if
the sender and receiver must communicate at the same time (the reciever must
be available to receive the message when the sender sends it). A one-way
message is asynchronous if the sender and receiver do not need to
communicate at the same time (the message may be stored and delivered at a
later time).
      I must say that I like Anne's wording that synchronous means that "the
receiver must be available to receive the message"  better than notions of
blocking or simultaneity.  What about changing Ugo's suggestion to:

      Asynchronous: A request/response interaction is said to be
asynchronous
      when the request and response are chronologically and procedurally
decoupled. In other
      words, the client agent can process the response at some indeterminate
point in the future when its existence is discovered, for example, by
polling, notification by receipt of another message, etc.

      Synchronous:  A request/response interaction is said to be synchronous
when the client agent must be available to receive and process the response
message from the time it issues
      it issues the initial request until it is actually received or some
failure condition is determined. The exact meaning of "available to receive
the message" depends on the characteristics of the client agent (including
the transfer protocol it uses); it may, but does not necessarily, imply
tight time synchronization, blocking a thread, etc.