Cornel Creanga

Archive for the ‘LCDS/Blaze DS’ Category

Bringing data into Flex applications - introduction

Posted by cornel | Filed under Flex, Java, LCDS/Blaze DS

This article will describe the most common ways to bring data into a Flex application and will present the advantages and disadvantages of each approach. It assumes that the reader has a basic understanding of the Flex language.

Unlike a classic web application (by classic I mean pre AJAX) where the pages are generated on the server the Flex application is loaded at startup and makes calls in order to load or to save data. Of course a Flex application can also make requests in order to load other Flex modules in the same way a Java application can dynamically load JAR libraries but that is a subject for a different article.

Some of the presented solutions are server agnostic – you can use anything on the backend – others assume that you have installed a Java application server where you can deploy various solutions including BlazeDS, Livecycle Data Services, GraniteDS, WebORB etc.

a)Opening a socket connection between the Flex application and the backend.

A socket connection It is the most low-level solution and at the same time the one most flexible. You will have to define your own protocol and how to serialize data (or use the AMF/Hessian protocols). In most cases, you should use this solution only if you have a very specific business need and the existing solutions do not meet your requirements).

You can use Apache MINA if you intend to do that. For example Red5 Flash server was written using the MINA framework.

Bellow is a simple code snippet that shows how to create a socket and how to read or write data:

public function initConnection():void{

    CursorManager.setBusyCursor();

    Security.loadPolicyFile(“xmlsocket://localhost:24″);

     socket = new Socket();

     socket.addEventListener( Event.CONNECT, onConnect );

    socket.addEventListener(ProgressEvent.SOCKET_DATA, socketRead);

    socket.addEventListener(ErrorEvent.ERROR, errorHandler);

    socket.addEventListener(IOErrorEvent.IO_ERROR, errorHandler);

    socket.addEventListener(SecurityErrorEvent.SECURITY_ERROR, errorHandler);

    socket.connect(“localhost”, 23);

}

public function socketWrite(event:Event){

    socket.writeUTF(inputName.text);

    socket.flush();

}

public function socketRead(event:ProgressEvent){

  while ( socket.bytesAvailable ) {

        var data:String = socket.readUTF();

        Alert.show(data);

  }

}

You probably noticed the line Security.loadPolicyFile(”xmlsocket://localhost:24″); By default a Flex application can open connections only to the same domain from where it was loaded and on the same port. In order to be able to initiate connections to another domain a file named crossdomain.xml must exists on that server. This file specifies the what resources are available and for what domains. In our case the policy file will allow that the all the SWF loaded from any domain are allowed to connect to the port 23

<cross-domain-policy>

    <allow-access-from domain=“*” to-ports=“23″ />

</cross-domain-policy>

For more details regarding the policy files and Flash security, see this documentation.

b)Using REST and SOAP services (via HTTPService and WebServices components)

REST and SOAP services works with any type of server-side technology – also these technologies are standard and most of the biggest service providers(Yahoo, Amazon, Google, Flickr, eBay) expose their API through both of them . There is an endless debate on when to use REST and when to use SOAP but that is beyond the scope of this article. Instead I will present some samples on how to use them.

As with the sockets example, because the Flex application can initiate requests only to the same domain from where it was loaded you’ll need a crossdomain.xml file on the server where the services are located. Obvious you cannot put a policy files on every server so use the following approach: connect to the back-end server from where the Flex application was loaded and use that server to make the request – after that send the result back to the Flex application. For that you can use an existing product – BlazeDS or another solution.

Below is a sample code showing the two mxml tags used to call REST and SOAP services:

<mx:HTTPService id=“resultHttpService”

     url=“http://www.sampledomain.com/query.jsp?quote=ADBE” />

<mx:WebService id=“resultWebService”

     wsdl=“http://www.sampledomain.com/quotes?wsdl” />

In this case I am connecting directly to sampledomain so the first time the Flash Player will check for crossdomain.xml to see if the server allows the request.

In order to use the proxy approach (use the server to do the request) I will modify the code:

<mx:HTTPService id=“resultHttpService” destination=“HTTPDestination” useProxy=“true” />

<mx:WebService id=“resultWebServive” destination=“WebServiceDestination” useProxy=“true” />

and in proxy-config.xml I will add the destination definition:

<destination id=“resultHttpService”>

    <properties>

        <url>http://www.domain.com/query.jsp?quote=ADBE</url>

    </properties>

</destination>

<destination id=“ws-catalog”>

    <properties>

        <wsdl>http://www.domain.com/quotes.wsdl</wsdl>

        <soap>*</soap>

    </properties>

    <adapter ref=“soap-proxy”/>

</destination>

In the REST example it is very important to notice that due to Flash Player limitations you are allowed to use only GET and POST methods, and any return code other than 200 will generate a fault. To overcome these limitations you can write your own proxy server, or better still, use one already written (BlazeDS for example).

c)Using remoting

