gsa

l1. Introduction

In this paper we are concerned with developing software toolsand methodologies to enable scientific collaborations at many dif-ferent scales. This will allow scientists to make use of the poten-tial offered by the utilisation of many resources, necessary for theinvestigation of scientific problems via computational simulationand experiment. In the intensive phase of Grid development from19972007 the concept of the Virtual Organisation (VO) arose toprovide scientific collaborations with access to resources acrossinstitutional boundaries. Thus in [1] the Grid problem is definedas coordinated resource sharing and problem solving in dynamic,multi-institutional Virtual Organisations. The task of computerscientists developing the Grid infrastructure was to hide the com-plexity of this task from the domain scientists. Hey [2] states TheGrid should allow scientists to routinely set up VOs. However,from the community of domain scientists came a warning that theGrid middleware designed to enable this was making this prob-lem more rather than less difficult [3]. Two reasons were given forthis. Firstly, the most popular middleware (Globus) requires a re-source intensive installation on client machines. Secondly, on bothclient side and server side, it also requires particular customisedversions of libraries (for example, for secure socket layer security).These customised libraries quickly get out of synchronisation withthe operating systems libraries that are patched to defend against

Corresponding address: 1 Room 2.22, School of Computer Science, KilburnBuilding, University of Manchester, Manchester, M13 9PL, United Kingdom. Tel.:+44 0 161 275 6814; fax: +44 0 161 275 6024.

E-mail address: john.brooke@manchester.ac.uk (J.M. Brooke).

new methods of security attack. It is also a barrier to usability thatmost Grid security mechanisms require domain users to adapt tothe technology of using digital certificates and go through the strin-gent procedures necessary to obtain and maintain them [4].

In order to understand these issues we need to examinecarefully the concept of Virtual Organisation as introduced tothe distributed computing/Grid community in [1], where a VO isdescribed, obliquely, as a set of individuals and/or institutionsdefined by [highly controlled] sharing rules. An example of aVO is given as a crisis management team and the databasesand simulation systems that they use to plan a response in anemergency situation. This description implies that a VO can spanadministrative domains (as it can be cross-institutional) and is acombination of the people and computational, data and equipmentresources required to achieve a specific goal. In forming a VOaccording to a widely accepted definition [1] a new administrativedomain is created, as this definition states that a VO is an abstractentity grouping users, institutions and resources (if any) in thesame administrative domain. Many others across the computerscience community have gone on to confirm and repeat thisinterpretation of a monolithic VO containing both users andresources. For example, the EGEE Project has the definition of a VOas a set of users, collaborating on a common goal, get together andthrow whatever local resources they have access to in a commonpool. We call the resource pool and the users a VO [5]. Similardefinitions of VOs exist in (for example) [68], and [9].

Our contention in this paper is that the problems describedabove can be more elegantly and effectively solved if a conceptualseparation is made between the integration of the scientistswho collaborate and the integration of the resources requiredby the collaboration. We call the first the resource requestersFuture Generation Computer

Contents lists availa

Future Generation

journal homepage: www

Enabling scientific collaboration on the GJohn M. Brooke a,, Michael S. Parkin ba School of Computer Science, University of Manchester, Manchester, M13 9PL, United Kinb Barcelona Supercomputing Centre, Torre Girona, Barcelona, 08034, Spain

a r t i c l e i n f o

Article history:Received 7 October 2007Received in revised form24 February 2008Accepted 11 March 2008Available online 27 March 2008

Keywords:Distributed applicationsCollaborative computing

a b s t r a c t

We examine the problem ofto support dynamic collabordissolved. We argue that cuthis requirement. We propomechanisms for forming coresources in a Grid infrastarchitecture and, secondly,organisation. An example isto change current existing G0167-739X/$ see front matter 2008 Elsevier B.V. All rights reserved.doi:10.1016/j.future.2008.03.001Systems 26 (2010) 521530

ble at ScienceDirect

Computer Systems

.elsevier.com/locate/fgcs

rid

dom

upporting access by collaborations of scientists to Grid resources. Our aim istions, by which we mean collaborations that can be easily formed and easilyrrent technology for creating Virtual Organisations has difficulty meetingse an alternative structure, called an Alliance, based on a separation of thelaborations of people from the mechanisms for allocating and integratingructure. The key tools for achieving the Alliance are, firstly, a securityan ontological approach to the defining of roles and processes within anpresented to show how these tools can be implemented without needing

rid middleware. 2008 Elsevier B.V. All rights reserved.

oMowshowitzs own language, a set of task formers, existingseparately from a set of task satisfiers. They are loosely coupledsince, depending on conditions such as cost, quality and previousexperience, task satisfiers are chosen and changed at will bytask formers, providing the overhead for switching satisfiers isnot greater than the benefit gained. This switching should bestandard operating procedure according to Mowshowitz. In thebusiness world this practice has become known as outsourcing orsub-contracting, and it allows a task-forming organisation to focus

existing Grid VOs, if desired.As an example, suppose we have a computation running

on some resource which reaches a point where it has datafor visualisation and rendering. It is not be able to performthe visualisation tasks since it lacks the requisite hardware(e.g. specialist graphics pipes). The resource, acting as a resourceprovider in running the computation on behalf of a resourcerequest, then takes the role of resource requester too, as itrequires a service from another resource. The current interest in522 J.M. Brooke, M.S. Parkin / Future Generati

Table 1Alliance & Virtual organisation characteristics (From [19])

Characteristic Alliance

Number ofentities

Few, typically 1 to 2

Life-cycle Temporary; designed to accomplish a specific task anddisband

Scope Narrow; options focussed

