Extensibility Using Java Callouts and POJOs

To allow you to extend the capabilities of ALSB, you can invoke custom Java code from within proxy services. ALSB supports a Java exit mechanism via a Java callout action that allows you to call out to a Plain Old Java Object (POJO). Static methods can be accessed from any POJO. The POJO and its parameters are visible in the ALSB Console or ALSB Plug-in for WorkSpace Studio at design time; the parameters can be mapped to message context variables.

You can also use Java callouts to create Java objects to store in the pipeline and to pass Java objects as parameters to other Java callouts.

“Java Callout” in Proxy Services: Actions in Using the AquaLogic Service Bus Console
Adding and Configuring Java Callout Actions in Using the AquaLogic Service Bus Plug-in for WorkSpace Studio

Usage Guidelines

Custom validation—Examples of custom validation include validation against a DTD, or doing cross-field semantic validation in Java.
Custom transformation—Examples of custom transformations can include converting a binary document to base64Binary, or vice versa, or using a custom Java transformation class.
Custom authentication and authorization—Examples of custom authentication and authorizations include scenarios in which a custom token in a message needs to be authenticated and authorized. However, the authenticated user’s identity cannot be propagated by ALSB to the services or POJOs subsequently invoked by the proxy service.
Lookups for message enrichment—For example, a file or Java table can be used to look up any piece of data that can enrich a message.
Binary data access—You can use a Java callout to a POJO to sniff the first few bytes of a binary document to deduce the MFL type. The MFL type returned is used for a subsequent NonXML-to-XML transformation using the MFL Transform action.
Implementing custom routing rules or rules engines.
Create a Java object and store it in the pipeline.
Pass a Java object as a parameter to another Java callout.

The input and return types for Java callouts are not restricted. However, any return types other than primitives, Strings, or XmlObjects can only be passed (unmodified) to other Java callouts. See Java Content in the body Variable for more information about storing and passing Java objects in the pipeline.

Enterprise JavaBeans (EJBs) also provide a Java exit mechanism. The use of EJBs is recommended over the use of POJOs in the following cases:

When you already have an EJB implementation.
When you require read access to a JDBC database—Although POJOs can be used for this purpose, EJBs were specifically designed for this and provide better support for management of, and connectivity to, JDBC resources.
When you require write access to a JDBC database or other J2EE transactional resource—EJBs were specifically designed for transactional business logic and they provide better support for proper handling of failures. However, transaction and security context propagation is supported with POJOs and they can be used for this purpose.

For outbound messaging, BEA recommends that you write a custom transport instead of using POJOs or EJBs.

Best Practices

POJOs are registered as JAR resources in ALSB. For information about JAR resources, see JARs in Using the AquaLogic Service Bus Console.

In general, BEA recommends that the JARs are small and simple—any large bodies of code that a JAR invokes or large frameworks that are made use of are best included in the system classpath. Note that if you make a change to the system classpath, you must reboot the server.

BEA recommends that you put dependent and overlapping classes in the same JAR resource; put them in different JARS if they are naturally distinct. Any change to a JAR causes all the services that reference it to be redeployed—this can be time consuming for your ALSB system. The same class can be located in multiple JAR resources without causing conflicts. The JARs are dynamically class loaded when they are first referenced.

A single POJO can be invoked by one or more proxy services. All the threads in the proxy services invoke the same POJO. Therefore, the POJO must be thread safe. A class or method on a POJO can be synchronized, in which case it serializes access across all threads in all of the invoking proxy services. Any finer-grained concurrency (for example, to control access to a DB read results cache and implement stale cache entry handling) must be implemented by the POJO code.

User’s Guide

Extensibility Using Java Callouts and POJOs

Usage Guidelines

Best Practices