OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Elliotte Rusty Harold on Web Services

[ Lists Home | Date Index | Thread Index ]

On Monday 10 February 2003 18:21, Mark Baker wrote:
> On Mon, Feb 10, 2003 at 04:40:01PM +0000, Alaric B. Snell wrote:
> > And on top of that sat the actual application protocols; the SEs are not
> > protocols themselves, they are more like protocol toolkits. More like the
> > convention in most IETF protocols of single line commands and three-digit
> > response codes, found within SMTP and POP3 and others. But they allow the
> > actual applications to be built on top of something higher-level than raw
> > TCP or UDP!
>
> Right, I follow.  I suggest that there's not a whole lot of value to
> that model, since two parties over the Internet need to agree on
> an application protocol in order to get anything done without a priori
> agreement; how that protocol was was designed, or what its constituent
> SEs may be, is irrelevant.

To the end user, yes, but not to the application developer.

Point of terminology: HTTP was designed as an application protocol, "what web 
browsers speak to web servers", just as SMTP is for email etc.

However, if you use HTTP to base lots of different applications on top of - 
so your mail client uses HTTP to talk to the mail server, etc - then it 
becomes a service element of those protocols, really. This is particularly 
obvious if you run it over a port other than 80!

(I *hope* I'm using the term 'service element' correctly; I wasn't around at 
the time it was coined...)

Now, the value of HTTP as a service element is that you could put two 
different applications on top of it, to support the same goal. Say we use 
HTTP to replace IMAP with a design based around visiting the URL of the 
mailbox *plus the prefix "/mail.xml"* to get an XML document of the form:

<mail-account name="alaric@alaric-snell.com" fullname="Alaric Snell">
  <folder name="Inbox" uri="http://mail.alaric-snell.com/alaric/INBOX"; />
  <folder name="Archives">
    <folder name="XML-DEV" 
       uri="http://mail.alaric-snell.com/alaric/Archives/XML-DEV"; />
    <folder name="ASN.1-DEV" 
       uri="http://mail.alaric-snell.com/alaric/Archives/ASN.1-DEV"; />
  </folder>
</mail-account>

And that the mailbox URIs, with appropriate query parameters, can be used to 
get messages by ID or to query for message IDs matching a criteria, and there 
are POSTs that can be done to move and delete messages, etc.

However, at the same time, we can say that implementations should, if queried 
on the mailbox URI itself (without the "/mail.xml" prefix) present some HTML 
forms-based interface for people without special clients.

In this usage, we're taking the mechanism of HTTP and abstracting it away 
from hypertext transfer, into a service element which we might call 'Bob' or 
something. Then HTTP proper is that service element used to transfer 
multimedia to a Web browser; that is the application. Now that we run HTTP 
over 'Bob' and email over 'Bob', we can arrange it so that things fit 
together in ways that allow more than one protocol interface to a given 
resource.

Note that 'Bob' still defines GET and POST and so on; don't worry, I'm not 
trying to disturb your RESTful sleep in this thread :-) But GET and POST 
alone do not an application protocol make.

> MB

ABS

-- 
A city is like a large, complex, rabbit
 - ARP




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS