• No results found

Enabling CASs to Access to Grid and Web Services

5.1 Client Component Requirements and Capabilities

5.1.1 Enabling CASs to Access to Grid and Web Services

The architecture of the client side component is composed of two types of components, the ones that have the role to provide capabilities for interacting with generic remote Web or Grid Services and a special category that are designed to be used in conjunction with the services provided by the AGSSO components. All these components rely them-selves on specialized components and packages developed by third party providers. For instance, components at the client side that allow access to Web Services rely for some of their implemented features on the capabilities offered by Apache Axis. Similarly, other components provides support for features specific to Grid Services and rely on al-ready existing APIs provided by Globus Toolkit. Whenever possible existing solutions already well known and accepted by research communities and industry are preferred to ad-hoc solutions. The client side components provided by AGSSO have the role to embed features such as security certificates management and further provide them as routines accessible directly within the CASs’ command line environment. Due to spe-cific design of the components we developed, they can be easily integrated within any CAS.

In addition to the core functionality that allows access to remote services specific func-tionality for managing data and preparing calls is provided. We have presented in the previous chapter a solution for handling symbolic computation workflows. This solution required that the client specifies the workflow in a specific format which can be under-stood and managed by the AGSSO server. Even if the workflow instance that has to be described at client side does not have a complicated structure, the fact that it must be described using the specific XML language makes this task cumbersome to be done manually. One of the components available at client level implements functions that assist the user in creating workflows in the appropriate format. All features mentioned

Client

SGServices

SGProxyCert

SGUtils

AGSSOCli

CAS

Web Services

Grid Services

AGSSO

Figure 5.1: Client Side Architecture

above are wrapped into a single stand-alone executable that can be accessed by any ex-ternal component which is able to communicate through pipes. This represents the first, the lowest level layer of the client side architecture.

The second layer of components that must exist at client side are components that are directly integrated within the CAS and they have the role to facilitate access within the CAS environment to the features provided by the first layer. Within the CAS’s develop-ment environdevelop-ment, the user should access already provided routines that makes access-ing Web Services or describaccess-ing complicated workflows simple and intuitive. Packages of functions specific to a certain CAS represent a thin layer and have the role to relay requests to the specialised external components mentioned above. This decoupling is in many respects beneficial. Specific functionality does not have to be implemented within the CAS and only a thin layer of routines which formulate appropriate requests to the first layer have to be provided. Enabling a new type of CAS to access Web of Grid services is easy and reliable because the core functionality is provided by external com-ponents. If access to new technologies have to be provided within the CAS, they can be easily added at a later time.

The general architecture of the client is presented in Figure 5.1. CASs access the

func-tionality of the CAGS components by communicating with the RunManager component which is a command line interpreter. RunManager is a completely generic interpreter that exploits Java reflection capabilities to allow the execution of any class. The sub-components of the clients side helper component are the following:

• SGServices: this provides support for three types of operations retrieval of the list of services registered to a certain UDDI registry or Globus container; retrieval of signatures for the exposed operations of a service; calling remote operations.

• SGProxyCert: this handles issues arising from the need to support single sign-on for users of the Grid and delegatisign-on of credentials: namely the creatisign-on and destruction of proxy certificates. The component can also be used to retrieve in-formation about the owner of a X509 certificate and about the lifetime of a proxy certificate. Since a user may have more than one X509 certificate, but with only one being used at a certain moment, when creating a proxy certificate, the location of the certificate is automatically stored in a session file. When a proxy certificate is needed, this default certificate is loaded and used.

• SGUtils: this provides additional functionality for explicit file transfer, file deletion and remote job execution. This capabilities are related to generic services that Grid environments build over Globus provide. For data specific management that the AGSSO architecture provides, other services are involved which the user does not have to call explicitly.

• AGSSOCli: this package reunites all the functionality required for users to ac-cess capabilities provided by the components of the of AGSSO architecture. This component is responsible for incrementally constructing the workflow in the for-mat that the AGSSO server is able to understand and also specific capabilities to interact with services provided by AGSSO and CAS Server components