nil desperandum - BlazeDS

My SOTR 2011 Presentation : AJAX Longpolling with BlazeDS

Wed, 11 May 2011 21:44:00 -0800

I'm rubbish I know... Takes me forever to actually post anything on my blog. Let me throw you a small bone. Scotch on the Rocks 2011 was a marvelous event, even if I did manage to trash my ankle stepping off the train on the Wednesday night. Not that you care, but if you saw me hopping around, it turns out that I actually chipped a bit of bone off my ankle when I twisted my ankle. I'm sure you'll be ecstatic to know that after two and a half month I'm finally back to biking to work again. Anyway....Andy Allan, the lovely Leanne and the ColdFusion Monkeh, Matt Gifford, as always, put on a grand event. Some top class ColdFusion developers and speakers from around the globe. While I enjoyed every presentation I went to, Robert Rawlins presentation "The Pen Is Mightier Than The Keyboard" sticks in my mind as one of the most entertaining and inspirational of the two days. Enough about them though! What about me!? Quite frankly I nearly had kittens! Its the first time in a very long time that I've done a presentation of this nature. I was in the smallest presentation room and it was overflowing even before it had started. I was afraid that when I hopped off for a minute or two that I'd come back to find someone had pinched my seat! Thankfully my seat was still there when I got back. A fair percentage of my presentation was actually based around live coding a small chat application. Amazingly it all went perfectly to plan! Code worked because I remembered to start my ColdFusion server and there were no dodgy porn sites in background web pages. (If you were there you'll know what I'm alluding to. ;) ) You can find my presentation on SlideSix : The code I used throughout my presentation is also attached to the slide show on SlideSix. The code is in the state it was at the end of my presentation, but you can find the bits that I used to build the application up step-by-step in the "Bits" folder. You'll also find the updated FABridge.js so that the Flex-AJAX bridge will also work in Chrome in the ChromeFix folder. You'll also find a "BluePeter" folder. If you're British you've probably already guessed what is in this folder. "Here's one I prepared earlier" is a well known phrase from the children's program Blue Peter when they are making or baking anything on the show. My BluePeter folder is just that. A complete working application, one I prepared earlier, just in case anything didn't go quite to plan. I got some great comments and compliments from those that attended my presentation and for that I thank all of you that attended. Here's hoping I can come up with something to talk about at the next one.

Getting the Flex-AJAX Bridge (FABridge) working in Chrome

Wed, 19 Jan 2011 23:59:00 -0800

Very brief blog post. I've been working on my longpolling blog posts trying to resolve why I'm having problems with the dynamic channel creation with ColdFusion 9.0.1. I've been trying to call my application from Firefox and Chromium on the same laptop. Firefox has been working beautifully, but Chromium 10 has not been playing nice. Finally (I can be a stubborn fool sometimes) I decided to check from Internet Explorer, Safari and Firefox from my desktop all of which work first time, but Chrome just wasn't working. So brain engages and I google "FABridge Chrome". The very first entry that turns up is this one on Tim's Blog called FABridge plays nice with chrome. In it Tom points out a bug in the javascript of FABridge.js, specifically the FABridge__bridgeInitialized function. This function does a browser test, but doesn't include Chrome. Add a check for Chrome and everything starts working just as it should! For the record this is the change : In FABridge.js if you change: if (/Explorer/.test(navigator.appName) || /Konqueror|Safari|KHTML/.test(navigator.appVersion)) to: if((!(/Chrome/.test(navigator.appVersion))) && ((/Explorer/.test(navigator.appName) || /Konqueror|Safari|KHTML/.test(navigator.appVersion)))) Thank you Tom! Much appreciated! Only wish I'd looked sooner!

AJAX Longpolling with ColdFusion and BlazeDS - Subtopics and building a messaging app

Thu, 24 Jun 2010 01:56:00 -0800

I'm sorry to say that I've been putting this post off. Why? Well to be honest I've been struggling with getting my head around how to actually use longpolling. Its all very well understanding the mechanics, but how can you use it effectively. Part of the problem I've been having is the nature of sending messages and filtering them with BlazeDS. What I keep forgetting is that long poll messaging is "fire and forget". You don't send a message and expect an immediate response. You send a message and a response might be broadcast to all event listeners with a specific filter. If you want a request and response, call a webservice or a make an ajax request. Don't use long polling and event gateways.Remembering this is pretty important. If you try to get long polling with FDMS, BlazeDS and ColdFusion event gateways to work like Ajax XHR then you're going to end up in a mess. There are two places you will need to filter messages. Fairly obviously these are in the javascript consumers/event listeners on the client side and in the onIncomingMessage function in your ColdFusion event gateway. I'm going to start with the client side as this also forms the basis of filtering messages on the server side. There are two methods for filtering messages; selectors and sub-topics. There is essentially no difference between selectors and sub-topics. They are both a string of characters that the consumer looks for in a broadcast message to see if it should grab that message and trigger a client-side event. The difference comes in flexibility. Selectors are a single "word", whereas sub-topics have delimited values to which you can apply wildcards. Selectors are available to use without any additional configuration. Sub-topics require a little additional configuration in the destination set up. I've been using sub-topics, so I'm going to cover sub-topics here, but the basic premise is the same for selectors. Starting at the beginning, the additional configuration is actually only a couple of extra lines in the server setting for the destination.


	ss.setAllowSubtopics(true);
	ss.setSubtopicSeparator('.');

As it happens, these lines are already in the code from way back when I wrote part 2 of this series. These two lines should be fairly self-explantory. The first setAllowSubtopics tells the destination to allow subtopics to be used in the Producers and Consumers that use it as a destination. The second, setSubtopicSeparator, defines the character that will be used as a domain seperator. So having set the destination to allow subtopics we now need to update a Consumer/Listener that can listen for specific topics. Lets start with something simple and listen for a specific three part subdomain. The three parts are going to be "app" for the full application, "user" for user related events and a "hello" event.


	consumer = new Consumer(); 
	consumer.setDestination('dispatcher'); 
	consumer.addEventListener("message", messageHandler); 
	consumer.setChannelSet(cs);
	consumer.setSubtopic('app.user.hello'); 
	consumer.subscribe();

So that's the updated consumer from part two. The only difference is that we've set a subtopic that it will listen for of "app.user.hello". Having updated the listener we need to update the simple sender that I created in part 2 to also use subtopics. This is done by adding a subtopic to the message headers. The name for the subtopic field in the header is "DSSubtopic". This field names in the header of client messages are case sensitive, so make sure that the "DSS" on the front is capitalised and the rest is lower case.



clientMsg = {Destination='dispatcher',body={text='The answer to life, the universe and everything'}};
clientMsg['headers']['DSSubtopic'] = 'app.user.hello';

sendGatewayMessage('myGateway',  clientMsg);

You should now be able to load the listener page, load the sender page in another broswer or rbowser window or tab and you'll recieve an alert of "The answer to life, the universe and everything" on the listener page. A word of warning here, and one I should have raised before now. If you load the sender page first and haven't previously loaded any of the listener pages from this or previous posts, you will get an error. The error is because the destination has yet to be created by the listener and the sender has no idea where to send the message. [TODO ERROR HANDLING THIS : CREATING THE DESTINATION FROM THE SERVER SIDE] So fine. I can send a message directly to a listener of a specific name. Whoop de doo. Its no different to what we were doing previously! Change the subtopic in the consumer to "app.user.*", reload the listener page and then refresh the sender page. You should still get the alert. OK, next change the sender subtopic in the sender page to "app.user.owtornowt". To be honest you can change the last part of the subtopic to "asdf" or the name of your wife's mother's brother for this next bit and it will still work. Having changed the subtopic to a "word" of your choice, reload the sender page to get it to send the client message. Once again you should get the alert on the client with out message text in it. What's happening here is that the listener is now listening for any subtopic that starts with "app.user". It doesn't matter what comes after this stub of the subtopic the listener will pick it up and handle it. What this means is you can send out a broadcast to everyone that is listening. The data that you send from the server will then be processed by the handler. You can do the reverse of this and send subtopic to the server in exactly the same way.


function send(subtopic,msg){
	var message = new AsyncMessage();
	message.setBody(msg);
	
	producer.setSubtopic(subtopic);
	producer.send(message);
}

This updated send() function allows you to set the subtopic of the message you want to send the server. As you can see its as simple as "setSubtopic('mytopic.here')". Lets put this to the test and build a little app that uses subtopics on both the client and server side. This app will send a message from the server to a "app.user.message" and will only be displayed by a randomly selected available client. To start with we need to register the client with the server when we open the page. First I'm adding in a couple of javascript functions from http://note19.com/2007/05/27/javascript-guid-generator/ to create a UUID that I can send to the server. NOTE: I could just hard code a createuuid() into the javascript, but I'm trying to always seperate client side code from server side code. I could do something like create a web service that I could call from javascript to register and return a clientID and this would be a better solution in the long term, but for simplicity and for the sake of this demo I'm just going to create GUIDs on the client side and send them to the server.


function S4() {
   return (((1+Math.random())*0x10000)|0).toString(16).substring(1);
}
function guid() {
   return (S4()+S4()+"-"+S4()+"-"+S4()+"-"+S4()+"-"+S4()+S4()+S4());
}

I'm going to get rid of the sendTest function and replace it with a "register" function. This function will grab a globally available ClientID and send it to the server under the subtopic of "app.user.register".


function register() {
	regData = new Object();
	regData.clientid = ClientID;
	send('app.user.register',regData);
}

The register function can't be called until the polling has been initialised, so I'm going to add the creation of "ClientID" and a call to the register() function into the initPolling function.


	ClientID = guid();
	register();

Now over to the server side. We're going to be storing the client ids in the application scope, so we're going to need an Application.cfc. The one over on Ben Nadel's blog is as good as any and I've just dropped that into this demo code with a change of application name. I'm also going to create an empty array in the application scope called "clientregister". This is where I'm going to store my client ids when they register. Next we need to update the onIncomingMessage function in the gateway.cfc. I'm not going to go nuts with this, so I'm just going to assume that there will always be a DSSubtopic in the header of any message and I'll put the data from the body section of the message into a variable for easy access. Next I'll set up a simple switch to look at the subtopic and do "something" based on that subtopic. In this case I'm going to add the client id to the end of the array and send back a quick response. To do this I've also added a "sender" method based on the code in our sender.cfm file. So here's what my gateway looks like now



	
		
		
		

		
			
				
				
				
			
		

		
	
	
	
		
		
		
		
		clientMsg = {Destination='dispatcher',body=arguments.body};
		clientMsg['headers']['DSSubtopic'] = arguments.subtopic;
		
		sendGatewayMessage('myGateway',  clientMsg);

At the minute the message from the sender is going to display for every client hooked into the gateway, so we'll need to update the handler on the client side. First though, take a quick look at the data packet I'm sending back. I've included the clientid that I was sent in the packet I'm sending out. This means that I'll be able to see this on the client side when I get a message to handle, so lets update the handler to look at this value.


function messageHandler(event){
	var eventBody =  event.getMessage().getBody();
	var subTopic = event.getMessage().getHeaders().DSSubtopic;
	if (eventBody.CLIENTID != undefined && eventBody.CLIENTID === ClientID) {
		alert(subTopic+": "+eventBody.TEXT); 
	} else {
		if (subTopic == 'app.user.hello') alert('Someone just registered!');
	}
}

In the function I grab the event body and, as the handler is for a wild card subtopic, I also grab the subtopic from the message header. I'm going to quickly check that CLIENTID does exist in the event body and check to see if it is the same as this client's global "ClientID". If it is I'm going to display the subtopic and the message. If its not then I'll display a message on all the other connected clients of "Someone just registered!". Its 2am and I've just realised how huge this post is, so I'm going to leave this application build here and continue on with it in the next post. Have fun with the attached code!

Blog Roundup 30 April 2010

Sat, 01 May 2010 00:13:00 -0800

