Re: Visibility (was Re: Introducing the Service Oriented Architectural style, and it's constraints and properties.

>  ... On the other hand, if message bodies
> are in one or more standardized XML-based formats, this allows
> intermediaries to perform cacheing, routing, and filtering based on the
> content of the message, and as of this writing actual firewall products
are
> available that implement this approach.  For example, routing can be done
on
> the basis of WS-Routing SOAP headers, or XPath or XQuery examination of
the
> actual message payload; firewalls can use WS-Security headers and/or XACML
> assertions to make quite fine-grained decisions as to whether to allow a
> specific message from a specific user requesting a specific service to
pass
> through.

The first sentence above mentions cacheing, routing and filtering.  The
examples are for routing and filtering only.  What about cacheing
examples?

> This flexibility comes a a cost in performance (since the entire
> message must be parsed by the firewall), robustness in the face of change
> (since knowledge of actual message formats must be propagated to the
> intermediaries as well as the endpoints), and could require security
> tradeoffs (since message content would have to be decrypted before being
> examined).

I think "security tradeoffs" is too mild.  I want to see the word
"compromise" in there.  But at the same time it would be fair to point
out that this is only an issue for applications that require confidentiality
and/or integrity constraints.

>
> Actual specwriters and systems designers must consider the costs and
> benefits of exploiting the visibility that XML messages offer and design
> accordingly.

Here, a level of abstraction (or something) has slipped.  Above you're
careful to stress that it's XML-based *standards* which figure into
the retention of visibility.  Here, it's sounding like any XML vocabulary
offers visibility.  Unfortunately, lots of people think that.


 > For example, visibility considerations might mandate a
> separation of information that is clearly confidential from information
that
> intermediaries may use to operate on.

A really important point in distributed application design, and one
that transcends this discussion of visibility via XML-based standards,
I think.  Also, a nit: The separation is mandated by the combination of
visibility and confidentiality requirements, not just visibility.


 > This can work both ways: A pure REST
> approach might compromise security if confidential information is encoded
in
> URIs (e.g., the identity of the user requesting a specific resource), or a
> pure REST approach might enhance security by allowing the entire contents
of
> a resource representation to be encrypted in a manner that only the
ultimate
> consumer of a representation can decrypt while allowing intermediaries to
> make decisions based on URI, HTTP method, etc.

I'm not sure about this part.  First off, how RESTful would it be to encode
the identity of the user in the URI (unless the resource IS the user, but I
don't
think that's what you mean).  I'll appeal to Mark on this one.

Basically, Mike, while I appreciate that you are trying to be even-handed
in your analysis, I think REST, by providing "uniform interface", pretty
much
guides the decision of how to separate the visible from the confidential in
messages, which is much-needed design guidance.  So, I think you're
straining a little to say it "cuts both ways".

> In any event, a better
> appreciation of the Web Services Architecture and the possibilities it
> enables should allow better engineering decisions by designers.

I'd rather you replaced the phrase "possibilities it enables" with the
phrase
"constraints it imposes", for reasons Mark has explained rather much.
If you want more positive language, you could say "properties it enables"
in addition to the constraints part.  But I think the community needs to
start thinking (and accepting) the notion of design constraints, as contrary
to freedom and western culture as it may sound.

>
> OK, Mark, Walden, or whoever ... what don't you like about that?

I like most of it.  And thanks for leaving Matthew out of this (!:-)

Walden

Received on Tuesday, 25 February 2003 11:48:09 UTC