rss
SOATUBE
Oracle
Custom Search SOABYTE here

Friday, June 25, 2010

WSIF Integration

















Understanding WSIF
 Java-to-xml-binding


Next, use the BPEL Console to start the process. In the visual flow window you can observe the execution of the process. Note that the <invoke> activity has been used in BPEL and that the book rating is 4, in contrast to the original Book Rating Web services, which returned 5:

figure 1

To be absolutely sure that the BPEL Process Manager has invoked the Java class, the BPEL Process Manager console window will show the following output:
05/10/19 19:35:36 Book rating for Business Process Execution Language (1-904811-
18-3): 4.

                            
Exception Handling
When invoking Java resources from BPEL we need a way to propagate Java exceptions to BPEL. With WSIF we can map Java exceptions to WSDL faults and handle them using BPEL fault handlers. For the mapping the exception serializer is responsible. Oracle BPEL Process Manager provides a default exception serializer, or you can write our own custom serializer.
To demonstrate how Java exceptions can be propagated to BPEL we will extend our example. First, use the default serializer and then extend the example with a custom serializer. Go through the following steps:
  1. Define a user exception in Java.
  2. Modify the BookRatingJava Java class to throw the exception.
  3. Define the corresponding fault in the WSDL. This includes the definition of XML Schema type for the fault message, the fault message, and addition of the <fault> message to the WSDL <operation> description.
  4. Define the WSIF binding for the exception.
Define User Exception in Java. First, define a user exception for signaling that a book, for which the rating has been acquired, does not exist. You will name the exception BookDoesNotExistException. The code below shows the exception in Java:
package com.oracle.rating;

public class BookDoesNotExistException extends Exception
{
  String detailDesc;
  String bookTitle;

  public BookDoesNotExistException(String message, String detailDesc, String bookTitle)
  {
    super(message);
    this.detailDesc = detailDesc;
    this.bookTitle = bookTitle;
  }

  public String getDetailDesc()
  {
    return detailDesc;
  }

  public String getBookTitle()
  {
    return bookTitle;
  }
}

                            
Throw Java Exception. Next, modify the BookRatingJava Java class. You will throw the exception if the ISSN of the book equals to 999:
package com.oracle.rating;

import com.oracle.service.bookrating.*;

public class BookRatingJavaUserException {

  public Integer getBookRating (BookDscType book) throws BookDoesNotExistException {

    if  
                                
(book.getISSN().equals("999"))
       throw(new BookDoesNotExistException("Book does not exist",
                                           "Book (ISSN="+book.getISSN()+") does not exist",
                                           book.getTitle()));

    System.out.println("Book rating for "+book.getTitle()+" ("+book.getISSN()+"): 4.");

    return new Integer(4);

  }
}
                              
                            
Define Fault in WSDL. In the next step, you will define the corresponding fault in WSDL. Java exception will be propagated to this fault. As you will use the default exception serializer, you have to use a specific complex type which has two elements: faultstring and detail. You will add this complex type to the <types> section of the Book Rating WSDL:
<xs:complexType name="BookDoesNotExistExceptionType">
  <xs:sequence>
    <xs:element name="faultstring" type="xs:string" />
    <xs:element name="detail" type="xs:string" />
  </xs:sequence>
</xs:complexType>

                            
Next, define the corresponding message:
<message name="BookDoesNotExistException">
  <part name="exception" type="tns:BookDoesNotExistExceptionType" />
</message>

                            
Finally, add the fault message to the BookRating operation signature:
<portType name="BookRatingPT">
  <operation name="BookRating">
    <input message="tns:BookRatingRequestMessage" />
    <output message="tns:BookRatingResponseMessage" />
     
                                
<fault name="BookDoesNotExistException" message="tns:BookDoesNotExistException" />
  </operation>