I'm rubbish! I really am... I promise and I promise to keep on top of Blog Round-ups, but I never seem to quite manage it. I would really like to keep writing this round-ups ever week, but its quite an effort. Can I persuade anyone to co-author these posts with me? Leave me a comment. Drop me an email. Shout me on Twitter. Anyway, on with the round-up.Who says there are no ColdFusion jobs?! Ricardo Parente's ColdFusion Developer Network posts several jobs a day from across the globe everyday, so I'm not going to post them all here. Check them out for yourself. Ricardo also post the jobs to his twitter account http://twitter.com/cfdevelopers. If you're from the UK, while you're on Twitter you should probably add http://twitter.com/aqualimeblue. Amber seems to always be looking for ColdFusion developers from the UK and around the globe to fill ColdFusion positions. If you hadn't noticed Adobe's Creative Suite 5 is now available as Marcos Placona points out on his newly refurbished blog with his Adobe CS5 Cracked post. If I didn't know better I'd think Marcos was trying for a Reachie Award at Scotch on the Rocks at the end of the month. ;) While I'm mentioning Scotch on the Rocks, Andy Allan is asking for help with a survey for SOTR2011! John Whish has an interesting little post on Why Shared Hosting is Bad. I've always known that it was possible to pick up data from other applications, but you forget how easy it is to abuse that and that you need to protect your clients and your applications. I really haven't been paying attention... I never noticed that ColdSpring 2.0 is in development and has a home on SourceForge. I didn't even realise that Mark Mandel was leading the development! Pass by value and pass by reference can often catch developers out; Here's a sneaky one using ArraySet that one of Ray Camden's readers brought to him thinking it might be a bug. There's a new ColdFusion podcast kicking about. CFBrew is brought to you by a team of developers in an organisation talking about their experiences in development. The second episode deals with starting developing in an Agile environment and using scrums. As this is something that we are just starting to try out I'm very interested to hear how they get on and the problems they encounter and how they solve them. A couple of other small post from Ray to finish up this round up. Ray dropped a very short blog post on new features in ColdFusion 9.0.1 Terry Ryan mentioned at cf.Objective. He also mentions a cookie bug in ColdFusion 9 that needs voting up to get fixed. Ooo I nearly forgot!! Pete Freitag has updated HackMyCF to detect a vulnerability in BlazeDS. This is a vulnerability that affects ColdFusion versions 7 through 9, so definitely worth making sure you are patched up. Using John Mason's Merlin Manager or cfUpdater project can help you make sure that your ColdFusion instances are correctly patched. And that concludes 3 hours of reading and writing to bring you this round-up. I hope you find it useful.

AJAX Longpolling with ColdFusion and BlazeDS - Connecting and Messaging

Sat, 13 Feb 2010 00:13:00 -0800

In my last post on long polling I went through the basic set up of ColdFusion and BlazeDS before getting into too much code. This part I want to get a basic connection and a couple of simple messages being sent and received.Before I go on, I should say that this is all done in ColdFusion 9, as BlazeDS is installed by default, but running BlazeDS on ColdFusion 8 is actually pretty simple to do. First things first. You need to add a function to the gateway.cfc that will handle any incoming messages, cunningly named "onIncomingMessage". At this point it doesn't actually need to do a whole lot, so I've simply got a dump of the event to a file and return the data back to the caller.

That is it... Next... In order to be able to connect to a BlazeDS channel, you need a destination. Like the channel definition I created in the previous post, you can manually create a destination in "messaging-config.xml", but I worked this all out from code from Joao's blog and Marko's Best of CF9 application, both of which use dynamic destinations. Creating a destination is a little convoluted. To be able to create destinations dynamically you need to get to the Message Service via java. To get to the Message Service you need to go through the Message Broker. NOTE : all of the code below is intended to be in a cfscript block (see attached files)


brokerClass = createObject('java','flex.messaging.MessageBroker');
broker = brokerClass.getMessageBroker( javacast('null','') );
brokerControl = createObject('java','flex.management.runtime.messaging.MessageBrokerControl').init(broker);
service = broker.getService('message-service');

