This article is sponsored by Adobe.

A Conversation with Adobe's Anil Channappa

---

Advertisement

Recommended Adobe Resources Build Beautiful Apps: Download Flash Builder 4 Trial Download the OpenSource Flex 4 SDK The Flash Platform At A Glance PDF Free Online Flex Training This section sponsored by:

Frank Sommers: Would you give us an overview of what BlazeDS is and what it offers to enterprise Java developers?

Anil Channappa: Web applications typically communicate via HTTP and exchange data with untyped, text-based data structures, such as JSON or XML. Since the Flash Player can store typed data on the client, we developed a protocol for data transmission with the Flash Player: AMF, or Action Message Format.

With AMF, you send serialized binary data from the server to the client and vice versa. Because AMF can be a payload on HTTP messages, you can use BlazeDS and AMF even in environments where firewall restrictions, for instance, would require HTTP-based data access.

In addition to the ability to receive typed data, having a binary data protocol gives you tremendous performance benefits: We are able to obtain performance that's ten to twenty times faster than using traditional HTML or some other unstructured, text-based data format.

BlazeDS is an open-source product that includes an AMF server, as well as infrastructure to do remote method calls from the Flash Player to server-side JavaBeans, perform distributed messaging, including server-initiated messaging, and proxy enterprise services for access from the Flash Player.

Remote method calls on JavaBeans

Frank Sommers: That's a lot of features. Let's take one feature at a time. How do remote calls work with BlazeDS?

Anil Channappa: BlazeDS's remoting lets you develop your business logic using traditional JavaBeans on the server. Those beans can then be called over RPC-style communication from the Flash Player client. We have client-side APIs that make it appear as though the bean existed locally on the client, but communication occurs over the network. The data is sent as objects, in a binary format.

The remote method calls occur asynchronously: When the client initiates a call, the call returns, and the client can register a callback to be notified when the response arrives from the server, or if a communication error occurs.

The remote call programming model in BlazeDS, combined with the fast binary data transmission, as well as the typed objects, allow you to use Flash as an application development platform.

General purpose messaging

Frank Sommers: How does the remote call mechanism tie into the more general-purpose messaging framework?

Anil Channappa: Most people are comfortable with pushing data from the client to the server. But it's much harder to implement something that allows the server to push some data into the client. You either have the client periodically poll the server for changes, or you have to ask users to refresh the browser to get the latest information from the server.

BlazeDS's messaging infrastructure lets messages on the server push data to the client. We implement multiple protocols, and multiple fail-over mechanisms, and support polling as well as long-polling. In long-polling, you make a request, and then wait for a while before you gather responses from the server. Those changes then all come in one shot, saving you bandwidth. It's also faster.

We also support streaming in BlazeDS: You can open a persistent connection from the Flash Player to the BlazeDS server. Once you have that streaming connection open, the server can send messages as it gets them. That, in turn, allows you to develop real-time messaging applications.

Frank Sommers: Can you describe the programming model for messaging? How can a client register interest in receiving messages from the server?

Anil Channappa: We have something called consumers and subscribers. You can have a client that acts as a consumer for messages. Then we have endpoints and destinations. Destinations are conceptually analogous to JMS topics. A single client, or multiple clients, can listen to a destination. Every destination is defined via a name. You have APIs on the client that say, I'd like to subscribe to this particular destination. Then there are API calls that help determine if you have any messages, and if so, you can start receiving those messages.

Using BlazeDS as a proxy

Frank Sommers: You mentioned proxying as another BlazeDS feature. Can you describe what proxying is?

Anil Channappa: Many enterprises have internal services that they'd like to communicate with from the Flash Player. These could be servlets or Web services, for instance. Rather then exposing those directly to the Flex client, which would open up security issues, you can use BlazeDS as a gateway to those services. That way, BlazeDS acts like a proxy to those services: the Flash Player talks to a BlazeDS destination, and BlazeDS just routes a request to the appropriate service.

Frank Sommers: In addition to proxying, how can developers use BlazeDS to provide Flex-based access to an existing enterprise application?

Anil Channappa: Any JavaBean can be a remote object. There is nothing special to add to your Java code. If you already have your business logic in Java, you just need to configure your entry points to your application in some BlazeDS-specific configuration file. That's all you really need to do. If you have a class Foo, then you need to create an entry in that configuration file to enable that as a remote object. You don't need to make changes to your Java classes.

BlazeDS integration with Spring

Frank Sommers: You recently announced BlazeDS integration with Spring. Could you describe what that integration entails and how it helps a Spring developer?

Anil Channappa: A lot of enterprise developers use Spring, mainly because Spring is very easy to configure, and also because it has additional services that let you integrate with other frameworks and products, such as Hibernate, JMS, security-related services, and so on. Spring solves that integration problem in a nice way.

Spring folks realized early on the value of Flex as a UI technology, but there was no easy way to enable an existing Spring application with a Flex client. From BlazeDS's perspective, the issue was, how do you use BlazeDS, but without having to use BlazeDS-specific configuration? Could you just use Spring configuration instead? Moreover, how could you leverage your existing Spring classes without having to do anything differently?

The result is a new Spring product, Spring for BlazeDS. It integrates with BlazeDS such that each time you use a remote object, you can define BlazeDS-related configuration in the Spring configuration file. In addition, all your Spring beans have an extended protocol that supports AMF. Our goal was to allow someone already using Spring to easily transition into Flex.

Apart from remoting for Spring beans, you also get JMS integration, as well as integration with Spring security. The forthcoming version of Spring will also support REST-based services, allowing you to access any Spring bean via a REST interface. You not only will be able to access any Spring object via remoting, but the same AMF-format data can be accessed via a REST-based interface as well.

That's important because many users don't transition an application to a RESTful, Ajax-style model all the way from server to the Flash Player in one go. Rather, customers prefer to do that in phases. In the past, customers wanted to write the business logic once, and reuse that via the Flash Player as well as from HTML and Ajax, but that was just not possible. Now you can define a Spring bean, and from the Flash Player you can access that bean using AMF, and non-Flash Player clients can use those same beans via the RESTful interface. The communication will be slower in the non-AMF case, but everything will continue to work. It provides a good migration strategy to Flex.

Migrating an application to Flex

Frank Sommers: You mentioned that Spring integration with BlazeDS provides a migration path to Flex on the client. What steps would you recommend to a project that already had some UI code, perhaps JSPs or Ajax, and wanted to incorporate Flex in its UI?

Anil Channappa: If you can start building a brand new application, or new parts of an existing application, with Flex, then you'll have a Flex UI from the start. You can re-use your business logic from the server, but ignore most of the [server-side] presentation logic. Instead, the presentation logic will be implemented in Flex.

But you can also embed Flash in your existing HTML pages, because the Flash Player is an embeddable plug-in. You can take an existing HTML and Ajax application and just embed Flash Player in it. That way, you can move over to Flex on the UI side gradually. That's even easier now that we integrate with Spring. We are in the process of making it similarly easy to integrate with other Java enterprise frameworks, or even Rails.

Resources

BlazeDS
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS

Adobe's Flex SDK
http://www.adobe.com/products/flex/

Flex.org, the Flex community site
http://www.flex.org

Talk back!

Have an opinion? Readers have already posted 1 comment about this article. Why not add yours?

About the author

Frank Sommers is an editor with Artima Developer. He is also founder and president of Autospaces, Inc., a company providing collaboration and workflow tools in the financial services industry.