What is Service-Oriented Architecture?

Service Oriented Architecture or SOA for short is a new architecture for the development of loosely coupled distributed applications. In fact service-oriented architecture is collection of many services in the network. These services communicate with each other and the communications involves data exchange & even service coordination. Earlier SOA was based on the DCOM or Object Request Brokers (ORBs). Nowadays SOA is based on the Web Services.

Broadly SOA can be classified into two terms: Services and Connections.

Services:
A service is a function or some processing logic or business processing that is well-defined, self-contained, and does not depend on the context or state of other services. Example of Services are Loan Processing Services, which can be self-contained unit for process the Loan Applications. Other example may be Weather Services, which can be used to get the weather information. Any application on the network can use the service of the Weather Service to get the weather information.

Connections:
Connections means the link connecting these self-contained distributed services with each other, it enable client to Services communications. In case of Web services SOAP over HTTP is used to communicate the between services.

Technologies Used:
SOA is much different from point-to-point architectures. SOA comprise loosely coupled, highly interoperable application services. These services can be developed in different development technologies (such as Java, .NET, C++, PERL, PHP), the software components become very reusable i.e. the same C# (C Sharp) service may be used by a Java application and / or any other programming language. WSDL defines an standard, which encapsulates / hides the vendor / language specific implementation from the calling client / service.

SOA Peek

SOA by philosophy helps achieve an environment which has independent services, which can be utilized without the knowledge of underlying implementation.

Nice tour on SOA by SUN :

http://www.sun.com/software/media/flash/tour_soa/index.html?intcmp=75


The advantages we can derive from this approach:

1) Classes will not be scattered across the application.
2) Developer can focus more on a particular entity, and has clarity of its purpose.
3) Programming to interfaces is achieved.
4) Debugging time reduces, as the developer knows which module to look for, pin point root cause and fix the bug, thus reducing response time.
5) Major changes can be done easily, thanks to the API based approach; we need to only find the dependent module which uses the APIs of the affected module. Reducing response time in impact analysis and estimation.
In case there is a change in the method signature, the API change notification can be sent across modules.
6) Each module can be treated separately, helping us to achieve good Unit Test capability.
7) Modules that are dependent on services of another module need not worry about the underlying implementation, as only the API`s would be exposed.
8) The build system can have separate builds for each module (micro level), which can give us a good idea of the sanctity of the module, in production mode, where there are daily commits, ensuring that the module does not fail or even if it fails, tracking the bug will be easy.
9) The build system can have a continuous integration (macro level), where it will be easy to detect because of which module the product as a whole fails.
10) The above two points will ensure that the application is always in a stable state, and if there are any surprises, they can be handled easily.

Treating each module as independent, we can have a loosely coupled application which can incorporate future modification (in terms of business meaning) or addition of a new feature with ease.

In brief, we have
1) Reuse, granularity, modularity, composability, componentization
2) Compliance to standards
3) Services identification and categorization, provisioning and delivery, and monitoring and tracking

This approach would help us in having:
1) Service Encapsulation
2) Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other
3) Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world
4) Service reusability - Logic is divided into services with the intention of promoting reuse
5) Service composability - Collections of services can be coordinated and assembled to form composite services
6) Service autonomy - Services have control over the logic they encapsulate
7) Service optimization - All else equal, high-quality services are generally considered preferable to low-quality ones
8) Service discoverability - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms (In our case API`s)

Below is a small sample package structure for reference :
When we design class, we need to make sure that the designed class serves a specialized purpose i.e. the business meaning it has, while loosely coupled to classes that uses its service.
Consider a scenario where the modules are cut across services:
The services of all the entities are clubbed in the service package, with the implementation classes in impl package,

Even though “programming to interfaces”, has been practiced, we cannot treat modules or any other entity as truly independent, since the module itself has been cut across the layers.







Check out the SOA way at micro level :
Consider the new approach that would help us achieve SOA:

Here we can see that, there is clear separation of concern and the service has cut across the module, if we treat each entity as an independent object, we are on our way to achieve SOA.