...
This is a presentation of the proposed adoption of an Enterprise-wide Service Oriented Architecture (SOA) for the GLAST experiment's data processing requirements. This project is composd of two parts, the GRITS Framework and the GRITS Projects that are built upon the framework. This presentation is primarily concerned with the GRITS Framework, which is a lightweight Java based distributed architecture which uses some, but not all, of the technologies from the J2EE specification.
...
The GRITS Framework is the infrastructure upon which GRITS Projects are intended to be devloped. The GRITS Framework was born out of a detailed deconstruction of the current, and proposed, GRITS Projects by members of the GLAST Core Team in early 2004. This deconstruction and subsequent analysis identified many common services shared by all GRITS Projects, and an SOA approach to deliver these sercies was unanamously agreed upon.
...
- Provide a common framework to develop the GRITS Projects and their associated set of common services
- Provide a distributed, cross-platform SOA for GLAST Projects that is simple to develop with and simple to use
- Promote team oriented development (as opposed to individual contributors)
- Maximize disparate talents of a small group
- Programmers
- Web Developers
- Occasionally-connected programmer/manager/astronomer
- Utilize talents of JAS group
...
Many of the GRITS Projects must run 24x7, and all of them will have a service life of 10+ years. Additionally, the software will operate within the SLAC computing infrastructure. Therefore, to meet these constraints and achieve the stated goals, we list the following requirements for the GRITS Framework as a whole and the technologies used in its implementation:
...
A Perl + CGI solution was rejected since it violoated many of our requirements (specifically the scaleability, maintainability, security and easily testable requirements), and was considered too complex to utilize all of our group's talents. However, Perl is (and will continue to be) an important system maintainence tool for GLAST.
While a complete J2EE Application Server fullfilled the technological requirements (particularly the integrated out-of-the-box persistence and remoting EJB capabilities), in practice the effort involved to develop using EJB proved to be too complex and violated our easily testable requirement.
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.
...
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. |
|
|
Quick start-up |
|
|
|
No special deployment requirements | Developers should be able to write pure Java code without knowing anything about the container |
|
|
Run in variety of environments | Have a small footprint and minimal API to allow use in everything from standalone desktop applications, to web-only containers (like Tomcat), to full-blown J2EE Application Servers. |
|
|
Provide crosscutting customization and extensibility | For example, inject security checks, logging, or profiling into objects without them being aware. |
|
|
...
- The Spring Framework, which is the cornerstone of the GRITS Framework, provides those parts of the J2EE specification that we rejected as either too complicated, too expensive, or otherwise not addressing the project's requirements. Specifically, Spring provides:
- Hibernate, a thin wrapper over JDBC which provides the full power of transparent persistence by providing O/R mapping but not trying to hide the underlying relational database.
- Web servers (IIS on Windows and Apache on Linux) for security-conscious service deployment.
- ColdFusion MX for web front-end development.
- Several Jakarta components, primarily Tomcat for service deployment and many of the jakarta commons for
...