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

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