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

I want to make two suggestions.

First to replace 'communication' with 'transport' since the term
communication is a bit too broad, afterall IP and TCP are communication
protocols.

Second, as you and Bob suggested, there's an even higher level of
abstraction which doesn't talk about the actual services, so either we call
it something else (e.g. a pattern), or we need to split 5 in two. Maybe we
could talk about a business protocol that is not defined in terms of
business partners and one that is (e.g. RN, ebXML) and call the other
'trading partner protocol'?

Or any other suggestion.

arkin


> > Would 'business protocol' be the best term to describe both 5 & 6?
>
> I would think so, yes.
>
> So the stack would then be:
>
> 1. Network Protocols
> 2. Communication Protocols
> 3. Messaging Protocols
> 4. Utility Protocols
> 5. Business 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
>
> "Assaf Arkin" <arkin@intalio.com> wrote on 02/27/2003 02:09:24 PM:
>
> > > 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:38:36 UTC