iansrobinson.com

The slides from yesterday’s talk are here. Thank you to everyone who attended – there were some great questions both during and after.

I’ll be at the wonderful JAOO in Aarhus throughout most of next week (Monday, September 5th to Thursday, September 8th). On Tuesday I’m giving a talk, Hydras and Hypermedia, that reveals what your enterprise apps get up to when they cut loose at the weekends; if you’re curious, come along and meet Wired ERP and the DeeEmEs. The presentation is really my ticket to seeing talks from all the great speakers on Stefan Tilkov’s Is REST turning SOA’s promise into reality? track: Rachel Reinitz, Subbu Allamaraju, Mike Amundsen, Anne Thomas-Manes, and Stefan.

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

On Monday 20th July, Jim Webber and I, the golem and the frog, will be participating in the European Virtual ALT.NET (E-VAN). Colin Jack has already assembled a bunch of interesting questions, covering not only REST, but Guerrilla SOA, ESBs, consumer-driven contracts, and capability modeling.

The session will be on Live Meeting, at http://snipr.com/virtualaltnet.

Please join us on Monday, times below:

• France/Germany/Belgium: 8:00PM
• UK is: 7:00PM
• EST in the US: 2:00PM
• PST in the US: 11:00AM

Consider these links:

Example 1

<preceding>http://iansrobinson.com/0F449B535C2C</preceding>
<following>http://iansrobinson.com/796DC49C644E</following>

and

Example 2

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

Example 3

<preceding>http://iansrobinson.com/0F449B535C2C</preceding>
<following>http://iansrobinson.com/796DC49C644E</following>
<all>http://iansrobinson.com/22F4D1881C36</all>

Example 4

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

I’ve many times worked with developers and architects to help them understand the nature and implications of their distributed systems design choices. One of the ways I’ve found of framing a useful discussion is to look at coupling issues – particularly those arising as a result of temporal and behavioural coupling.

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

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

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:

Distributed 3-layer

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.

Command-oriented

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

Event-oriented

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.

Emergency services

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.

Endnote

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.