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.