Defining SOA as an architectural style

Introduction

There is a lot of talk about SOA, yet very little agreement on what this popular three-letter acronym actually means. With many competing definitions, it's hard to decipher its true essence. SearchWebServices.com announced a contest for the best definition and received a slew of submissions. There was little chance of selecting a single "best" definition because SOA means different things to different people. (See Resources [1] and [2].)

Although all of these views are absolutely correct, the key to understanding SOA is in the letter A for architecture. The difficulty is that no one is in agreement on a universally accepted definition for software architecture either; the list maintained by the Software Engineering Institute has more than 50 different software architecture definitions.

For this article I use the definition provided by IEEE Standard 1471-2000, the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (see Resources [3]):

"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution."

The set of components and their relationships for the particular architecture is defined as an architectural style (see Resources [4]): "A vocabulary of components and connector types, and a set of constraints on how they can be combined."

A more holistic definition of the architectural style, provided in Convergent architecture: Building model-driven J2EE systems with UML, states that "An architectural style is a family of architectures related by common principles and attributes." An IT architectural style is both a holistic and specific approach to IT architecture. It is holistic in that it covers the entire software life cycle, including project and tool design aspects. It is specific in that it consolidates and integrates the many structural, procedural, and descriptive aspects that are addressed as separate entities in the traditional methodologies. "An architectural style provides a useful set of reasonable alternatives--not all alternatives--and coordinates them to work well together." (See Resources [8]).

SOA can be defined as an architectural style promoting the concept of business-aligned enterprise service as the fundamental unit of designing, building, and composing enterprise business solutions. Multiple patterns, defining design, implementations, and deployment of the SOA solutions, complete this style.

Why SOA?

Both business and technical leaders alike are interested in SOA, considering it a silver bullet for:

• Achieving better alignment between business and IT
• Creating more flexible and responsive IT infrastructure
• Simplifying integration implementation

It is strongly believed that "SOA allows you to align the business world with the world of information technology (IT) in a way that makes both more effective. SOA is a bridge that creates a symbiotic and synergistic relationship between the two that is more powerful and valuable than anything that was experienced in the past. Moreover, SOA is about the business results that can be achieved from having better alignment between the business and IT." (See Resources [5]).

To understand the current push for SOA, let's start by taking a closer look at today's typical enterprise IT architecture and its shortcomings.

Application-centric architecture

Today's enterprise IT architecture is often viewed as a collection of applications. Design, development, enhancements, and maintenance of software systems revolve around applications. This approach leads to creation of segregated silos within the enterprise architecture, resulting in expensive and inflexible IT systems. Each application is built for a single purpose (such as loan origination, claim management, and so on), with its own data stores and for a single set of users. As a result, it implements only a subset of the enterprise functions, using and producing only a subset of the enterprise data, and typically without concerns about other processing within the enterprise. These silos manifest themselves as islands of data and islands of automation.

Islands of data

With islands of data, each has its own meaning or definition of enterprise objects (see Resources [6]). For example, while in one application "price" defines the net price, in another application the same term also includes sales taxes. Even if an object such as "address" has the same meaning in two applications, one of them can define it as a set of address lines while another one treats it as street address, city, state, ZIP, and country. Both cases create semantic dissonance between applications.

Each has information that overlaps with the contents of another island. For example, applications dealing with the management of health and dental claims also store the demographics information for the insured. At the same time, a customer relationship management (CRM) application contains both insured addresses and demographics. This duplication creates integrity issues.

None can provide a complete picture of the enterprise data. For example, a mortgage management application doesn't contain information about the borrower's loans from other lines of business. Creating a unified view of the enterprise data requires integrating information from multiple sources.

Islands of automation

Each island of automation focuses on a limited set of activities within the enterprise (see Resources [6]). For example, the health claim management application deals only with the processing of health claims, without considering the role and place of these activities in the overall enterprise business process. This requires users to "application hop" to perform their work, thus impacting their productivity.

There is duplication between business processes contained within different islands. For example, an insurance company can have several claim-processing systems as a result of a merger or acquisition. This requires synchronization of changes between multiple applications, ensuring consistency of processes and business rules, supporting these processes.

