Service Oriented Architecture is a way of using software modules that exist somewhere else on a network and that are explicitly made available in the form of “services” for use by others.

The term Service Oriented Architecture (SOA) is a little bit misleading because SOA is not an “architecture” per se. It is only a particular style of defining and structuring software functionality in terms of services.

Why SOA?

The reason that we want someone else to do the work for us is usually one or both of the following:

1. They are experts and can do a better job than if we were to do it ourselves.
2. They are available and already know the job. So instead of us learning to do the job and doing it ourselves, it is easier, faster and cheaper to employ the other person to do it for us.

The same reasons justify the use of SOA:

1. The “services” already know how to perform a business function that we want to execute.
2. The “services” already exist and are available. So instead of us learning how to code the business function and doing it ourselves, it is easier, faster and cheaper to simply employ the “service”.

The OASIS² Group defines SOA as follows:

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

If you cut through all the technical definitions of SOA, it all boils down the following characteristics:

• It is a form of application integration, software integration, module integration – call it by whatever name, it is about integration! It is software modules provided for integration as “services”.
• Business functionality is made available to the world over a network in the form of “services” (e.g., invoice printing service) and any external system on that network can utilize those “services” using the proper protocol.
• The right protocol involves a way of packaging data for exchange (usually XML) and a way of transmitting that package to and fro between the service requestor and the service provider (usually HTTP).
• “Loose coupling” (i.e., internal knowledge not necessary) is a necessary quality of SOA because how the service is rendered is a blackbox to the requestor of the service. All the requestor needs to know how to request the service and how to get back the results. In this respect, SOA is very similar to the “methods” in object orientation.
• SOA is another way to re-use software that already exists. From this angle, again, it is an extension of object orientation beyond objects and into services.
• SOA operates across operating systems and across operating platforms, as long as these platforms are connected via a network. So software running on a Mac computer can utilize a service running on an IBM Mainframe and not even have to know that it is running on an IBM Mainframe.
• Underlying and enabling all of this requires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them.
• While there are similarities between Object Orientation and SOA, The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together.

1. Obtain the relevant data from the database.
2. Compute the Subtotal, Tax and Total Amount Due.
3. Format the information in the desired manner.
4. Create a PDF file.
5. Send the PDF to the designated printer for printing.

1. We could bundle ALL of the above as an “Invoice Printing Service”.
2. We could create two services out of the above:
   • An “invoice creation service” that takes care of Steps 1-3.
   • A “printing service” that takes care of Steps 4-5.
3. Or, we might even create five different services – one for each step listed above.

• The smaller (i.e., more granular) we make the services, the greater the opportunity for their re-use.
• For instance, a generic “printing service” could be utilized by many more programmers than only those looking to print an invoice.
• Making services more granular also improves separation of concerns. For instance, the service that accesses data from the database can focus only on that task instead of also having to know how to create a PDF and send it to the printer.
• Smaller services are also promote flexibility of use. The user has greater freedom is combining the mix of services that is just right for his needs.

• Smaller services make maintenance and governance more difficult. Instead of having to maintain one program, now one has to maintain and govern multiple programs.
• Smaller services also make testing more difficult.
• Most importantly, the use of multiple smaller services instead of one large service degrades runtime performance.
• Smaller services also increase network load, because now many more messages have to exchanged between many more services in order to achieve the same task that might otherwise have been achieved by one service and one message exchange.

• Service encapsulation: Business functions are encapsulated as services.
• Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
• Service contract: Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
• Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.
• Service reusability: Logic is divided into services with the intention of promoting reuse.
• Service composability: Collections of services can be coordinated and assembled to form composite services.
• Service autonomy: Services have control over the logic they encapsulate.
• Service discoverability: Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.
• Service relevance: Functionality is presented at a granularity recognized by the user as a meaningful service.

The services themselves are usually written in traditional languages like C#, C++, Java, C, COBOL, etc.

Gartner analysts call this Advanced SOA and refer to it as "SOA 2.0".

1. The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web (abbreviated WWW or W3). Founded and headed by Sir Tim Berners-Lee, the consortium is made up of member organizations which maintain full-time staff for the purpose of working together in the development of standards for the World Wide Web. W3C also engages in education and outreach, develops software and serves as an open forum for discussion about the Web.
   
   
2. The Organization for the Advancement of Structured Information Standards (OASIS) is a global consortium that drives the development, convergence and adoption of e-business and web service standards. Members of the consortium decide how and what work is undertaken through an open, democratic process. Technical work is carried out under the following categories: Web Services, e-Commerce, Security, Law & Government, Supply Chain, Computing Management, Application Focus, Document-Centric, XML Processing, Conformance/Interop, and Industry Domains.