E XÁMENES PSICOSENSOMETRICOS

A grid service is a software agent that performs some well-defined set of operations (service provision) and can be invoked by users (humans or other services (called agents)) through a high-level feature called network-addressable interface via standard grid protocols and data formats (Buyya, 2002). Network-addressable interface is the Internet Protocol (IP) address of a host or node in a network which uniquely identifies the machine and allows other machines to communicate with it. Standard grid protocols include SOAP, WSDL and WSRF as explained earlier. These services or agents coordinate their activities by sending and exchanging messages within a distributed network system known as service-oriented architecture (SOA). An SOA is a distributed system based on open-standard architecture in which the agents are services that perform specific functions and operations. Resource owners (grid service providers) in the grid environment need to publish services for resource users (grid service requestors) to access. Both resource owners and users need to agree on policies and rules guiding the grid ‘market’ place (Buyya et al., 2001). The next sections will describe the process and representation strategies that grid service providers need to follow to define grid services that meet the clients’ requirements.

2.7.2.1 Representation of grid service definition

Grid resources (services) are defined and represented using standard mechanisms for creating, naming and discovering grid service instances. These standard mechanisms are defined by the Open Grid Forum (OGF) based on Open Grid Standard Architecture (OGSA) and Web Services Resource Framework (WSRF) specifications. OGSA is the architecture upon which grid services are deployed. WSRF provides the infrastructure for the implementation of OGSA functionalities. The representation ensures grid service location transparency, technology neutrality, loosely coupled systems and multiple protocol bindings for service instances and supports integration with underlying native platform facilities (Foster et al., 2002b). The representation of service definition is built on the service model called service-oriented architecture (SOA). Figure 1.1 in chapter 1 shows the basic diagram of SOA. It is the relationship between three fundamental participants in grid service marketplace namely grid

service provider, grid service requestor and grid service discovery agent (Papazoglou, 2003). The service provider hosts and defines the service descriptions as well as publishes the described services for service requestors to access or subscribe for published services. Service requestors find services through service discovery agents in the form of registry such as UDDI (Universal Description Discovery and Integration) protocol which is created and maintained by the service provider. It is important to note that service provider, service requestor and service discovery agent in this context are all software agents. The fundamental logical representation of SOA consists of service interfaces (software agents) and strategies that allow implementation of business functions. In this research, services for MODO applications are implemented using OGSA within the Globus middleware. Below is the hierarchy or taxonomy of the representation of service definition in SOA.

Grid service providers

Providers are software agents that provide services while requestors are software agents that use those services. An agent can play the role of service provider as well as service requestor. Providers publish descriptions of services they provide within a standard layered architecture. For example, a resource such as sensor will be published as a core resource at the lowest layer of representation. Core resources are services that interact with hardware and operating systems and their implementation are not visible to the user. A resource such as CAD (Computer Aided Design) software will be published at the topmost (application) layer so that end users can use it directly. This layered architecture follows the conventional grid architecture as described in Figure 2.9. DECGrid developed in this research uses the same convention to run its services within the Globus environment.

Grid service interfaces

The interaction between service providers and service requestors is done through interface implementation. They simply provide the mechanism through which services communicate with applications and other services. The service interface is the descriptive GSDL implementation of operations available to service requestors to invoke services (Smith and Lumb, 2001). Various OGSA platforms implement different service interfaces as described below.

WSRF: Web Services Resource Framework

WSRF represents the convergence of grid services and web services. It is the interface that implements protocols that enable grid and web technologies to interact on the same platform. WSRF provides capabilities to define mechanisms for creating, naming, service lifecycle, managing and exchanging information among grid services. Because grid services are dynamic and stateful, a mechanism is used to globally assign unique names to every service instance called grid service handle (GSH). This means every service instance is unique and can be identified through its GSH by users. GSH carries no protocol or information and so if a network fails with a service instance running, the same GSH can be used to store information of a new service instance when it is restored. The information in every GSH is encapsulated in a mechanism called grid service reference (GSR). Unlike GSH, a GSR can change over its lifetime if the information on GSH changes. This means GSR can expire because it has an explicit lifetime. WSRF implements stateful grid services, inheritance of service interfaces, asynchronous notification of state changes, references to service instances using GSR and the unique global identifier for every grid service using GSH (Slomiski, 2005).

