7.6. BlazeDS Adapter for JPA and Hibernate
This section explains facets of a JPA and Hibernate adapter for BlazeDS and walks through some of the core concepts involved in writing such an adapter.
Writing a JPA or Hibernate adapter involves two distinct tasks:
Writing to the BlazeDS API so that the adapter can hook onto the existing infrastructure
Incorporating the JPA and Hibernate semantics so that the behavior is consistent and the benefits of JPA and Hibernate are leveraged
Chapter 9 explains the nuances of writing an adapter in detail, so I will not repeat the same content here. The only point worth mentioning is that a Hibernate adapter could best be written by extending the built-in JavaAdapter. If you want to learn more, then jump over to Chapter 9 and come back after reading it.
In this section, the focus is on understanding the complexities involved in incorporating the JPA and Hibernate semantics. JPA and Hibernate return persistent entities and their collections with built-in proxy, which as its name suggests sits in place of the real data. The proxy helps lazily load data sets and provides for efficient management of entities and their collections. These entities and their collections lie within a JVM. When you integrate these persistence layers into a Flex application, you expose these entities and their collections to a language and environment beyond what they are scoped for.
BlazeDS is capable of serializing and transforming Java-based objects to their AS3 counterparts so that you may wonder why taking these entities and their collections needs any special handling. This is where you will benefit from understanding how BlazeDS carries out the serialization and the translation between the two environments.
BlazeDS has a set of endpoints where a Flex application channel sends requests up to BlazeDS that resides within a Servlet container or an application server. Responses from BlazeDS follow the route back up from the endpoint to the channel. On endpoints that support translation and serialization between AS3 and Java (or even web services), a serialization filter is defined to intercept calls to the endpoint. When an incoming or outgoing message hits the filter, serialization and deserialization occur with the help of a MessageSerializer and a MessageDeserializer.
During serialization, the serializer eagerly fetches all the JPA and Hibernate persistent objects and sends them across the wire. The JPA and Hibernate proxies are replaced with the data that they stand in place of. This breaks the lazy loading semantics, rendering the idea of proxies useless. Therefore, any Hibernate adapter needs to preserve the proxy characteristics while keeping the standard behavior of the essential serialization and de-serialization mechanism between Flex and Java intact.
A common design pattern used to solve this problem is what I like to call the "Clone and Merge Transfer Pattern," CMTP for short. The fundamental tenets of CMTP are shown in Figure 7-14.
Figure 7.14. Figure 7-14
The cornerstones of this pattern are the clone and merge operations. On the way from the Java server side to the Flex client, a persistent object with proxy-based references is cloned, and the clone is sent to the serializer-deserializer, which in turn converts it into an AS3 object. This object reaches the Flex client. In the reverse direction, an AS3 object, after being converted to Java, is merged back to the original persistent object. One important requirement for the merge operation to work successfully is that you keep a copy of the original object when it's cloned. This copy can be maintained on the server or within the class locally.
When the copy of the object is stored on the server, the HTTP session seems like the best place for it. Keeping an application scoped and shared areas may make the object visible beyond its rightful owners.
When the copy is maintained locally, you need to have a structure within the class for it. This is where you require entities to extend specific classes that accommodate for this structure. One could leverage Aspect-Oriented Programming (AOP) to induce such behavior at runtime and keep persistent objects from extending a specific class or have them adhere to a specific API. The sidebar provides a few links and references to AOP.
Aspect-Oriented Programming (AOP)Aspect-oriented programming (AOP) is a programming paradigm that enhances modularity by enabling improved separation of concerns. Object-oriented programs are partitioned along distinct functions or concerns. Some of these concerns are abstracted as independent modules and objects, while a few others such as logging or security are cross-cutting in nature. AOP encapsulates each concern independently into aspects and allows interception points within classes and methods, which it operates on. An aspect can modify the behavior of a class by applying an advice or additional behavior at various join points specified in an expression or query called a pointcut. An aspect can also make byte code compatible structural changes to classes. It can add members or parents to a class. AspectJ is a leading AOP implementation for Java. Details can be accessed online at www.eclipse.org/aspectj. If AOP is something you know little or nothing about then start by reading the 3 part JavaWorld article series titled: "I want my AOP!" The links to the three-part article series are:
AOP is gaining popularity ever since it first appeared. The popular Spring Framework also supports AOP. |
You will learn later that the Gilead Flex BlazeDS Hibernate adapter follows many of these enlisted principles. The "dsadapters" Hibernate adapter also embodies all these principles. In addition, as far as I know, the BlazeDS adapter from dsadapters is the only adapter that leverages AOP for runtime object manipulation.
As you will learn in Chapter 9, the invoke method of an adapter class is the place where all the adapter logic resides or is called from. A message sent to an adapter triggers a call to the invoke method.
In addition to appropriately handling lazy collections, an adapter may also provide services for data management, which is discussed in the section before the summary, later in this chapter.
Now you have a sense of how to write your own adapter, but you don't necessarily need to jump into writing one of your own. There are a few open source options that you could use.