Forwarded: Sat, 08 May 1999 14:25:16 -0400 Forwarded: beca@boss Forwarded: marek@boss Forwarded: haupt@boss Received: from osc.edu (atlantis.osc.edu [192.148.249.4]) by postoffice.npac.syr.edu (8.9.3/8.9.3) with ESMTP id UAA10173; Tue, 4 May 1999 20:34:11 -0400 (EDT) Received: from osc.edu (oscid107.osc.edu [206.21.215.107]) by osc.edu (8.8.6/8.8.6/OSC 1.1) with ESMTP id UAA01647; Tue, 4 May 1999 20:34:05 -0400 (EDT) Message-ID: <372F912C.882E3993@osc.edu> Date: Tue, 04 May 1999 20:30:36 -0400 From: Ken Flurchick X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Geoffrey Fox CC: "Asbury, William L" , Tom Haupt , "Hoffman, Dana E" , bernhold@npac.syr.edu Subject: Gateway Overview for developers. References: <372CE56A.DDA1378F@npac.syr.edu> Content-Type: multipart/mixed; boundary="------------7D02A0492BBF5A740283458E" Content-Length: 9743 This is a multi-part message in MIME format. --------------7D02A0492BBF5A740283458E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gentlebeings As per my discussion with geoffrey yesterday, I have modifed and extended his discussion about the Gateway. Is is enclosed below as a draft to provide a framework for devlopers to understand the Gateway components. kenf --------------7D02A0492BBF5A740283458E Content-Type: text/html; charset=us-ascii; name="gatewaysummary.html" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gatewaysummary.html" Gateway Architecture

Gateway Architecture

The Gateway comprises a multi-tier (currently three) architecture. The tiers are the clients, servers or brokers(the middle-tier) and backend resources. The backend resources consists of a collection of specialized resources to service requests not handled by the client or middle-tier. Typically these requests are too large for the client, and may require access to specialized software (e.g. a database or application code), or require access to specialized hardware (either a computer or instrument) or data, or other similar special requests. The client may handle some user requests internally but will usually direct the request to the middle-tier.

In the simplest model, all data flows from client to middle-tier to the backend and back again. In the high performance implementations, control commands are routed this way while large data transfers can be routed by specialized high bandwidth low latency channels.

Gateway Interfaces

There are two importance interfaces:

  1. Client <-> Middle-Tier
  2. Middle-Tier <-> Backend

These interfaces can be expressed in various forms but a clear and simple method is to define them in XML. The XML specification can, for example be converted to Java or CORBA IDL at the Middle-Tier <-> Backend interface. Large data block transfers would use more efficient native wire format.

Use of an XML specification is consistent with using Jini (a Java service) although in this case, XML is converted client side before being transmitted using Java's RMI protocol to the middle tier.

Gateway Middle-Tier

The Gateway middle-tier contains all the 'business logic' or control code necessary to handle requests from a client or direct a request to an appropriate backend resource. The middle-tier can also act as a broker choosing from several possible backend systems to service the user request.

Gateway Client Tier

The Gateway client tier The client architecture consists of a set of toolbox kits. These toolboxes have components, 'buttons', 'menus', documentation and application information. Most of these components will be expressed in XML. There can be a set of toolboxes, e.g., one for computational chemistry or astrophysics, another toolbox for visualization, a third for job and computer monitoring etc. These can be rendered as HTML by the browser via the client <-> middle-tier interface. These toolboxes can be interpreted as pure client side actions or involve the other tiers. This distinction is hidden from the user and is exhibited through the handler invoked by the XML parser.