Having got the message service we can now create the destination, but we need three bits of information and lets do a bit of validation. The three bit of information we need are the name of the channel and gateway created in the previous part and the name of the destination we want to create. In this case I'm going to call my destination "dispatcher", my channel was "longpolling-amf" and the gateway id was "myGateway".


channelName = "longpolling-amf";
gatewayID = 'myGateway';
destinationName = 'dispatcher';

If the destination already then you don't need to create it again. Destinations are created at a server level and persist, so only the first person accessing the application needs to create it.


destinations = service.getDestinations();
if (!structKeyExists(destinations,destinationName)){ //check if destination already exist

}

getDestinations() returns a struct of all the destinations on the server and their properties. The destination name is the key to the struct entries at the top level, so we just check to see if the destination we want to create already exists in our "destinations" struct. If there's no destination, then you'll need to create it.


//Create the destination and connect it to the ColdFusion adapter defined in the flex/messaging-config.xml file.        
destination = service.createDestination(destinationName);
destination.createAdapter('cfgateway');

// Now apply some settings to the destination - these are the same one's you'd see in 
// the flex/remoting-config.xml file
ss = createObject("java","flex.messaging.config.ServerSettings");
ss.setAllowSubtopics(true);
ss.setDurable(true);
ss.setSubtopicSeparator('.');
destination.setServerSettings(ss);


//Initializes the adapter with the gateway properties.
adapter = destination.getAdapter();
configMap = createObject('java','flex.messaging.config.ConfigMap').init();
configMap.addProperty('gatewayid',gatewayID);
adapter.initialize('cfgateway',configMap);

// connect the destination to the channel/endpoint we're using and start the destination
destination.addChannel(channelName);
destination.start();

Congratulations you now have a destination to which you can connect your javascript/flex bridge. In the previous post I added a load function which had a call back to a initPolling function. This is where we need to look next. Now, before I do I should say that this is going to be a _really_ simple example. The creation of the producer/consumer (broadcaster/listener) should be done somewhere more appropriate, but for the purposes of this series of posts my init function will suffice. Lets crack on... Loaded the FDMSBridge.swf flex object on to the page triggers an external call to a set of initialisation function in the two javascript libraries that come with the bridge. These calls create javascript facades to the flex equivalent objects. Take a look in the FDMSLib.js file and the BlazeDS docs for the objects that are available to you. The objects we are going to use now are ChannelSet, Producer and Consumer. First up connect to your endpoint using a ChannelSet().

I've been moving this code around between a few servers where I know that the end point is on the same server as my code, so I've "hacked" in a cgi.http_host, but equally I could use document.domain in javascript to specify my server. Set this anyway you wish, hardcode it, use my hack, whatever. Do be aware that you'll need to make sure that your calling domain is in the crossdomain.xml file if you are accessing different domain. I'm not going to go into this here. What this javascript does is creates an AMFChannel from javascript, through the flex bridge to the channel/endpoint in BlazeDS on your ColdFusion server. Impressed? You should be. If you've written any flex or flash listeners that talk to coldfusion through the flash remoting or flex2 gateway you now have a reasonably complete set of objects that you would use there available to you in javascript. Lets extend this. We need to be able to send messages to our event gateway to do this we need a broadcaster. "Producer" is the proper term in this case.


producer = new Producer();
producer.setDestination('dispatcher');
producer.setChannelSet(cs);

This goes in the initPolling function after the addChannel function. It creates your Producer object, hooks it up to the destination we created and tells it to use the ChannelSet to our endpoint. This allows our javascript to send a message to our event gateway on ColdFusion. Any message sent head down the channel set, through the flex bridge, to the endpoint, to the destination that routes the message to our ColdFusion event gateway, where it will be handled by the onIncomingMessage method in our cfc. Sending a message is done using the AsyncMessage object from the FDMSLib. Its pretty simple; you create an AsyncMessage object, set the message body and then use the producer to send the message.