The effects of islands of data and automation are invisible at the individual application level. However, they cause significant problems at the enterprise level, most notably with

• Information fidelity: The redundancy of business data between islands of data creates an inaccurate representation of enterprise data, even when periodic synchronization occurs. The representations themselves are often contradictory and hard to reconcile. As the individual applications evolve independently, the complexity of the problem increases.
• Business processes fragmentation: Individual applications provide a limited piece of enterprise functions. Implementing business processes requires linking the applications containing partial implementations of a process.

Solving these problems has made enterprise application integration (EAI) and enterprise information integration (EII) the focal point of many enterprise projects. Today these activities consume (and will continue to do so) a significant portion of the enterprise IT budget.

One major reason these integration initiatives are so expensive, complex, and labor intensive is that they are attempting to bring together both data and processing from the applications, which were never designed to work together. The majority of time spent on this undertaking is an effort of rationalizing both data and processes from the existing applications against each other.

From applications to processes and services

In his 2004 interview with InfoWorld magazine, Grady Booch states that "the fundamentals of engineering, like good abstractions, good separation of concerns, never go out of style… there are real opportunities to raise the level of abstraction again." (See Resources [7]).

SOA introduces two high-level abstractions: enterprise business services and business processes. Enterprise business services represent existing IT capabilities (aligned with the business functions of the enterprise). Business processes, orchestrating business services, define the overall functioning of the business.

The charter of SOA is to eliminate applications as they exist today (with all of their drawbacks, just described) and create software systems as a set of interacting services, coordinated by business processes. Every service implements a particular business thing or functions, which are defined in the context of the overall enterprise, and business process represents a business solution that has to be implemented.

Table 1, based on correspondence with Jean-Jacques Dubray, summarizes the key differences between application-centric and SOA approaches.

SOA and decomposition

Enterprise business services are usually defined as a result of decomposition of the enterprise IT system. Decomposition is a technique formalized by classical system theory in the late 1950s. System theory states that the more complex a system is, the more unknowns it contains and thus, the harder it is to automate it. This theory prescribes decomposing complex systems into smaller, more manageable ones that are easier to control, and then treating the whole system as a composition of its parts. The same applies to complex software development initiatives.

Evolution of decomposition in software

The first software decomposition approach introduced in the early 1960s was splitting mainframe applications into separate jobs, each implemented by a separate program. Later, as more insight into the program internals was gained, each program itself was split into modules or subroutines, according to their function.

The object-oriented (OO) paradigm introduced by Simula and Smalltalk in the 1970s strengthened decomposition adoption by introducing objects, or modules of code, each of which implemented a model of a real thing. The idea was to represent in software the "things of the problem domain," such as customer, order, or trade. But, the abstractions provided by objects turned out to be too fine-grained and intertwined with technical concepts to have meaning on the business level.

For various reasons, many object-oriented developers wound up spending most of their time dealing with technical constructs such as collections, graphical widgets, and so on. In most cases the objects of the problem domain disappeared inside amorphous modules that no longer represented anything recognizable by domain experts. Another problem with OO is that although objects are important in a decomposition approach during design and implementation, they are not visible at either deployment or run times and consequently do not directly support either deployment or run-time decomposition.

In the continued search for a better design paradigm, a different approach to decomposition was introduced in the late 1990s: components. The idea was to fix the problems of OO by raising a level of abstraction, increasing granularity, and creating a tighter linkage with the business artifacts.

Introduction of software components allowed for the creation of flexible, better structured, and more manageable software applications. However, it did not solve the main enterprise IT problem: its application-centric nature. Both objects and components provide better design and development approaches for individual applications. SOA brings decomposition to a higher level, as shown in Figure 1. Instead of trying to decompose individual applications, it decomposes the entire enterprise IT functionality.

Elements of SOA

By providing business meaning to its main constituents (business services and business processes), SOA architectural style promotes alignment of business and technology. In fact, both services and processes can be traced back to enterprise business architecture.

