To understand how bindings affect our applications, we need to put them into the context of the web services stack. For the purposes of this discussion, we focus only on the exposure of services within the web services stack, ignoring composition of services through BPEL and the service bus.

Logical view of web services stack

A logical view of the web services stack is shown in the following diagram and identifies three key components:

1. A service description layer that provides a consistent view of how services are described. In particular, it must describe what interfaces are supported by the service, what messages are used by those services, and finally how those services are mapped onto physical formats and transport facilities. This role is fulfilled by WSDL, the Web Services Description Language which is covered in more detail in the next section.

2. A message format for transmission of service requests and service responses. This is normally described by SOAP, the Simple Object Access Protocol. However, as the diagram shows, other message formats are possible.

3. A physical transport mechanism for delivery of messages. This may be covered by a SOAP profile, such as SOAP over HTTP (the most commonly used mechanism) or SOAP over FTP. However, it is also possible to have other transports being used with non-SOAP message formats.

The join between the service description layer and the message layer is known as the binding of the service, and specifies how the actual communication protocols are used by the service. This binding provides a wrapper to a physical service implementation, which may be in Java, C#, or some higher level implementation mechanism such as BPEL or a service bus.

We will now look at how the Web Service Description Language (WSDL) describes services, before exploring why we have a need for all these different binding layers. WSDL describes the interfaces supported by a service. It also describes the data they expect to receive and send, and the operations within those interfaces.

How to read WSDL

In Chapter 10, we looked at how to build a WSDL document. It is easy to get confused by all the parts of a WSDL file. Hence, in this section we will look at what they are and how they fit together. The example below shows a sample WSDL file with key elements highlighted. We will look at the basic structure of a WSDL file by examining each element in turn.

<?xml version="1.0" encoding="UTF-8" ?> 
 <definitions targetNamespace="urn:ChangeCurrencyInterface"

xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="urn:ChangeCurrencyInterface"
... >
 <types
<xsd:schema elementFormDefault="qualified">
<xsd:import schemaLocation="OBayCanonical.xsd"
namespace="http://www.obay.example"/>
</xsd:schema>
</types>
 <message name="ChangeCurrencyRequestMessage">

<part name="in" element="ccs:ChangeCurrencyRequest"/>
</message>
 <message name="ChangeCurrencyResponseMessage">

<part name="return" element="ccs:ChangeCurrencyResponse"/>
</message>
 <portType name="ChangeCurrencyPortType">

<operation name="ConvertCurrency">
<input message="tns:ChangeCurrencyRequestMessage"/>
<output message="tns:ChangeCurrencyResponseMessage"/>
</operation>
</portType>
 <binding name="ChangeCurrencyServiceSoapHttp" type="tns:ChangeCurrencyPortType">

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="ConvertCurrency">
<soap:operation soapAction="urn:ChangeCurrencyInterface/ChangeCurrencyService.wsdl/ ConvertCurrency"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
 <service name="ChangeCurrencyService">

<port name="ChangeCurrencyPort"
binding="tns:ChangeCurrencyServiceSoapHttp">
<soap:address location="http://www.example.com"/>
</port>
</service>
</definitions>

<definitions>

A WSDL document is an XML document, and it has a root element called <definitions>. The definitions element provides a wrapper for a set of definitions. The set of definitions may be named through an optional name attribute. The definitions in the document are:

• Types: Used to define content of messages

• Messages: Used to define parameters of operations

• Port Types: Used to define collections of logical operations

• Bindings: Used to define concrete protocols and data formats

• Ports: Used to define concrete endpoints for bindings

• Services: Used to group sets of related ports

The following diagram shows how these definitions relate to each other.

Note

WSDL concepts in a 3GL

It is useful to map WSDL concepts onto a third generation language, such as Java to clarify what they mean.

portType is like a Java interface; it contains operations that are like Java methods.

messages are like the input parameters or return value of a Java method.

binding and service are like a Java class in that they identify a concrete mapping of an interface onto a physical implementation.

<types>

A WSDL document may include a <types> element, which is used to define data types that will be used later. These types are normally described using XML Schema, and may also be brought in from an external XSD file. This is good practice as they may well be reusable in several services. The types element will almost always include an XML Schema document shown as follows:

<types>
<xsd:schema elementFormDefault="qualified">
<xsd:import namespace="http://www.obay.example"
schemaLocation="../OBAYSchema/OBayCanonical.xsd"
/>
</xsd:schema>
</types>

<message>

