Ruby as Enterprise Glue

<definitions
  name="LocServiceImplementationDescription"
  targetNamespace="example.com/wsdl/loc_service.wsdl"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  
  
  >

  <message name="locate_in">
          <part name="street" type="xsd:string"/>
          <part name="house_number" type="xsd:string"/>
          <part name="postal_code" type="xsd:string"/>
          <part name="city" type="xsd:string"/>
          <part name="state" type="xsd:string"/>
        </message>

        <message name="locate_out">
          <part name="longitude" type="xsd:double"/>
          <part name="latitude" type="xsd:double"/>
        </message>

        <portType name="LocServiceInterface">
          <operation name="locate">
            <input message="tns:locate_in"/>
            <output message="tns:locate_out"/>
          </operation>
        </portType>

        <binding
            name="LocServiceBinding"
            type="tns:LocServiceInterface">
          <soap:binding style="rpc"/>
      <operation name="locate">
              <soap:operation soapAction="locate"/>
                <input>
                  <soap:body namespace="urn:LocService"/>
               </input>
               <output>
                 <soap:body
                   namespace="urn:LocService"
                   use="encoded"/>
               </output>
            </operation>
         </binding>

   <service name="LocalizationService">
      <documentation>
        Calculates coordinates of a given address.
      </documentation>
      <port
           binding="tns:LocServiceBinding"
           name="LocServicePort">
         <soap:address
           location="http://localhost:2000"/>
      </port>
   </service>
</definitions>

Ruby has excellent support for SOAP because of the SOAP4R library (see Resources). It implements version 1.1 of the SOAP specification and is easy to use. If you've worked with SOAP before, you probably know what to do with a WSDL file. Normally, you'd use it to create skeleton code for a SOAP server or client you're going to implement. SOAP4R comes with a tool called wsdl2ruby.rb that turns a WSDL file into Ruby code. It can create code both for accessing a service having the interface described in the file and for creating a server that implements the interface.

We need a client that uses the localization service, and we could generate the complete code from the WSDL file with wsdl2ruby.rb. But in a dynamic language like Ruby, we don't need this intermediate step. It's easier to derive the client from a WSDL file on the fly. Listing 6 demonstrates how to do this.

require 'soap/wsdlDriver'
include SOAP

class LocalizationService
  def initialize(wsdl_file)
    factory = WSDLDriverFactory.new(wsdl_file)
    @loc_service = factory.create_rpc_driver
  end

  def locate(address)
    @loc_service.locate(
      address.street,
      address.house_number,
      address.postal_code,
      address.city,
      address.state
    )
  end
end

The initialize method expects a WSDL file and creates a driver factory from it. This factory creates a driver (a synonym for proxy) for every service binding that has been specified in the WSDL file. We choose the RPC driver and treat the instance variable @loc_service as if it were a local object of class LocalizationService. In the locate method, we simply delegate the work to the localization service.

You need to run a standalone SOAP server to make these examples work, as shown in Listing 7.

In a final step, we build an HTTP server that returns the coordinates belonging to a particular address as an XML document. It takes some time to calculate the coordinates, and the localization service isn't free either. Hence, we calculate coordinates only if necessary and store them locally in our database.

Back in the old days of the Internet, you had to use standards like the Common Gateway Interface (CGI) to create dynamic Web sites. Whenever a client requested a nonstatic page, the Web server called an external program—often a Perl or bash script—to create the content. The server passed it the current environment, including the client's request parameters, and returned the script's output to the requesting client. This approach causes a severe performance overhead, because the scripts have to be started as separate processes.

CGI programs have more disadvantages. First, they cannot easily maintain a state, because they are shut down immediately after they have done their work. Second, they are often a security problem, because they run in a more or less uncontrolled environment.

With the advent of Java, an alternative technology became fairly popular—servlets. Servlets are little code snippets that are executed by a so-called servlet container. They are loaded into memory only once and can be reused as often as necessary. This increases performance tremendously, and it allows developers to manage state information in the servlets. Eventually, the servlet container controls the environment of the servlets and can prevent them from performing unwanted operations such as deleting files.

Ruby ships with WEBrick (see Resources), a fantastic framework for creating HTTP servers. It allows you to follow the more or less obsolete CGI approach, but it strongly encourages the use of Ruby servlets. In Listing 8, you can see a servlet that implements the main logic of our service.