...
The GRITS Projects share a common set of services, which are listed in the following table.
RequirementCommon Service | 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 |
|
|
|
|
|
|
...
Legacy System | Linux | Windows |
|---|---|---|
Oracle |
|
|
LSF |
|
|
NFS |
|
|
Windows File System |
|
|
mstore |
|
|
cvs |
|
|
gcc |
|
|
cl.exe |
|
|
cmt |
|
|
gleam.exe |
|
|
ROOT |
|
|
| Anchor | ||||
|---|---|---|---|---|
|
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
- The framework and technologies must have proven to be lightweight, scaleable, maintainable, and enjoy wide adoption in the SOA communityEnterprise Software community. The GRITS Projects will be in use for 10+ years, and the framework must support this.
- Conform to SLAC and DOE security policy
- Leverage existing SLAC infrastructure
- 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
...
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 | ||||
|---|---|---|---|---|
|
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:
share a common set of services, which are listed in the following table.
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 |
|
|
|
|
|
|
| Anchor | ||||
|---|---|---|---|---|
|
The GRITS Framework primarily uses open-source software, but also contains commercial components where they make sensea mixture of open source software and commercial products. We don't view open source software as a no-cost solution, but instead view it as a technical choice.
The primary components are:
- 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
The Databse Schema
Configuring a DataSource
...