SOA - How to implement
Post date: Mar 28, 2012 8:06:34 PM
Discussion on Service Oriented is on for a long time but there are few things which should be taken care and understood at implementation level. As a concept SOA has business context first then technology but how it will be transformed in to technology implementation is also important. Here are few things I would like to discuss.
If SOA is an Architectural Style and only has business vision not technology than I don't have any issue but if it is for your enterprise IT, Infrastructure, Implementation of business requirements in software than I want to raise few questions:-
1. Why it is not yet decided unanimously that what will be and how will be implemented as SOA Service? Even if it is not about implementing the things than it must accommodate any implementation in any flavor.
2. If SOA is going to be implemented as webservices (which people don't agree) then why not people accept it and decide how those webservices will be packaged to make SOA services. Although some efforts were going on to define SOA architecture standard and SOA services/component standards but how many of you know about it, accepted it and implemented it.
3. If SOA is not webservices then how will it be different. What should be packaged inside a service. Single view of customer requirements, complete process coverage which may include definition of process along with components to serve process requirements.
4. What about interoperability, transactions and security?
SOA adoption will take more time if things will not be decided and accepted soon. Specifications should be finalized. Specs are in hands of vendors and they always try to make them complex and difficult so that their business can be accommodated.
I suggest following things:-
1. Make it simple.
2. Don't put very high claims
3. It is only an architecture style like black board, pipe & filter etc so don't make it a new technology. It is to suggest some best practices.
4. Don't confuse people by saying webservices are not SOA (in fact they should not be) but this negative thinking is stopping setting of defacto standards. Promote integration through webservices. They should act as facade for your business services/functionality/process and behind that hide your implementation what ever you want to do with that do that.
5. Still set some guidelines on internal implementation too but it should not be forced. Accept what ever businesses have right now as assets and don't advocate for top level approach always. Definition of interface to out side world can be taken top down but existing assets of an organization can be made better through bottom up approach.