An important aspect of WSRF is to implement new grid service interfaces called portTypes. Examples of portTypes are GridService (encapsulates the root behaviour of service model), HandleResolver (mapping from a GSH to a GSR), ServiceGroup (allows requestors to maintain group of services), ServiceGroupRegistration (allows grid services to be added and removed from a ServiceGroup), ServiceGroupEntry (defines the relationship between a grid service and its membership within a ServiceGroup) and Factory (standard operation for creation of grid service instances). Most portTypes are optional, but for a grid service to be WSRF-compliant, it must implement the GridService portType (Baker et al., 2005). PortTypes use some elements to implement operations on grid interfaces. For example, the operation findServiceData is defined for GridService portType to query the service data element (SDE) referred to as ServiceData. SDE is the property of any data represented in grid and can be used to query instance of that data. It is this same operation that allows optimisation experts to query available optimisation algorithms and computational resources. For example to use the OGSA service browser graphical user interface to

query NSGA-II optimisation algorithm as a resource, the following command is issued:

mds-find-service-data –service http:/isxp1313c.sims.cranfield.ac.uk:1081/nsga-ii

OGSA Platform Interfaces

The OGSA Platform Interface (OGSA-PI) defines important functions of grid services. These functions include Service Groups and Discovery Interfaces (two-level naming based on GSHs and GSRs provides a way of accessing known services which requires a higher level abstraction to allow clients to find services at lower level), Service Domain Interfaces (grid service collections that produce a high order grid service interface), Security, Policy (agreement between service providers and requestors), Data Management Services and Metering and Accounting (metering interface, rating interface, accounting interface, billing and payment interface) among others (Berman et al., 2003).

OGSA Platform Models

OGSA-PI does not provide capabilities for managing virtual and physical entities (hardware and software), though it provides some basic management mechanisms for grid services. OGSA Platform Model (OGSA-PM) provides set of common models for describing and manipulating real entities such as Linux high performance computing (HPC) cluster to be presented as grid services. Each model defines specific attributes of a domain. For example, a model will define Linux HPC cluster which describes the attributes of Linux clusters that are specific to HPC and are needed to run jobs on clusters. This capability is used in the proposed DECGrid together with Condor to provide statistics on the computational usage of the cluster at any given time.

OGSA Platform Profiles

OGSA Platform Profile (OGSA-PP) defines protocol bindings, hosting environments and domain-specific services.

Every service has a number of service data elements (SDEs) from all the portTypes the service inherits. All services must have logical XML document containing these

values together with a root element type of serviceDataValues. The service implementation can store these values in any format but must convert the internal representation to XML as necessary (Berman et al., 2003). The service specification document that is used to develop the proposed DECGrid services explored this capability. A description of portTypes and SDEs are shown in Tables 2.3 and 2.4.

Table 2.3: PortTypes for Basic Services (Berman et al., 2003).

PortType Description

GridService Encapsulates the root behaviour of the service model. A web service must implement the GridService interface. All other portTypes are optional.

HandleResolver Mapping from a GSH to a GSR

NotificationSource Allows clients to subscribe to notification messages NotificationSubscription Defines the relationship between a single

NotificationSource and NotificationSink pair

NotificationSink Defines a single operation for delivering a notification message to the service instance that implements the operation

Factory Standard operation for creation of Grid Service

instances

ServiceGroup Allows clients to maintain group services

ServiceGroupRegistration Allows grid services to be added and removed from a ServiceGroup