</portType>
                              
                            
The default exception serializer will create the fault element and fill the faultstring with the content returned byException.getMessage() and the detail element with the content returned by Exception.toString().
Define WSIF Binding for Exception. Now you are ready to add the exception to the WSIF binding. You have to define the type mapping for the BookDoesNotExistExceptionType XML type, which in our case will map to the corresponding Java exception class—to the com.oracle.rating.BookDoesNotExistException. You also have to add the fault message name ( BookDoesNotExistException) to the operation mapping part:
<binding name="JavaBinding" type="tns:BookRatingPT">
  <java:binding/>
  <format:typeMapping encoding="Java" style="Java">
    <format:typeMap typeName="tns:BookDscType"
                    formatType="com.oracle.service.bookrating.BookDscType" />
    
                                
<format:typeMap typeName="tns:BookDoesNotExistExceptionType"
                    formatType="com.oracle.rating.BookDoesNotExistException" />
  </format:typeMapping>
  <operation name="BookRating">
    <java:operation methodName="getBookRating"/>
    <input/>
    <output/>
     
                                
<fault name="BookDoesNotExistException"/>
  </operation>
</binding>
                              
                            
For this example to work you have to compile Java classes and deploy them to the C:\OraBPELPM_1\integration\orabpel\system\classes directory, where the BPEL server can access them. The easiest way is to use the obant utility with the example:
Z:\WSIF\3_JavaBindingUserExceptionDefaultSerializer>obant

Z:\WSIF\3_JavaBindingUserExceptionDefaultSerializer>SETLOCAL
Buildfile: build.xml

CompileJava:
  [schemac] schemac> parsing schema file 'Z:\WSIF\3_JavaBindingUserExceptionDefa
ultSerializer/BookRating.wsdl' ...
  [schemac] schemac> Loaded schemas from wsdl located at Z:\WSIF\3_JavaBindingUs
erExceptionDefaultSerializer/BookRating.wsdl
  [schemac] schemac> generating XML business document ...
  [schemac] schemac> compiling XML business documents ...
    [javac] Compiling 2 source files to C:\OraBPELPM_1\integration\orabpel\syste
m\classes

main:
    [bpelc] validating "Z:\WSIF\3_JavaBindingUserExceptionDefaultSerializer\BuyB
ook.bpel" ...
    [bpelc] BPEL suitcase deployed to: C:\OraBPELPM_1\integration\orabpel\domain
s\default\deploy

all:

BUILD SUCCESSFUL
Total time: 18 seconds

Z:\WSIF\3_JavaBindingUserExceptionDefaultSerializer>ENDLOCAL

Z:\WSIF\3_JavaBindingUserExceptionDefaultSerializer>

                            
After starting the example from the BPEL console and entering ISSN of 999, you get the following output:

figure 2

Custom Exception Serializers. If you are not happy with the structure of the WSDL fault (which consists of the faultstring and detail elements) and would prefer to have more control over the mapping of Java exceptions to WSDL faults, you can use custom exception serializers. A custom exception serializer is a Java class that maps the exception and its attributes to the complex type used for the WSDL fault. To see how custom serializer is developed, go through the following steps:
  1. Define a custom complex type used for the WSDL fault message.
  2. Write a custom exception serializer to propagate the Java exception to WSDL fault.
  3. Register the custom exception serializer.
First, define the XML Schema custom complex type to represent the Java exception that will include all three exception attributes, message, detail description, and book title. You will replace the default complex type with this type in the<types> section of the Book Rating WSDL:
<xs:complexType name="BookDoesNotExistExceptionType">
  <xs:sequence>
    <xs:element name="message" type="xs:string" />
    <xs:element name="detailDesc" type="xs:string" />
    <xs:element name="bookTitle" type="xs:string" />
  </xs:sequence>
</xs:complexType>

                            
The custom exception serializer is a Java class, which defines how the Java exception maps to the WSDL fault complex type. The exception serializer has to map the Java exception attributes to the corresponding XML elements of the fault message, and has to implement the following interface:
public interface IExceptionSerializer {

