Go to page: Prev  1  2  3  4  5  6  7  8  9  10  11  12  13  Next

We can see that using the XML façade makes the code simpler and easier to maintain; this is particularly true for larger variables with many member fields. For this example to work, we have to include the XML façade classes in the BPEL process suitcase.

Web Services Invocation Framework Bindings

WSIF is an Apache technology that was originally developed by IBM alphaWorks as a part of WSTK (Web Services Toolkit). Oracle has implemented WSIF in the BPEL Process Manager. For more information of WSIF, visit http://ws.apache.org/wsif/.

Invoking a Java Class through WSIF

To demonstrate how WSIF works, let's invoke a Java class. Remember that with WSIF we will only have to modify the WSDL of the service and not the BPEL code. So, in this example we will use the original BPEL code that invokes the Employee service using the <invoke> activity.

Instead of invoking the Employee web service we will bind it to a Java class. In order to replace the web service with a Java class we will need a class with the exactly the same interface as the web service. We need to modify the Java class from our previous example slightly.

Looking at the Employee web service interface, we can see that it provides an operation that takes as input the EmployeeTravelStatusRequestMessage, which is of type EmployeeType. To map the EmployeeType to Java we use the corresponding XML façade (using the schemac tool) as we did in our previous example. The web service operation returns the EmployeeTravelStatusResponseMessage message of type TravelClassType, which is actually a specialization of xs:string. We map this type to java.lang.String. We will call the new Java class EmployeeStatusFull:

package com.packtpub;

import com.packtpub.service.employee.*;

public class EmployeeStatusFull {

   public String getTravelStatus (EmployeeType emp) {
      System.out.println("Java employee status for "+emp.getFirstName()+
                         " "+emp.getLastName()+": Economy.");

      return "Economy";
   }
}

We added a console output to verify that our process calls the Java class and not the web service.

Next we modify the Employee WSDL. We have to add the binding section, which defines the Java provider to be used. We also have to map the XML types to Java types and the WSDL operation to the Java method. We start by defining the two namespaces used by WSIF providers:

<?xml version="1.0" encoding="utf-8" ?>
<definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"
             xmlns:tns="http://packtpub.com/service/employee/"
             targetNamespace="http://packtpub.com/service/employee/"
             xmlns="http://schemas.xmlsoap.org/wsdl/"
             xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"
             xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/"
             xmlns:java="http://schemas.xmlsoap.org/wsdl/java/" >
...

Next we add the binding section (usually after port type declarations and before partner link types). Here we define a Java binding for the EmployeeTravelStatusPT port type. We define the type mapping from XML to Java:

• XML EmployeeType is mapped to the com.packtpub.service.employee.EmployeeType Java class
• XML TravelClassType is mapped to java.lang.String

We also have to specify that the WSDL operation EmployeeTravelStatus is mapped to the Java method getTravelStatus():

...
   <!-- Java binding -->

   <binding name="JavaBinding" type="tns:EmployeeTravelStatusPT">

      <java:binding/>

      <format:typeMapping encoding="Java" style="Java">
         <format:typeMap typeName="tns:EmployeeType"
                 formatType="com.packtpub.service.employee.EmployeeType" />
         <format:typeMap typeName="tns:TravelClassType"
                 formatType="java.lang.String" />
      </format:typeMapping>

      <operation name="EmployeeTravelStatus">
         <java:operation methodName="getTravelStatus"/>
         <input/>
         <output/>
      </operation>
   </binding>
...

Next we have to define the Java port and specify that the Employee service will use the com.packtpub.EmployeeStatusFull Java class:

...
   <service name="Employee">

      <documentation>Employee</documentation>

      <port name="JavaPort" binding="tns:JavaBinding">

         <java:address className="com.packtpub.EmployeeStatusFull"/>

      </port>

   </service>

The rest of the Employee WSDL (including partner link types) has not been changed. We make no changes to the BPEL process code. Notice that we use the same partner link and invoke the EmployeeStatusFull Java class with the usual <invoke> activity used for invoking the web service, as shown in the following code excerpt:

...
   <!-- Synchronously invoke the Employee Travel Status -->
   <invoke partnerLink="employeeTravelStatus"
           portType="emp:EmployeeTravelStatusPT"
           operation="EmployeeTravelStatus"
           inputVariable="EmployeeTravelStatusRequest"
           outputVariable="EmployeeTravelStatusResponse" />
...

To test this example we must first generate the XML façade using the schemac utility. Then we have to compile the Java class and deploy it (and the XML façade) to the c:\orabpel\system\classes directory. Finally we can compile the BPEL and deploy it. If the BPEL successfully invokes the Java class, the BPEL Process Manager console window will show the following output:

(Full Size Image)

In a similar way we could map the Employee web service to an EJB or other supported resources using the corresponding WSIF provider.

Go to page: Prev  1  2  3  4  5  6  7  8  9  10  11  12  13  Next

Tools:

Add www.codeguru.com to your favorites Add www.codeguru.com to your browser search box IE 7 | Firefox 2.0 | Firefox 1.5.x Receive news via our XML/RSS feed