Archive for April, 2009
Jeff Vroom – moving on
Posted by cornel | Filed under Events
Jeff Vroom, the principal computer scientist from Livecycle Data Services team, has decided to move on from Adobe – more can be found on his new blog. Jeff was the architect for this product and the one responsible for its success. I wish him good luck with his new plans and I encourage anyone interested in RIA and middle tier technologies to bookmark his blog – I expect some good technical posts.
Adobe Developer Day
Posted by cornel | Filed under Events
The first large event organized by Adobe in Bucharest is called Adobe Developer Day and it will take place in 19 May, Intercontinental Hotel. All the details can be found here. The event will have eight session (with speakers like Ben Forta and Digby Horner) and four bootcamps. It should be interesting for everyone from RIA space, not necesarilly only for the ones already familiar with Adobe technologies
Using Hessian and Flash player
Posted by cornel | Filed under Flex, Java
I created my first application using Hessian last week and I thought I’d write about the main differences between using AMF and the Hessian protocol for remoting. You can also download my sample project here – it’s the same Hello World sample with PureMVC from a previous post modified to work with Hessian.
In comparing AMF and Hessian I’ll start with the server side.
a)Server side libraries and configuration
If you plan to use AMF you will need to use BlazeDS, LiveCycle Data Services or another product (GraniteDS, WebOrb etc). If you only need remoting you can strip out most of the jars, but you will still need more than 800 kbytes. For Hessian you need only one jar – about 300 kbytes. Also for AMF you will need to declare a servlet (MessageBroker) in the web.xml file.
b)Exposing your Java methods
When using BlazeDS any object with a public constructor can be a remoting point, and you will have to write an entry in a configuration file:
<destination id=”HelloService”>
<channels>
<channel ref=”my-amf”/>
</channels>
<properties>
<source>
org.puremvc.server.java.helloworld.services.HelloService
</source>
<scope>application</scope>
</properties>
<adapter ref=”java-object” />
</destination>
You will also have to define the channel – to specify how you intend to communicate between the client and server. For remoting the AMF channel is the preferred solution
<channel-definition id=”my-amf” class=”mx.messaging.channels.AMFChannel”>
<endpoint url=
http://{server.name}:{server.port}/hellopuremvc_blaze/messagebroker/amf
class=”flex.messaging.endpoints.AMFEndpoint”/>
</channel-definition>
For Hessian you have to write a class extending HessianServlet containing all the methods which can be invoked. After that you add this servlet in web.xml
<servlet>
<servlet-name>model</servlet-name>
<servlet-class>HessianSerializeServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>model</servlet-name>
<url-pattern>/model/*</url-pattern>
</servlet-mapping>
Another difference is that in the Hessian case all the Java objects used as value objects should implement the Serializable interface
c)Client side invocation
For AMF you do not need any external libraries because the serialization and deserialization is done natively in Flash Player. However for Hessian you will need a library and latest version (3.2) is about 500 kbytes.
From a programming point of view is the biggest difference is that for Hessian case you will need to have the AS class and the Java class in the same location (package +name) if you want to have automatic serialization/deserialization. You can use the “RemoteClass” tag also for Hessian, but it works only in one direction (from Flex to Java), at least this is what I noticed. Otherwise the call looks the same:
AMF:
service = new RemoteObject();
service.destination = “HelloService”;
service.requestTimeout = 3;
var call:Object = service.sayHello(name);
Hessian
service = new HessianService();
service.destination = “/hellopuremvc_hessian/services/”;
service.requestTimeout = 3;
var call:Object = service.sayHello(name);
The destination definition is a little bit tricky – for AMF it should be the same as the one defined in services.xml, for Hessian it should be the same as the servlet mapping from web.xml
<servlet>
<servlet-name>services</servlet-name>
<servlet-class>org.puremvc.server.java.helloworld.servlet.HelloServiceServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>services</servlet-name>
<url-pattern>/services/*</url-pattern>
</servlet-mapping>
d)Performance and other considerations
As I wrote in a previous post Hessian serialization from the server side is faster than AMF one, and the compressed data almost has the same size. However on the client side the AMF is the clear winner because of the native support provided by Flash Player. Also the Hessian library for the client is quite big.
Below are the links describing the mapping between ActionScript and Java types:
AMF
Hessian