RE: Web services messaging
"Cutler, Roger (RogerCutler)" <[email protected]> Mon, 17 Mar 2003 15:16:41 -0600
| Newsgroups | gmane.comp.web.services.ws-arch |
|---|---|
| Message-ID | <7FCB5A9F010AAE419A79A54B44F3718E01624BB4@bocnte2k3.boc.chevrontexaco.net> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C2ECCA.80F28FC1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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. =20 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. =20 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.=20 =20 -----Original Message----- From: Newcomer, Eric [mailto:[email protected]]=20 Sent: Sunday, March 16, 2003 1:04 PM To: [email protected] 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. =20 =20 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. =20 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. =20 Eric -----Original Message----- From: Newcomer, Eric=20 Sent: Sunday, March 16, 2003 11:58 AM To: Champion, Mike; [email protected] Subject: RE: Friendly amendment to friendly amendment (was RE: Friendly amendm ent #2c [Re: Straw poll on "synchronous" definitions] =09 =09 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): =20 "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: =20 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. =20 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. =20 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. =20 These communication paradigms apply to all distributed applications, not just in TP. ..." =20 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. =20 Eric -----Original Message----- From: Champion, Mike=20 Sent: Sunday, March 16, 2003 11:18 AM To: [email protected] Subject: Friendly amendment to friendly amendment (was RE: Friendly amendm ent #2c [Re: Straw poll on "synchronous" definitions] =09 =09 =20 -----Original Message----- From: Anne Thomas Manes [mailto:[email protected]] Sent: Saturday, March 15, 2003 6:12 PM To: Walden Mathews; Christopher B Ferris; [email protected] Subject: RE: Friendly amendment #2c [Re: Straw poll on "synchronous" definitions] =09 =09 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.=20 =20 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). =20 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: =20 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.=20 =20 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. =20 =20 ------_=_NextPart_001_01C2ECCA.80F28FC1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Message</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><SPAN class=3D287081321-17032003><FONT face=3DArial color=3D#0000ff = size=3D2>The=20 current refactored document uses the terms synchronous and/or=20 asynchronous a number of times. All previous versions have = used the=20 terms. Neither the requirements document nor the charter use the = terms,=20 but the Usage Scenarios have tons of references to the = term.</FONT></SPAN></DIV> <DIV><SPAN class=3D287081321-17032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D287081321-17032003><FONT face=3DArial color=3D#0000ff = size=3D2>IMHO,=20 if we are going to use the term ANYWHERE, given the number of = alternative=20 and probably incompatible interpretations of what the words = mean, then we=20 need to agree on what sense we are using the words in and put it in the=20 Glossary.</FONT></SPAN></DIV> <DIV><SPAN class=3D287081321-17032003></SPAN> </DIV> <DIV><SPAN class=3D287081321-17032003><FONT face=3DArial color=3D#0000ff = size=3D2>I can=20 see de-emphasizing the use of these words, but I thinkn it would be = pretty tough=20 to edit out all references in all documents.</FONT> </SPAN></DIV> <DIV><SPAN class=3D287081321-17032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV></DIV> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft><FONT face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> Newcomer, Eric=20 [mailto:[email protected]] <BR><B>Sent:</B> Sunday, March 16, 2003 = 1:04=20 PM<BR><B>To:</B> [email protected]<BR><B>Subject:</B> Web services=20 messaging<BR><BR></FONT></DIV> <DIV><SPAN class=3D216524718-16032003><FONT face=3DArial color=3D#0000ff = size=3D2>If we=20 can agree to discuss Web services messaging from the application or = "actor"=20 viewpoint rather than the viewpoint of the transport, I think we have a = better=20 chance of gaining agreement and adding useful text to the = document. =20 </FONT></SPAN></DIV> <DIV><SPAN class=3D216524718-16032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D216524718-16032003><FONT face=3DArial color=3D#0000ff = size=3D2>Defining such terms as "synchronous" and "asynchronous" are not = likely to=20 be viewed as much of a contribution to industry, whereas defining the = behavior=20 of Web services messaging relative to software "agents" probably would=20 be.</FONT></SPAN></DIV> <DIV><SPAN class=3D216524718-16032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D216524718-16032003><FONT face=3DArial color=3D#0000ff = size=3D2>In the=20 context of application to application communication paradigms, Web = services=20 are basically a peer-to-peer system since the agents perform = operations to=20 send and receive messages in various patterns. Web services do not = perform=20 RPCs since there is no equivalent of a local procedure call. Web = services=20 also do not define queueing, although persisting messages can be viewed = as the=20 same thing.</FONT></SPAN></DIV> <DIV><SPAN class=3D216524718-16032003><FONT face=3DArial color=3D#0000ff = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D216524718-16032003><FONT face=3DArial color=3D#0000ff = size=3D2>Eric</FONT></SPAN></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> Newcomer, Eric=20 <BR><B>Sent:</B> Sunday, March 16, 2003 11:58 AM<BR><B>To:</B> = Champion, Mike;=20 [email protected]<BR><B>Subject:</B> RE: Friendly amendment to = friendly=20 amendment (was RE: Friendly amendm ent #2c [Re: Straw poll on = "synchronous"=20 definitions]<BR><BR></FONT></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff size=3D2>I'd=20 like to say that I'm not sure that defining synchronous and = asynchronous are=20 going to help us very much. I'd like to offer a quote from a = book Phil=20 Bernstein and I wrote in 1997 on transaction processing ("Principles = of=20 Transaction Processing," page 74):</FONT></SPAN></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff size=3D2>"TP=20 application programs communicate with each other when they run in a=20 distributed setting on different computers. Even on a single = computer,=20 for modularity reasons, it's often convenient to break up the = application=20 programs into separate processes. Application programs therefore = have to=20 communicate between processes, which means the programs have to = exchange=20 messages. There are three ways to do this:</FONT></SPAN></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>1. Use remote procedure calls, which mimic the behavior = of local=20 procedure calls within a single process. When a program in one = process=20 calls a program in another process (in another address space), it does = so by=20 calling a procedure and getting a value returned just as if the two = procedures=20 were running within a single address space.</FONT></SPAN></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>2. Explicitly send and receive messages, called = peer-to-peer=20 messaging. Rather than use a procedure call with a return, = application=20 programs issue operations that send and receive = messages.</FONT></SPAN></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>3. Move messages among queues. An application = sends a=20 message from one program to another by putting the message in a = queue. =20 The queue is a third object, with which both programs = communicate. One=20 program enqueues the message to the queue, and sometime later the = receiver=20 program dequeues the message from the queue.</FONT></SPAN></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>These communication paradigms apply to all distributed = applications,=20 not just in TP. ..."</FONT></SPAN></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff size=3D2>I=20 think this approach is much clearer and more helpful than trying to = define how=20 the technology works under the covers, or describing the messaging = systems on=20 which these paradigms are based. It's clearly possible to use a=20 synchronous protocol to implement a message queuing paradigm, and = possible to=20 implement a remote procedure call paradigm using peer-to-peer. = If we=20 look at the capability of Web services based communication technology = from=20 this perspective, we can fairly easily decide which of these paradigms = it=20 really supports, and how, rather than argue over synchronous vs. = asynchronous,=20 which is really a detail rather than an indication of application = level=20 behavior.</FONT></SPAN></DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D515394816-16032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Eric</FONT></SPAN></DIV> <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> Champion, Mike=20 <BR><B>Sent:</B> Sunday, March 16, 2003 11:18 AM<BR><B>To:</B>=20 [email protected]<BR><B>Subject:</B> Friendly amendment to friendly = amendment (was RE: Friendly amendm ent #2c [Re: Straw poll on = "synchronous"=20 definitions]<BR><BR></FONT></DIV> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff = 2px solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> Anne Thomas = Manes=20 [mailto:[email protected]]<BR><B>Sent:</B> Saturday, March 15, 2003 = 6:12=20 PM<BR><B>To:</B> Walden Mathews; Christopher B Ferris;=20 [email protected]<BR><B>Subject:</B> RE: Friendly amendment #2c = [Re:=20 Straw poll on "synchronous" definitions]<BR><BR></FONT></DIV> <DIV><SPAN class=3D460020123-15032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2>The biggest issue I have with Ugo's definition (and all = the others)=20 is that they tie synchrony with blocking versus non-blocking. = Synchronous=20 means "at the same time". Asynchronous means "not at the same = time".=20 Whether or not the sender has to wait idly for a response is a = separate=20 issue. </FONT></SPAN></DIV> <DIV><SPAN class=3D460020123-15032003><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D460020123-15032003><FONT face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2>An interaction (one-way, = two-way, or=20 multi-way) is synchronous if the sender and receiver must = communicate at=20 the same time (the reciever must be available to receive the = message when=20 the sender sends it). A one-way message is asynchronous if the = sender and=20 receiver do not need to communicate at the same time (the message = may be=20 stored and delivered at a later time). <SPAN=20 = class=3D299350016-16032003> </SPAN></FONT></FONT></FONT></SPAN></DIV= ></BLOCKQUOTE> <DIV dir=3Dltr><SPAN class=3D460020123-15032003><FONT = face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN class=3D299350016-16032003>I = must say that I=20 like Anne's wording that synchronous means that "the receiver must = be=20 available to receive the message" better than notions of = blocking or=20 simultaneity. What about changing Ugo's suggestion=20 to:</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D460020123-15032003><FONT = face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 = class=3D299350016-16032003></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr><SPAN class=3D460020123-15032003><FONT = face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN = class=3D299350016-16032003>Asynchronous: A=20 request/response interaction is said to be asynchronous<BR>when the = request=20 and response are chronologically and procedurally decoupled. In=20 other<BR>words, the client agent can process the response at = some=20 indeterminate point in the future when its existence is=20 discovered, for example, by polling, notification by=20 receipt of another message,=20 etc. </SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D460020123-15032003><FONT = face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 = class=3D299350016-16032003></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr><SPAN class=3D460020123-15032003><FONT = face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 class=3D299350016-16032003>Synchronous: A = request/response=20 interaction is said to be synchronous when the client agent must be=20 available to receive and process the response message from the time = it=20 issues<BR>it issues the initial request until it is actually = received or=20 some failure condition is determined. The exact meaning of = "available to=20 receive the message" depends on the characteristics of the client = agent=20 (including the transfer protocol it uses); it may, but does not = necessarily,=20 imply tight time synchronization, blocking a thread,=20 etc.</SPAN></FONT></FONT></FONT></SPAN></DIV> <DIV dir=3Dltr><SPAN class=3D460020123-15032003><FONT = face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 = class=3D299350016-16032003></SPAN></FONT></FONT></FONT></SPAN> </DIV= > <DIV dir=3Dltr><SPAN class=3D460020123-15032003><FONT = face=3DArial><FONT=20 color=3D#0000ff><FONT size=3D2><SPAN=20 = class=3D299350016-16032003></SPAN></FONT></FONT></FONT></SPAN> </DIV= ></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML> =00 ------_=_NextPart_001_01C2ECCA.80F28FC1--