SOA—The Motto

We have been doing integration for many decades in proprietary or ad-hoc manner. Today, the buzz word is SOA and in the integration space, we are talking about Service Oriented Integration (SOI). Let us look into the essentials of SOA and see whether the existing standards and APIs are sufficient in the integration space.

Why We Need SOA

We have been using multiple technologies for developing application components, and a few of them are listed as follows:

• Remote Procedure Call (RPC)
• Common Object Request Broker Architecture (CORBA)
• Distributed Component Object Model (DCOM)
• .NET remoting
• Enterprise Java Beans (EJBs)
• Java Remote Method Invocation (RMI)

One drawback, which can be seen in almost all these technologies, is their inability to interoperate. In other words, if a .NET remoting component has to send bytes to a Java RMI component, there are workarounds that may not work all the times.

Next, all the above listed technologies follow the best Object Oriented Principles (OOP), especially hiding the implementation details behind interfaces. This will provide loose coupling between the provider and the consumer, which is very important especially in distributed computing environments. Now the question is, are these interfaces abstract enough? To rephrase the question, can a Java RMI runtime make sense out of a .NET interface?

Along these lines, we can point out a full list of doubts or deficiencies which exist in today’s computing environment. This is where SOA brings new promises.

What is SOA

SOA is all about a set of architectural patterns, principles, and best practices to implement software components in such a way that we overcome much of the deficiencies identified in traditional programming paradigms. SOA speaks about services implemented based on abstract interfaces where only the abstract interface is exposed to the outside world. Hence the consumers are unaware of any implementation details. Moreover, the abstract model is neutral of any platform or technology. This means, components or services implemented in any platform or technology can interoperate. We will list out few more features of SOA here:

• Standards-based (WS-* Specifications)
• Services are autonomous and coarse grained
• Providers and consumers are loosely coupled

The list is not exhaustive, but we have many number of literature available speaking on SOA, so let us not repeat it here. Instead we will see the importance of SOA in the integration context.

SOA and Web Services

SOA doesn’t mandate any specific platform, technology, or even a specific method of software engineering, but time has proven that web service is a viable technology to implement SOA. However, we need to be cautious in that using web services doesn’t lead to SOA by itself, or implement it. Rather, since web services are based on industry accepted standards like WSDL, SOAP, and XML; it is one of the best available means to attain SOA.

Providers and consumers agree to a common interface called Web Services Description Language (WSDL) in SOA using web services. Data is exchanged normally through HTTP protocol, in Simple Object Access Protocol (SOAP) format.

WSDL

WSDL is the language of web services, used to specify the service contract to be agreed upon by the provider and consumer. It is a XML formatted information, mainly intended to be machine processable (but human readable too, since it is XML). When we host a web service, it is normal to retrieve the WSDL from the web service endpoint. Also, there are mainly two approaches in working with WSDL, which are listed as follows:

• Start from WSDL, create and host the web service and open the service for clients; tools like wsdl2java help us to do this.
• Start from the types already available, generate the WSDL and then continue; tools like java2wsdl help us here.

Let us now quickly run through the main sections within a WSDL. A WSDL structure is as shown here:

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace=
                 "http://versionXYZ.ws.servicemix.esb.binildas.com" …>
  <wsdl:types>
    <schema elementFormDefault="qualified"
            targetNamespace="http://version20061231.ws.
                           servicemix.esb.binildas.com"
            >
    </schema>
  </wsdl:types>
  <wsdl:message name="helloResponse">
    <!-- other code goes here -->
  </wsdl:message>
  <wsdl:portType name="IHelloWeb">
    <!-- other code goes here -->
  </wsdl:portType>
  <wsdl:binding name="HelloWebService20061231SoapBinding"
                type="impl:IHelloWeb">
    <!-- other code goes here -->
  </wsdl:binding>
  <wsdl:service name="IHelloWebService">
    <wsdl:port binding="impl:HelloWebService20061231SoapBinding"
                  name="HelloWebService20061231">
      <wsdlsoap:address
               location="http://localhost:8080/AxisEndToEnd20061231/
                                 services/HelloWebService20061231"/>
    </wsdl:port>
  </wsdl:service>
</wsdl:definitions>

We will now run through the main sections of a typical WSDL:

• types: The data types exchanged are expressed here as an XML schema.
• message: This section details about the message formats (or the documents) exchanged.
• portType: The PortType can be looked at as the abstract interface definition for the exposed service.
• binding: The PortType has to be mapped to specific data formats and protocols, which will be detailed out in the binding section.
• port: The port gives the URL representation of the service endpoint.
• service: Service can contain a collection of port elements.

Since JBI is based on WSDL, we can deal with many WSDL instances.