Previously applications were considered as an isolated entity. They reside on on machine and do not have much ability to communicate with other applications. This lead to the following problems.
1. There was no reuse of the same functionality present in different applications.
2. The applications once deployed have very less chance of changing or updating there functionality.
3. If solid small applications are created with robust testing and they group together to create a composite application, then the chances of them being buggy is minimized.
The idea behind the SOA architecture is that there will be lot of small modular applications which can be called by a composite application on a service basis. This composite applications decides on the services it needs and then groups together all this small applications and gets its job done by delegating tasks to each of these applications. As an example:
A train carrying tourist is traveling between two cities through a scenic terrain and depending on the weather it has the option to decide on multiple pathways. The train can achieve this dynamic calculations of the path by having a software on board the trains computers which determine the weather outside and then do the calculation or it can just call a service running somewhere on the internet and this tells what path it should take.
The problem with the application in the onboard computers is that if there is a change in the pathway, like addition of a new path or closing of a old path, the software needs to be updated on every train that runs in this route, whereas if the train is just using a service then you just update the service once and all the trains will get the correct and up to date information.
Another advantage is that this weather service can also be shared by other people including sports team who are trying to schedule a outdoor event. They could just reuse the weather module of the service instead of writing a new application for that.
SOA solves thses problems.
1. There was no reuse of the same functionality present in different applications.
2. The applications once deployed have very less chance of changing or updating there functionality.
3. If solid small applications are created with robust testing and they group together to create a composite application, then the chances of them being buggy is minimized.
The idea behind the SOA architecture is that there will be lot of small modular applications which can be called by a composite application on a service basis. This composite applications decides on the services it needs and then groups together all this small applications and gets its job done by delegating tasks to each of these applications. As an example:
A train carrying tourist is traveling between two cities through a scenic terrain and depending on the weather it has the option to decide on multiple pathways. The train can achieve this dynamic calculations of the path by having a software on board the trains computers which determine the weather outside and then do the calculation or it can just call a service running somewhere on the internet and this tells what path it should take.
The problem with the application in the onboard computers is that if there is a change in the pathway, like addition of a new path or closing of a old path, the software needs to be updated on every train that runs in this route, whereas if the train is just using a service then you just update the service once and all the trains will get the correct and up to date information.
Another advantage is that this weather service can also be shared by other people including sports team who are trying to schedule a outdoor event. They could just reuse the weather module of the service instead of writing a new application for that.
SOA solves thses problems.
Powered by ScribeFire.
No comments:
Post a Comment