Your opinion matters! Please fill in the InfoQ Survey!

Microsoft SOA Reference Model, Initial Draft of the Introductory Chapter

| by Hartmut Wilms Follow 0 Followers on Apr 19, 2007. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

John Evdemon, an architect with the Microsoft Architecture Strategy Team has published an initial draft of the introductory chapter of a Microsoft Abstract SOA Reference Model. According to Evdemon this paper shall serve as an abstract reference for understanding, designing and building software architectures that adhere to service-oriented principles.

Right at the beginning of the first chapter John Evdemon states that Microsoft has always promoted a "grow-to-fit" approch to SOA efforts:

In this approach, SOA efforts are driven by strategic vision and business need, and are met through incremental, iterative SOA projects that are designed to deliver on business goals one business need at a time. Microsoft has been using this technique to assist customers with their SOA initiatives since the .NET framework was first released in 1999.

Although called an Abstract SOA Reference Model, the paper follows this pragmatic approach by providing a use-case-driven approach to explain the underlying architectural requirements of a SOA. Evdemon explains Microsoft's belief "that there are three abstract capability layers exposed within a SOA:"

  • Expose (Service Implementation Architecture)
  • Consume (Application Architecture)
  • Compose (Service Integration Architecture)

The first two layers or architectures relate to the classical web services triangle, where web services are registered and provided (exposed) by one or two participants and consumed by another. The third layer expresses the loosely coupled nature of a SOA that allows for great flexibility in composing or integrating services.

[...] the SOA architectural model is fractal. This means that a service can be used to Expose IT assets (such as a Line of Business system), be Composed into workflows or Business Processes (each of which may also be exposed as a service) and be Consumed by end users, systems or other services. SOA is a fractal, not layered model.

Each of the three architectures encompasses a set of five architectural capabilities:

  • Communications - how is messaging accomplished between senders and receivers
  • Workflow and Processes - orchestration or choreography of processes and implementations via workflows
  • Data - data management
  • User Experience - means of service consumption adhering to contextual requirements
  • Indentity - identity management and lifecycle
The five architectural capabilities serves as a set of views to better understand the challenges associated with Exposing existing IT investments as services, Composing the services into business processes and Consuming these processes across the organization.

John Evdemon refers to the four tenets regarding service design and summarizes the intent of the paper as follows:

In this chapter we provided some useful analogies for understanding the fractal nature of SOA. Services are the fundamental building blocks of SOA, although services do not necessarily need to be web services. Ideally these services should follow the four service design tenets which describe a set of best practices for service scopes, dependencies, communications and policy-based configuration. While these tenets focus upon service design, it is important to realize that services alone are not necessarily solution architecture – Microsoft uses an abstract reference model to describe the various aspects of SOA. The abstract SOA reference model provides three fundamental concepts to help most organizations understand the role that services can play within their solution architectures[.]

Although the Microsoft Abstract Reference Model does not promote a specific service-oriented architecture, the aspects of a SOA and the underlying architectural capabilities of each aspect introduced in this first chapter provide a more concrete model for building SOAs than the definitively abstract OASIS SOA Reference Model. The subsequent chapters will elaborate on each aspect and capability. The final paper will most likely introduce several Microsoft technologies and products (in addition to the few named within the first chapter), which might be used to build SOAs according to the Microsoft Abstract Reference Model.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you