As I continued to work on OSGi based web apps, there was rising demands from our clients and partners about supporting Flex clients in future. I took a lead to evaluate our existing architecture consisting mainly of POJOs, supported with Spring and OSGi.
Thanks to the documentation at
BlazeDS site and the
refcard at DZone for helping me out. I am almost ignorant of Flex programming, but still I could make out few things. Here is my first-cut evaluation.
Flex and Java with POJO
I was happy to learn that with Spring's hailed paradigm of programming with interfaces and POJOs would make integration with Flex very simple, and would hardly require any change in how we program and architect our application.
Flex has strong ties to Java. Its server BlazeDS is based on Java remoting. Good news that with Spring BlazeDS, we can reuse our interfaces and its POJO implementations.
Spring BlazeDS as described by SpringSource:
Spring BlazeDS Integration is a new addition to the Spring portfolio, and a component of the complete Spring Web stack. This project's purpose is to make it easier to build Spring-powered Rich Internet Applications using Adobe Flex as the front-end client. It aims to achieve this purpose by providing first-class support for using the open source Adobe BlazeDS project and its powerful remoting and messaging facilities in combination with the familiar Spring programming model.
Blaze DS is based on Java remoting and web messaging from Adobe. Its primary purpose of existence is easier integration of Adobe Flex/Adobe AIR with existing Java code to create Rich Internet Applications (RIA). Spring BlazeDS leverages more on this end by its dependency injection, and simpler integration platform.
Blaze DS can be set to run on any web container such as Tomcat. It listens to a particular URL for client requests and processes them. Flex clients connect to the Blaze DS server and executes Java methods. The base transport protocol will be HTTP.
The regular client calls with Blaze DS is usually handled by a Servlet from Blaze DS. However, when Spring Blaze DS comes into picture, this is replaced by the Spring's Spring MVC Servlet, so that Spring can intercept those client calls.
Flex works on the concept of message broker. A class that will can handle client calls. The clients calls will be routed to the message broker through additional configuration specific to Blaze DS. We should be happy to expose our interfaces and its implementation classes to work as message brokers.
A sample Spring's application-context.xml file
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:flex="http://www.springframework.org/schema/flex"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/flex
http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
<!-- Spring Beans's -->
<bean id="myService" class="MyServiceImpl" />
<!-- Simplest possible message broker -->
<flex:message-broker />
<!-- exposes myService as BlazeDS destination -->
<flex:remote-service ref="myService" />
</beans>
The point to be noted above is that myService can be given any reference, including a reference to any OSGi service.
Another notable point about Spring BlazeDS Integration is that Flex can support authentication, that can easily plug in with
Spring Security.
Kudos
Spring BlazeDS has not yet had its final release, but indeed a great work from Spring guys to help lift existing POJO based applications to work with Flex clients in most non-intrusive manner.
