PRISM System Specification Handbook

Architecture Choices, Detailed Design and Implementation (ARCDI)

---

II.1 : System architecture choice / relative role of modules

Version 1.2

---

 

Authors C. Larsson, N. Wedi, H. Thiemann

Table of contents

• Summary

1. Introduction
2. Terminology and concepts
3. The local system, a basis for development
4. Architecture of the generalised web services concept.
5. From analysis to design: The process to component translation of the PRISM system
6. Proposed architecture
7. Specifications, definitions and standardised interfaces needed for the implementation of the system
8. From design to implementation : The component to deployment translation
9. Implementation plan, deliverables and desirables
10. Integration with other projects
11. Risks
12. Definitions,Acronyms and Abbreviations
13. REFERENCES

---

Summary

The purpose of the PRISM system is to enable users to perform numerical experiments, coupling interchangeable model components using standardised interfaces.

The general architecture provides the infrastructure for this. There is an emphasis on choosing an architectural design that allows these activities to be done remotely, eg. without the user physically being in the place where the numerical computations take place.

Within the PRISM system three different types of actors exist: Users: someone who uses the PRISM System to assemble and run a coupled model. Model developer: someone who makes changes to a PRISM model code that will be introduced to the default model version. Administrator: the person who provides the link between developers and users. These different actors represent different demands on the system.

The best design in order to fulfill the PRISM requirements (remote access, modularity, extendability) is a centralised architecture that minimises the administration and duplication of resources at the expense of some added complexity, see figure below.

It is proposed to gradually refine the system in two phases and into two different products configured from the same software base:

 Local system: used by developers to develop models without affecting operations.
 Web based system: used by administraters and users to administrate model changes and run coupled experiments remotely.

1.0 Introduction

This document is primarily about delivering the infrastructure necessary to enable a distributed configuration,submission and monitoring system for PRISM experiments. A local system will be delivered to enable model developers to run the configuration tool without the web service infrastructure to test out their models. The local system is based on the same software to ensure a transparent transition between the local and the Web Services infrastructure system. The requirements and constraints from the REDOC document will be translated into a specific design in the document. The architecture will be detailed into software components and the choice of these components discussed. A run-time and deployment architecture will be discussed and finally an implementation model detailing the order and importance of implementation tasks is presented.

2.0 Terminology and concepts

Software component: software that is a part of a larger system, or an object that is part of a larger object, delivering a specific functionality.

Deployment: describes the physical distribution of the system being built, in terms of how functionality, that is software components, are distributed among a set of run-time processing nodes (computers). The terms is also used in a more limited scope in other documents referring to the deployment of an experiment to computing resources (REDOC II.2).

Configuration:The arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts.Also used in relation to experiments where it defines the collection of programs, documents and data that an experiment consists of. Figure 1 shows different aspects of the configuration process between the PRISM user and the PRISM site.

3.0 The local system, a basis for development

A large amount of effort in the PRISM project will go into modularisation of models and standardisation of scientific input and output. Likewise, the task of deployment of models on the web infrastructure and also the task of making it a painless exercise for a user or developer to download a model locally and make it work needs to be given the same attention and priority.

To succeed in the deployment of models we have to standardise procedures,i.e. the standardisation of model builds, model runs and model configuration is critical in view of long term maintainence and usability of the system.

A file structure must be specified that enables a locally configured model to be put into an archive file and transported to a deployment site and deployed there automatically.

Such a structure needs to be proposed by the model developers but could look like this:

	/prism

	      /models/modelX/src
	                    /lib
	                    /doc
	                    /config
	                    /runscripts
	                    /bin
	                    /tmp
	             
      

A version of the GUI (Graphical User Interface) that runs without the web infrastructure will be developed initially. This version can be started from the command line on the users linux workstation and will not need any network support. Support for other platform is optional. All input and output will be read/written to the current directory according to the standard structure described above. The user will have to download the latest versions from a central source code repository.

