7 Rationale for choosing the Open Grid Services Architecture Malcolm Atkinson National e-Science Centre, Edinburgh, Scotland, United Kingdom 7.1 INTRODUCTION This chapter presents aspects of the UK e-Science communities’ plans for generic Grid middleware. In particular, it derives from the discussions of the UK Architecture Task Force [1]. The UK e-Science Core Programme will focus on architecture and middleware develop- ment in order to contribute significantly to the emerging Open Grid Services Architecture (OGSA) [2]. This architecture views Grid technology as a generic integration mechanism assembled from Grid Services (GS), which are an extension of Web Services (WS) to comply with additional Grid requirements. The principal extensions from WS to GS are the management of state, identification, sessions and life cycles and the introduction of a notification mechanism in conjunction with Grid service data elements (SDE). The UK e-Science Programme has many pilot projects that require integration technol- ogy and has an opportunity through its Core Programme to lead these projects towards adopting OGSA as a common framework. That framework must be suitable, for example, it must support adequate Grid service interoperability and portability. It must also be 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 200 MALCOLM ATKINSON populated with services that support commonly required functions, such as authorisation, accounting and data transformation. To obtain effective synergy with the international community that is developing Grid standards and to best serve the United Kingdom’s community of scientists, it is necessary to focus the United Kingdom’s middleware development resources on a family of GS for which the United Kingdom is primarily responsible and to deliver their reference implementations. The UK e-Science and computing science community is well placed to contribute substantially to structured data integration services [3–15]. Richer information models should be introduced at the earliest opportunity to progressively approach the goal of a semantic Grid (see Chapter 17). The UK e-Science community also recognises an urgent need for accounting mechanisms and has the expertise to develop them in conjunction with international efforts. This chapter develops the rationale for working with OGSA and a plan for developing commonly required middleware complementary to the planned baseline Globus Toolkit 3 provision. It takes the development of services for accessing and integrating structured data via the Grid as an example and shows how this will map to GS. 7.2 THE SIGNIFICANCE OF DATA FOR e-SCIENCE The fundamental goal of the e-Science programme is to enable scientists to perform their science more effectively. The methods and principles of e-Science should become so pervasive that scientists can use them naturally whenever they are appropriate just as they use mathematics today. The goal is to arrive at the state where we just say ‘science’. Just as there are branches of mathematics that support different scientific domains, so will there be differentiated branches of computation. We are in a pioneering phase, in which the methods and principles must be elucidated and made accessible and in which the differentiation of domain requirements must be explored. We are confident that, as with mathematics, these results will have far wider application than the scientific testing ground where we are developing them. The transition that we are catalysing is driven by technology and is largely manifest in the tsunami of data (see Chapter 36). Detectors and instruments benefit from Moore’s law, so that in astronomy for instance, the available data is doubling every year [16, 17]. Robotics and nanoengineering accelerates and multiplies the output from laboratories. For example, the available genetic sequence data is doubling every nine months [16]. The volume of data we can store at a given cost doubles each year. The rate at which we can move data is doubling every nine months. Mobile sensors, satellites, ocean-exploring robots, clouds of disposable micro-sensors, personal-health sensors, combined with digital radio communication are rapidly extending the sources of data. These changes warrant a change in scientific behaviour. The norm should be to collect, annotate, curate and share data. This is already a trend in subjects such as large-scale physics, astronomy, functional genomics and earth sciences. But perhaps it is not yet as prevalent as it should be. For example, the output of many confocal microscopes, the raw data from many micro-arrays and the streams of data from automated pathology labs and digital medical scanners, do not yet appear as a matter of course for scientific use RATIONALE FOR CHOOSING THE OPEN GRID SERVICES ARCHITECTURE 201 and analysis. It is reasonable to assume that if the benefits of data mining and correlating data from multiple sources become widely recognised, more data will be available in shared, often public, repositories. This wealth of data has enormous potential. Frequently, data contains information rele- vant to many more topics than the specific science, engineering or medicine that motivated its original collection and determined its structure. If we are able to compose and study these large collections of data for correlations and anomalies, they may yield an era of rapid scientific, technological and medical progress. But discovering the valuable knowl- edge from the mountains of data is well beyond unaided human capacity. Sophisticated computational approaches must be developed. Their application will require the skills of scientists, engineers, computer scientists, statisticians and many other experts. Our challenge is to enable both the development of the sophisticated computation and the collaboration of all of those who should steer it. The whole process must be attainable by the majority of scientists, sustainable within a typical economy and trustable by sci- entists, politicians and the general public. Developing the computational approaches and the practices that exploit them will surely be one of the major differentiated domains of e-Science support. The challenge of making good use of growing volumes of diverse data is not exclusive to science and medicine. In government, business, administration, health care, the arts and humanities, we may expect to see similar challenges and similar advantages in mas- tering those challenges. Basing decisions, judgements and understanding on reliable tests against trustworthy data must benefit industrial, commercial, scientific and social goals. It requires an infrastructure to support the sharing, integration, federation and analysis of data. 7.3 BUILDING ON AN OGSA PLATFORM The OGSA emerged contemporaneously with the UK e-Science review of architecture and was a major and welcome influence. OGSA is the product of combining the flexible, dynamically bound integration architecture of WS with the scalable distributed architecture of the Grid. As both are still evolving rapidly, discussion must be hedged with the caveat that significant changes to OGSA’s definition will have occurred by the time this chapter is read. OGSA is well described in other chapters of this book (see Chapter 8) and has been the subject of several reviews, for example, References [18, 19]. It is considered as the basis for a data Grid (see Chapter 15) and is expected to emerge as a substantial advance over the existing Globus Toolkit (GT2) and as the basis for a widely adopted Grid standard. 7.3.1 Web services Web Services are an emerging integration architecture designed to allow independently operated information systems to intercommunicate. Their definition is the subject of W3C- standards processes in which major companies, for example, IBM, Oracle, Microsoft and SUN, are participating actively. WS are described well in Reference [20], which offers the following definition: 202 MALCOLM ATKINSON ‘A Web service is a platform and implementation independent software component that can be • described using a service description language, • published to a registry of services, • discovered through a standard mechanism (at run time or design time), • invoked through a declared Application Programming Interface (API), usually over anetwork, • composed with other services.’ WS are of interest to the e-Science community on two counts: 1. Their function of interconnecting information systems is similar to the Grid’s intended function. Such interconnection is a common requirement as scientific systems are often composed using many existing components and systems. 2. The support of companies for Web services standards will deliver description lan- guages, platforms, common services and software development tools. These will enable rapid development of Grid services and applications by providing a standard frame- work for describing and composing Web services and Grid services. They will also facilitate the commercialisation of the products from e-Science research. An important feature of WS is the emergence of languages for describing aspects of the components they integrate that are independent from the implementation and platform technologies. They draw heavily on the power of XML Schema. For example, the Web Services Description Language (WSDL) is used to describe the function and interfaces (portTypes) of Web services and the Web Services Inspection Language (WSIL) is used to support simple registration and discovery systems. Simple Object Access Protocol (SOAP) is a common denominator interconnection language that transmits structured data across representational boundaries. There is currently considerable activity proposing revisions of these standards and additional languages for describing the integration and the coordination of WS, for describing quality-of-service properties and for extending Web service semantics to incorporate state, more sophisticated types for ports and transactions. It is uncertain what will emerge, though it is clear that the already strong support for distributed system integration will be strengthened. This will be useful for many of the integration tasks required to support e-Science. Inevitably, the products lag behind the aspirations of the standards proposals and vary significantly. Nevertheless, they frequently include sophisticated platforms to support operations combined with powerful development tools. It is important that developers of e-Science applications take advantage of these. Consequently, the integration archi- tectures used by e-Science should remain compatible with Web services and e-Science developers should consider carefully before they develop alternatives. 7.3.2 The Open Grid Services Architecture As other chapters describe OGSA (see Chapter 8), it receives only minimal description here, mainly to introduce vocabulary for later sections. A system compliant with OGSA RATIONALE FOR CHOOSING THE OPEN GRID SERVICES ARCHITECTURE 203 is built by composing GS. Each Grid service is also a Web service and is described by WSDL. Certain extensions to WSDL are proposed to allow Grid-inspired properties to be described, and these may be adopted for wider use in forthcoming standards. This extended version of WSDL is called Grid Services Description Language (GSDL). To be a Grid service the component must implement certain portTypes, must comply with certain lifetime management requirements and must be uniquely identifiable by a Grid Service Handle (GSH) throughout its lifetime. The lifetime management includes a soft-state model to limit commitments, to avoid permanent resource loss when partial failures occur and to guarantee autonomy. In addition, evolution of interfaces and function are supported via the Grid Service Record (GSR). This is obtainable via a mapping from a GSH, and has a time to live so that contracts that use it must be renewed. These properties are important to support long-running scalable distributed systems. A Grid service may present some of its properties via SDE. These SDE may be static or dynamic. Those that are static are invariant for the lifetime of the Grid service they describe, and so may also be available via an encoding in an extension of WSDL in the GSR. Those that are dynamic present aspects of a Grid service’s state. The SDE may be used for introspection, for example, by tools that generate glue code, and for monitoring to support functions such as performance and progress analysis, fault diagnosis and accounting. The SDE are described by XML Schema and may be queried by a simple tag, by a value pair model and by more advanced query languages. The values may not be stored as XML but synthesised on demand. An event notification, publish and subscribe, mechanism is supported. This is associated with the SDE, so that the query languages may be used to specify interest. The functions supported through the mandatory portTypes include authentication and registration/discovery. 7.4 CASE FOR OGSA The authors of OGSA [2] expect the first implementation, Globus Toolkit 3 (GT3), to faithfully reproduce the semantics and the APIs of the current GT2, in order to min- imise the perturbation of current projects. However, the influence of the thinking and the industrial momentum behind WS, and the need to achieve regularities that can be exploited by tools, will surely provoke profound changes in Grid implementations of the future. Indeed, OGSA is perceived as a good opportunity to restructure and re-engineer the Globus foundation technology. This will almost certainly be beneficial, but it will also surely engender semantically significant changes. Therefore, because of the investment in existing Grid technology (e.g. GT2) by many application projects, the case for a major change, as is envisaged with OGSA, has to be compelling. The arguments for adopting OGSA as the direction in which to focus the development of future Grid technology concern three factors: politics, commerce and technology. The political case for OGSA is that it brings together the efforts of the e-Science pio- neers and the major software companies. This is essential for achieving widely accepted 204 MALCOLM ATKINSON standards and the investment to build and sustain high-quality, dependable Grid infras- tructure. Only with the backing of major companies will we meet the challenges of • installing widespread support in the network and the operating system infrastructures, • developing acceptance of general mechanisms for interconnection across boundaries between different authorities and • obtaining interworking agreements between nations permitting the exchange of signif- icant data via the Grid. The companies will expect from the e-Science community a contribution to the political effort particularly through compelling demonstrations. The commercial case is the route to a sustainable Grid infrastructure and adequate Grid programming tools, both of which are missing for the Grid at present because the e-Science community’s resources are puny compared to the demands of building and sustaining comprehensive infrastructure and tool sets. If convergence can be achieved between the technology used in commercial applications for distributed software integra- tion and that used for scientific applications, then a common integration platform can be jointly constructed and jointly maintained. As commerce is ineluctably much larger than the science base alone, this amortises those costs over a much larger community. Com- merce depends on rapid deployment and efficient use of many application developers who are rarely experts in distributed systems. Yet it also depends on a growing number of ever more sophisticated distributed systems. It therefore has strong incentives to build tool sets and encapsulated services that would also benefit scientists if we share infrastructure, as we do today for computers, operating systems, compilers and network Internet protocol (IP) stacks. A further commercial advantage emerges from the proposed convergence. It will be easier to rapidly transfer e-Science techniques to commerce and industry. Using a common platform, companies will have less novel technology to learn about, and therefore less assimilation costs and risks when they take up the products of e-Science research. The technological case for OGSA is largely concerned with software engineering issues. The present set of components provided by the Grid has little structure to guide the application developers. This lack of explicit structure may also increase the costs of maintaining and extending the existing Grid infrastructure. The discipline of defining Grid services in terms of a language (GSDL) and of impos- ing a set of common requirements on each Grid service should significantly improve the ease and the accuracy with which components can be composed. Those same disciplines will help Grid service developers to think about relevant issues and to deliver depend- able components. We expect significant families of GS that adopt additional constraints on their definition and address a particular domain. Such families will have improved compositional properties, and tools that exploit these will be a natural adjunct. Dynamic binding and rebinding with soft state are necessary for large-scale, long- running systems that are also flexible and evolvable. The common infrastructure and disciplines will be an appropriate foundation from which to develop RATIONALE FOR CHOOSING THE OPEN GRID SERVICES ARCHITECTURE 205 • tools, subsystems and portals to facilitate e-Science application development, taking advantage of the richer information available from the metadata describing Grid services, • advances in the precision and detail of the infrastructure and the disciplines to yield dependable, predictable and trustworthy services. 7.5 THE CHALLENGE OF OGSA To deliver the potential of OGSA many challenges have to be met. Sustaining the effort to achieve widely adopted standards that deliver the convergence of the WS and the Grid and rallying the resources to build high-quality implementations are obvious international challenges. Here we focus on more technical issues. 1. The types commonly needed for e-Science applications and for database integration need to be defined as XML Schema namespaces. If this is not done, different e- Science application groups will develop their own standards and a babel of types will result. 2. The precision required in GSDL definitions will need to be specified so that it is sufficient to support the planned activities. A succession of improved standards should be investigated, so that progressively more of the assembly of Grid services can be automated or at least automatically verified. 3. Standard platforms on which Grid services and their clients are developed. 4. The infrastructure for problem diagnosis and response (e.g. detecting, reporting, local- ising and recovering from partial failures) has to be defined. 5. The infrastructure for accounting within an assembly of Grid services. 6. The infrastructure for management and evolution. This would deliver facilities for limiting and controlling the behaviour of Grid services and facilities for dynami- cally replacing Grid service instances in an extensively distributed and continuously operating system. 7. Coordination services that some Grid services can participate in. 8. Definitions and compliance testing mechanisms so that it is possible to establish and monitor quality and completeness standards for Grid services. 9. Programming models that establish and support good programming practice for this scale of integration. 10. Support for Grid service instance migration to permit operational, organisational and administrative changes. 11. Support for intermittently connected mobile Grid services to enable the use of mobile computing resources by e-Scientists. These issues already exist as challenges for the ‘classical’ Grid architecture. In some cases, Global Grid Forum (GGF) working groups are already considering them. OGSA provides an improved framework in which they may be addressed. For example, interfaces can be defined using GSDL to more precisely delimit a working group’s area of activity. 206 MALCOLM ATKINSON 7.6 PLANNING THE UNITED KINGDOM’S OGSA CONTRIBUTIONS The UK e-Science Core Programme should coordinate middleware development to align with, influence and develop the OGSA. This will inevitably be a dynamic process; that is, an initial plan will need to be monitored and modified in response to contributions by other countries and by companies. The UK Grid middleware community must work closely with pilot projects to explore the potential of OGSA, to conduct evaluations and to share implementation effort. Our initial plan proposed work on a number of sub-themes. Phase I : Current actions to position the UK e-Science Core Programme middleware effort. 1. Understanding, validating and refining OGSA concepts and technical design. 2. Establishing a common context, types and a baseline set of Grid services. 3. Defining and prototyping baseline database access technology [21]. 4. Initiating a Grid service validation and testing process. 5. Establishing baseline logging to underpin accounting functions. Phase II : Advanced development and research. 1. Refining GSDL, for example specifying semantics, and developing tools that use it. 2. Pioneering higher-level data integration services en route to the semantic Grid. 3. Pioneering database integration technology. 4. Developing advanced forms of Grid Economies. The work in Phases I and II must take into account a variety of engineering and design issues that are necessary to achieve affordable, viable, maintainable and trustworthy ser- vices. These include performance engineering, dependable engineering, engineering for change, manageability and operations support, and privacy, ethical and legal issues. The following sections of the chapter expand some of the topics in this plan. 7.7 ESTABLISHING COMMON INFRASTRUCTURE There are three parts to this: the common Grid services, namely computational con- text, the standard set of e-Science and Grid service types and the minimal set of Grid service primitives. Developers building new Grid services or applications require to know which oper- ations are always supported by a hosting environment. As code portability can only pertain within a single hosting environment, these operations may be specific to that hosting environment. For example, the operations for developers working within a J2EE hosting environment need not be the same as those for developers using C. However, there will be a pervasive baseline functionality, which will have various syntactic forms. The physiology chapter (see Chapter 8) describes it thus: RATIONALE FOR CHOOSING THE OPEN GRID SERVICES ARCHITECTURE 207 . implementation of Grid services can be facilitated by specifying baseline charac- teristics that all hosting environments must possess, defining the ‘internal’ interface from the service implementation to the global Grid environment. These characteris- tics would then be rendered into different implementation technologies (e.g. J2EE or shared libraries). Whilst traditional Grid implementations have mapped such requirements directly to the native operating system or to the library code, GS are likely to be significantly influenced by the platforms used in Web service hosting. 7.7.1 Grid services hosting environment We are familiar with the power of well-defined computational contexts, for example, that defined by the Java Virtual Machine [22] and that defined for Enterprise Java Beans [23]. Designing such a context for GS requires a balance between the following: • Parsimony of facilities to minimise transition and learning costs. • Complete functionality to provide rich resources to developers. A common issue is a standard representation of a computation’s history, sometimes called its context. This context contains information that must be passed from one service to the next as invocations occur. Examples include the subject on behalf of whom the computation is being conducted (needed for authorisation), the transaction identifier if this computation is part of a transaction and so on. An example of such a context is MessageContext in Apache Axis. 7.7.2 Standard types The SOAP definition [24] defines a set of types including primitive types and the recursive composition of these as structures and arrays, based on namespaces and notations of the XML Schema definitions [25, 26]. The applications and libraries of e-Science use many standard types, such as complex numbers, diagonalised matrices, triangular matrices and so on. There will be a significant gain if widely used types are defined and named early, so that the same e-Science-oriented namespaces can be used in many exchange protocols, port definitions, components and services. The advantages include 1. simplification of interworking between components that adopt these standards, 2. better amortisation of the cost of type design, 3. early validation of the use of WSDL for these aspects of e-Science and 4. simplification of the task of providing efficient mappings for serialising and deserial- ising these structures by avoiding multiple versions. Many communities, such as astronomers, protein crystallographers, bioinformaticians and so on, are developing standards for their own domains of communication and for curated data collections. The e-Science core programme can build on and facilitate this process 208 MALCOLM ATKINSON by developing component types that can be reused across domains. As higher-level types are standardised and reused, it becomes easier to move activities towards the information and knowledge layers to which the semantic Grid aspires. 7.8 BASELINE DATABASE ACCESS This is primarily the responsibility of the UK Database Task Force [12] and now the GGF Database Access and Integration Services (DAIS) working group [21]. A Centre Project, OGSA-DAI based on a consortium of EPCC, IBM, NEeSC, NeSC, NWeSC and Oracle, is developing a set of components to serve this function and to contribute to the standards. This is an illustration of using OGSA and so it is presented as an example. The suite of middleware envisaged is complementary to that produced by data man- agement projects, such as the European Data Grid (see Chapter 15) and distributed file and replication management, such as GIGGLE [27]. Their primary concern is to manage reliable storage, distributed naming, replication and movement of large collections of data that are under their management. They operate largely without concern for the structure and the interpretation of data within their containers (mostly files and collections of files). Database Access and Integration (DAI) components permit access to data, which is usually stored in standard Database Management Systems (DBMS), which is often man- aged autonomously and provide database operations, such as query and update, for the data held in these databases. The challenges include establishing connections, estab- lishing authority and handling the variety of forms of data. At present DAI aspires to handle distributed database operations applied to collections of data in relational databases, XML collections and files whose structure is adequately described. A cur- rent description may be found in Reference [21] and in other papers prepared for GGF5 (http://www.cs.man.ac.uk/grid-db/). 7.8.1 An overview of the OGSA-DAI architecture DAIcomponent categories: There are four categories of component. Each may have a variety of detailed forms. Their function and range of forms are introduced here. Grid database services (GDS): These are either a structured data store or (more often) a proxy for a structured data store, such as an instance of a DBMS. In either case they provide access to the stored data through a standard portType. In later versions of DAI they will also represent federations. To accommodate the variety of data models, query languages, data description languages and proprietary languages, this API includes explicit identification of the language that is used to specify each (database) operation that is to be applied. This flexibility also allows for GDS that reveal proprietary operations of specific DBMS, allows batches of operations to be optimised and processed by interpreting a Grid Job Control Language and provides for extension for future data models. Developers may restrict themselves to standard widely supported languages, such as SQL’92 and Xpath, in order to achieve platform independence. [...]... Storey, T and Watson, P (2002) Database Access and Integration Services on the Grid , UK DBTF working paper, January, 2002 (presented at GGF4), http://www.cs.man.ac.uk /grid- db/ 13 Pearson, D (2002) Data Requirements for the Grid: Scoping Study Report, UK DBTF working paper, February, 2002 (presented at GGF4), http://www.cs.man.ac.uk /grid- db/ 14 Stevens, R., Goble, C., Paton, N., Bechhofer, S., Ng, G., Baker,... UDDI Indianapolis, IN: Sams Publishing (2002) 21 Atkinson, M P et al Grid Database Access and Integration: Requirements and Functionalities, (Presented at GGF5 July, 2002), http://www.cs.man.ac.uk /grid- db/ 22 Linholm, T and Yellin, F (1996) The Java Virtual Machine Reading, MA: Addison-Wesley, 1996 RATIONALE FOR CHOOSING THE OPEN GRID SERVICES ARCHITECTURE 215 23 Mohan, Application Servers and Associated... W., Fernandes, A A A and Sakellariou, R Distributed Query Processing on the Grid , http://www.cs.man.ac.uk /grid- db/ 29 Melton, J., Michels, J.-E., Josifovski, V., Kulkarni, K., Schwarz, P and Zeidenstein, K (2002) SQL and Management of External Data, 2002 30 Foster, I., Kesselman, C and Tuecke, S (2001) The Anatomy of the Grid: Enabling Virtual Organisations International Journal of Supercomputer Applications,... Many other middleware functions can be extracted and developed as GS One example is accounting and the infrastructure for a Grid ‘market’ This is identified as urgently required by many UK projects and by those who provide computation resources RATIONALE FOR CHOOSING THE OPEN GRID SERVICES ARCHITECTURE 213 The OGSA infrastructure and the componentisation of e-Science infrastructure is expected to have... Imperial College, London IBM Hursley Laboratory, UK REFERENCES 1 Atkinson, M P et al (2002) UK Role in Open Grid Services Architecture, Report for the UK e-Science Programme, April, 2002 214 MALCOLM ATKINSON 2 Tuecke, S., Czajkowski, K., Foster, I., Frey, J., Graham, S., Kesselman, C and Nick, J (2002) Grid Service Specification, Presented at GGF4, February, 2002 http://www.globus.org/research/papers.html...RATIONALE FOR CHOOSING THE OPEN GRID SERVICES ARCHITECTURE 209 Grid database service factories (GDSF): These may be associated with an instance of a DBMS or they may be associated with a particular DBMS type or data model In the former case, the GDS... Survey, Technical Report MR-TR-99-30, Microsoft Research, Revised 2000 18 Kuntz, P Z (2002) The Open Grid Services Architecture: A Summary and Evaluation, Report for the UK e-Science Core Programme, April, 2002 19 Gannon, D., Chiu, K., Chiu, Govindaraju, M and Slominski, A (2002) An Analysis of the Open Grid Services Architecture, Report for the UK e-Science Core Programme, April, 2002 20 Graham, S.,... a GDS that allows direct access on that storage system The API will again provide control and flexibility by explicitly defining the language used Grid data transport vehicles (GDTV): These provide an abstraction over bulk data transmission systems, such as GridFTP, MPICH-G, Unix Pipes and so on They provide two APIs, one for a data producer and one for a data consumer.1 These may then be kept invariant,... services Grid data service registries (GDSR): These allow GDS and GDSF to register and then allow client code to query GDSR to find data sources or GDS/F that match their requirements according to data content, operations, resources and so forth They will be a special form of registry in the OGSA sense, providing support for data content and structure searches These depend on a metadata infrastructure Grid. .. Diverse Information Sources Using an Ontology In Proceedings of Workshop on Computation of Biochemical Pathways and Genetic Networks, European Media Lab (EML), pp 83–88 15 Watson, P (2002) Databases and the Grid , Version 3, Technical Report CS-TR-755, Newcastle University, Department of Computer Science, January, 2002, in this volume 16 Gray, J (2001) The World Wide Telescope: Mining the Sky SC2001, Denver . emerging Open Grid Services Architecture (OGSA) [2]. This architecture views Grid technology as a generic integration mechanism assembled from Grid Services. suitable, for example, it must support adequate Grid service interoperability and portability. It must also be Grid Computing – Making the Global Infrastructure