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.
Marco Casario is one of the most dynamic developers in the Adobe (formerly Macromedia) world. Flex and FlashLite certified Instructor, Flash and Dreamweaver certified, he intensively collaborates with Adobe Italy as a speaker and promoter of several events and roadshows. Marco has recently founded Comtaste S.r.l., a company dedicated to explore new frontiers in the Web 2.0 field, where the themes of accessibility and usability have added further importance to the PDF format and the relevant Acrobat application tools.