The purpose of the local version is :

• To allow individual developers to adapt, test and run their models locally .
• To enable testing of build and deployment scripts locally.
• To prepare a version for deployment in the web infrastructure.

Once the developer can verify that the model works properly it can be made available for users through the Web Services infrastructure wich is described in the following section

4.0 Architecture of the generalised web services concept.

A Web Services (WS) system makes the services it provides abstract, shielding the client from the particulars of an implementation of a service. A client, be it another service or a user interface, requests a specific service. The service is located with the help of a web services registry using UDDI, the Universal Description, Discovery and Integration protocol, which contains information on where the service is located and how to use it as shown in Figure 2.

A Web services provider uses the UDDI protocol to publish the service it provides encoded in WDSL, the Web Services Description Language to a UDDI directory. The client requests a service from the directory. The directory information returned tells the client how to find and use the service. It is the intention to use this system to allow users to find local PRISM sites.

4.1 Subsystem topology

A wide area network (WAN) is a geographically dispersed telecommunications network. The term distinguishes a broader telecommunication structure from a local area network (LAN). A wide area network may be privately owned or rented, but the term usually indicates the inclusion of public (shared user) networks.

A local area network (LAN) is a group of computers and associated devices that share a common communications line and typically share the resources of a single processor or server within a small geographic area (for example, within an office building). A local area network may serve as few as two or three users (for example, in a home network) or many as thousands of users.

The client is typically running in his LAN requesting a service from applications running in another LAN using a WAN such as the Internet and the related protocols to forward the request.

The WS universe consist of a number of zones or locations derived from their networking status as LAN or WAN .

The importance of the zones lies in that as messages travel from a LAN to a WAN the authentication and validity of the message is lost because the public network potentially allows tampering with the message. Measures need to be taken to detect and prevent such tampering.

4.2 Subsystem layers in WS

Below are the software components in the architecture of the subsystems infrastructure for a generalised WS system. The application layer describes the software component(s) in the subsystem and its function. The middle-ware layer details the actual implementation of the subsystem as shown in Figure 4.

The implementation choice is decided on deployment of the system, if the particular implementation does not restrict the functionality of the subsystem. A discussion of the choices listed can be found in the deployment section.

Table of software components in the system
Application layer	Applicatiton function	Middle-ware layer	Communications protocol
User Interface	Interface task	Java.Applet	HTTP
Web server	Serve pages,Listens for requests	Apache	HTTP
Application server	Interface application,	Tomcat	AJP12
Domain Applications	Deliver domain function such as configurations	Any	Any
Authentication server	Authenticate clients	SKey, Kerberos	HTTP/HTTPS
ORB (Object Request Broker)	interface to application server	Java	HTTP
Event service	Deliver events to applications	Java	HTTP
Directory server	Publish and access information on services	UDDI server Java	WSDL
PRISM administrator	Executes administration tasks	Definitions of administration entities	SSH
Table 3

5.0 From analysis to design: The process to component translation of the PRISM system

The processes described in the REDOC document will be translated into software that enables the desired activities.

Process to component view

The processes listed in the REDOC II.1 document, Tables 1,2,3,referred to as RDT1, RDT2 and RDT3 describe what activities take place and which process is handling it. For each process the software components that handle the related activity is described.

The physical location of the software component also determines the choice of component, but the mapping of components to the architecture will be more closely examined in the deployment section .

The design of the PRISM system processes falls into three categories mirrored by the REDOC Tables RDT1/2/3 as shown in Figure 5.

• Controller processes : User (client) activities from Table RDT1
• Controlling processes :Provider (server) from from Table RDT2
• Controlled processes : Execution of model from from Table RDT3

The Table RDT1 processes naturally falls into the application layer of the GUI in this document as shown in Figure 5 to the left.

The Table RDT2 processes are domain service applications that are delivered by application servers directly to the client GUI, Figure 5 middle boxes.

