Service Oriented Architecture


Service Oriented Architectures (SOA) has become a buzzword these ways. Generally, it is confused with Web Services. But SOA is an architectural concept and web services are one way of implementing them.

The software is growing complex everyday. Modular designs, object-oriented approaches, and component based software were proposed by researchers to address complexity and promote re-use. However, issues of maintenance, deployment, and integration of large-scale software remained problem until the advent of SOA. By adopting a SOA, you eliminate the headaches of protocol and platforms and your applications integrate seamlessly.

This article discusses the SOA in general, covering the key points, requirements and issues involved in service-oriented computing. We will dive deeper into SOA how this architecture allows faster integration and execution play.

SOA Analogies

The principles of SOA can be found in numerous places. That is to say, there are examples that abound that are analogous to the SOA ideal. Consider how different items . potentially manufactured by different vendors -- integrate together to provide some repeatable service.
For instance, a DVD player, which can connect to virtually any TV, can also play just about any DVD movie. Those same DVDs can be played on another device, such as a laptop, or automobile entertainment system. All of these devices integrated with the DVD provide common operational service, although the quality of the service may be different.

As another example, consider batteries which are used for numerous consumer electronic devices. The common service provided is loosely coupled power. It is possible to take the same AA batteries out of a MP3 player, and plug them into a small flashlight, or wireless mouse to receive for power needs.

Similarly, the objective of SOA is to minimize unnecessary dependencies among systems and software elements. This in effect, is what loose coupling is all about.

Key Components of SOA

The first step in learning something new is to understand its vocabulary. In the context of SOA, we have the terms service, message, and dynamic discovery. Each of these plays an essential role in SOA [1].

A service in SOA is an exposed piece of functionality with three properties:
1. The interface contract to the service is platform-independent.
2. The service can be dynamically located and invoked.
3. The service is self-contained. That is, the service maintains its own state.

A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery hints that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria. For example, if I was looking for a credit-card authorization service, I might query the directory service to find a list of service providers that could authorize a credit card for a fee. Based on the fee, I would select a service (see Figure 1). The last property of a service is that the service be self-contained.

Figure 1: Directory service
Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Because the interface contract is platform- and language-independent, the technology used to define messages must also be agnostic to any specific platform/language. Therefore, messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages. That is, for consumers and providers to effectively communicate, they need a non-restrictive type of system to clearly define messages; XML provides this. Because consumers and providers communicate via messages, the structure and design of messages should not be taken lightly. Messages need to be implemented using a technology that supports the scalability requirements of services. Having to redesign messages will break the interface to providers, which can prove to be costly.

Dynamic Discovery
Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:
1. Scalability of services; you can add services incrementally.
2. Decouples consumers from providers.
3. Allows for hot updates of services.
4. Provides a look-up service for consumers.
5. Allows consumers to choose between providers at runtime rather than hard-coding a single provider.

Elements of Service-Oriented Architectures

SOA gives several advantages. It allows seamless integration between different applications and platforms. Another advantage is that SOA allows extending the capabilities of already existing applications without disturbing them much. To realize the above advantages, SOAs impose the following requirements:

Loose coupling. No tight transactional properties would generally apply among the components. In general, it would not be appropriate to specify the consistency of data across the information resources that are parts of the various components. However, it would be reasonable to think of the high-level contractual relationships through which the interactions among the components are specified.

Implementation neutrality. The interface is what matters. We cannot depend on the details of the implementations of the interacting components. In particular, the approach
cannot be specific to a set of programming languages.

Flexible configurability. The system is configured late and flexibly. In other words, the
different components are bound to each other late in the process. The configuration
can change dynamically.

Long lifetime. We do not necessarily advocate a long lifetime for our components. However, since we are dealing with computations among autonomous heterogeneous parties in dynamic environments, we must always be able to handle exceptions. This means that the components must exist long enough to be able to detect any relevant exceptions, to take corrective action, and to respond to the corrective actions taken by others. Components must exist long enough to be discovered, to be relied upon, and to engender trust in their behavior.

Granularity. The participants in an SOA should be understood at a coarse granularity. That is, instead of modeling actions and interactions at a detailed level, it would be better to capture the essential high-level qualities that are (or should be) visible for the purposes of business contracts among the participants. Coarse granularity reduces dependencies among the participants and reduces communications to a few messages of greater significance.

Teams. Instead of framing computations centrally, it would be better to think in terms of how computations are realized by autonomous parties. In other words, instead of a participant commanding its partners, computation in open systems is more a matter of business partners working as a team. That is, instead of an individual, a team of cooperating participants is a better modeling unit. A team-oriented view is a consequence of taking a peer-to-peer architecture seriously.


SOA is the latest buzzword these days. This article clearly brings out two important conclusions. Firstly, SOA is general purpose architecture; although, it is talked about in business applications but it finds equal importance in military simulation domains as well. Secondly, SOA should not be confused with Web Services. Web Services are just one way of implementing SOA.


1. Principles of Service Oriented Computing available through

2. Paul, Tram Chase, Larry Root, Karl Crosson, Moving Towards a Service Oriented Architecture (SOA) for Distributed Simulation Component Environments, SimVentions Inc.

3. Per M Gustavvson, Service Oriented Simulations Concept, SimTect, Sydney, Australia, May 2005.