W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2005

Lack of layering in WS (Was: RFC 2616 (rfc2616) - Hypertext Transfer Protocol ...)

From: Tim Berners-Lee <timbl@w3.org>
Date: Thu, 10 Mar 2005 10:48:35 -0500
Message-Id: <DCB3B73E-917B-11D9-A27C-000A9580D8C0@w3.org>
Cc: "www-tag@w3.org" <www-tag@w3.org>, "Rice, Ed (HP.com)" <ed.rice@hp.com>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
To: Rich Salz <rsalz@datapower.com>

I agree.

This for me is part of a more general concern I have about a lack
of layering in WS architecture.  There is very little encapsualation and
data hiding. Messages are sent around with many levels exposed, and
without a clear architectural indication of what should be processed 

This breaks the cleanness of a remote procedure call model,
where many calls may be nested across the net, but the architecture
is defined in terms of just one.

It seems to me also to break much of the ways of doing business.
When I have a relationship with the bank, it is with the bank pure and 
and though for some purposes I know the teller's names
all my dealings are cleanly between two or sometimes three parties.
What happens inside the bank or the organization I write the check to 
is hidden.

Layering typically involves a each protocol being defined
in terms the services provided by lower protocols.
It involved messages carrying the messages of higher levels as
payload. Even when there is in fact visibility between the layers,
which is often useful, it allows no ambiguity as to the order in which 
should be processed -- or more strictly the grammar by which
the meaning of a message is interpreted.
XML is good at this, with its nested structure.
Header-oriented systems, like HTTP, SMTP and SOAP have the problem
that interaction between headers is not clear.

For example, security should be end-end between the parties who trust 
each other.
So it is reasonable for me to do SSL with the bank, and
for the bank server to do whatever it needs to do inside the bank.
I could encrypt something with a key of a teller, but that would be
inappropriate.  I'm not doing business with the teller.
If I wanted specifically to address the bank's CEO I would
have to encrypt the message with the CEO's key
and ask the bank to pass it on.

The visibility within a SOAP message and the idea that lots of
different processes will be looking at different bits in a random
way is reminiscent of the RDF graph of information: the information
is the sum of many small atomic parts. However, in RDF any subgraph
is true if the graph is true, but in SOAP that is not so. The flat 
belies the reality.  You can't just remove of ignore some parts,
and the "must understand" flag which addresses the problem is only
a single bit.  It flags that there is more structure, but doesn't say 
it is. Maybe more nesting of messages would make the system
more modular, more flexible and evolvable.

A layered structure would also point to an addressing syntax in
which an address was formed of an identifier at the top layer appended
to an (opaque to that layer) address used at lower layers.


> I want end-to-end security, not hop-by-hop.  I'm not alone. :)
>         /r$
> -- 
> Rich Salz                  Chief Security Architect
> DataPower Technology       http://www.datapower.com
> XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
Received on Thursday, 10 March 2005 15:48:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:24 UTC