An introduction to Spring BlazeDS integration
Created
22 March 2010
Requirements
User level
All
Over a year ago, SpringSource and Adobe announced a partnership aimed at streamlining the integration between Spring and BlazeDS. This partnership has led to the new Spring BlazeDS Integration project, which allows you to seamlessly integrate the two technologies and build state-of-the-art Internet applications that feature a Flex front end and a Spring back-end.
Whether you are a Flex developer just learning Spring or a Spring developer learning Flex, you can benefit from the powerful integration of these technologies.
Spring has emerged as the de facto standard for building the Java back-end of Internet applications. Flex is rapidly becoming the preferred technology for building innovative Internet applications delivered in the browser and on the desktop (using the Adobe AIR runtime).
This article provides an introduction to the Spring BlazeDS Integration, and includes a simple example application to illustrate key concepts.
What is Spring?
The foundation of the Spring framework is a lightweight component container that implements the Inversion of Control (IoC) pattern. Using an IoC container, components don't instantiate or even look up their dependencies (the objects they work with). The container is responsible for injecting those dependencies when it creates the components (hence the term "Dependency Injection", which is also used to describe this pattern).
By enabling looser coupling between components, the Spring IoC container has proven to be a solid foundation for building robust enterprise applications.
The components managed by the Spring IoC container are called Spring beans. In addition to its core IoC container, The Spring framework includes several other modules, including support for transaction management, JDBC Data Access, and ORM Data Access. While these modules are beyond the scope of this article, it is important to note that an additional benefit of using BlazeDS with Spring is the ability to leverage these modules to facilitate the development of your remote objects. More information on the Spring framework can be found here.
What is Flex?
Flex is a developer toolkit for building Rich Internet Applications. The Flex programming model includes:
- ActionScript - an ECMAScript-compliant, object-oriented programming language. With some syntactical differences, ActionScript looks and feels similar to Java, and supports the same object-oriented constructs: packages, classes, inheritance, interfaces, strong (but also dynamic) typing, and so on.
- MXML - an XML-based language that provides an abstraction on top of ActionScript, and allows parts of an application (typically the View) to be built declaratively.
- An extensive set of class libraries. The documentation is available here.
The Flex source code (.mxml and .as files) is compiled into Flash bytecode (.swf) that is executed at the client side by the ActionScriptVirtual Machine in Flash Player using a Just-In-Time compiler.
The Flex SDK is an open-source project. It includes the Flex component library, the compiler, the debugger, and the documentation. A complete discussion of Flex is beyond the scope of this article, but you can find more information and download Flex 4 here.
What is BlazeDS?
BlazeDS is a set of data services that give your Flex applications additional options for data connectivity. Without BlazeDS (or, without deploying any Flex-specific component on the server side), Flex applications can access back-end data using either the HTTPService or WebService components:
- You use the HTTPService component to send HTTP requests to a server and consume the response. Although the HTTPService is often used to consume XML, it can be used to consume responses in other formats, including JSON. The Flex HTTPService is similar to the XMLHttpRequest component available in Ajax.
- You use the WebService component to invoke SOAP-based web services.
BlazeDS adds the following services:
- The Remoting Service allows your Flex application to directly invoke methods of Java objects deployed in your application server.
- The Message Service provides a publish/subscribe infrastructure that enables your Flex application to publish messages and subscribe to a messaging destination, enabling the development of real-time data push and collaborative applications.
- The Proxy Service allows your Flex application to make cross-domain service requests in a secure and controlled manner. In other words, it allows your Flex application to access a service available on a different domain than the domain from where the application was downloaded (without having to deploy a crossdomain.xml policy file on the target domain).
BlazeDS is deployed as a set of JAR files as part of your web application. Like the Flex SDK, BlazeDS is an open-source project. More information is available here.
Accessing Spring Beans from a Flex application
If Flex clients can remotely access Java objects using BlazeDS, and if Spring beans are just regular Java objects, aren't you all set and ready to start accessing Spring beans from Flex clients? Almost…
By default, you configure BlazeDS remote objects in a configuration file called remoting-config.xml located in WEB-INF\flex. For example, to make a Java class named ProductService available remotely to a Flex application under the logical name "product", you would define a destination as follows:
<destination id="product">
<properties>
<source>my.package.ProductService</source>
</properties>
</destination>
This destination allows a Flex application to invoke the public methods of ProductService. Here is a minimalist Flex application that populates a DataGrid with a list of products obtained by remotely invoking the findAll() method of the ProductService class.
<?xml version="1.0" encoding="utf-8"?>
<s:Application
xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
<fx:Declarations>
<s:RemoteObject id="ro" destination="productService"/>
</fx:Declarations>
<s:layout>
<s:VerticalLayout/>
</s:layout>
<mx:DataGrid dataProvider="{ro.findAll.lastResult}" />
<s:Button label="Get Data" click="ro.findAll()"/>
</s:Application>
The problem is that by default, BlazeDS takes care of instantiating and managing the life cycle of the remote objects defined in remoting-config.xml. The whole idea behind Spring IoC, however, is to let the container instantiate components (and inject their dependencies). The key to the integration of Spring and BlazeDS, therefore, is to find the best possible arrangement to leverage the data services provided by BlazeDS while letting the Spring container manage the configuration, instantiation, and life cycle of the remote objects.
The old approach: SpringFactory
BlazeDS provides a general purpose integration/pluggability mechanism based on the Factory pattern. You can plug a custom factory in the definition of a destination to delegate the instantiation and life cycle management of the underlying remote object to another subsystem. The role of the factory is to provide ready-to-use instances of objects to BlazeDS instead of letting BlazeDS instantiate those components. To create a factory, you create a class that implements the flex.messaging.FlexFactory interface, and you implement the lookup() method used by BlazeDS to obtain an instance of a remote object. Internally, the lookup() method may construct a new instance, or obtain it from somewhere else.
Historically, Adobe has provided a SpringFactory class that provides BlazeDS with fully initialized (dependency-injected) instances of objects obtained from the Spring container.
Configuring a destination to delegate the instantiation of a remote object to Spring was a two step process.
- Register the Spring factory in WEB-INF/flex/services-config.xml:
<factories>
<factory id="spring" class="flex.samples.factories.SpringFactory"/>
</factories>
- Configure the destination to use the factory:
<destination id="myService">
<properties>
<factory>spring</factory>
<source>myBean</source>
</properties>
</destination>
Although it provides basic integration between BlazeDS and Spring, the factory approach has a number of shortcomings:
The "dependency lookup" approach described above is squarely at odds with the Spring "dependency injection" approach.
Objects have to be configured twice: once in the BlazeDS remoting-config.xml file and again in the Spring application context file.
The overall system configuration is spread over multiple files. BlazeDS is configured in web.xml, and remoting-config.xml, while Spring is configured in its own application context XML file.
The integration is limited to basic "remoting" and doesn’t cover other important aspects such as security and messaging.
The Spring BlazeDS Integration Project
The SpringSource and Adobe partnership is aimed at streamlining the integration between Spring and BlazeDS. This partnership has resulted in a new subproject in the Spring web portfolio: the Spring BlazeDS Integration project.
Instead of having two concurrent systems that have their own configuration approach and that communicate in a rudimentary way, the goal of the project is to let Spring manage BlazeDS "the Spring way", just as it manages the other components of an application, and therefore provide a much deeper and cohesive level of integration between the two technologies.
The Spring BlazeDS Integration project provides the following features:
The MessageBroker, which is the cornerstone of the BlazeDS engine, is configured and bootstrapped as a Spring-managed bean and doesn’t need to be configured in web.xml.
Flex messages are routed to the MessageBroker through the Spring DispatcherServlet.
Remote objects are configured the "Spring way" in the application context configuration file. You don’t need a remoting-config.xml file when working with BlazeDS and Spring.
Messaging destinations are configured the "Spring way". You don’t need a messaging-config.xml file when working with BlazeDS and Spring.
The Spring security integration ensures that you can secure Spring-managed beans exposed as remote objects just as you would secure any other Spring-managed endpoint, and that you can provide your security credentials from within a Flex application through the channelSet.login() API.
A simple example
To set up a simple Spring BlazeDS Integration application, you will need to:
- Configure Spring in web.xml.
- Configure the BlazeDS message broker as a Spring-managed bean in the application context configuration file.
- Configure your beans and expose them as remote objects in the application context configuration file.
Note: Depending on the DispatcherServlet mapping defined in web.xml, you may also need to adjust the default channel configuration in the BlazeDS services-config.xml file.
In web.xml, you configure the DispatcherServlet to bootstrap the Spring WebApplicationContext as usual. In this simple configuration, you then map all the /messagebroker requests to the DispatcherServlet.
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
<servlet>
<servlet-name>spring</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/web-application-context.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>
</web-app>
In web-application-config.xml, you first configure the BlazeDS message broker as a Spring-managed bean using the simple message-broker tag. This will bootstrap the BlazeDS message broker. When you use the message-broker tag without mapping child elements, all incoming DispatcherServlet requests are mapped to the MessageBroker. You can add mapping child elements if you need more control.
With the message-broker in place, you then configure your Spring beans as usual, and you expose the beans you want to make available for remote access using the remoting-destination tag.
web-application-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:flex="http://www.springframework.org/schema/flex"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/flex
http://www.springframework.org/schema/flex/spring-flex-1.0.xsd">
<flex:message-broker/>
<bean id="productService" class="org.springframework.flex.samples.product.ProductDAO" >
<flex:remoting-destination />
<constructor-arg ref="dataSource" />
</bean>
<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.h2.Driver" />
<property name="url" value="jdbc:h2:~/sprinflexdemodb/sprinflexdemodb" />
</bean>
</beans>
The above configuration allows a Flex application to invoke the public methods of the productService bean. Here is a minimalist Flex application that populates a DataGrid with a list of products obtained by remotely invoking the findAll() method of the ProductService class.
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
<fx:Declarations>
<s:RemoteObject id="ro" destination="productService"/>
</fx:Declarations>
<s:layout>
<s:VerticalLayout/>
</s:layout>
<mx:DataGrid dataProvider="{ro.findAll.lastResult}" />
<s:Button label="Get Data" click="ro.findAll()"/>
</s:Application>
Note that this is the same code that was used to connect to a plain BlazeDS installation: The client-side code is isolated from the specific server-side implementation.
Where to go from here
The Spring BlazeDS Integration project enables you to seamlessly integrate Flex, BlazeDS, and Spring to build expressive, high-performance, and well-architected Rich Internet Applications. If you are already a Spring developer, you can leverage your existing infrastructure and simply expose your beans for remote access by Flex clients via BlazeDS remoting. If you are an existing Flex and BlazeDS developer, you can use Spring BlazeDS Integration to easily leverage the many powerful features of the Spring IoC container and other components of the Spring Framework.
The example above was intentionally kept very simple and we only scratched the surface of the Spring BlazeDS Integration. To learn about other features including Messaging and Security integration, read the article Spring BlazeDS Integration Test Drive.
The following resources are also helpful:
More Like This
- The Spring BlazeDS Integration Test Drive
- Introduction to Flex 4 and Java integration
- Foundation Flex for Designers excerpt: Flex Builder and Flash
- Using an ActionScript code generator to enable Flex and .NET integration
- Integrating a simple Flex search application with Grails
- Integrating Flash Builder 4 with other Adobe products
- 100 Days of Exercise: Building social features into mobile AIR apps
