Extensibility Using Java Callouts and POJOs

To allow you to extend the capabilities of AquaLogic Service Bus in your organization, you can invoke custom Java code from within proxy services. AquaLogic Service Bus 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 AquaLogic Service Bus Console at design time; the parameters can be mapped to message context variables.

For information about configuring a Java Callout to a POJO, see "Java Callout" in Proxy Services: Actions in Using the AquaLogic Service Bus Console.

Usage Guidelines

The scenarios in which you can use Java Callouts to POJOs in AquaLogic Service Bus include the following:

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 AquaLogic Service Bus 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.

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 AquaLogic Service Bus. 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 AquaLogic Service Bus 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 Guide

Extensibility Using Java Callouts and POJOs

Usage Guidelines

Best Practices