Originally posted by Romario Dominic:
If I write a webservice in Tomcat would that be a demonstration of SOA?After all isn't that service accessible to the world?
Pls advise.
No. That is simply a web application that happens to have a web service interface - it's only accessible to the world if you put it on the internet.
A Services Oriented Architecture (SOA) does not have to be based on web services and it doesn't have to be accessible to the world. Web services are simply an enabling technology for SOA as they make it possible for heterogeneous platforms to communicate with one another.
Thomas Erl in
Service-Oriented Architecture : Concepts, Technology, and Design lists the principles for Fundamental/Primitive SOA as:
loose coupling - Services maintain a relationship that minimizes dependencies and only requires that the retain awareness of one another service contract - Service adhere to a communications agreement, as defined collectively by one or more service descriptions and related documents autonomy - Services have control over the logic they encapsulate abstraction - Beyond what is described in the service contract, hide the logic from the outside world reusability - Logic is divided into services with the intention of promoting reuse composability - Collections of services can be coordinated and assembled to form composite services statelessness - Services minimize retaining information specific to an activity discoverability - Services are designed to be outwardly descriptive so that the can be found and assessed via available discovery mechanisms He then adds the characteristics that "contemporary SOA" expands on.
Contemporary SOA
increases Quality of Service. is fundamentally Autonomous is based on Open Standards supports Vendor diversity fosters intrinsic interoperability promotes discovery promotes federation promotes Architectural composability fosters inherent reusability emphasizes extensibility supports a service-oriented business modeling paradigm implements Layers of abstraction promotes loose coupling throughout the enterprise promotes organizational agility Web service technologies enable and support some of these characteristics but not all of them - and they usually do not guarantee that you will achieve an objective in an optimal fashion. For example, while services can be loosely coupled, a particular (attempt at) SOA design could in fact create tightly coupled services because of improper partitioning - i.e. the individual "services" just don't do enough and too much detailed data is shared between them. It is important in a Service Model to identify the right service (business process) boundaries, just as it is important to identify the "right" domain objects in an Object Model. And the Service Model is most definitely different from the varying Object Models as the services operate on a much higher level (coarser granularity). This doesn't imply that services
exchange objects either. Services simply exchange messages/information. In many cases each service will have a different domain model internally; a domain model that is uniquely suited to the business process that it represents - that's why you need loose coupling between services. If you exchanged domain objects, you may be heading towards tight coupling. It doesn't matter if you choose the "right" technologies to implement your SOA - the "wrong" service partitioning can still be implemented with potentially disastrous results.
Choosing web service technologies doesn't automatically make it SOA, nor is it a guarantee that a particular SOA implementation will exhibit all the desired characteristics of SOA.
A bunch of applications with Web Service interfaces does not constitute a "Service Oriented Architecture".