Remoting technology allows developers to directly invoke methods on the backend server. Initially this was possible only with Java and Coldfusion but after that different implementations have appeared for PHP, Python, Ruby and .Net. Also there are several other implementations that use Hessian protocol. Below I will present some examples for Java language, using BlazeDS.

The mxml tag from the Flex application looks the same as the ones used for calling webservices – the main attributes are the id and the destination

<mx:RemoteObject id=“productService” destination=“ProductService”/>

The destination is configured into the file remoting-config.xml:

<destination id=“productService”>

    <properties>

        <source>

            com.test.services.ProductService

        </source>

    </properties>

    <adapter ref=“java-object” />

</destination>

The remote object allows you to call methods on the Java object associated with the corresponding destination. Everything else is transparent from the user’s point of view (including the conversion between ActionScript and the Java objects and the serialization mechanism that can handle complex objects graph). You will only need to declare the mapping between the ActionScript and the Java objects using the [RemoteClass] metadata:

package com.test.model{

    [RemoteClass(alias="com.test.model.Product")]

    public class Product{

        public var id:int;

        public var name:String;

    }

}

Before you start to use remoting it’s a good idea to read this link describing data types conversion between Java and ActionScript.

It is important to notice that on every I/O operation also the remote method is invoked asynchronously so you will need to register handlers for the result and fault events.

d)Using messaging

There are currently several messaging solution on the market for the Flex applications: BlazeDS (and the commercial version Livecycle Data Services) , Granite Data Services and WebORB. All of them also have integration with JMS servers.

With messaging, a Flex application can connect to a message destination on the server (specified in messaging-config.xml) and can exchange messages with the server or with another clients (using the server as a proxy). You can use messaging to have the server push messages to the clients (for example, in an application that displays the latest stock prices) and you can use it for collaboration between clients (for example a chat application).

One of the most important things when working with messaging is choosing the proper communication channel in order to obtain real time messaging. BlazeDS server supports HTTP streaming and polling (short and long) over AMF and HTTP channels. HTTP streaming is the best way to obtain data in real time but because of the limitations from the servlet model it keeps one thread open per connection. The commercial version (Livecycle Data Services ES) overcomes this limitation with the help of NIO channels (RTMP and NIO HTTP).

Below is a code sample that shows the main tags used for messaging:

<mx:Producer id=“producer” destination=“chat”/>

<mx:Consumer id=“consumer” destination=“chat”/>

The destination chat is defined below:

<default-channels>

    <channel ref=“my-rtmp”/>

    <channel ref=“my-streaming-amf”/>

</default-channels>

<destination id=“chat”>

    <properties>

        <network>

            <!--The session timeout for inactive HTTP sessions–>

            <session-timeout>0</session-timeout>

        </network>

    </properties>

</destination>

Detailed information regarding messaging can be found in the Messaging Service chapter of the BlazeDS developer guide.

e)Using Data Management Service

Data Management Service is a feature provided (as of the writing of this article) both in Livecycle Data Services ES and WebORB. Both products offers a framework called Data Management however the architectures differ – in this article I will discuss only the Data Management framework provided by Livecycle Data Services. It operates at a much higher level than the messaging and RPC services. While it can be used for different types of applications it provides the most value for data intensive applications (especially where collaboration is very important). It is designed to solve several important challenges:

