SOA means that you have some *services* which works together to bring another purpose. services should be self contained ,..... There should be a service broker , some recovery mechanism,.... so,if you build one service , for example using xml-ws, you have just one service. To demonestrate a soa for example to your professor or .. you should build and show all soa elements. i suggest you take a look at : http://www.onjava.com/pub/a/onjava/2005/01/26/soa-intro.html it has some nice explanation and also a sample.
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?
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.
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 Architectural composability
fosters inherent reusability
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".