Overview

This document summarizes the internal architectural changes between versions 0.4 and 0.5 of OSCARS.

0.4 Architecture

The diagram below shows the OSCARS architecture as it exists in the 0.4 version of the software:

The diagram shows that in 0.4 all of the software components run within the Tomcat application server. This includes the main OSCARS component (the lower left box) that handles tasks such a resource scheduling, running a pathfinder, and contacting components that provision circuits. It also includes the NotificationBroker (the lower right box) that manages user subscriptions to Notifications and the delivery of those Notifications. Each component listens for Java Remote Method Invocation (RMI) calls and also accepts web service requests. There is also the Web Browser User Interface (WBUI) component that uses RMI to access the OSCARS core.
This architecture is an improvement over 0.3 but still presents some issues:

  1. The OSCARS and NotificationBroker services are not easy to separate because they rely on common databases and configuration files.
  2. The web service interface and the cores are tightly integrated making it difficult to support multiple protocols simultaneously. This limits backward compatibility as the protocol changes.
  3. Similar to #2, tightly integrating the core and the user access layer limits an administrators' ability to split these between different physical machines. This may be desirable for security purposes.
  4. Running everything inside Tomcat makes the applications dependent on Tomcat's classloading. This has caused unpredictability when working with some third-party libraries in the past.

0.5 Architecture

The diagram below shows the architecture of OSCARS 0.5:

This architecture splits the core functions out of Tomcat and makes OSCARS and the NotificationBroker their own self-contained processes. The web services and web browser interfaces are fully separated and access the core processes via Java Remote Method Invocation (RMI). The creation of a new AAA process allows OSCARS and the NotificationBroker to be completely separated without relying on the same databases. The AAA service only allows access via RMI as a web service interface is the focus of much broader research.
Some desirable features of the above architecture are as follows:

  1. It separates the web interfaces from the core processes making it possible to run multiple versions of an interface simultaneously
  2. Similar to #1 it makes it possible to run Tomcat and the cores on separate physical machines. As previously noted, this might be desirable for security purposes.
  3. The NotificationBroker becomes a standalone component that can more easily be run by those interested in running it outside of the context of OSCARS (i.e. perfSONAR).
  4. An external AAA component allows for a more natural progression for OSCARS and the NotificationBroker to begin using a full implementation of an AAA service in the future.
  5. Increased flexibility and control over classloading as the cores are external to Tomcat
  • No labels