RE: Web services messaging

The current refactored document uses the terms synchronous and/or
asynchronous a number of times.  All previous versions have used the
terms.  Neither the requirements document nor the charter use the terms,
but the Usage Scenarios have tons of references to the term.
 
IMHO, if we are going to use the term ANYWHERE, given the number of
alternative and probably incompatible interpretations of what the words
mean, then we need to agree on what sense we are using the words in and
put it in the Glossary.
 
I can see de-emphasizing the use of these words, but I thinkn it would
be pretty tough to edit out all references in all documents. 
 
-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
Sent: Sunday, March 16, 2003 1:04 PM
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.