RE: [obix-xml] Groups - Notes_20041020.pdf uploaded

["Considine, Toby (Facilities Technology Office)" <Toby.Considine@fac.unc.edu>]

Bravo! I concur, as have most that I know who have read 0.5

Can we make the schema support life-cycle operations across the entire
facilty function? I'm thinking harmonization of schema across design intentn
/ design / construction / commissioning / operation (with continuous
commissioning coming for free). While this may be to ambitious for v1,
aiming in this direction would drive oBIX adoption across all owner/Operator
groups.


Some recent readings that come to mind when reading the Spec, meeting notes,
preparatory to Schema:

Eventing and Generic Reads:

Dave Orchard:

http://www.pacificspirit.com/blog/2004/09/28/web_services_needs_transfer_pro
tocols_and_specific_protocols

Web services needs Transfer protocols AND specific protocols
Having been involved in the "REST vs Web services" debate for quite a while,
I've steadfastly believed that a "Generic"-only or a "No Generic" operation
architecture isn't the "right" and "only" way. WS-Transfer and
WS-ResourceFramework are great ways to bridge the gap between two very
different architecture styles. As Don says, "Why would I ever author another
WSDL PortType". 

Reads and Writes
To answer, any distributed architecture has to deal with 2 primary types of
operations: Reading things and Writing things. When doing either of these
two types of operations, an architecture typically uses either generic
operations (ala REST/WS-Transfer) or specific operations (much of Web
services). 

My belief is that most customers need an architecture that combines both
generic and specific operations. Read operations using a generic protocol
(ie GET) hits the 90/10 point. In the Write operation case, it's a little
more difficult. In many cases, the thing being accessed is what WebDAV calls
a "dead" property, where there are no side-effects of it being written. In
these cases, a generic "Create/Delete/Update" works well. Where the thing
being accessed is a "live" property, that is it has side-effects, then a
thing specific "Create/Delete/Update" operations are needed.

Specific Writes
Let's take an example, a time-out property of a resource.
WS-ResourceFramework correctly allows reads using the generic "getProperty"
operations. It also correctly does not provide a "setProperty" operation on
the time-out value, rather it provides a "setTimeout" operation. 

If the timeout was done as a "setProperty", then it could be set as part of
a multi-property set operation. The problem is that the time-out value could
be an invalid value, or unacceptable. In which case, the multi-property set
will fail, and the other properties will be in an undetermined state. Did
they get set or not? The client will have to troll through property specific
result codes to figure out each properties result. In which case, it's an
operation specific return and it's roughly "lied" about it's ability to
compose with other properties!

This is an example of a fine grained control flow that is not appropriate
for generic operations. But let's take a look at the flip side, that generic
read.

Generic Reads
I believe a main reason for "generic" operations is for loose coupling,
particularly extensibility and versioning. In previous lives, I've regularly
deployed enterprise systems that had "specific" operation middle-tiers. A
good example is integrating a large entrprise system with another system.
The problem with "specific" operation middle-tiers is that they are
incredibly brittle. If there's a property that isn't available from the
middle-tier, a new set of "get/set" operations have to be written. For
performance reasons, you invariably need to do complex reads across business
objects, so you need to provide for "pushing" the complex reads into the
business objects. SQL Join statements are a classic way of dealing with
performance, and the same is needed for middle-tiers. 

Imagine that I've got my business object layer that knows about .... oh
let's imagine something... Names that have First and Last names. If I add a
Middle name and I want to allow a query for it, in a "specific" interface I
need to add findName operations for each of the combinations of Names that I
allow - or I make a generic findName operation, ie findName(first,last);
findName(first, middle,last); findName(prefix,first,middle,last); etc.

Generic Reads AND Specific Writes
What would be *really* great is if we could provide a Web service middle
tier that allowed generic read operations that were easy to evolve in
addition to the current specific operation architecture style. I could add a
Middle into my schema, and then the query operations don't change! This is
what I mean about evolvability of the interface and why a generic interface
is required. I wrote about this in WebXQuery

I followed through on the first action item as I tried to get some of this
into the WSDL 2.0 HTTP binding, but I wasn't very successful. My
experiements in using WSDL 2.0 to describe a generic interface (a Music
service) showed that the current structure of WSDL 2.0 optimizes for custom
operations across a few URIs, and doesn't optimize for generic operations
across a complex URI space that is defined by a schema. I boldly predict
that these limitations will hinder the adoption of WSDL 2.0 to describe
generic HTTP interactions.

The current transfer mechanisms - WS-Transfer and WS-ResourceFramework - are
better as they define the property space based upon a schema, but they are
very limited or don't specify how the queries on the properties can evolve.
For example, WS-RF allows me to add a property (foo) into a resource and
then I can do a "getProperty(foo)". But modelling the world as a set of flat
properties effectively destroys XML and the Web's hierarchical structures.
We still need full featured query operations, ala SQL/XQuery.

What's missing from the debate is the discussion is the properties of the
distributed systems we are deploying and have deployed. One propertyis
evolvability, that is what has to be changed and what components will break
when an interface is extended or versioned. I wish the REST folks would
admit that generic updates have limitations, and the "specific operation"
folks would admit that evolvability of interfaces could be *a lot* easier. 

Another couple properties are performance and re-use of existing
infrastructure. It that would be good from a Web services perspective is if
generic Web service interactions (like WS-Transfer) had a binding that made
full utilization of HTTP. It certainly easier to get performance
improvements by caching HTTP representations now rather than waiting for the
deployment of EndpointReference caches (which will have specify how to
canonicalize an XML structure for cache comparison). WS-MetadataExchange has
bare-bones support for this with the scheme specific dereferencing operation
when a MetadataSection contains a Location. But there's much more work to be
done.

We've work to do, but I'm hopeful that we are moving towards a future round
of Web services specs will combine generic and specific operations in a more
evolvable and performant architecture. The publication of WS-Transfer shows
that the Web service architecture understands the problems of evolvability
in deploying large numbers of operations. The downside is that it takes time
as people often redo the mistakes of earlier systems and customers pay the
price. 



 

-----Original Message-----
From: ahansen@tridium.com [mailto:ahansen@tridium.com] 
Sent: Tuesday, November 09, 2004 10:19 AM
To: obix-xml@lists.oasis-open.org
Subject: [obix-xml] Groups - Notes_20041020.pdf uploaded

The document Notes_20041020.pdf has been submitted by Aaron Hansen
(ahansen@tridium.com) to the oBIX XML Standards SC document repository.

Document Description:
oBIX XML Standards Teleconference
October 20, 2004, 1:30pm - 2:00pm (EDT)

We decided that the specification was complete enough to begin work on the
schema.

Download Document:  
http://www.oasis-open.org/apps/org/workgroup/obix-xml/download.php/9971/Note
s_20041020.pdf

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/obix-xml/document.php?document_
id=9971


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.