Archive for September, 2008

We are building a sizable new Flex-based mapping application to support our internal Endorsed Local Provider program. We are passing a significant amount of data between Flex and ColdFusion. So, we architected a service layer that exposes the interface between Flex and CF, and are using BlazeDS to allow us to link Java-based data transfer objects (DTO) on the server side to equivalent Actionscript objects in Flex.

We chose to use Java DTOs rather than CFCs because we found that the Java versions were 15-20 times faster on ColdFusion server. For example, a loop through 1,000 records takes an average of 1.5 seconds:

I created a custom Java class that generates the Actionscript DTOs from the Java DTOs. We had no trouble sending Java objects to Flex with ColdFusion services through BlazeDS where the parameters passed from Flex were built-in objects, like Strings, Numbers, or Maps. However, when calling a method from Flex that passed one of our custom DTOs as a parameter, the server reported the following error: “Unable to invoke CFC – Could not find the ColdFusion Component or Interface”.

It turns out that if you use ColdFusion services through BlazeDS, meaning that you are using the “cf-object” adapter in your remoting-config.xml, BlazeDS only links ActionScript DTOs with ColdFusion CFC objects on the server. You have to use the “java-object” adapter for it to link Actionscript DTOs to their Java counterparts, but then you have to build your entire service layer in Java, instead of ColdFusion.

Here’s an example of the kind of objects we’re talking about. We have a service method called getPolygons(BoundingBox bb). Flex passes a BoundingBox object, which contains two LatLng objects, and the server returns all of the zip code polygons in that box.

The key to BlazeDS’s ability to link the Actionscript to the Java object is the [RemoteClass(alias="...")] block. From ColdFusion to Flex, a BoundingBox or any other custom object is automatically serialized by BlazeDS and all is well. The problem is going from Flex back to CF with Java DTOs.

To address this, we tried doing some enhancements to the built-in deserialization code, wrapping a ColdFusion DTO around a Java DTO, and decompiling coldfusion.flash.messaging.ColdFusionAdapter to figure out how to make it load Java DTOs. After weighing these ideas we decided to try serializing our Actionscript DTOs into JSON before sending them to ColdFusion. This turned out to be a relatively pain-free solution that maintained our desire to use matching objects on the client and server.

Details

First, we found Adobe’s as3corelib, which includes very handy methods for serializing any object into JSON. Once you download their libraries and include them in your Flex project, it’s as simple as:

import com.adobe.serialization.json.JSON;
JSON.encode(yourObj);

To decode them, we found JSON-lib on SourceForge. Once you have it installed in ColdFusion (see below) you can add a function like this in your Java DTO:

Since the BoundingBox object includes properties that are also custom objects, you have to provide a Map that links the property names to the classes, so that JSON-lib can generate the object from the input JSON. This is very handy, and can be called in ColdFusion like this:

One of the first tasks put on my plate when I started as an e-learning developer here 3 years ago was to research our options for taking the various forms of classroom-based training offered here online. I had experience with various Learning Management Systems, so I jumped in with both feet, installing and testing a wide range of systems.

We had a few immediate needs for a simple LMS system, one that would track a user’s progress through a simple video course, but we needed to make sure that the solution we chose would be able to grow with us as we expanded our e-learning course catalog.

One thing that was certain was that we wanted to have the ability to use SCORM or AICC compatible learning modules. This would allow us to bring in third-party courses to offer to both internal and external customers.

As we examined each option, a few things began to stand out.

If we went with a proven, feature-rich system, we would be getting way more than we needed, especially at first. These came with a huge price tag as well.

Using an open source solution alleviated the price issue, but we couldn’t be certain that we could get the support we would need. Even as we were researching open source options, we noticed several that seemed to have been abandoned and had no community support to speak of.

Hosted solutions like Breeze didn’t give us the flexibility we wanted. Since we were just getting started with our LMS, we knew we would learn some lessons as we went (so to speak) and would want to expand in a relatively uncharted area of e-learning (personal finance).

As we talked with experts in the LMS arena, we started considering the advantages of building our own custom LMS from the ground up.

First, we could pick and choose the features we needed and build them as we needed them. This was a big plus, as Dave is big on starting small and growing your business as the need and opportunity are available.

Second, we would never be paying for features we didn’t need, as would likely be the case with out-of-the-box solutions.

Third, we have one of the most talented group of developers in Nashville, certainly in the state, and likely, in the nation. We knew that we could produce a better product than any vendor. Why not set the bar high and turn us loose on it?

So that’s what we chose to do. We brought an expert with years of experience in the e-learning industry on board, locked him in a room with some of the top software development and systems architecture people in the industry, and our LMS was born. At least in concept.

What we got was a scaleable, extensible system that is being improved every day and running underneath FPU Online and the Bankruptcy Education systems.