Sunday, July 03, 2011

Service Boundaries in SOA

A service has explicit boundaries

This is one of the four tenets of SOA, promulgated by Microsoft and others around 2004. In its (now discontinued) Connected Services Framework (3.0 SP1), it is identified as one of the four principles of service-oriented design.

  • Boundaries are explicit
  • Services are autonomous
  • Services share schema and contract, not class
  • Service compatibility is determined based on policy

I found a presentation on the MSDN website by Udi Dahan called SOA in the Real World (ppt), in which this tenet is expanded as follows.
Services run in a separate process from their clients
A boundary must be crossed to get from the client to the service – network, security, …

Also on the MSDN website, I found some design guidance from ramkoth called Service Boundaries, Business Services and Data, in which the same tenet is expanded as follows.

Services explicitly choose to expose certain (business) functions outside the boundary. Another tenet of SOA is that a service - within its boundary - owns, encapsulates and protect its private data.

In SOA, dollar signs and trust boundaries, Rocky Lhotka describes SOA as a mechanism for bridging trust boundaries. He argues that SOA is expensive (in terms of complexity and performance), and can only decrease the overall cost and complexity when used for inter-application communication across trust boundaries. Trust is not just a security issue, but also a future-proofing issue, because we can't always be sure what future applications will do. A trust boundary therefore helps protect us from an uncertain future, and builds some degree of flexibility into the system of systems.

Where did all the boundaries go?

Now here's the funny thing. All of the pieces I've quoted above were published in 2004, as are the vast majority of hits in the first several pages of Internet search. Apart from one Bill Poole, who published a few blogposts in early 2008 on Service Boundaries, the internet seems to have more or less dropped the concept of service boundary. So am I looking in the wrong place, or has the internet been infected by the misleading rhetoric of boundarylessness?

I'm also struck by the apparently rapid disappearance of something that had been promulgated as an SOA principle. If you think that principles are timeless truths, think again.


In his latest post Service Boundaries Aren’t Process Boundaries Udi Dahan replies with a correction of his 2004 presentation. He points out that his later posts (from 2007 onwards) no longer assert that services must run in a separate "system" or "process". (One reason for this is that the concepts of "system" or "process" belong in a different architectural view.) He still appears to believe in explicit service boundaries, but he is now thinks it's more appropriate to base these on business capabilities. Meanwhile in a new post on Service Boundaries, Lawrence Wilkes outlines the CBDI position, explains that the service boundaries are orthogonal to various other boundaries, including resource, technology and organizational boundaries, and shows how services can be used to cross these boundaries.


  1. I believe the concept of service boundaries is still valid today. I guess you might argue that all services are effectively at some boundary, and so an explicit principle is not needed. However, as I have explained in my blog I think it is still a useful way to think about how flexibility is going to be introduced into the architecture, and not just on a technology basis.

  2. Very interesting topic. I think the lack of literature and references reflects the intricacy of the matter.

    The ‘fuzziness of the boundaries’ could be the issue. A relevant question could be: Do large SOA systems end up effectively behaving like complex systems?

    In a SOA system, the relationships among services may become ‘nonlinear relationships’ and hard to derive using merely mental models. Changing one part of the system may potentially have unforeseen impacts on other part of the system. Many SOA systems also experience ‘nesting’ by which a ‘component’ (or several components) may be ‘complex’ in itself. It may be difficult to determine service and system boundaries when dealing for example with ‘extended enterprise’ systems (a typical example is the extended supply chain.)

    It looks like ‘non-linear relationships,’ ‘nesting,’ and ‘difficult-to-determine boundaries’ in a SOA system could qualify as features of a complex system

    On boundaries, I quote from Professor A. Juarrero
    “A complex dynamical system’s internal structure consists in the patterns that result
    from particular objects and the interactions among them. But unlike those systems
    characterized by linear processes that can be effectively isolated from environmental
    influence, the external structure or boundary conditions of complex systems are as
    much as part of the complex system as the internal structure; the interactions
    between the components and the environment, that is, “the set of all [interactions
    not components of the system] that act or are acted on by components of [the
    system]” (Bunge 1979) provides the system with a causally effective external
    structure. Although the environment of interest is thus not the total environment but
    the environment that affects and is affected by the thing in question, the feedback
    provides complex systems with a contextual embeddedness that makes the
    boundaries of complex systems typically fuzzy and difficult to demarcate.”

    So if large SOA systems behave like complex systems, How do we analyze & model such systems? Where to draw the borderlines? Where exactly is the boundary? We may need ‘alternative’ design methods and ‘alternative’ design tools.

    Systems Dynamics Modeling may provide some answers. SDM may be a useful design tool to help business analysts to identify service boundaries and their dynamic relationships.

    In a seminal article Nicholas Gall at Gartner wrote about Modeling Complex Adaptive Systems and researchers at IBM have published very interesting papers:

    On Exploiting System Dynamics Modeling to Identify SOA Service Requirements

    System Dynamics Modeling for SOA Projects

    This is an interesting book. Business Dynamics: Systems Thinking and Modeling for a Complex World

    I hope this adds to the whole discussion.

  3. Great observation!

    The definition of Service Orientation has become more relaxed in response to real-world challenges of working with encapsulated black box business functions.

    Quite predictably, these are some of the same challenges of working with big blackbox / monolithic OO programs.

    We live in an increasingly fluid world and static boundaries and hierarchies are inconvenient, they represent premature optimization - coupling before the fact that resists change. It's a design-time technical debt that results in 'exceptions' and 'continuous improvement', which are arguably design smells.

    Service boundaries MUST be porous if we want them to be inclusive of the environment and user discretion, otherwise you are always working out of context.

    Of course, this notion is paradoxical for SOA as a whole, what then for SOAP and WSDL? UDDI has never been realized and is already effectively dead.

    How would re-use of generic blackbox services ever help business? Re-use is a valuable property for development leverage, but it shouldn't come at the cost of the business. SOA hasn't achieved its promise of widespread re-use because business wants its specialization, and specialized services aren't highly re-usable. Standardization is not the friend of innovation and change.

    It is a good time to re-consider Software Architecture. We need to move from mass production thinking to mass customization thinking.

    Generics don't satisfy individual needs/circumstances - we need to use models for what they are - generalizations.

    We have implemented a Framework based on the use of meta-models, in which behavioral patterns are dynamically configured at run-time. System-wide late-binding means the architecture comes together on-demand for each architecture.

    It's a self-organizing, self-adapting system, with full audit history.

    Forrester gave us a mention in their Dynamic Case Management report, and Dr. Robin Bloor of the Bloor Group wrote a post “The New Kid on the Block” ( In addition, we’ve presented papers at academic conferences – and We'll be presenting the system at a Webinar this Thursday -