The enterprise SOA defines a set of business-aligned IT services (available to participants throughout the enterprise across multiple lines of business or even outside of the enterprise) that collectively fulfill an organization's business processes and goals. These services can be choreographed into enterprise business solutions and invoked through standard protocols. Figure 2 shows the major elements of enterprise SOA (see Resources [13]).

Organization

Owns all SOA-related artifacts (models, services, processes, resources) and governs their creation, usage, access, and maintenance. The role of these artifacts is to support the organization and its business goals.

Business model

Is the primary representation of the business' resources and processes that are required to meet enterprise operational, tactical, and strategic business goals.

A business model is critical to successful alignment of services with business goals and requirements, and consequently, to the overall SOA implementation success.

Semantic data model

Defines the standard business data objects for a given enterprise (such as customer, agreement, and so on). These objects effectively create ontology of the enterprise data by defining common concepts, and their content, which describe the functioning of the enterprise.

Using this data model for defining the business services interfaces leads to the creation of interoperable semantic service interface definitions--a semantic SOA.

Services

Implement specific enterprise business functions and access its data and resources. Well-defined and business-aligned services are a critical ingredient of a flexible, extensible enterprise SOA implementation.

The structure of services allows them to be independently developed and deployed. Correctly defining and aligning services with the business and semantic models results in plug-and-play implementation, allowing them to be effectively combined into different enterprise-wide business processes and solutions.

Business processes

Orchestrate the execution of business services to implement enterprise functions as specified in the business model (order processing or claims processing, for example).

Business processes are usually associated with operational objectives and business goals, such as insurance claims processing or engineering development processing, in a form of key performance indicators (KPI). The KPI collected as part of the process implementation are usually used to evaluate effectiveness of the enterprise functions.

Information

Represents the data resources of the organization. Data resides in a variety of different stores, applications, and formats. Different levels of data are used by different levels of SOA constructs. The semantic data model defines the data for business processes and services. The SOA defines the mechanisms for transforming data from its native operational format to the semantic data required for the business services.

Documents

Represent legal entities (such as financial documents, insurance policies and claims, and government regulations) that define the obligations of the enterprise and its partners. Documents are a vital part of modern enterprises and have to be included in the SOA implementations, along with the rest of the enterprise information, as first-class citizens.

What makes SOA different?

There have been several attempts to present SOA as either a new form of distributed systems architecture, as an extension of object orientation, or as the next-generation EAI. Let's take a closer look at these analogies.

SOA and distributed systems

The W3C Architecture group (see Resources [9]) defines SOA as a form of distributed systems architecture, typically characterized by the properties shown in Table 2.

The SOA model developed by W3C, shown in Figure 3, can be defined in terms of invocation message, implementation, owning organization, and metadata describing the service.

• The message-oriented model defines message in terms of its content (header and body), delivery transport, and originating and executing agents.
• The resource model defines resources, or implementations, in terms of URI, representation, and owning organization.
• The policy model defines policy in terms of its subjects (resource and action) and organization. A policy is a constraint on the allowable actions or states, such as a security policy.

Although SOA is distributed system architecture with message and network orientation, it is also more than that. Equating SOA with a distributed system focuses only on the technical and implementation aspects of services communications, missing one of its key value propositions: the business-IT alignment.

SOA and object orientation

Some practitioners consider SOA a direct evolution of OO, considering services as objects or components on steroids (see Resources [10]). This is as far from reality as it can get. The similarities do not extend beyond system decomposition for definition and encapsulation for implementation.

Additional features of objects, such as inheritance and polymorphism, are not applicable to SOA. What really sets the two apart is usage and programming model (similar to the differences between instance-based and service-based collaborations, described in Resources [11]).

• In OO, multiple object instances of the same type (potentially existing simultaneously) are distinguished based on their internal state, representing a particular execution context. As a result, the object's life cycle is controlled explicitly by its consumer through an object creation.

  Every object exposes multiple methods, which are bound to a particular instance (execution context) and allowed to manipulate variables on a given instance.

• In SOA, services support not the execution context of a particular consumer but rather the state of the enterprise resources associated with the particular service. Typical service invocation is stateless; the notable exception to this rule is a conversational composite service, which typically has an execution context, supporting a particular conversation.

  As a result, the service life cycle is not associated with a life cycle of any particular consumer -- it exists regardless of whether a particular consumer invokes it or not. The resulting programming model is the direct invocation of the service, without its explicit creation.

