D IVULGACIÓN POLÍTICA DE CINTURÓN

Like any service, a grid service has its target users and grid service providers strive to meet the requirements of their users (requestors). The process of defining a grid service is guided by this principle. For example IBM (Hayes, 2008), Google (Dyer et al., 2008) and Amazon (Weiss, 2007) started their cloud computing projects based on some initial market assessment of the demand in the grid community. The choice of target users determines whether or not the grid will serve research communities or commercial and business communities. This again will determine the features desirable by such communities. For example, research communities are often comfortable with the proxy security feature in Globus toolkit which delegates authentication and authorisation of resource access to users through third parties while the business community is not happy with this. They would rather use bipartite security feature which restricts the right of authentication and authorisation to resource owners without involving third parties. However, regardless of what target users a grid service is to serve, a generic procedure is adopted here and can be ‘customised’ to meet various types of grid services. The generic process is described in Figure 6.1.

Process of Grid Service Definition

Identify Service Requestors Chose Type of Grid Define Grid Service Requirements Identify Competing Grid Services Platform Development Policy Agreement between Provider and Requestor Service Implementation

Figure 6.1: Process of grid service definition

o To identify the process of grid service definition

o To discuss the critical variables that make grid services practically useful for

MODO applications

o To use the design in chapter 5 to come up with a framework for the

research

o To provide an architecture for implementing MODO services

Each stage described in Figure 6.1 is explained below.

6.2.1 Identification of service requestors

Like every utility, grid service existence and continuity is driven by users’ demand. This forms the basis that grid service providers use to define and create services. The first process in grid service definition is to identify service requestors and decide on what type of services and requirements a service provider needs to satisfy. Service requestors range from the field of science, engineering and business and they may require services for data, computation, collaboration, optimisation and visualisation among others. Users may be from different companies and may be located in different geographical locations. These and many other considerations are captured during this stage to serve as decision guideline for the type of service provision (Kim et al., 2008). This may help in delivering the required quality of service (QoS) on resources assembled dynamically from enterprise and service provider through abstractions and concepts acquired (Foster et al., 2002a). In this research, the service users are design experts carrying out MODO tasks to obtain optimum solutions for designs. This category of users needs computational power, data repository, collaboration and visualisation capabilities within the services provided.

6.2.2 Choice of grid type to publish services

When service requestors have been identified, the provider decides what type of grid can accommodate the services the users need. For example, if users are mainly in the research and scientific domain, then a combination of computational and data grids which allows collaboration is a likely candidate. This is because researchers usually need computational power to perform some simulations and data could be generated which requires inputs from collaborating researchers to analyse. A single grid type may not satisfy users, so the normal convention as proposed by this research is to identify combination of grids that best suits users’ needs. Grid types include computational grid, data grid, enterprise grid, extraprise grid and global grid (Abbas, 2001).

6.2.3 Definition of grid service requirements

Now that the requestors have been identified and the type of grid that suits them is also identified, the next stage is to define service requirements that will meet requestors’ needs. Service requirements may include collaboration, dynamic prizing

and accounting system (Buyya, 2002), special security features, deadline and priority job completion, service discovery mechanisms, and communication protocols (Lin and Lin, 2006). Both functional and non-functional requirements are defined. In chapter 5, the design was based on MODO service requirements. Such requirements include the need to have a mathematical model building interface and to have a collaboration for design experts to collaborate. Other obvious requirements are the computation and data repository.

6.2.4 Identification of existing competing grid services

It is a good practice that the services provided conform to existing similar services so as to maintain a standard. This is done by studying the performance and problems faced by existing similar grid services with the aim of improving upon them and avoiding problems. During the literature review and industry survey in chapters 2 and 4 respectively, MODO PSEs were discussed. This gave the researcher an idea of existing PSEs in MODO domain and their capabilities (Kim et al., 2008). The emergence of cloud computing is believed to have come out of the grid community to launch production grids for companies to see the business needs to invest in it even though the utility computing concept has been part of the grid concept (Buyya, 2002). The Geodise, FIPER, SORCER and DAME projects are the main competing PSEs in MODO applications.

6.2.5 Grid convention platforms development

This is one of the most important stages in grid service definition. Services do not operate in isolation; they interact with other services through grid ‘plumbing’ interface implementations that follow recommended standard interface protocols as provided by the Open Grid Forum (OGF). These protocols are part of the Open Grid Service Architecture (OGSA) and Web Service Resource Framework (WSRF) platform implementation that allow services to be dynamically created, named, discovered, used and destroyed without much configuration difficulties (Berman et al., 2003). Every service provider that intends to join the grid follows the OGF recommended convention for developing the platforms upon which the services are published. Service requestors also need to do the same so that both interfaces (provider and requestor) conform to the same standard. This is what allows the service provider and service requestor to communicate effectively. This feature is partly a

technology issue and partly a business issue. Section 2.7.1.1 of chapter 2 describes the OGSA platform together with portTypes, GridService and service data elements (SDEs). Conventional grid services use these standards for services to communicate and be useful.

6.2.6 Policy and agreement between grid service providers and

requestors

Service level agreement in grid services is increasingly becoming an important aspect to have multiple providers and requestors sharing and allocating resources and services for multiple applications (Wu et al., 2009). Service providers and requestors usually have written agreement for the services to be provided along with functional and non-functional requirements. The service provider agrees to provide services that will deliver functions that satisfy some parameters such as QoS, computational power, data storage and management, security and optimisation to service requestors. Service requestors are charged for using the services on-demand basis as long as the services satisfy their requirements (Buyya, 2002). This agreement is necessary to make grid service stakeholders (providers and requestors) know their obligations. This is one of the features this research intends to incorporate and emphasise in the service specification document.

It is worth mentioning here that the legal framework for service level agreement has not been addressed in the service specification document in this research. This is considered as a future work.

6.2.7 Grid Service definition implementation

When service providers and requestors finally agree on terms of service provision and service requisition, the entire service definition is set for implementation. Every single grid resource (service) is uniquely registered and is uniquely traced to a service provider by a Grid Service Reference (GSR). This makes implementation of similar services by different service providers possible within a global grid. Also, every single instance of a service is uniquely identified globally by a Grid Service Handle (GSH). This property makes it possible to create multiple copies of the same service by different service requestors globally through stateful representation (Chao et al., 2006). This research uses the factory pattern model for developing services which

uses the OGSA. Globus middleware is built on OGSA and has capabilities for GSR and GSH.

It is important to note some differences in what ‘grid service providers and requestors’ stand for from two different points of views. The first version is looking at grid service providers and requestors as ‘organisations, companies, institutions or individuals’. For example a university that builds grid services for its researchers (requestors) to use. This is the context in which this research uses the phrase ‘grid service providers and requestors’ in the ‘process of grid service definition’. This is a practical view of grid service definition which looks at grid services in terms of economic models of supply and demand or supplier (service provider) and customer (service requestor) (Buyya, 2002; Papazoglou, 2003). However, the same phrase (grid service providers and requestors) can be used to mean software or hardware systems that implement grid service provision and acquisition. These systems are the autonomous agents for service discovery, service orchestration, service brokering, service scheduling, information service, resource management and service authentication and authorisation (Czajkowski et al., 2001). This is a systemic view point of grid service definition and is used in grid service representation.