ServiceGroupEntry Defines the relationship between a Grid Service and its membership within a ServiceGroup

Table 2.4 describes the interfaces that services use to communicate among themselves.

Table 2.4: Service Data Elements (SDEs) (Berman et al., 2003).

SDEs Description

Interface A list of the names of all portTypes implemented by

the service

serviceDataName A list of names of all SDEs supported by this service instance

factoryLocator A service locator that points to the grid Service instance that created this Grid Service instance

gridServiceHandle Zero or more GSHs of a Grid Service instance gridServiceReference Zero or more GSRs of a Grid Service instance

findServiceDataExtensibility A set of operation extensibility declarations for the findServiceData operation. The client can use any of the listed inputelent types

setServiceDataExtensibility Operation extensibility declarations for the setServiceData operation.

PortTypes GridService (required) Other Interfaces (optional) Service Data Element Service Data Element Service Data Element SDEs Implementation

Hosting Environment Runtime (C#, J2EE, .NET, …..) OGSA-defined Notification Authorisation Service creation Service registry Manageability Concurrency Application specific interfaces

Service data access Explicit destruction Soft-state lifetime Binding properties: Reliable invocation Authentication ---

Figure 2.10: OGSA Grid Service (Foster et al., 2002a)

The implementations and configurations of these portTypes, SDEs and operations can be done within the Globus XML schema to suit users’ requirements. The development of grid services can be done using two main models. These models are the single- resource grid service model and factory pattern grid service model. Both models use the OGSA standard interfaces. The single-resource model uses the same class to define and implement the service (functionality) and resource (data). This implementation model is only good for small web services. For complex grid services which require multiple data sources and services for different users, the factory pattern model provides different classes for data and services. This makes system maintenance of the grid services easy. This research adopts the factory pattern model because MODO experts need to have different data sources for different services. A simple description of the implementation is shown in Figure 2.10.

MODO Services

MODO framework needs to support a diverse set of services as well as a diverse group of grid users. The diverse services may run on different hardware architectures (HP, Intel, Sun, etc), operating systems (Linux, Sun Solaris, Windows, Mac OS, etc), data formats (relational databases, file systems, etc) and optimisation codes

(evolutionary algorithms, classical algoritms, etc). The diverse group of users may constitute toolkit developers, grid administrators, application users, managers and professionals in the fields of science, engineering and business. Every user has a different need. The domain administrator is concerned with having control over the resources under his hosting environment without being restricted to a centralised administration. In this way he/she can decide who accesses what and when. The application programmer wants to have transparent access to development tools without bothering to have prior knowledge of the hardware or operating system architecture.

When creating new services, a user application issues a create Grid Service request on a factory interface, leading to the creation of a new instance (Berman et al., 2003). This newly created instance will now be allocated some computing resources automatically. An initial lifetime of the instance can also be specified prior to its creation and allows the OGSA infrastructure to keep the service ‘alive’ for the duration of this instance. This is achieved by sending it keepalive messages. The newly created instance is assigned a globally unique identifier called the Grid Service Handle (GSH).

Organisations can come together to collaborate at different granularities. Horizontal MODO service collaboration involves organisations and professionals in similar disciplines, vertical MODO services involve organisations from different disciplines but with complementing roles to produce products or deliver services. Using the above capabilities, a simple implementation of MODO services could involve the following steps:

o Write a portType definition

o Write a GSDL binding definition to connect to MODO services using protocols such as SOAP/HTTP, TCP/IP, etc

o Write a GSDL service definition based on the portTypes supported by the MODO and identified in first step

o Implement a factory by extending the FactorySkeleton provided indicating how new instances of MODO services are to be created

o Implement the functionality of the MODO service by extending the FactorySkeleton class. If an existing code (legacy code) is to be used in this mode, the delegation mechanism should be used, in this case the factory returns a skeleton instance

o Implement code for the client that must interact with the MODO service

2.8 Critical variables that make grid service