Why SOA?
Due to iterative adoption of technology by organizations, Enterprise Middleware applications needs to co-exist in heterogeneous environments. For any new or old application, one new particulate functionality either had to be redeveloped or reintegrated which throws a situation of multiple version of similar application specification exist within one organization. This puts other operational issues maintenance, version control and patch updates. SOA solved this problem holistically by bring these different applications for similar functionality as a service at one central location and provide interface to all. With this approach, Business Process gets greater alignment between IT and line of business while generating more flexibility by reuseability of existing infrastructure and well defined interface for collaboration between business processes.
I used to think it is more about Web Service communicating with each other over ESB. But when I started to look close, found web service with lots of customized standard from J2EE world.
- Actors - Service Requester and Providers
- Action - Message Exchange
- Medium - Shared transport for message flow
Four major pillars:
- Web Service Description Language (WSDL): It is self explanatory description of service in a platform independent XML file.
- SOAP Messages: It is communication transport layer where business documents are exchanged in heterogeneous environment where providers have very little info about each other.
- Universal Definition, Discovery and Integration (UDDI): An enterprise level service directory/registory to look-up and invoke services.
- Quality of Service (QoS): Service level agreement about security consideration, authentication and authorization standard and reliability of messages in the system
SOA is more than web service. Web service role is to communicate with a service using SOAP/UDDI/HTTP, but SOA needs collaboration infrastructure of enterprise class communication both asynchronous and synchronous. Messaging has been the pick and ESP provides it at enterprise level. It is not mandatory that your SOA has to be ESB based but it suites the bill best. SOA is technology agnostic, therefore, there can't be one vendor providing all the nuts and bolts at least for near future. But SOA will remain at center-point of Enterprise Integration technology.
Pitfalls of SOA?
- To view SOA as an end, rather than a means to an end. Developers who focus on building an SOA solution rather than solving a specific business problem are more likely to create complex, unmanageable, and unnecessary interconnections between IT resources.
- Try to solve multiple problems at once, rather than solving small pieces of the problem. Taking a top-down approach—starting with major organization-wide infrastructure investments—often fails either to show results in a relevant timeframe or to offer a compelling return on investment.
SOA does require people to think of business and technology differently. Instead of thinking of technology first (e.g., If we implement this system, what kinds of things can we do with it?), practitioners must first think in terms of business functions, or services (e.g., My company does these business functions, so how can I set up my IT system to do those things for me most efficiently?).
References:
ToDo:
0 comments:
Post a Comment