SOA (Service Oriented Architecture)

Example :

A company sells electronics items through an online store. After a few months of successful sales, The Company then wants to add new shipping options. A SOA shipping component makes adding the new shipping options as easy as checking a few boxes in an administrative control panel. Initially, the company only offered e-mail support, but later decides that adding phone support would be beneficial. A phone support component allows the phone representatives to look up customer orders the same way the e-mail support specialists could.

Goal of SOA :

SOA is not dependent upon any particular programming language, and a service written in one language should be able to interact with another service written in another language, assuming they both adhere to open standards. Each service operates autonomously without any awareness that other services exist. Communication among the services is accomplished using standard protocols. The services are without memory--they do not remember previous transactions. The services are also discovered by means of a common services registry.

When businesses grow, they often add new products and services. While these additions may help make the business larger, it is often difficult to implement them in an efficient manner. The goal of SOA is to make it easy for businesses to grow and add new services.

Basically, SOA makes it possible for a business to add new features and services without having to create them from scratch. Instead, they can be added or modified as needed, making it simple and efficient to expand the business. Because many products and services are now offered via the Web, most SOA solutions include Web-based implementations.

SOA is the continuation of the concept of "loose coupling," a principle that has a long history in software engineering. A software item that exhibits loose coupling performs a single function, independent of other functions, with a well-defined interface. This is the concept inherent in the rise of structured or modular programming in the 1970s and object-orientation in the 1980s. The rise of SOA in the early part of this decade is a further evolution of this concept, greatly aided by the introduction of open standards, such as XML and SOAP.

SOA provides benefits to organizations by better enabling integration of disparate systems, increasing software reuse, and by allowing new applications to be developed more quickly.

The goal of SOA is to develop modular applications consisting of independent services, each fulfilling a purpose and all compatible with each other. Below is a diagram of a very simple SOA.

A user makes a request to the website's front-end, which communicates with back-end services in order to get whatever information is required. These back-end services may in turn communicate with each other in order to complete the response to the data request they've received.
With this high degree of modularization comes a great amount of freedom: individual members of a team can create services and maintain them themselves, leading to clearer boundaries and easily balanced workloads. The developer can also choose the best tools for the job: services written in Python or Perl will happily talk to others written in .Net, completely oblivious to the fact. They can be re-used and recycled as needs be, and can of course be easily migrated to isolated servers, if they're resource-intensive.

Advantage :

Flexibility in planning and tool choice, re-usability, independence.
Scalability is one of the primary advantages of the SOA.
First users away as you spend your time frantically re-designing and re-factoring code.
While suffering a little performance hit from the beginning, focus your talents on adding more features to a modular system as it scales well to growing demand, letting your users enjoy a pleasant.

Dis-Advantage :
One considerable disadvantage is the complexity of your typical service-oriented architecture.
If done right, laying the foundations for a service-oriented project will most likely take longer than it would if a more monolithic approach were taken.
The actual performance of the website will take a hit too. As the number of web services increases, so too does the amount of overhead.