- From: James M Snell <jasnell@us.ibm.com>
- Date: Thu, 27 Feb 2003 12:30:22 -0800
- To: "Assaf Arkin" <arkin@intalio.com>
- Cc: "Burdett, David" <david.burdett@commerceone.com>, "Mark Baker" <distobj@acm.org>, www-ws-arch@w3.org, www-ws-arch-request@w3.org
Comments inline... - James Snell IBM Emerging Technologies jasnell@us.ibm.com (559) 587-1233 (office) (700) 544-9035 (t/l) Programming Web Services With SOAP O'Reilly & Associates, ISBN 0596000952 Have I not commanded you? Be strong and courageous. Do not be terrified, do not be discouraged, for the Lord your God will be with you whereever you go. - Joshua 1:9 "Assaf Arkin" <arkin@intalio.com> wrote on 02/27/2003 11:47:28 AM: > James, > If I understand correctly protocols like WS-RM, ebXML TRP or RosettaNet RNIF > would fall under messaging protocols, and very specific protocols like > BTP/WS-Tx, UDDI/RSS, SAML, etc would fall under utility protocol. Correct. > I like the name 'utility protocol', thanks for suggesting it. > This still leaves us with 5 and 6, and I still have an uneasy filling about > using application protocol at level 6, since in many cases application > protocols refers to protocols like HTTP, FTP, SMTP. > What would be an example for a business protocol? RosettaNet PIPS. BPEL Flows. etc. Now that I consider it further, I'm not sure there is a real difference between 5 & 6. > Is HTTP a messaging protocol since you can use it on its own, or a > communication protocol with WS-RM, ebXML, RN being messaging protocols using > that communicatio protocol? Bepends on how it is used. In REST style applications that use HTTP, it is clearly a messaging protocol. In services that implement WS-RM/ebXML/RN/etc and use HTTP, it is clearly a communications protocol. > arkin > > -----Original Message----- > > From: James M Snell [mailto:jasnell@us.ibm.com] > > Sent: Thursday, February 27, 2003 8:00 AM > > To: Burdett, David > > Cc: 'Assaf Arkin'; Burdett, David; Mark Baker; www-ws-arch@w3.org; > > www-ws-arch-request@w3.org > > Subject: Re: Application Protocol Definition (was RE: Visibility (was > > Re: Intr oducing the Service Oriented Architec tural style ... > > > > > > Just my 2 cents thrown in from the spectator stands... > > > > I agree that "application protocol" is not the right term for the > > collection of "slightly more specialized but still general protocols". I > > often refer to those as Utility Protocols rather than Application > > Protocols which should focus on the abstract business operations and data > > needing to be exchanged. > > > > The order I would recommend is: > > > > 1. Network Protocols > > 2. Communication Protocols > > 3. Messaging Protocols > > 4. Utility Protocols > > a. Business Transaction Protocols > > b. Discovery Protocol > > c. Negotiation Protocol > > .... <etc> ... > > 5. Business Protocols > > 6. Application Protocols > > > > - James Snell > > IBM Emerging Technologies > > jasnell@us.ibm.com > > (559) 587-1233 (office) > > (700) 544-9035 (t/l) > > Programming Web Services With SOAP > > O'Reilly & Associates, ISBN 0596000952 > > > > Have I not commanded you? Be strong and courageous. > > Do not be terrified, do not be discouraged, for the Lord your > > God will be with you whereever you go. - Joshua 1:9 > > > > > > > > "Burdett, David" <david.burdett@commerceone.com> > > Sent by: www-ws-arch-request@w3.org > > 02/27/2003 03:33 AM > > > > To > > "'Assaf Arkin'" <arkin@intalio.com>, Mark Baker <distobj@acm.org>, > > "Burdett, David" <david.burdett@commerceone.com> > > cc > > www-ws-arch@w3.org > > bcc > > > > Subject > > Application Protocol Definition (was RE: Visibility (was Re: Intr oducing > > the Service Oriented Architec tural style ... > > > > > > > > > > > > Arkin > > > > You said ... > > > > >>> This of course doesn't help much, because we've just introduced three > > different protocols, one described by HTTP, one described by WSDL and one > > described by WSCI (just as an example). Again as with synch/asynch, this > > is all a matter of applying a definition in the proper context.<<< > > > > It might not help, but it is real life. You do have multiple protocols > > operating in combination at different "layers", for example (not > > sure this > > list is complete or the names are right) > > > > 1. Network infrastructure protocols, e.g. TCP/IP > > 2. Communication protocols, e.g. HTTP > > 3. Messaging protocols, e.g. ebXML Messaging or WS-RM > > 4. Business protocols, e.g. Order placement protocol that defines > > sequence > > of exchange of business documents > > > > You can also have other more slightly more specialized but still general > > "protocols", e.g. > > 5. Two phase commit, e.g. Business Transaction Protocol > > 6. Discover protocol, e.g To discover a WSDL or Schema definition (REST > > can work well here) > > 7. Negotiation protocol, e.g. To negotiate which combination of protocols > > 1 through 4 to use in a specific instance > > > > ... we could probably go on ... > > > > The point is just calling some or all of these an "Application Protocol" > > is, IMHO, insufficiently precise. > > > > Do you think we should try and define these types of protocol and what > > they mean in more detail? > > > > David > > > > -----Original Message----- > > From: Assaf Arkin [mailto:arkin@intalio.com] > > Sent: Wednesday, February 26, 2003 12:13 PM > > To: Mark Baker; Burdett, David > > Cc: www-ws-arch@w3.org > > Subject: RE: Visibility (was Re: Introducing the Service Oriented > > Architec tural style, and it's constraints and properties. > > > > > On Wed, Feb 26, 2003 at 03:18:48AM -0800, Burdett, David wrote: > > > > <DB>We need to define what we mean by an "application" if you mean it > > is > > > > anything above the transport layer, then you are correct but > > > really I think > > > > the layers are typically: Operating System, App Server, "Web Services > > > > Middleware", Application. > > > > How about: > > > > Application - A program designed to assist in the performance of a > > specific > > task, such as word processing, accounting, or inventory management > > > > Now the only question is 'what application are we talking about?' > > > > Are we talking about the HTTP or FTP server? In this case HTTP > > and FTP are > > > > the application protocols. > > > > Are we talking about accounting? In this case the accounting protocol is > > the > > application protocol. > > > > Is it possible to have an application on top of an application on top of > > an > > application? How about my accounting application running inside a WS > > container (in itself an application) implemented inside an HTTP > > server (in > > > > itself an application). Is that possible? > > > > This of course doesn't help much, because we've just introduced three > > different protocols, one described by HTTP, one described by WSDL and one > > described by WSCI (just as an example). Again as with synch/asynch, this > > is > > all a matter of applying a definition in the proper context. > > > > arkin > > > > > > > > The *critical* thing that one has to accept in order to > > understand REST, > > > > > is that application protocol methods are the same as operations in an > > > API, i.e. at the same layer of the stack as "getStockQuote" or > > > "purchaseBook". If you just take this as a given for a moment, you'll > > > see that all the arguments I've ever made on this subject become a big, > > > complex, yet entirely self-consistent description of much of Web > > > architecture, and indeed several other Internet scale architectures. If > > > you don't accept it, then I probably come off as a loon, which I > > > completely understand because I thought the same thing of some guys who > > > saying that to me back in 97/98 (Dan Connolly and Roy Fielding, FWIW). > > > > > > So, a *rhetorical* question for those of you who don't believe that > > > GET is at the same layer as getStockQuote; what would you call a > > > protocol that does have a "getStockQuote" method? Note; "application > > > protocol" is already taken. 8-) > > > > > > MB > > > -- > > > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > > > Web architecture consulting, technical reports, evaluation & analysis > >
Received on Thursday, 27 February 2003 15:31:03 UTC