This difference has a profound impact on the interface definition for objects and services. In OO, multiple methods defined on the interface always physically belong to the same instance of the object because they are bound to the same execution context. In contrast, since services don't have an execution context, the association of methods in the service interface is purely logical.

The service (and consequently service interface) effectively represents a namespace providing a logical grouping of service methods, which are otherwise independent entities with their own quality of service requirements, security, versioning strategy, endpoint address, and so on. To make a programming language analogy: every method of the service is similar to a FORTRAN subroutine/function, which can exist and be executed independently from others.

SOA and EAI

Traditional EAI implementations are typically based on proprietary solutions from EAI vendors, thus creating "lock in" to the vendors' platforms. Many practitioners are presenting SOA as the next-generation EAI technology. For example, Gartner Group has come up with the term Service-Oriented Integration (SOI), and EbizQ lately included SOA in its application-integration roadmap.

With the current advances of Web services as a technology for providing transport solutions, they are often viewed as standards-based integration solutions. This makes them an extremely attractive (and vendor-independent) alternative to EAI implementations. The introduction of Enterprise Service Bus (ESB) products makes Web services-based, standards-based integration solutions even more popular.

Although the goal of both EAI and SOA is often similar--support of enterprise business processes with the existing application portfolio--they achieve it in radically different ways. EAI focuses on exposing the applications' functions through integration services (see Resources [12]), effectively exposing an existing application portfolio as an enterprise business model. In contrast, SOA focuses on hiding the existing applications and exposing a set of application-independent business services instead, projecting an enterprise business model on the existing applications portfolio.

Services

One of the basic abstractions introduced by SOA is service. An SOA implementation typically encompasses three types of services (see Resources [12]):

• Business services (representing business-aligned IT artifacts)
• Integration services (with implementation of integration through SOA technologies, typically Web services)
• Infrastructure services (representing common IT artifacts aimed at infrastructure support)

Please note that when discussing "services" in this article, I'm referring to business services.

In the simplest case, a service can be defined as a self-contained, independently developed, deployed, managed, and maintained software implementation supporting specific functions relevant to an enterprise as a whole and "integratable" by design. The service functionality is defined by a service interface, which can be supported by multiple implementations. This implies that a service is not a programming construct or a set of APIs, but is rather an architectural artifact (unit of design, implementation, and maintenance) used for implementation of enterprise solutions.

Service implementation concerns

Service implementation concerns span from the service designer (such as business alignment and reuse of existing IT functions) to the ones exposed to the service consumer (service contract, service interface, and access policies). Figure 4 sketches these elements and the relationships between them.

Service business functionality

Defined by enterprise business model, which in turn is built based on the enterprise business goals.

Service contract

Defines business functionality of the service, its interface, and one or more service endpoint addresses.

Service interface

Describes, in technical terms, the capabilities of the service provided to potential consumers. The interface is defined as a service name and a set of operations (methods) supported by the service. The description of every operation includes definitions of the set of parameters required for operation invocation (request) and, if applicable, the result returned by the operation (reply). The description also covers the operation's functionality, and pre- and post-conditions.

Service method

Can be accessed through an endpoint address, usually defined as an address' network location. Every endpoint address is governed by a set of access policies. These policies define the communication protocol used for data transfer, actual service invocation, and Quality of Service (QOS) (for example, security and privacy provided or required by a given endpoint address).

Granularity and loose coupling

Represent important service design attributes.

Service implementation

Strives for maximum reuse of the existing enterprise IT functions.

Service orchestration

Represents the prevalent mechanism for composing services into larger ones and building enterprise solutions out of services.

The following sections take a closer look at the major service implementation concerns.

Business alignment
One of the main promises of SOA is business-IT alignment. This promise can be fulfilled only if the services are aligned with the business model of the enterprise. This implies that an enterprise business model is a prerequisite for a successful SOA implementation. A high-level model must be in place to set the direction, partitioning, and taxonomy of services. Its details can be developed over time, in parallel with development of the services. (See Resources [12].)