        public Element serialize(Throwable ex,
                             String messageName,
                             String namespaceURI);
}

                            
For our example, you will name the custom exception serializer BookDoesNotExistExceptionSerializer and extend the existing ExceptionSerializer class. Using DOM API we will map the three attributes of the Java exception (message, detail description, book title) to the above presented XML Schema type (BookDoesNotExistExceptionType):
package com.oracle.rating;

import org.w3c.dom.Element;

import com.collaxa.xml.XMLHelper;
import com.oracle.bpel.xml.util.ExceptionSerializer;
import com.oracle.bpel.xml.util.IExceptionSerializer;

public class BookDoesNotExistExceptionSerializer extends ExceptionSerializer
                implements IExceptionSerializer {

        public Element serialize(Throwable ex, String messageName, String namespaceURI) {

                if(ex instanceof BookDoesNotExistException)
                {
                        BookDoesNotExistException brEx = (BookDoesNotExistException)ex;

                        Element exceptionElement =
                         XMLHelper.createRootElement(messageName, namespaceURI,"tns");

                        Element messageElement =
                         XMLHelper.createElement("message","tns",namespaceURI);
                        messageElement.setNodeValue(brEx.getMessage());
                        exceptionElement.appendChild(messageElement);

                        Element detailElement =
                         XMLHelper.createElement("detailDesc","tns",namespaceURI);
                        detailElement.setNodeValue(brEx.getDetailDesc());
                        exceptionElement.appendChild(detailElement);

                        Element bookElement =
                          XMLHelper.createElement("bookTitle","tns",namespaceURI);
                        bookElement.setNodeValue(brEx.getBookTitle());
                        exceptionElement.appendChild(bookElement);

                        return exceptionElement;

                }
                return super.serialize(ex, messageName, namespaceURI);
        }

}

                            
The final step is to register the custom exception serializer with the Oracle BPEL Process Manager. This step will instruct the BPEL Process Manager to use your custom serializer instead of the default serializer. To do so, define the exceptionSerializer property in the bpel.xml deployment descriptor:
<partnerLinkBinding name="BookRating">
  <property name="wsdlLocation">
      BookRating.wsdl
  </property>
   
                                
<property name="exceptionSerializer">
      com.oracle.rating.BookDoesNotExistExceptionSerializer
  </property>          
</partnerLinkBinding>
                              
                            
As with the previous example you have to compile Java classes and deploy them to the C:\OraBPELPM_1\integration\orabpel\system\classes directory. Use the obant utility:
Z:\WSIF\3_JavaBindingUserExceptionCustomSerializer>obant

Z:\WSIF\3_JavaBindingUserExceptionCustomSerializer>SETLOCAL
Buildfile: build.xml

CompileJava:
  [schemac] schemac> parsing schema file 'Z:\WSIF\3_JavaBindingUserExceptionCust
omSerializer/BookRating.wsdl' ...
  [schemac] schemac> Loaded schemas from wsdl located at Z:\WSIF\3_JavaBindingUs
erExceptionCustomSerializer/BookRating.wsdl
  [schemac] schemac> generating XML business document ...
  [schemac] schemac> compiling XML business documents ...
    [javac] Compiling 3 source files to C:\OraBPELPM_1\integration\orabpel\syste
m\classes

main:
    [bpelc] validating "Z:\WSIF\3_JavaBindingUserExceptionCustomSerializer\BuyBo
ok.bpel" ...
    [bpelc] BPEL suitcase deployed to: C:\OraBPELPM_1\integration\orabpel\domain
s\default\deploy

all:

BUILD SUCCESSFUL
Total time: 21 seconds

Z:\WSIF\3_JavaBindingUserExceptionCustomSerializer>ENDLOCAL

Z:\WSIF\3_JavaBindingUserExceptionCustomSerializer>

                            
After starting the example from the BPEL console and entering ISSN of 999, you'll get the following output. Notice the different fault structure:

figure 3

Custom Java Serializers. A custom Java serializer is a class that implements the IJavaSerializer interface. It has to provide the implementation of two methods: serialize and deserialize.
public interface IJavaSerializer {