• synchronizing data on clients with the server without having to write CRUD methods
• automatic or manual data synchronization between clients
• conflict handling, paging data sets, working with offline applications and synchronizing the data when the application is online again

One can make a comparison between Data Management and Hibernate – both frameworks allow the developers to concentrate on defining the domain model and working with it without spending too much time on problems like how to persist, load, version and synchronize data. Hibernate deals with data persistence into database, Data Management with data persistence and synchronization between client applications and the server. There is also integration between these two frameworks and I’ve attached a fully working example showing that.

As with messaging,it is very important how to choose the correct communication channels (especially for automatic synchronization feature). The same choices described in the messaging example apply here.

Here is a simple example that shows how easy it is to create an application for editing a table:

The Flex code:

<?xml version=“1.0″ encoding=”utf-8″>

<mx:Application xmlns:mx=“http://www.adobe.com/2006/mxml” layout=“absolute” initialize=“init();” >

    <mx:Script>

        <![CDATA[

            import test.*;

            import mx.collections.ArrayCollection;

            import mx.data.events.*;

            import mx.events.*;

            import mx.data.*;

            var    companyDataService = new DataService("test.Company");

            [Bindable]

            var companyArray:ArrayCollection = new ArrayCollection();

            function addCompany():void{

                var company:Company = new Company();

                company.name=“<new company>”;

                companyArray.addItem(company);

            }

            function deleteCompany():void{

                var company:Company = companyGrid.selectedItem as Company;

                if (company==null)

                    return;

                companyDataService.deleteItem(companyGrid.selectedItem);

            }

            function save():void{

                companyDataService.commit();

            }

            function revert():void{

                companyDataService.revertChanges();

            }

            function init():void{

                companyDataService.fill(companyArray,“mainFill”,[]);

                companyDataService.autoCommit=false;

            }

        ]]>

    </mx:Script>

    <mx:VBox width=“100%” height=“100%” horizontalAlign=“center” >

        <mx:DataGrid  id=“companyGrid” width=“40%” height=“40%” dataProvider=“{companyArray}” editable=“true” textAlign=“center”>

            <mx:columns>

                <mx:DataGridColumn dataField=“id”  headerText=“Id” editable=“false”/>

                <mx:DataGridColumn dataField=“name”  headerText=“Company”/>

            </mx:columns>

        </mx:DataGrid>

        <mx:HBox horizontalAlign=“center” width=“100%”>

            <mx:Button label=“+” click=“addCompany();”/>

            <mx:Button label=“-” click=“deleteCompany();”/>

        </mx:HBox>

        <mx:HBox width=“100%” horizontalAlign=“center”>

            <mx:Button label=“Save changes” click=“save();”/>

            <mx:Button label=“Revert modifications” click=“revert();”/>

        </mx:HBox>

    </mx:VBox>

</mx:Application>

The definition of the DataService object is located in the configuration file data-management-config.xml

<destination id=“test.Company” channels=“my-rtmp”>

    <properties>

        <source>flex.data.assemblers.HibernateAnnotationsAssembler</source>

        <scope>application</scope>

        <item-class>test.Company</item-class>

        <metadata>

            <identity property=“id” />

        </metadata>

        <server>

            <hibernate-entity>test.Company</hibernate-entity>

        </server>

    </properties>

</destination>

As you can see there are no remoting calls – after the collection companyArray is filled with data you can manipulate the data by adding new elements, deleting or updating elements. You have the option to call save when you want to persist the modifications or revert if you decides to discard them.

It is possible to work with more complex domain models (associations between objects) and you can find one example of this attached.

Data Management is the most appealing approach for bringing data into a Flex application, but like Hibernate case it has a steep learning curve. Documentation related to it can be found in LCDS developer guide.

The following table summarizes the advantages and disadvantages for each solution:

