October 27, 2009

Hidden Contracts and Governance

In a RESTful system the contract between client and server is expressed solely in the form of hypermedia specifications[1]. On the Web this works fine, because there is usually always a human being involved that can act as the ultimate arbiter of semantics when things need to be decided that happen not to be covered by the involved hypermedia specifications.


1. When I want to buy a book, what hypermedia is telling me that www.amazon.de is a place to go?

2. When the Amazon site is not reachable, how do I find out where else I could buy a book?

3.How do I know what 'buying a book' means and what the basic sequence of operations is that need to be executed in order to achieve the overall goal?

4. How do I figure out, what the new appropriate sequence of operations is should Amazon significantly change its understanding of the flow of a book purchase?

All of the above are ultimately solved by a human being in the case of the Web and usually don't cause any trouble.

3. is particularly interesting because the fact that no hypermedia specification even touches that question reveals that there is a very high level, common sense contract in operation between human clients and some Web applications.

4. is also interesting because economic sense will usually keep e.g. a book seller from changing the flow of operations in a way that causes the potential buyer to not being able to buy anymore.

How does all this relate to IT governance?

When one applies REST (HTTP that is in practice) in an enterprise IT context, these hidden contracts matter because they either need to be covered by hypermedia specifications (e.g. for the discovery/equivalence examples 1. and 2.) or at least need to be made explicit so they become manageable in an IT governance sense.

Example 3. relates to the general question of how types of services (e.g. 'procurement seller role' or 'repository') can be expressed to provide guidance to client developers regarding the intended sequence of operations.

Example 4 relates to the question of how change can be managed not of the pertaining hypermedia specifications (this is easy!) but of their composition (which is what effectively forms the service type).

Besides being able to frame the problem and ask the questions I do not yet have definitive answers - comments and thoughts are very welcome.

lass="Apple-style-span" style="font-size:medium;">[1] The term 'hypermedia specification' is meant as a general expression for specifications of media types, media type extensions, link relations and 'little' things like category definitions (used for example by Atom and NewsML2).

(Also posted in the XING REST Group)

October 26, 2009

Taylor, Medvidović, Dashofy. 2010. Software Architecure

The book just arrived and I think it is one of those worth an in-depth study!
I like the caution note on page 421:

"Numerous Web sites and books purport to characterize or exemplify REST principles. The reader should be very cautious, as many sources misrepresent or mischaracterize REST."

Sadly so..

October 10, 2009

Product Modeling at W3C

This seems sort of interesting and probably has some potential to be used in Web architecture-based procurement collaborations. Is there any serious industry involvement in this?

I wonder if OWL and friends will eventually obfuscate the real goal; wouldn't a decent media type be a better way to approach this?

October 1, 2009

Formal Hypermedia Contexts

Formally, a hypermedia context can be understood as a conjunction of predicates that evaluates to true or false for a given URI. The predicates can be expressed as one of the following:

  • unary link, e.g service(x)

  • binary relationship, e.g. edit-media(u1,x)

  • pattern match on representation of x, e.g. r-match( xpathExpr , x)

  • pattern match on occurrance of x in representation, e.g match( xpathExpr , x)

Logical sentences build from such predicates can be evaluated against the current state of the client to either test if a given URI matches the denoted context or to find all URIs known to the client that match the predicate conjunction.

The next step will be to express the operations that are currently stated in the form of prose in hypermedia specifications in terms of the above predicate conjunctions and HTTP operations. For example could AtomPub's 'create entry' operation be expressed as the combination of the predicate conjunction match( '/service/workspace/collection@href',x) and POST. Where the match predicate evaluates to true for any URI x that is found as the value of the XPath expression.

This needs more precision of course, but it's a start.