The promise of service oriented architecture is to liberate business from the constraints of technology and unshackle technologists from the chains they themselves have forged. This has major implications both for the business and for the IT that supports the business.
The main purpose of a service-oriented architecture (SOA) is to offer synergy between the business and IT groups in an organization and to offer the organization greater flexibility.
One of the biggest deals in the SOA world is the idea that you don’t throw things out. You take the stuff (software assets) that you use every day — well, the best of the stuff you use every day — and package it in a way that lets you use it, reuse it, and keep on reusing it.
With SOA, these important programs become business services. You end up with one single business service for a given function that gets used everywhere in your organization. With SOA, when you need to change a business policy, you change it in one place and, because the same service is used everywhere, you have consistency throughout your organization.
SOA uses the find-bind-execute paradigm. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.


SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.

SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense that:

• Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.
• Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
• Services can be dynamically discovered
• Composite services can be built from aggregates of other services.
• 
  
  The Enterprise Service Bus (ESB): The ESB is actually an architectural construct that can be designed and deployed in a manner that will parallel the business processes environment. The bus can be implemented in various ways, such as with classical messaging, EAI, and brokering technologies or by using platform-specific components such as the service integration buses in J2EE systems (such as WebSphere Application Server). The ESB can also be a combination of both EAI and application server technologies, but the implementation should not affect the overall architecture. The selection between possible implementations will be the result of an initial architecture assessment, including existing IT infrastructure, skills, and processes in the evaluation.
  
  Mediation in an ESB enables the intelligent processing of service requests and responses, events, and messages. These mediations can be implemented at application service endpoints (either requestor or provider) or can be distributed through the infrastructure of the bus.
  
  Mediation capabilities include the following:
  
  Transformations: XML-to-XML translations, database (DB) lookups, and aggregations.
  
  Message validation: This can consist of verification of any data field or a combination of fields with specific rules.
  
  Content or quality service selections: This requires a service selection based on content or on required quality of service. As an example, a priority customer should probably be routed to a higher throughput server than others of lesser priority.
  
  Content-based routing: As an example, if the service parameters contain some country information, the request can be routed to a provider in that country.
  
  Customized logging: This is a legal requirement that might ask for logging and audit tracks of the services interactions. Mediation is potentially a good place for this purpose.
  
  Metering and monitoring: A bus should have all of the manageability anchor points to enable control of its behavior and of the integrated services.
  
  Autonomic behavior: This is used to react when events are detected—to self-configure, heal, optimize, and so on.
  
  Policy management: This allows a description of all of the behavior rules that are required for the previous items in this list through externalized policies based on XML.
  Mediators are intermediary components that operate on logical Web service SOAP message representations between the requestor and the provider. These mediator components can be located close to requestors, providers, or halfway between both requestors and providers as true intermediaries. SOAP messages usually contain a header that has to be processed by the mediation handlers, but mediation can be used for purposes other than just SOAP processing and routing.
  You can implement an ESB in many different ways. It is important, however, to reuse whatever standard infrastructure services already exist, ensuring compatibility and reliability. Thus, in a best-practice-based implementation, mediators should use the standard Java Web services SOAP-handling standard: JAX-RPC. This standard provides access to the SOAP headers via the handler API and can be hosted in a J2EE application server infrastructure. Handlers can be easily chained in series and reused across systems. In addition, using embedded mediations, the ESB supports a broad spectrum of ways to hop on and off the bus. The ESB includes business connections that enable external partners in B2B interaction scenarios to participate in the service interaction flows. In this B2B case, it provides the additional mediations and security that external access imposes. Mediation on the protocols that attach to the bus enables the connectivity with existing service-oriented components. These protocols include CORBA, RMI/IIOP, TCP/IP, JCA, native JMS, and other Java protocols.
  A Web services gateway is an additional component of a bus that provides controlled access to the bus for external partners, hiding details of individual internal services, validating user access, controlling access, and auditing requests. The gateway uses core bus components such as mediation and security to implement its routing and management services.
  
  Because business processes are essential to the SOA approach, the model must also integrate an additional standard for this aspect: the Business Process Execution Language (BPEL). BPEL is used by business analysts to model the business processes and by programmers to implement the choreography of services.