Introduction to Service-Oriented Architecture
14 April 2003
Yefim Natis, Roy Schulte
Driven by Web services momentum, service-oriented architecture moves from leading-edge software projects to the mainstream. However, most enterprises are confused about its benefits and don't understand its risks.
What You Need to Know
Service-oriented architecture is a best-practice architecture pattern for the systematic design of request/reply applications. Its primary intentions are business-level software modularity and rapid, nonintrusive reuse of business software in new runtime contexts. Users must understand the essence of SOA, as well as its strength and limitations, to identify its role in the overall architecture of modern enterprise IT.
Analysis
Strategic Planning Assumptions
By 2006, more than 60 percent of enterprises will consider SOA a guiding principle in designing their new mission-critical business applications and business processes (0.7 probability).
By 2006, more than 75 percent of midsize and large enterprises will have deployed SOA-enabled development tools and middleware (0.8 probability).
Through 2006, service interaction will require coordinated implementations of service stub and service proxy encoding (0.8 probability).
Service-oriented architecture (SOA) is a client/server software design approach in which an application consists of software services and software service consumers (also known as clients or service requesters). SOA differs from the more general client/server model in its definitive emphasis on loose coupling between software components, and in its use of separately standing interfaces.
SOA principles are rendered during application design, development and deployment. These renditions share the essential principles of encapsulation and flexible coupling, but they differ in detail. The fundamental intent of SOA is the nonintrusive reuse of software components (services) in new runtime contexts. The design and development of SOA is performed for the purpose of achieving such an agile runtime environment.
A service interface is the design essence of SOA.
At design time, a service is an encapsulated business software component that is rendered as a pair of separately defined elements — service interface and service implementation. The interface is the fundamental, definitive component of a service. A service is always intended for programmatic access from another software component (a service consumer). The service interface defines the programmatic access "contract" of the service.
The service implementation fulfills the business functionality of the service. Depending on the level of detail in the design effort, the service implementation may be left as a "black box" to be fleshed out at development time. In other cases, it may be designed as a new module, wrapped access to an older, pre-SOA module, or a composition of multiple, conditional calls to new and pre-existing software modules.
The design of the service implementation is secondary in the design of SOA; however, the design of the service interface is primary. SOA is fundamentally a flow and a relationship of service interfaces. The design of SOA involves defining service interfaces as well as their interaction with each other and service consumers.
A black box nature is essential to a service.
A service interface is a contract that establishes the identity of the service and the rules of the service invocation. The service interface must have sufficient information for a service to be identified (that is, found and understood) and used, without considering its internal design and content. A black box nature is essential to a service. This means that all input data, all response data (if any) and all exception conditions raised must be listed in the interface. It also means that sufficient metadata must be provided in the interface to identify the purpose and function of the service. Relying on the name of the service is an acceptable but weak form of identity. A searchable repository that defines the function of a service can support a larger number of services with finer granularity, and come from a larger number of independent sources.
Loose coupling differentiates SOA from basic software modularity.
SOA is a loosely coupled arrangement of services and service consumers. At design time, loose coupling means that services are designed with no affinity to any particular service consumer. Inside the service, no information is assumed as to the purpose, technical nature or business nature of the service consumer. Thus, a service is fully decoupled from a service consumer.
However, the service consumer is dependent on the service (that is, it embeds literal references to service interfaces). Thus, SOA is a semicoupled (or loosely coupled) architecture. It differs from an event-driven architecture, in which all participating software components are decoupled from others, and also from a monolithic architecture, in which all software components are designed to operate only in the initially intended context (that is, logically tightly coupled).
Design-time loose coupling is essential to SOA because it enables the nonintrusive reuse of service interfaces. However, tools can't guarantee design-time loose coupling. Poorly designed services, which are logically locked into their service consumers, may render the entire application monolithic — despite the use of SOA-style technologies.
The optimal granularity of a service depends on use, tools and skills.
A service interface may be designed to expose multiple entry points (methods) or only one entry point. Customer maintenance may be an example of a service that exposes multiple methods (for example, create customer, delete customer or get customer information). The "get customer information" method may also be a complete service in its own right, with only a single entry point. The optimal granularity of a service interface depends on many factors (see "Service-Oriented Integration Architectures for Healthcare").
The service interface definition is at the center of SOA development.
At development time, a service interface is rendered as a separately standing interface definition file. Similar to design time, the service interface remains the essential element of SOA. Interface files can be defined using any syntax that is agreed upon, but a standards-based syntax enables broader adoption of the service.
When Web Services Description Language (WSDL) is used to encode the service interface, the service is a Web service.
WSDL is the proposed standard that is used for the service interface definition in most new development tools. Earlier SOA development was based on CORBA Interface Definition Language (IDL), COM/DCOM Microsoft IDL (MIDL), Customer Information Control System (CICS) common area (COMMAREA) and other narrower-defined specifications.
A typical SOA application development process starts with the definition of the interface, and follows with the development of service implementation software and service consumer software. Most development tools hide the exact language of the interface definition, but the development methodology of SOA-oriented tools remains centered around the definition, discovery and interconnection of service interfaces.
Service implementation software has an architecture of its own.
At development time, a service implementation may be a new program, a wrapper that connects through an adapter to an older application, or a composite of the two — a conditional and integrated assembly of multiple programs, old and new. Developing service implementations may be a purely new programming undertaking, an attempt at pure legacy wrapping and adapting, or an application integration undertaking. Each requires different tools and developer skills.
A lack of sufficient service isolation will render the resulting application monolithic.
Loose coupling at development time involves programming service implementations that can be invoked in multiple contexts. Service implementation software developers must understand that the essence of a service is its capability to be reused in new contexts. The service implementation must make no assumptions about a service consumer's technology or business logic. However, tools can't enforce this requirement. Developers and their project leaders must ensure the isolation of service implementations. The less isolated the internal design of a service implementation is, the more expensive it will be to reuse the service. A lack of sufficient isolation will prevent a service implementation from being reusable, and render the resulting application monolithic — despite the use of SOA tools and middleware.
The assembly of independent services requires integration.
Service isolation empowers reuse but increases complexity. Independent services have independent and possibly conflicting information and process models. This makes the orchestration of services more difficult. In most cases, the assembly of services requires additional (integration) technology to resolve differences between services, and to manage common context and error recovery.
Runtime SOA is evident in dynamically reusable business-scope software components.
At runtime, a service interface is rendered as a pair of programs — the service interface stub and the service interface proxy — which are typically generated by a development tool from the interface definition file, but they are also possibly developed by hand and embedded into other software at development time.
The stub:
- is deployed on the server, local to the service implementation
- interacts with the service implementation using local communication methods and data encoding that is appropriate to the service implementation
The proxy:
- is deployed local to the service consumer
- interacts with the service consumer using local communication methods and data encoding that is appropriate to the implementation of the service consumer
A typical example would have the stub as a Java servlet and the proxy as a Visual Basic component. This pair of programs implements the service interface. Any new runtime application may access the service via its interface proxy, delivering the nonintrusive runtime reuse of services.
When SOAP is used in service stub and service proxy communication, the service is a Web service.
Theoretically, the generated pair of interface stub and proxy modules may use XML, a SOAP message envelope, HTTP, message-oriented middleware (MOM) or shared memory to pass the service interface parameters.
Service stub and service proxy communication is a "private business," but to preserve the appearance of vendor and tool independence, most generation tools render the connectivity using standard protocols. In reality, however, the "standard" protocols are not standard enough to ensure automatic interoperability. Performance optimization may also require the use of less-standard (and more-flexible) communication protocols. Thus, despite the standards, through 2006, service interaction will require coordinated implementations of service stub and service proxy encoding (0.8 probability).
At runtime, technical loose coupling is accomplished via underlying "sessionless" communications, such as HTTP or MOM. This low-level loose coupling is only effective if the service was designed and developed with logical loose coupling. If so, then the use of loosely coupled middleware permits the dynamic runtime addition of new service consumers (that is, new user experiences can be added to running systems with virtually no impact on current systems). Otherwise, loosely coupled middleware may still offer greater throughput for the overall system, but it won't increase the system's agility.
The runtime middleware of SOA may be tightly coupled (for example, Java Remote Method Invocation (RMI) or Microsoft .NET remoting). If the design and development of the service is logically loosely coupled, then some of the agility of SOA is still delivered at runtime — despite the use of tightly coupled runtime middleware.
SOA is not always the right architecture.
SOA is useful in systematic application engineering, especially in circumstances where request/reply is the natural relationship pattern between software components. However, SOA comes at the cost of additional design and development efforts, and it also carries certain middleware coupling requirements. Limited-scope applications, intended for short life, typically do not benefit from SOA because their business logic is neither reused nor changed during their useful lifetime. SOA is also not recommended for applications using asynchronous one-way interactions. Here, the loose coupling of SOA is unnecessary and undesirable.
Key Issue
Which software infrastructure architectures and patterns will prevail, and which will fail to gain industry support?
Acronym Key
| CICS | Customer Information Control System |
| COMMAREA | Common area |
| IDL | Interface Definition Language |
| MIDL | Microsoft IDL |
| MOM | Message-oriented middleware |
| RMI | Remote Method Invocation |
| SOA | Service-oriented architecture |
| WSDL | Web Services Description Language |
This research is part of a set of related research pieces. See AV-19-6751 for an overview.
Return to Top