Re: WSA Properties (was RE: WSA constraints)

On Thu, Dec 19, 2002 at 09:24:27AM -0700, Champion, Mike wrote:
> 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. 

Good to hear.  I agree.

> 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"

That's great.  I was assuming that the desirable properties of WSA are
already in the requirements document.  But sure, let's talk about those
first.

> [Yes, Mark, I *know* that they don't have to be different in
> principle, but they currently are in practice :-)].

Amen!

>  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.

Ok.

> 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.

I think all those you list are useful properties, but I'd be happy just
to focus on visibility, because I feel it's a required property, and
that Web services don't have it.

> 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)

I wouldn't call the ability to create custom protocols a desirable
property, because it sacrifices interoperability.  But custom messages,
sure.  I guess this one would need some further clarification.

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

I don't understand that one.  "versioning" scares me though. 8-)

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

I don't understand that one either.

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

I'd call that part of "visibility", where messages are self-describing,
including any extensions (mandatory extensions, for example) ... if I
understand it correctly.

Sorry for being dense.  I'm sure it was clearer on the call. 8-)

> 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?  

Would it be ok just to start with one property (say, visibility 8-), and
go to town on it; what does it mean, why is it valuable, and what
kinds of constraints can effect it?

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis