Andrew Powell

Here are the slides from my presentation this week at 360Flex.  I should have the updated samples into the SVN repository later this week.

http://static.infoaccelerator.net/files/FlexServerLib.pdf

A lot of people think that BlazeDS (and LCDS, for that matter) is a server.  They think it's something that you can deploy, like ColdFusion, and write apps on it.  Not quite, the case, but not too far off either.

BlazeDS is not a server.

Let's say that again, so you understand it.  BlazeDS is not a server.

BlazeDS is a set of servlets and listeners that you can add to your J2EE web application to access your service layer via the AMF protocol.  You don't deploy BlazeDS on its own unless you want to do purely messaging.  90% of deployments are done as part of a larger web project.  BlazeDS is simply another tool that you can use to expose your services to AMF clients (not just Flex).  

Further proof that BlazeDS exists as part of the J2EE ecosystem came late last year when SpringSource announced Spring/BlazeDS Integration.  This virtually removed the MessageBrokerServlet from the equation, routing messages through Spring's MVC architecture instead.  BlazeDS, the guts of it at least, was still responsible for the leg work in processing the AMF requests, but the easy integration into the Spring Framework really made it apparent that BlazeDS is not a server.

Lastly, BlazeDS is easy to incorporate into ColdFusion.  ColdFusion is, at it's roots, a J2EE web app.  BlazeDS is just another piece you can integrate into the web app to enable access to Java and CFC services via AMF.

Any questions?

Russell Ackoff was an organizational theorist who pioneered a lot of modern theories in "systems thinking".  He was able to classify the content of the human mind into five categories that build upon each other:

1. Data - raw symbols; numbers, text, etc.
2. Information - processed data to be useful
   1. usually provides answers to: who, what, where, and when
3. Knowledge - applying data and information to answer the "how" of the system
4. Understanding - an appreciation of the "why" of the system
5. Wisdom - an evaluated understanding of the system

Data visualization is changing.  Everyone has analyzed their data over time since the beginning of data analysis.  Does this purely temporal approach to data analysis tell the whole story of your data, or does it tell just a  narrow perspective?  If you could have more insight into your data and analyze it in more than a temporal space, wouldn't your data yield more useful information?  A good number of data sets have a geographic component to them that is easily adaptable to a mapping solution.  SpatialKey unlocks that aspect of your data and lets you visualize your data over both geography and time.

Modern systems, for the most part, limit the answers of information to who, what, and when.  SpatialKey, changes that by providing a new insight into the where aspect of Information via the map.  SpatialKey's primary strength is that it allows you to easily visualize large amounts of your data over both space and time while mapping the results and rendering a timeline.  This opens new insights and enhances the knowledge derived from the information presented by SpatialKey.  This is information that might not be derived from traditionally visualized data sets.

The information unlocked by SpatialKey  creates a new knowledge that would not be available otherwise.  The knowledge can lead to a new understanding of the trends in the data system, both temporal and spatial.  Practically, this means that, for example, instead of seeing sales trends over time, you can now have new visual insight into sales trends over time by a given geographic area.  

SpatialKey is the new standard for data visualization.  It will help you to unlock new perspectives into you data, like never before.  If you would like to experience SpatialKey, you can sign up for the private beta and use SpatialKey for yourself.  The private beta is limited to datasets of 10,000 rows, but the actual application can handle datasets of over a million rows.  

After you signup for the beta, import your data, or get some sample data from geocommons.  Once imported, SpatialKey can geocode your data and get you started with data visualization like you've never seen before.

If you want to learn more about SpatialKey, you can head over to the SpatialKey website. 

About a year ago, it seems like parts of the ColdFusion community really took to my idea of running Spring and Hibernate inside of ColdFusion (see this link for the materials). Some people, like Joe, took the concept to heart and really ran with it. Some very cool things have been done with the concept, like Groovy integration, etc. That's all well and good, but shortly after I gave that presentation at cf.Objective() last year, I got to thinking: "If ColdFusion is just a J2EE app, why am I even using ColdFusion in this setup and not straight-up Java?".

