On February 11th I’ll be presenting Hydras and Hypermedia at London Geek Night.
Do you know what your enterprise apps get up to in their time off? Fighting fantasy, pick-your-path, hypermedia-driven, RESTful Web application adventures – of course.
In this speculative dungeon delve I’ll show how we can use hypermedia-driven Web applications to model rich workflows. We’ll tackle the many-headed Hydra of HATEOAS, the “Hypermedia as the Engine of Application State” monster; level up through the Web services maturity heuristic; and meet the dwarves with grudges. On the way, we’ll learn how to model business processes as domain application protocols, implement them in terms of resource lifecycles, and advertise them using HTTP idioms, media types and link relation values.
atom:content element (enveloping).
A little while ago, Bill de hÓra expressed his preference for direct extension over enveloping. At its worst, enveloping results in near anaemic Atom entries, with very few of the Atom metadata elements put to good use, rightly prompting Bill’s question: “why bother using Atom at all?”
Like Bill, I’ve gone back and forth between these two options. At present, I’m inclined to use enveloping more than direct extension, but only if I can still put the Atom metadata to good use. If I find I’m having to fill out Atom metadata elements with lots of dummy information, just so that I can use Atom to transfer some opaque data between applications, I quickly turn to another format.
To my mind, Atom’s “meta-purpose” is to establish a domain processing context for some content. In AtomPub, Atom artefacts establish a publishing context for Web content. When used to establish this publishing context, the Atom artefacts are called collections and members, rather than feeds and entries.
I prefer not to extend Atom beyond the domain processing context I’m trying to model: instead, I push the thing to be processed down into the content. This allows for media type composition, whereby one media type processor hands off to another as it works its way through a representation. A reasonably “generic” Atom client can resurrect the domain processing context, which then remains in force whilst a specialized media type handler deals with the content (according to its media type).
In the past I’ve illustrated this point by showing how Atom feeds can be used to represent streams of events. The event metadata maps nicely to Atom metadata. The content itself contains a snapshot of some other resource’s state at the point the event occurred. In other words, the Atom metadata establishes an event-ish processing context for the content. When the client invokes a specialised handler for the content, it does so in the knowledge that its dealing with a representation of state at a particular point of time.
If I can’t separate a given problem into 1) an activity and accompanying processing context (e.g. “eventing”, “publishing”), and 2) the thing to be acted on, I’ll consider using something other than Atom.
]]>I used to introduce this topic with a quote from Beckett’s Unnameable – “You must go on, I can’t go on, I’ll go on” – which nicely sums up the situation I see many organisations facing today: burdened with a legacy systems estate, unable to stop the world, sorely in need of a change in strategy to face the future.
Based on case study material from the last few years, talk suggests some future proofing strategies that can arise out of an assessment of today’s business operations.
The First International Workshop on RESTful Design (WS-REST 2010) aims to provide a forum for discussion and dissemination of research on the emerging resource-oriented style of Web service design.
Over the past few years, several discussions between advocates of the two major architectural styles for designing and implementing Web services (the RPC/ESB-oriented approach and the resource-oriented approach) have been mainly held outside of the research and academic community, within dedicated mailing lists, forums and practitioner communities. The RESTful approach to Web services has also received a significant amount of attention from industry as indicated by the numerous technical books being published on the topic.
This first edition of WS-REST, co-located with the WWW2010 conference, aims at providing an academic forum for discussing current emerging research topics centered around the application of REST, as well as advanced application scenarios for building large scale distributed systems.
In addition to presentations on novel applications of RESTful Web services technologies, the workshop program will also include discussions on the limits of the applicability of the REST architectural style, as well as recent advances in research that aim at tackling new problems that may require to extend the basic REST architectural style. The organizers are seeking novel and original, high quality paper submissions on research contributions focusing on the following topics:
All workshop papers are peer-reviewed and accepted papers will be published as part of the ACM Digital Library. Two kinds of contributions are sought: short position papers (not to exceed 4 pages in ACM style format) describing particular challenges or experiences relevant to the scope of the workshop, and full research papers (not to exceed 8 pages in the ACM style format) describing novel solutions to relevant problems. Technology demonstrations are particularly welcome, and we encourage authors to focus on “lessons learned” rather than describing an implementation.
Papers must be submitted electronically in PDF format. Submit at the WS-REST 2010 EasyChair installation.
Also as part of QCon, I gave a talk, Beginning an SOA Initiative, the slides of which can be downloaded here.
Jim and I will be giving the REST tutorial at QCon London next year. We’re already planning plenty of changes so as to make it a little more hands-on and practical.
]]>At other times in the week you’ll find me hanging around the ThoughtWorks booth, where besides an informal chat, you can schedule a 30-minute one-on-one meeting with one of the many ThoughtWorks consultants attending the conference.
Photo taken from ElDave’s Flickr stream under the Creative Commons licence
]]>The session will be on Live Meeting, at http://snipr.com/virtualaltnet.
Please join us on Monday, times below:
<preceding>http://iansrobinson.com/0F449B535C2C</preceding>
<following>http://iansrobinson.com/796DC49C644E</following>and
<link rel="http://iansrobinson.com/resources/link-relations/preceding" href="http://iansrobinson.com/0F449B535C2C"/>
<link rel="http://iansrobinson.com/resources/link-relations/following" href="http://iansrobinson.com/796DC49C644E"/>Functionally equivalent?
There are two separate concerns at play here: finding links, and understanding links. An application’s semantic space – the set of link relations it uses to annotate links – is extensible. Understanding targets an open set. The capability to find links, on the other hand, ought ideally target a closed set.
In Example 1, each element bears the weight of addressing both concerns. The ability to find links is pinned to an open set. In Example 2, by contrast, the link element belongs to a closed set, with the semantic variance broken out and herded into the rel attribute value. Much easier to find links belonging to Example 2 using an application-agnostic function, a LINQ for Links, as it were.
What happens when we extend an application’s semantic space?
<preceding>http://iansrobinson.com/0F449B535C2C</preceding>
<following>http://iansrobinson.com/796DC49C644E</following>
<all>http://iansrobinson.com/22F4D1881C36</all><link rel="http://iansrobinson.com/resources/link-relations/preceding" href="http://iansrobinson.com/0F449B535C2C"/>
<link rel="http://iansrobinson.com/resources/link-relations/following" href="http://iansrobinson.com/796DC49C644E"/>
<link rel="http://iansrobinson.com/resources/link-relations/all" href="http://iansrobinson.com/22F4D1881C36"/>A client of Example 3 will likely only be able to report: “foreign markup found.” A client of Example 4 will be able to recognize the new link, though not necessarily understand the new rel value.
Every apostate technician on his or her descent to whiteboard irrelevancy ought produce at least one “magic quadrant” diagram. This is mine: the coupling matrix. Whilst sadly not a career-making architectural silver bullet, this diagram may help you characterize the several parts of your extant solutions, envision direction for future initiatives, and understand the constraints – both legitimate and inadvertent – that in part determine the design options available to you.
First, a brief overview of these two types of coupling:
Temporal coupling refers to the degree to which the sending and handling of a message are connected in time. If a sender is dependent on a receiver being available when a message is sent, we have high temporal coupling: if the provider is not available, the interaction fails. Processes whose activities are strictly ordered or whose results carry forward, leaving subsequent activities unable to start until a response to a prior request has been received, are similarly temporally coupled. In situations of high temporal coupling, the time taken to handle the message and return a response increases the processing time on the sender side.
Behavioral coupling refers to the degree to which parties share assumptions regarding behaviors, more specifically, to the implications of assigning the twin responsibilities for determining what action to execute and how to execute that action to the parties in a distributed interaction. In systems that exhibit an extremely high degree of behavioral coupling, the sender of a message determines what to do, and also knows something of how the receiver ought satisfy its request. Such coupling is typically evinced by, for example, database foreign keys and/or platform-dependent artifacts such as collection types leaking into messages and operations. If a sender determines what to do, and a receiver determines how to satisfy the sender’s request, the participants similarly exhibit a high degree of behavioral coupling. If a receiver alone determines both what to do and how to do it in reaction to a received message, the sender and receiver have low behavioral coupling. High behavioral coupling requires a provider to evolve its service offerings in response to changed consumer requirements.
And then some sketchy characterizations of each of the quadrants:
Traditional 3-layer application architecture blown up to distributed proportions. Characterized by call stack-like, imperative behaviour (high temporal and behavioural coupling) and synchronous request-response interactions. Includes systems that layer synchronous interactions on top of asynchronous message exchanges. Senders tell receivers what to do; receivers execute the sender’s orders. Sender and all intermediaries block until the call stack unwinds, effectively locking and/or consuming system resources further up the call chain. This blocking behaviour undermines the autonomy of upstream components and at the same time increases the availability requirements of downstream components. As Michael Nygard’s Release It! reminds us, in these circumstances the availability of the overall system can be no more than that of the least available participant, and the probability of failure is the joint probability of failure in any component or service.
“Good”, “orthodox” SOA. Low degree of temporal coupling characterised by asynchronous interactions, deferred state and a resumable programming model (process or activity instances are dehydrated between remote invocations in order to conserve resources, and then rehydrated based on correlated responses). Senders typically determine what needs to be done, but rely on receivers to determine how to execute their instructions. This behavioural coupling can require providers to evolve (message formats, supported operations) in lockstep with changing consumer demands.
Low temporal and behavioural coupling. Receivers determine both what needs to be done and how to do it based on the content of received messages. Resumable programming model: processes are suspended or dehydrated, waiting for events. Can be difficult to trace the execution path of an end-to-end transaction or activity. Exposing an ExtinguishFire operation is a command-oriented way of executing a business process; acting on FireStarted notifications an event-oriented approach.
So called because you tell them what happened, and they decide what to do, but if there’s no one to take your call, you’re hosed. Low behavioural coupling, which allows for the independent evolution of system components, but a degree of temporal coupling, impacting availability requirements of participants. Many RESTful solutions occupy this quadrant. URI-templated solutions have a higher degree of behavioural coupling than hypermedia-driven solutions (where servers constrain and guide what a client can do next, and determine how best to satisfy requests); client polling and caching can mitigate some of these temporal coupling issues.
These coupling issues are well understood by many developers and architects – to the extent they comprise a general base of knowledge without specific authority or provenance. I would, however, like to draw your attention to one of very many excellent posts by Bill Poole, Avoid Command Messages, that some time ago helped bring behavioural coupling into focus for me.
]]>