J2EE For Glast

Introduction

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.

Currently, the GRITS Framework is completely in place, and development of the various GRITS Projects within the framework has only recently begun. The first concrete components for the Processing Pipeline (which is one of the GRITS Projects) were recently installed into production.

The outline of this presentation is as follows:

1. The GRITS Framework is introduced, which includes a description of the project's goals, the players involved, current project status and the project's timeline.
2. The GRITS Projects are briefly introduced, with an emphasis on their requirements and use-cases. It is these requirements and use-cases that drove the design and implementaiton of the GRITS Framework.
3. The technologies used by the GRITS Framework are described in some detail.
4. Development tools and methodologies used by the GRITS Framework are described in some detail, as they are the recommended approach for development of GRITS Projects.

GRITS Framework

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.

GRITS Projects

The GLAST Projects are intended to serve the data processing needs of the GLAST collaboration. The current and proposed set of projects, and the platforms they are required to run on, are shown in the following table:

Common Services

The GRITS Projects share a common set of services, which are listed in the following table.

The bulk of these services are provided out-of-the-box by the GRITS Framework technologies. Those that aren't are provided by the grits commons project.

Note: A shared set of common services was one of the primary reasons for adopting an SOA.

Legacy Systems and Services

Another important reason for adopting an SOA is to leverage and integrate existing back-end systems services. This set of legacy systems and services and the platforms they run on are shown in the following table.

GRITS Framework Goals

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:

1. Provide a common framework to develop the GRITS Projects and their associated set of common services
2. Provide a distributed, cross-platform SOA for GLAST Projects that is simple to develop with and simple to use
3. Promote team oriented development (as opposed to individual contributors)
4. Maximize disparate talents of a small group
   • • Programmers
     • Web Developers
   • Occasionally-connected programmer/manager/astronomer
5. Utilize talents of JAS group

GRITS Framework project Requirements

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:

1. Provide high availability
2. Provide for scaleability
3. Provide for maintainability
4. Are lightweight in nature
5. Enjoy wide adoption in the Enterprise Software community
6. Easily testable
7. Run on both Windows and Linux
8. Conform to SLAC and DOE security policy
9. 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.

Technology Choices

In order to accomplish the project's goals and meet the project's requirements, we initially researched several complete full-blown Application Servers (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.

For the GLAST Framework, a lightweight container had to provide the following services:

GRITS Framework Technologies

The GRITS Framework uses a 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:

1. 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:
2. 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.
3. Web servers (IIS on Windows and Apache on Linux) for security-conscious service deployment.
4. ColdFusion MX for web front-end development.
5. Several Jakarta components, primarily Tomcat for service deployment and many of the jakarta commons for

The Databse Schema

Configuring a DataSource

An Example Hibernate Mapping File

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">

<hibernate-mapping package="grits.gino.domain">

	<class name="TaskImpl" table="TASK">

		<id name="id" type="long" unsaved-value="null">
			<column name="TASK_PK" />
			<generator class="native">
				<param name="sequence">TASK_SEQ</param>
			</generator>
		</id>

		<property name="name" type="string">
			<column name="TASKNAME" length="30" unique="true"
				not-null="true" />
		</property>

		<property name="datasetBasePath" type="string">
			<column name="BASEFILEPATH" length="200" not-null="false" />
		</property>

		<property name="runLogPath" type="string">
			<column name="RUNLOGFILEPATH" length="200" not-null="true" />
		</property>

		<many-to-one name="type">
			<column name="TASKTYPE_FK" not-null="true" />
		</many-to-one>

		<set name="taskProcessSortedSet" inverse="true"
			cascade="all-delete-orphan" sort="natural" order-by="SEQUENCE asc">

			<key column="TASK_FK" />
			<one-to-many class="TaskProcessImpl" />
		</set>

		<set name="datasetSetInternal" inverse="true"
			cascade="all-delete-orphan">

			<key column="TASK_FK" />
			<one-to-many class="DatasetImpl" />
		</set>

	</class>

</hibernate-mapping>