David,
I understand your concern and agree with you. I don't know what is the best solution for this, and probably there is no an absolute solution at all.
Maybe we all should speak mathematics language, like 1+1=2? I am joking.
Cheers,
Jenny
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, February 27, 2003 12:41 PM
To: Xu, Jenny, ALABS; Burdett, David
Cc: Assaf Arkin; Mark Baker; www-ws-arch@w3.org
Subject: RE: Application Protocol Definition (was RE: Visibility (was Re: Introducing the Service Oriented Architectural style ...
You can't label ebXML and RosettaNet as whole since they contain many different "categories" of protocols. I think part of the confusion over what ebXML and RosettNet do, is their broad scope.
I also agree that there are object relationships between the different levels of protocols. If we try and define what an application protocol is, then tyhe bundle of protocols that aren't application protocols become "everything else". I am not suie this would help.
David
-----Original Message-----
From: Xu, Jenny, ALABS [mailto:jennyxu@att.com]
Sent: Thursday, February 27, 2003 8:32 AM
To: Burdett, David
Cc: Assaf Arkin; Mark Baker; www-ws-arch@w3.org
Subject: RE: Application Protocol Definition (was RE: Visibility (was Re: Introducing the Service Oriented Architectural style ...
David,
If we classify protocols in this way, what should we call ebXML and RosettaNet as a whole? In other words, what category name(s) should be given for ebXML and RosettaNet types of protocols? We may call ebXML messaging and RosettaNet messaging as Messaging protocols, ebXML business process and document types and RosettaNet PIPs as Business protocols, ebXML Registry as Registry protocol, and so on.
Protocols, as objects, have all the object relationship. So I don't know if we can just try to classify them neatly. I understand "Application Protocol" is vague, but IMHO it might be easier to define what scope is for an Application or what an "Application Protocol" really means here.
This is just my thought.
Jenny
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, February 27, 2003 6:34 AM
To: 'Assaf Arkin'; Mark Baker; Burdett, David
Cc: www-ws-arch@w3.org
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