...
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 goals, we list the following requirements for the GRITS Framework as a whole and the technologies used in its implementation:
- Provide high availability
- Provide for scaleability
- Provide for maintainability
- Are lightweight in nature
- Enjoy wide adoption in the Enterprise Software community
- Easily testable
- Run on both Windows and Linux
- Conform to SLAC and DOE security policy
- Leverage existing SLAC infrastructure
...
In order to accomplish the stated goalsproject's goals and meet the project's requirements, we initially researched several complete , full-blown J2EE Application Servers since they provided integrated persistence and remoting capabilities. However, the effort involved the Instead, we follow the emerging post-EJB consensus and adopted a lightweight container that provides the best parts of J2EE Enterprise Services.
In order to accomplish the stated goals, we rejected most of the EJB parts of J2EE and with it the heavy, complex and expensive J2EE Application Servers. Instead, we follow the emerging post-EJB consensus and adopted a lightweight container that provides the best parts of J2EE Enterprise Services.
...
(specifically J2EE and .NET), as well as a Perl + CGI solution. For the purpose of this discussion, all of these solutions are considered a container according to the following definition:
Definition: A container is a framework in which application code runs.
The .NET Framework (but not the entire concept of a .NET Application Server) was rejected becuase it was not cross platform, but we did adopt Windows Server 2003 and IIS 6 (both parts of a .NET Application Server) for the Windows deployment endpoints as meeting all of our requiremetns.
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.
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.
...