Partager via

An Abstract SOA Reference Model

  • Article

A fluffy draft on a fluffy topic - feedback and flames encouraged...

----

While a well planned and executed SOA undertaking can help organizations realize greater responsiveness in a changing marketplace, not all service-oriented efforts have been successful. SOA projects may experience limited success when they are driven from the bottom up by developers unfamiliar with the strategic needs of the organization. Building SOA for the sake of SOA without reference to the business context is a project without organizing principles and guidance. The result is a chaotic implementation that has no business relevance. On the other hand, taking a top-down enterprise-wide approach to SOA requires such enormous time investments that by the time the project is complete, the solution no longer maps to business needs. (This of course is one of the problems SOA is supposed to solve!)

By contrast, Microsoft advocates a “middle out” approach which combines both top-down and bottom-up methodologies. 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.

The concept of SOA can be viewed from several possible perspectives. While no single perspective or set of perspectives represents a definitive view of a SOA, from a holistic view these perspectives assist in understanding the underlying architectural requirements. Microsoft believes that there are three abstract capability layers exposed within a SOA:

An illustration of these categories and their relationships to one another appears below:

Figure 6: An Abstract Reference Model for SOA

Expose

Expose focuses on how existing IT investments are exposed as a set of broad, standards-based services, enabling these investments to be available to a broader set of consumers. Existing investments are likely to be based upon a set of heterogeneous platforms and vendors. If these applications are unable to natively support Web services a set of application or protocol-specific set of adapters may be required. Service creation can be fine grained (a single service that maps on to a single business process), or coarse grained (multiple services come together to perform a related set of business functions). Expose is also concerned with how the services are implemented. The functionality of underlying IT resources can be made available natively if they already speak Web services, or can be made available as Web services though use of an adapter. A Service Implementation Architecturedescribeshow services are developed, deployed and managed (we will cover this topic in greater detail in Chapter 2).

We will examine the Expose concept in greater detail in Chapter 2 (Service Orientation).

Compose

Once services are created, they can be combined into more complex services, applications or cross-functional business processes. Because services are exist independently of one another they can be combined (or “composed”) and reused with maximum flexibility. As business processes evolve, business rules and practices can be adjusted without constraint from the limitations of the underlying applications. Services compositions enable new cross-functional processes to emerge, allowing the enterprise to adopt new business processes, tune processes for greater efficiency, or improve service levels for customers and partners. A Service Integration Architecture describesa set of capabilities for composing services and other components into larger constructs such as business processes.

Composing services requires some sort of workflow or orchestration mechanism. Microsoft provides these capabilities via BizTalk Server 2006 (BTS) or Windows Workflow Foundation (WF). While BTS and WF may appear to serve similar needs, they are actually quite different. WF and BTS are complementary technologies designed to serve two very different needs:

  • BTS is a licensed product designed to implement workflow (“orchestrations”) across disparate applications and platforms.
  • WF is a developer framework designed to expose workflow capabilities within your application. There are no fees or licensing restrictions associated with using or deploying WF.

We will examine workflow, orchestration and the use of BizTalk/WF in Chapter 3 (Workflow and Business Processes).

Consume

When a new application or business process has been created that functionality must be made available for access (consumption) by IT systems, other services or by end-users. Consumption focuses on delivering new applications that enable increased productivity and enhanced insight into business performance. Users may consume “composed” services through a broad number of outlets including web portals, rich clients, Office business applications (OBA), and mobile devices. “Composed” services can be used to rapidly roll out applications that result in new business capabilities or improved productivity. These application roll-outs can be used to measure the return on investment (ROI) in an SOA. A Service Oriented Application Architecture describes how “composed services” are made available for consumption through as business processes, new services or new end-user applications. This concept is sometimes referred to as Composite Applications since it implies service consumption by end-user applications. Microsoft’s Office Business Applications (OBAs) support the Composite Application notion of transactional systems while expanding the scope of user interaction via the familiar Office environment.

We will examine consumption in greater detail in Chapter 5 (User Experiences).

While the architectures described within Expose / Compose / Consume may be interdependent, they are designed to be loosely coupled. This enables services to be managed, versioned and configured independently of how they are exposed,

Comments

  • Anonymous
    April 12, 2007
    A fluffy draft on a fluffy topic - feedback and flames encouraged... ---- While a well planned and executed

  • Anonymous
    April 12, 2007
    The comment has been removed

  • Anonymous
    April 19, 2007
    The comment has been removed

  • Anonymous
    April 20, 2007
    The comment has been removed

  • Anonymous
    April 22, 2007
    The comment has been removed

  • Anonymous
    April 22, 2007
    Some practical considerations that should be addressed:

  • Stand against fine grained v/s coarse grained services?
  • Handling of services dependencies?
  • Handling of reference data across autonomous services (eg. customer's industry in relation to a customer entity)?
  • Handling of data integrity across autonomous services (eg. customer reference in say Order Proccess Service)?
  • SOA with (or in the face of) ADO-ERD,DLINQ, LINQ??
  • EDA (Event Driven Architecture) with SOA?
  • Loosely Coupled Integration of Services? Consideration for Enterprise Service Bus (ESB) therein?
  • Exposing of Database as Services, and applicability of CRUDy Services (See MS CRM 3.0 Web Service)? When can we expect the final document? And lastly, perhaps you should consider following it up a real-world code sample - walk the talk? Good Luck..

  • Anonymous
    April 22, 2007
    Look - an RM has been done.  What would really be helpful is a reference architecture to map the RM to WS-.  Rishi's comments above are very relevant to a lot of people.  Making another abstract model is not going to help much.  Making a reference architecture that maps the RM to WS- will be very useful. The RA team is meeting in San Diego this week to work on a first draft of an RA based on the last 9 months of their work on their Wiki.  It would be great to get great minds like John's behind this work (or helping steer it). Duane

  • Anonymous
    April 23, 2007
    John, This is a great topic to get addressed but as such your fluffy draft does not have much content:

  • Building systems (no matter SOA based or not) requires addressing strategic needs of the organization involved. This is really nothing new. We know this for eternity. Corollary: What Microsoft advocates as per your introduction is nothing new. You can use Microsoft tools and technologies (or for that matter any other stack) to build great or clumsy systems depending upon taking a good or bad approach.  
  • I would be too careful to say that the graphics of Fig. 6 represents any kind of reference model.
  • What you have described apropos of Expose, Compose, and Consume are not architectures at all as you have claimed. Just asserting something being an architecture normally does not render it so.
  • You might not have wanted to sound it so but it feels that you want to run Expose, Compose, and Consume in a serial fashion which contradicts to your basic thesis that SOA projects should be driven by strategic business needs. I am sure you shall come up with a great paper finally. Kind Regards, rashed_iqbal@ieee.org

  • Anonymous
    May 03, 2007
    Microsoft Abstract SOA Reference Model and SOI codenamed Alchemy

  • Anonymous
    June 01, 2008
    A fluffy draft on a fluffy topic - feedback and flames encouraged... ---- While a well planned and executed SOA undertaking can help organizations realize greater responsiveness in a changing marketplace, not all service-oriented efforts have been successful