function send(msg){ 
	var message = new AsyncMessage(); 
	message.setBody(msg); 
	producer.send(message); 
}

A message can be any data you wish to send. In this example I'm just sending some random strings and numbers.


function sendTest() { 
	testData = new Object(); 
	testData.andnow='for'; 
	testData.something='completely';
        testData.different=42;
	send(testData); 
	return false; 
}

Jury rig a link to call the sendTest function in the HTML body and we're all set to send our test message to the server.



	Send the Test

For the purposes of this simple example the gateway.cfc in the attached zip has a cfdump in it that writes to a file. When you click on the "send" link a dump of the data received by the gateway will be written to the dumps folder. In there you should be able to see the message we sent along with information about how the message was sent to the server and a unique identifier for where the message came from (originator). All this information can be used when replying to a message sent to the event gateway. For the minute I'm going to skip over replies and just start with a simple broadcast from the server to all connected clients. Sending messages back to the client from the server requires a listener or consumer. Add the following to your initPolling function to create a consumer:


consumer = new Consumer(); 
consumer.setDestination('dispatcher'); 
consumer.addEventListener("message", messageHandler); 
consumer.setChannelSet(cs); 
consumer.subscribe();

Consumer() is another object available in the FDMSLib. The code above connects a consumer to our destination and end point, adds a event listener of "message" and then tells the event gateway its ready and waiting by "subscribing". The data I'm going to send back to the server will contain a string in a variable called "TEXT" and my handler is simply going to alert() that that text.


function messageHandler(event){ 
	alert(event.getMessage().getBody().TEXT); 
}

I strongly recommend using something like firebug to have a dig around in the event object to see all the data that is available in the event and message. To send a message to all connected clients I need another template with 2 lines of cfscript in it.



clientMsg = {Destination='dispatcher',body={text='The answer to life, the universe and everything'}};
sendGatewayMessage('myGateway',  clientMsg);

The first line is a structure for my message to the client. Its made up of destination and body. Destination is the same destination we created previously and body is the data of the message. The second line is the ColdFusion function sendGatewayMessage(). You simply specify the gateway it will be sending the message through and the message it needs to send. With your main index.cfm loaded and listening, load the page that you put this bit of cfscript into in another browser window. Within a few moments, if all your code is correct, you should get an alert appearing the first window. And that is it for this post. This is a very crude server-side sender. If you were to have more than one window open with the index.cfm in it, all of those windows would display the alert message. This isn't especially useful, so in the next post I'll cover replying to messages received by the event gateway and routing messages based on subtopics on both the client and server. Attached to this post is the complete code for this blog post. Enjoy! *UPDATE* I've sorted out the two issues that Anthony raised with the file path for dumps and the erroneous messages.

AJAX Longpolling with ColdFusion and BlazeDS - Getting set up

Thu, 28 Jan 2010 21:31:00 -0800

