Andrew Powell

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?

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

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.

I did this last time around, so here it is again, my session survey results.  Did people love me?  Did they hate me?  Did they care?  Well, the ones who cared enough to fill out the session survey did enough to fill out the survey.  Either way, enough rambling, here's the link:

Survey Results

Excited about BlazeDS, but not really sure what it means for you?  Are you a Java developer coming to Flex who wants to learn how to connect your services to Flex?  Want to see a new spin on the ubiquitous chat application?  Come to my 360|Flex session, Implementing BlazeDS, and you'll get all that and more.  This session is the first of a three-part "Flex/Java Track" that you will get at 360|Flex.  Major topics covered will be:  Remote Objects, Messaging, Integrating Spring & Hibernate, & Binary Remoting without BlazeDS.  Stop on by Monday at 4:00PM if you're interested in learning more.

I attended my first 360|Flex earlier this year.  It was in my own backyard, in downtown Atlanta.  Well, now 360|Flex is returning home to where it all begain:  San Jose, CA.

The only thing I can say about 360|Flex is that it is, hands down, the most intense collection of Flex talent you will ever see in one place.  Maybe you're looking at your 2nd half conference schedule and trying to decide where to go....you can't go wrong with 360|Flex.  The sessions are great, the people are great, and the locations are generally pretty great too.  Beyond the intense sessions that you'll see ( they're all damn good ), the interaction you'll get with the rest of the Flex community can't be beaten.  You get to hang with people like:

• Ben Stucki
• Adam Flater
• Ben Clinkenbeard
• Mike & Mike from Digital Primates
• Jeff Tapper
• Laura Arguello 
• Many, Many More....

If "Web 2.0" was all about interactions and experience, then what I like to call "WebNext" is going to be about how we communicate with our services. The experience revolution that we've been a part of in the last 5 years has changed the way we use the Web, but WebNext will fundamentally change the way applications communicate and that will open up doors we never thought possible.

So what is going to drive all this? Well, it's quite simple. Ever since we've had the Web, and into Web 2.0, server communication has always been synchronous. The client makes a request and waits, in some form or another, for a response. The concept of WebNext is driven by Message Oriented Middleware (MOM). MOM brings a level of asynchronicity to the client-server communication paradigm that is just now starting to get traction in the enterprise sector. With MOM, your application sends a message to a message bus (cloud), then immediately goes about its business. Whether or not you listen for a corresponding response message from the bus, or if the server even responds via the bus, is totally unrelated the message you initially sent. It is a total shift from the request-response model we are used to now.

Let's stop for a minute and think about what this means in terms of development. Developers can now truly develop both the client and server (and back-office processes) in parallel to each other. As far as each tier is concerned, everything else that it communicates with is just a "black box". You can develop your client independent of the server, as long as you know what messages for which to listen and what messages you want to send and how to send them. It's pretty straightforward, once you break the components down.

The client level platform can be anything that can communicate with the message bus. Same goes for the servers and back-office processors. The bus that is the most prevalent foundation for architecting MOM powered applications is JMS. A good number of Enterprise Service Buses (like Fiorano), which expand on the concept of MOM, are running on top of JMS. At the moment though, Microsoft's MQ not withstanding, JMS is the most user-friendly and standards-based API available to implement MOM. JMS, at this point in the MOM concept, is a solid platform for implementing MOM type architectures.

Where does this bring us with WebNext? In WebNext, applications become independent of a particular web server and middleware. In WebNext, applications become message relayers, message creators, message readers, and message destinations. Applications gain true autonomy in this server independence. Applications will be able to communicate with a diverse and distributed set of services, ranging from an .NET app (there are JMS adapters) to Java apps to tiers such as ColdFusion. Security models can be setup that will make services either trusted or untrusted, authenticated or not, etc. The crux of WebNext is that it will give us a truly distributed web.

I believe that going forward, for the Web to remain relevant, it needs to be changing and evolving. This paradigm of WebNext via MOM is the next evolution for the Web. If, at the client level, we are able to, at least partially, break out of the request-response paradigm, why can we not break out of it when it comes to the server-side? The current communication, at its heart is still request-response and synchronous. Asynchronous requests to the server will allow us to open more doors and process data in methods currently not thought of as "standard practice". WebNext is the future, it's just a matter of how quickly we get there.

Flex Messaging is, by far, one of the most under-appreciated and unexplored parts of both LCDS and BlazeDS.  Everyone has seen the ubiquitous chat demos (I'm even guilty of this one myself) when people have shown you what FM can do for you.  Flex Messaging, I contend, is even more important and powerful than the more well known piece of LCDS and BlazeDS:  Remoting.

 Just like remoting, the messaging communication is AMF and happens over port 80 and HTTP, unless you're using RTMP, then it's a different port and protocol, but it's still AMF.  If you are using JMS as your messging provider, and have a corresponding java object, that AS object will be deserialized to the corresponding Java type and the resulting POJO will be placed, by Flex, into the JMS topic or queue.  Basically, this lets you send typed Objects to JMS from Flex, not just anonymous Objects or plain text.

On the receiving end, if the message receiver has access to the same class (via jar, etc), then you can cast the ObjectMessage to your type.  This allows you to pass objects from Flex to Java via JMS without worrying about typing.  Pretty powerful, but pretty unknown as well. Code samples to illustrate my point are below

Person.as
package com.universalmind.model.vo {        
   [RemoteClass(alias="com.universalmind.model.vo.Person")]
   public class Person    {       
      public var name:String;       
      public var age:Number;       
      public var department:String;       
      public var username:String;       
      public var password:String;              
      
      public function Person()       {       }                  
} }

Person.java
package com.universalmind.model.vo;
import java.io.Serializable;

public class Person implements Serializable {
   private String name;
   private int age;
   private String department;
   private String username;
   private String password;
   
   public Person(String name, int age, String department, String username, String password) {
      this.name = name;
      this.age = age;
      this.department = department;
      this.username = username;
      this.password = password;
      }
      
   public Person() { }
   
   public String getName() {
      return name;
   }
   
   public void setName(String name) {
      this.name = name;
   }
   
   public int getAge() {
      return age;
   }
   
   public void setAge(int age) {
      this.age = age;
   }
   
   public String getDepartment() {
      return department;
   }
   
   public void setDepartment(String department) {
      this.department = department;
   }
   
   public String getUsername() {
      return username;
   }
   
   public void setUsername(String username) {
      this.username = username;
   }
   
   public String getPassword() {
      return password;
   }
   
   public void setPassword(String password) {
      this.password = password;
   }
}

messaging-config.xml - destination setup
<destination id="my_queue">

<properties>
<jms>
<destination-type>Queue</destination-type>
<message-type>javax.jms.ObjectMessage</message-type>
<connection-factory>java:ConnectionFactory</connection-factory>
<destination-jndi-name>queue/myQueue</destination-jndi-name>
<delivery-mode>NON_PERSISTENT</delivery-mode>
<message-priority>DEFAULT_PRIORITY</message-priority>
<preserve-jms-headers>"true"</preserve-jms-headers>
<acknowledge-mode>AUTO_ACKNOWLEDGE</acknowledge-mode>
<max-producers>1</max-producers>
</jms>
</properties>
<channels>
<channel ref="my-streaming-amf"/>
         <channel ref="my-polling-amf"/>
</channels>

<adapter ref="jms"/>
</destination>

Application.mxml
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" creationComplete="init(event)">

<mx:Script>
   <![CDATA[
      import mx.messaging.messages.AsyncMessage;
      import com.universalmind.model.vo.Person;
             
      private function init(e:Event):void{
       controlProducer.connect();

      }
      
      private function sendPerson():void{
       var personMsg:Person = new Person();
       personMsg.name = "Test User";
       personMsg.age = 30;
          personMsg.department = "Development";
       personMsg.password = "mypass";
       personMsg.username = "mylogin";
      
       var msg:AsyncMessage = new AsyncMessage();
       msg.body = personMsg;
       myProducer.send(msg);
      }
   ]]>
</mx:Script>

   
   <mx:Producer id="myProducer" destination="control_queue" />
   
   <mx:Button id="controlButton" label="Send Control Packet" click="sendPerson()"/>
</mx:Application>

Here are my slides from today's presentation: Implementing BlazeDS (Flex with Java).  I am doing the same preso Friday afternoon and Thursday a.m. I am sitting on the OS Flex Project panel with Adam Flater, Ben Stucki, Tony Hillerson, and Juan Sanchez.

The slides

This is a follow-on to my previous post.

As CFML developers start to learn Java and move into the realm of Spring and Hibernate, it is very important to stop and ask "What Is ColdFusion?".  ColdFusion, since CFMX, has been a J2EE application running within a J2EE server (JRun, JBoss, Tomcat, Websphere, etc.).  This is important because thinking of ColdFusion like this lets us expand our mind to what we can really do with ColdFusion.  We (CFML developers) can start to leverage J2EE services and frameworks like JPA, JNDI, JTA, and others to make ColdFusion a real player in the J2EE stack.  

Java developers are quick to dismiss ColdFusion as simply a J2EE app and miss its real potential:  It is the fastest way to get data to the web.  It is the fastest way to get data to AJAX, Flex, Silverlight, and even JavaFX (the last two via XML or web service).  I think that going forward, ColdFusion will really shine in this space and make itself be known as a the leader in moving data into RIAs.

ColdFusion also provides complex services easier than Java, .Net, Ruby, or whatever wishes they could.  Let's look at a couple of examples:  CFMAIL is, by far, the easiest way to generate email from an application.  CFPDF?  Are you kidding me?  It doesn't get any easier than this.  Don't tell the Java guys this, but it integrates with JMS easier than Java does too (look at the gateways).  These specialty services are an often used, but at times, overlooked part of ColdFusion because of their simplicity.  By the same token, they're often a source of ammo for the ColdFusion detractors.  Maybe they're just jealous.  

Simply put, at the end of the day, ColdFusion is a J2EE app that enables you to be more productive than if you were writing pure Java or CFML code, alone.  Look at it, and embrace it as such, and a whole new world will open up to you, as a CFML or Java developer.