and the second the resource providers. In previous work wehave shown how this can help solve problems of interoperabilityof heterogeneous resources [10] and integration of lightweightdevices [11]. More recently the concept has been applied to thedescription of service level agreement [12]. Here we addressthe problem of widening access to resources by scientificcollaborations that are dynamic, by which we mean that they areeasily formed and easily dissolved. Despite the virtues of currentVirtual Organisations in terms of scalability and robustness, theyare not dynamic. Thus the Virtual Organisation ManagementService (VOMS) used in many European projects acknowledges:the main shortcoming of VOMS is its relatively high weight;the setup (and management perhaps) of a VOMS server [is aproblem] as it should be to allow for dynamic VOs [13]. Our toolfor conceptualising and implementing the separation of concernsis the concept of an Alliance between requesters and providers,which allows the coupling to be much looser than in a VirtualOrganisation. The major difference between our approach to VOsand Grid middleware and current practice is that we place theseparation between the organisations of providers and producersat the heart of our analysis. We concentrate on the protocolsthat allow such provider and producer organisations to formcontracts whilst retaining autonomy in their internal protocols andstructures. Our claim, which we elaborate in the paper, is that thisallows a simpler and more robust approach to key problems indistributed computing across administrative domains.

The paper is structured as follows. In Section 2 we introducethe concept of the Alliance. Section 3 describes how the Alliancedevelops role-based access to resources. Section 4 illustrates howwe model the knowledge required to dynamically form collabora-tions of requesters. In Section 6 we present our conclusions andoutline future work to enable the creation of dynamic collabora-tions in different areas of science and engineering.

2. The Alliance

2.1. Insights from the science of organisations

In pursuing the concept of a separation between the integrationof requesters and providers, it was encouraging to find thatthis problem has been previously addressed in the science oforganisations. For example, Mowshowitz [14] describes a virtuallyorganised entity as a set of principles for managing a categoricalsplit between task requirements and their satisfiers. This premiseleads us to consider that these principles are describing thedelineation between two loosely coupled entities or, to useon its core competencies and primary goals and delegate non-corefunctions to specialist suppliers.n Computer Systems 26 (2010) 521530

Virtual Organisation

Many

Usually temporary; but can sometimes last for years

Includes non-operational elements such as Human Resources, marketing and legal

The split between task forming and task satisfying organisations(or, more generally, entities that produce a set of goals andentities that achieve those goals [15]) is further emphasised inthe identification of types of business-orientated organisationalmodels [16]. These place an organisational boundary between aproducer of some service and the customer. They also categorisetasks within a collaboration as co-ordination and productiontasks [15]. To use Mowshowitzs terminology again, task formingentities exist independently from the task satisfiers.

2.2. Application to Grid computing

This very much fits the Grid case. From the point of view ofthe requesters, they wish to use resources to maximise their goalsquite independently of the interests of others outside their collabo-ration. This attitude is so characteristic that it has been given a labelMe-Science [17]. The providers cannot blindly accord with thisview of their resources, since they generally achieve their goals bytrying to maximise the benefit of their resources across their wholepool of users. Undue attention to one set risks alienating others. Itis possible to address this via an economic model in which accessto the resources is maximised according to ability to pay, but thisreinforces the separation of requesters and providers in the sameway that consumers and vendors are separated in economic mar-kets.

This arrangement of two organisations working together hasbeen identified as being distinct and separate from a VO and nameda negotiated organisation [18], joint venture or strategicalliance [19] (the shorter Alliance is used to identify thisorganisational structure in this paper). The Alliance organisationalstructure is narrower in scope than a VO and focussed on theoperational issues essential to a task. To differentiate how anAlliance structure differs from the VO, Table 1 introduces thegeneral characteristics of both forms of organisation.

As the resource requester and resource provider are no morethan roles an organisation plays in an Alliance, there is norestriction on an organisation taking on both roles and be aresource provider and requester if desired. Then, the Alliancestructure can also be used to form supply chains of Grid resourcesproviders, e.g. as shown in Fig. 1, where an organisation mayexhibit both task satisfying and task formulating behaviour. Asthere is also no restriction on how the organisations taking eitherrole are implemented or represented, Alliances can be betweenGrid workflows maps naturally onto this model, especially so if theworkflows are to be enacted in a Service Oriented Architecture.

onseen that these problems are different views of the same problem.An important part of the complexity of Grid computing is that weare required to cross administrative boundaries at both requesterand provider level. Requesters may be bound together by thestructure of a scientific project subject to rules laid down both bythe funding body and also by their own (different) institutions.Providers of resources, such as computing centres, laboratories,and data providers, also have constraints at the funding body andinstitutional level.

To solve this problem (at both requester and provider level)we require a security architecture to restrict the access ofentities to resources. This architecture is devised abstractly sothat it may be implemented in different ways according to therequirements of given projects or situations. In this way, wecan avoid overprescribing the working practices of researchers,for example by insisting that they obtain and work with digitalcertificates as the only allowable security token.

One way of enforcing access restrictions is to specify whichindividuals are allowed which permissions on a resource bymeans of an access control list (ACL). The ACL for a resourcecontains access control entries (ACEs) for individual users thatspecify permissions in the form of who can carry out what. Thismethod is similar to the Globus grid-map file, which has beenshown not to scale as the number of resources grows becausethe management overhead of the ACL/ACEs is proportional to the

proportional to P I to proportional to P+ I) and avoids the directmapping of individuals to permissions.

Thus, RBAC has the advantage that the administration of theuser-to-role assignment and role-to-permission assignment can besplit. A human resources department may administer the formerrelationship and system administrators maintain the latter. Then,when individuals change their status we merely have to changetheir role to grant them the appropriate privileges to informationand resources they may require. In an organisation of many(i.e. thousands of) users and resources this eases the administrativeburden from the system administrator.

3.3. Local roles in an alliance

Using RBAC as an access control model, a requirement from theuse case is that access should be granted to individual functions ofthe Grid resource. Thus, access at the operation level is necessaryin order to support RBAC as, without the ability to support access(i.e. authorisation) decisions at this level, the only option is togrant or deny access to a whole resource. Therefore the designof the security model for the Alliance architecture has a simplestarting point, shown in Fig. 2, i.e. all requests to create a resourceor manipulate a resource in the resource providing organisationare carried out through one or more operations. For example, if theresource is a file the operations may be read, write and delete. ToJ.M. Brooke, M.S. Parkin / Future Generati

