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?

Most of us use tools like Charles or Service Capture to help debug our web applications and flex applications.  They show you the AMF data going back and forth between your browser and the server.  It's all very helpful.  However, there's a little trick if you are trying to debug traffic to a local instance of a server.  Say you're running tomcat locally and are trying to debug the calls with one of these tools.  In your browser, you would put:

http://localhost:8080/mycontextroot/myapp.html

This works to test the app, but you don't see anything in your debugger tool. If you want this traffic to show up in your debugger, you need to use the following variation on the url:

http://localhost.:8080/mycontextroot/myapp.html

This will ensure that you do not bypass the proxy settings used to route your web traffic through the debugger.  

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.

Here is the code/slides for my cf.Objective 2008 presentation: "Enterprise MVC With ColdFusion and Java".  If you are currently sitting in my session, feel free to download the code and follow along.  If you're not in my session right now, still download the code and follow along.

 

Download The Code From My Google Code Site

 

P.S.  Don't forget to come to my BOF tonight on creating & using Open-Source Projects. 

In my interest of getting into the mobile web, I've created an XHTML Mobile version of MXNA. It uses CFFEED to pull the last 15 entries from MXNA and formats the data for mobile phone browsers. If "Web 2.0" is about user experience, maybe "Web 2.5" is all about mobile. Just my thoughts. Enter the following URL on your mobile phone to read MXNA2GO: http://www.infoaccelerator.net/mxna2go/ p.s. I also had to include mobile ads via my Google Mobile Ad JSP Custom Tag.

I went to my AdSense account the other day to create an ad to place on the Weight Watchers Points Calculator. Turns out that the only server-side options that are supported to generate the ads are PHP, CGI, JSP, or ASP. Hmmmm. Our favourite server-side language isn't on that list. However, we can leverage JSP Custom Tags within ColdFusion pages. Charlie has a great article on how to do this (Standard Sys-Con warnings apply). So, I went and did what any good developer would do, I created an easy way to re-use this functionality in ColdFusion. I created a custom JSP tag that you can use to generate Google Mobile Ads within your content. I've included JavaDocs in the zip so that you know what the default values of the attributes are, and how to use them. Included in the package are the class file with path, the JavaDocs, the TLD, and a sample usage file. Enjoy.