TwinTechs

I recently had the opportunity to integrate the Adobe Flash Collaboration Service, also known as AFCS, with another application.  For those of you that don’t know, AFCS is a hosted Adobe service that gives Flex developers the ability to easily add real-time social capabilities directly into an application.

Getting Started:

Although it’s still in Beta, the product team at Adobe has done a great job with documentation and has released a slew of sample applications. Setting up an initial “Hello World” AFCS project with webcam, text chat, and a white board support can be done in less than an hour. The Adobe “Hello World” code sample is here.

Getting Down and Dirty:

As we all know, sample applications always work perfectly. But if you are trying to do something a little off piste…  well… many times, things can get a bit dicey.  Our application’s requirements resulted in us extending the base AFCS functionality a fair amount.   These extensions can be summed up into two distinct groups:

1. Storage of additional data in AFCS.
2. Enhancements/additions to the current AFCS components (pods).

Storing additional data in AFCS

Luckily, storing additional data in AFCS is easy.   AFCS has a three-deep level data hierarchy,  including:

1. Collection Node: The highest level.  Collection Nodes wrap up functionality stored in components/pods and consist of a collection of nodes.
2. Node: Second Level.   These generally wrap up functionality to a certain section, e.g. a history of a chat window and consist of a collection of message items.
3. Message Item: Lowest level.  Message Item’s support both primitives and simple objects.

In addition, there is a whole bunch of additional goodness relating to all of these data structures including private messaging, session management, and user management.  Also, there is a rather extensive security model that allows you define read/write permissions at a granular level.

Retrieving data and notifying clients of data changes was very easy and the Nodes operated in much the same way as Shared Objects do in Flash Media Player. There were events notifying clients of both data changes as well as synchronization with the server.

I did find a couple of downsides with the data model. Creating a collection node requires owner permissions and  this ended up being a problem as our application had clients trying to dynamically add instances of pods. In addition, the data model is not N deep. This could be troublesome with some data sets, i.e. you want to store the data in nodes as a BST.

Extending AFCS Components

Extending the base components, while not particularly hard, is a little time consuming and does force a developer to get his hands dirty. Fortunately, the developers at Adobe followed some coding rigor and separated most of the pods into two components, model and view. Thus, if you only have to change the L&F of a component and not necessarily its underlying functionality, you can get away with just extending the view component.

In our case, we had to update both the model and the view components. This resulted in reading and understanding the individual components and updating them as necessary.

In hindsight, it might have been prudent to just write our own components.  Once you are comfortable with the API and its functionality, it is easy enough to write your own custom components and interface with AFCS.

Final Thoughts:

Overall, I was very impressed with AFCS and I think it has potential.  The ability to generate an application that gives you chat, webcam, and whiteboard functionality instantly is great. In addition, being able to develop Flex components without the fuss of configuring and installing (not to mention developing!) an app server is a huge plus. Recommendation to Adobe: a desktop sharing component would make this a killer service.

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.