Since that time, I've been focused on creating Flex/AIR apps with BlazeDS, Java, Hibernate, and Spring all in the mix. ColdFusion, though, still has a place in the core application stack. I've not abandoned it, totally. Why? Well, ColdFusion still easily provides services and functionality that are, quite frankly, a pain in the ass to leverage in Java, even with Spring. I have come to realize that while CFML is not the greatest application of pure OO principles and CFCs really just irritate me more than anything else (more on that in another post), it is still pretty handy for other things like:

• PDF functionality
• Exchange Server integration
• Image Manipulation
• Presentation Generation
• Report Writing
• Email Services

Granted, there are some things on that list that Spring makes easier than Java without Spring, but at the end of the day, it's still not as simple as doing it with CFML. That being said, I try to keep all of my data persistence, and other business logic within my Java app, but at the same time, make ColdFusion available to Flex (via AMF) for those "special services". At the end of the day, it's not a matter of building your application in ColdFusion vs. building your application in Java, it's simply finding the balance of what works best from both environments.

I'm not anti-ColdFusion in anyway, nor is ColdFusion "dead", like some have suggested. ColdFusion's role in the modern web application stack has just changed, for me. Adobe makes it possible for you to use ColdFusion as your only platform, but also enables you to use it as a provider of specialized services to your application. I don't like to think that I am only limited to ColdFusion as my application platform. I like to think of ColdFusion as another piece of the total puzzle for my solutions. It's just not the same piece it was for me 18 months ago.

Register For cf.Objective()

The past two years, I have spoken at cf.Objective() on mostly ColdFusion topics with a little JavaEE and AJAX thrown in for good measure.  This year however, is different.  I'm going to be speaking on a topic near and dear to my heart:  Merapi.  For those of you who don't know, Merapi is a bridge that lets you talk to Java applications running on the desktop via AIR or Flex.  These presentations aren't really slide heavy, but they're very demo heavy.  So, if you want to see, amongst other things, JoJo the Merapi robot, come to this session.  Other demos I will show include:

• AIR & GPS
• AIR & RFID
• AIR & MS Office
• AIR & Hibernate
• AIR & Text To Speech
• AIR & Translation Engine

Register For cf.Objective()

Flex Camp Miami, that is.  Yeah, I know it's all Miami Vice'd up on the site, but I couldn't help using the awful Will Smith reference.

Register Now

I will be speaking at Flex Camp Miami on March 6th, 2009, along with a list of other, better known, names.  This really isn't so much a Flex 101 type event as they have been in the past, but will touch on a wide array of skill-levels and give you a good feel as to what you can do with Flex and AIR.  Among the speakers slated, other than myself, are:

• David Tucker
• Maxim Porges
• Brian LeGros
• Laura Arguello

This question has come up to me a number of times lately.   People are concerned that the Spring BlazeDS Integration will mean an end for FlexServerLib.  This couldn't be further from the truth.  There are two main reasons why this is not the end of FlexServerLib:

1. FlexServerLib Extends BlazeDS - The goal of FlexServerLib is to extend BlazeDS. Extending it does not just mean tight integration with Spring.  Yes, we do use Spring for a lot of what's going on under the hood, but that's more of a testament to the power of Spring than an indictment of FlexServerLib.  There are some things that Spring's project just won't do, like a MailDestination for Messaging.  Granted, we may port our solution to both stand alone BlazeDS and the Spring-integrated solution, but it is independent.  We are focused on extending BlazeDS, not just exposing destinations via Spring Beans (although that is nice).
2. Not Everyone Is Using Spring - As much of a shock as this can be, not everyone in the Java world is using Spring.  Some of our functionality that Spring will do easier, is not available to those using...say....EJB.  Well, we provide an easy way to expose EJBs as Flex RO destinations.  There is still a market for extending BlazeDS.

FlexServerLib , the extension project for BlazeDS, is a powerful library that allows you to access functionality on the server, in Flex, as easily as ColdFusion allows developers to access complex server functionality in CFML.  Imagine if sending an email was as easy as sending a message into a destination and receiving an email was as simple as subscribing to the same destination.  This is just some of the functionality FlexServerLib aims to implement.

A topic has been submitted on FlexServerLib for 360|Flex Indianapolis, but if you want to learn more, we need your vote.

Follow this link to vote

The Problem:

When using Hibernate as your persistence layer, it allows you to create lazy collections. This is nice because lazy collections can speed up your application, and in theory, you only access the data you want to access. Simple enough. The problem lies however in talking to Flex applications, specifically via BlazeDS or LiveCycle DS. What happens is the fault of the serializers. When you make a request, via mx:RemoteObject, to the server, and you are accessing a lazy collection, when the serializer attempts to turn the data from Java to AMF, it touches everything. This "unwelcome touching" by the serializer, in turn, triggers all of your lazy loading to fire, therefore rendering your lazy collections and the effort to set them up, useless. So, with that in mind, how do we pass back only the data we want to pass back?

The Solution

Let's consider the following value objects:

package com.universalmind.samples.lazyloadIssue;
   import org.hibernate.annotations.Entity;
   import java.util.UUID;
   /**
    * Copyright (c) 2008 Universal Mind Inc.
    * Created by IntelliJ IDEA.
    * Created By: Andrew Powell
    * Date: Dec 9, 2008
    * Time: 11:44:37 AM
    */
   @Entity
   public class Item implements AMFSerializable {
    private UUID id;
    private String sku;
    private String name;
    private String description;
    public Item() {
    }
    public UUID getId() {
    return id;
    }
    public void setId(UUID id) {
    this.id = id;
    }
    public String getSku() {
    return sku;
    }
    public void setSku(String sku) {
    this.sku = sku;
    }
    public String getName() {
    return name;
    }
    public void setName(String name) {
    this.name = name;
    }
    public String getDescription() {
    return description;
    }
    public void setDescription(String description) {
    this.description = description;
    }
    public Item cloneForAMF() {
    Item item = new Item();
    item.setDescription(description);
    item.setId(id);
    item.setName(name);
    item.setSku(sku);
    return item;
    }
   }

package com.universalmind.samples.lazyloadIssue;
   import org.hibernate.annotations.Table;
   import javax.persistence.Entity;
   import javax.persistence.ManyToMany;
   import javax.persistence.FetchType;
   import java.util.UUID;
   import java.util.Date;
   import java.util.ArrayList;
   /**
    * Copyright (c) 2008 Universal Mind Inc.
    * Created by IntelliJ IDEA.
    * Created By: Andrew Powell
    * Date: Dec 9, 2008
    * Time: 11:43:09 AM
    */
   @Entity
   public class Order implements AMFSerializable {
    private UUID id;
    private Date date;
    private ArrayList items;
    public Order() {
    }
    public UUID getId() {
    return id;
    }
    public void setId(UUID id) {
    this.id = id;
    }
    public Date getDate() {
    return date;
    }
    public void setDate(Date date) {
    this.date = date;
    }
    @ManyToMany(targetEntity=Item.class,fetch= FetchType.LAZY)
    public ArrayList getItems() {
    return items;
    }
    public void setItems(ArrayList items) {
    this.items = items;
    }
    public Order cloneForAMF() {
    Order clone = new Order();
    clone.setDate(date);
    clone.setId(id);
    return clone;
    }
   }

These two value objects are related in the sense that there is a many-to-many relationship between Order and Item. An Order can have many Item instances and a Item can belong to many Order instances. There is another piece in there as well. Both of these implement the AMFSerializable interface, listed below:

package com.universalmind.samples.lazyloadIssue;
   import java.io.Serializable;
   /**
    * Copyright (c) 2008 Universal Mind Inc.
    * Created by IntelliJ IDEA.
    * Created By: Andrew Powell
    * Date: Dec 9, 2008
    * Time: 12:16:37 PM
    */
   public interface AMFSerializable extends Serializable {
    public Object cloneForAMF();
   }

This interface extends java.io.Serializable which is needed for AMF serialization. It also adds one method: cloneForAMF(). This method allows you to create a copy of the object that is free from Hibernate proxies and only contains the data that you want to send back to Flex. The next trick, however, is invoking that method once your business logic completes.

Let's say we have a simple, Hibernate and Spring enabled, data access object:

package com.universalmind.samples.lazyloadIssue;
   import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
   import org.hibernate.criterion.DetachedCriteria;
   import org.hibernate.criterion.Restrictions;
   import java.util.*;
   /**
    * Copyright (c) 2008 Universal Mind Inc.
    * Created by IntelliJ IDEA.
    * Created By: Andrew Powell
    * Date: Dec 9, 2008
    * Time: 11:42:55 AM
    */
   public class OrderDAO extends HibernateDaoSupport {

    @SuppressWarnings("unchecked")
    public ArrayList getTodaysOrders(Date yesterday, Date tomorrow){
    DetachedCriteria criteria = DetachedCriteria.forClass(Order.class);
    criteria.add(Restrictions.gt("date",yesterday));
    criteria.add(Restrictions.lt("date",tomorrow));
    return (ArrayList) this.getHibernateTemplate().findByCriteria(criteria);
    }
   }

The method we're going to call, getTodaysOrders is going to return an ArrayList, given a set of criteria. Pretty simple. Between the time this method executes and the time it hits the serializer, within the RemoteObject call, we want to prep our data with the cloneForAMF() method that we created on our value objects. Since we're using Spring, we can leverage the power of Aspect-Oriented Programming to accomplish this task. In order to accomplish this with AOP, we need to implement advice both before and after the method in question. Implementing this "around advice" is easy using the MethodInterceptor class, as shown below:

package com.universalmind.samples.lazyloadIssue;
   import org.aopalliance.intercept.MethodInterceptor;
   import org.aopalliance.intercept.MethodInvocation;
   import java.util.ArrayList;
   /**
    * Copyright (c) 2008 Universal Mind Inc.
    * Created by IntelliJ IDEA.
    * Created By: Andrew Powell
    * Date: Dec 9, 2008
    * Time: 12:12:37 PM
    */
   public class PreSerializationInterceptor implements MethodInterceptor {
    public Object invoke(MethodInvocation methodInvocation) throws Throwable {
    if(methodInvocation.getMethod().getName() == "getTodaysOrders"){
    ArrayList persistentCollection = (ArrayList) methodInvocation.proceed();
    ArrayList serializedCollection = new ArrayList();
    for(Order order : persistentCollection){
    if(order instanceof AMFSerializable) serializedCollection.add(order.cloneForAMF()); }
    return serializedCollection;
    }
    else{
    return methodInvocation.proceed();
    }
    }
   }

This code will first make sure we're executing the method we want to clean the results of, execute the method using methodInvocation.proceed(), and then we will do some "post-processing" of the method results to only return what we want to be serialized to Flex. We must also create a new collection, as the collection that is returned is aware that it's a Hibernate lazy-collection (via proxy). After we create the new collection, if the members of the persistent collection implement the AMFSerializable interface, we will call the cloneForAMF() method and add the resulting object to our new non-persistent collection. This collection then gets returned and serialized by the AMF serializer. There are now lazy-loaded collections triggered because the collection we are passing back to the serializer is blissfully unaware of Hibernate or any lazy-collection.

The drawback to this method is that every time you want to get an object's collection, you must make another round-trip to the server. These trips can be less data passed across, but be aware that this must happen if you want to retrieve the lazy collections. Those calls must also be via another method you create, you cannot just load the same objects up and expect the collections to come back by themselves. That defeats the purpose.

I must admit that this does feel like a bit of a hack instead of a more elegant solution like dpHibernate, but sometimes you don't want to mess around with custom adapters on the Java side and special configs on the Flex side. This allows you to implement Hibernate and bypass lazy loading with minimal impact to your value objects and retrieval methods on the AS side. So, in that sense, I think this solution has its place and can be valuable to you on your Flex / Java projects.

A while back, at 360|Flex San Jose, I gave a presentation titled "Implementing BlazeDS". I've been interested in BlazeDS a lot since Adobe announced it way back in early 2008. Being open-source, BlazeDS is open to extension and customization. Until now, only dpHibernate has really taken advantage of what can be done when you extend BlazeDS. At 360|Flex, Mike Nimer and I got to talking about how we could integrate some of the things we really like from ColdFusion into BlazeDS / Flex. We considered creating a Flex server that hooked into Mule, the OS ESB, but ultimately decided that Adobe's established presence in the server-side space with BlazeDS / LCDS was enough to guide us in a direction for extending the server-side capabilities of Flex. So Mike and I decided, after a bit of discussion, to create FlexServerLib.

So, what is FlexServerLib? FlexServerLib is an open-source project that aims to extend BlazeDS with custom message adapters, endpoints, and services. We will provide, in addition to each piece of server-side functionality, a corresponding SWC to implement the service on the Flex client.