This approach to the definition of the enterprise business services allows for better alignment of business, organizational, and application (services) architectures, as prescribed by convergent architecture. (See Resources [8] and [14].) It then becomes easier to trace software implementations (services, processes) back to the business architecture, making software applications easier to understand by business analysts, and simplifying the implementation of changes in business functions.

Service granularity
Traditional distributed systems technologies, such as CORBA and DCOM, provide local and remote transparency. They present the same programming model, regardless of the target's location. Such consistency not only simplifies the programming model, it also relieves system designers and developers from spending a lot of time thinking about and defining boundaries. This tradeoff between simplicity of development and execution speed represents one of the major reasons behind the poor performance of many applications built with distributed objects. This was never a problem with the distributed objects technology, but rather a symptom of fine-grained object interactions across system boundaries. (See Resources [15]).

In SOA, all service invocations are remote. This makes explicit the very different characteristics of intra-service (inside the service) and inter-service (across service boundaries) calls. This differentiation emphasizes that service calls are expensive. Consequently, granularity becomes one of the important characteristics of service design.

Because service invocation involves the network, they are designed as coarse grained. Service method execution must deliver the value that justifies the latency cost of a network request. Consequently, the exposed service interfaces must be coarse grained. Instead of exposing many interfaces that provide limited functions, services should expose a small number of interfaces that allow individual requests to perform complete business function.

Proper service granularity not only allows creation of better-performing systems, it also lowers the coupling. Large-grained services tend to be self-contained, resulting in fewer dependencies on other services.

Coupling
If you want to use services to build, maintain, and modify flexible enterprise solutions and to support a federated development approach throughout the enterprise, then loose coupling of those services is a prerequisite. The following list includes some consequences of coupling (see Resources [16]).

• Tighter coupling tends to cost more over time:
• Synchronizing multiple organizations for change
• Adapting and redeploying updated components without affecting others
• Making changes is hard and expensive, or impossible
• Different parts of the solution are difficult to manage separately
• Hard to move, hard to scale, hard to distribute, hard to replace
• More coupling implies more expensive testing
• Looser coupling requires greater investment up front:
• More design work
• More implementation work

The most important dimensions of coupling in SOA implementations are:

Functional coupling

Although interface-based design is not new, SOA takes it even further by basing the (service) interfaces on the enterprise-wide semantics. The importance of enterprise-wide semantics for services interoperability was downplayed by early SOA adopters. The Web services community hoped that the well-defined content and structure of SOAP messages, coupled with XML representation of the payload and standardization of the transport, would ensure interoperability of the Web services communication. In reality this provides only technical interoperability, ensuring that a SOAP message from one system can be received and successfully processed by the other system. However, it does not help in any way with the semantic interoperability--the ability of two systems to "understand" each other.

Examples of such differentiation can be found everywhere. For instance, just because many languages use the Roman alphabet does not mean that the people talking different languages sharing this alphabet understand each other. Pure knowledge of the alphabet is not sufficient for understanding the language.

Usage of the enterprise semantic data model for service interface definitions leads to the creation of interoperable semantic interface definitions. (See Resources [13]). This semantic SOA provides significantly enhanced interoperability between services: all of them work with the same model at the interface level.

Introduction of semantic messaging requires that service implementations support two completely different, but equally important, data models. (See Resources [17]).

• Internal data model: Used by services implementations. This model relates to the internal implementation of the service, and thus is specific to the underlying services and components. The internal data model is not exposed to service consumers.
• External data model: Used for inter-service exchanges, and is the enterprise semantic data model.

Each service is responsible for the semantic brokering, transforming between the enterprise and internal data models.

Temporal coupling

Services, especially Web services publications, tend to focus on synchronous service invocations. The shortcomings of current implementations are sometimes viewed as shortcomings of the SOA itself. Hence, there are several publications promoting events-driven architecture (EDA) and SOA-2 as the ways to fix SOA. In my opinion, it is not SOA that needs fixing, but rather its current usage.

