About Oracle SOA

Service-Oriented Architecture

While using Web services allows you to achieve interoperability across applications built on different platforms with different languages, applying service-oriented concepts and principles when building applications based on using Web services can help you create robust, standards-based, interoperable SOA solutions.

It is interesting to note that Service-Oriented Architecture, while providing architectural foundation for building service-oriented solutions, is not tied to a concrete technology or technology set. In contrast, it may be implemented with various technologies, such as DCOM, CORBA, or Web Services. However, only the Web Services technology set is currently the primary way to put SOA into practice.

Basic Principles of Service Orientation

As mentioned, to build an SOA solution based on Web services, you need to follow the service-orientation principles when pulling the services together into an application. Here are some of the key principles of service-orientation you need to keep in mind when designing SOA solutions:

• Loose coupling represents a relationship that allows the underlying logic of a service to change with minimal or no impact on the other services utilized within the same SOA. Loose coupling is the key principle of service orientation. Implementing services as loosely coupled pieces of software allows you to keep up with the other key principles of service orientation, such as service reusability, service autonomy, and service statelessness.
• Service contract represents service descriptions and other documents describing how a service can be programmatically accessed. In the Binding with WSDL section earlier in this article, you saw an example of a WSDL service description document that describes a service, defining the contract for that service.

Binding with WSDL

Looking through the SOAP request message discussed in the preceding section, you may notice that it carries only the parameter for the getOrderStatus function exposed by the service. The message doesn't actually contain any information about how to get to the service, what remote function is to be invoked, and what that function is to return. Obviously, there must be another document that describes the Web service, providing all this information to consumers of the service. Web Services Description Language (WSDL) provides a mechanism to describe Web services, making them available for external consumption. A WSDL service description is an XML document that defines how to communicate with the Web service, describing the way in which that Web service has to be consumed.

For detailed information about WSDL, you can refer to the WebServices Description Language (WSDL) W3C Note available at.

Actually, a WSDL service description document consists of two parts: logical and physical. The logical part of a WSDL describes the abstract characteristics of a Web service and includes the following sections:

WSDL basics

A WSDL definition is an XML document with a root definition element from the http://schemas.xmlsoap.org/wsdl/ namespace. The entire WSDL schema is available at http://schemas.xmlsoap.org/wsdl/ for your reference. The definitions element can contain several other elements including types, message, portType, binding, and service, all of which come from the http://schemas.xmlsoap.org/wsdl/ namespace. The following illustrates the basic structure of a WSDL definition:

<!-- WSDL definition structure -->

<definitions

   name="MathService"

   targetNamespace="http://example.company.com/tempService/"

   xmlns="http://schemas.xmlsoap.org/wsdl/">

   <!-- abstract "interface" definitions -->

   <types> ...

   <message> ...

   <portType> ...

   <!-- concrete "implementation" definitions -->

   <binding> ...

  <service> ...

</definition>

The following table briefly defines these basic WSDL elements and the following sections discuss them in more detail:

Element Name	Description
types	Container for abstract type definitions defined using XML Schema.
message	Definition of an abstract message that can consist of 0 or more parts, each part can be of a different type.
portType	Abstract set of operations supported (commonly known as an interface). Operations are defined by an exchange of messages.
binding	Concrete protocol and data format specification for a particular portType.
service	Collection of related endpoints, where an endpoint is defined as a combination of a binding and an address (for example, http://my.company.com/webservices/getTemp).

The first three elements, types, message, portType (especially operations), are all abstract definitions of the web service interface. These elements constitute the interface that you interact with as an ESB developer. Variable to parameter mapping is all done at this level and saved in a web service call (an ESBWS file).
The last two elements, binding and service, describe the concrete details of how the abstract interface maps to messages on the wire. The details of how to actually send the messages are handled by the SonicESB web service invocation framework. SonicESB supports the normal SOAP bindings and SOAP addresses (for example, http: or https: URLs) as well as a special ESB binding that is optimized for message transport to services with JMS destinations or ESB entry endpoints. Other types of bindings are not supported by Sonic ESB.

• types is an optional section in which you can define types for the data being carried, normally using the XSD type system.
• message contains one or more logical parts representing input and output parameters being used with an operation.
• Definition of an abstract message that can consist of 0 or more parts, each part can be of a different type.
• operation describes an action performed by the service, specifying input and output messages being used as parameters of the operation.
• portType establishes an abstract set of operations supported by the service.
• Abstract set of operations supported (commonly known as an interface). Operations are defined by an exchange of messages.
• binding associates a concrete protocol and message format specifications to operations and messages defined within a particular port type established in the logical part of the document.
• Concrete protocol and data format  specification for a particular portType
• service contains one or more port elements representing related endpoints.
• Collection of related endpoints, where an endpoint is defined as a combination of a binding and an address 

• port estlishes an endpoint by associating a binding with a concrete network address.

Turning back to the example discussed in the preceding section, the WSDL description document that describes the Web service exposing the getOrderStatus function might look like the following:

<?xml version="1.0" encoding="utf-8"?>
<definitions name ="poService"
             xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns="http://schemas.xmlsoap.org/wsdl/"
        targetNamespace="http://localhost/WebServices/ch1/poService">
    <message name="getOrderStatusInput">
        <part name="body" element="xsd:string"/>
    </message>
    <message name="getOrderStatusOutput">
        <part name="body" element="xsd:string"/>
    </message>
    <portType name="poServicePortType">
        <operation name="getOrderStatus">
           <input message="tns:getOrderStatusInput"/>
           <output message="tns:getOrderStatusOutput"/>
        </operation>
    </portType>
    <binding name="poServiceBinding" type="tns:poServicePortType">
        <soap:binding style="rpc"
                transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="getOrderStatus">
           <soap:operation
               soapAction=
                 "http://localhost/WebServices/ch1/getOrderStatus"/>
           <input>
                <soap:body use="literal"/>
           </input>
           <output>
                <soap:body use="literal"/>
           </output>
        </operation>
    </binding>
    <service name="poService">
        <port name="poServicePort" binding="tns:poServiceBinding">
           <soap:address
               location=
                 "http://localhost/WebServices/ch1/SOAPserver.php"/>
        </port>
    </service>
</definitions>)

• Abstraction of underlying logic means that a service publicly exposes only logic described in the service contract, hiding the implementation details from service consumers. This means that services interact with each other only via their public interfaces. As you learned in the preceding example, the WSDL descriptor describing a service actually provides the interface for service consumers.
• Autonomy means that services control only the logic they encapsulate. Dividing application logic into a set of autonomous services allows you to build flexible SOA solutions, achieving loose coupling, reusability, and composability.
• Reusability in service-orientation is achieved by distributing application logic among services so that each service can be potentially used by more than one service requestor. Building reusable services supports the principle of composability.
• Composability represents the ability of services to be grouped into composite services that coordinate an exchange of data between services being aggregated. For example, using an orchestration language, such as WS-BPEL, allows you to compose fine-grained services into more coarse-grained ones. WS-BPEL is discussed in the WS-BPEL section later in this article.
• Statelessness means that services don't maintain their state specific to an activity. Building stateless services encourage loose coupling, reusability, and composability.
• Interoperability between services is easily achieved as long as the services interact with each other through interfaces that are platform- and implementation-independent.
• Discoverability refers to standard mechanisms that make it possible for service descriptions describing services to be discovered by service requestors. Universal Description, Discovery, and Integration (UDDI) specification provides such a mechanism, which allows for publishing service descriptions documents in an XML-based registry, thus making them available for public use.

As you can see, most of these principles are tightly related. For example, if you bear the autonomy principle in mind when dividing application logic into services to be utilized within an SOA, you will have reusable, composable, and loosely coupled pieces of software that can be reused in future projects.

On the other hand, ignoring at least one principle of service-orientation makes it very hard to keep up with the others. For example, if you ignore the principle of statelessness when designing services, you will end up with less reusable and less composable building blocks for your SOA solutions.

Applying SOA Principles

