During my recent SUN ISV meetings I faced one frequent question on WebServices & SOA…. Is Webservices = SOA or SOA = Webservices. My answers is an immediate NO, NO – followed up by non-stop few mins talk on the differences. Everytime I answered this question I have covered many different topics to delineate and contextify (dont laugh – you can’t find this word in dictionary ) "SOA & Webservices". I feel putting my ideas around this on my BLOG makes more sense for a wider distro when ever I require, and my answer starts like this ….
    
    The essential feature set of SOA is having a bigger context and bigger requirements than the feature set offered by Webservices. Lets quickly review what are those.

Most of these features can be achieved through distributed component architectures like Webservices, CORBA, COM/DCOM. Certain essentials of SOA like Governance & Standards, Architecture principles, Process & Practice are more to do with People participating in SOA maintenance and also Enterprise business process. Here Governance is a pure form of People’s practice on incubating applications within an enterprise practicing SOA. With this said it looks like we can achieve most important features of SOA through Web-computing Distributed Component architectures like (Webservices, CORBA, DCOM), but the wide acceptance to Webservices happened because of its Open-Standards than CORBA, DCOM.

CORBA, DCOM are tightly coupled with the implementation program that is providing the service is directly associated with the program requesting the service.  This makes the SOA as a proprietary implementation but not OPEN.

Coming back to the topic whether or not SOA = Webservices. It can’t be, as Webservices addresses few challenges to achieve SOA with a careful service composition. Standards based Interoperable Service components composition is very easy and highly valuable with Webservices standards but there is no SILVER BULLET ANSWER from Webservices to address Process orchestration, Process definitions, Service Control, Service Accessibility, Service Composition, Business Activity monitoring and Governance, Event Management etc. Webservices suitability in each and every aspect of SOA is a choice given based on requirement. If there is any other component or tool which fits to the context better than Webservices is definitely adoptable. For example a typical EAI Challenge of "High Volume Data Integration" within an Enterprise off-line process. Given this scenario using an ETL Tool (Extract, Transform, Load tool) than a custom built Webservice is a wise adoption.

 Conclusion - Taking all the Enterprise SOA Challenges if we need to put down suitable component architectures, there is a possibility that Webservice component architecture sits on top of all – but definitely not Everywhere. In a N-Tiered architecture SOA systems Elemental business services may or may not exist with Webservices, Once the Composite applications are built on top of Elemental Business services then the possibility of having Webservices in "Composite Tier" is very high for Webservices. Still depending on requirement elemental business services can be composed with EJB, COM, CORBA, etc component architectures.