        public Element serialize(Object obj, Class type, String name, String namespaceURI,
                             String prefix, Map classMap) throws Exception;
        public Object deserialize(Element el, Class type) throws Exception;
}

                            
Similar to custom exception serializers, you have to deploy the compiled class to the C:\OraBPELPM_1\integration\orabpel\system\classes directory and define the javaSerializer property in the bpel.xml deployment descriptor:
<partnerLinkBinding name="helper">
    <property name="wsdlLocation">HelperService.wsdl</property>
     
                                
<property name="javaSerializer">com.oracle.bpel.xml.util.MyCustomSerializer</property>
</partnerLinkBinding>
                              
                            
Oracle provides three custom serializers out of the box: for Java API for XML Bindings (JAXB), XML Beans, and Axis Beans.
JAXB is a part of Java Web Services Developer Pack and provides a conceptually similar approach to XML façades, but differs in several details. To use JAXB serialization with Oracle BPEL Process Manager, take the following steps:
  1. Add the JAXB JAR files, located in the JWSDP installation directory (for example c:\jwsdp-1.5\jaxb\lib) to the environment variable BASE_OB_CLASSPATH in the obsetenv.bat file found in C:\OraBPELPM_1\integration\orabpel\bin and to the application.xml file found in C:\OraBPELPM_1\integration\orabpel\system\appserver\oc4j\j2ee\home\confi.
  2. Copy the JAXBSerializer.class (see sample code download) into C:\OraBPELPM_1\integration\orabpel\system\classes\com\oracle\bpel\xml\util directory.
  3. Copy the Java classes produced by the JAXB compiler (xjc) to the C:\OraBPELPM_1\integration\orabpel\system\classes directory.
You also have to define which serializer your BPEL project will use. You do that in the bpel.xml file, where you have to define the javaSerializer property:
<partnerLinkBinding name="helper">
  <property name="wsdlLocation">HelperService.wsdl</property>
   
                                
<property name="javaSerializer">com.oracle.bpel.xml.util.JAXBSerializer</property>
</partnerLinkBinding>
                              
                            
XML Beans are another approach for Java to XML bindings, originally developed by BEA, which donated the project to the Apache community. In contrast to XML façades and JAXB, XML Beans provide an approach that does not completely hide XML from Java developers. Instead, it provides Java interfaces with getter/setter methods and additional methods (with x appendix) through which you can manipulate XML directly if needed. XML Beans are also aware of XML Infoset—when XML is converted to Java objects the whole XML Infoset is available to the developer.
Similar to JAXB, you have to make a few configuration steps in order to use XML Beans:
  1. Add the XML Beans JAR files (xbean.jar from BEA Weblogic) to the environment variable BASE_OB_CLASSPATH in the obsetenv.bat file found in C:\OraBPELPM_1\integration\orabpel\bin and to the application.xml file found in C:\OraBPELPM_1\integration\orabpel\system\appserver\oc4j\j2ee\home\config.
  2. Copy the XMLBeansSerializer.class (see sample code download) into C:\OraBPELPM_1\integration\orabpel\system\classes\com\oracle\bpel\xml\util directory.
  3. Copy the Java classes produced by the XML Beans compiler to the C:\OraBPELPM_1\integration\orabpel\system\classes directory
  4. Set path to the xbean.jar in the build.xml file used with the ANT utility ( obant).
You also have to define that BPEL project should use the XML Bean serializer in the bpel.xml file:
<partnerLinkBinding name="xmlBeansService">
  <property name="wsdlLocation">XMLBeansService.wsdl</property>
   
                                
<property name="javaSerializer">
        com.oracle.bpel.xml.util.XMLBeanJavaSerializer
  </property>
