Service-oriented architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers, and service producers can coexist, and still have no dependence on each other. SOA enables an enterprise to increase the loose coupling and the reuse of frequently used software assets. These software assets, together with the functionality that they provide, are called services in the SOA terminology. By nature, SOAs are complex and are typically applied to solutions with highly volatile requirements.

As SOA concepts are increasingly utilized and applied to solve software integration problems, there is confusion as to where SOAs are applicable, where they would yield the best results, and where the use of an SOA would be overkill. There are also misconceptions as to what the benefits of using an SOA are, as well as what the potential approaches to realizing an SOA solution are. In fact, there is no clear and consistent understanding about SOA across the different functions within an enterprise such as marketing, sales, delivery team, and so on. Similarly, even within the software industry these misconceptions are present.

This article expresses these misconceptions and areas of confusion in the form of myths and aims to provide a voice of reason and reality in response to these myths.

SOA Solution Overview
An SOA solution refers to a solution built using the concepts of service-oriented architecture. As mentioned earlier, SOA is an architectural concept, and hence to realize an SOA solution, one must map the architecture to an implementation using a specific set of technologies/products/platforms. As with any other solution, an SOA solution is characterized by a set of mandatory (and optional) components. Figure 1 shows the main components of an SOA solution.

A complete SOA solution consists of the following main components:

• Producers: A producer is an entity that offers a specific service or functionality
• Consumers: A consumer is an entity that makes use of the service offered by the producer
• Services: A service is an entity that performs a specific task when invoked
• Contract: A contract or an interface specifies a format in which the data needs to be provided to the service to perform the specific task
• Repository: A repository is a glorified version of a registry and includes the metadata relevant for the solution, namely service, service contract, data/object model, and so on

As Figure 2 shows, the solution to the SOA consists of multiple components - an infrastructure layer, a set of applications, and a set of business processes and best practices. Though the expertise in the SOA architecture is the foundation for the overall solution, the other components, namely the business process expertise and the applications expertise, are absolutely required to arrive at an end-to-end solution to the problem at hand. The SOA principles are applied at each of the layers in the solution to arrive at a complete SOA solution. Only by doing so is it possible to reap the benefits of SOA completely.

Myth #2: SOA is like a product, and can be downloaded for trial
SOA is an architectural approach for building solutions that are loosely coupled in a stepwise, phased manner, resulting ultimately in the realization of a complex, federated, service-oriented enterprise. The business-specific services are initially identified over the SOA architecture, and then mapped to a set of technology-specific implementation architectures for the purpose of realization.

Though SOA concepts are reasonably simple to understand and apply, it is a rather involved process to build an SOA-rich enterprise, covering all aspects of the SOA characteristics. These solutions evolve over time, and they need to be crafted carefully and jointly along with the customer to ensure that the journey in the SOA architecture evolution is progressing in the "correct" direction. Due to this very nature, many SOA solutions typically do not fall into the category of "products."

Myth #3: SOA is a complete, off-the-shelf solution
SOA solutions are composed of prefabricated building blocks that typically represent the services identified during architecture workshops. The concept of prefabricated building blocks (services) reduces time to market, risk, promotes reusability, and provides a head start. While the generic, technology-neutral SOA approach continues to strive for increasing levels of reusability, the technology-specific SOA solution always requires some degree of customization. The degree of customization is based on factors including if the customer's environment already has a set of services or an environment with different degrees of legacy applications and integrations. The service-oriented approach provides a significant differentiation in building a federated service-oriented enterprise, and helps in realizing the business services reasonably quickly.

Myth #4: SOA software always needs to be developed using Web services
SOA is a technology-neutral architecture, and can be realized using any technology. The selection of technology is performed by considering the various possible factors such as the functional requirements to be addressed, the performance and reliability requirements, the available budget, and so on. Based on these factors, the technology is chosen. Web services offer just one such technology option that is used to realize SOA solutions. However, it is possible to use other alternatives (apart from Web services), and still realize SOA solutions.