• Introduction
• Service Oriented Architecture
• What Is SOA?
• SOA and Enterprise Architecture
• SOA and Boundaryless Information Flow
• SOA Features and Benefits
• Acknowledgements
• Referenced Documents
• OSIMM Version 2 Technical Standard
• SOA Reference Architecture Technical Standard
• SOCCI Framework Technical Standard
• Using TOGAF to Define and Govern SOAs
• SOA Governance Technical Standard
• SOA Ontology Technical Standard
• Legacy Evolution to SOA
• Navigating the SOA Open Standards Landscape Around Architecture White Paper

SOA Work Group

SOA Work Group Members Page

Service Oriented Architecture : SOA Features and Benefits

SOA starts with a simple idea – the concept of service. This makes it possible to introduce other ideas, such as service bus, service composition, and service virtualization, each of which can be applied to the architecture of an enterprise to deliver benefits. As an architect, it is your job to evaluate the needs of your enterprise, and the costs of the different potential solutions, to determine which of these ideas should be applied, and how they should be applied, in your SOA.

An architect should always probe into the information given, about both requirements and solutions, to reach a level of understanding that goes deeper than the buzzwords. For example, it is often said that “SOA delivers enterprise agility”. What does “agility” mean for your enterprise? Is it the ability to re-combine existing functions to meet changing customer requirements? Is it the ability to develop new functions rapidly? Is it the ability to scale operations to meet different levels of demand? Within the broad concept of SOA, there are three very different ideas that can help you meet these different agility requirements: service composition, model-driven development, and service virtualization. You can build all of these ideas into your SOA, but they each require different – and expensive – supporting infrastructure. You must choose your solution to fit the requirements.

This section will help you to match the features of SOA to the needs of your enterprise, so that you can determine the kind of SOA that is appropriate.

Summary of Features and Benefits

SOA Features, Benefits, and Infrastructure shows the main features and benefits of SOA, together with the infrastructure needed to support them.

SOA Features, Benefits, and Infrastructure

Service

Service is the essential concept of SOA.

It is not originally a technical concept. The idea of a service was developed in the world of business. Look in any “Yellow Pages” directory, and you will find categories such as “courier services”, “garage services”, and “roofing services”. For each of these, some person or company (the service provider) is offering to do something – carry goods and messages, look after vehicles, install and repair building roofs – that will benefit other people or companies (the service consumers). The providers offer to contract with the consumers to do these things, so that the consumers know in advance what they will get for their money.

The idea has been adopted by technologists. They have established the concept of a software service. A software service is performed by a software program. It produces effects that have value to the people or organizations that are its consumers. It has a provider – a person or organization that takes responsibility for running the program to produce those effects. And there is an implicit or explicit contract between the provider and the consumers that the program will produce the effects that the consumers expect.

Software services can be provided over the Internet and the world-wide web. In some countries, for example, the government provides a service by which taxpayers can complete and submit their tax returns via the web. Here, the service has a human interface. Services provided over the web can also have software interfaces. For example, there are commercially-available web services that provide real-time stock quote information in a form where it can be analyzed by the consumers’ software. Software services can similarly be provided over enterprises’ internal networks, and a service performed by one program can be used by another program running on the same computer system. It is the organization of an enterprise’s software as software services that are provided internally in this way, and also externally, that is the essential characteristic of SOA.

The use of services provides major benefits:

• In contrast to the use of large applications, which tend to be “information silos” that cannot readily exchange information with each other, the use of finer-grained software services gives freer information flow within and between enterprises. Integrating major applications is often expensive. SOA can save integration costs.
• Organizing internal software as services makes it easier to expose its functionality externally. This leads to increased visibility that can have business value as, for example, when a logistics company makes the tracking of shipments visible to its customers, increasing customer satisfaction and reducing the costly overhead of status enquiries.
• Business processes are often dependent on their supporting software. It can be hard to change large, monolithic programs. This can make it difficult to change the business processes to meet new requirements (arising, for example, from changes in legislation) or to take advantage of new business opportunities. A service-based software architecture is easier to change – it has greater organizational flexibility, enabling it to avoid penalties and reap commercial advantage. (This is one of the ways in which SOA can make an enterprise more “agile”.)

