CSC/ECE 517 Fall 2010/ch6 6j ps: Difference between revisions
| Line 42: | Line 42: | ||
* Service Abstraction - service should be like a black box, it should hide the implementation details from the outside world. | * 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 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 | * 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. | ||
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 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 | * 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 | ||
Revision as of 00:41, 16 November 2010
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
- Consumer of Services:
- Service producer:
- Directory services:
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.