RE: Application Protocol Definition (was RE: Visibility (was Re: Intr oducing the Service Oriented Architec tural style ...

> 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