I have also attached an archive containing one Flex Builder project showing the data transfer using sockets and also a more advanced case of data management use. For the rest of the cases I recommend that you download the most recent version of BlazeDS (look in samples folder) or LCDS (look in the lcds-samples folder). If you want to use non Adobe products you can try WebORB (look in examples/flex folder) or GraniteDS (I was not able to find a folder with samples in this product).

Read more | Comments (5) | Nov 11, 2008

Connecting Java applications with Blaze DS

Posted by cornel | Filed under Java, LCDS/Blaze DS

A new feature was added to Blaze DS (currently only in the nightly builds) – the ability to connect to a Blaze DS server from a Java client. It’s a useful feature if you have to do integration between some legacy Java application and a Blaze DS server and you don’t want to write your own serialization mechanism or if you plan to write some tools for testing.

The specification can be found here and I’ve also created a Hello world project which can be downloaded from this location. On my local computer I was able to do about 3000 calls per second – impressive compared with a WebService call.

On the client I wrote four lines of code in order to invoke the method from the server:

AMFConnection amfConnection = new AMFConnection();

amfConnection.connect(http://localhost:8080/blaze/messagebroker/amf);

Message message = (Message)amfConnection.call(“HelloService.sayHello”, new Message(“cornel”));

amfConnection.close();

And the method signature is:

public class HelloService {

    public Message sayHello(Message message){

        return new Message(“hello “+message.getText());

    }

}

On the client you need to use two jar files from Blaze DS distribution (flex-messaging-common.jar and flex-messaging-core.jar).

Read more | Comments (0) | Oct 14, 2008

LiveCycle Data Services 2.6 – new features (4)

Posted by cornel | Filed under Java, LCDS/Blaze DS

Support for offline synchronization was improved in LiveCycle Data Services 2.6 – the Flex applications deployed on the AIR runtime will use a cache base on SQLite database instead of a Local Shared Objects cache.

There are several resources describing in details this feature in detail and providing some samples – Cristophe Coenraets blog, an article on Inside RIA and the developer guide.

Of course, you can synchronize your application without using LiveCycle Data Services and use whatever suits you best (SQLite or LSO), in fact I know several developers who have been doing this for the Flex applications they deploy on browser for a long time. There are, however, advantages to using the LiveCycle Data Services solution for the offline/online synchronization are:

• you do not have to write additional code to deal with synchronization so you can save a lot of time
• you can use the already implemented conflict resolution model

Read more | Comments (0) | Sep 14, 2008

LiveCycle Data Services and Hibernate one-to-many association

Posted by cornel | Filed under Java, LCDS/Blaze DS

I’ve noticed that several peoples have problems implementing one-to-many associations so I decided to write a simple example (using HibernateAnnotationsAssembler). It contains several use cases of working with this kind of association (more than the samples provided with LCDS distribution):

• you can modify (update, add, delete) a parent or a child and see the synchronization between several clients. Note that when deleting the parent I have to programmatically delete the children’s – cascade on delete does not work yet automatically
• you can create a parent and a child in the same transaction (no need to create the parent and save it before adding the children)
• you can revert your modifications
• conflict management should work both for parents and children
• you can check the generated SQL in the server console (I’ve tested with MySQL database) and see the effect of the load-on-demand and page-size attributes).
• you can check what happens when cache-items is set to true and when it is set to false

Note: I’ve mapped the one-to-many association as bidirectional (The parent has a list of children and a child has a reference to the parent). However if you have a large number of children associated with a parent, then from a performance point of view it is better to drop the list from the parent)

Also because the association is bidirectional I had to add the read-only attribute for the list of children (to notify the dataservice that it should look for updates only at the other end). If you will set the value to “false” you will see some strange SQL commands.

I’ve used Java 1.5 and Hibernate annotations so there is really not much code. You can download it from here (it’s an archive containing a Flex project and a readme.txt).

Read more | Comments (2) | Sep 9, 2008

LiveCycle Data Services 2.6 – new features (3)

Posted by cornel | Filed under Flex, Java, LCDS/Blaze DS

