BlazeDS – Adobe Open Sources Flash Remoting and Messaging Servers
On twitter just moments ago, I saw James Ward point toward a truly awsome move by Adobe. Tonight Adobe announced that they are open sourcing the technologies that are the base for Flash Remoting and the Messaging Services found in their high end server technologies. BlazeDS represents the services which makes data transfer with Flash and Flex perform better than traditional javascript (text based) technologies. These technologies make use of the AMF (Action Message Format) a binary protocol for describing the data to lessen the data payload that must be transfered to describe your data. In addition to open sourcing the technologies to do the messaging they have also released the AMF specification allowing AMF servers to be implemented on other server platforms.
In hitting the labs site to read more about BlazeDS I see that it appears the Flex 3 Beta 3 has also been released. Flex 3 is another amazing product from adobe that has been open sourced. Although not open source the Adobe AIR product has also seen its 3rd beta release tonight. AIR allows web developers to use their existing skill set to build desktop applications which reach beyond the boundaries of the browser.
So take some time and get familiar with these new tools from adobe.
I don’t think I’ll be getting much sleep tonight.. time to do some downloading
Do you know much about compiling resources?
I would like to first describe the structure that we are deploying our applications as this will make this issue that much clearer. We are deploying and packaging the BlazeDS war file as its own standalone application, meaning that the compiled swf files will be packaged and deployed in their own separate web apps. For example, if we were to have 3 different Flex applications accessing Java objects remotely through BlazeDS, from a deployment and packaging standpoint, there will be only one instance of BlazeDS deployed, and there will be 3 separate deployed web applications all making calls to this one instance.
The issue lies in the fact that a Flex application is compiled into a Flash (.swf) file, and upon compilation, it must know where to make calls to these remote objects. This is done by specifying a compiler option to point to an xml file that is part of BlazeDS called services-config.xml. This causes an interesting situation because the location of this file must fall under a certain set of constraints in order for the Flex application to be readily checked out from source control and compiled.
Furthermore, after the former has been correctly setup, and the code is compiled, it is compiled for that specific environment as there are certain references such as, <endpoint url=”http://{server.name}:{server.port}, that is specific to that environment and can change throughout the development/QA/production lifecycle. So given this, I don’t know if the code must be compiled for every environment which doesn’t seem efficient or suited for an enterprise environment.
Please let me know if this clarified the situation, and let me know if there is further information I could provide.
Hi Tom,
Thats quite a post :) So as I read through your comment there are several questions that come to mind. But at the end I tend to come to a single conclusion. So the trick here is basically that you want the endpoint which the swf communicates with to change based on where its deployed. There are 2 routes I can think of to make this work depending on what types of services you are using (remoting vs messaging).
The first thing that comes to mind is that regardless of wether you are using remoting or messaging you can use the server compilation process of blaze ds which will use whatever configuration files are on the server that is compiling. This allows you to have different setup depending on what server (staging, testing, production) without changing the code in the swf at all. The swf just uses a destination and the server does the rest. This has the draw back of the swf being compiled on its first request, but all subsequent requests are cached.
The second option is if you are talking about remote object rpc calls Flex 3 now allows you to configure the channels and endpoints in your swf without the use of a config file. Using that approach you could use ant or rake to place the correct values in the file (for staging, testing and production) as part of your deployment script.
I hope these solutions may guide you to some resolution for your deployment woes.