Traditionally, BEA applications have been built as a series of Jar files with ant (and then launched with one giant CLASSPATH) or as installable JEE applications. However, going forward (and aiming to be complete by end of 2008) is a switch to using the microServiceArchitecture (mSA) which is a provisioned set of bundles on top of an OSGi runtime. A simple servlet engine consisted of 38 bundles with a deployable footprint of 3Mb, and this summer will be releasing the WebLogic Liquid Operations Control (WL LOC) as the first mSA application.

To facilitate development of this system, the concept of feature sets (sets of bundles) are tested and ensured that they work to each other; for example, the base feature has utilities and standard configuration code, whilst the enterprise feature has JNDI, JDBC etc. supplied. Although OSGi would allow any of those bundles to be individually updated, the mSA launcher ensures that a valid (tested) set of bundles are used together. There's about 100 bundles in the current setup, but more of them are expected in the future.

The good : OSGi handling of packages and modules works well for mSA, especially since this gives a better picture of dependencies (and thus, it's harder to introduce accidental dependencies). Moving to OSGi isn't easy though, especially if there's a lot of so-called 'modular' code that really has extra-modular dependencies.

The bad : the Java security model is additive, which means that you can't revoke permissions, and as such, configuring the OSGi security is roughly the same. The configuration isn't well externalised; for BEA customers, they expect the configuration to be in XML files and (in addition) the ability to change/verify many properties in a single go with rollback if validation fails. Lastly, there are some existing Java code systems which have different uses; OSGi has fixed the case of the URLStreamHandler, but other libraries (particularly the WS stuff) have singleton sets which make it difficult to use in an OSGi environment.

The ugly : The bundle installation model, with persistent bundles and the configuration data, doesn't suit some types of application well (such as servers or command-line utilities) although it does others (embedded devices). It would be better if there were was of launching OSGi with a fresh set of new bundles each time, and without needing writable configuration area if not necessary (though Equinox uses this for caching as well as state information). Also, there's no standard for launching OSGi systems (yet) so the BEA mSA is tied to Equinox at the moment; but perhaps the initial provisioning service will bring a general way of launching OSGi VMs in the future. Lastly, JSR277. Why re-invent the wheel? If it makes it into the core Java (as Sun hopes it will), it's only going to confuse matters.