</partnerLinkBinding>
                              
                            
The third well-known approach for Java to XML bindings is Axis Beans, and you can use them with Oracle BPEL Process Manager, too.
Similar to the previous two examples you have to make a few configuration steps in order to use Axis Beans:
  1. Add the Axis Beans JAR files (axis.jar from Axis version 1.2) to the environment variable BASE_OB_CLASSPATH in the obsetenv.bat file found in C:\OraBPELPM_1\integration\orabpel\bin and to the application.xml file found in C:\OraBPELPM_1\integration\orabpel\system\appserver\oc4j\j2ee\home\config.
  2. Copy the serializer classes from AxisSerializer.zip (see sample code download) into C:\OraBPELPM_1\integration\orabpel\system\classes\ directory.
  3. Copy the Java classes produced by Axis Beans to the C:\OraBPELPM_1\integration\orabpel\system\classes directory.
You also have to define that BPEL project should use the Axis Bean serializer in the bpel.xml file:
<partnerLinkBinding name="AxisBeansService">
  <property name="wsdlLocation">AxisBeansService.wsdl</property>
   
                                
<property name="javaSerializer">
        com.oracle.bpel.xml.util.AxisJavaSerializer
  </property>
</partnerLinkBinding>
                              
                            
WSIF Binding for EJBs
Now you know how to use a Java class instead of a Web service through WSIF bindings. In a similar manner, you can use EJB, particularly the stateless session beans. To demonstrate the WSIF EJB binding we will extend our example. You will include an additional activity in our BPEL process; after invoking the Book Rating service you will invoke the Publisher Rating service. Through WSIF binding you will use a session bean instead of a Web service. Assume that the session bean already exists. To achieve this goal you will go through several steps:
  • Define the WSDL for the session bean.
  • Add the partner link type to the WSDL.
  • Supplement the BPEL process to invoke the Publisher Rating service.
  • Add the WSIF binding to EJB.
WSDL for Session Bean. The session bean that we will use has the following remote component interface:
package com.oracle.ratingSB;

import java.rmi.RemoteException;
import javax.ejb.EJBObject;

public interface PubRating extends EJBObject
{
    public int getAvgPubRating (String name) throws RemoteException;

}

                            
You can see that it provides a method called getAvgPubRating, which takes a string as input and returns an integer. You will not show the home interface, the implementation class, and the deployment descriptors here (see sample code).
Now define the corresponding WSDL document, which is very simple and defines two messages (PubRatingRequestMessage and PubRatingResponseMessage). They are used in the operation PubRating as input and output. The operation is declared within the PubRatingPT port type:
<?xml version="1.0"?>
<definitions xmlns:xs="http://www.w3.org/2001/XMLSchema"
             xmlns:tns="http://oracle.com/service/pubrating/"
             targetNamespace="http://oracle.com/service/pubrating/"
             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:ejb="http://schemas.xmlsoap.org/wsdl/ejb/" >

  <message name="PubRatingRequestMessage">
    <part name="name" type="xs:string" />
  </message>

  <message name="PubRatingResponseMessage">
    <part name="rating" type="xs:int" />
  </message>

  <portType name="PubRatingPT">
    <operation name="PubRating">
      <input name="PubRatingRequest" message="tns:PubRatingRequestMessage" />
      <output name="PubRatingResponse" message="tns:PubRatingResponseMessage" />
    </operation>
  </portType>
</definitions>

                            
Add Partner Link Type. To use the WSDL you have to add the partner link type. The operation is synchronous; therefore you need only one role:
<plnk:partnerLinkType name="PubRatingLT">
  <plnk:role name="PubRatingService">
    <plnk:portType name="tns:PubRatingPT" />
  </plnk:role>
</plnk:partnerLinkType>

                            
Supplement BPEL Process. Now you are ready to supplement the BPEL process to invoke the Publisher Rating service. First, define a new partner link:
<partnerLink name="PubRating"
             partnerLinkType="pbr:PubRatingLT"
             partnerRole="PubRatingService"/>

                            
