The three Ps of SOA

Achieving a truly loosely coupled services architecture depends on separating application code into three distinct aspects. I want to reiterate this message because I'm not seeing enough recognition of the importance of each member of this triumvirate. Perhaps people are scared of decomposing the application infrastructure into too many moving parts. But the more I discover, the more convinced I am that this three-way separation is utterly fundamental.

This is something I first wrote about almost five years ago, when the concept of delivering services over HTTP was being taken seriously only by application service providers. In Breaking Software Out of the Box, an excerpt from an ASPnews.com report first published in January 2000, I argued that, "Three separate elements are intermingled in the code of present-day applications. The emerging component-based, messaging-enabled network computing architecture enables each to be separated out." In the ensuing years, I've seen those three elements given various labels and levels of attention, so here is my original defintion of each along with some additional commentary to help put them into context:

• "Process is the part of the application that performs a function. This is the only element that must always remain coded in software. The other elements are purely information." To put that another way using today's language, what I'm saying here is that process is the only part of an application that can't be saved as an XML document. It's executable functionality. (Larger composite processes can be assembled using XML documents but the individual functional components are still made of software that executes at runtime). Nowadays we can go further and add that this software functionality is probably available as open-source code, although for the time being most users are currently still paying for proprietary equivalents. One of the big problems for the software industry about the SOA model is that it reduces executable processes to commodities. Competition squeezes margins to nothing for any software that offers mainstream functionality. The only scope for profit as a pure software developer is at the market periphery, either offering niche functionality or bringing new innovations to market. In the mainstream market, the biggest profits are made not by creating software but by executing it faster or more reliably or in a more convenient mode.

• "Profile is where information about identity is stored. It defines the name, location, rights and roles of each entity that participates in an application." Today's buzzword for this element is identity, but I deliberately chose the word profile for a number of reasons (the least important of which was to have this element begin with the same letter as the other two). Too many misunderstandings arise from using the word 'identity', which implies a unique, individual persona. For one thing, most of the participants in an SOA are not people; they can be anything from a fleeting software artefact to a dumb physical appliance. These are things that people find hard to associate with the concept of identity, and so they easily forget to record and manage the profiles of such items. But most importantly, the interactions in an SOA involve aspects of each participant's identity that are selected according to what is relevant to that specific interaction. A single entity presents multiple profiles to other participants in an SOA, and it is the multiple profiles rather than the individual identities that the architecture needs to be able to handle.

• "Policy defines when and how a process should be applied. It is the most valuable element of an application, because it is where the core business logic resides ... An application matches process to profile in accordance with policy." This is the element that is most often overlooked, mainly because people assume that it's part of process rather than being a separate element in its own right (software vendors of course have a vested interest in maintaining that status quo, since it protects them from the commoditization of process that follows on from separating it out). There are several different words people are using to convey the concept of policy; rules, views, contracts, SLAs. And of course the muddled thinking this encourages means that policies aren't being defined with sufficient granularity to allow effective loose coupling. But the strength of SOA comes precisely from being able to define policy separately from both process and profile, and then being able to rapidly modify policy to adapt to changing circumstances — all without ever having to touch the code that executes the underlying processes.

My thanks to Ian Goldsmith of Digital Evolution, who set me thinking again about these matters when we chatted by phone this week. One of the strengths of the company's SOA management product is its ability to handle application identities as well as user identities. When a user accesses a web service via a portal, for example, "the portal has an application identity but the web service itself actually needs to know who is using the portal to invoke the request, so you end up with two SAML assertions," he told me. Recognizing that there may be policies associated with that user or application (or both), the product is also capable of instantiating an SLA that assigns the appropriate policies to that specific interaction. This is fully in line with the separation I've outlined above, which is why Ian's description brought it back to mind.

Naturally, there's a whole debate about the level of granularity you allow within each of these elements that I've left unanswered here (see last week's article, Adding policy to integration for a small taster of part of that debate). I am however adamant that this three-way separation into process, profile and policy has to be seen as a baseline requirement for a successful services architecture.

posted by Phil Wainewright 10:42 PM (GMT) | comments | link