The use of synchronous communication for service invocations creates tight temporal coupling between service consumer and provider:

• The service provider has to be up and running in order for the service consumer to access it.
• Because synchronous invocation is a blocking call, performance changes in either service execution or request/response delivery can have a significant impact at the service consumer execution.

Making a service invocation asynchronous with a separate reply invocation allows the consumer to continue execution while the provider has a chance to respond. This leads to a temporally decoupled system. Temporary service provider outages and network delays have little or no impact in this case. As long as the service provider returns a response, the overall system functions properly.

Services represent coarse-grain singletons in the overall software system, which make scalability and high availability of services an extremely important issue. Asynchronous invocation, providing better scalability and availability characteristics, is a significantly better fit for SOA implementations.

Transactional coupling

Transactionality, in particular the atomicity, consistency, isolation, and durability (ACID) represent a prevalent approach for solving reliability issues in distributed computing. Financial applications employ it for funds transfer, e-commerce systems use it for payments processing, manufacturing applications use it for inventory control, telecommunication billing systems use it for call rating, and so on.

ACID transactions are usually implemented using transaction monitors (for example Tuxedo, CICS, Encina) or component platforms, such as J2EE application server or MTS. Support for ACID transactions requires coupling through the transactional environment, thus limiting interoperability and flexibility.

Another requirement for ACID transactions implementation is resource locking for the duration of the transaction, which requires guaranteed short execution time of services. Longer transaction time usually leads to worsening of the overall throughput of transactional resources.

ACID transactions, while perfectly appropriate for objects and components, are usually too restrictive for services. SOA favors business transactions over the traditional two-phase commit protocol. (See Resources [18] and [19]).

Business processes

Business services by themselves rarely constitute a complete business solution; they typically serve as its building blocks. Creation of the complete solution is usually implemented through composition, or orchestration, of participating services. Such composition is usually done using business processes.

Business processes and process-centric computing are not new. They have been used in IT successfully for over 20 years, starting with the office automation and workflow systems. Companies that want to increase effectiveness and competitiveness have to move toward making the process a basic unit of computer-based automation and support. They have to shift the focus from systems of record to systems of processes. "Process processing" needs to replace "data processing."

At the heart of BPM is the notion of orchestration, where a process engine orchestrates several manual and automatic process steps while manipulating input/output data. SOA makes the realization of BPM more practical. (See Resources [20]). Business processes in SOA facilitate the next phase of business process evolution from merely automated to managed flexibility.

The goal of SOA is to expose an organization's computing assets as reusable business services, implementing basic business functions, which can be (re)used and integrated more readily using business processes. Such ability to rapidly assemble or reassemble solutions using existing services is one of the main advantages of SOA. The relationship between business services and business processes, shown in Figure 5, paves the way to a truly flexible enterprise:

• Business services support stable business artifacts, incorporating processing and rules whose interface changes fairly rarely. (However, the service implementation can and typically does change over time.)
• Business processes support fairly fluid business procedures and rules, which can change every few months, or even weeks.
• The interaction between business processes and business services is based on the enterprise semantics, which minimize impact of services changes on the business processes and simplifies building processes from business services.

Such separation of responsibilities allows business analysts and IT architects to reuse IT functions that are encapsulated in business services through business processes, orchestrating these services. This simplifies creation of the new processes and optimization of the existing ones. More important, once designed, these processes can be quickly modified in response to market conditions. All this translates into increase of the business flexibility and competitiveness without dramatically increasing incremental costs of making frequent process changes.

SOA and patterns

One of the proven ways of explaining and implementing a certain architectural style is through patterns.

"Patterns and pattern languages are ways to describe best practices, proven designs, and capture past experiences in a way for others to learn from these experiences. Patterns are a proven approach for rapidly understanding design guidelines and the various contexts in which they should be applied." --John Evdemon (See Resources [23])

There are many recent publications on patterns and patterns languages for SOA (see Resources [21-26]). Each publication, however, is concentrating only on a particular aspect of SOA implementation, including:

• Service access and infrastructure (Resources [21])
• Service composition (Resources [22])
• Service definition and implementation (Resources [23])
• Service versioning (Resources [24])
• Services security (Resources[25])
• Enterprise data access (Resources [26])

