File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Web Services and the fly likes SOA example? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "SOA example?" Watch "SOA example?" New topic

SOA example?

Romario Dominic

Joined: Feb 27, 2006
Posts: 26
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.
Masoud Kalali
Ranch Hand

Joined: Jul 08, 2004
Posts: 531

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 :
it has some nice explanation and also a sample.

also for some more papers look at :

Masoud Kalali
Software Engineer - My Weblog - GlassFish Security
Peer Reynders

Joined: Aug 19, 2005
Posts: 2933
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".
    Romario Dominic

    Joined: Feb 27, 2006
    Posts: 26
    Thanks for the reply.I really appreciate it.
    I agree. Here's the link:
    subject: SOA example?
    It's not a secret anymore!