Re: Messaging Service Layer

----- Original Message -----
From: "Anne Thomas Manes" <anne@manes.net>
To: "Walden Mathews" <waldenm@optonline.net>
Cc: <www-ws-arch@w3.org>
Sent: Monday, February 17, 2003 4:24 PM
Subject: RE: Messaging Service Layer


> Please recognize that the term "transport" has different meaning in
> different circumstances. When talking about the OSI 7-layer model,
> "transport" refers to level 4, the transport layer (e.g., IP). But when
you
> pop up out of the network protocol world into the application domain,
> "transport" doesn't have such a strict meaning. Many people use the term
to
> mean "the network protocols that I use to transfer my message" -- which is
> equivalent to the entire OSI 7 layer stack. An application's access to
this
> "transport layer" is through level 7, the application layer. Hence
> applications think of level 7 as the "transport layer".

That would be bad thinking, and I'm at a loss as to why you're
propagating that on this list, instead of educating those people on how
the OSI stack works.  Everyone's loss. :-(

>
> TCP/IP isn't an application layer protocol. It's at levels 5 (TCP) and 4
> (IP). An application can't just use TCP/IP. It needs an application-layer
> protocol to access the network. Something like HTTP, SMTP, IIOP, etc.

I think Arkin's point is on target here.  Depends on what you mean by
application.  But surely any program (except maybe an applet) can open
a socket for TCP and converse with another application with no special
priveleges.  Are you saying their conversation can probably be modeled
at a higher level?  I'd think so, but how does that apply here?  We're
talking
about the place to start if you want to build a messaging layer.  GET
and POST are not optimal to that task, while send and recv are.  Is
there any argument there?

>
> From the network's perspective, SOAP (as with most middleware systems) is
an
> application. As with any other application, it accesses the network using
an
> application layer protocol. Unlike other middleware systems, SOAP has been
> designed so that it can use any application layer protocol to access the
> network. So it can use HTTP, SMTP, IIOP, etc. as its "transport".

How ironic that it *can't* use TCP or UDP!  Or can it?

>
> We could build an entirely new application layer protocol for SOAP, but
why
> would we want to? This "transport"-independence is one of its most
valuable
> features. It's not so much a matter of firewalls. It's that **you don't
have
> to install a new network protocol to use SOAP.** You can just use what
> already there -- e.g., HTTP.

The messaging service layer is already a new "application layer" protocol
(according to your terminology).  Why would we want to build that?  I don't
know: I spent some time trying to dissuade the group from that idea last
month, with poor results.

You're downplaying the firewall issue, while just about every paper and
interview I've read on the advent of SOAP casually mentions the problems
with using ports other than 80.  Hmmmm.

Anyway, one description of SOA included a requirement to use IP, so
there's one bit of protocol depence we're not going to get away from.
Since that battle is lost, why not concede and build the messaging service
upon TCP, and avoid dependencies and baggage from higher level
protocols that don't really fit the task?

And don't say "because of firewalls".  :-)

Walden

Received on Monday, 17 February 2003 22:06:30 UTC