A true SOA pattern language should define a holistic approach to design, creation, utilization, and execution of services -- a complete SOA life cycle. Figure 6 shows an example of such a language.

This pattern language covers three major areas (some of the patterns can belong to several areas):

Service design

This set of patterns covers some of the most important services design activities. The service-oriented decomposition pattern provides the starting point, describing how to define services based on the problem at hand, including the enterprise business model and required long-term architectural qualities.

The service contract pattern defines the creation of formal definition of services, allowing system designers to choose the most appropriate service for their implementation, and service architects and developers to properly invoke it.

The service repository pattern defines solutions for organizing services-related artifacts within the enterprise, thus simplifying collaboration of the stakeholders involved in service definition, creation, and usage.

The service versioning pattern provides guidelines for dealing with inevitable changes in services contracts and implementations, allowing you to reduce the impact of these changes on service consumers.

Service implementation

These patterns cover some of the issues related to service implementation activities. The service implementation layer shows how a portfolio of existing enterprise applications can be leveraged to implement services aligned with the enterprise business model. The service implementation components pattern complements previous patterns by defining major components involved in a typical service implementation and their interactions.

The composite services pattern explores approaches for combining the functions of multiple existing services in order to support functions required by service consumers.

Service infrastructure

This set of patterns covers some important issues of services run-time infrastructure. The service registry pattern focuses on the implementation of late binding for service invocations through the centralized registry, allowing for a single enterprise-wide point of control over deployment and run-time capabilities of services.

Services security is a specialized pattern language (see Resources [25]) defining a set of patterns, and governing design and implementation of services security.

The service logging and service exception-management patterns define approaches for centralized logging and exception management in highly distributed SOA environments.

The service monitoring and management pattern concentrates on approaches to monitor and manage service execution. Finally, the enterprise service bus pattern provides insights into virtualization of services communications, which result in easier implementation of the previously mentioned infrastructure patterns.

Summary

In this article you learned what makes SOA an architectural style. You explored major elements of this style and their interactions. You looked at the rationale behind this style and its differentiation from the other popular approaches for building enterprise architecture. We also touched upon a pattern language that you can use for understanding and simplifying the implementation of this style.

Stay tuned for upcoming articles that will discuss patterns in more detail.

Resources