I've spent some of my week this week fighting with JavaScript, BlazeDS and ColdFusion to get a working model for some ExtJS functionality that I'm currently building at work. One of several pieces of functionality we'd like is to have is real time notifications of workflow changes. The way it was described was "we want to push alerts to the users". I decided to have a look at how we actually addressed this "problem". We didn't really need to "push" alerts to users, so the solution was traditional polling or long polling.Traditional polling will hit Apache and ColdFusion via a timed ajax call over and over. Any "messages" that are sent to a client will wait on the server until the request is made. Long polling opens a connection to the server and keeps that connection open until a timeout limit is reached and then reconnect. If a "message" is made available for the client, then the open connection will send it to the client immediately. After reading the Best of CF9 Entry from Marko Simic on Ray Camden's blog and talking to a bunch of people, but specifically João Fernandes I decided to go with long polling using BlazeDS. If you don't know what BlazeDS is, its the default messaging server used in ColdFusion 9, in place of Live Cycle Data Services. Given that I basically needed a messaging service between ColdFusion and ExtJS it seems logical that I should use this, particularly as it has the ability to create long poll connections. As with all the thing i seem to be doing at the minute, they are actually pretty simple, but there's no concise idiots guide for the likes of me to be able to put these things together. Hopefully this blog post will help others. There are a number of things that we are going to use and need to know in order to get started. Firstly, you cannot simply create a javascript long polling connection to BlazeDS. This has to be done through a bridge mechanism. Fortunately, there is a Flex-AJAX Bridge available for just this purpose. We need a service channel definition in the services-config.xml and a ColdFusion event gateway. We'll have an HTML/Javascript interface that will sit on the browser. This will include the Flex-Ajax Bridge. On the server side we'll have BlazeDS handling the messaging and ColdFusion Event Gateways handling the messages that are sent. This is kind of how I visualise how everything fits together. Hopefully this diagram will make some kind of sense later on when all the pieces of code and technology are put together. Ok, so lets get started with the two easiest bits of set up. The event gateway and the service channel. If you've looked at Marko's Best of CF9 entry, you'll have seen in the INSTALL text that he has a bit of config that you need to insert into the services-config.xml file on your ColdFusion Server. This is the service channel and we'll be inserting the exact same piece of config. (I copied it from there - thanks Marko ;) ) Find services-config.xml under the Flex folder in your ColdFusion Server. I always use Multi Server installs and I always expand the cfusion.ear file out to folders, so on my local blog server I can find the flex folder here : C:\JRun4\servers\blog\cfusion-ear\cfusion-war\WEB-INF\flex Open up the service-config.xml file and find the section. In this section insert the following channel definition :

This is the BlazeDS channel that we'll be connecting too. The comments in there should help you understand what its doing. The important part to understand is that the wait-interval-millis is how long a connection will stay open for before BlazeDS drops the connection. This is what will allow us to create a messaging connection that will remain open. For now I'm manually creating this channel and endpoint in the services-config.xml. Later I want to remove this and dynamically create an end point, so that we don't have to do any manual configuration and for one other reason I'll come to later. Next go into the ColdFusion administrator, find the the event gateways section and the Gateway instances under that. Add a new data services messaging gateway : In this case I've just called it myGateway and I've pointed it at an empty cfc called gateway. This CFC will handle the messages that are sent from the browser to the server. The last bit of set up, and the end of this blog post, is the initial set up of the Flex-AJAX Bridge. The bridge is made up of 2 javascript files and a swf. The swf does actually exist you have to compile this yourself. The javascript files and the actionscript files can be found in the download of the source for BlazeDS or from the SVN repository here : http://opensource.adobe.com/svn/opensource/blazeds/branches/3.x/resources/fds-ajax-bridge/ There are also instructions on how to compile the bridge in the readme.txt file with the actionscript and javascript files. You may find that when run the compile with the command line given in the readme.txt file it will throw an error about not knowing what the context root is. If you do add "-context-root /" to the end of the command line, or replace the "/" with your context root if its different eg. "cfusion" is a possibility. This compilation is the second reason why I would like to make the channels/endpoints dynamic. One of the attributes of the compile points to the services-config.xml file. If you change the services-config.xml file you will need to recompile the bridge swf. By compiling the bridge against a standard services-config.xml and dynamically generating the endpoint this will negate the need to recompile the bridge when ever you need a new endpoint. So now we've got a message channel/endpoint, an event gateway, an empty event handler and our Flex-AJAX bridge. Just to conclude this blog post create an basic index.cfm file with your standard html head and body. Include the two Flex-Ajax Bridge javascript files in the head of the page. At the foot of the body insert :

This will load the bridge swf that you compile previously. Note : The load function does a document.write() of a bunch of HTML to insert the swf into the page. I found that if you try to run this "onReady" or at the head of the page it would lock up the processing of the rest of the page. It really needs a rewrite to be a bit more clever than simply injecting the object/embed html into page where ever this is called. Again something for later down the line, probably as an Ext.JS object of some kind. Lastly, before I fall asleep at my laptop, back up in the head of your page, create an empty javascript function called "initPolling". I've attached a rar file with this initial bit of code, as well as the bridge javascript and my compiled FDMSBridge.swf. Whether you'll get any use out my bridge swf is really down to your set up.