WSIF Binding

Overview of the ServiceMix 1.x WSIF Example

This document describes the components that integrate with the Apache Web Service Invocation Framework (WSIF) to perform web service invocations using a number of different implementation protocols such as Axis, local Java, EJB, JMS, JCA and CCI.

The WSIF example illustrates the following:

• an example of declarative programming
• how to enable a service to be exposed over a JMS queue through WSIF

This example shows critical code snippets from a larger example, which can be found at: Apache Web Services Project. The original example has a client application submitting a zip code to a Web Services application. The web service checks if DSL service is available in the zip code area and responds to the client. In the original example, the client uses a JMS queue to send the message and the web service receives the message from queue and responds. In the ServiceMix example, the WSIF API is used by the client to make the request. This decouples the transport layer from the client code. The WSIF takes care of the details of JMS for the client. Other transport mechanisms could have been used by the client as well, such as SOAP. WSIF provides a single API to the client and handles the details of the transmission for the client. More to follow...

The following example shows how to bind a WSDL file for a web service, which is adorned with WSIF additional metadata to configure the service implementation.

<component id="checkAvailability" service="foo:checkAvailability" class="org.servicemix.components.wsif.WSIFBinding">
  <property name="definitionResource" value="classpath:org/servicemix/components/wsif/service.wsdl"/>
</component>

How it Works

The diagram below illustrates the logical flow of the program through the WSIF components:

The logical flow of the program is:

1. A user opens a web browser and access a web form with a "zipcode" input field and a submit button. The submit button sends the form and the zipcode typed in by the user to a Servicemix HTTP binding component.
2. The HTTP binding component creates an InOut exchange message through the client API. The message is sent through the NMR to the checkAvailability component
3. The checkAvailability component sends the request to the JMS queue.
4. The webservice is implemented with a message driven EJB (MDB), who's "onMessage" method is listening for messages on the queue
5. The MDB, processes the request and sends back a response to the checkAvailability component through a temporary queue.
6. The checkAvailability component receives the response from the queue.
7. The checkAvailability component responds to the HTTP client.
8. The HTTP client sends the result back to the web form. The value of the result property is displayed and let's the user know whether or not DSL is available at the zipcode.

Details

The following table provides more details about the function of the checkAvailability component the Web Service MDB:

Some Coding Details

Snippet from service.wsdl

  <message name='checkAvailabilityRequest'>
    <part name='zipCode' type='xsd:string'/>
  </message>

  <message name='checkAvailabilityResponse'>
    <part name='result' type='xsd:string'/>
  </message>

  <portType name='CheckAvailabilityPortType'>
    <operation name='checkAvailability'>
      <input message='tns:checkAvailabilityRequest'/>
      <output message='tns:checkAvailabilityResponse'/>
    </operation>
  </portType>

  <binding name='CheckAvailabilityJMSBinding' type='tns:CheckAvailabilityPortType'>
    <jms:binding type="TextMessage"/>
    <format:typeMapping encoding="XML" style="Java">
      <format:typeMap typeName="xsd:string" formatType="java.lang.String"/>
    </format:typeMapping>
    <operation name='checkAvailability'>
      <input>
        <jms:input parts="zipCode"/>
        <jms:property message="Request" part="myInt"/>
        <jms:propertyValue name="myLiteralString" type="xsd:string" value="Hello World"/>
      </input>
      <output>
        <jms:output parts="result"/>
      </output>
    </operation>
  </binding>

  <service name='CheckServiceAvailability'>
    <port name='CheckAvailabilityPort'  binding='tns:CheckAvailabilityJMSBinding'>

      <!-- ActiveMQ configuration -->
      <jms:address destinationStyle="queue"
        jndiDestinationName="dynamicQueues/test.org.servicemix.example.wsif"
        jndiConnectionFactoryName="ConnectionFactory"
        initialContextFactory="org.activemq.jndi.ActiveMQInitialContextFactory"
        jndiProviderURL="tcp://localhost:61626"/>
    </port>
  </service>

The following are descriptions of the properties found in the service.wsdl file. These descriptions are quoted from the WSDL Bindings for JMS web page:

• <jms:address> describes a target port that is accessible via JMS.
• destinationStyle must either be queue or topic, although only queue is supported at this time.
• jndiDestinationName is the JNDI name of the JMS queue that WSIF will send requests to.
• jndiConnectionFactoryName is the JNDI name of the connection factory that WSIF will be used.
• jndiProviderURL and initialContextFactory specify which JNDI database to use. If they are not present, WSIF uses the default JNDI.
• jms:binding specifies that this binding is for Native Jms. The type is the type of the JMS message that will be sent. In this case it will be a text message.

Related Documentation

For more information on the following topics please see:

• ActiveMQ related components, jmsFactory, jmsTemplate, broker

• NMR

• PXE BPEL Engine

• Spring