Adobe Flex at the frontend

Adobe Flex is used to built the frontend views, but that's just the framework. You can compare a pure Adobe Flex application with something similar to a Java SE app. When you start implementing the first views you will find out that a proper MVC framework is inevitable. Thats why we've introduced one of the popular Action Script MVC frameworks thats already part of GraniteDS (Granite Data Services) called Tide.

Separation of Model, View and Controller (MVC) is only one feature that Tide and GraniteDS provide. With Tide's event mechanism it is possible to built completely lose-coupled Flex applications. Some other nice features we use from GraniteDS respectively Tide: http/AMF3 bridge, Dependency Injection, Security, Spring Integration, Server-push and a plugin to generate Action Script transfer objects (Gas3).

Tide Event Mechanism

The Tide framework is initialized when the application is loaded and recognizes all annotated Action Script controllers and MXML components. Doing so Tide knows about the components which are interested to consume particular events (like the Spring container does). Each time an event is dispatched (using plain Action Script), Tide catches the event and populates it to the event observers. At the beginning we've chosen to use the Adobe Cairngorm framework instead of Tide. But the downside of Cairngorm is, that you have to register all observers manually at startup time. This is a inflexible and error-prone task which becomes a hard job when dynamic modules have to be registered or unregistered on the fly. Tide is much more feasible regarding this aspect.

Tide Dependency Injection

Another nice feature that aims lose-coupling is called Dependency Injection, one of the key-concepts of the Spring Framework as well. An Action Script controller does not have to know about it's backing model bean - this is injected at startup. A MXML component that is backed with a data model bean gets the bean injected by the Tide client framework - lose-coupling, isn't it?

Backend Service Integration

Connections to backend services (Spring beans) are managed by GraniteDS and Tide. Tide offers several context implementations regarding to your chosen backend technology (Spring, EJB, Seam). Usually an Action Script controller is responsible to invoke service methods on the backend service. The Tide context object is a dynamic class that is injected into the controller and represents all managed backend services where the controller can invoke exposed service methods on.

Spring Security Integration

GraniteDS integrates very well with the Spring backend layer hence support for Spring Security is essential and enabled by default. An important role within Spring Security's authentication mechanism has the authentication manager. GraniteDS takes care of populating the security context with the user credentials and the security handling between both frameworks.

Spring Dynamic Modules and OSGi

OSGi environment

The big difference between OSGi containers and traditional JEE servers is the classloading mechanism. In an OSGi environment we talk about OSGi bundles instead of enterprise applications. Such a bundle represents one small piece of an application and has its own isolated classloader. All dependencies to other bundles must be named explicitly and are prevented by default whereas propagated services must be exported and are available to all other bundles. A JEE compliant enterprise application behaves completely different. One classloader is used for the whole application and all application classes and 3rd party libraries have to be packaged within one huge archive file.

A further nice feature of OSGi bundles is that multiple versions of a particular bundle can exist at the same time. That makes hot deploying parts of an application very handy. The days are gone where you had to re-deploy the whole application archive (several megabytes) and wait for a couple of minutes till the application is back again.

Spring's OSGi support

To make things easier for developers and to shield from low-level OSGi handling SpringSource introduced the Spring Dynamic Modules sub project. Creating pure Spring applications and combine them with the power of OSGi with a minimum amount of configuration effort is the target of this project and another key concept of Spring - Enterprise Integration. Beside Dynamic Modules, SpringSource hosts a repository of certified OSGi bundles that can be queried by ANT and Maven build tools for the most popular 3rd party libraries. BTW: Our Maven repository offers some 3rd party libraries that are not available on SpringSource.