Then add the interaction with the Publisher Rating service as a new scope just after the Book Rating scope. Please notice that here you only add new functionality to BPEL:
<scope name="RetrievePublisherRating">

  <variables>
      <variable name="PubRatingRequest" messageType="pbr:PubRatingRequestMessage"/>
      <variable name="PubRatingResponse" messageType="pbr:PubRatingResponseMessage"/>
  </variables>

  <faultHandlers>

      <catchAll>

        <sequence>
          <assign>
            <copy>
              <from expression="string('Unable to retrieve publisher rating')" />
              <to variable="Fault" part="error" />
            </copy>
          </assign>

          <invoke partnerLink="Client"
                  portType="buy:ClientCallbackPT"
                  operation="ClientCallbackFault"
                  inputVariable="Fault" />
        </sequence>

      </catchAll>

  </faultHandlers>

  <sequence>

    <assign>
      <copy>
        <from variable="BookPurchase" part="book" query="/book/bkr:Publisher"/>
        <to variable="PubRatingRequest" part="name"/>
      </copy>
    </assign>

    <invoke partnerLink="PubRating"
            portType="pbr:PubRatingPT"
            operation="PubRating"
            inputVariable="PubRatingRequest"
            outputVariable="PubRatingResponse" />

  </sequence>

</scope>

                            
Add WSIF Binding for EJB. WSIF EJB binding is similar to Java class binding, the major difference being that you have to specify the details regarding the mapping of WSDL operations to EJB methods.
Shown below is the WSIF EJB binding excerpt from the Publisher Rating service WSDL file. You have first defined the type mapping and then specified which method should be used for the PubRating operation ( getAvgPubRating()). Please notice that you have specified the message part names for parameters ( name) and for return ( rating). You have also specified the input and output message names ( PubRatingRequest and PubRatingResponserespectively):
<binding name="EJBBinding" type="tns:PubRatingPT">
  <ejb:binding/>
  <format:typeMapping encoding="Java" style="Java">
    <format:typeMap typeName="xs:string" formatType="java.lang.String" />
    <format:typeMap typeName="xs:int" formatType="int" />
  </format:typeMapping>
  <operation name="PubRating">
    <ejb:operation
       methodName="getAvgPubRating"
       parameterOrder="name"
       interface="remote"
       returnPart="rating" />
    <input name="PubRatingRequest"/>
    <output name="PubRatingResponse"/>
  </operation>
</binding>

                            
In the services binding you have to specify additional details of the EJB such as JNDI name, JNDI provider URL, and initial context factory. The JNDI provider URL is specific for each deployment. In this case it would be ormi://localhost/SessionBean. You can use the obant utility to replace the [jndiProviderURL] with the actual address at the time of deployment (please look in the build.xml file for details):
<service name="PubRatingPT">
  <port name="EJBPort" binding="tns:EJBBinding">
    <ejb:address className="com.oracle.ratingSB.PubRatingHome"
                 jndiName="ejb/session/PubRating"
                 initialContextFactory="com.evermind.server.rmi.RMIInitialContextFactory"
                 jndiProviderURL="[jndiProviderURL]"/>
  </port>
</service>

                            
Now you are almost ready to deploy the example and test it. Don't forget to add the wsdlLocation property to the bpel.xml deployment descriptor:
<partnerLinkBinding name="PubRating">
  <property name="wsdlLocation">PubRatingBinded.wsdl</property>
</partnerLinkBinding>

                            
Please notice that you could use the deployment descriptor to add additional properties required by EJB, such as java.naming.security.principal and java.naming.security.credentials if your EJB would require authentication and authorization:
<partnerLinkBinding name="PubRating">
  <property name="wsdlLocation">PubRatingBinded.wsdl</property>
   
                                
<property name="java.naming.security.principal">admin</property>
  <property name="java.naming.security.credentials">welcome</property>    
</partnerLinkBinding>
                              
                            
To test the example you first have to deploy the session bean and then the BPEL process. Again, use obant, which automates the procedure:
Z:\WSIF\4_JavaBindingEJB>obant

