Reply-to: gcf@npac.syr.edu To: beca@boss cc: marek@boss, haupt@boss Subject: Not Finished Date: Sat, 08 May 1999 14:25:15 -0400 From: Geoffrey Fox Tom has edits not integrated into this yet Geoffrey Fox gcf@npac.syr.edu, http://www.npac.syr.edu Director of NPAC and Professor of Physics and Computer Science Phone 3154432163 (Npac central 3154431723) Fax 3154434741 ------- Forwarded Message Date: Tue, 04 May 1999 20:30:36 -0400 From: Ken Flurchick To: Geoffrey Fox cc: "Asbury, William L" , Tom Haupt , "Hoffman, Dana E" , bernhold@npac.syr.edu Subject: Gateway Overview for developers. 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 servi ces for processing the user requests.
  3. The Code Toolbox
    This toolbox API provides a mechanism to develop co de 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 si mple analysis tools plus provide access to more detailed ana lysis 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 st atus 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 middl e tier using CORBA rather than the custom Java servers us ed in our initial WebFlow system demonstrated at SC98. One can either use commercial object brokers or NPAC's JWORB se rver supporting Web/XML, COM, CORBA and Java object models. This basic architecture exhibits the two interface layers di scussed above and we are part of the DATORR process to define c ommunity consensus for both client-middle tier and middle tier-c lient interfaces. The core architecture is designed to suppor t necessary security and authentication services.
  3. Execution model including back-end systems. In this model the execution is invoked by a batch scheduler eit her directly from middle-tier as a service or through Globu s.
  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 H PCC simulations and those from the FMS and IMT CTA's. We be lieve that DMSO's HLA/RTI framework is an interesting approac h to metacomputing where one can exploit NPAC's object Web b ased RTI (basically an event based messaging system) built a round JWORB servers. In the Gateway architecture it is natura l 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 collaborati ve 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-ti er 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 interest ing technologies. The software repository RIB offers this c apability for software modules.
  8. Programming models where initial Gateway offers the WebFlow capabilities with client and middle tier support for da taflow and a more object composition coarse grain programming envi ronment.
  9. Computational steering where NPAC originally developed a Java server based rapid prototyping system DARP. This i nvolves interactive links between client and execution of the P rogram. In that way, it has some analogies to the portal servic e called "Edit, Compile, Run and Debug job" i.e. program develop ment as opposed to execution of developed codes. Here NPAC desi gned and deployed some time ago a "Virtual Programming Laborator y" used for web-based programming for classes. This was for ins tance 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 compo nents of a CTA gateway (or portal). This includes information di scovery, XML standards for scientific discourse, glossaries etc.
  11. Special features of a given application portal. For instance in NPACs nanomaterials work for the NCSA Allia nce we supported file manipulation and a particular visualizat ion engine Cerius.
- --------------7D02A0492BBF5A740283458E-- ------- End of Forwarded Message