Foundations - Messages & Services – An Introduction

The term or acronym service-oriented architecture (SOA) is widely used, but there's not a lot of precision in the way that it's used. The World Wide Web Consortium (W3C) refers to SOA as 'A set of components which can be invoked, and whose interface descriptions can be published and discovered'. The CBDI recommends SOA is more usefully defined as 'The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface.'

SOA isn't a new approach to software design, and some of the notions behind SOA have been around for years. A service is generally implemented as a coarse-grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled (often asynchronous), message-based communication model.

Service-oriented architecture and development is based on the following four fundamental tenets:

• Boundaries are explicit. Service orientation is based on a model of explicit message passing and crossing a boundary is considered an explicit act. At the technology level, services interact by passing messages and this tenet demands externally, consumable service interfaces.
• Services are autonomous. Changes made to one service should in no way impact another service. Each service in a system is deployed, managed and versioned independently of each other. Encapsulation is a key element of this tenet. A service should be able to be rewritten without negatively impacting the consumers of the service. Autonomy at the service level requires interchangeable and loosely coupled services. Autonomy at the technology level requires implementation independence.
• Services share schema and contract, not class. This is largely concerned with services not exposing their internals. As an example, consider J2EE and .NET interoperability. This is not possible if you try to interchange platform-specific types, but rather an intermediate meta-model or schema is required. The contracts for what to pass in and what will be sent out have to be clearly defined by schemas and contracts for behavior. Schemas and contracts are expected to remain stable over time bearing in mind that any change in the contracts will impact consumers who are using the previous schema and contract.
• Service compatibility is determined based on policy. Policy defined at the meta level describes the semantic capability of a service based on a set of explicit statements of capabilities and constraints. Examples include security related constraints such as encryption, signing, and the use of appropriate token types. Policies are expressed publicly in terms of policy assertion. This enables the service consumer to access the policy information and then abide by it when interacting with the service. Policy assertions are identified by stable and globally unique names.

SOA is the aggregation of components that satisfy a business need. It consists of components, services, and processes. Components are binaries that have a defined interface and a service is a grouping of components to complete the task. This higher level of application development provides a strategic advantage, facilitating more focus on the business requirement. Web services are part of the wider picture that is SOA. They provide certain architectural characteristics and benefits (specifically platform independence, loose coupling, self description, and discovery) and they can enable a formal separation between the provider and consumer because of the formality of the interface.

For SOA there are three important architectural perspectives:

• The Business Architecture - This is the business facing solution which consumes services from one or more providers and integrates them into the business processes.
• The Service Architecture - This provides a bridge between the implementations and the consuming applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture.
• The Technology Architecture - This describes the various environments supporting the implemented applications, the business objects and their implementations.

Service-oriented architectures are rapidly being accepted by the IT world as a sound, modularized approach for building and deploying services across the extended enterprise. However, practical implementation of these architectures requires careful planning. Interested enterprises must first make sure that they're geared up to implement and support them in the long-term. By developing and following an implementation road map, companies can proactively address a range of challenges that they'll encounter along the way. Each enterprise will face a unique set of challenges; corresponding approaches for solving those challenges will vary, as well. The impact of the challenges, both during and after the implementation, also depends on the context of the given enterprise. Adopting SOA is essential to deliver the business agility and IT flexibility promised by Web Services.

Top of page