The Table RDT3 processes are the domain applications controlled by the Table RDT2 processes and not served by any application server and as such not part of the WS infrastructure, to the right in Figure 5.

5.1 Subsystem communication

The subsystems communicates by sending messages to each other. The messages are usually of the form request - reply, but can also be in the form of publishing information, eg. event notifications. In this case no reply is expected. The term reply should be understood as receiving a useful object back, not a protocol confirmation of the transmission status.

Figure 13 details the messages and protocols in a WS system. The MX numbers in Figure 13 relate to the description of the messages in Table 6.

Table of system messages
Message	Protocol	Function
M1	HTTP/S	Load gui from central webserver
M2	HTTP/S	Authenticate from gui to webserver
M3	AJP12/13	All traffic to tomcat
M4	RMI	Reading/writing experiment configurations, submit
M5	FORK	Send job to SMS scheduler
M6	QSUB	Queue job to supercomputer
M7	FCGI	Monitoring requests to SMS on job status
M8	RPC	Cgi server requesting information from SMS
M9	AJP/RMI	M3/M7 traffic if PRISM site has no WEBSERVER
M10	RMI,SOAP,RPC	M4 traffic if PRISM site has no WEBSERVER OR TOMCAT
M11	FTP	Ftp of new model code to build.Requested by Prism site
Table 6

Detailed interaction analysis for the following cases, i.e. typical scenarios is made in form of a diagram and a table detailing the resources needed for every message:

• CASE 1: User downloads gui and directory information. Messages M1,2,3,4
• CASE 2: User submits build job. Messages M1,2,3,4,5,6
• CASE 3: Monitoring of job. Messages M1,M2,M3,M7,M8

Comments: This highlights the administration and maintainence advantages of having all users running the same software versions of a program and that all configuration information for compositions is coming from the same domain server and is saved there together with the users changes. This is the function of the central site.



Comments: This highlights the configurability of the system where the M3 step could lead to a submission of the experiment on different sites depending on the the availability of computing hosts in the service directory (UDDI).



Comments: This shows the monitoring and control of an experiment through the use of a mediator program running at the execution host. The role of the program is to make sms functionality available remotely through a web browser.



The system as shown in Figure 13 will be configurable to allow for some components not to be duplicated, see Figure 15 and Table 18 which lists the placement of the software components in the system. Each process has now been classified into its subsystem software component and the communication between these components has been described.

5.2 Overview of the software components

The use of existing components is necessary to achieve the system as described in REDOC in the time frame of the project. Below is a table of the software components and their possible implementation and the state of the implementations is as follows:

• Exists : Can be without modification.
• To be refined : The component exists with the correct functionality but will need some modification.
• To be developed : The component does not exist.
• ** : To be decided. See Security implementation .
• ?? : Has yet to be published.

5.3 Choice of existing components: experiment configuration

PrepIFS as an experiment configuration application consists of several components: GUI,ORB and configuration server. The GUI allows access to experiment configurations, SMIOC and SSC as described in ARCDI 2.2 - PRISM coupler and I/O library, stored on the configuration server and also contains logic to validate the configuration. Experiment configurations are sent to the configuration server which generates the correct job control scripts for the experiments and deploys these through SMS which schedules the experiment for execution.

The system is built on Web Services and so fits well into the proposed architecture.

5.4 Choice of existing components: WEB Server

The choice of Apache is based on the fact that it is free and used by a majority of the worlds web servers as well as being reliable, mature, maintained and high performance.

5.5 Choice of existing components: Application Server

The Tomcat application server is closely linked to the Apache Web server and follows the choice of Apache and Java as implementation language of preference.(see REDOC II.1) For sites that do not provide a web server or application server the overhead to install these components is too large. Therefore a service component should be developed that does not require the web server and application server. This service component, we refer to it as a Request Listener (RL), listens for HTTP requests from the Internet and converts them into calls to the provider services listed in Table RDT2. Great care needs to be taken to prove that the RL can only forward authenticated requests and that only the intended services can be reached.

