W3C home > Mailing lists > Public > www-ws@w3.org > April 2003

Re: Protocol independence and application protocols

From: Mark Baker <distobj@acm.org>
Date: Tue, 15 Apr 2003 11:10:01 -0400
To: www-ws@w3.org
Message-ID: <20030415111001.C31683@www.markbaker.ca>

On Tue, Apr 15, 2003 at 08:42:30AM -0400, Mike Champion wrote:
> On Tue, 15 Apr 2003 00:18:43 -0400, Mark Baker <distobjOacm.org> wrote:
> 
> 
> >
> > Ok, great.  So was there a reason why you didn't support my proposal to
> > talk about the pros and cons of protocol independence[1] in the WSA
> > doc?
> 
> Exhaustion?

Yah, tell me about it. 8-)

>  A sense that there are other topics that WSA needs to examine 
> besides this? :-)

Hey, it's an architecture, there's lots to cover.

> Your proposal was:
> 
> "Though envelopes sent over application protocols differ in meaning
> depending upon which application protocol and method is used, the WSA
> prescribes that application protocols shall be treated as if they were
> transport protocols.  This has the following advantages and
> disadvantages; [...]""
> 
> I could live with: Although from the underlying protocol's perspective Web 
> services messages might appear to have different meanings depending on 
> which operation is used to move the message body from one network node to 
> another, the WSA takes the point of view that a Web services message has 
> the same meaning irrespective of the mechanism by which it is delivered. 
> This approach, often referred to as "tunneling" one protocol over another, 
> is controversial, and should be undertaken in a specific application only 
> after considering the advantages and disadvantages:

I can live with that.

> Advantages: Messages can be more easily bridged from one underlying 
> protocol to another in a heterogenous environment .... Development tools, 
> Web services, and application components can be written to the XML Infoset 
> and SOAP processing model and abstracting away support for the underlying 
> protocol(s) ....

Ok.

> Disadvantages:  .... [you suggest some, Mark]

Disadvantages: visibility is reduced, increasing the likelihood that
messages from the application may not be permitted to pass firewalls.

I think I'll leave it at that, as it's probably the only one that
standands a chance of being accepted by the WG. 8-O

> > it simply does not possess the properties necessary to succeed on the
> > Internet.
> 
> Remind me of what those are .... statelessness, visiblity, uniform 
> interfaces?

Mostly just visibility.  There are many systems on the Internet which
are not stateless, and only the Web itself uses the uniform interface.
But all systems use some form of constrained interface which is what
provides the bulk of their visibility.

> FWIW, I personally could easily live with the conclusion that stateful, 
> limited-visibility, heterogenous interface services are most appropriate 
> for enterprise-scale rather than Internet-scale deployment.  But since 
> that's where Web services are actually being deployed today, that's not a 
> problem if the advantages outweigh the disadvantages.

I agree completely.  Behind the firewall, the current approach is
"fine".  Of course, I happen to think that the Web way remains a
better way, even there, but I can't disagree that Web services will
work there; heck, I spent 6 years building SOA based systems behind
firewalls, so I know they do.

> Also, new generations of infrastructure are continually evolving to 
> mitigate the disadvantages.  For example, application servers evolved to 
> manage the disconnect between the stateless HTTP servers and the stateful 
> applications that people wanted to access over the Web; SOAP/XML-aware 
> firewalls are coming online that exploit the visibility that XML allows 
> whereas Fielding (AFAIK) assumes that message bodies are opaque to 
> intermediaries, and WSDL (and potentially RDF-based description languages) 
> make heterogenous interfaces dynamically "understandable" [to a limited 
> extent, of course] by both client side and service-side components.

Let's not go there. 8-)

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Tuesday, 15 April 2003 12:36:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:41 GMT