• Now that you know the key principles of service orientation, it's time to look at how these principles can be applied when designing SOA solutions. This section briefly discusses process of designing a service-oriented application, applying the service-orientation principles outlined in the preceding section.
• The service-oriented analysis phase is the first one in the process of designing a service-oriented application. Regardless of whether you are going to build an SOA solution upon the existing application logic or build it from scratch, you have to consider the following questions:
• Which services are required to satisfy business requirements?
• How should application logic be divided between services?
• How should services be composed to implement the required SOA solution?
• The easiest way to understand what has to be done at this stage is by taking up an example.
• Imagine you run an online magazine that specializes in publishing technical articles submitted by technical people working on a contract basis. When a potential author submits an article proposal, you look through it and then either accept it or reject it, depending on your current editorial needs and some other things. Here are the general steps you perform upon accepting a proposal:
• Save the proposal in the database.
• Save information about the author (for new authors only).
• Notify the author about accepting the proposal.
• Issue a PO.
• Send the PO to the author.
• Now, suppose you want to design an SOA solution automating this process.
• As mentioned earlier, the first thing you have to determine is which services have to be built. Keeping in mind the service-orientation principles outlined in the preceding section, you might create the following services to be then used as building blocks in the SOA solution being designed:
• Proposal service
• Author service
• Purchase order service
• Notification service

As you can see, the first three services in the above list are entity-centric, representing corresponding business entities.

There are two main approaches for designing services representing business logic: entity-centric and task-centric. While a task-centric service is tightly bound to a specific task and so has a poor chance of reuse, an entity-centric service represents a specific business entity, standing a good chance of being reused in solutions dealing with the same business entity. Both the approaches are discussed in more detail later in Chapter 7 of the book SOA and WS-BPEL, which focuses on issues related to service-oriented business modeling.

An entity-centric service usually provides a full set of operations required to manipulate an instance of a specific business entity. For example, the Proposal service might support the following set of operations to fulfill processing requirements:

saveProposal

getProposalById

getProposalByTitle

getProposalsByAuthor

getProposalsByTopic

Assuming that submitted proposal documents have a certain structure (say, each proposal includes the Topic and Outline sections), the above list of operations supported by the Proposal service might need to be expanded to include some operations responsible for retrieving specific parts of a proposal.

However, it is important to realize that including new operations impacts on the service interface, making you edit the WSDL document describing the service each time you add a new operation. One way to work around this issue is to use parameter-driven operations that invoke the required piece of underlying logic depending on the arguments passed in. In this case, the function encapsulating the underlying logic of a parameter-driven operation delegates the work to some other function where the real work is done.

For example, you might expose a single operation for getting the contents of a proposal, passing parameters identifying whether to find the proposal document by ID or title and which part of the proposal must be returned. In this case, a request message issued by a requestor to invoke the getProposal operation might look as follows:

SOA Compositions

Once you have created all the services needed to automate the process of submitting proposals, it's time to think about how to put them into action.

Actually, there are several ways in which services can be organized to compose an SOA solution. For example, you might create a composite service as a PHP script exposed as a Web service, and which programmatically invokes other services as necessary. However, the most common way to build an SOA composition is by using WS-BPEL, an orchestration language that allows you to create orchestrations—composite, controller services defining how the services being consumed will interoperate to get the job done.

Orchestration

An orchestration assembles services into an executable business process that is to be executed by an orchestration engine.

An assembly of services coordinated by the logic encapsulated in the controller service. This controller service may be a WS-BPEL business process, which when executed against the orchestration engine completes a certain business task. In this particular example, the controller service may be organized so that it completes the steps outlined at the beginning of the preceding section Applying SOA Principles.

Built with WS-BPEL orchestration language, a controller service, like any other service, should have a corresponding WSDL document describing the service to its consumers. Building WSDL definitions for composite services built with WS-BPEL is discussed in the WSDL Definitions for Composite Services section later in this article.

You can create an orchestration to be used as a service within another, larger orchestration. For example, the orchestration depicted in the previous figure might be a part of a WS-BPEL orchestration automating the entire editorial process—from accepting the proposal to publishing the article.

http://en.wikipedia.org/wiki/Service-oriented_architecture
http://docs.oracle.com/cd/E13222_01/wls/docs81/adminguide/overview.html