Tài liệu Grid Computing P29 pptx

29
Unicore and the Open Grid
Services Architecture
David Snelling
Fujitsu Laboratories of Europe, Hayes, Middlesex, United Kingdom
29.1 INTRODUCTION
This chapter describes a GridService demonstrator built around the Unicore Grid envi-
ronment, its architectural design and implementation [1]. It then examines some lessons
learned from the process of developing an implementation of a family of GridServices
that conforms to the Open Grid Services Architecture (OGSA) [2] and the Grid Service
Specification [3].
The goals of this project were two fold. Primarily, it is only through implementation
that complexities such as those that arise in OGSA can be fully understood and analyzed.
Secondly, Unicore (www.unicore.org) is a complete production Grid environment that
seemed to conform extremely well to the OGSA. The author wanted to test this hypothesis
and see how difficult it would be to construct an OGSA-hosting environment on top of
the Unicore infrastructure.
By way of a brief summary, both goals were met easily and with satisfaction. The
OGSA model is remarkably clean and the abstractions well matched to what is needed
at the implementation level. The lessons learned reveal where cracks exist and, in many
Grid Computing – Making the Global Infrastructure a Reality. Edited by F. Berman, A. Hey and G. Fox

2003 John Wiley & Sons, Ltd ISBN: 0-470-85319-0
702
DAVID SNELLING
cases, support the changes currently under discussion in the Open Grid Services Infras-
tructure (OGSI) working group of the Global Grid Forum (GGF). The reader should note
that this chapter and the implementation on which it is based are targeted at the first draft
(2/15/2002) of the Grid service specification [3]. By the time of going to the press, many
of the issues discussed here and elsewhere will have become part of the next version.
With respect to the second goal, the implementation of a complete OGSA GridService

environment that could be used to deploy task specific GridServices was significantly
easier than expected initially. The combination of the Unicore Grid infrastructure with
a flexible Web Services tooling environment (GLUE from www.themindelectric.com)
proved to be effective and easy to use.
29.1.1 Caveats
The implementation discussed here conforms to the OGSA model, but not to the speci-
fications as such. The specification is still under development and requires extensions to
the Web Services Definition Language (WSDL) [4]. It will be some time before tooling
platforms are available that support these extensions. Therefore, our approach has been
to develop the architecture described by OGSA, but to work within the constraints of
existing Web Services. The OGSA abstractions (serviceTypes in particular) are exposed
in Java implementation, and then merged into a ‘flat’ WSDL representation, as the var-
ious portTypes are aggregated into a single Web service. This restriction has very little
impact on our ability to meet the goals of this project. In fact, the extent to which this
project was possible within the Web Services framework raises questions about the need
for extensions, see Section 29.3.1 below.
29.2 IMPLEMENTATION
This section outlines the overall architecture and implementation of this GridService
demonstrator. On top of a ‘hosting environment’, the demonstrator supports a generalized,
distributed, application-steering GridService. This section also includes a summary of this
application-steering GridService.
29.2.1 Infrastructure and architecture
In ‘The Physiology of the Grid’ [2], Foster et al., describe a hosting environment
as follows:
In practice, Grid services are instantiated within a specific execution environment or
hosting environment. A particular hosting environment defines not only implementa-
tion programming model, programming language, development tools, and debugging
tools, but also how an implementation of a Grid service meets its obligation with
respect to Grid service semantics.
The platform component of this demonstrator fits easily into this definition; however,

the overall environment is more complex than this definition indicates, see Figure 29.1.
UNICORE AND THE OPEN GRID SERVICES ARCHITECTURE
703
Hosting environment
GridService platform
Client
GLUE server
Unicore servlet
Unicore server B
Computing
resource B
Unicore server A
Computing
resource A
http(s)+SOAP
UPL
SSL
Figure 29.1 Architecture of Unicore GridService hosting environment.
Implicit in the above definition, a hosting environment is based on a single programming
model/language; it implies that the GridService client interacts with a single ‘program’.
Although true of this demonstrator’s platform component (i.e. the client interacts with a
Java program constructed as described below), this simplification belies the complexity of
the Unicore infrastructure that interacts with the platform and the distributed computing
resources. The Unicore hosting environment supports applications written in a variety of
programming languages and run on many different computer architectures. Nonetheless,
the notion of Unicore deployed in this way is well described as a hosting environment.
This hosting environment is based on two primary building blocks, the Web Services
platform GLUE from The Mind Electric, (www.themindelectric.com) and the Unicore
server implementation developed by Fujitsu Laboratories of Europe for Unicore-related
projects (www.unicore.org). Both environments are freely available for downloading along

with the source code of this demonstrator.
1
All components are written in Java. Only a
small part of the Unicore environment requires Perl.
29.2.1.1 Client
The user accesses several GridServices from a single client application, linked with the
client side classes from GLUE. The client included in the demonstration download is
a crude, command line client supporting all the GridServices provided, for example,
Factory, Registry, HandleMap, a NotificationService, and various JobGridServices. More
realistic and user friendly clients could be written using any Web Service environment,
for example, .NET.
The client connects to the hosting environment’s platform component, via http or
https, with Simple Object Access Protocol (SOAP) bindings, as specified in the WSDL
1
Note the demonstrator download does not include the Unicore or GLUE infrastructure components. To experiment with this
demonstrator, the GLUE Web Services environment is required and must be obtained from The Mind Electric. A ‘DummyGrid-
Service’ is included in the demonstrator that does not require a complete Unicore Grid. This demonstrator will interact with
the demonstration Unicore Grid at (www.fz-juelich.de/unicore-test), which supports some of the demonstration applications.
704
DAVID SNELLING
sent from the platform. For https, a pair of certificates and the associated key stores are
required for the client and server. The use of an https binding automatically activates a
password-based authorization step. In the http mode, no user authentication is needed.
With the simple http binding, the ‘console’ supported by GLUE can be started (see
GLUE documentation for details). The console introspects the WSDL and generates
dynamic Web pages for most of the GridService operations. The exceptions are those
that return structured data types, which the simple console interface cannot introspect;
however, no fundamental barriers exist to automatic tooling within this GridService
environment.
29.2.1.2 Platform

On the server side, the GLUE Web Services server is integrated with a servlet pack-
age that supports the Unicore protocols. From the servlet, Unicore Abstract Job Objects
(AJOs) can be consigned to Unicore sites, monitored, controlled, and the results retrieved.
Within a Unicore Grid, this servlet can be used to construct lightweight clients. In this
implementation, the GridService package implements the basic OGSA portTypes and a
collection of JobGridServices. The servlet package manages the interaction between the
GridService package and the Unicore Grid. This servlet also manages Unicore security,
see section 29.2.1.4.
29.2.1.3 Unicore server
From the servlet, Unicore sites are contacted via the Unicore Protocols Layer (UPL).
The Unicore Server receives AJOs from Unicore clients, the GridService platform, and
other Unicore Servers. As the various workflow tasks of the AJO are processed, they
are converted from their abstract representation in the AJO to platform-specific forms by
Unicore mechanisms. All aspects of the Unicore Grid, including the AJO, are of course
hidden from the OGSA user. Further details of the Unicore side are not central to this
chapter. See Unicore download documentation and Reference [5] for more information.
29.2.1.4 Security framework
At the time of writing, the Grid Service Specification [3] only indicated that security
was a binding time property. As a result, there are two separate levels to the security
framework, one at the https binding between the client and the GridService platform and
another between the platform and the rest of the Unicore hosting environment.
Https is used to connect the client to the platform component of the GridService. The
use of https triggers the need for simple authentication using user names and passwords.
2
Once the https connection is established, a Unicore certificate, loaded by the servlet when
it starts up, is used to authenticate and authorize work by all users of the GridService. In
2
The user name/password step is redundant, given that the authentication can be taken from the https connection. However,
we chose to leave it in place, since the normal practice for an https connection assumes the use of a generic client certificate
(e.g. as supplied with most browsers) and a separate login to sites requiring authentication.

UNICORE AND THE OPEN GRID SERVICES ARCHITECTURE
705
this case, the GridService is acting like an Application Service Provider (ASP). The user
authenticates the ASP, using user name and password over https, and the ASP authenti-
cates the supercomputer centres, using Unicore authentication over UPL. In this demon-
strator, the computer centres do not know the identity of the end user, only that of the ASP.
Other security and trust models are clearly possible as detailed below:
1. Globus style proxy credentials could be generated by the Web Services client and sent
to the platform. This proxy certificate could then be used by Unicore to identify the
user to the computer centres.
2. The servlet can be run on the client side. In this case, Unicore authentication and
authorization are used throughout the process. The Web Services authentication can
be omitted since this connection is local. This approach has little to offer byway of
practical GridServices beyond providing a GridService client to existing Unicore users.
3. The Unicore sites could accept authentication according to the ASP model as described
above, but the Unicore sites can be configured to authorize on the basis of the login
used at the Web Services point of entry.
4. As OGSA security plans evolve, other approaches will be considered.
29.2.2 Supported Grid Services
The basic set of portTypes, as outlined in Reference [3], has been implemented. By aggre-
gating and extending these, a collection of practical GridServices has been implemented.
29.2.2.1 Basic GridService portTypes
All the basic portTypes are coded as Java interfaces. The WSDL representation of each
is generated automatically by the GLUE environment. However, GLUE has not been
extended to support the serviceType extension; hence, the aggregation of portTypes into
services takes place in the Java implementation and the complete Web service description
for each GridService is created automatically from the Java implementation.
Given that the Grid Service Specification indicates that all GridServices should support
the GridService portType, all other portTypes are constructed using interface extensions
from the GridService interface. The basic GridService interface hierarchy is therefore

as follows:
interface com.fujitsu.arcon.gridservice.IGridService
interface com.fujitsu.arcon.gridservice.IGridServiceFactory
interface com.fujitsu.arcon.gridservice.IHandleMap
interface com.fujitsu.arcon.gridservice.IJobGridService
interface com.fujitsu.arcon.gridservice.ISteeringGridService
interface com.fujitsu.arcon.gridservice.INotificationService
interface com.fujitsu.arcon.gridservice.INotificationSink
interface com.fujitsu.arcon.gridservice.INotificationSource
interface com.fujitsu.arcon.gridservice.IRegistry