Z:\WSIF\4_JavaBindingEJB>SETLOCAL
Buildfile: build.xml

deploySessionBean:

build_ear:

deployIas:

deployOc4j:
     [java] Notification ==> Application Deployer for SessionBean STARTS [ 2005-
10-19T19:47:00.891CEST ]
     [java] Notification ==> Undeploy previous deployment
     [java] Notification ==> Copy the archive to C:\OraBPELPM_1\integration\orab
pel\system\appserver\oc4j\j2ee\home\applications\SessionBean.ear
     [java] Notification ==> Unpack SessionBean.ear begins...
     [java] Notification ==> Unpack SessionBean.ear ends...
     [java] Notification ==> Initialize SessionBean.ear begins...
     [java] Notification ==> Initialize SessionBean.ear ends...
     [java] Notification ==> Application Deployer for SessionBean COMPLETES [ 20
05-10-19T19:47:19.470CEST ]


bindingWsdl:
     [copy] Copying 1 file to Z:\WSIF\4_JavaBindingEJB

setJndiUrlOrclej2ee:

setJndiUrlIas:

setJndiUrlOc4j:
     [echo] Replacing token [jndiProviderURL] by ormi://virtualxp/SessionBean in
 Z:\WSIF\4_JavaBindingEJB/PubRatingBinded.wsdl

main:
    [bpelc] validating "Z:\WSIF\4_JavaBindingEJB\BuyBook.bpel" ...
    [bpelc] BPEL suitcase deployed to: C:\OraBPELPM_1\integration\orabpel\domain
s\default\deploy

all:

BUILD SUCCESSFUL
Total time: 28 seconds

Z:\WSIF\4_JavaBindingEJB>ENDLOCAL

Z:\WSIF\4_JavaBindingEJB>

                            
After starting the BPEL process from the console, you should see that the Publisher Rating service has been invoked:

figure 4

To be absolutely sure that the EJB has been invoked, have a look at the BPEL server console windows; you should see the following output:
05/10/19 19:50:51 Tutalii: C:\OraBPELPM_1\integration\orabpel\lib\orabpel.jar ar
chive
05/10/19 19:50:54 Avg. publisher rating for Packt Publishing: 5.

                            
Generating WSIF Bindings from JDeveloper
Writing WSIF bindings by hand can be quite complicated; therefore, Oracle JDeveloper 10.1.3 (available in Early Access release at the time of this writing) provides a wizard for automatic generation of WSDL and WSIF for existing Java resources, such as Java classes and EJBs. This greatly reduces the effort to invoke Java resources from BPEL and make BPEL even more attractive for integration.
Based on a Java class or EJB you have to start the wizard for the creation of a Java Web service. The screen shoots apply to Java class example:

figure 5

Select the JAX-RPC Web service type, which is Java EE 1.4 compliant.

figure 6

Next, select the Java class or the stateless session bean you would like to use. Check the WSIF binding option (to generate WSIF binding).

figure 7

Next select the SOAP message format, where you can use Document/Wrapped, Document/Literal, RPC/Literal, or RPC/Encoded representations.

figure 8

Next, specify custom mappings between XML types and their Java equivalent classes and the corresponding serializers.

figure 9

Specify the namespaces used by the Web services.

figure 10

Finally, select the methods, which should be exposed through WSDL:

figure 11


The wizard offers additional steps where you specify the optional class loaders, JAX-RPC handler classes, service state (stateful), and additional classes used by the service. In most cases you will not need to specify these, so you can conclude the wizard by pressing the Finish button and look at the generated WSDL, where you will find the WSIF bindings, similar to those written by hand. Refer to the JDeveloper documentation for more information on the wizard.
Conclusion
As you've learned through various examples here, WSIF offers EAI-like capabilities as well as the flexibility to configure partner services of BPEL processes in an easy and flexible way. Clearly, WSIF extends the usability of BPEL to existing resources and makes BPEL an even more valuable technology for SOA.

0 comments:

Post a Comment

 
Blogger Profile