[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Elliotte Rusty Harold on Web Services

• To: Mark Baker <distobj@a...>
• Subject: Re: Elliotte Rusty Harold on Web Services
• From: "Alaric B. Snell" <alaric@a...>
• Date: Mon, 10 Feb 2003 16:40:01 +0000
• Cc: xml-dev@l...
• In-reply-to: <20030210112546.L2173@w...>
• References: <57EF69AF56D92148984EDA3174082945040F9930@R...> <E18iGOW-0001ga-00@c...> <20030210112546.L2173@w...>

On Monday 10 February 2003 16:25, Mark Baker wrote:
> On Mon, Feb 10, 2003 at 04:03:09PM +0000, Alaric B. Snell wrote:
> > No, they don't, despite both being protocols used to fetch stuff. Neither
> > do HTTP, LDAP, ODBC, IMAP, POP3, finger, ftp, tftp, fsp, etc.
> > interoperate; yet all of them are based around the concept of fetching
> > something. They were all designed to be too specific, trying to limit
> > their horizons in the hope of spending less effort on design, but that
> > cost was paid later in the effort of expanding the design...
>
> Not that I agree, but your point is what?  That we need a generic "fetch
> stuff" layer 6 protocol?
>
> The problem with that - if that is indeed what you mean - is that
> layer 6 isn't where you define "fetch stuff"; that's for layer 7.

*scratches head* layer 6 is presentation, the mapping from abstract 
information to strings of bits... XML and ASN.1 and MIME and so on are layer 
6.

> So what's needed is not a common layer 6 protocol on which new "fetch
> stuff" protocols can be constructed, but a generic layer 7 protocol that
> can provide a network interface to those protocols.

Hmmm, I sense much confusion.

I'm talking about what, in the ISO 7-layer model, is called a Service Element.

Layer 6 defined ASN.1.
Layer 7 defined applications like email and file transfer, but on top of a 
kind of toolkit (why not another layer? because the interrelationships start 
getting complex and nonlinear; it doesn't stack neatly, I gather) of Service 
Elements.

ROSE - Remote Operations Service Element - was your general 'request/response 
protocol for making applications with'.

ACSE - can't remember the acronym; Assocation Control Service Element IIRC - 
does something to do with managing long-term connections.

There's stuff to do with transactions and so on too.

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!

> MB

ABS

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

• Follow-Ups:
  • Re: Elliotte Rusty Harold on Web Services
    • From: Mark Baker <distobj@a...>

• References:
  • RE: Elliotte Rusty Harold on Web Services
    • From: "Don Box" <dbox@m...>
  • Re: Elliotte Rusty Harold on Web Services
    • From: "Alaric B. Snell" <alaric@a...>
  • Re: Elliotte Rusty Harold on Web Services
    • From: Mark Baker <distobj@a...>

• Prev by Date: Re: Microsoft XMLReader
• Next by Date: ANN: Topologi Collaborative Markup Editor 1.1.1
• Previous by thread: Re: Elliotte Rusty Harold on Web Services
• Next by thread: Re: Elliotte Rusty Harold on Web Services
• Index(es):
  • Date
  • Thread