Fig. 1. Alliances acti

3. Role-based security in the Alliance

3.1. Abstract security architecture

As discussed in Section 2, it is essential that access to Gridresources is controlled both at the resource requester and providerlevel. An example of the importance of this control at the requesterlevel is to prevent a single member of the collaboration from usingall of the resources allocated (perhaps in the form of a grant)thus preventing any further investigation by the collaborationas a whole. An example at the provider level is to prevent anunauthorised user from using resource that had been allocated toa Principal Investigator of some project or collaboration. It can benumber of permissions (P) multiplied by the number of individuals(I) [20].n Computer Systems 26 (2010) 521530 523

g as a supply chain.

3.2. Role based access control

A more convenient method of controlling access is to add ACEsthat give permissions to groups of users. We then assert thatmembership of these groups is defined through the function, orrole, of each individual within an organisation. By assigning aset of permissions to these roles we achieve role-based accesscontrol (RBAC) [21]. A full discussion of RBAC is outside the scopeof this paper but, as [20] describes, RBAC reduces the overheadin managing security permissions from being proportional to thenumber of permissions multiplied by the number of individuals asdescribed above, to being proportional to the sum of the numberof permissions and the number of individuals (i.e. from beingrestrict access to an operation a role, or group of entities that havesome capacity, is associated with it, and a resource has as many

o524 J.M. Brooke, M.S. Parkin / Future Generati

Fig. 2. A resource, its operations and local roles.

local roles as it has operations, as shown in the multiplicities inFig. 2. This role is defined in this work as a local role as it is withinthe boundaries of the resource, and it contains a set of entitiesauthorised to carry out that operation; therefore, an entity requestsan operation: if they are a member of the local role associated withthat operation they are allowed access and the operation is carriedout. If the requester is not a member of the local role then accessto the operation is denied.

3.4. Global roles in the alliance

However, this simple model is similar to the ACL/ACE arrange-ment that, as discussed above, is not scalable as the resourceprovider has to add and remove entities to and from the localroles. To remove the burden of administration from the resourceprovider we can specify that requesting entities are added toresource-independent global roles, or roles that exist outside of theresource providers administrative domain and within the resourcerequesting organisation. For example, these global roles might bethe PhD students of Professor X, Laboratory Technicians at In-stitute Y or Computational chemists in Project Z roles as they areindependent of resource provision and can be used globally acrossresource providers.

A reference to the global role is added to the local role onthe resource (e.g. Computational chemists in Project Z mightbe mapped to a files read operation) and many of these globalrole references can exist inside a local role. Requesting entities(e.g. people and other entities, such as services and softwareagents) are added to the global role in the requesting organisation.This is shown in Fig. 3. Now, if a requester attempts to carry outan operation (as indicated by the dashed line from requester to theoperation in Fig. 3) the resource first checks the local role, finds areference to a global role and consults that role to find out if therequester is a member. This sequence is illustrated in Fig. 4. If therequester is found, the resource allows access to the operation; ifnot, then access is denied.

3.5. Roles in a particular example

To ground the discussion in a concrete example we describe

a group of computational chemists in distributed locationsand using distributed computing resources. They would like ton Computer Systems 26 (2010) 521530

Fig. 3. The abstract security architecture.

spontaneously form short-lived collaborations to perform what-ifexperiments using high-performance computer resources. Theseexperiments may be unplanned and exist for relatively shortperiods of time, making overheads in installing and configuring aVO using VOMS and CAS or joining an existing VO, as described,potentially unfeasible. This example is based on a number ofactual collaborations initiated in the Reality Grid project.1 Thesecollaborations have produced ground-breaking science, winningfour international awards at supercomputing conferences. Furtherexamples are described in [22].

The chemists are steering a computational simulation, whichequates to the resource concept in Fig. 3. One of the operationson that simulation may be update temperature, which has acorresponding local role. This local role has a reference to a groupof users the global role in the resource requesting organisation.Thus, when a chemist attempts to access the update temperatureoperation they must be a member of the global role in order forthat request to succeed and the temperature to be updated.

This architecture fulfils our requirement to be token-agnosticand maintains the separation of the resource requesting andresource providing entities. Because it is independent of thesecurity token used to gain authorisation, any credential can beused within this architecture, meaning lightweight and flexibleauthorisation can be achieved and lightweight clients can beinvolved within the collaboration. Furthermore, because we havenot prescribed how the global groups should be implemented,except that they should be collections of entities, hierarchicalglobal groups can be formed by adding entries to other globalgroups within other global groups, for example. This architecturehas been tested in a concrete implementation using the WSRF::Litemiddleware [23]. We have also presented protocols that will allowresources to be booked by requester collaborations accordingto legally binding contracts using protocols based on ContractLaw [24,25]. Thus the abstract architecture can be implementedvia real and practical methods.1 http://www.realitygrid.org.

omultiple implementations; thus we can meet the objections thatGrid middleware requires freezing versions of libraries and hostingenvironments (see the discussion in Section 1). Thirdly it allowsus to reason across different Grid systems, to determine commonprocesses and functionality that can be expressed in differentterminology. In previous work this ontological approach has beenapplied to the problem of brokering for resources across differentGrid systems [27]. We now apply this approach to the forming ofan Alliance.

The Grid ontology is modular, building on a foundationalontology that represents processes on a Grid in their mostabstract from. This foundational ontology can be extended toinclude the constructs being developed in OGSA and specialisedfurther to specific Grid systems such as GT4 or Unicore. Thismodular ontology is encoded in the Web Ontology LanguageOWL and is freely available via the web.2 We now extend thefoundational ontology in a different way, to represent the resourcerequesting organisations structure and the entities (includingnon-human entities, such as devices, agents and services). It isenvisaged that template ontologies like the one presented here, butwhich describe different organisational structures, could be madeavailable, taken off-the-shelf as required by short-term projects

structure that it most appropriate for their needs, because, as longas the global role definitions are consistent with the organisationalstructure, the organisational structure can be defined in any wayas long as the definition is consistent with the rules of descriptionlogic. A final advantage of the ability to import ontologies intoone another is that organisations can be combined through themapping of common concepts within their respective ontologies.Thus, if two existing organisations wanted to collaborate, themapping can be performed through a third ontology for theduration of the collaboration.

4.2. Global role ontologies

We recall from Section 3 that the global roles are those of theresource requester organisation. They get mapped onto local rolesat the resource provider level, and thus are global since they existacross the many resources and resource providers used by thecollaboration. As shown in Fig. 5, the ontologies describing globalroles extend the resource requesting organisations ontology, andare termed restrictions on that ontology as, when an OWL reasoneris passed over a global role ontology, the instances within theresource requesting organisation ontology that have the necessaryand sufficient criteria to be an instance of that concept arereturned. Note that this is a slightly different way of determiningJ.M. Brooke, M.S. Parkin / Future Generati

Fig. 4. Sequence diagram

4. Knowledge for the Alliance

4.1. Development of a Grid ontology

The concept of Grid middleware originally arose to hide theheterogeneity at both the resource and the application level. TheGrid middleware was envisaged as a simple set of tools andprotocols connecting both, the so-called hourglass model [1].However, a proliferation of Grid middleware (a partial list includesGlobus, Unicore, gLite, CROWN, OMII-UK, NAREGI) means that theheterogeneity at the middleware layer is approaching the level ofheterogeneity it is attempting to hide. In previous work we havedescribed an approach to this problem based on modelling theprocesses of Grid computing using ontologies [26]. This approachhas several advantages. Firstly it allows our knowledge of buildingGrids to grow with experience. Secondly it can be mapped to2 http://www.unigrids.org/ontology.n Computer Systems 26 (2010) 521530 525

of authorisation process.

and completed as required so the rapid deployment of a resourcerequesting organisation can take place.

In this implementation separate ontologies have been writtenthat describe the global roles, i.e. resource-provider independentgroups of resource requesters allowed to carry out some function,as introduced in Section 3. These global role ontologies import theresource requesting organisations ontology, which in turn importsthe Grid foundational ontology (described in [26]). The modularapproach, shown in Fig. 5, has been taken as it allows for easiermaintenance and administration as new global roles can be createdwithout having to modify the information contained in the mainresource requesting organisation ontology.

As a result, this modular, composable, ontology-based approachis extremely flexible as the organisational structures structure canbe changed through standard ontology editors, such as Protg [28]or Swoop [29]. This model also allows each organisation to define arole membership; a role is usually a container to which entitiesare added in order to become a member. However, in this case,

oFig. 5. The resource requesting organisations ontologies.

members are not explicitly added to a role but they becomemembers of that role through their properties matching those inthe role definition and being an instance of that concept.

The real benefit of this is that the role members can beinferred from knowledge contained in the resource requestingorganisations ontology. These results are used to determine if anentity requesting access to computational resources is a memberof a global role and an authorisation decision performed. Thisis, therefore, an extremely lightweight method of providing anRBAC infrastructure that captures knowledge about the roles,information that is usually tacit within an organisation, and makesit explicit through the role definition. This design can also providehierarchical RBAC by extending existing roles, e.g. as shown inFig. 5, global role D is an extension of global role A as it importsthe ontology defining global role A.

We take a concrete example of this by examining a scientificcollaboration that has existed since 2001, namely the RealityGridconsortium. This is more that a single project since many projectshave been funded to develop the working methodologies of

Fig. 6. Definition of a RealityGrid project member employed by ManchesterUniversity in the Protg editor.526 J.M. Brooke, M.S. Parkin / Future GeneratiRealityGrid. Thus it is an example of the sort of collaborationthat the UK e-Science programme has fostered. The global rolen Computer Systems 26 (2010) 521530definition for a RealityGrid person employed by ManchesterUniversity and not blacklisted is shown in Fig. 6, and the class

oproperty an individual in the global role must have in order thatthe security token can be linked to the individual. For example,if the security token being presented were an Jabber id, theproperty would be the URI of the hasjabberId property,whereas if the security tokens were an X.509 subject, thevalue would be the URI to the hasSubject property in thefoundational ontology.

requirements for an implementation: one, to integrate withexisting Grid middleware products and standards, such as WSRF,and use standard libraries and components wherever possible;two, to allow the Grid resource to be accessible using a varietyof authenticated security tokens in order that requesting clientsthat cannot support X.509 certificates may interact with the Gridresource; three, to be accessible to lightweight clients, i.e. to thoseclients that do not have the capability to run a heavyweight SOAP-J.M. Brooke, M.S. Parkin / Future Generati

Fig. 7. Class axiom of RAs o

axiom for the definition of RealityGrid project members who havebeen asserted to be RAs or managers is given in Fig. 7.

This example shows many of the points we consider important.Since the collaboration is multi-institutional we need to knowabout the institutions since members of an institution mayhave rights to certain resources not available to the RealityGridcollaboration as a whole. The multiple inheritance from theclass Blacklist allows an elegant method of revocation whichcan be easily changed without affecting all the other complexproperties of a resource requesting entity. Multiple inheritance isa useful concept which is difficult to implement in programminglanguages; thus we can see how ontologies are useful forrepresenting complex concepts which cannot be programmed inconventional languages.

4.3. Implementation over the network

The inference of global role members in the previous sectionused the internal reasoner of the Protg ontology editor. Whilstthis is sufficient for proving the concepts behind the design andoperation of the ontologies, in a networked environment this is oflittle use as the results are not available outside of the local Protgeditor. Thus, this section presents a service that implements anauthorisation protocol described in [22] to allow the inference ofglobal role membership across a network to provide authorisationdecisions. This type of authorisation service is called a reasoningauthorisation service.

The implementation of the reasoning authorisation servicesupports a request-response authorisation protocol [22]. Theservice consists of a lightweight Java servlet hosted in a Jetty HTTPcontainer [30] that wraps a single Java class which takes fourpieces of information necessary to make an authorisation decision(and encoded in the URL query sent to the authorisation service,i.e. the AuthRequest message) using the Pellet OWL-DL reasoninglibraries [31]. This Java class (called OWLQuery) is implementedso that the four parameters required for the OWLQuery class tomake an authorisation decision are:

(1) The security token presented to and authenticated by the Gridresource. For example, these could be an X.509 certificatesubject of the form /C=UK/O=eScience/.../CN=john_smith a Jabber id of the form johnsmith@jabber.org,or an OpenID URL in the form johnsmith.pip.example.com.3

(2) The type of security token presented. In the case of thereasoning authorisation service, this parameter is a URI to the3 Where PIP is an OpenID Personal Identity Provider.n Computer Systems 26 (2010) 521530 527

r Managers in RealityGrid.

(3) The global role. For the reasoning service to operate, this mustbe the URI of the definition of the concept in the global roleontology, e.g. http://.../reg_person_in_manchester.owl#ReG_Person_in_Manchester tells the reasoner the physical locationof the ontology (everything to the left of the hash symbol) andthe class that is being inferred (the fragment to the right of thehash symbol).

(4) The name of the blacklisted group. As with the global group,this must be the URI of the blacklisted entity concept. Inthe example ontology described above, this is http://.../rr_organization_1.4.owl#Blacklisted_Entity. Again, everything tothe left of the hash symbol tells the reasoner the physicallocation of the OWL ontology, whilst the URI fragment after thehash symbol tells the reasoner the concept definition withinthe ontology.

Thus, this ontological solution can be fully realised overnetworks using standard HTTP protocols. All of its componentsare lightweight and easily built, and the ontology editors allowfor rapid prototyping on a single system before deployment.Essentially the same type of reasoning engines work in bothcases (local and networked). They are moreover highly scalable.For example, the RACER DL-reasoner has been shown to scale toreason over ABoxes (a technical feature of the Description Logicunderlying the reasoner) containing over 100,000 assertions [32].

5. Resource providing organisation

5.1. Requirements at provider level

Part of the responsibilities of the organisation playing the roleof the resource provider is to host the Grid resources that theresource requesting organisation will access. Once a contract toaccess the resources has been negotiated and the resources createdor configured for access, these WS-Resources are accessed byentities in the resource requesting organisation attempting to carryout operations allowed by that resource. The resource provider is,therefore, responsible for supplying a resource that authenticatesthe credentials presented by an entity that has requested tocarry out an operation on the resource. The resource must thencreate the AuthRequest message of the authorisation protocol,send it to the authorisation service, interpret the authorisationdecision message returned in the response and, if the requester isauthorised, execute the operation.

Our previous analysis in Section 1 has identified the followingbased application; and, four, to provide a resource that carries outRBAC.

o528 J.M. Brooke, M.S. Parkin / Future Generati

5.2. Implementing alliance-enabled WS-resources

To illustrate our ideas we need to represent resources withinthe resource providing organisation. We chose the WSRF::Lite [33]implementation of the Web Service Resource Framework (WSRF)[34] to give resource requesters access to Grid applications, serviceand devices, virtualised as WS-Resources. As its name suggests,WSRF::Lite has the advantage over other WSRF implementations,such as the Globus Toolkit v4.0 [35] and Apache WSRF [36], ofbeing extremely lightweight and is supported on most (if notall) platforms as it can be hosted wherever Perl can be installed.WSRF::Lite is mature (as it was first released in 2003), stable,4scalable, supports dynamic service deployment (i.e. new servicescan be deployed without restarting the container) and, in the eventof the container failing, allows the persistence of the WS-Resourcesit is hosting. Additionally, as Perl is an excellent glue language,it is easy to interface the WSRF::Lite container with low-levelsystem software and legacy code written in languages such as Cand Fortran and has been used extensively (and successfully) forthis purpose in the UK e-Science RealityGrid project.

However, in order for the WS-Resources hosted in a WSRF::Litecontainer to meet the requirement of the Alliance model ofrestricting access to resources at the operation level, the containerhas to be extended to provide RBAC. The methods and a fulldescription of the code used to restrict access to each WS-Resourceoperation are described in full in [23]. In summary, the techniquesdescribed in that work provide the RBAC function by interceptingcalls to WS-Resource operations using Perls method dispatchingcapability. Each operation is associated with a local role that ismapped to a global role as described in Section 3. The methoddispatching technique is specific to the Perl programming languageand, as a consequence, WSRF::Lite, as it is the only WS-Resourcecontainer written in Perl. However, method dispatching like thisprovides a function similar to what Aspect Oriented SoftwareDevelopment (AOSD) techniques provide. Thus AOSD could beused on other non-Perl WS-Resource containers (e.g. the Globusor Apache implementations, which are both written in Java) toprovide a similar RBAC function.

What is most important about the design and techniquesused to extend the WSRF::Lite container to provide RBAC at theoperation level is that this solution does not modify the maincontainer code or the WS-Resource code (i.e. the virtualisation ofthe application, device or service). That is, the extensions havebeen developed in a non-intrusive manner that does not toucheither the main body of WSRF::Lite code or the application code(i.e. the WS-Resource virtualisation of an underlying resource).This approach has three significant advantages: one, by notmodifying the WSRF::Lite container code or creating a fork tosupport RBAC, the OMII-UK maintained WSRF::Lite code can beused and, thus, a system administrator can run the same, centrallymaintained WSRF::Lite code across all their resources; two, bynot modifying the application code the developers of the WS-Resource code do not have to modify their code just to enableRBAC; three, the same WS-Resource code can be run in an instanceof a WSRF::Lite container with or without RBAC, thus reducing thesystem administration overhead.

5.3. Supporting lightweight clients in WSRF::Lite

A requirement of the Grid resources provided to the resourcerequesting organisation is that they are accessible to lightweightclients. As described above, the authorisation extensions have4 WSRF::Lite is an Open Middleware Infrastructure Institute UK (OMII-UK)managed project.n Computer Systems 26 (2010) 521530

been designed in such a way that they are agnostic to thesecurity tokens presented to the WSRF::Lite container. Thus, aslong as the resource requesting organisation authenticates thesecurity token presented the RBAC extensions will take thatcredential and pass it to the authorisation service together withthe necessary parameters to make an authorisation decision. Bybeing agnostic to the type of token used the design allows clientswhich are lightweight and cannot support some types of securitytokens (e.g. VOMS proxy certificates) to access the Grid resourcesthe resource requesting organisation has negotiated access to.The second reason why lightweight clients are excluded fromparticipating in the Grid is that they often cannot support a SOAPstack to send messages to a Web Service-based container hostingWS-Resources and interpret the responses. WSRF::Lite allows theintegration of lightweight clients by implementing two featuresthat other WS-Resource containers do not. First, it only usesthe address parameter of the WS-Addressing end-point reference(EPR) that identifies a WS-Resource; thus the EPR of a resourcecan be used as a URL since there is a direct one-to-one mappingbetween them, and a WS-Addressing header is not requiredin the messages sent to the container. Secondly, WSRF::Litehas mapped certain HTTP methods onto WSRF operations;i.e. WSRF::Lite maps an HTTP GET method onto the WS-Resource GetResourcePropertyDocument operation, theHTTP PUTmethod onto the PutResourcePropertyDocumentand the HTTP DELETE method onto the WS-Resources Destroyoperation.5 This simple binding of the WS-Resources operationsto HTTP means the container can be used without a SOAP stack,thus allowing devices that may only be able to support HTTP,such as lightweight devices, to interact with the WS-Resourcehosted by WSRF::Lite. This has been illustrated in [37], which usedthe WSRF::Lite container to create a dynamic web-based AJAXinterface to Grid resources that were also accessible by traditional,heavyweight SOAP clients at the same time.

Thus, the WSRF::Lite implementation, whilst supporting theWeb Service standards necessary to host standard WS-Resources,has been bold in recognising and asserting that Web Services areusually, if not exclusively, accessed via HTTP and binding WS-Resource/WSRF operations to that application protocol. As a result,WSRF::Lite Grid resources are on the web and are accessible bystandard web browsers and lightweight HTTP clients as well asbespoke Web Service clients. It is hoped that other Grid containerdevelopers take the lead shown by WSRF::Lites adoption of boththe Web Services and the web as it increases the pervasivenessof Grid computing generally. In the context of the Alliance model,WSRF::Lites behaviour allows lightweight clients, such as mobiletelephones that do not have a bespoke Web Services client installedbut do have a web browser installed, to access Grid resources. Also,the same client (i.e. the browser) has the potential to access Gridresources across resource providers, and they are able to switchbetween resource providers another requirement of the Alliancemodel as described in Section 2.

6. Conclusions and future work

We have introduced the concept of an Alliance as an extensionto the general concept of Virtual Organisations in distributedcomputing. This has resulted in our analysis of the requirementsnecessary to provide access to Grid resources to dynamicallycreated collaborations of scientists. We based the Alliance on aseparation of the process of forming the scientific collaboration(the resource requesters) from the process of integrating access5 WSRF::Lite does not, at the time of writing, implement a mapping between theHTTP POST method and the WSRF UpdateResourceProperties operation.

oJ.M. Brooke, M.S. Parkin / Future Generati

to resources via the Grid (the resource providers). We foundsubsequently that such a conceptual distinction already existedin organisational science, namely task formers and task satisfiers.This provides a valuable connection between current research intoGrids and a well-established body of research. It also provides alink between the study of Grids for scientific use with the study ofGrids for business.

Once this conceptual basis is clarified it then becomes possibleto make use of the large amount of technology developed fordistributed computing without having to reinvent it. As anexample, Role Based Access Control is a well-developed andunderstood tool for providing access to resources. Our Alliancefocus allows us to distinguish between the local roles at theresource provider end and the global roles of the scientists inthe collaboration. These can now be easily changed independentlyof each other, avoiding the highly burdensome task of havingto install user details and roles across all of the resourceswhich could potentially be used in a given collaboration. Italso facilitates dynamic switching between resource providers,allowing competition to increase choice and stimulate efficienciesof resource provision.

We have also been able to integrate technology from theSemantic Web, namely the Web Ontology Language (OWL) andthe tools provided to support reasoning across ontologies. Modularontologies have been created based on an ancestral FoundationOntology that expresses the process involved in access distributedresources. This is at a sufficiently abstract level that it can bespecialised either to different Grid middleware systems or to thestructure of different forms of scientific collaboration. This meansthat the process of forming such structures can be increasinglyautomated since the Alliance structure can be created from asufficiently precise description of the collaboration.

Our approach is independent of the manner of implementation.In this way Alliance structures can be implemented by a varietyof tools. We have illustrated this by showing how the WSRFstandard can be used to create the provider organisation for theAlliance. We have implemented this using lightweight tools suchas WSRF::Lite and a Jetty web server. We show how this can allowthe easy integration of lightweight clients providing a access to themembers of the resource requesting organisation. However, otherimplementations are possible. The tools for creating Alliancescould be integrated into middleware stacks (e.g. Globus, gLite,Unicore) with relative ease since they are based on the standardsbeing developed in the Open Grid Forum.

We stress that our work should be seen as complementary tocurrent work on Virtual Organisation for Grid computing, such asVOMS. In very large and long lived collaborations, such as thosebeing developed around the Large Hadron Collider, these have theadvantage of robustness, durability and scalability. However, formore transient collaborations, which we believe are characteristicof a very broad spectrum of scientific collaborations, they areoverkill. Our work is also directed towards the development ofeconomically based Grids. We have described elsewhere how wehave based the negotiation necessary to provide resources to theAlliance on the principles of contract law. Thus Grid computing cancome inside the standard legal framework governing exchange ofgoods and services in society.

In future work we intend to describe the implementation ofAlliances for different types of scientific collaborations to gainexperience of their strengths and weaknesses. This work willalso refine the ontologies and protocols used to create Alliances.Some promising areas are collaborations to steer very largecomputational simulations, virtual prototyping in engineeringand design and scientific mash-ups using Web 2.0 technology.

Increasingly, scientists will be familiar with social networking viathe internet. This is why we stress the importance of trying ton Computer Systems 26 (2010) 521530 529

develop in a WWW-friendly style of working, by using HTTP as theprotocol of choice, for example.

Finally we comment briefly on our use of the terms Grid,Virtual Organisation and Alliance. We see the term Grid as referringto a form of distributed computing designed to give uniformaccess to resources, hiding the heterogeneity of the underlyinginfrastructure. A Virtual Organisation is a type of organisationalstructure that can provide access mechanisms to such resources.An Alliance is a different type of structure to provide access tosuch resources based on a much looser coupling of the requesterand provider organisations. Both a VO and an Alliance may use thesame underlying infrastructure via Grid methods. However, fromthe point of view of the users of the Grid resources, the experiencesof joining a VO and an Alliance will be very different.

Acknowledgements

Michael Parkins work was supported by a RealityGrid DTAstudentship funded by EPSRC (GR/R67699).

References

[1] I. Foster, C. Kesselman, S. Tuecke, The anatomy of the grid: Enabling scalablevirtual organizations, International Journal of Supercomputer Applications 15(3) (2001) 200222.

[2] T. Hey, e-Science and cyberinfrastructure: A middleware perspective, in:Proceedings of the 15th International Conference on World Wide Web,International World Wide Web Conference, 2006, pp. 245245.

[3] J. Chin, P. Coveney, Towards tractable toolkits for the grid: A plea forlightweight, usable middleware, Tech. Rep. UKeS-2004-01, UK e-ScienceTechnical Report Series, 2004.

[4] B. Beckles, P. Coveney, P. Ryan, A. Abdallah, S. Pickles, J. Brooke, M. McKeown,A user-friendly approach to computational grid security, in: S. Cox (Ed.),Proceedings of the UK e-Science All Hands Meeting 2006, 2006.

[5] EGEE Global Security Architecture, Deliverable EGEE-JRA3-TEC-487004-DJRA3.1-v-1-1, Enabling Grids for E-sciencE (EGEE) Project, September 2004.

[6] B. Matthews, J. Bicarregui, T. Dimitrakos, Building trust on the GRID: Trustissues underpinning scalable virtual organisations, in: ERCIM Workshop TheRole of Trust in e-Business in Conjunction with IFIP I3E Conference, 2001.

[7] N. Tuptuk, E. Lupu, (Eds.), State of the Art Evaluation Phase 1, DeliverableSOA-D2-Issue1, TrustCOM (IST-2002-2.3.1.9), June 2004.

[8] P. Alper, O. Corcho, M. Parkin, I. Kotsiopoulos, P. Missier, S. Bechhofer, C. Goble,An authorisation scenario for S-OGSA, in: Proceedings of Posters and Demos,3rd European Semantic Web Conference, ESWC06, 2006, pp. 78.

[9] Next Generation Grids Expert Group Report 3, Future for European Grids:GRIDs and Service Oriented Knowledge Utilities: Vision and ResearchDirections 2010 and Beyond, European Commission, 2006. ftp://ftp.cordis.lu/pub/ist/docs/grids/ngg3_eg_final.pdf (Last accessed 30.05.07).

[10] J. Brooke, D. Fellows, J. MacLaren, Interoperability of resource descriptionacross grid domain boundaries, in: P. Neittaanmki, T. Rossi, S. Korotov,E. Oate, J. Priaux, D. Knrzer (Eds.), European Congress on ComputationalModels in Applied Sciences and Engineering, ECCOMAS 2004, 2004.

[11] M. Parkin, J. Brooke, A PDA client for the computational grid, Special Edition ofConcurrency and Computation: Practice and Experience: Second InternationalWorkshop on Emerging Technologies for Next-generation GRID, ETNGRID2005.

[12] J. Yan, R. Kowalczyk, J. Lin, M.B. Chhetri, S.K. Goh, J. Zhang, Autonomousservice level agreement negotiation for service composition provision, FutureGeneration Computer Systems 23 (6) (2007) 748759.

[13] R. Alfieri, R. Cecchini, V. Ciaschini, F. Spataro, L. dellAgnello, A. Frohner,K. Lrentey, From gridmap-file to VOMS: Managing authorization in a gridenvironment, Future Generation Computer Systems 21 (4) (2005) 549558.

[14] A. Mowshowitz, Virtual organization, Communications of the ACM 40 (9)(1997) 3037.

[15] T. Malone, Organizational structure and information technology: Elements ofa formal theory, Tech. Rep. CISR WP No. 130; 90s WP No. 85-110, Center forInformation Systems Research, Sloan School of Management, MassachusettsInstitute of Technology, August 1985.

[16] R. Bradt, Virtual organizations: A simple taxonomy, Tech. Rep. InfoThink.com,1998.

[17] C. Goble, e-science is me-science: What do scientists want, Keynote speechto EGEE 06. http://www.gridtoday.com/grid/963514.html, September 2006.

[18] H. Lucas Jr., J. Baroudi, The role of information technology in organizationdesigns, Journal of Management Information Systems 10 (4) (1994) 915.

[19] R. Syler, P. Schwager, Virtual organization as a source of competitiveadvantage: A framework for the resource-based view, in: Proceedings of theAmericas Conference on Information Systems, AMCIS2000, 2000.

[20] D. Ferraiolo, J. Barkley, D. Kuhn, A role-based access control model and

reference implementation within a corporate intranet, ACM Transactions onInformation and System Security 2 (1) (1999) 3464.

o530 J.M. Brooke, M.S. Parkin / Future Generati

[21] R. Sandhu, E. Coyne, H. Feinstein, C. Youman, Role-based access control models,Computer 29 (2) (1996) 3847.

[22] M. Parkin, Lightweight client organisations for the computational grid, Ph.D.Thesis, School of Computing, University of Manchester, February 2008.

[23] M. Parkin, B. Harbulot, J. Brooke, Non-intrusive, flexible, role-based authoriza-tion extensions for WSRF::lite, in: S. Cox (Ed.), Proceedings of the UK e-ScienceAll Hands Meeting 2007, 2007, ISBN: 978-0-9553988-3-4, pp. 270277.

[24] D. Kuo, M. Parkin, J. Brooke, Negotiating contracts on the grid, in:P. Cunningham, M. Cunningham (Eds.), Proceedings of the 4th eChallengesConference: Exploiting the Knowledge Economy: Issues, Applications and CaseStudies, 2006, pp. 6066.

[25] M. Parkin, D. Kuo, J. Brooke, A framework & negotiation protocol forservice contracts, in: L. OConner (Ed.), Proceedings of the 2006 InternationalConference on Services Computing, SCC06, 2006, pp. 253256.

[26] M. Parkin, S. van den Burghe, O. Corcho, D. Snelling, J. Brooke, The knowledge ofthe grid: A grid ontology, in: M. Bubak, M. Turala, K. Wiatr (Eds.), Proceedingsof the 6th Karkow Grid Workshop, 2006, pp. 111118.

[27] J. Brooke, D. Fellows, K. Garwood, C. Goble, Semantic matching of grid resourcein grid computing, in: M. Dikaiakos (Ed.), Proceedings of the Second EuropeanAcross Grids Conference, AXGrids 2004, in: LNCS, vol. 3165, Springer, 2004,pp. 240249.

[28] M. Horridge, D. Tsarkov, T. Redmond, Supporting early adoption of OWL 1.1with Protg-OWL and FaCT++, in: B. Cuenca Grau, P. Hitzler, C. Shankey,E. Wallace (Eds.), Proceedings of the OWL Experiences and Directions Work-shop, 2007. http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-216/submission_15.pdf (Last accessed 30.05.07).

[29] A. Kalyanpur, B. Parsia, E. Sirin, B. Cuenca Grau, J. Hendler, SWOOP: A webontology editing browser, Journal of Web Semantics 4 (2) (2006) 144153.

[30] Mort Bay Consulting, Jetty: An open-source, standards-based, full-featuredweb server. http://www.mortbay.org/ (Last accessed 30.05.07) (December2006).

[31] E. Sirin, B. Parsia, B. Cuenca Graua, A. Kalyanpur, Y. Katza, Pellet: A practicalOWL-DL reasoner, Journal of Web Semantics 5 (2) (2007) 5153.

[32] V. Haarslev, R. Mller, High performance reasoning with very large knowledgebases: A practical case study, in: B. Nebel (Ed.), Proceedings of the SeventeenthInternational JointConference on Artificial Intelligence, IJCAI 2001, 2001, pp.161168.

[33] WSRF Lite - An Implementation of the Web Services Resource Frame-work, Manchester computing, supercomputing, visualization & e-science cen-tre. http://www.sve.man.ac.uk/Research/AtoZ/ILCT (Last accessed 30.05.07),2007.n Computer Systems 26 (2010) 521530

[34] I. Foster, J. Frey, S. Graham, S. Tueke, K. Czajkowski, D. Ferguson, F. Leymann,M. Nally, I. Sedukhin, D. Snelling, T. Storey, W. Vambenepe, S. Weerawarana,Modelling stateful resources with web services, v1.1. http://www.ibm.com/developerworks/library/ws-resource/ws-modelingresources.pdf (Lastaccessed 30.05.07), May 2004.

[35] I. Foster, Globus toolkit version 4: Software for service-oriented systems,in: H. Jin, D. Reed, W. Jiang (Eds.), Proceedings of the IFIP InternationalConference on Network and Parallel Computing, in: LNCS, vol. 3779, Springer,2005, pp. 213.

[36] Apache WSRF, Apache web services project. http://ws.apache.org/wsrf/ (Lastaccessed 30.05.07), 2007.

[37] A. Sen, J. Brooke, B. Harbulot, M. McKeown, S. Pickles, A. Porter, CombiningAJAX and WSRF for Web-browser based Grid clients, in: Proceedings of the2nd International Workshop on Grid Computing Environments, GCE06, 2006.

JohnM. Brooke obtained a Ph.D. in Mathematics from theUniversity of Manchester in 1997. He then worked in theHPC group and led the Applications Team on the UK CSARSupercomputing Service until 2001 when he became co-Director of the UK North-West e-Science Centre (ESNW).He has worked on large UK computational projects suchas RealityGrid and on a series of EU projects developingthe UNICORE middleware. His research interests arein distributed computing, computational science anddynamical systems.

Michael S. Parkins first degree is in Physics. Aftergraduation he worked on computational models of cloudsin the Atmospheric Physics Group at UMIST for 18months before starting a 7-year career as an InfrastructureEngineer/Architect, as a consultant to leading investmentbanks in London, New York and Paris. Returning toacademic life at the University of Manchester in 2002,Michael has recently submitted a Ph.D. on LightweightClient Architectures for the Computational Grid. He iscurrently working as a CoreGrid Fellow at BarcelonaSupercomputing Centre.

Enabling scientific collaboration on the GridIntroductionThe AllianceInsights from the science of organisationsApplication to Grid computing

Role-based security in the AllianceAbstract security architectureRole based access controlLocal roles in an allianceGlobal roles in the allianceRoles in a particular example

Knowledge for the AllianceDevelopment of a Grid ontologyGlobal role ontologiesImplementation over the network

Resource providing organisationRequirements at provider levelImplementing alliance-enabled WS-resourcesSupporting lightweight clients in WSRF::Lite

Conclusions and future workAcknowledgementsReferences