5.6 Choice of existing components: Monitoring and Scheduling

The choice of SMS/XCDP as scheduling/monitoring tool is based on our evaluation of its reliability, functionality, performance and suitability for working with very large numbers of tasks and their dependencies. Figure 16 shows how information is exchanged between the components.

6.0 Proposed architecture

Combining the PrepIFS system with the SMS/XCDP tools results in a configurable and flexible WS system (Fig. 5) with much of the required functionality in place as described in REDOC II.1.

6.1 Additions and changes to components in Table 3

The requirements for components listed in Table 14 as to be refined or to be developed are examined further.

Experiment configuration , task id# 1

Addition of keyboard navigation.
Creation of a experiment configuration definition interface to allow modellers to develop configurations for the models remotely (optional).
Changes to allow a more flexible experiment hierarchy. Standardisation of interfaces.

Experiment visualisation, task id# 2

It is assumed that this task will only involve implementation of an interface to start the visualisation tools. If there are no requirements the user interface will spawn a browser with a configurable URL.

Authentication, task id# 3

This task contains the development of an authentication system as well as exporting the authentication as an interface to other services if needed.

Archive query, task id# 4

It is assumed that this task will only involve implementation of an interface to start the archive tools. If there are no requirements the user interface will spawn a browser with a configurable URL.

Documentation, task id# 5

PrepIFS has an integrated help/documentation system available. It is desirable that this is extended to allow modellers to add/change documentation remotely in a safe way.

Experiment monitoring, task id# 6

The current monitoring system (see fig 1 in REDOC II.1) is designed for LAN access and is to be extended to WAN access over the Internet.It is desirable that it retains its graphical view if possible. It should provide the functionality as described in section II.4, if this can be achieved without security concerns.

Experiment configuration server, task id# 7

Creation of a deployment environment and the scripts needed to deploy the composed model automatically.

Documentation server, task id# 8

Automatic generation of documentation from all available meta data and addition of developer descriptions.

Administration server, task id# 9

An interface for administration of the WS system and domain software should be developed. Initially this will be handled manually but some automatic system is desirable. This is further developed in section Software life cycle management .

Archive Meta Data browser and server, task id# 10

It is assumed that this task will only involve implementation of an interface to start the archive tools. If there are no requirements the user interface will spawn a browser with a configurable URL.

Visualisation server, task id# 11

It is assumed that this task will only involve implementation of an interface to start the archive tools. If there are no requirements the user interface will spawn a browser with a configurable URL.

Monitoring server, task id# 12

Some refinements needed to allow for web based monitoring.

Scheduling server, task id# 13

No changes anticipated.

Execution server, task id# 14

This is the task of the modelers.

Archiving server, task id# 15

It is assumed that this task will only involve implementation of an interface to start the archive tools. Due to the lack of a central archiving system archiving will be made at the site where the experiment runs using the local facilties available. This is detailed in REDOC II.3. If there are no requirements the user interface will spawn a browser with a configurable URL.

Authentication server, task id# 16

This will be implemented as recommended in collaboration with Fujitsu. It should allow for Message Authentication (MAC) between services and for client authentication between users and services.

ORB, task id# 17

The existing ORB has a protocol manager for Java RMI services. This will be extended to allow other protocols such as Java-RPC. A typical system is shown in Figure 17:

Request Listener, task id# 18

This service component, the Request Listener (RL), listens for HTTP requests from the Internet and converts them into calls to the provider services. It allows for deployment of models from the central site to the PRISM sites. There are considerable security implications for this component and by delaying the development of this component to a later stage software to help with this task should have become available.

Event service, task id# 19

An event service should be developed to allow for notification between applications and to clients. A Java application programming interface JINI exists and this will be implemented.

Directory server, task id# 20

The PrepIFS directory server, the interface repository, is a proprietary technology and this should be migrated to a UDDI compliant server.

Administration scripts, task id# 21