• Participate in the discussion forum.
  
  
• [1] Revisiting the definitive SOA definition: Multiple definitions of SOA are presented at SearchWebServices.com.
  
  
• [2] Realizing service-oriented solutions with the IBM Software Development Platform: An excellent introduction to service-oriented development of applications (SODA) and usage of IBM® Rational® tooling for its implementation. (A.W. Brown, M. Delbaere, P. Eeles, S. Johnston and R. Weaver; IBM Systems Journal, Oct 2005)
  
  
• [3] IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems -Description: IEEE recommended practice addressing the activities of the creation, analysis, and sustainment of architectures of software-intensive systems.
  
  
• [4] Software Architecture: Perspectives on an emerging discipline: A classical description of software architecture. (Mary Shaw and David Garlan; Prentice-Hall, 1996, ISBN: 0-13-182957-2)
  
  
• [5] IBM's SOA Foundation. An architectural introduction and overview: A position paper from IBM on SOA. (developerWorks, Nov 2005)
  
  
• [6] Achieving the ultimate EAI implementation: An overview of EAI implementation approaches with a focus on a process-driven EAI. (Boris Lublinsky; Business Integration Journal, Feb 2001)
  
  
• [7] IBM's Grady Booch on solving complexity: In this interview, Grady Booch discusses how IBM's acquisition of Rational helps to create a stronger organization helping to solve complexities of modern software implementations. (InfoWorld, Feb 2004)
  
  
• [8] Convergent architecture: Building model-driven J2EE systems with UML: An excellent introduction into convergent architecture, architecture patterns, and more. (Richard Hubert; Wiley, 2001 ISBN: 0471105600)
  
  
• [9] Web Services Architecture, W3C Working Group Note 11 February 2004: Web services architecture definition from W3C.
  
  
• [10] SOA: Buzzworld Whiplash or Real Meat?: James Gosling's thoughts on SOA and its relationships to OO.
  
  
• [11] Enterprise Solution Patterns Using Microsoft .NET Version 2.0: An overview of architecture patterns for implementing software solutions using .NET framework. (David Trowbridge, Dave Mancini, Dave Quick,Gregor Hohpe, James Newkirk and David Lavigne; Microsoft Press, 2003)
  
  
• [12] SOA Design: Meet in the middle (Boris Lublinsky; Java Pro, Aug 2004): Top-down, bottom-up, and meet-in-the-middle approaches to SOA implementation.
  
  
• [13] Unifying Data, Documents and Processes: Discusses incorporation of documents into SOA implementation. (Boris Lublinsky; Enterprise Architect 2004, vol 2, number 2)
  
  
• [14] Business Engineering with Object Technology is a classical introduction into software engineering. (David A.Taylor; John Wiley & Sons, 1995, ISBN: 0471045217)
  
  
• [15] The key to superior EJB design discusses various approaches for improving EJB performance. (Boris Lublinsky; Java Developer Journal, Jan 2002)
  
  
• [16] Bridging Business Value to SOA: SOA Best Practices: This presentation discusses best practices for SOA implementation. (Karin Duermeyer)
  
  
• [17] Data on the Outside vs. Data on the Inside: Differences between data inside and outside services implementation. (Pat Helland)
  
  
• [18] Transactions and Web Services: Differences between different Web Services Transaction standards and their relationships to each other. (Boris Lublinsky; EAI Journal, Jan 2003)
  
  
• [19] A comparison of Web services transaction protocols: Provides a side-by-side comparison of different Web Services Transaction standards and their relationships to each other. (developerWorks, Oct 2003)
  
  
• [20] SOA & BPM: Living Happily Ever After? discusses relationships between SOA and BPM. (B. Lublinsky, D Tyomkyn; Business Integration Journal, March 2006)
  
  
• [21] Toward a pattern language for service-oriented architecture and integration, Part 1: Build a service ecosystem: Approaches to SOA creation and patterns that can be used for every approach. (developerWorks, Jul 2005)
  
  
• [22] Toward a pattern language for service-oriented architecture and integration, Part 2: Service composition: Patterns that can be used for service's composition. (developerWorks, Dec 2005)
  
  
• [23] Principles of service design: Service patterns and antipatterns: Discusses tenets for SOA design, along with major patterns and antipatterns that can be used for service definitions. (John Evdemon; MSDN, Aug 2005)
  
  
• [24] Principles of service design: Service versioning: Explore the rationale and various approaches to service versioning. (John Evdemon; MSDN, Aug 2005)
  
  
• [25] Web Service Security-Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0: Covers patterns for Web services security and their implementation using Microsoft's WSE 3.0. (Jason Hogg, Don Smith, Fred Chong, Dwayne Taylor, Lonnie Wall, Paul Slater; Microsoft Press, 2005)
  
  
• [26] Incorporating Enterprise Data into SOA: Learn about architectural patterns for incorporating enterprise data access into SOA implementations. (Boris Lublinsky; InfoQ, Nov 2006)
  
  

About the author

Boris Lublinsky has more than 25 years of experience in software engineering and technical architecture. For the past several years he has focused on enterprise architecture, SOA, and process management. Dr. Lublinsky is a technical speaker and author, with more than 40 technical publications in different magazines, including Avtomatika i telemechanica, IEEE Transactions on Automatic Control, Distributed Computing, Nuclear Instruments and Methods, Java Developer's Journal, XML Journal, Web Services Journal, JavaPro Journal, Enterprise Architect Journal, and EAI Journal. Currently Dr. Lublinsky works for a large insurance company, where his responsibilities include developing and maintaining SOA strategy and frameworks. You can reach Boris at blublinsky@hotmail.com.

Comments

Back to top

Trademarks

Table of contents

• Introduction
• Why SOA?
• SOA and decomposition
• What makes SOA different?
• Services
• Business processes
• SOA and patterns
• Summary
• Resources
• About the author
• Comments