The service concept also makes possible further features of SOA. These can provide additional benefits, as explained in the rest of this section.

Service Re-Use

Clear service descriptions are a starting point for service re-use, which can provide another major benefit of SOA:

• Using existing software modules rather than writing new ones means lower development and testing costs and – in many cases an even greater saving – lower maintenance costs.

Messaging

You can have an SOA in which software services invoke each other directly; for example, by programming-language function calls. But, in many SOAs, the software services always invoke each other by exchanging messages, even where they are executing on the same processor. This might seem to be an additional overhead but, if the services are loosely-coupled (as they should be), then the number of message exchanges is relatively small, and the overhead is reasonably low.

Consistent use of messaging provides a key benefit:

• Services can very easily be moved between computer systems within the enterprise, and it is reasonably easy to use externally-provided services to replace internal ones, and vice versa. Which services handle which messages can be changed rapidly to meet changing business needs, or to tune performance. In short, messaging provides significant configuration flexibility.

Having a central mechanism by which all messages are exchanged facilitates monitoring, control, transformation, and security of messages.

Message Monitoring

Message monitoring can provide three key benefits:

• Monitoring message streams between business activities, and analyzing them to obtain information about those activities, is known as business activity monitoring. It can be a valuable source of business intelligence.
• Monitoring message volumes and response times is a valuable source of performance measurement. Service contracts often include performance clauses. Performance measurement enables service designers to put realistic clauses into the contracts, and enables systems managers to verify that those clauses are being met.
• Monitoring messages and message volumes can provide security attack detection, including detection of denial-of-service attacks as well as of attacks in particular messages.

Message Control

Message control can provide:

• Application of management policy; for example, by restricting a service consumer to a contracted service volume, or giving priority to certain kinds of message
• Application of security policy; for example, by controlling access to certain services, or rejecting messages that could damage the enterprise systems or the enterprise itself (e.g., messages containing viruses that could destroy data)

Message Transformation

Message transformation can provide:

• Data translation – the conversion of data from one format to another through automated field mapping.

Data conversion by specially-written software is expensive. The use of generic data translators can bring significant cost saving.

Message Security

Message security can include:

• Data confidentiality through encryption of messages
• Data integrity through addition of cryptographic integrity-check fields

Security is a complex area that is of crucial importance to enterprises. The ability to encrypt and apply integrity checking to messages in transit can be a valuable component of an overall security strategy.

Complex Event Processing

As well as being invoked by their consumers, services can respond to events from other sources. For example, a financial information service might respond to stock-price changes, or a manufacturing production-control service might respond to production process events, such as changes in temperature of the materials being processed.

In many cases, action is taken when a pattern of events is recognized, rather in response to individual events. A financial information service might notify the user when a volume of trades is exceeded rather than in response to a single trade. A production-control service might take measurements from a number of sensors and take action when the average exceeds a limit. This aggregation of simple events to generate complex events is known as Complex Event Processing (CEP).

In SOA, CEP is often used, not only for external events, but also to detect patterns in the flow of messages between services. When used in this way, it becomes an extension of message monitoring.

CEP is often linked with business activity monitoring. For example, detection of a particular pattern in sales transaction messages could provide advance warning of difficulties for the production process. In some industries, such as banking, detection of particular patterns may indicate fraudulent activity, or assist with regulatory compliance.

CEP can also be used with performance measurement and security attack detection. For example, where a service contract specifies an average level of performance, CEP used in conjunction with performance measurement could generate contract exception events. CEP might also be used to generate security events for unusual message volumes or patterns.

CEP provides the following benefits:

• Simplification of software structure – by removing functionality that is not business-related from the business software services
• Ability to adapt quickly to different external environments – by concentrating in one place the logic that relates environmental events to business events
• Improved manageability and security – when used with performance measurement and security event detection

Service Composition

Service composition is the putting together of a number of simple services to make a more complex one. For example, a “product sale” web service could be composed of simpler “product selection”, “shopping cart review”, “payment method selection”, “credit card payment”, and “invoice payment” services. Service composition provides a key benefit:

• Ability to develop new function combinations rapidly

For example, if it is decided that the product sale service should cater for a new method of payment – “Internet cash” – this can be done by developing a new “Internet cash payment” service, and including it in the composition.

