In this chapter, we will examine the following recipes that allow us to integrate Java code into our SOA composites:
- Creating a custom XPath function for SOA Suite
- Calling an EJB from an SOA composite
- Using a Spring bean in an SOA composite
- Using an EJB reference in a Spring component
- Accessing the SOA runtime environment from BPEL
Java is a widely used and popular programming language; indeed, SOA Suite is written in Java. Often we have existing Java code that we wish to use in our composites. The point about Service Oriented Architecture is that it is language neutral and encourages re-use, so it is natural to want to re-use existing Java artifacts. In addition to re-using existing artifacts, we may want to use Java to handle some tasks that are too complicated to handle easily in XML. The following list summarizes the ways in which we may interact with Java from within the SOA Suite, and the purpose for which they should be used:
- Spring container
- Allows the use of existing Spring beans and other Java objects
- Allows the implementation of a WSDL interface in Java
- EJB reference
- Allows composites to call an Enterprise Java Bean
- Java Exec
- Allows a BPEL process to access an executing environment
- Custom XPath function
- Allows custom Java code to be embedded in assign statements and XSLT transforms
- EJB service
- Allows a composite to be invoked by Java code as though it were an EJB
The following use cases outline when to use the different types of Java integration.
Sometimes, the existing XPath functions are insufficient for our needs. In this case, we can write custom XPath functions in Java code. These XPath functions can be used in XQuery, XSLT, and Assign operations in the same way as built-in XPath functions. This allows complex logic to be embedded in XML processing without requiring complex XPath or Xquery logic to be added to it; it also helps to avoid having to make callouts to Java code through other mechanisms and hides the fact that Java is being used from the user of the XPath function.
Existing Java code can be classified as an EJB, a Spring bean, or some other Java object. Other Java objects can be wrapped in a Spring bean to make them consumable by SOA composites. It is possible to select methods to be exposed from existing code. Methods to be exposed should have only simple types or Java beans as input and output parameters. Java beans have no argument constructors. If the methods do not meet these criteria, then it will be necessary to wrap the methods with a Spring bean interface that does meet these criteria if the method is to be called from non-Java components.
The following flowchart helps you decide how to re-use existing Java code, identifying if there is a need to wrap the code to make it usable by non-Java components. Use the flow chart to determine how to re-use your existing Java. Depending on your answers to the questions in the flow chart, it will suggest if you need to create a Java bean wrapper for your resource to convert parameter and return types into simple Java types and Java beans. It will also identify how the resource should be consumed within the SOA Suite, such as by an EJB reference or as a Spring component.
SOA Suite is generally concerned with orchestrating services together, but it can also be used to implement the services. Sometimes, we have existing interfaces that need a concrete implementation behind them that may best be provided in a 3GL, such as Java. In this scenario, instead of writing a Java web service, deploying it, and operating it separately to our SOA infrastructure, it may be better to implement the interface in a Spring component inside an SOA composite. This keeps the service in a managed environment while taking advantage of Java.
Sometimes, we need to access information about the composite or BPEL process that is exposed through Java APIs but not available through built-in XPath functions. We could use custom XPath functions to access this information, but sometimes we want quick, one-off access that will not be re-used. In this case, we can use a Java Exec activity in a BPEL process to execute Java code as part of our BPEL process. This code has access to the BPEL and composite environment.