TwinTechs

With the proliferation of LiveCycle Data Services, it surprises me that there has not been more attention paid to the creation of a Java framework for standard three tiered implementations of LCDS. Of course, in a perfect world, the application tier development should be completely agnostic to your service and UI tiers. However, long term, you can save yourself a lot of headaches if you think about the consequences of an application’s service tier and UI tier architectures. The most obvious case of this is how assemblers execute updates for all clients

As far as I know, the only application tier framework option available that is tailored to LCDS is the Adobe LCDS Hibernate plug-in. However, when using this framework, it quickly becomes apparent that it is not a good solution for enterprise level applications. Reason: the Hibernate plug-in makes the application tier little more than a transportation layer. Using the Hibernate plugin-in, one is effectively creating a client server application. This can be troublesome on many fronts, such as:

• You can’t always assume the only consumer of the application tier is going to be a Flex client. Web Services and a “classic” or “ajaxy” HTML front end may also need to be implemented.
• No business logic can be implemented on the middle tier and consumed across clients. All business logic must be implemented in the database and/or client.
• Security becomes very complicated.
• Hibernate is not good for bulk data transfers (example: reporting). It specializes in transactional operations.

Due to the lack of options available and lack of development time to come up with a clean architecture, my experience has been that the middle tier architectures of most LCDS applications are not well thought out. LCDS applications generally result in some sort of standard DAO and entity implementation (probably Hibernate) coupled with bloated mapping classes to handle all entity to value object creation. Business logic tends to be sprinkled in between the mappings and is not abstracted at all. This type of architecture (or lack thereof) might work well during the prototyping phase. However, it quickly becomes unwieldy and error prone.

To resolve the architectural problems I’ve seen, I came up with a personal framework that I use for LCDS application development. It covers the entire application tier from DAO’s and Entity Beans to the assemblers and value objects that are being passed back to the UI.

The goal of the framework was to speed up development, follow generic patterns, minimize bugs and ensure a flexible enough solution to fit any type of application. Ease of use was important but not the most critical requirement. I find that each application I write is slightly different and the framework needs to be generalized a little more for each project needs. The framework is meant to solve the common problems one faces and not every problem.

To get a high level overview of the framework and its usage, check out the document posted here.

Next Steps: The framework is still evolving, and there are some features I will likely need to add for future projects. Some big extensions that may need to be added are:

• Utilization of the java scripting engine in 1.6 for writing business rules in JavaScript. This allows easy customization of the business rules without requiring a system restart.
• Creation of an ActionScript rules engine that can leverage the same JavaScript rules in the application tier. This saves writing validation scripts on both the client and server side (Think email address).
• Further streamlining of some of the mapping files, and removing full package names where possible by keying off of directory locations instead of mapping files.
• Creation of a Web Service DAO Factory and a JDBC DAO Factory.
• Creation of a generic web service client.
• Usage of Session and Entity Beans in EJB3.

If you are at all interested in the framework, feel free to shoot me an email at michael.korthuis@twintechs.com and we can talk about it further.