- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 27 Feb 2003 14:09:24 -0800
- To: "James M Snell" <jasnell@us.ibm.com>
- Cc: "Burdett, David" <david.burdett@commerceone.com>, "Mark Baker" <distobj@acm.org>, <www-ws-arch@w3.org>, <www-ws-arch-request@w3.org>
> Now that I consider it further, I'm not sure there is a real difference > between 5 & 6. Would 'business protocol' be the best term to describe both 5 & 6? arkin > > > 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 17:11:29 UTC