There has always been much hype and misconceptions about service oriented architecture(SOA).To be frank there is no unanimous agreement among SOA experts and authors on what and how SOA needs to be defined and boundaries of it.However let me define it in my own way-SOA is an architecting style to design computer applications to achieve certain design goals.
Now let us see what the goals are.
Design goals
- Loosely fashioned interacting software agents
- Easy integration among disparate software components
- Reusing software components
- Composability
- Technology neutral
- Rapid application development
The basic building block of SOA is service. In simple words service can be any business function designed to do unit of work. For example service can be a pure C- language funtion, C++ method, Pl/SQL procedure or java application with certain characteristics.
A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.
Let us talk about a scenario where business has multiple applications running implemented in various technologies. If he wanted to integrate all of them, then the option he has in his hand is recruit multiple consultants who understands all these technologies which forces business to shell out lot of money.
In contrast, if all these applications have been designed following SOA then all he need is one consultant who knows SOA.
Many more can be added but I want to keep the list short, precise and meaningful.I am sure all the traditional application development approaches like OOPS, distributed components like EJB, DCOM and CORBA must have struggled to achieve same goals but they were successful only in achieving few of goals but not all.That means SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures.
In nut shell-It aims at coming up with a software design in such a way that all business functionality can be implemented in set of reusable technology neutral software units with de-couple fashioned communication among them.
How SOA changes next generation of application development
It impacts many phases of a typical SDLC. We need to revise the way we used to follow to design pre-SOA applications.Some enterprise architects believe that applications developed using SOA gives lot of business agility which helps in reacting to business changes as quickly as possible and incorporate those changes in services and be at the edge of nowadays competition.If a business wants to develop a new application, what all they need to do is choose already built in-house/third-party software services, compose and orchestrate them. This paradigm greatly reduces time to 'develop to deploy' cycle.
SOA Business also has an option of choosing their own technology to implement the services. This allows coding the logic in a technology that best fits.
When started adopting SOA it is going to take more time to realize SOA benefits because initially you need spend time to identify what functionality needs to be defined as a separate service called granularity level.Once business is done with this activity, then next step would be pick those services and build new ad-hoc applications.
A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.
Let us talk about a scenario where business has multiple applications running implemented in various technologies. If he wanted to integrate all of them, then the option he has in his hand is recruit multiple consultants who understands all these technologies which forces business to shell out lot of money.
In contrast, if all these applications have been designed following SOA then all he need is one consultant who knows SOA.
Many more can be added but I want to keep the list short, precise and meaningful.I am sure all the traditional application development approaches like OOPS, distributed components like EJB, DCOM and CORBA must have struggled to achieve same goals but they were successful only in achieving few of goals but not all.That means SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures.
In nut shell-It aims at coming up with a software design in such a way that all business functionality can be implemented in set of reusable technology neutral software units with de-couple fashioned communication among them.
How SOA changes next generation of application development
It impacts many phases of a typical SDLC. We need to revise the way we used to follow to design pre-SOA applications.Some enterprise architects believe that applications developed using SOA gives lot of business agility which helps in reacting to business changes as quickly as possible and incorporate those changes in services and be at the edge of nowadays competition.If a business wants to develop a new application, what all they need to do is choose already built in-house/third-party software services, compose and orchestrate them. This paradigm greatly reduces time to 'develop to deploy' cycle.
SOA Business also has an option of choosing their own technology to implement the services. This allows coding the logic in a technology that best fits.
When started adopting SOA it is going to take more time to realize SOA benefits because initially you need spend time to identify what functionality needs to be defined as a separate service called granularity level.Once business is done with this activity, then next step would be pick those services and build new ad-hoc applications.
How web services and SOA related
There is a myth that both web services and SOA are one and same, in fact both are different but work closely together.Web service talks about exposing a legacy application functionality over the network so that clients can call them to achieve certain business work or unit of work.Web services never talks about software architecting styles. In contrast SOA talks about designing an application with certain characteristics mentioned above. Neither of them replaces another. They simply supplements each other.Web services paves the way to realize and implement SOA and in tern SOA gives best practices and design principles to implement a web service.
SOA Challenges
- Identification and granularity of service
- Performance overhead
- Service meta data maintenance
- Governing services
Given many more advancements in XML standards, process and data standardizations and processing speeds above challenges are no longer be in the list.
In next post we will talk about SOA characteristics and challenges in detail.
No comments:
Post a Comment