We chose the name FlexServerLib because we really wanted the same mindset to FlexServerLib as there is to FlexLib. FlexLib is the goto point for AS3/MXML components and is strongly community driven. We want the same thing, the same community atmosphere for FlexServerLib. And, if you're wondering, we ran the name by Doug to get his blessing before settling on it.

Through the course of discussion at 360|Flex, we came across another collaborator: Chris Scott. Chris is really strong in the Flex to Java and Flex to ColdFusion department, plus he's released his own Flex framework: Swiz. Let's just say he knows his stuff. We are leaning on him to integrate the Spring Framework into our adapters to make them simple to use. Spring abstracts out a bunch of configuration headaches when dealing with these enterprise services, so it only makes sense to include it in our adapters. Chris is working on the Spring implementation for our first adapters, the JMSAdapter (Spring configurable), and the MailAdapter. Going forward, a lot of the work Chris is doing will set the groundwork for our pattern of how our adapters work. We're very lucky to have him on board with this project.

This announcement however, is not all fluff and no stuff. We already have something ready to give to the community. The first piece we wanted to deliver was a messaging interface for sending mail; i.e. We wanted to create the BlazeDS/Flex equivalent of CFMAIL. Well, we have a custom messaging adapter (MailAdapter) and the corresponding SWC that will let you send email from your Flex application without any additional server-side code. Now, sending a mail message from Flex is as easy as MessageSender.sendMail(messgae:MailMessage). This is only the tip of the mail iceberg, however. The plan is to evolve this custom adapter into a complete POP3/IMAP interface for Flex. The first piece though is just getting mail to send, and we have that today. We will also be breaking out a RPC component to do the sending of mail only.

So, where are we going with this? We have a few things on our radar to implement, but no real timetable to do it as we all have day jobs which require attention. First up is RTMP. We are planning on implementing RTMP (engineered from Red5's example) into the BlazeDS MessageBroker servlet (or maybe we can get Adobe to just do this and save us the pain). Like I said earlier, we also plan on fleshing out the MailAdapter to support full blown IMAP and POP3 messaging. Another big announcement is that, as a part of creating FlexServerLib, Mike is planning on rolling dpHibernate into FlexServerLib. So, right away, we'll have dpHibernate, a JMSAdapter, and a MailAdapter available as part of FlexServerLib.

I really think that BlazeDS is somewhat overlooked when it comes to building Flex applications. We are aiming to bring more functionality, relevant functionality (think porting cool ColdFusion functionality to BlazeDS), to BlazeDS and enabling powerful applications for Flex developers, while reducing the amount of server-side development. All that has to be done, server-side, for most components of FlexServerLib is to configure the adapter's settings in messaging-config.xml or remoting-config.xml, and include the relevant jars in your BlazeDS deployment. It's as easy as that.

We've already started to recruit contributors as well. Our first two contributors, outside of the core project leadership are Brian O'Connor and Ivan Latysh. Brian is another member of the Universal Mind team and brings a great deal of experience with LCDS and BlazeDS to the table. Ivan has actually contributed to BlazeDS (an EJB adapter), but that contribution has been put off a version by Adobe. I saw this as an opportunity and asked Ivan if he'd like to add his contribution to FlexServerLib. He gladly accepted our request and will be adding it to the repository soon.

What would any open-source project be without sponsorship? Well, we have two firms sponsoring the project. They are, in no particular order, Digital Primates and Universal Mind. These two firms are the only ones that are going to be able to provide you with any project-approved professional services you would need in regards to support and advanced development around FlexServerLib. We also have a third sponsor: JetBrains, the makers of IntelliJ IDEA, the absolute BEST Java (and now Flex) IDE around. JetBrains has kindly donated IntelliJ licenses to the contributors of FlexServerLib. All the more reason for you to become a contributor, a free IntelliJ license to use on your FlexServerLib work.

This project is being hosted at Google Code, and the SVN repository is already open and ready for you to take up. Feel free to drop any of emails or questions in the comments and we'll try to answer as best we can. Contributions, questions, and the like are all welcome. Feel free to sign up for one of the mailing lists, download the code, give us feedback on what we hope will be a great community resource.