Microsoft SOA Reference Model, Initial Draft of the Introductory Chapter

Posted by Hartmut Wilms on Apr 19, 2007

Community

.NET,

SOA

Topics

Design ,

Modeling

Tags

Service Design ,

Microsoft ,

SOA Adoption

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.

• Older >