WSA Properties (was RE: WSA constraints)

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, December 18, 2002 10:21 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: WSA constraints
> 


> A next step would be to document WSA constraints, right?  The last
> time I proposed this[1], I suggested the following constraints as a
> starting point;
> 
> - layered
> - client/server
> - XML messages

We discussed the long-running issue of how to deal with the overlaps and
mismatches between the Web architecture and the Web services architecture in
the WSA editors call yesterday.  This is a bit of a rathole because of all
the strong opinions surrounding it, but it's clear that sooner or later we
need to come to a well-reasoned position that we can explain to the TAG, the
Director, etc. 

In our discussions, we've concluded that it would be useful to define a set
of properties that characterize both architectures, and analyze which are
the same and which are different across the "hypermedia web" and the
"services web" [Yes, Mark, I *know* that they don't have to be different in
principle, but they currently are in practice :-)].  Also, these are
idealized extremes, since "real" web services and web sites are usually
somewhere in the middle.  For example, a web service that uses the SOAP 1.2
GET binding to retrieve an XML document that contains the information it
needs is more "hypermedia-ish" than one that POSTs a complex RPC invocation
of some COBOL code.  Likewise, a human-oriented website triggered by a POST
of what amounts to an RPC invocation of that same code via an application
server that maintains the state during calls to multiple back-end methods
and formats the result in HTML  is somewhat more "service-like" than one
explicitly designed using the resources/respresentation architectural model.

So, accepting that this is a fuzzy rathole that we will soon wish we never
crawled into :-), what are some of these properties?  (I'm uncomfortable
with "constraints" because that seems too normative for me, and I'm hoping
we can be descriptive at this point.  At some point, we can talk about
constraints on the values of the properties, but we first have to identify
the properties, no?).

Fielding (not surprisingly) may offer a good starting point.
"The goal of architectural design is to create an architecture with a set of
architectural properties that form a superset of the system requirements."
In
http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3
he mentions as "Architectural Properties of Key Interest":

Performance
Scalability
Simplicity
Modifiability
Visibility
Portability
Reliability

I'm not so sure these are exactly what we want, since they seem (from a
quick reading) more like Good Things to achieve from a architecture than
properties of an architecture itself.  "Visibility" might be an exception; I
think we had a relatively productive discussion yesterday about how
visibility / bootstrappability is a critical feature in an environment where
parties don't have a priori knowledge of one another, but less important
when they are tightly coupled.

Some other possible properties (credit to Dave Orchard here, but blame me
for the labels) include:

Extensibility (Easily creating and using custom protocols and messages)

Customizability (Applications built for specific messages, and versioning of
the
messages/interfaces)

Abstraction of Connectivity (Multiple arbitrary intermediaries, and
targetting of information for each intermediary)

Neutrality (Arbitrary extension of message content for intermediaries and
)endpoints

Is there something like such a set of properties that we could specify,
perhaps in collaboration with TAG members, that define the architecture(s)?
It would be nice to have a rigorous argument as to which properties would
have different value in a Web of humans who know how to interpret the
semantic nuances of the content, and a Web of machines that needs to have
the semantic nuances rigorously mapped from the data to the software.  (I
for one would prefer to abstract away the different ways that one can handle
these semantic nuances, e.g. via RPC-like interface definitions, RDF
inferencing, heuristic pattern recognition, or whatever ... but I imagine
that others disagree).

Thoughts?

Received on Thursday, 19 December 2002 11:25:01 UTC