Creating Dynamic Remote Destinations with BlazeDS

Doing remoting with Flex and BlazeDS is great, you set up your remoting-config.xml with your destinations and them consume this destination with your Flex client, that's good if you have your destinations hardcoded in your xml file, but there are times when you want to create your remoting destinations dynamically, taking this post as a base i will show you how to do this with BlazeDS in a simple example.

First we create a class called DestinationHelper this will contain all the classes you want to create at run time, read the comments so you know exactly what are you doing for a deeper explanation please read this post.




I take the great explanations of Nick Kwiatkowski  and change a little so this can match the example, please all the credits go to him.

The first thing we do is call the createDestination() function on the remoting-service and cast this to a RemotingDestination.  This will pass back a reference to the new destination that was created for us with the name we passed in. Next, we set the source property.  Since we are working within Java, this could be the dot-path-name of the Java class we are working with, or * to allow our dynamic destination to talk to ANY Java Class.   

The next thing we do is set up the Adapter.  The adapter is what actually processes the requests from our connected Flex client and sends it over to Java to be worked on.  In our case, I am having a Java Adapter do the processing, so I went with the “java-object” adapter.  There are a variety of adapters available, and depending on your situation, you may want to choose from a list of adapters, or use the getDefaultAdapter() method to find out what is the default for the service you are working on.  Creating an instance of the adapter involves calling the createAdapter() method on the destination.  What is returned to you is a reference to the adapter that isn’t initialized yet.  When diving through the source code — this is what screwed me up the most, as I was under the impression that the createAdapter() was all I had to call to get things working.  If that is all you do, you will get NullPointerException errors when you try to pass data to the destination. 

In order to initialize the adapter, you need to pass in a property with the type of a ConfigMap.  The ConfigMap holds the configuration properties that the adapter is expecting.  There are lots of properties that could be set (and if you want to get a general idea of what they are, take a look at the XML config).  In theory, you should be able to pass in an empty ConfigMap to the initialize method and it will take all the defaults (which work in my case), but there is a bug in the JavaAdapter (Yes in the Java adapter too) that requires to you set the use-mappings and method-access-level properties to something or you can’t send any data to the destination.  These two properties are within a ConfigMap named “access” (again, take a look at the XML in the remoting-config.xml to see how this translates).  Finally, in order to initialize the adapter, we pass in the ConfigMap we just setup to the initialize() method and we are set.

Our final steps include binding our newly created adapter instance to the destination by using the setAdapter() method, and setting the channel that the destination will bind to.  If I wasn’t making the assumption that the channel “my-amf” already exists, I could call the getChannels() method on the Message Broker to verify that it is one of the ones available.  If the channel wasn’t available, I could create using a similar method as above.  And finally, we need to start the instance.  Call the start() method to start it.  If everything is set up right, you should be able to send data to your new destination!