Modularity in Flex enterprise applications

The need for Flex modules

When applications grow to be bigger, there are several reasons to split them up into modules. Here we focus on some reasons specifically applied to our Flex applications. This makes it clear what features our modularity system provides and why.

• For developers: Code manageability. If you’d develop a large Flex application into one big project, it would quickly grow to be unmanageable. Any class can depend on any other one. By splitting into separately compiled modules, you are forced to properly separate concerns, giving better maintainable code. Although they are compiled separately, modules can depend on each other, but dependency cycles must be impossible.
• For users: Performance. Flex applications can be used over the internet, over possibly slow connections. Someone who only uses part of the application should not have to download everything before he can use it. The module system automatically takes care of loading modules on demand; only when they are really needed.
• Pluggability. Not every user is interested in all functionality, some might only need a limited set of modules. Developers cannot foresee all possible combinations of modules that can be shipped together. Some client-specific modules can be added too. The main application and modules can not know in advance (at development/compilation time) which other modules will be available. Available modules must automatically plug their features into the appropriate locations (e.g. in the user interface), even before they have been loaded.

Technical basis

In the Flex/Flash world, there are several kinds of module artifacts. None of these provide the separately compiled, inter-dependent, on-demand-loaded modules we want; but they are the building blocks of our solution.

• Swf modules are loaded on demand at runtime by the Flash Player. But you cannot use a swf as a dependency when building another artifact.
• Swcs can be used as a dependency when building another artifact. They are compile-time-only: helpful during development, but they don’t exist at runtime. The Flash Player cannot load them.
• Rsls (runtime shared libraries) can be used as dependencies and are loaded at runtime. But they are always loaded immediately when the application or module that uses them is loaded. They are not on-demand.

The common way of splitting a Flex application into swf modules, is to have the application and all its module in the same project. In other words, dropping our “separately compiled” requirement. You tell the Flex compiler what the main classes of the application and the modules are, and it will automagically figure out which classes are (directly or indirectly) used by which part, and include them in the right swf that it generates. This big project that contains or depends on everything and generates all swf artifacts may work for small applications, but for bigger ones it has several problems. It is slow to compile, hard to manage and predict (what codes ends up in what module), and does not fit into the maven world. And there’s no way to make this pluggable; no way to add a module to this without touching the central project.

Our solution is to have sources of modules separately (in different maven modules / FB projects), and for each of them generate both a swf and a swc from the same sources. The swf is deployed in the web application, and the swc is only used for other modules that depend on it. This takes care of code manageablility and performance. Next, we’ll make modules pluggable.

Extensions and extension points

With the standard approach of loading Flex modules (using the ModuleLoader or ModuleManager), the name of the swf to load is hard-coded in the main application. We want any module to be able to plug itself in, so the application can’t have an explicit reference to any module, not even the name. To accomplish this, when some code needs a feature that may be in another module, instead of asking for a particular module, it must ask for the feature it needs. Modules describe which features they provide, so at runtime the system can figure out which module needs to be loaded.

For this we heavily base ourselves on the ideas of Eclipse extension points and extensions, but apply them in Flex. An extension point is a place in an application or module, where another module’s extension can be plugged in to add the needed functionality. Just like in Eclipse, modules describe their extension points and extensions in a plugin.xml file. For example, we have a main application with a menu bar, where entries in the menu can open a view that fills most of the screen. We call these kinds of views tasks. One such task in the Flex scheduler module is the TriggersTask, in which the user can configure a scheduler running on the server. The main application defines the task extension point in its plugin.xml and provides the xml schema for this point. In the scheduler module’s plugin.xml, there is the TriggersTask extension. Concretely, it looks like this:

The plugin.xml of course can’t be embedded in the swf, because it is needed before the swf is loaded. Instead, for every module, in addition to the swc and swf, we package the plugin.xml separately. All plugin.xmls of available modules are combined on the server-side into one plugins.xml file which is downloaded by the flex client at startup. That way it knows which tasks it can show in the menu without loading any of their module. Using this extension point mechanism makes it easy to abstract away the details involved in dealing with modules from the code that uses it (e.g. the code behind the menu). It simply asks for a list of all task extensions, and when the user selects a menu entry, it asks for the extension’s implementation. It doesn’t have to care if the task is in the same or in a different module that is already loaded or not. Loading a module is an asynchronous process, so to get an extension, you have to pass a callback that will be called when it is available (which can be immediately).

Conclusion

The Flex framework provides the basic foundations for a module mechanism. To build truly modular, performant, pluggable applications we made a layer on top of it using a double swf-swc compilation mechanism and extensions inspired by Eclipse. This turns out to be a nice fit: it cleanly abstracts the lazy asynchronous loading, and making many parts of application pluggable becomes easy.
We covered the basics here, but this opens up more opportunities: we take advantage of this mechanism to handle asynchronous initialization steps of modules, automatic loading of dependent modules and more.