understanding SOA

A service-oriented architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services.

These services have well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) which can be reused for different purposes.

SOA design principles are used during the phases of systems development and integration.

Service-oriented architectures have the following key characteristics:

• SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.
• SOA services communicate with messages formally defined via XML Schema (also calledXSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.
• SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.
• Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.

Benefits of Service Oriented Architecture (SOA):

1. Platform Independence –Since web services can be published and consumed across development and operating platforms, an enterprise can leverage its existing legacy applications that reside on different types of servers and build additional functionality without having to rebuild the entire thing. It also helps an enterprise to integrate its applications with those of its partners.

2. Focused Developer Roles – Since a service is a discrete implementation independent of other services, developers in charge of a service can focus completely on implementing and maintaining that services without having to worry about other services as long as the pre-defined contract is honored.

3. Location Transparency – Web services are often published to a directory where consumers can look them up. The advantage of this approach is that the web service can change its location at any time. Consumers of the service will be able to locate the service through the directory.

4. Code Reuse – Since SOA breaks down an application into small independent pieces of functionality, the services can be reused in multiple applications, thereby bringing down the cost of development.

5. Greater Testability – Small, independent services are easier to test and debug than monolithic applications. This leads to more reliable software.

6. Parallel Development – Since the services are independent of each other and contracts between services are pre-defined, the services can be developed in parallel – this shortens the software development life cycle considerably.

7. Better scalability – Since the location of a service does not matter anymore, the service can be transparently moved to a more powerful server to service more consumers if required. Also, there can be multiple instances of the service running on different servers. This increases scalability.

8. Higher availability – Since the location of a service does not matter and you can have multiple instances of a service, it is possible to ensure high availability.

SOA is a new badge for some very old ideas:

• Divide your code into reusable modules.

• Encapsulate in a module any design decision that is likely to change.

• Design your modules in such a way that they can be combined in different useful ways (sometimes called a "family" or "product line").

These are all bedrock software-development principles, many of them first articulated by David Parnas.

What's new in SOA is

• You're doing it on a network.

• Modules are communicating by sending messages to each other over the network, rather than by more trandtional programming-language mechanisms like procedure calls. In particular, in a service-oriented architecture the parts generally don't share mutable state (global variables in a traditional program). Or if they do share state, that state is carefully locked up in a database which is itself an agent and which can easily manage multiple concurrent clients

http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html?page=3