SoftArchDoc:Node-ClusterGridCommunication ServicesInvocation

Introduction

The CVRG at JHU provides an infrastructure for cardiovascular researchers to collect, analyze, and share cardiovascular research data. In order to provide a solid and scalable infrastructure, employment of accepted information technologies and sound architecture is essential. JHU ICM will adhere to these sound architecture principles.

Purpose

The purpose of this document is to provide a roadmap and suggest best practices on software development for the CVRG at JHU. This paper will specifically address proper software engineering techniques that should be employed for Node-to-Cluster communication and Grid services invocation.

Scope

The scope of this document is limited to the front-end tier of the Grid and its communication layer to Grid services. Due to the collaborative nature of the software development between JHU and other Grid partners, these services can be either internal or external. However this paper will only address invocation of Grid services, internal to JHU and the abstraction of invocation to external Grid services.

Acronyms/Abbreviations & Definitions

References

Overview

The remainder of this document describes the decisions of the architectural analysis Node-to-Cluster communication and Grid services invocation.

Architectural Representation

This document presents the architecture as a series of views; use case view, process view, deployment view, and implementation view. These views are presented as UML Models.

Architectural Goals and Constraints

There are some key requirements and Grid constraints that have a significant bearing on the architecture. These are:

• CVRG software will be developed in J2EE platform utilizing a standard ICM development tool set (see the “Development tool set” section).
• Existing code bases will be re-used as much as possible where is possible unless it doesn’t align with future architecture goals.
• CVRG services will rely on the Globus Toolkit to provide authentication.
• CVRG front-end tier will rely on consumption of several existing web services. This includes external Grid services developed by OSU for its caGrid project.

Use-Case View

The generic tasks involved with a cardiovascular researcher are as follows:

1. The researcher launches a unique CVRG widget and connects node to broker, which registers the node to a cluster
2. The researcher selects from a list of services provided via the CVRG widget, usually data services or analytical services
3. CVRG widget (connected to the cluster) contacts the attached broker which dispatches one or more attached nodes to launch requested service and researcher is advised of results
4. Upon notification of completion of service the researcher may choose another service to package a preferred presentation format
5. CVRG widget (connected to the cluster) contacts the attached broker which dispatches one or more attached nodes to launch requested service and researcher is advised
6. The researcher uses the CVRG widget to view or download the results presentation

Figure 4-1 Cardiovascular Researcher Use Case

Logical View

Overview

Architecturally the Grid model consists of a number of logical layers, as shown by the following diagram:

Figure 5-1 Logical Model

Node Layer

Until recently, the CVRG user interface was presented to the cardiovascular researcher in the form of a web portal. This meant that the researcher had to download and install all of the portal software. Once the installation was completed then a security certificate was issued to the user, which also had to be installed.

This was a time-consuming and somewhat clumsy approach since there were many steps and missing any of those steps jeopardized a successful installation. Most cardiovascular researchers don’t want to spend much of their personal or professional time remediating installation issues.

To simplify and accelerate the installation process, ICM has decided to use the Google Web Toolkit (GWT). It is a tool that creates a widget that can be re-used on computer desktops, web browsers, PDAs, and web-enabled cell phones.

Figure 5-2 CVRG ECG Widget

Cluster Layer

This layer is essentially an object representation of the underlying Domain / Class model. This layer holds all of the Entity classes identified within the Grid. Persistence layer will be implemented utilizing Database controls. Domain will be distributed and accessed via 2 mechanisms:

• JDBC or ORM control
• Remote web services (WSDL, SOAP) http://cvrgrid.org/SomeService?WSDL)

Required protocol will be evaluated and chosen against the following non-functional requirements:

• Coupling (or loose coupling)
• Performance
• Data volume required to be transferred

Services Layer

The Apache Software Foundation provides an Open Source SOAP engine called Axis2 that provides ready-made customizable J2EE software component templates that can be arranged to provide Information Technology solutions. Using a service descriptor and extending the RawXMLInOutMessagingReceiver construct, provided by Axis2, one could easily refactor the application development approach to an alternative construct (such as Enterprise Java Beans). This includes:

• Reusable GUI components
• Service locators
• Database controllers
• Logging
• Common functions

Process View

Figure 6-1 CVRG Process Flow

Deployment View

Figure 7-1 CVRG Deployment Diagram

Implementation View

Overview

The implementation of the Grid is very similar to the design view presented earlier in this document, with the layers identified, and the high level packages specified. This section of the document shows the component assembly of the CVRG application into a J2EE enterprise application. Grid development has been planned in 2 phases with 2 iterations in each phase. During Phase 1 Iteration 1 all domain logic will be delivered. After the completion of phase 1iteration 2, CVRG will provide all domain logic via a J2EE-compliant Enterprise Archive file, which will contain GUI components.

Quality

The architecture has been specified to allow for optimal flexibility, while ensuring that it isn’t over engineered. Best practice J2EE patterns have been employed, and certain well-tested J2EE 1.5 features encompassed to ensure that the Grid could meet the following service level requirements:

Performance

Throughout, the Grid will be designed and developed using Performance measuring tools to ensure that the optimum level of performance is maintained. Also the definition of an optimized database design and the use of various caching patterns, such as Service Locators, will ensure that performance is as optimal as possible.

Scalability

Due to the nature of the platforms and techniques employed, and ensuring that best practice J2EE techniques are followed the Grid should facilitate vertical and horizontal scaling.

Reliability

This ties into the same factors mentioned in scalability.

Availability

The CVRG must be available worldwide constantly.

Maintainability

Many of the factors mentioned in the extensibility section also apply to the maintainability of the Grid. In addition through the automated testing mechanisms employed and the automated documentation generation, a common base line can be met to test any changes made to the Grid.

Security

The initial delivery of the CVRG application will rely on customized components from the Globus Toolkit and a core LDAP service to provide authentication. Only people who are registered to use CVRG are able to access the Grid.

Toolset

Run-time Environment

1. Client (Web-based)

• Apache Tomcat 6 (deployed by GWT)

1. Middle-tier (server)

• Apache Tomcat 6
• Apache Axis2 1.4.1