The administration model proposed requires considerable standardisation and and automation. The process is described in section Software life cycle management.

Experiment configuration , task id#22

The use of XML in definitions of meta data requires the configuration server to be able to read its input data in this format.It might be needed to create special configurations files for this purpose.

Semiautomatic deployment of java components, task id# 23

An interface for administration of the WS system and domain software should be developed. Initially this will be handled manually but some automatic system is desirable. This is further developed in section Software life cycle management .

Setup of PRISM central site

The configuration of all system components on a central site on dedicated hardware and with security measures in place.

7.0 Specifications, definitions and standardised interfaces needed for the implementation of the system

1. Format of experiment configurations (definitions and compositions) for instances and inherited values.
2. Format of experiment names and id's for archived data to facilitate unique names.
3. API for experiment configuration widgets in the GUI to allow new visual representations.
4. API for getting context and authentication information from the GUI.
5. API for service extensions and additions.
6. Format of naming conventions used to specify services.
7. Format for calling services from clients, message standard.
8. Development of standards for achieving remote build capacity for each model component. This includes build scripts capable of determining compiler versions and switches, libraries and operating systems.

8.0 From design to implementation : The component to deployment translation

The web services concept is a very flexible architecture and well suited for deployment over multiple computers.The proposed architecture involves the partitioning of functionality into a central system for storing experiment configurations and local PRISM sites for executing the models.

The components will be located as follows,where 1 means on site and 0 means not on site:

Table of software components and their location
Component	Central site	PRISM site
Experiment configuration server	1	0
Documentation server	1	0
Administration server	1	0
Meta Data server	1	0
Visualisation server	0	1
Monitoring server	0	1
Scheduling server	0	1
Execution server	0	1
Archiving server	0	1
Authentication server	1	0
ORB	1	0
Event service	1	1
Directory server	1	0
Table 18

Some replication of functionality is possible, see Figure 15. It is desirable to store the experiment configurations centrally to minimise administration unless the system is run locally.

8.1 Detecting, handling and reporting faults strategy

