CSC/ECE 517 Fall 2010/ch6 6j ps
Introduction
SOA is an architectural approach to creating systems built from autonomous services.SOA brings the concentration to the integration of services to form an application. SOA usually seems like a natural development to all the existing methods to do enterprise wide integration of applications.
Cocepts of SOA like services, discovery and late binding etc are from older middleware solutions like corba. The SOA design principles too are similar to the previously exisiting OOA/OOD techniques like encapsulation, abstraction and well defined interfaces.
Need for SOA??
To appreciate SOA, one should understand the problems faced by current software architectures and problems addressed by Service Oriented architecture. Consider the example of bank.Say the bank is currently handling credit card division , and it developed a software to handle all its transactions. This software developed is a collection and interaction of various modules like getuserinformation, checking balance , check credit card history and process payments and so on .Say at some later point of time, bank started debit card division and again now to handle all its debit card related functionality it need one more software and it does almost have similar functionality as credit card ,with some differences in functionality. Now the possible solutions bank can think in developing the software for debit card division would be :-
- Take same code and make changes to it : The problem with this approach is code duplication and maintainablity.Say if bug crops in one of the module we now need to change at 2 places one in credit card software and another in debit card software.If company thinks of developing the debit card software using new programming language ,then even code reuse is not possible.
- Object oriented approach of inheriting objects: One might say bank can use Object oriented approach and derive class and functionalities and so on.Even then we have problem with this approach, we can't tamper the existing credit card software and even maintainability is problem over here.As discussed previously, if bank thinks of writing new software in different programming language then this solution also gets ruled out.
This is where SOA comes to rescue, SOA approach tells us to make each functionality as a software service .Each service to exploit the functionality of other service communicates to it using languages like 'xml' as compared to function calls in convention programming language.With this approach we have many advantages
- Reusable code in the form of services: Code is reused in the form of services.
- Code is easily maintainable:- as functionality is offered as a service and it is single place .
- Support for legacy functions:We can reuse legacy functions by writing wrapper around the functionality and make it interact with other services using XML.
- Platform and language independant services - as services interact with each other through xml so there is no requirement of both functions in same programming language.
Without SOA
With SOA
Technical jargons associated with SOA
Lets explain this using the above example itself.
- Consumer of Services: - One who uses the services .In the above example, credit card division and debit card division software are the services.
- Service:- Individual functionalities exposed to outside world. In the above example getbalance, Depositmoney are services provided by the banking system.
- Directory services: - After each service is created it registers itself to directory service so that service can be easily located by the consumer of services. whenever consumer wants to utilize the functionality ,he will enquire the directory service and locate the service.
SOA vs Enterprise Architecture
SOA to be understood well in the present scenario is often compared and contraseted with the enterprise architecuture frameworks. We would like to discuss some points about this here. EA is defined as "The EA discipline defines and maintains the architecture models, governance and transition initiatives needed to effectively co-ordinate semi-autonomous groups towards common business and/or IT goals". So SOA is one of many ways of implementing the IT part of the enterprise architecture. They are similar because both these concepts strive to closely align IT with business, they share similar planning and stratagies. The major differences are EA focuses on defining different business components and SOA focuses on providing business services to help these components interact with each other.
Some Key Principles beyond SOA
- Service Loose Coupling - According to this principle service should be designed in such a way that it reduces the dependency of given service on other service.
- Service Abstraction - service should be like a black box, it should hide the implementation details from the outside world.
- Service Reusability - services should be implemented in such a fashion that it should be more reusable.
- Service Statelessness - Service should be implemented in such a fashion that it tries to minimize the amount of state information it store. It should store the state information if its really necessary.
- Service Discoverability - Each service should be associated with meta data, this allows us to discover the service and what it does, its i/p requirements.
- Service Autonomy - For the service to work correctly and reliably it should have some amount of control on its underlying environment.According to this principle only limited autonomy is provided to the service such that it works correctly.
Deep dive into some of the key principles involved in SOA
coupling
Coupling is a entity which tells us level of dependency that exists between program modules.Ideally speaking there should be zero coupling between modules.
Based on the level/degree of dependencies between modules we have different types of coupling like Content coupling (high), Data coupling, Message coupling (low) and
so on.Good service in SOA should exhibit low coupling as in message coupling
a)message coupling' - this is one of the loosest forms of coupling where in the calling function doesn't know the location of the recipient and has very less
knowledge of the recipient.
cohesion
Another important concept that need to be discussed with respect to SOA is cohesion.Cohesion tells us about how the parts/sections in the service are related to
each other.Ideally modules should have very cohesion.Good service in SOA should exhibit one of the following types of cohesion:
a)Functional Cohesion: Here module does only one thing , such type of services are highly reusable.
b)Sequential Cohesion: module does several tasks and that must be in order.
c)Communication Cohesion: when a module carries out multiple operations based on the same input, but which do not have any prescribed ordering requirements.
In Summary ,service we design should have loose coupling and have high cohesion.
Design Patterns associated with SOA
Now Lets study some of the design patterns associated with SOA:-
- The Document Processor: The document processor pattern solves the problem of providing a simple and well-defined contract for a service. A contract as mentioned earlier needs to be granular and very well-defined so that no assumptions about its capabilities need to be made. This can be done by using the OOA/OOD principle of "program to an interface". In a service scenario this would mean define the contract first. That is to define a XML schema to request and the response message, then based on this schema the implementation needs to be done.
- The idempotent message: This design pattern solves the generic problem of multiple deliveries of the same request where a single request needs to be sent. This is usually observed in transition based systems. To ensure impotency the service contract should be designed in such a way that a unique identifier should be tagged per request. Although unique identifier for each request is part of the agreement it should not assumed that these numbers will remain unique over time. The identifier should be considered as a unit of work and work should be performed once for each unique identifier. Duplicates can be handled in many ways depending on the system
- Reservation: This problem solves the problem of maintaining data consistency for long running transactions. We take an approach of creating tentative operations so that database still remains consistent but still we keep a record of ongoing transactions. These tentative operations can go thorough one of these paths. First one is where it operation is completed as all the required messages are completed and the database is updated. The operation is canceled either implicitly due to inconsistency of data etc, or explicitly by the consumer. These services should have certain amount of service levels(time outs) which are explicitly mentioned in the contract and the third possibility is that the service get aborted due to service level considerations.
References
- Bloor, Robin, Judith Hurwitz, Marcia Kaufman, and Fern Halper. Service Oriented Architecture . 2nd ed. Hoboken: For Dummies [Imprint], 2009. Print.
- Juneja, Girish. Service oriented architecture demystified . Hillsboro, Or.: Intel Press, 2007. Print.
- Hariharan, Charanya, and Brian H. Cameron. Enterprise architecture & service oriented architecture . University Park, Pa.: Pennsylvania State University, 2009. Print.