Developing JEE applications using Grails and Flex

The Java platform has evolved into a mature and reliable enterprise application platform, and a hallmark of a mature application platform is its ability to drive a wide range of derivative technologies and options that can be integrated with other technologies. This article will detail how to develop JEE using the derivative technology developed by grails, a traditional JEE application, and a different flex technology that can be used in Java. These two platforms can greatly improve development efficiency. The combination of the two will not affect the overall development efficiency while creating rich clients for the Java EE application.

The predecessor of Grails is a Web application running in the JVM, which uses groovy and several other well-known frameworks, such as spring and hibernate. In order to realize rapid application development, it relies heavily on the principle of "convention over Configuration". Groovy has a lot of dynamic features and is very powerful in defining common behavior between components. Grails uses the plug-in architecture, so it's easy to integrate it with other frameworks, and it's easy to reuse their capabilities between applications.

Flex is an RIA development kit, and the SWF application created by it can only be applied under Flashplayer. This is a new flash development kit for Adobe (formerly Macromedia). In addition to the powerful language of rich widgets and the ability to glue various widgets together, it provides some high-end communication solutions, and the development of distributed applications becomes quite easy. It uses two kinds of syntax: Mxml and ActionScript. Mxml is created on top of the XML syntax to define the user interface for common components, while ActionScript is used to define dynamic interactions between components.

The integration of Grails and flex--the challenge

To combine the two frameworks, which are based on a completely different foundation, between Grails and Flex, you first encounter a lot of communication problems:

How can a component in a framework find the right communication object in another frame?

In essence, Grails is actually a Web application framework running on the server's JVM. Flex is an RIA platform with client and (thin) server components, and server components are deployed as Web applications. Therefore, the integration between the two frameworks is actually done within the Web application container.

Communications initiated by a user in the Flex UI must invoke the business logic through the grails component. So how does the Flex UI component find the right Grails component?

How do you parse each other's data between frames?

Flex uses ActionScript to describe data, while Grails uses Java and Groovy objects. The ActionScript object sent to the server by the Flex UI should be relayed to the data structure that the application understands. How does this happen?

How can a user's modifications interact with other users of the application?

This is a pervasive problem for multiuser applications, but using two different frameworks at the same time makes the problem more complex. The difficulty is in the Grails application, where users start the application through the Flex UI, but how can they communicate with other users through the flex UI to let them know the user's action?

In the next three sections, we discuss the three issues mentioned above in detail, looking for solutions that adopt grails and flex.

Integration-looking for a message sink object

How can a component in a framework find the right communication object in another frame?

In the case of Grails and Flex, the question is asking how the flex component can find the right grails component to send the request data, or perform some action on behalf of the user. To better understand the solution to this difficulty, we first look at the Flex communication subsystem.

Customer in Flex--server communication

Flex's communication subsystem can be divided into two parts for customers and servers. The customer section contains components that allow applications to send or receive messages, such as RemoteObject and consumer components. These components are associated with server-specific "service" objects, such as Remotingservice and Messagingservice. The combination of customer components and their associated server components can support typical communication patterns. For example, with consumer, producers, and Messagingservice, the application software can communicate using the Publish-subscribe mechanism.

Communication between customer and service devices is done through the channel (Channel). The channel implementation is not unique, and the most important of all channels is AMFChannel and Rtmpchannel. AMFChannel is based on HTTP, which means that it is built on a request-reply architecture. It can be used concurrently with Messagingservice to support the Publish-subscribe architecture. In this combination, the channel periodically reads the new message from the publication, generating the request. Rtmpchannel is more efficient in such a configuration, and it can support client-server connectivity on a TCP/IP basis. This allows messages to be sent or received immediately between the client and the server. Unfortunately, Adobe free Open-source Flex implementation--blazeds does not include such a rtmpchannel implementation.

The most important communication infrastructure in flex is destinations. Destination is the server end of the communication channel. A service provides a destination, and the customer component is associated with the service through this destination. The associated customer component can send and read messages to the destination. Destinations can be created by factories.

Grails-Exposed remote interfaces: services

How do you combine Flex's complex communication facilities with Grails? Grails can identify several types of objects: domain objects, controllers, views, and services. Every service in Grails is through an external communication channel--such as http----to show an object of some function or service. In flex, each service corresponds to a destination.

This is precisely the solution offered for Grails's flex-plugin. All services indicated in Grails to flex display will be registered as destination in the Flex framework. Grails adds the indicated service to a specially configured Remotingservice in flex through a specific factory. This particular factory will navigate to the corresponding service in the spring context that Grails uses. All of these configurations can be found in Services-config.xml, and Flex-plugin will copy the file to the correct location for grails.

class UserService {
　static expose = ['flex-remoting']
　def List all() {
　　User.createCriteria().listDistinct {}
　}
　def Object get(id) {
　　User.get(id);
　}
　def List update(User entity) throws BindException {
　　entity.merge();
　　if (entity.errors.hasErrors()) {
　　　throw new BindException(entity.errors);
　　}
　　all();
　}
　def List remove(User entity) {
　　entity.delete();
　　all();
　}
}

This configuration will show UserService to flex customers. The following Mxml code is the application of this configuration to the previous section. RemoteObject's destination is UserService, and this userservice is the name of the service provided by the target object in Grails. All methods of the service object can be invoked as remote operations. ActionScript can invoke these operations as normal methods, and the result or error of the method invocation can be treated as a generic ActionScript event.

...
　<mx:RemoteObject id="service" destination="userService">
　　<mx:operation name="all" result="setList(event.message.body)"/>
　　<mx:operation name="get" result="setSelected(event.message.body)"/>
　　<mx:operation name="update"/>
　　<mx:operation name="remove"/>
　</mx:RemoteObject>
...Conclusion

Flex-plugin's integrated solutions for grails are beautiful, easy to use, and almost automated. Under the Convention-over-configuration concept, the naming convention is used when destinations dynamically adds to the flex configuration.