Large parts of the communication will take place over public networks (Internet) of which we have no control. It must be understood that communications over the Internet is on a best effort basis. An organisation (email's etc) for reporting faults in web services together with problem report standards must be set up. A monitoring system for the web services together with some diagnostic tools would be desirable.

8.2 Integration with other work packages, published interfaces

This is connected to the requirements of the subsystems and what context related information of the main GUI they need, for example "current experiment".

Close cooperation is needed with WP3i, Assembling the PRISM System, will be required to make sure all configuration information can be accessed from the GUI and to provide for the scripts used to run the models. These scripts typically deals with the:

• Creation of executables.
• Hardware specification (model resolution, number of processes used....
• Imput/Output.
• Initialisation of physical parameters and physical constants.
• Distribution of the different type of files into the tree architecture.

8.3 Software life cycle management

Initially manual administration will have to be considered. Typically and administrator has to log into the site. Tools such as Secure Shell should make this possible. Semiautomatic administration should be developed allowing for administrators to install new versions of models and for infrastructure components to be updated efficiently.

Component models should be updated through the administration interface. This interface is the composition GUI used for experiments but will now enable the administrator to enter locations for files, change compilation options and the like. These responsible components are number 1, 9 and 22 in Table 14. A typical administration scenario is described:

• Administrator starts GUI
• Loads configuration of site X component model M1
• Enters the location of the sources as ftp address
• Changes other settings and gives new version number.
• Presses submit.
• A build job is created at site X with the configuration and queued for execution.

The outline above suggests that this procedure can only succeed by using a high standardisation of build scripts, makefiles,versions and source layout. This standard needs to be described, defined and followed by the model developers to allow us to create an automated procedure.

For infrastructure components such as the Request Listener (RL) and the administration server, a semiautomatic system should be developed. Components consisting of archive files with java classes and associated configuration data can be triggered for automatic installation on a site. The viability of this solution depends on the the security model implemented.
The component responsible for this is no 23 in Table 14.

8.4 Access control

The area of access control has not been addressed by any other document and as such is undefined for archiving, visualisation, monitoring and running experiments.
This questions is related to the security implementation.
It is expected that unix permissions related to user ids will be implemented and that only preregistered per user access to PRISM sites will be allowed.

9.0 Implementation plan, deliverables and desirables

In general the implementation should be feature based,i.e. we first deliver a very basic but useful functionality. Subsequent development is concerned with developing new functionality as "features" with each new feature requiring a new release.The implementation is to be made as a local system and a WS system.

9.1 Description of local system.

The local system will run the server and client parts as one component on a local computer. The software will be made available from a repository at prism.enes.org. The software will deliver a GUI run from the command line that reads all configuration files from the current working directory. The user will be in full control of all configuration files and can edit them at will. This system is aimed primarely at model developers, refer to local system.

9.2 Description of WS system.

The WS system involves splitting the local system into its separate software components and moving the configuration files developed with the local system to the server. This requires the security mechanisms to be in place.

9.3 Security implementation.

The security requirements have been described in detail in the REDOC II.1 document. Some implementation aspects are :

• The modularity of the solution.
• The timescale of implementation.
• The use of existing software independent products.
• Discovery and implementation of new schemes in the computing community.

One of the reasons that the security implementation is difficult is that there are currently no ideal security implementations available that are scalable, cheap, secure and convenient. New technologies are being held back because of this and there is a lot of activity in the field to overcome this situation. Standardisation and reference implementations can be expected within the progress of the PRISM project. Further, there is a variaty of solutions in place at different PRISM sites and a survey is made to gather information on their preferences.

The security solution involves authentication and security between computers and of humans communicating with computers.

From the implementation plan we can see that a security implementation will not be required until month 24. It will be a further year until a fully service based system is in operation and advanced service to service authentication needs to be in place. Therefore the final security solution is kept open to allow for the use of new emerging standards and initially concentrate on modular solutions with low maintainance requirements.

9.4 Proposed solution

For authentication between humans and computers we should use a software independent simple password related system such as s/key. This system can be implemented with HTML and Java based solutions and is well known to system administrators who already maintain password files. Implementations are freely available. Communication can be secured by signatures but should not be encrypted.

For authentication between computers standardisation is currently under way by the Sun Web Messages Security API (http://jcp.org/jsr/detail/183.jsp) and also by Worl Wide Web Consortium Encryption WG (http://www.w3c.org/Encryption/2001/) and other related XML technologies such as SAML (http://www.oasis-open.org/committees/security/).

The basics of the these technologies is to use signatures to secure the messages from being tampered with and public key encryption to allow for authentication. An implementation building on the password files as a shared secret key is possible and could be implemented if no standards have emerged.

9.5 Plan

The implemenentation plan builds on creating the necessary infrastructure for the WS system on the central site . Parallel to this the local system is used by developers to work on their models so that they can be made available to the central system.

Once the quality and operation of the system is satisfactory the remote servers on other sites will be developed and deployed letting users submit experiments on other sites.

This has the advantage of not spending administration efforts on inferior quality software and time on remote debugging sessions.

9.6 Phases

The implementation plan consists of 4 different phases: Foundations, prototype, network and integration, documentation and features. The plan tries to move the features not necessary for basic operation to the later phases.

It is important to determine the critical path in the development and the functionality that can stop the progress of the project:

9.7 Critical path

It is essential to determine the critical path for the implementation of components. Dependencies are given for each phase.

9.8 Month 6 to 12 : Foundations, local system

• Administration scripts
• Build administration interface.
• Adapt existing GUI
• Tasks: 1,7,21,22

Deliverable :Delivery of local system to modelers.
Dependencies :Deployment scripts defined and available, deployment structure agreed on, XML formats known and defined with examples, standard build scripts defined and created.

9.9 Month 12 - 18 Prototype of web based system

• Develop monitoring server
• Develop administration server
• Tasks:12,9,6
• Additional work is required to set up a central site.

Deliverable: Prototype of web based system.
Dependencies :Standardised configurations made available by modelers, monitoring tool available.

9.10 Month 18 - 24 Testing,security and feature development.

• Develop/Test security
• Development of network related infrastructure
• ORB,Directory server.
• Tasks: 3,16,17,20

Deliverable : Deliver system with components installed in multiple locations.
Dependencies : Security and access model defined, test systems available, archiving of data must be working and accessible or results will have to be deleted.

9.11 Month 24 - 36 Network and integration of visualisation and diagnostics tool

• Event service
• Integration of visualisation and diagnostics.
• Semiautomatic software distribution system.
• Documentation
• Tasks: 8,18,19,23

Deliverable: Deliver fully tested and documented system.
Dependencies :Security implemented, interfaces to visualisation and diagnosticstools implemented and available for integration.

10.0 Integration with other projects

The fact that other projects with similar goals (Globus etc) are emerging and being developed raises the question of integration and also cooperation. If a high degree of inter-operability is required we should test their systems and also make contact to discuss how we can both benefit from each others development. Advantages could be reuse of software but the time it takes to identify these areas is at stake.

11.0 Risks

Table of risks
Risk	Risk Magnitude	Description	Impact
Security demands incompatible on some sites.	Severe	Multiple security solutions may be necessary.	If sites cannot agree on one security solution it may introduce costly separate solution affecting the client experience.
Deployment and administration cycles made difficult due to security.	Severe	Increased manual intervention necessary at higher cost.	Synchronisation of software is delayed.
Hardware resources unavailable for testing and implementing the infrastructure.	Fatal	System cannot be built and tested.	No system.
Standardisation of build scripts not achieved.	Severe	Models not conforming to standards.	Manual intervention required.
Creation of configuration information for GUI incomplete.	Severe	Necessary information missing for configuration or deployment	GUI will not work properly and automation benefits lost.
Deployment standards not achieved.	Severe	Difficult to achieve standards if validation and editing tools not available.	Deployment will fail.
Table 19

12.0 Definitions,Acronyms and Abbreviations

Table of Definitions,Acronyms and Abbreviations
Keyword	Description
WSDL.	is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.
XML	The Extensible Markup Language is the universal format for structured documents and data on the Web. is a human-readable, machine-understandable, general syntax for describing hierarchical data, applicable to a wide range of applications Custom tags enable the definition, transmission, validation, and interpretation of data between applications and between organisations.
Simple Object Access Protocol	SOAP is a lightweight protocol for exchange of information in a decentralised, distributed environment. It is an XML based protocol.
Java	A programming language invented by Sun which runs on any platform and supports web services.
SSL	Secure Socket Layer, a Netscape invented secure communications protocol.
SSH	Secure Shell, a secure remote access protocol pioneered by BSD enabling remote logins.
Kerberos	Network security system developed by MIT.
SKey	One-Time Password system.
UDDI	Universal Description, Discovery and Integration.Enables dynamic lookup and advertising of services.
X509	Standard for certificates used by SSL authentication and encryption.
Table 20

13.0 REFERENCES

1. Dr Foster, P.42 Physics Today, Feb 2002
2. GLOBUS - www.globus.org
3. UNICORE - www.unicore.de
4. SOAP - http://www.w3.org/TR/SOAP
5. XML - http://www.w3.org/XML/1999/XML-in-10-points
6. UDDI- http://www.uddi.org/
7. WSDL - http://www.w3.org/TR/wsdl
8. JAVA - http://www.sun.java
9. SSH - http://www.openssh.com/
10. SSL - http://www.openssl.org/
11. Kerberos - http://web.mit.edu/kerberos/www/
12. Skey - http://www.freesoft.org/CIE/RFC/Orig/rfc1760.txt
13. X509 - http://www.openssl.org/docs/apps/x509.html