Some questions and answers on using HibernateAssembler, EJB3/JPA in Flex/LiveCycle Data Services applications

Some days ago on the Comtaste's blog  we published an article on LiveCycle Data Services and Hibernate integration in Flex RIA applications.

I found an interesting comment that gave us the possibility to goo deep into that topic :

I'm currently investigating the use of LCDS 2.5 and EJB3/JPA and am wondering about a couple of things.
First - would it be likely that in the near future we would have a JPAAssembler class, much like what Jeff has been doing with Hibernate?

Second - if not a JPAAssembler, what would be the best way of wiring data management to JPA?

Third - do I really need a DTO, can't I just 'return' domain objects, and how does this work with lazy loaded instances as set by JPA annotations.

Fourth - conceptually I've been thinking about this quite a lot. Looks to me that datamanagement is specifically geared towards CRUD like applications. But what if the use case at hand requires some more involved server side processing, most likely contained within a JTA transaction. Shoud I instead implement this as a RPC call and thus mix 'n match RPC and DM?

You can read the reply on the next page >>

The HibernateAssembler that provides support for hibernate entities as flex destinations in Flex Data Management Services (flex.data.assemblers.AbstractAssembler)
HibernateAssembler deals mainly with data management operations such as fill collections of data or working with single items.
I am not aware if the existence of a JPAAssembler or alike; EJB entities and session beans are generally managed within the container while Hibernate POJOs can basically be deployed about anywhere.
There are, of course, ways of calling EJB3 session beans directly from the Flex client, through a LiveCycle Data Serivces layer, such as using the FlexFactory (flex.messaging.FlexFactory). The FlexFactory interface is implemented by factory components that provide instances to the Flex messaging framework.
LCDS can be configured to perform automatic EJB lookup. Or, instead of using a HibernateAssembler look alike, a solution might be creating ad hoc flex assemblers, by implementing the flex.data.assemblers.AbstractAssembler interface, but it depends on your particular scenario and use case. You can have a look at the example on the LiveCycle documentation that shows the source code for the CompanyAssembler class, which is part of the CRM application included in the samples web application :

http://livedocs.adobe.com/flex/201/html/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Book_Parts&file=data_collection_config_106_11.html

Using DTO or direct EJB3 POJO, again, depends on the application; if the EJBs use lazy fetching for their associations, it can create problems when sending one of those objects: if one sends only the POJO, the lazily fetched association is not being sent and an attempt to load it "later" will result in exceptions, as the request will come after the EJB session was closed. In this case it would be useful to use a DTO that packs all the data in the POJO together with the lazy collection, but it would be just like the collection were eagerly fetched.
Basically one could use lazy fetch for the operations within the container, defining a layer of business logic and creating session beans that can be accessed from the Flex client through the LiveCycle Data Services.

Comments

[robi]

I think this statement is a little confusing

"EJB entities and session beans are generally managed within the container while Hibernate POJOs can basically be deployed about anywhere.
There are, of course, ways of calling EJB3 session beans directly from the Flex client, through a LiveCycle Data Serivces layer, such as using the FlexFactory (flex.messaging.FlexFactory). The FlexFactory interface is implemented by factory components that provide instances to the Flex messaging framework."

In that it seems to imply that you need a container to do EJB3 /JPA which you do not. I am not sure thats what you intend to say.