The client tier components provide for the development of a Problem Solving Environment (PSE). More information about the PSE design specification is here. There are three primary classes of toolbox components for the client tier:

  1. The Entry Toolbox
    This toolbox will consist primarily of middle-tier interface components to access a set of user Gateway information such as completed jobs and analysis.
  2. The Problem Description Toolbox
    This toolbox API provides for the development of application domain information concerning methods and other information (such as solution databases). This toolbox also provides an interface to middle-tier services for processing the user requests.
  3. The Code Toolbox
    This toolbox API provides a mechanism to develop code input pages and job submission. This toolbox provides several mechanisms to access the middle-tier interface.
  4. The Results Toolbox
    This toolbox API provides a mechanism to develop simple analysis tools plus provide access to more detailed analysis tools via the middle-tier.

In the Gateway, a given problem domain customizes both the client and backend environment. At the backend, one would define, using the Gateway Interface, particular application domain specific modules as distributed objects. Each application domain can develop a specialized toolbox, or arrange and customize existing toolboxes or both, to form a specific PSE.

Some Gateway Features and Capabilities

Some Gateway capabilities are very application specific, e.g. the XML button invoking the Gaussian chemistry modeling program; others such as visualization or collaboration are applicable across multiple CTA's. The Gateway core team must come up with a methodology to allow these toolboxes to be produced in a modular fashion by different groups. This requires a good architecture and well designed and supported interfaces.

Some NPAC experiences:

  1. The initial capability of Gateway is of course seamless access from the client to backend resources. There are also some core capabilities within basic system including status displays for backend systems supported by the usual XML standards.
  2. Basic multi-tier architecture. Here Gateway has a three-tier model with client, server/broker and back-end layers. In the last year, NPAC re-implemented the middle tier using CORBA rather than the custom Java servers used in our initial WebFlow system demonstrated at SC98. One can either use commercial object brokers or NPAC's JWORB server supporting Web/XML, COM, CORBA and Java object models. This basic architecture exhibits the two interface layers discussed above and we are part of the DATORR process to define community consensus for both client-middle tier and middle tier-client interfaces. The core architecture is designed to support necessary security and authentication services.
  3. Execution model including back-end systems. In this model the execution is invoked by a batch scheduler either directly from middle-tier as a service or through Globus.
  4. Metacomputing Services. This has been a focus of the Globus and Legion groups and Gateway can be extended to support this. For DoD, one would like to support both classic HPCC simulations and those from the FMS and IMT CTA's. We believe that DMSO's HLA/RTI framework is an interesting approach to metacomputing where one can exploit NPAC's object Web based RTI (basically an event based messaging system) built around JWORB servers. In the Gateway architecture it is natural that metacomputing support (fault-tolerance, load balancing etc.) is built into the middle tier.
  5. Collaboration services include both general collaborative tools as seen in Tango Interactive but also collaborative visualization, debugging, program preparation etc.. We have developed under Tango already, prototype collaborative visualization (for both NPAC's Java visualizer and NCSA who linked CAVE and workstation visualizations)
  6. Visualization. Here we expect to work with NCSA and the ARL DICE team in analyzing WebFlow and general multi-tier portals to understand how to set up visualization services.
  7. General registration and discovery services for software, data and computing resources. XML and Jini are interesting technologies. The software repository RIB offers this capability for software modules.
  8. Programming models where initial Gateway offers the WebFlow capabilities with client and middle tier support for dataflow and a more object composition coarse grain programming environment.
  9. Computational steering where NPAC originally developed a Java server based rapid prototyping system DARP. This involves interactive links between client and execution of the Program. In that way, it has some analogies to the portal service called "Edit, Compile, Run and Debug job" i.e. program development as opposed to execution of developed codes. Here NPAC designed and deployed some time ago a "Virtual Programming Laboratory" used for web-based programming for classes. This was for instance used in NPAC's last online computational science class at Jackson State.
  10. Information services which are in fact critical in both management Intranets, training and in information components of a CTA gateway (or portal). This includes information discovery, XML standards for scientific discourse, glossaries etc.
  11. Special features of a given application portal. For instance in NPACs nanomaterials work for the NCSA Alliance we supported file manipulation and a particular visualization engine Cerius.
--------------7D02A0492BBF5A740283458E--