CSC/ECE 517 Fall 2010/ch6 6j ps

Introduction

Service oriented architecture is an architectural approach for building and integrating software applications.In SOA approach each application is broken down into many service and these services can be used to build an entire system.For example banking software which does all sort of operations like telling the balance of account holder, depositing money into account annd getting credit history and so on.With traditional architecture. Give one example.

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.

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 is a entity which tells us level of dependancy that exists between program modules.Ideally speaking there should be zero coupling between modules. Based on the level of dependancies 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 recipeint and has very less knowledge of the recipient.

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.