So far, this sounds to be little different from other software modularization techniques, from machine-code subroutines through to Java objects. Indeed, in an SOA that does not include messaging, service composition will be implemented by some such technique. But in many SOAs composition is implemented by services sending messages to invoke other services, and this technique gives much greater flexibility.

Two styles of composition are often distinguished:

• Orchestration, in which one of the services schedules and directs the others. If the above example was designed as an orchestration, there would be a direction service that would invoke in sequence the product selection, shopping cart review, payment method selection, and, depending on the selection result, credit card payment or invoice payment services.
• Choreography, in which the composed services interact and cooperate without the aid of a directing service. If the above example was designed as a choreography, there would be no directing service: the product selection service would invoke the shopping cart review service, the shopping cart review service would invoke the payment method selection service, and the payment method selection service would invoke the credit card payment or invoice payment service.

Service Discovery

When a program uses a software service, the identity of that service can be explicitly given in the program code. For example, where services are implemented as Java objects, their methods can be invoked by name by user programs. Where messaging is used, the destinations of the messages can be explicitly named at programming time. This is called hard-wiring of service connections.

Hard-wiring is a simple approach, but it has limitations. A different and much more flexible approach is service discovery. In this approach, the identity of the target service is not known at programming time, but is discovered at run time. The user program finds target services that meet its requirements, and chooses one of them.

The benefits of service discovery are:

• Ability to optimize performance, functionality, and cost – by selecting component services by these criteria
• Easier introduction of system upgrades – an upgraded service can be made available for selection in parallel with the one that it replaces, which can then be withdrawn

Asset Wrapping

The IT assets of an enterprise can often be considered as actors that perform services. A CPU performs an information processing service; a filestore performs an information storage service; and so on. This includes software as well as hardware assets. A database management system performs a database management service; an accounts package performs a financial information processing service.

An important feature of SOA is the recognition that these assets perform services, and the development of software façades that provide access to these assets and have interfaces that are in the same form as the interfaces to other software services of the enterprise. This is called asset wrapping. From a component-based software engineering point of view, the assets and the façade are components that are assembled to form a software service. The software services formed in this way can be used in service composition, have registry entries, and be dynamically discovered, in the same way as other services.

When an enterprise adopts an SOA, asset wrapping is typically applied to existing application software packages. This provides a significant benefit:

• Ability to integrate existing assets – which means that the value of an enterprise’s existing assets is preserved, the cost of developing or acquiring replacements is avoided, and there is a smooth migration path from the old architecture to the new one

With the advent of SOA, some application vendors have begun to offer versions of their products in which the product capabilities are exposed as services. The acquisition of such a version is clearly a convenient way for an enterprise to achieve the “wrapping” of an application asset.

Virtualization

A façade can present to the consumer a virtual asset that does not correspond to the real underlying assets. This technique is called virtualization. Virtualization can be used to enable programs that were written to use one asset to be executed with a different asset. For example, there are so-called “hypervisors” that can provide different operating system environments to programs running on a single CPU. But in the context of SOA it is more commonly used to create virtual assets that are functionally similar to the underlying assets. This can deliver two benefits:

• Improved reliability – through redundant operation of the underlying assets, so that one can take over when another fails or is withdrawn for maintenance
• Ability to scale operations to meet different demand levels – through dynamically increasing or reducing the number of underlying assets that support a real asset, as demand rises and falls

These benefits are particularly important when the principles of SOA are applied to enterprise infrastructure. While SOA is most commonly thought of as a way of architecting an enterprise’s application software, it can also be used at the infrastructure level, to create a Service-Oriented Infrastructure (SOI). Taken to the limit, this can provide a form of grid computing. The use of virtual assets that are made available over the Internet has become known as cloud computing.

Model-Driven Implementation

Model-driven implementation refers to the automatic realization of a system or application from an abstract model. Where the model starts at a high level of architectural abstraction, it is usually referred to as Model-Driven Architecture (MDA).

SOA lends itself particularly well to model-driven implementation, because it is based on a high-level software module concept (the service) for which there are good definition and interface standards.

Model-driven implementation provides:

• The ability to develop new functions rapidly – an important form of agility

In SOA, model-driven implementation can be applied to service compositions as well as to software services.