Creating a Java Interface

• •A stateless invoke means that each time the Java code is called from the BPEL process, a new instance of the Java class is instantiated.
• •A stateful invoke is based on a Java class that is marked implementing the java.io.Serializable marker interface. With a stateful invoke, the process uses the same Java instance throughout the lifetime of the partnerLink useing it. Multiple invokes on the same POJO partner link result in method calls on the same POJO instance.

Setting up Your Java Project in Process Developer

1. 1. Select File > New > Orchestration Project.
2. 2. Name your project and click Next.
3. 3. Select Java Enabled Orchestration.
4. 4. In the orchestration project, import or create a new Java Project. The Java project must contain:
• - A Java interface with at least one method.
• - Concrete implementation of the Java interface.

• •Constraints for your Java Project
• •Creating a Java Interface

Constraints for your Java Project

• •The Java interface's method parameter types are limited to JavaBeans and the following primitive Java types:
• - byte, short, int, long, float, double, boolean, char
• - Byte, Short, Integer, Long, Float, Double, Boolean, Character
• - String
• - BigInteger
• - Date
• •Java checked exceptions are modeled as faults, but the Java method must throw the same exception at runtime for the fault to be properly thrown.
• •The Java interface to the WSDL generator is performed by JAXB, and support for JavaBeans is inherited from JAXB.
• •Arrays and Collections are not currently supported as arguments to Java methods; however, Collections are suwpported if they are wrapped in JavaBeans.
• •The class that implements the interface must have a default constructor.
• •The class that implements the interface can be stateless or stateful. A stateful class is one that is marked implementing the java.io.Serializable marker interface.

Generating WSDL and Schema from a Java Interface

1. 1. In your Java orchestration project, create a new BPEL process in the bpel folder.
2. 2. In Participants view, right-mouse click on Partner Service Provider and select New Partner Service Provider.
3. 3. In the Partner Service Provider dialog, select Generate Interface.
4. 4. In the New Interface wizard, select From a Java Interface.
5. 5. Browse to your Java interface and select it.
6. 6. Notice that the new WSDL is generated in the wsdl folder of your project.
7. 7. Select Finish, and then select OK in the Partner Service Provider dialog.

• •All methods in the Java interface manifest as WSDL operations.
• •All method arguments manifest as top-level XML schema element declarations. The arguments are generated with generic names, such as "argl_string". To generate actual argument names, see Generating Argument Names for Schema Elements.
• •The method return type manifests as a top-level XML schema element declaration.
• •All declared exceptions on the method manifest as WSDL faults.
• •The WSDL is commented with "Do Not Edit" since it is a derived file that can be automatically updated.

• •One Partner Link Type named [JavaInterfaceName]PLT
• •One Port Type named [JavaInterfaceName]
• •One Operation within the port type for each method in the Java Interface
• •Two messages for each Java interface method:
• - One message for the method's arguments named [methodName] with a single part of the same name.
• - One message for the method's return value named [methodName]Response with a single part of the same name.
• •Two embedded schema elements for each Java interface method:
• - One element to model the Java interface method's arguments named methodName.
• - One element to model the Java interface method's return value named [methodName]Response.
• •A schema complexType and a schema element for each Java class used by the interface.

• •Top-level element declarations are created for each of the explicit class references.
• •The implicit declarations manifest as top-level complexTypes and are reused throughout other parts of the schema (if applicable).

• •Updating Your Java Project and Your BPEL Process Concurrently
• •Creating a Java Interface

Generating Argument Names for Schema Elements

1. 1. In the Project Explorer, right-mouse click on your project, and select Properties > Java Build Path.
2. 2. Select the Libraries tab.
3. 3. Select Add External JARs.
4. 4. Browse to [Designer Installation]\designer\plugins\org.activebpel.enginep_[version_number]\server\shared\lib
5. 5. Select ae_rt.jar, as shown:

6. 6. Open your Java interface file and add the @AeWsdlParam annotation to each argument. For example:
Public interface IMyInterface {
   public void execute(
   @AeWsdlParam("someValue") String someValue);
}
7. 7. Generate (or regenerate ) a WSDL by right-mouse clicking on a Java interface, and selecting Generate WSDL.

• •You should not edit the generated WSDL. If you update the Java interface, you must regenerate the WSDL.
• •You do not need to deploy ae_rt.jar. It is already on the server's classpath.
• •If you upgrade Process Developer to a new version, you must remove the older version of ae_rt.jar and re-add the new one.

Updating Your Java Project and Your BPEL Process Concurrently

Deployment Requirements for a Java (POJO) Endpoint

1. 1. Open the PDD Editor, as described in Creating a Process Deployment Descriptor File.
2. 2. On the Partner Links tab, select the partner role that invokes the Java interface.
Notice that the selection is set to Java Service for the invoke handler.
3. 3. In the Java Invoke Handler Properties dialog, select the Java class that is created and invoked at runtime.
4. 4. Select the Java classpath to be used when instantiating and invoking the Java class. The classpath includes not only the JAR (or local "src" workspace directory) that contains the class being invoked, but also any JARs that contain classes referenced directly or indirectly by that class.
Note that the Inherit server classloader checkbox is selected by default. If you disable this option, you will only have access to the JARs on your classpath, not the JARs that are deployed to the server. You can also select Parent classloader last when inheriting Process Server classloader.

Deployment Requirements for Java (EJB) Endpoint

1. 1. For a JNDI Name, specify the JNDI name as defined in your application server's EJB file, such as the JBOSS ejb-jar.xml file, the WebLogic weblogic-ejb-jar.xml file, or the WebSphere ibm-ejb-jar-bnd.xml file.
2. 2. For EJB Home, specify the home interface as defined in application server's ejb-jar.xml file.
This property is required for WebSphere, but is optional for JBoss and WebLogic.
3. 3. In the Classpath box, select the Java classpath that is used when instantiating and invoking the Java class. The classpath includes not only the JAR (or local "src" workspace directory) that contains the class being invoked, but also any JARs that contain classes referenced directly or indirectly by that class.
Note that the Inherit server classloader checkbox is selected by default. If you disable this option, you will only have access to the JARs on your classpath, not the JARs that are deployed to the server.

Running a BPEL Process with a POJO EJB Endpoint

• •Unmarshalls the WSDL message into Java objects. (For a POJO, reflection is used. For an EJB, a JNDI lookup is used.)
• •Instantiates the concrete Java class.
• •Invokes the appropriate method, based on the WSDL operation name.
• •Marshalls the method return value into a WSDL message (or marshalls the Java exception into a WSDL fault).

Comparing the POJO EJB Interface to a Custom Java Invoke Handler