Introduction
I would like to begin to determine what SOA (service-oriented architecture) is technically meaning. We can clearly say SOA is a methodology for designing software architectures to utilize and organize distributed systems using loosely coupled software services. Most confusing define of SOA is equaling it with Web Services or if any architecture uses Web Services thinking it is a SOA, which both are wrong. Using Web Services does not make an architecture service oriented. A service-oriented architecture is not limited to a specific technology. SOA may be designed using a wide range of protocols, such as Web Services, RPC, DCOM, CORBA or REST as well as multiple programming languages.
At this point loose coupling comes to the picture. We should clearly understand what is loosely coupling mean from architectural perspective. Then it will help us to determine SOA properly. What can help to make an architecture loosely coupled? Perhaps we can say a Web Service will be very helpful but it will be very limited comment to describe this relation. We should say using services would help to build loosely coupled systems.
Let us describe how SOA reach loosely coupling between interacting systems. Here are two architectural constraints that explain this perceptibly:
A small set of simple and widespread interfaces to all systems. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.
Generic messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.
Because SOA is very loosely coupled, it provides us numerous flexibility as well as deployment and regulation, the capability to reuse common components across a large number of domains.
Loose coupling is platform free as well as a state, which the impact of change is minimized across dependencies. In addition, loosely coupling is an approach where integration interfaces are developed with minimal assumptions between the sending/receiving components, which are reducing the risk that a change in one application/module will force a change in another application/module. In addition, loose coupling of services can be improved by reducing the information passed into a service to the key data.
On the other hand, an SOA can also contain a service, which provides a directory or registry of services. The registry comprises information regarding the service for instance its interface. A client can discover services by examining the registry. A registry can also be coupled with a repository component, which stores supplementary information about each service. This extra "metadata" can contain business process information such as policy statements.
Why SOA
Currentley there are many reasons for an architect to take an SOA approach. First of reusability is biggest advantage, interoperability is another as well as scalability and flexibility. Additionally to these four we can say cost efficiency is an important reason for enterprise architects. At the second part of this article, we will discuss and talk in depth these four main items as well cost efficiency.