I made an informal comparison table of three Java component models: JavaBeans, EJB 2.x and OSGi. I considered several point of views without being rigorous on terminology. My goal was to show fundamental features of these component models.
Personally I think that previously used component models (in particular EJB) lack many fundamental features that can help developers keeping their applications mainteneable and easy to develop.
An interesting technology that contains these important characteristics is OSGi which is an interesting enabling technology for designing new systems and applications.
| Javabeans | EJB 2.x | OSGi |
| Non invasive in application code | Invasive in application code | Non invasive in application code It means that domain code doesn’t mix infrastructure code |
| Standardize a simple deployment format | Standardize a deployment format without versioning | Standardize a deployment format with versioning and dependency management |
| Impose a convention in naming | Don’t impose any convention | Don’t impose any convention |
| Support traditional programming model | Support traditional programming model | Support traditional and service oriented programming model. Favor loosely coupling design principle |
| Don’t support distributed programming | Support distributed programming | Don’t support distributed programming |
| Don’t support security | Support security | Support security |
| NO dependency management | NO dependency management | Support automatic dependency management between components |
| Don’t support code sharing | Don’t support code sharing | Support controlled code sharing between components |
| Don’t support loading of same classes with different versions (JAR-Hell problem) | Don’t support loading of same classes with different versions (JAR-Hell problem) | Support loading of same with different versions inside the same process |
| Don’t support dynamic loading/reloading of components | Don’t support dynamic loading/reloading of components | Support dynamic loading/reloading of components (hotplug) |
| Don’t support transactions | Support transactions | Don’t support transactions |
| Don’t support dynamic configuration | Don’t support dynamic configuration | Support dynamic configuration |
| Synchronous invocation | Synchronous and Asynchronouse invocation | Synchronous invocation. Support asynchronous events |
| No Container Services (no need for a container) | Container services:
|
Container services:
|
| Standard specification | Standard specification | Standard specification |
{ 1 } Comments
For the JavaBean column, isn’t java.beans.BeanContext the container model?
Quote:
Package java.beans.beancontext Description
Provides classes and interfaces relating to bean context. A bean context is a container for beans and defines the execution environment for the beans it contains. There can be several beans in a single bean context, and a bean context can be nested within another bean context. This package also contains events and listener interface for beans being added and removed from a bean context.
Since:
1.2
Perhaps, in the future, something Like Spring will become the defacto Javabean container model?
Post a Comment