9.6. Advanced Strategies for Custom Adapter Creation

From Chapter 7, which covered Flex and Hibernate integration, you are familiar with a few advanced adapters, which in that particular case worked within the semantics of Hibernate, the object-relational mapping tool.

One of the adapters illustrated there is the Gilead Hibernate PersistentAdapter. The Gilead PersistentAdapter extends the built-in JavaAdapter. In its invoke method, the PersistentAdapter stores the Hibernate POJO in the HTTPSession (if the adapter needs to maintain state) and then merges the input parameters from the remoting message before it calls the invoke method of the JavaAdapter. This adapter class relies on the JavaAdapter for the standard instantiation and invocation functions and just adds the value-added functions on top of what is already present in a JavaAdapter.

Going with this use case, a ready piece of advice is to leverage existing adapters for standard features, especially if your adapter also needs them.

An adapter class is a Java class, and you can call any Java code from within it. Sometimes, an adapter needs to work exhaustively with the API of the destination, as is the case with a JMSAdapter. In such cases, the complexity is in the target destination interaction and not in the adapter itself.

An adapter is instantiated and managed within a Servlet container, so it's advisable not to include any direct threading within that code. Also, for the sake of clean design and clear separation of duties, remember to keep all external resource access code in classes separate from the adapter class.