Two new endpoints were introduced in LiveCycle Data Services 2.6: NIO AMF and NIO HTTP and with them one can have now a viable alternative to RTMP. While RTMP offers best performance for data push - offers a direct duplex socket connection between the client and server and does not need a dedicated thread for every connection it uses a non-standard port (2038) so sometimes it is blocked by firewalls. If the firewall restriction cannot be lifted the other options was to use servlet-based AMF and HTTP endpoints and use long polling or HTTP streaming to emulate real time communication. The scalability was very low compared with RTMP (maybe several hundreds/thousands compared with tens of thousand) because of the dedicated thread per connection.

With the new endpoints this problem was solved – by building a NIO server based on the JAVA NIO api this limitation was removed– now it is possible to handle the connections asynchronously. And you do not have firewall issues because they are using the HTTP port.

From the client point of view the NIO AMF and HTTP endpoints are equivalent to the old endpoints (AMF and HTTP) so you should not modify the existing applications (but you cannot share the FlexSession between channels using NIO HTTP endpoints and the ones using HTTP). After you download the Livecycle Data Services 2.6 you can find several examples of how to configure them in the services-config.xml file.

It is important to mention that these new endpoints were introduced only for LiveCycle Data Services and not for Blaze DS - so if you are using the last one you still have to deal with the limitations of the current servlet API (one thread per connection) – at least at the moment of writing this post. Probably the situations will change in future – Blaze is open source so anyone can contribute to the source code. There seems to be other several free options - GraniteDS and WebORB however I did not had yet time to test them.

Read more | Comments (0) | Aug 22, 2008

Flex, Blaze DS and storing session data

Posted by cornel | Filed under Flex, Java, LCDS/Blaze DS

One of the biggest difference between the classical web applications (HTML/JS) and the rich ones (Java applets, Flex, Silverlight) is how can you store the state of the application.

With HTML applications we are used to using different hacks to store the state – either appending all the necessary information to the requests or storing the data on the server (and using a cookie or a session id to link the user and the information). Some even use a “dirty hack” and keep a small window open where you can store/retrieve all this information by using Javascript (yes, I have seen this unusual approach in several applications).

With Flex applications (and also with the other technologies mentioned before) the things are much simpler. You do not have several pages which are loaded from the server, instead you have an application that is loaded in the browser and can store the data using its internal data structures. The application will make requests to the server but only to exchange data (and in some situations to load modules), not to load whole pages. To make an analogy – it’s like having a HTML application composed of only one page that uses AJAX and JavaScript to load and build other pages (This is doable, I have seen a project where the guys were using this approach because of some strange requests from the client, but it was a nightmare to maintain and develop the application).

So you are able to store user preferences, user actions (for example the products added to a shopping cart) and other data directly into the client – the Flex application. It is more natural (in my opinion) than storing the data on the server and it is also much cheaper than buying expensive hardware for the middleware – you are using the client machine to store data so you are not overloading the server (think about having 100000 connected clients and session replication and you will understand what I’m talking about).

However there are several situations when you have to store a minimal amount of information on the server – the user identifier for example. After a successfully login authentication I have to store the user ID into the server session. After that this ID is used to check all the requests and to filter data that is sent to the client. Below I show you how to do that in Flex and what things you need to take into account. I’m using Blaze DS  on the server side.

The FlexContext class can be used to access the FlexSession class which has several useful methods to set/get/remove attributes, to configure the timeout and session listeners, and so on. Here is some code that shows how to use them.

UserRoles userRoles = userHome.logIn(userName, passwd);

if (userRoles == null)

  throw LoginFailedException(“Invalid login”);

FlexContext.getFlexSession().setAttribute(“userId”, userRoles.getUserId());

public Collection fill(List fillArgs, int startIndex, int numItems){

    Integer userId = (Integer) FlexContext.getFlexSession().getAttribute(“userId”);

    if (userId==null)

        throw AuthenticationException(“No logged user”);

    ASObject map = (ASObject)fillArgs.get(1);

    Integer companyId = (Integer)map.get(“companyId”);

    return new CompanyService().findProducts(

            companyId,

            userId);

}