The types defined are used to create messages defined by one or more <message> elements. Messages are the units of data transfer between service provider and service requestor. Messages are identified by their name attribute. The messages themselves may consist of several parts, identified by the <part> element. Each part is either a type (common in RPC style web services) or an element (seen in doc style web services). Hence parts depend upon the types. These types could include primitive types such as string or int.

Note

RPC and Document Style Web Services

RPC and Document Style refers to the way in which the web service encodes the messages. RPC style expects there to be an element indicating the operation and the data is encoded according to SOAP encoding rules, for example, allowing for cyclic graphs to be passed. Document style expects to pass the messages as XML documents that conform to an XML Schema. Generally doc style are viewed as preferable because of the ability to transform the documents en-route using XSLT transforms. See Chapter 10 for a more detailed discussion of different web service styles.

Parts are identified by their name attribute and will have either an element attribute to indicate the root element of the part or a type attribute to indicate the type of the part.

<message name="ChangeCurrencyRequestMessage">
<part name="in" element="ccs:ChangeCurrencyRequest"/>
</message>
<message name="ChangeCurrencyResponseMessage">
<part name="return" element="ccs:ChangeCurrencyResponse"/>
</message>

A message may have more than one part.

<portType>

The messages are grouped together into exchanges using the <portType> element. A portType defines an interface or abstract service. The portType is identified by its name attribute. Within the definitions element, a portType must have a unique name. Associated with the portType are one or more <operation> elements. Operations are identified by their name attribute. Each operation through the use of an <input> and/or an <output> element specifies a message and its direction. A normal request/reply operation would have an input message followed by an output message. There is also a <fault> element to allow for exceptions to be thrown by an operation.

<portType name="ChangeCurrencyPortType">
<operation name="ConvertCurrency">
<input message="ChangeCurrencyRequestMessage"/>
<output message="ChangeCurrencyResponseMessage"/>
</operation>
</portType>

<binding>

Everything we have discussed so far is abstract, and has no concrete implementation. As we move to the right-hand side of the diagram we move from the abstract to the concrete.

The <binding> element provides a concrete implementation of the abstract portType identified by the bindings type attribute, specifying for example the use of SOAP over HTTP. Bindings are identified by the name attribute. For each operation in the portType there may be a corresponding <operation> tag in the binding that will describe the mapping of the message onto the physical transport mechanism. Operations are identified by their name attribute.

Note that the binding details themselves are in a different namespace. This is because the WSDL specification is extensible to allow for many different kinds of bindings, not just SOAP over HTTP.

<binding name="ChangeCurrencyServiceSoapHttp"
type="tns:ChangeCurrencyPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="ConvertCurrency">
<soap:operation
soapAction="urn:ChangeCurrencyInterface/ChangeCurrencyService.wsdl/ConvertCurrency"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service>

Finally, the concrete service itself is identified by the <service> element. A service groups together a related set of functionality into a logical service implementation. The service is identified by its name attribute. The service is associated with one or more <port> elements. Each port has a name attribute to identify it and in turn it identifies the binding supported by this port through the <binding> attribute. Because the bindings in turn refer to the portTypes, we have a link between the ports exposed by a service and the abstract ports defined earlier in the WSDL. When using SOAP bindings the port also includes an <address> element, which provides the physical endpoint for the port.

<service name="ChangeCurrencyService">
<port name="ChangeCurrencyPort"
binding="tns:ChangeCurrencyServiceSoapHttp">
<soap:address location="http://www.example.com"/>
</port>
</service>

It is worth noting that a service may have multiple ports that use different bindings but refer back to the same portType. This allows the service to have multiple ways of requesting its service. For example, one binding may be through SOAP over HTTP and another may be through a direct mapping onto an Enterprise Java Bean. We will explore this latter possibility later in the chapter.

The binding describes how the abstract XML interface and data type is mapped onto the physical data format and transport. The ability of WSDL to describe different bindings other than SOAP begs the question of why. There are at least three answers to this. Let us look at them in detail.

Java Connector Architecture, JCA, is a standard way in Java to access a wide range of resources. A JCA resource adapter may provide an interface to many different types of resource including databases, packaged applications, and mainframes. Java Enterprise Edition (JEE) containers, such as WebLogic and WebSphere, provide JCA frameworks that allow registered adapters to be made available to hosted components as though they were native container resources. JCA adapters may also participate in transactions.

JCA bindings are probably the most commonly used non-SOAP binding in the SOA Suite. This is because they are used extensively by the adapter wizards to provide access to a wide range of native resources. Generally, the JCA bindings are generated by the wizards with no need for further work by the developer.

