Companies are at different levels of maturity in the adoption and incorporation of service-oriented architecture (SOA). Some are just beginning to explore the world of SOA using its technology instantiation: web services. They are wrapping legacy functionality and exposing it for invocation for third-parties, clients, and business partners. This gets them into the game: they ramp up the development team, start the process of changing the corporate culture to better support SOA, and take the first steps in the exploration of new technologies and the business capabilities that may be impacted.

	express delivery
	• print  • comment
	SOA is a journey of gradual, small transformations that increasingly decouple service descriptions from service implementations offered by multiple service providers. Ali Arsanjani is Chief Architect in the SOA and web services Center of Excellence at IBM. This article is an edited excerpt from the first of a series of white papers entitled Toward a Pattern Language for Service-oriented Architecture and Integration.
	Glossary terms: service oriented, EAI, ESB, web services, legacy, lookup tool Sponsored links: your text link here

The next level of SOA adoption is when the initial testing of web services has been successfully overcome and now the organization is beginning to integrate systems and applications using services. This is a step beyond enterprise application integration (EAI). As proprietary protocols, glue code, and point-to-point connections give way to more open, standards-based protocols and interaction based on service descriptions that each system externalizes, we step into the realm of service-oriented integration (SOI). In this world, the enterprise service bus (ESB) reigns supreme: a mechanism for mediation, routing, and transformation of service invocations irrespective of the target service provider. It helps overcome many of the shortcomings associated with point-to-point connections.

One of the key value propositions of service-oriented integration is the leveraging of existing investments in IT systems, rather than revamping or rewriting new ones. Realistically, service integration goes further than enterprise application integration and will define and leverage a loosely-coupled set of services over non-proprietary protocols, with minimal "glue code". This approach hinges on the use of services as the key enabler to access; and on the interaction of data and processing between multiple systems or even business partners in an ecosystem.

In order to succeed with this SOI approach, and to start from a practical point in terms of IT systems and gradually move incrementally toward the evolution of services within the enterprise, we need to overcome several principal obstacles or challenges. These problems can seem to form a spectrum from simple, almost trivial issues, to increasingly complex ones that must be resolved as we move to greater maturity in the use and implementation of SOA and garner the corresponding business and IT benefits. The patterns outlined here help resolve those challenges; one pattern per challenge.

Hard-coded

When: Silo; concentrated functionality (this is not a pattern, but a point in time state)
Why: Low risk; low-changing, high-performance systems.

Point-to-point exposure

When: Distributed; multi-point of access
Why: Expose existing functionality rapidly; unlock value fast; access embedded functionality.

Service adaptor

When: Wrap a legacy function and make it callable through web services
Why: Consumer needs access to functionality that is not service-enabled.

Service proxy

When: Access a service using its proxy if you do not have direct access to the service provider’s service description and are unable to directly invoke the service
Why: Provides consumers with an SOA interface.

Remote service strategy

When: Provide flexibility in the choice of the service provider
Why: Provides flexibility in changing service providers based on quality of service or functionality considerations.

Single point of access

When: Eliminate redundant functionality; refactor and consolidate or, in some cases, replace existing systems
Why: Provides one access point to a number of potential variants in functionality. A service strategy often requires a single point of access.

Virtual provider

When: One project or line-of-business at a time, yet relies on others for some functions not yet exposed as services
Why: Non-existent providers; ramp up service critical mass.

Service integrator

When: Single point of access
Why: Routing, transformation.

Enterprise service bus

When: General enterprise integration approach
Why: Mediation; routing; transformation, policies, rules, events; inside the organization or between partners in ecosystem/value-net.

Integrated service ecosystem

When: The Nirvana of SOA; dynamic reconfiguration through context-aware services relying on business domain specific capabilities
Why: Provides dynamic configuration capabilities to a set of semantically inter-related, industry-specific business partners that leverage and recombine the ecosystem capabilities to provide greater value to themselves and the ecosystem as a whole.

As we move towards increasing sophistication, we see a trend — we are using finer grained patterns to build solutions of increasing complexity to solve more complex problems. For example, rather than jump to having an ESB from day one, we may find it more judicious to start with a service strategy, create some service adaptors and proxies, move to a virtual provider, then a service integrator, and then to an ESB. The use of these patterns will depend upon the practical considerations of your project, and you will use them differently on different projects, as Alexander says, "without doing it the same way twice."

SOA is a journey of gradual, small transformations that increasingly decouple service descriptions from service implementations offered by multiple service providers. Like any other pattern, these must be adapted to fit the context and the forces that shape your individual problem space: the tradeoffs and considerations of your project, whether organizational or technical, make a difference, and you can determine if you need to skip a step from one pattern to another or to partially implement the pattern.

As organizations evolve to higher levels of maturity in their usage and adoption of SOA, they will begin to step out of the boundaries of their internal systems, beyond point-to-point piecemeal integration with a few partners, into an ecosystem of services that require new capabilities. Among these capabilities are the patterns we have outlined above that assist in positioning the architecture to enter into the realm of the service ecosystem. Other capabilities include a service-oriented enterprise architecture, a service-oriented modeling and architecture method, a service-oriented reference model, governance, and the patterns needed to ensure flexibility in re-composition within the service ecosystem.

More on this topic