Note: this is just a simple example how to use FlexSession. For user authentication and securing destinations read the LCDS developer guide, specifically the chapter titled “Securing destination”.

Important things to take into account when working with session data (taken from the developer’s guide):

• when using RTMP channel after a browser refresh the content of the FlexSession is lost; also the user will have to log in again
• you will have different FlexSession objects for HTTP, RTMP and NIOHTTP channels – so consider working with only one type of channel
• if you logged in using a RTMP channel you must log in again when switching to another type of channel
• FlexSession is not cluster aware - if a client connects to a different server in the cluster, the client receives a new FlexSession and the client will have to login again

Read more | Comments (1) | Aug 21, 2008

LiveCycle Data Services 2.6 – new features (2)

Posted by cornel | Filed under Flex, Java, LCDS/Blaze DS

This is the second post describing several new features in the 2.6 version of LiveCycle Data Services– I will present several features that are related to managed associations.

In the current version several new parameters were introduced: read-only, load-on-demand, page-size, paged-collection and paged-updates.

The first one should be used for bidirectional relationships and it has the same meaning as setting inverse=”true” for a Hibernate association (the assembler will use only the other side of the relation in order to take modifications into account).

The other ones are used to improve the performance of managed associations. In the previous version you could improve it in several cases by using the “lazy” parameter. When set to true and applied to a one-to-one, one-to-many, or many-to-many association the client, by default, will load by default only the ID of the objects - the whole object will be loaded only when it is accessed for the first time. This can improve performance, but if you have a large collection you will still have to load a lot of information from the database to obtain all the ID’s and send them to the client

The new parameters remove this limitation. When you set load-on-demand for an association no values are sent to the client until the first time the association is accessed (it has the same effect as the lazy parameter for Hibernate managed collection). The page-size and paged-collection parameters are used to implement page-by-page fetching from the database/server - very important for large sets. The last one, paged-updates, controls the way in which the modifications from the client are sent to the server. If the value is false the entire collection is sent when some objects are removed or added, if true only the ID’s of these objects are send to the server. This parameter is automatically set to true if also page-size is set to true.

The effect of these parameters can be noticed especially when working with large collection – I performed some tests with a collection that has about 50000 elements (loaded in a datagrid) and it worked smoothly.

Read more | Comments (3) | Aug 18, 2008

LiveCycle Data Services 2.6 – new features

Posted by cornel | Filed under Flex, Java, LCDS/Blaze DS

I plan to write some posts describing what’s new in LiveCycle Data Services 2.6 compared with the previous version (2.5.1) and also to provide some examples. There are some important new features that affect both productivity and performance

Today I will describe two of them: hibernate annotations and the automatic creation of associated destination

First, you can now use hibernate annotations because a new type of assembler was introduced – HibernateAnnotationsAssembler. This assembler extends HibernateAssembler and it has only one supplementary method – createHibernateConfiguration, which knows to create a Configuration class from the annotations.

In order to use the annotations the following steps should be followed:

a)Declare annotations for the persisted objects

b)Change Hibernate configuration files in order to use <mapping class=”class name”/> instead of <mapping resource=”resource name” />

c)Change the assembler for a destination from HibernateAssembler to HibernateAnnotationsAssembler

d)Add the following entry to the destination configuration:

<item-class>class name</item-class>

The second one: Now it is possible to create automatically associated destinations as long as the destinations you are directly using for are defined in the data-management-config.xml. Also you can skip the identity tag for a destination and then it will be automatically generated taking into account the corresponding annotations. The big advantage of this is that now you can create and manage your destinations faster. The disadvantage is that if you do not want to configure any metadata you can lose performance (for example if you do not specify load-on–demand for a large set).

Another important point is that you cannot use the automatically created destinations for fill operations – if you want to do that you will have to add an explicit destination declaration for them into data-management-config.xml.

Below is an example of data-management-config.xml which uses the new way of declaring destinations:

<?xml version=“1.0″ encoding=“UTF-8″?>

<service id=“data-service”

    class=“flex.data.DataService”>