JCA bindings actually differ a lot in the way in which they map the WSDL message onto a physical format. But where they are common is in their use of Java Connector Architecture (JCA) adapters to provide the physical wrapper to the service. Across all JCA adapters/bindings the wizard will offer the opportunity to identify a JNDI location for the JCA resource. Either develop your own consistent notation for this or pay attention to the location generated by the wizard.

Most JCA adapters describe both a JNDI lookup for the JCA resource and also embed a description of the JCA resource used to generate the adapter. For example, a database adapter WSDL binding will have a lookup to a JCA database adapter at a specific JNDI location but it will also have a description of the database connection used by the wizard to interrogate the database to build the WSDL.

At run time, the JCA binding will first attempt to find a resource by looking up the JNDI location, for example /eis/DB/MyDB. If this name does not exist, or in other words if there is no resource adapter bound to this JNDI location, then the binding will use the connection properties used by the wizard that have been embedded in the WSDL.

When deploying to any system other than your embedded SOA Suite instance in JDeveloper, it is good practice to ensure that the JNDI location referenced does indeed have a resource of the correct type. It is also good practise to make sure that this is a pooled resource so that resource usage can be monitored and controlled by the application server infrastructure. Configuring of JCA resources is container specific and you will need to consult your container's documentation to find out how to bind adapters to particular JNDI locations.

In Chapter 11, we looked at how to create a Java web service that used SOAP protocols. In this section, we will explore how we can directly access that same Java without the need for using SOAP. This will improve performance as we do not have to send the message over HTTP but instead can invoke the Java directly.

Creating a Java binding

Using the example in Chapter 11, let's create a web service with Java bindings. We begin by right-clicking on the service wrapper class and selecting Create J2EE Web Service. This launches the Create Java Web Service wizard.

We must select the J2EE 1.4 (JAX-RPC) Web Service option, as this is the only option that currently supports Java binding.

We can then select the web service name and choose the bindings that we want to provide, in this case just the WSIF binding which provides a WSDL wrapping around our service. Selecting Autogenerate Service Endpoint Interface causes JDeveloper to automatically create a Java interface extending java.rmi Remote which is needed when creating a web service wrapper. If we are not generating any other bindings, we need to select Next to advance to the next configuration screen. We do not need to provide any additional configuration for the Specify Custom Data Type Serializers screen, and so can skip it by selecting Next. Similarly we can skip the Mapping screen. These two screens can be used to customize how data is transformed to/from XML, and how the mapping works between the WSDL interface and the Java interface.

By choosing a Java binding(WSIF) we are avoiding the overhead of SOAP and HTTP, but limiting ourselves to invoking a local service.

We now have the opportunity to select the methods to be exposed as part of the service. This allows us to limit the functionality of the Java that we are exposing through the web service.

Having selected the methods we desire, and having clicked Finish, the required WSDL description of the service and any necessary wrapper classes, such as the Java interface corresponding to the WSDL Port Type, will be generated.

Note that before using the service, it is necessary to copy the Java classes so that they can be found by the appropriate SOA Suite component. For example, by copying the classes onto the SOA Suite server in the $ORACLE_HOME/bpel/system/classes directory, they can be found at run time by the BPEL Process Manager. Classes placed here are available to all BPEL processes.

The Oracle Service Bus is very flexible in its use of bindings. When creating a Business Service or a Proxy it is possible to specify the bindings to be used on the Transport Configuration screen. The choice of transports available is different depending on whether we are configuring a Business Service or a Proxy.

When configuring a Business Service transport described by WSDL we have the following protocol options available.

The different transports allow for better performance or more reliable messaging than simple SOAP over HTTP. The transports available when defining a Proxy Service described by WSDL include http, jms, ws, and sb as already described. The other three mentioned, bpel-10g, dsp, and jpd are not supported for inbound traffic to the service bus. There is, however, another transport supported by Proxy services, which is local.

The local transport is highly optimized for using internally by the service bus.In addition to being highly performing, is also very reliable, having exactly once invocation semantics. Exactly once invocation semantics means that when called there will be a single invocation of the proxy with no retries.

Bindings allow us to control the way in which SOA Suite components interact with services. Different bindings provide different benefits, such as transactionality or better performance.

Generally when considering bindings, we do not have to worry too much about the low level details. The key questions we need to ask are:

Most of our binding choices will be dictated by the nature of the service required, and only occasionally will the latter two questions enter into our considerations.