Service-oriented architecture, or SOA, is an extraordinary step in the application architecture evolution. In order to solve the problems with today’s component-base architectures, we need to architect systems that expose business logic in a well defined way, adhere to industry standards, and do not require any specific implementation or technology by the calling application.
In other words, we need a mechanism to wrap the business objects and provide a well defined access point for calling applications.
A service-oriented architecture is layered just like the component-oriented architecture. It consists of a data access layer and a business layer. The presentation layer exists, but is not part of the service-oriented definition.Additionally, a service-oriented architecture contains a well defined service interface. This is the access point for all external calling applications. Each method on the service interface has a single, well-defined input parameter and a return type. The service interface method supports a request/response metaphor. The service interface is responsible for controlling access to the business layer. Any applications or other services calling the service interface do not have access to the business layer. This provides a loosely coupled architecture – the service’s implementation can be changed without requiring any changes on the calling application.
A service-oriented architecture solves the following problems:
The service can be deployed to any type of machine.
The service can physically reside anywhere on the network
The service can be developed in any language.
Definition of a Service
We have defined what a service-oriented architecture is, but what exactly is a service within a service-oriented architecture?
A service can be defined as a software system that:
Corresponds to a real-life business activity ( placeOrder or submitClaim )
Is the interface for a business function or functions
Is usually discoverable, but not always
Has a well-defined interface, which is exposed through some sort of contract
Interacts with other services and components using loosely coupled, message based architecture and asynchronous or synchronous access models
Uses industry standards for communications
Is up and running all of the time, versus a component that must be instantiated
Benefits of a Service-Oriented ArchitectureApplications are complex to design and build. Businesses need software to be agile and flexible to ever changing business requirements. Businesses need software to interoperate with other businesses software.
Today’s component-based architectures cannot provide this flexibility and interoperability. Service-oriented architectures, on the other do, provide a flexible and interoperable solution for the agile business.
Service-oriented architectures provide additional benefits by:
Encapsulating complexity – systems are hard to build and very complex. SOA provides the mechanisms to hide the complexity and provide a simple well-defined interface to the business logic.
Providing location independent code – the service can be located anywhere on the network on any machine. Additionally, the service can be written in any programming language. The client does not need to know how the service was implemented and what language was used.
Allowing developer to focus on specific issues – service developers will be concerned with things like transactions and messaging. The client developer only needs to know how to invoke the service.
Allowing parallel development – once a service interface is defined, the service can be implemented in parallel with the client application.
Providing support for multiple client types – different types of clients can access a service. As long as the client is network aware, it can invoke the service. Clients can be web-based, windows-based, console-based, or pda-based type of applications.
Providing a standard place for implementing security