BlazeDS, LCDS and integration with existing application
Posted by cornel | Filed under Flex, Java, LCDS/Blaze DS
UPDATE: Well, I just published my post and I received the following message on YM: You forgot to write that you have to pay money in order to use these products.
I do not want to write a half a page now on licensing so I will be brief (please check the Adobe site for exact information):
BlazeDS is free and opensource. You do not have to pay anything to use it. If you want to buy Adobe support that’s fine, if not you can find books, articles and samples related to this product. LCDS it is a commercial product but it is free if you are using it for one processor, so you can evaluate it and decide if it’s ok for you or not.
Some time ago, after a discussion with several Java developers I realized that they thought that BlazeDS and Livecycle Data Services were some kind of special servers that should be installed separately from the application server – something like Lightstreamer. They also thought that in this case they would have to write additional code in order to do the integration between servers. And one week ago I even met some guys using webservices in order to retrieve data from the Java backend because they did not want “to depend on some Adobe server”. There is nothing wrong with using webservices in Flex, in some cases it is your only option (for example if you want to use Amazon search API), but it is much slower than using BlazeDS remoting. So if you need to connect your Flex application to your java backend I strongly recommend using remoting or the data management feature provided by LCDS.
So I’ve decided to write two posts, one describing how to integrate BlazeDS or LCDS into your existing application, the second one on how to integrate or expose the existing Java code in order to be used in remote calls or for data synchronization. I will also try to cover the aspect of integrating Hibernate and Spring.
Both BlazeDS and LCDS are packaged as WAR applications, they are just simple Java applications that can be deployed in any application server. The procedure to install them is described in so many places so I don’t want to insist on that – take a look, for example, at my colleague’s post. Instead I will write what to do when you already have an application packaged as a WAR and you intend to do the integration with BlazeDS/LCDS.
For BlazeDS there are three steps:
a)Copy the folder called “flex” from blazeds.war\WEB-INF into your WEB-INF folder. This folder contains the configuration files needed by BlazeDS. Of course you can copy in other location if you want but for the sake of simplicity leave them under WEB-INF
b)Take a look at the folder named “lib” at blazeds.war\WEB-INF\lib . It contains all the jar files needed by BlazeDS:
backport-util-concurrent.jar
cfgatewayadapter.jar – you don’t need this it if you do not use ColdFusion
commons-codec-1.3.jar
commons-httpclient-3.0.1.jar – used by the proxy services, if you use only remoting it’s optional
commons-logging.jar
concurrent.jar
flex-messaging-common.jar
flex-messaging-core.jar
flex-messaging-opt.jar
flex-messaging-proxy.jar
flex-messaging-remoting.jar
xalan.jar
You should copy these libraries into your WEB-INF\lib folder. If you already use some of them (Jakarta libraries for example) you should keep the latest version (you can check the version by looking in the manifest.mf file.
c)Add the following entries into your web.xml file (taken from BlazeDS web.xml file):
<!– Http Flex Session attribute and binding listener support –>
<listener>
<listener-class>flex.messaging.HttpFlexSession</listener-class>
</listener>
<!– MessageBroker Servlet –>
<servlet>
<servlet-name>MessageBrokerServlet</servlet-name>
<display-name>MessageBrokerServlet</display-name>
<servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
<init-param>
<param-name>services.configuration.file</param-name>
<param-value>/WEB-INF/flex/services-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MessageBrokerServlet</servlet-name>
<url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>
The same steps are valid also for LCDS with several small differences:
a)The same folder flex should be copied but for LCDS it also contains some SWC libraries and one more configuration file
b)The libraries shipped with LCDS are:
acrobat-core.jar - you don’t need this if you plan to use only data management and remoting
acrobat-core-charset.jar - you don’t need this if you plan to use only data management and remoting
backport-util-concurrent.jar
cfdataservicesadapter.jar – you don’t need this if you do not use ColdFusion
cfgatewayadapter.jar – you don’t need this if you do not use ColdFusion
commons-codec-1.3.jar
commons-httpclient-3.0.1.jar – used by the proxy services, if you use only remoting it’s optional
commons-logging.jar
concurrent.jar
flex-acrobat
flex-messaging-common.jar
flex-messaging-core.jar
flex-messaging-data.jar
flex-messaging-data-req.jar
flex-messaging-opt.jar
flex-messaging-proxy.jar
flex-messaging-remoting.jar
c)This step is identical for both BlazeDS and LCDS.
In the second post on this subject I will show how to integrate your existing Java code so it can be invoked remotely or used with the data management feature.
March 4th, 2009 at 9:41 pm
Great read, but you left us hanging. Can’t wait for the second post!
October 1st, 2009 at 4:31 am
Please post the second part. I am waiting too.