...
In short, we took an A la Carte approach, choosing only those technologies we actually needed that fullfilled our requirements, and adopting an *emerging post-EJB consensus* favoring a lightweight container to provide only those J2EE Enterprise Services we required.
Under this definition, a continaer could be anything from a full-blown J2EE Application Server to Apache Tomcat, depending on the services required of the container.
...
For the GLAST Framework, a lightweight container had to provide the following services:
Service | Description | All Containers | Lightweight Containers |
---|---|---|---|
Lifecycle management | Control lifecycle of application objects running within it (for example, clean initialization, startup and shutdown). |
| |
Lookup | Obtain references to managed objects; create objects/services on demand. |
| |
Configuration | Externalize configuration from code into simple configuration files. |
| |
Dependency resolution | Manage relationships among managed objects (for example, configuring beans by calling setters, or automatically calling constructors with managed beans). |
| |
Transaction management | Externalize transaction management from code into configuration files (i.e. declarative transactions). |
| |
Object pooling | The obvious example are database connections. |
| |
Expose remote services | Not just SOAP based web services; there are other, simpler wire protocols. |
| |
Consume remote services | Provide transparent access to remote objects running outside the container. |
| |
Non-invasive | Run existing legacy code as-is in the container. Code should run the same both inside and outside the container |
Requirement | GINO | RM | Installer | TC | System Tests | Data Access |
---|---|---|---|---|---|---|
Web configuration/editing |
|
|
| |
| |
Web reports | ||||||
Single Sign-On | ||||||
Persistence (CRUD) |
|
|
|
| ||
Reports (DB Queries) | ||||||
Batch Submission |
|
|
| |||
Scheduler |
|
| ||||
Event Notification |
|
| ||||
Automated email |
|
|
|
...