...
The primary goal of the GRITS Framework is to provide the software architecture and infrastructure for the GLAST Core Team to accomplish its mission. Specific goals include:
- 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
...
There are three sets of expected users of the GLAST Framework and GLAST Projects and their timelines.
User | Description | Time Scale |
|---|---|---|
Core team | Develop and maintain GLAST data processing projects | now |
GLAST collaborators | Use the GLAST data processing projects to accomplish the GLAST mission | some now, all by July 2005 |
Astronomy community at large | Consumers of GLAST data products | post-launch (2007) |
...
| Anchor | ||||
|---|---|---|---|---|
|
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:
- Provide high availability
- Provide for scaleability
- Provide for maintainability
- Are lightweight in nature
- Enjoy wide adoption in the Enterprise Software community
- Easily testable
- Conform to SLAC and DOE security policy
- Leverage existing SLAC infrastructure
The schedule for delivery of the GLAST Projects varies for each project. For example, the pipeline is required now. Also, some of the projects have perl implementations that may or may not be migrated to the GRITS Framework. Version 1 of all projects must be completed by July 2005. The GLAST experiment has a current launch date of July 2007.
| Anchor | ||||
|---|---|---|---|---|
|
In order to accomplish the stated goals, 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.
Definition: A container is a framework in which application code runs.
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.
share a common set of services, which are listed in the following table.
...