78

593 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
593
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

78

  1. 1. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) Editors: 2Open Grid Services Infrastructure (OGSI) Tim Banks 3http://www.ggf.org/ogsi-wg 4 November 30th, 2003 5 1 Open Grid Service Infrastructure Primer 2 (Draft) 3Abstract 4This is a working draft of the OGSI Primer. The aim is to provide an introduction to the OGSI 5specification with progressive examples, but without relying on any particular 6implementation. 7The Primer is a non-normative document, which means that it is not a definitive (from the 8GGF's point of view) specification of OGSI, intended to provide an easily readable 9description of OGSI. It is intended towards quickly understanding the basic fundamentals for 10creating OGSI-based Grid Services. The examples and other explanatory material in this 11document are here to help you understand OGSI, but they may not always provide definitive 12or fully-complete answers. In such cases, you should refer to the relevant normative parts of 13the Grid Service Specification that can be found on the OGSI working group web site. 14Making comments and contributions. 15The OGSI Primer is a being produced by the OGSI working group of the GGF. The web site1 16of the working group lists its charter, mailing list and previous products, including the draft of 17the OGSI specification for which the Primer will act as an introduction. 18The Primer will be developed during 2003 and during its development comments from the 19OGSI working group are encouraged. 20You can put you comments directly on the OGSI-WG mailing list, or use the GridForge web 21site. Contributions to the document are coordinated via the mailing list and associated 22conference calls. 23 24 25 26 Copyright © Global Grid Forum (2002). All Rights Reserved. 27 For details, see the Full Copyright Notice on page 78. 28 29 30 61 The GridForge web site is at https://forge.gridforum.org/projects/ogsi-wg 7 Copyright © Global Grid Forum (5/6/2010). All Rights Reserved
  2. 2. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 3 4 4 Page 2 of 79 5 6
  3. 3. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2Contents 41. About this Primer....................................................................................................................7 5 1.1. Who should read this Document?....................................................................................7 6 1.2. Related Documents.........................................................................................................8 72. Grids and their Requirements.................................................................................................9 8 2.1. What are Grids?...............................................................................................................9 9 2.2. Features and Requirements of Computational Grid Systems..........................................9 10 2.3. Why a ‘Service-Oriented’ Architecture?.......................................................................11 11 2.4. Exploiting Web Services Architecture...........................................................................11 12 2.5. What is needed to provide and use Grid Services?........................................................12 13 2.5.1. The Client Side........................................................................................................12 14 2.5.2. The Server side........................................................................................................12 15 2.6. Associated and dependent standards..............................................................................13 163. Background Technology.......................................................................................................14 17 3.1. The Essentials of Web Services.....................................................................................14 18 3.1.1. Interactions defined by messages............................................................................14 19 3.1.2. Exploiting Web Services standards and facilities...................................................14 204. Describing Grid Services......................................................................................................16 21 4.1. Web Services Description Language (WSDL)..............................................................16 22 4.2. Grid Services Description Language (GWSDL)...........................................................18 23 4.3. The ‘Counter’ Example.................................................................................................20 24 4.3.1. Counter Web Service..............................................................................................20 25 4.3.2. Counter Grid Service..............................................................................................22 265. The Concepts of Grid Services.............................................................................................25 27 5.1. Using portType Extension.............................................................................................25 28 5.2. The Factory and Instance Pattern...................................................................................26 29 5.3. Lifetimes of Instances....................................................................................................26 30 5.4. Identity: Handles, References and Locators .................................................................26 31 5.4.1. Grid Service Handles..............................................................................................26 32 5.4.2. Grid Service References..........................................................................................26 33 5.4.3. Passing Handles and References: the Grid Service Locator...................................27 34 5.4.4. Identifying Grid Service Instances .........................................................................27 35 5.4.5. Service Instance Copies..........................................................................................28 36 5.5. Introducing serviceData.................................................................................................28 37 5.5.1. The Structure of serviceData...................................................................................29 38 5.5.2. Dynamic Addition and Removal of serviceData Elements....................................31 39 5.5.3. The Validity of serviceData Element Values..........................................................31 40 5.5.4. ServiceData Operations...........................................................................................32 41 5.6. Extensibility of Grid Service Operations.......................................................................33 42 5.7. Introducing Notification.................................................................................................33 43 5.8. Operation Faults.............................................................................................................35 44 5.9. Basic Services and Their Roles......................................................................................36 45 5.9.1. The Registry Service...............................................................................................37 46 5.9.2. The HandleResolver Service..................................................................................37 47 5.9.3. The Factory Service................................................................................................38 486. Implementing Web and Grid Services.................................................................................39 49 6.1. Server-Side Programming Patterns................................................................................39 4 Page 3 of 79 5 6
  4. 4. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 6.1.1. Monolithic Service Implementation........................................................................39 2 6.1.2. Implementation within a Container.........................................................................40 3 6.1.3. Container-managed State........................................................................................40 4 6.1.4. Replicated Copies of a Service Instance.................................................................41 57. Using Grid Services..............................................................................................................43 6 7.1. Client-Side Programming Patterns.................................................................................43 7 7.2. Reasons for Registries....................................................................................................44 8 7.2.1. The OGSI portTypes...............................................................................................45 9 7.2.2. Example: a simple registry of service factories .....................................................46 10 7.3. Service discovery and Invocation..................................................................................49 11 7.4. Binding to a Service.......................................................................................................49 128. The GridService portType....................................................................................................51 13 8.1. The basic requirement: GridServiceportType................................................................51 14 8.1.1. Terminology: Service Description and Service Instance........................................51 15 8.2. GridService Service Data...............................................................................................52 16 8.2.1. Using serviceData, an Example from GridService portType.................................53 17 8.2.2. ServiceData Initial values.......................................................................................54 18 8.2.3. ServiceData and portType Inheritance....................................................................54 19 8.2.4. ServiceData Bindings..............................................................................................54 20 8.3. GridService Operations..................................................................................................54 21 8.3.1. Querying ServiceData.............................................................................................54 22 8.3.2. GridService Examples 23 ...........................................................................................................................................55 249. ...............................................................................................................................................55 2510. Handle Resolution...............................................................................................................56 26 10.1. The handleResolverScheme SDE................................................................................56 27 10.2. The findByHandle operation........................................................................................57 28 10.2.1. Input......................................................................................................................57 29 10.2.2. Output....................................................................................................................57 30 10.2.3. Faults.....................................................................................................................57 3111. Finding Services: ServiceGroups and Registries................................................................59 32 11.1. The Registry Interfaces................................................................................................59 33 11.1.1. The purpose of registries in OGSA ......................................................................59 34 11.1.2. OGSI support for service registries ......................................................................59 35 11.1.3. Factory and instance registration..........................................................................60 36 11.1.4. Making Discoveries..............................................................................................60 37 11.2. Grouping services: The ServiceGroup portType.........................................................61 38 11.2.1. The membershipContentRule SDE:......................................................................61 39 11.2.2. The entry SDE:......................................................................................................61 40 11.3. Proxies for ServiceGroup members: The ServiceGroupEntry portType ....................62 41 11.3.1. The memberServiceLocator SDE: .......................................................................62 42 11.3.2. The content SDE: ................................................................................................62 43 11.4. Managing ServiceGroup membership: The ServiceGroupRegistration portType.......62 44 11.4.1. The addExtensibility SDE:....................................................................................62 45 11.4.2. The add operation:................................................................................................63 46 11.4.3. The removeExtensibility SDE:.............................................................................63 47 11.4.4. The remove operation:..........................................................................................63 4812. Creating Transient Services: The Factory...........................................................................65 49 12.1. The createServiceExtensibility SDE ...........................................................................65 4 Page 4 of 79 5 6
  5. 5. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 The createService operation ...............................................................................................65 2 12.1.1. Input......................................................................................................................65 3 12.1.2. Output....................................................................................................................65 4 12.1.3. Faults.....................................................................................................................66 5 12.2. Example.......................................................................................................................66 613. GridService Notification.....................................................................................................67 7 13.1. Notification Source and Notification Sink...................................................................67 8 13.2. Subscription Model......................................................................................................67 9 13.3. NotificationSource : Service Data Declarations .........................................................67 10 13.3.1. notifiableServiceDataName.................................................................................67 11 13.3.2. subscribeExtensibility SDE...................................................................................67 12 13.4. NotificationSource :: subscribe operation....................................................................68 13 13.5. Lifetime Management of the NotificationSubscription...............................................69 14 13.6. Notification Clients ....................................................................................................70 15 13.7. NotificationSource :: deliverNotification operation....................................................70 1614. Grid Services Security........................................................................................................71 17 14.1. Approach & Scope.......................................................................................................71 18 14.2. List of Topics to address..............................................................................................71 1915. Advanced Topics.................................................................................................................72 20 15.1. Advanced Registries [?]...............................................................................................72 21 15.2. Recommendations for Change Management...............................................................72 22 15.3. Describing Operation semantics..................................................................................72 23 15.4. Monitoring Execution..................................................................................................72 2416. Glossary of Terminology....................................................................................................73 2517. Comparison with other Distributed Architectures..............................................................74 2618. Author Information and Acknowledegements....................................................................76 27 18.1. Acknowledgements......................................................................................................76 2819. Document References.........................................................................................................77 2920. Copyright Notice.................................................................................................................78 3021. The Index............................................................................................................................79 31 4 Page 5 of 79 5 6
  6. 6. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1Table of Figures 2Figure 22-1: Common features of computational grid systems..................................................9 3Figure 33-2: The basis of Web Service computing...................................................................14 4Figure 33-3: Web Services facilities used in a Computational Grid.........................................15 5Figure 44-4: WSDL document structure...................................................................................16 6Figure 44-5: WSDL markup elements......................................................................................17 7Figure 44-6: GWSDL document structure................................................................................18 8Figure 44-7: Markup language for Grid Services.....................................................................19 9Listing 44-1: WSDL document for the Counter Web Service..................................................20 10Figure 44-8: An increase operation to the Counter Web Service.............................................20 11Figure 44-9: An increase operation to a Counter Web Service that supports multiple counters 12...................................................................................................................................................21 13Listing 44-2: Modified version of the Counter Web Services WSDL that supports multiple 14counters.....................................................................................................................................21 15Figure 44-10: An increase operation to a Counter Grid Service Instance................................22 16Listing 44-3: GWSDL document for a basic Counter Grid Service.........................................23 17Figure 44-11: Operations to two different Counter GSIs representing a counter each.............23 18Listing 44-4: GWSDL for a simple Counter Grid Service with an SDE..................................24 19Figure 44-12: Consumer requesting the value of the counter through the counterValue SDE 24 20Figure 55-13: Example serviceDataValues...............................................................................30 21Figure 55-14: ServiceData Operations......................................................................................32 22Figure 55-15: Typical Notification scenario.............................................................................34 23Figure 55-16: Main Components of OGSI Services.................................................................37 24Figure 66-17: Simple monolithic Grid Service.........................................................................39 25Figure 66-18: approach to the implementation of argument demarshalling functions.............40 26Figure 66-35-19: Container with state management.................................................................41 27Figure 66-45-20: Use of multiple references for the same Grid Service Instance....................42 28Figure 77-21: A client-side runtime architecture......................................................................43 29Figure 77-22: Factories and a dedicated Registry as information sources...............................45 30Figure 77-3: ServiceGroup structure and its relation to ServiceGroupEntry............................46 31Figure 77-26-23: Resolving a GSH.........................................................................................50 32Figure 88-24: Counter ServiceData..........................................................................................55 33Figure 1010-25: GWSDL Description of Service Group.........................................................61 34 4 Page 6 of 79 5 6
  7. 7. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 11.About this Primer 2This chapter introduces the structure of this document, its intended audience, and other 3material that might be relevant. 41.1.Who should read this Document? 5This is an introductory document to the Open Grid Services Infrastructure (OGSI) 6specification that is aimed at a wide audience of architects and developers, implementers and 7users. 8No prior knowledge of the Grid or Web Services is assumed, though an awareness of 9distributed computing will help. If you plan to develop your own Grid services, some 10knowledge or experience of XML, XML Schema and WSDL syntax would help you to 11understand the WSDL examples that appear in some chapters. If you need extensive 12background material on grids, The Anatomy of the Grid should help. 13The remaining chapters of this document are organized as follows: 14 • Chapter 2 summarizes the background of grid computing, the requirements and 15 context which inspired OGSI, and its relationship to the architectures and systems on 16 which it builds. This chapter is suitable for a non-technical audience. 17 • Chapter 3 gives an overview of Web Services whose specifications and technology 18 form the basis for OGSI. It describes some major mechanisms underlying Web 19 Services. 20 • Chapter 4 is more technical. It describes the features introduced to Web Services by 21 OGSI and introduces a simple example of a Web Service and a corresponding Grid 22 Service as a comparison. This example is also used in succeeding chapters. 23 • Chapter 5 covers all the main concepts and terminology of OGSI. It describes the 24 scope and the framework in which the example of Chapter 4 can be created, and the 25 techniques which might be used to extend it. Readers who are very familiar with Web 26 Services, know the motivation for OGSI and simply want a summary of OGSI may 27 start at this point. 28 • Chapters 6 and 7 explain how Grid services can be constructed and discusses 29 scalability related features that are enabled by OGSI. These are the features necessary 30 to create large-scale applications and systems. 31 • From Chapter 8 onwards, the details of Grid Services interfaces are explained in a way 32 that parallels the OGSI specification. This makes it easy to correlate the information in 33 the two documents. 34Examples are used throughout the Primer to illustrate the features that the OGSI specification 35requires. The examples are deliberately simple in order to avoid any need for knowledge of 36more realistic, but usually more complex, Grid applications. Also, although they contain 37correct interface definitions for the functions described, implementations are not provided. 38This is because the OGSI specification aims to define a standard for interoperability while 39leaving freedom to implement Grid Services in a wide variety of ways. For implementation 40details, the reader should investigate one of the Grid Service toolkits such as Globus GT3 and 41identify sample services that correspond to the ones described here. 4 Page 7 of 79 5 6
  8. 8. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 11.2. Related Documents 2This document is a companion document to the Open Grid Service Infrastructure (OGSI) 3specification . The Specification is the complete and authoritative description of Grid Services 4and should always be used to resolve questions of detail or ambiguity. 5This document is, as far as possible, a self-contained introduction to the concepts of Grid 6Services and their main features that should quickly provide insight into the way Grid 7Services can be used and operated. Some of its sections are aligned to corresponding topics in 8the OGSI specification, but it has more introductory material and uses illustrative examples 9that are not constrained by the need to be complete in detail, though this is also a goal 10wherever possible. 4 Page 8 of 79 5 6
  9. 9. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 12.Grids and their Requirements 22.1.What are Grids? 3Grid computing is a way of organizing computing resources so that they can be flexibly and 4dynamically allocated and accessed, often to solve problems requiring many organizations’ 5resources. The resources can include central processors, storage, network bandwidth, 6databases, applications, sensors and so on. The objective of grid computing is to make 7resources available (that is, processing capacity, information, input sensors, output and storage 8devices and networking facilities) so they can be more efficiently exploited. 9The advantage of sharing is clearest when the need for resources is unpredictable, short-term, 10or changes quickly, or where it is simply larger than any single organization’s capability to 11provide for it. For example, some problems that might take days to solve on a single 12installation’s processing resources can be reduced to a few minutes with the right kind of 13parallelization and distribution on additional allocated computational resources. 14This reduction in turn-around time has opened up areas and styles for computing applications 15that have previously been impractical. Similarly, information sharing can lead to discoveries 16and analytical predictions which are simply not possible with only part of the information. 17Such sharing may be enabled by sharing of access to storage resources, if the information is 18voluminous, or by agreeing pervasive standards for data description and access. 192.2.Features and Requirements of Computational Grid Systems 20This section describes the main features of one kind of grid system as background to the 21motivation for OGSI, namely a grid which enables the sharing of processing capacity, 22sometimes called a Computational Grid. Figure 22-1 illustrates the concept. 23 24 Figure 22-1: Common features of computational grid systems. 25The ‘client’ shown in the diagram need not be an end-user system, but could be an agent 26acting on its behalf, and there may be many such clients or agents, acting independently with 27no central control over the components shown. To make use of the resources, a client first 28uses information sources, here called ‘Resource Registries’, to discover those resources 29needed for execution of a task: multiple sources may need to be consulted to locate all the 30resources needed for a computation. Having located them, the client contacts the owning 4 Page 9 of 79 5 6
  10. 10. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1resource manager to request allocations for CPUs, secondary storage. Assuming the 2discovery and allocation steps were successful, the client then sends the input data and 3executables, receiving a reference to the execution in return. These actions may be 4accomplished in several stages or as one consolidated action, depending on the nature and 5complexity of the task. As resources are allocated, the resource manager may need to update 6the information in the registry to enable reasonable bids for resource allocation from other 7clients. Lastly, the client monitors execution of the task using the reference it previously 8received. It can retrieve the results, or be sent status of the task as it progresses. 9The construction of a computational grid, and other kinds of grid systems, requires facilities 10common to general distributed computing architectures – for example, a mechanism for 11identifying information by globally understood references which can be passed from one 12system to another, and for subscribing to updates to information sources as the information 13changes. However, grids make extreme demands on distributed programming because they 14are typically large-scale, and they exploit wide-ranging networks consisting of a variety of 15protocols and systems which may span organizational boundaries. Some of these issues are 16addressed by standards which are not part of the scope of OGSI: interoperability amongst 17heterogeneous systems is addressed by Web Services standards (described in Chapter 3), 18while security issues relevant to widely-interconnected systems are being addressed by other 19groups within the GGF. OGSI exploits these standards, adding to them where necessary, and 20focuses on the mechanisms that enable resources to be located, managed and exploited at 21large scale. The concepts are introduced fully in Chapter 5, but, to summarize briefly, the 22main requirements addressed by OGSI are: 23 • Defining a framework which establishes a necessary common basic behaviour, while 24 allowing wide scope for extension and refinement (such as optimization) and 25 specialisation to particular uses. 26 • As part of the basic behaviour, enabling systems to describe their own interfaces (a 27 facility known as introspection) as a means of flexibly enabling extensions, and to 28 describe their underlying capabilities, such as the speed of a CPU or the currency or 29 progeny of a database. The particular vocabularies for comparing capabilities are not 30 part of OGSI, but the framework for identifying, describing, querying and modifying 31 the descriptive information or other state of the system is central. 32 • The identification and description of the state which is the target of messages also 33 enables a standard approach, called ‘statefulness’, to managing interactions between 34 systems and their users. 35 • As part of the basic behaviour, establishing a system of communication of information 36 about systems which requires the least synchronization amongst them while still 37 providing a useful aggregation of information and behaviour. This attribute of OGSI is 38 known as ‘soft-state’ (, ) and exploits caching of information for a limited period 39 which can be extended by explicit requests from its users. 40 • As one aspect of statefulness and soft-state, describing a basic style of behaviour 41 which gives artefacts (identities, information, resource allocations) an explicit point of 42 creation and an explicit, limited but extendable lifetime. This provides a natural 43 recovery mechanism for resources in the case of failed processes. 44The next section explores another fundamental need: the form of standards which allow wide 45interoperability based on the concept of services. 4 Page 10 of 79 5 6
  11. 11. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 12.3.Why a ‘Service-Oriented’ Architecture? 2In computing terms, a ‘service’ is simply a function that can be invoked via a well-defined 3remote interface and in the terminology of OGSI a ‘service’ is used to represent the behaviour 4of any application, database, resource or any other artefact. A system defined in terms of 5service interfaces allows largely independent development and management of the caller 6(client) and the service provider. ‘Service-Oriented Architecture’ (SOA) is an architectural 7style whose goal is looser coupling among interacting software systems compared to earlier 8forms of distributing computing architecture such as RPC , CORBA , Java RMI and DCOM 9. It allows great flexibility in the interconnecting protocol and the underlying platform for 10clients and servers, all of which are advantageous in constructing grid systems. In this section 11we review the essential components of an SOA and in the next, their relationship to OGSI. 12A service is defined in terms of the messages one uses to interact with it and the behaviour 13expected in response. This behaviour may depend on the state of resources such as files, 14databases or sensors that are encompassed by the service and the state may change in 15response to messages from one or more clients, or on internally generated events such as 16timers or external physical events. The messages, state and other behaviour must be described 17by a service definition. 18A good service definition permits a variety of implementations. For example, an FTP server 19speaks the FTP protocol and supports remote read and write access to a collection of files. 20One FTP server implementation may simply write to and read from the server’s local disk, 21while another may write to and read from a mass storage system, automatically compressing 22and uncompressing files in the process. If variants are possible, then discovery mechanisms 23that allow a client to determine the properties of a particular implementation of a service are 24important. 25From the client’s point of view, an important aspect of the implementation of a service is the 26protocol that is used to communicate requests. A well-constructed server side implementation 27may permit several protocols. For example, the http and https protocols can both be used to 28retrieve Web pages from Web servers, but the latter is preferable if security is important. 292.4.Exploiting Web Services Architecture 30A Web Services is a particular type of Service-Oriented Architecture whose interfaces are 31defined using the Web Services Description Language (WSDL) and which focuses on simple, 32Internet-based standards (such as eXtensible Markup Language (XML) and the http protocol ) 33to enable heterogeneous distributed computing. 34OGSI describes Grid Services using Web Services as a basis. This means exploiting: 35 • The mechanisms for encoding message transmission protocols that are described as 36 bindings in Web Services. There are many ways of encoding messages, and Web 37 Services separates these concerns from the XML definitions of application interfaces: 38 OGSI standardizes interfaces at the application level, independently of the bindings. 39 • The conventions used in Web Services to separate the primary application interfaces 40 (function calls and their parameters) from functions which can be managed by 41 standardized, generic middleware. This includes issues such as authentication and 42 access control. 4 Page 11 of 79 5 6
  12. 12. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 • The techniques used in Web Services to separate service- and network-management 2 functions from the application interface. The management issues include workload 3 balancing, performance monitoring, and problem diagnosis. 4Development of Version 1.0 of the OGSI specification to the requirements already described 5has required extensions to WSDL . The extensions are described in detail in Chapters 4 and 5, 6but they can be summarized as 7 • A mechanism for defining an interface in terms of an ‘extension’ of one or more 8 simpler interfaces. This is a reliable way of establishing the basic behaviour of a Grid 9 Service. 10 • Enabling an XML-based language for describing the information (or ‘state’) 11 associated with a service. 12The extended language used to describe Grid Services is known as GWSDL. In the future, 13OGSI may be able to exploit developments in Web Service standards which can reduce, or 14eliminate, the need for grid-specific extensions. Indeed, this is anticipated in developments by 15the Web Services Description Working Group , and the OGSI working group of the GGF, which 16developed the specification, is committed to updating it when this becomes possible. 172.5.What is needed to provide and use Grid Services? 18In this section we introduce the requirements for the implementations of clients and servers 19participating in a grid system. A client may, of course, also be a Grid Service in its own right, 20but the two aspects can be separately addressed. Further details of possible implementations 21are described in Chapter . 22 2.5.1.The Client Side 23There are two meanings to the term ‘client’. The end-users of a grid system are its ultimate 24clients, but they may be shielded from the internal workings and requirements of the 25underlying systems by intermediaries such as Web portals, whose main objective is ease of 26use for the end-user. Secondly, there are the direct clients of Grid Services, which may be part 27of such a Web portal and are part of the concern of this Primer. An example of this type of 28client is illustrated in Figure 22-1. OGSI specifies many things that are required of services in 29order for them to be used by clients in a standard way. 30Since OGSI is based on Web Services standards, a client which is capable of interacting with 31a Web Service can also interact with a Grid Service provided the interface description has 32been translated from GWSDL into WSDL. The normal process for developing services and 33applications in a Service-Oriented Architectures can then be followed: the client may use the 34interface description during development of a grid application to construct calls to the service, 35and can locate a suitable server and communicate with it using Web Service protocols during 36execution of the application. 37 2.5.2.The Server side 38The provider of a Grid Service can take many forms, and the OGSI specification is designed 39to impose the least possible restriction on its implementation, which can range from dedicated 40hardware components through operating system services and custom-built applications. 41However since the OGSI standard is built on Web Services, so a platform for hosting Grid 42Services may be built on existing systems for hosting Web Services, such as those based on 43the J2EE component model. Such a system can provide many of the basics of a Grid Service 4 Page 12 of 79 5 6
  13. 13. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1via standard layers and services known as the ‘hosting environment’, and exploitation of such 2an environment and associated development tools is an efficient way of developing grid 3applications. 4The details of the interfaces between a Grid Service implementation and a hosting 5environment will depend on the particular system, but some aspects of such systems can be 6described in generic terms. Firstly, the application-specific operations and state of the service 7can be described using an interface description language or tools specific to that system, such 8as Java for a J2EE system. This interface description can be translated into a form described 9by Web Services and OGSI for consumption by clients. Secondly, the runtime system creates 10the interface between the service implementation and the hosting environment. This may 11include management of the state of the service, converting messages to and from the 12implementation language, and provision of standard operations for Grid Services. 132.6.Associated and dependent standards 14The OGSI specification itself provides only basic levels of function. It enables Grid Services 15to be created, managed, discovered and destroyed, but does not say anything about the 16resources, databases and applications that make up a grid. Standard descriptions of these 17facilities are required and OGSI provides a language and building blocks from which 18descriptions can be constructed. The work of defining high level constructs is in progress 19among working groups of GGF. These include standard techniques for accessing data, for 20configuring resources, for scheduling and allocating them, for monitoring system 21performance, and for accounting and paying for use. The Architecture for these standards is 22collectively called the Open Grid Services Architecture (OGSA) . 4 Page 13 of 79 5 6
  14. 14. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 13.Background Technology 2This chapter provides a high-level overview of Web Services, which form the foundation for 3OGSI. It necessarily leaves out much detail, but describes the structure and important features 4and explains why these are important, especially in the context of Grids. The next chapter 5goes into more technical detail and illustrates Web Services and Grid Services via a simple 6example. 7A more thorough and precise view of Web Services can be found in the Web Services 8Architecture document . 93.1.The Essentials of Web Services 10 3.1.1.Interactions defined by messages 11For the purposes of this Primer we will define a Web Service as something that can be 12described using the Web Services Description Language (WSDL) . A WSDL document 13defines the set of messages, the encodings, and protocols used to communicate with a service. 14Note that Web Service standards say nothing about the application interfaces (APIs) or the 15technologies used to manipulate the messages. This approach ensures that interoperability is 16the main focus of attention. 17 3.1.2.Exploiting Web Services standards and facilities 18The use of WSDL defines message exchanges between users of the service and its 19implementers, but it also allows exploitation of a growing body of related standards for 20describing services, publishing them in registries, defining and implementing message 21protocols. These related standards provide facilities which simplify and support the Service 22itself. The simple concept of some of these facilities is shown in Figure 33-2. 23 24 25 Figure 33-2: The basis of Web Service computing 26The Services are created and deployed on a server which is able to receive messages in a 27particular encoding, which can be described using the service’s WSDL document, over a 28transfer protocol. The server may enable several styles of encoding and/or protocol pairs, each 29of which is called a binding because it binds a high-level service definition to a low-level 30means of invoking the service. The server publishes the presence of a service in a Registry 4 Page 14 of 79 5 6
  15. 15. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1(sometimes called a directory) which is also known to potential consumers. From the 2Requester’s point of view, a Registry represents a collection of servers which may provide 3suitable implementations of the interfaces that it needs to use and may find them using criteria 4associated with bindings such as the security and transport protocols. 5The design and implementation of Registries is a large and important topic, and many 6different solutions exist. It is the objective of the OGSI specification to be able to exploit 7standards such as UDDI , which have been created for use by Web Services. There may be 8aspects of Registries and service description which need specific extensions or enhancements 9for grid computing, and OGSI aims to enable these, and to adopt new Web Services standards 10as these develop. Figure 33-3 illustrates one sense in which the Computational Grid described 11in Chapter 2 extends the concepts of Web Services. 12 13 14 Figure 33-3: Web Services facilities used in a Computational Grid 15In many Web Services, and indeed for many used in Grid systems, the Service presents an 16interface to the combination of data, application and physical resources needed to perform the 17service. However, in a Computational Grid a Service may represent the physical resources 18more explicitly, separately from the data and applications which exploit them. In this case, 19information visible to clients can change more dynamically. As Section 2.2 described, OGSI 20provides a framework of Service descriptions, including descriptions of state, which improve 21the manageability of distributed, dynamic information at large scale. 22The definition of bindings is an aspect of Web Services which OGSI exploits directly. 23Although any kind of message encoding and security protocol can be used between a Server 24and Requester within the framework of Web Services, standard encodings are needed to 25ensure easy, pervasive interoperability. The Web Services Interoperability Organization (WS- 26I) exists to make appropriate recommendations. However, leading-edge implementations of 27Web services, including grid applications, may, from time to time, adopt protocols which are 28not yet standardised. 4 Page 15 of 79 5 6
  16. 16. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 14.Describing Grid Services 24.1.Web Services Description Language (WSDL) 3WSDL is an XML document for describing a contract between a Web Service and its 4consumers about the format of the messages that can be exchanged and the message exchange 5patterns that the service can support. Figure 44-4 outlines the structure and major parts of a 6WSDL document, together with their relationships. 7 8 Figure 44-4: WSDL document structure 9The elements of the document are divided into two vertical sections 10 • The top section (‘message’, ‘portType’) is the abstract definition of the service 11 interface, its operations, and their parameters. These definitions determine what a 12 consumer of the service can do. 13 • The bottom section defines the binding(s) of the abstract definition to concrete 14 message formats, protocols and endpoint addresses through which the service can be 15 invoked. 4 Page 16 of 79 5 6
  17. 17. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 Figure 44-5: WSDL markup elements 3Figure 44-5 describes the structure of a WSDL document in more detail. The root XML 4element called the wsdl:definitions is on the left of the diagram. It may contain the subsidiary 5elements, shown via the ‘contains’ linkage, such as wsdl:import and wsdl:types. Subsidiary 6elements can be repeated as shown by the range indicator; for example all subsidiary elements 7of wsdl:definitions can appear any number of times (0..*). 8At the heart of a WSDL description is the portType definition which defines a group of input, 9output, and fault messages that a service is prepared to accept or produce and the message 10exchange patterns in which it is prepared to participate. Sometimes, it is easy to think of a 11portType as a Java interface or a C++ class. A message in a portType may be composed of 12many parts, where each part can be of a different type. The message parts can be thought of 13as input and output parameters; a message simply combines them. Section 4.3 contains a 14simple example. 4 Page 17 of 79 5 6
  18. 18. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1The types of message parts are defined within the types component of wsdl:definition. 2This element is extensible, meaning that it can contain arbitrary subsidiary elements to allow 3general data types to be constructed. The default type system in WSDL is XML Schema, 4which we won’t discuss here in detail. In order to understand our example it is sufficient to 5know that at the end of the definition we link the type names of message parts to their XML 6definitions. WSDL allows the other elements to contain subsidiary extension elements as a 7means of allowing flexible description of interface types; these extension points are shown in 8the diagram. The purpose of other extensions is described in Appendix A.3 of WSDL[4]. 9Another important part of the WSDL definition is the binding. It describes the concrete 10implementation of messages: that is a data encoding, messaging protocol, and underlying 11communication protocol. The XML elements of a binding are operations which reference the 12corresponding abstract messages by name. An important aspect of WSDL bindings is their 13capacity for extension by the addition of new subsidiary element definitions. WSDL allows 14any and all data encoding, message and communications protocols to be described. The 15usefulness of a particular description depends on having client and server systems that are 16able to interpret the WSDL descriptions to encode/decode the messages. 174.2.Grid Services Description Language (GWSDL) 18OGSI adds the features of Grid Services to basic Web Services by redefining the WSDL 19portType element. Grid Services are described using an extended form of WSDL known as 20GWSDL. Figure 44-6 illustrates the main structure of a GWSDL document, which is very 21similar to the WSDL structure shown in Figure 44-4 (page 16). 22 23 Figure 44-6: GWSDL document structure 24The differences between WSDL and GWSDL are illustrated in more detail in Figure 44-7. 4 Page 18 of 79 5 6
  19. 19. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 Figure 44-7: Markup language for Grid Services 3 • In OGSI, a portType can be constructed by referencing an existing portType or 4 portTypes, and adding new definitions as required. This enables standard behaviour 5 to be defined authoritatively, and to be referenced by service definitions that need to 6 incorporate it. Standard behaviour is important to clients that may need to use 7 independently implemented services. 8 • While a WSDL portType contains only operations, an OGSI portType can also contain 9 Service Data Declarations (SDDs), which help describe the identity and interfaces of 10 the service, and how its state can be viewed by a client. 11As an example, Section 4.3 contains a GWSDL version of the Counter service. 12These additions to the WSDL document schema are prefixed with gwsdl to identify their 13definition by OGSI. They may be incorporated into subsequent versions of WSDL, 4 Page 19 of 79 5 6
  20. 20. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1eliminating the need for new markup elements defined by OGSI. They have been addressed 2by the current “work in progress” draft of WSDL 1.2 in the W3C Web Services Description 3Working Group [WSDL 1.2 DRAFT], but because WSDL 1.2 is currently “work in progress”, 4OGSI cannot directly incorporate the entire WSDL 1.2 body of work. 5Instead, OGSI defines an extension to WSDL 1.1, isolated to the wsdl:portType element, that 6provides the minimal required extensions to WSDL 1.1. These extensions to WSDL 1.1 match 7equivalent functionality agreed to by the W3C Web Services Description Working Group. 8The Global Grid Forum commits to updating OGSI when WSDL 1.2 [WSDL 1.2] is 9published as a draft specification by the W3C. 104.3. The ‘Counter’ Example 11In this section, some of the Grid Services concepts and terminology are introduced through 12the Counter Service example, which is used as a vehicle for the discussion throughout the rest 13of the document. The relationship between Web and Grid Services is also demonstrated. 14 4.3.1.Counter Web Service 15The WSDL for a simple Counter Service with two operations (increase and getValue) is 16shown in Listing 44-1 below (the bindings and service sections are not presented): 17 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 18 xmlns:xs="http://www.w3.org/2001/XMLSchema" 19 xmlns:counter="http://www.gridforum.org/namespaces/ 20 2003/05/ogsiprimer/counter/webservice" 21 targetNamespace="http://www.gridforum.org/namespaces/ 22 2003/05/ogsiprimer/counter/webservice"> 23 <wsdl:types> 24 <xs:schema/> 25 </wsdl:types> 26 <wsdl:message name="increaseMsg"> 27 <wsdl:part name="value" type="xs:positiveInteger"/> 28 </wsdl:message> 29 <wsdl:message name="getValueMsg"> 30 <wsdl:part name="value" type="xs:positiveInteger"/> 31 </wsdl:message> 32 <wsdl:portType name="counterPortType"> 33 <wsdl:operation name="increase"> 34 <wsdl:input message="increaseMsg"/> 35 </wsdl:operation> 36 <wsdl:operation name="getValue"> 37 <wsdl:output message="getValueMsg"/> 38 </wsdl:operation> 39 </wsdl:portType> 40 </wsdl:definitions> 41 Listing 44-1: WSDL document for the Counter Web Service 42In the Web Services world, the Counter Web Service is an agent whose interface is described 43in WSDL, and it is the logical receiver of operation requests. 44 45 Figure 44-8: An increase operation to the Counter Web Service 4 Page 20 of 79 5 6
  21. 21. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1The Counter Web Service of Figure 44-8 implements the WSDL interface presented in Listing 244-1. The interface does not say anything about the state that must be maintained by the 3implementation of the Web Service. However, for the Counter Web Service to be useful, state 4has to be maintained in an implementation-specific way (e.g., in memory, in a database, in a 5file, etc.). Multiple consumers that have discovered the Counter Web Service through a 6registry can use its operations to change the counter’s state (any security-related issues are 7outside the scope of this discussion and are not considered). In Figure 44-8, a consumer of the 8service submits a request for an increase operation. 9If a Counter Web Service was to be extended so that multiple counters were supported, an ID 10would have to be introduced. The ID would identify the particular counter on which an 11operation was to be executed. Although the interface of the Counter Web Service would have 12to change in order to accept the ID, the same Counter Web Service would still be the logical 13receiver of the operations (Figure 44-9). 14 15 Figure 44-9: An increase operation to a Counter Web Service that supports multiple counters 16Listing 44-2 has the modified WSDL of the Counter Web Service that can support multiple 17counters. 18 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 19 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl" 20 xmlns:xs="http://www.w3.org/2001/XMLSchema" 21 xmlns:counter="http://www.gridforum.org/namespaces/ 22 2003/05/ogsiprimer/counter/basic " 23 targetNamespace="http://www.gridforum.org/namespaces/ 24 2003/05/ogsiprimer/counter/basic "> 25 <wsdl:types> 26 <xs:schema/> 27 </wsdl:types> 28 <wsdl:message name="increaseMsg"> 29 <wsdl:part name="counterId" type="xs:positiveInteger"/> 30 <wsdl:part name="value" type="xs:positiveInteger"/> 31 </wsdl:message> 32 <wsdl:message name="getValueRequestMsg"> 33 <wsdl:part name="counterId" type="xs:positiveInteger"/> 34 </wsdl:message> 35 <wsdl:message name="getValueResponseMsg"> 36 <wsdl:part name="value" type="xs:positiveInteger"/> 37 </wsdl:message> 38 <wsdl:portType name="counterPortType"> 39 <wsdl:operation name="increase"> 40 <wsdl:input message="increaseMsg"/> 41 </wsdl:operation> 42 <wsdl:operation name="getValue"> 43 <wsdl:input message="getValueRequestMsg"/> 44 <wsdl:output message="getValueResponseMsg"/> 45 </wsdl:operation> 46 </wsdl:portType> 47 </wsdl:definitions> 48 Listing 44-2: Modified version of the Counter Web Services WSDL that supports multiple counters 6 Page 21 of 79 7 8
  22. 22. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 4.3.2.Counter Grid Service 2In OGSI-terms, a Grid Service is a general term referring to a template, a contract, an 3interface described in GWSDL and the Grid Service Instances that must adhere to it. The term 4Grid Service does not characterize a component that can be part of a Grid application (i.e., it 5does not refer to an agent that can receive operation requests). Instead, it is Grid Service 6Instances that are the logical recipients of operation requests. 7In the OGSI world, a Grid Service Instance (GSI) has to be explicitly created (by a factory or 8by the hosting environment), assigned a Grid Service Handle (GSH) which uniquely identifies 9it, and then registered with a handle resolver so it can be found by other Grid Service 10Instances. While a GSH is a unique, abstract name for a Grid Service Instance, a Grid Service 11Reference (GSR) provides the endpoint-related information that is necessary to access the 12identified Grid Service Instance. Details of the steps that may be required for a Grid Service 13Instance to be discovered, created, and consumed are given in Section 5.4 (page 43). 14Once a Grid Service Reference (GSR) to a Grid Service Instance is available to a consumer, 15the GSI can be used to provide functionality that is equivalent to its Web Service counterpart. 16However, the OGSI-specific characteristics of a GSI can be used to provide richer solutions. 17The Counter GSI of Figure 44-10 is equivalent to the Counter Web Service presented in 18Section 4.3.1. Different service consumers can invoke operations on the same Counter GSI in 19order to change or access the state of the counter. This example differs from the Web Service 20version in that the state is logically attached to the instance. The semantics of a Grid Service 21Instance, as defined by OGSI, specify that state has to be maintained between consumer- 22service interactions. This is done in an implementation-specific way (i.e., the OGSI standard 23does not talk about how state is to be maintained). 24 25 Figure 44-10: An increase operation to a Counter Grid Service Instance 26In contrast to the Counter Web Service, each Counter Grid Service Instance is associated with 27lifetime properties that can be used to manage the lifecycle of a counter. Also note that the 28OGSI specification does not deal with the semantics of concurrent access to the same Counter 29Grid Service Instance by multiple clients. Hence, the consistency semantics of state related 30information are application-specific. 31The GWSDL interface of the Counter Grid Service looks very similar to its Web Service 32equivalent. Apart from the obvious namespace change, the only other difference is the 33introduction of portType extension using the "extends" attribute (Listing 44-3). This indicates 34to GWSDL processors that the counterPortType extends the functionality defined by the 35ogsi:GridService portType. 36 <wsdl:definitions 37 xmlns:ogsi="http://www.gridforum.org/namespaces/2003/03/OGSI" 38 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl" 39 xmlns:xs="http://www.w3.org/2001/XMLSchema" 40 xmlns:counter="http://www.gridforum.org/namespaces/ 41 2003/05/ogsiprimer/counter/basic" 42 targetNamespace="http://www.gridforum.org/namespaces/ 43 2003/05/ogsiprimer/counter/basic"> 4 Page 22 of 79 5 6
  23. 23. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 <wsdl:types> 2 <xs:schema/> 3 </wsdl:types> 4 <wsdl:message name="increaseMsg"> 5 <wsdl:part name="value" type="xs:positiveInteger"/> 6 </wsdl:message> 7 <wsdl:message name="getValueMsg"> 8 <wsdl:part name="value" type="xs:positiveInteger"/> 9 </wsdl:message> 10 <ogsi:portType name="counterPortType" extends="ogsi:GridService"> 11 <wsdl:operation name="increase"> 12 <wsdl:input message="increaseMsg"/> 13 </wsdl:operation> 14 <wsdl:operation name="getValue"> 15 <wsdl:output message="getValueMsg"/> 16 </wsdl:operation> 17 </wsdl:portType> 18 </wsdl:definitions> 19 Listing 44-3: GWSDL document for a basic Counter Grid Service 20Once a Grid Service Instance that adheres to the above GWSDL is created, it behaves in 21exactly the same way as the Counter Web Service but it offers the additional functionality 22defined by OGSI. The GWSDL of a Grid Service Instance, of course, contains the necessary 23bindings and service elements, as required by WSDL. 24The implicit association between a GSI and its state allows us to replicate the functionality of 25the Multiple-Counter Web Service without making significant changes to the interface. All 26that is required is a new Grid Service Instance. One could argue that a new Web Service 27identical to the one of Figure 44-9 could be deployed if multiple counters were required, 28while still keeping the same interface. However, OGSI encourages the instantiation of 29transient Grid service instances to represent state, so it is more natural to represent each 30separate counter as a separate Grid Service Instance. The OGSI model encourages, but does 31not mandate, a one-to-one association between a resource, in this case the counter, and a Grid 32Service Instance. By adopting this approach we get the additional benefit of lifetime and 33identity management for resources, as specified by OGSI.2 34 35 Figure 44-11: Operations to two different Counter GSIs representing a counter each 36In addition to state management, Grid Service Instances can provide access to information 37through attribute-like constructs, called Service Data Elements (SDEs). An SDE is declared in 38the Grid Service's interface and accessed through operations defined by OGSI's GridService 39portType. 42 The process by which Grid Service Instances can be created, registered, and discovered is discussed in detail in 5the later chapters. 4 Page 23 of 79 5 6
  24. 24. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1The Counter Grid Service may expose the value of the counter through an SDE, removing the 2need for the explicit getValue operation. The GWSDL of the Counter Grid Service with an 3SDE is shown in Listing 44-4 below: 4 <wsdl:definitions 5 xmlns:ogsi="http://www.gridforum.org/namespaces/2003/03/OGSI" 6 xmlns:sd="http://www.gridforum.org/namespaces 7 /2003/03/serviceData" 8 xmlns:wsdl="http://schemas.xmlsoap.org/wsdl" 9 xmlns:xs="http://www.w3.org/2001/XMLSchema" 10 xmlns:counter="http://www.gridforum.org/namespaces/ 11 2003/05/ogsiprimer/counter/basic" 12 targetNamespace="http://www.gridforum.org/namespaces/ 13 2003/05/ogsiprimer/counter/basic"> 14 <wsdl:types> 15 <xs:schema/> 16 </wsdl:types> 17 <wsdl:message name="increaseMsg"> 18 <wsdl:part name="value" type="xs:positiveInteger"/> 19 </wsdl:message> 20 <wsdl:message name="getValueMsg"> 21 <wsdl:part name="value" type="xs:positiveInteger"/> 22 </wsdl:message> 23 <ogsi:portType name="counterPortType" extends="ogsi:GridService"> 24 <wsdl:operation name="increase"> 25 <wsdl:input message="increaseMsg"/> 26 </wsdl:operation> 27 <sd:serviceData name="counterValue" 28 type="xs:positiveInteger" 29 minOccurs="1" 30 maxOccurs="1" 31 mutability="mutable"> 32 <sd:documentation> 33 The value of the counter. 34 </sd:documentation> 35 </sd:serviceData> 36 </ogsi:portType> 37 </wsdl:definitions> 38 Listing 44-4: GWSDL for a simple Counter Grid Service with an SDE 39It is now possible to access the counterValue SDE through operations specified by the 40GridService portType (Figure 44-12). 41 42 Figure 44-12: Consumer requesting the value of the counter through the counterValue SDE 43Note that OGSI says nothing about how the value of an SDE is maintained, if indeed it is 44maintained at all – for example, a business process associated with an SDE could calculate the 45value of the SDE through some application-specific logic, or a Grid Service that reports 46temperature might read the value directly from the temperature sensor each time a client 47accesses the SDE. 4 Page 24 of 79 5 6
  25. 25. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 15.The Concepts of Grid Services 2This chapter introduces the ideas that are essential features of Grid Services. These are: 3 • The use of ‘extension’ to create complex portTypes from simpler, ones, how this is 4 enabled by Grid Service WSDL and the behaviour every Grid Service must have as a 5 result of extending the basic OGSI GridService portType. 6 • The Factory and Instance pattern. 7 • The lifetime of Instances. 8 • Grid Service References. 9 • The Identity of a Grid Service Instance: Handles, References and Locators. 10 • Service Data. 11 • Extensibility of operations. 12 • Notification. 13 • Faults. 14 • The basic services defined by OGSI: ServiceGroup, HandleResolver and Factory. 15Chapters and 7 describe how Grid Services can be implemented and what large scale features 16are needed to create and/or use services based in a grid. More detailed explanations of the 17standard portTypes can be found in subsequent chapters, starting with the core GridService 18portType in Chapter 8. 195.1.Using portType Extension 20Grid Service Descriptions can use portType extension to define standard operations through 21the use of the GWSDL ‘extends’ attribute. For example, the Counter Grid Service (Section 224.3.2) begins: 23 <ogsi:portType name="counterPortType" extends="ogsi:GridService"> 24This causes the inclusion of operations and ServiceData Declarations (SDD) from the 25ogsi:GridService portType. All Grid Service descriptions include these SDD definitions 26which are, in summary: 27 • The identity (called the Handle) of any Grid Service Instance which implements the 28 description. This identity distinguishes an Instance, and the state associated with it, 29 from all others. 30 • The termination time of the Instance. This can be set when the Instance is created and 31 may sometimes be modified by users of the Instance. 32 • The names of all the portTypes that the Service implements. 33 • The identity of the Factory that created the Instance (or xsi:nil if the instance was not 34 created by a Factory). 35The operations provided by the ogsi:GridService portType allow a client to query and modify 36the state reported by ServiceData, to specify the earliest and latest desired termination time 37and, finally, to destroy the Instance. 4 Page 25 of 79 5 6
  26. 26. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 15.2.The Factory and Instance Pattern 2The Factory design pattern is commonly used in Objected-Oriented software systems to 3enable the creation of multiple, similar artefacts. An OGSI Factory Service is a Grid Service 4that is used by a client to create other Grid Service Instances. When a client needs to create a 5new instance of a particular Grid Service it locates a corresponding Factory Service, invokes 6its createService operation, and receives a unique identifier that it can use to access the newly- 7created Instance. See Section 5.4 for information about Grid Service identifiers. 8A Factory Service may choose to implement either the Factory portType defined by OGSI or 9another portType which serves some more specialized function. For example, the 10NotificationSource portType described in Section 5.7 and the ServiceGroupRegistration 11portType both create new Instances, so they follow the Factory pattern and, by definition, any 12Grid Services that implement them are Factory Services. 135.3.Lifetimes of Instances 14In many cases, the artefacts (the Grid Service Instances) that are created to accomplish a task 15are only needed for a limited time. They may represent physical resources such as storage 16allocations, processor and bandwidth reservations, or the right to use sensors and databases. In 17such cases, an explicit lifetime can be associated with an Instance when it is created. 18Requesters may sometimes need to be aware of the lifetimes of the Instances they use or 19create. If the initial lifetime proves insufficient, they may periodically prolong the lifetime of 20an Instance by extending its terminationTime. Often, the lifetime will be significant in the 21case of any failure in the progress of a task. In that case, when their lifetimes expire, the 22Instances can be safely destroyed, and the resources they represent can be safely recycled. 23This convention is essential in a large-scale, distributed system such as a Grid, where it is not 24possible to take into account all the possible consumer dependencies when sweeping up 25Service Instances. 265.4.Identity: Handles, References and Locators 27 5.4.1.Grid Service Handles 28When a Grid Service Instance is created, it is given a globally-unique identity, known as a 29Grid Service Handle (GSH), which can be used by consumers to refer to the state associated 30with that Instance. 31A GSH is a standard Universal Resource Identifier (URI) – it indicates how to locate the 32Instance, but not how to communicate with it. Before the GSH can be used, it must be 33resolved into a Grid Service Reference. 34 5.4.2.Grid Service References 35Although a Grid Service Handle uniquely identifies an Instance, the Handle by itself does not 36provide all the information needed to allow the Requester to send messages to the Instance. 37What is needed is a description of a binding that can be used to translate application-level 38operations into network messages. In OGSI, these Handle-specific bindings are called Grid 39Service References (GSRs), and they can be described in WSDL. A Reference is created by 40passing a Handle to a special service called a Handle Resolver. 41Unlike a Handle, which is unique for all time, a Reference is a temporary identifier: it has a 42limited lifetime, and should be refreshed periodically if the client has a long-term need to use 4 Page 26 of 79 5 6
  27. 27. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1the associated Instance. The Reference’s goodUntil property indicates its expiration time, and 2while it may continue to work after that time the client should refresh it to ensure that the 3most appropriate binding is being used. If the Reference has become invalid – which may 4happen if the Instance has been relocated to a different server, for example – any attempt to 5use it will result in a failed operation. 6A single Handle may resolve to several different References, each with a different set of 7characteristics. If so, the client can choose which one to use. For example: 8 • A Reference that enables a high-performance binding might be available to clients 9 that are local to the Instance, while clients running on remote systems have to use a 10 lower-performance network binding. 11 • A client that is local to the Instance may use a Reference representing a binding that 12 describes unencrypted transmission, while remote clients are required to use 13 encryption. 14 • If multiple copies of a single Instance exist, the Handle Resolver may return a 15 separate Reference for each copy. Service Instance Copies are explained in Section 16 5.4.5. 17Many handle resolution schemes are possible; the OGSI specification does not restrict or 18mandate any particular one, and allows multiple schemes to be used in parallel. For example, 19a client may prefer a Handle described by a secure resolution scheme such as SGNP to 20safeguard the integrity of Reference which is returned. 21 5.4.3.Passing Handles and References: the Grid Service Locator 22Handles and References may be passed to or returned Grid Service operations, and it is often 23convenient to pass a collection of References and Handles so that the eventual user of the 24target Instance (a client application or its supporting middleware) can choose the most 25appropriate way of calling it. OGSI defines the Grid Service Locator as a container for a 26collection of Handles and References: a single Locator may contain any number of Handles 27and/or References, and its recipient may choose to use them in any appropriate way. 28For example, in response to a client’s successful createService request, a Factory service 29returns a Locator that might contain several Handles and valid References. The client may 30store the Locator before using it, and when it is needed discovers that the references are no 31longer useable. It passes the Locator to a Handle Resolver Service, which returns an updated 32Locator containing the original Handles plus one or more new References. The client can 33choose whichever of the References it considers appropriate. 34A Locator may also contain the name (a fully-qualified name in the XML namespace) of the 35interface for the target Service. This can be used by the recipient of the Locator to discover 36the interface description, to check that the Handles and References refer to implementations 37that are suitable for the client, and to allow the client infrastructure to enable access to the 38service. In some cases, References themselves may contain interface references or 39descriptions, but this is not always the case. 40 5.4.4.Identifying Grid Service Instances 41From the discussion above it should be clear that each Grid Service Instance is distinguished 42from all others by means of its Handles and References. Use of the same Handle to invoke 4 Page 27 of 79 5 6
  28. 28. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1(via resolution) operations on multiple occasions, even by different clients, must result in all 2of the operations acting on the same Instance. 3However, a Grid Service can have multiple Handles and/or References, and a client may 4receive different versions from several sources as Locators are passed around. Comparing 5versions of these received from different sources is not useful as a way of identifying the 6target Instance as being the same one, as the next section illustrates. If a Service requires 7clients to be able to establish equivalence of several Locators, Handles or References, it must 8provide an operation to do this. The details of the comparison are dependent on the Service. 9 5.4.5.Service Instance Copies 10A given Grid Service Instance is an association of a Service with some particular state – the 11value of a counter or the status of a physical resource, for example. If there is likely to be 12contention for the use of a particular Instance, it may be possible to improve performance by 13creating multiple copies of the same Instance, perhaps spread across multiple processors or 14servers. This is a service-oriented analogy of multi-threading a traditional program. 15For example, our Counter service may expect frequent access to each Counter Instance by 16multiple clients. One way of implementing the service is to distribute the load by establishing 17multiple copies of the same Instance, and resolving the Instance’s GSH to multiple (different) 18references to those copies. Each reference is equivalent to all of the others – provided that the 19copies are correctly synchronised during updates, and that they always refer to the same state 20values. It is up to the Service designer to determine how best to synchronise operations and to 21determine if the Handle Resolver should pass all of the References to a particular client, 22allowing the client to choose which one to use, or to give each client only a Reference to a 23particular copy, perhaps on a round-robin basis for each request. 24A service may also place additional information in its Handles to distinguish copies of the 25service from each other. The Counter Instance may provide different Qualities of Service 26(such as fast or slow response times) to different clients based on information in the Handle, 27yet still preserve the semantics of the Counter service across all clients of the Instance. 28The semantics of the service description may, as in the case of the counter, require that the 29service moves through a series of well-defined states in response to a particular sequence of 30messages, thus requiring state coherence regardless of how Handles are resolved to 31References. However, other service descriptions may be defined that allow for looser 32consistency between the various members of the distributed service implementation. The 33copies of the Service Instance, identified by different Handles and References, may respond 34differently in some respects, yet still be the same Instance. 355.5.Introducing serviceData 36The idea of stateful Grid Service Instances, which was introduced in Section 4.3, is based on 37the ability to assign a global identity and a lifetime to a piece of ‘state’ that is managed by the 38Instance. ServiceData is a way to describe some parts of the state. The Counter Service 39example introduced in Section 4.3.2 shows how a serviceData element (SDE) can be 40introduced to expose the value of the state – in this case the counter. In general, a Grid 41Service can include declarations in its Service Description that expose to its clients as much 42or as little of its state as necessary. 43The advantages of using serviceData are: 4 Page 28 of 79 5 6
  29. 29. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 • Generic operations are provided to get and set the values of the SDEs and retrieve 2 collections of values from the different SDEs. 3 • Interfaces are available that allow clients to receive notification of changes to the 4 value of an SDE during the lifetime of a Service Instance (see Section 5.7). 5 • SDEs may have lifetimes, which can help to qualify the validity of information in a 6 distributed system. 7ServiceData is designed to support the general requirements for information management in a 8Grid, including requirements for the discovery, introspection, monitoring and management of 9Grid Service Instances. SDEs can provide descriptive information about an Instance, 10including both meta-data (information about the service instance, such as the interfaces it 11supports and the way it is configured) and state data (runtime properties of the Instance, such 12as the counter value). 13 5.5.1.The Structure of serviceData 14The serviceData declarations Declarations in a service Service description Description define 15the structure of an XML document which is delivered to a client (though possibly rendered in 16some form convenient for the Requester) in response to a query operation on the serviceData, 17and which, to reports the values of the serviceData Elements. However, Aan implementation 18of OGSI may provide a query API that returns values in their natural forms – rendering 19integers as binary values, for example – so that the client never has to deal directly with the 20XML. 21The returned report document has a ‘serviceDataValues’ element at its root, and each 22serviceData Declaration (SDD) in the Service Description describes the structure of 23subsidiary elements of the report. For example, the declaration for the counterValue SDE 24from Section 4.3 is as follows: 25 <sd:serviceData name="counterValue" 26 type="xs:positiveInteger" 27 minOccurs="1" 28 maxOccurs="1" 29 mutability="mutable"> 30 <sd:documentation> 31 The value of the counter. 32 </sd:documentation> 33 </sd:serviceData> 34Part of the structure of the XML document generated by the Counter Service to report the 35value of the SDEs is shown graphically in Figure 55-13. 4 Page 29 of 79 5 6
  30. 30. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 Figure 55-13: Example serviceDataValues 3The declaration of the counterValue SDE causes the inclusion of one element named 4‘counter:counterValue’ which contains an integer. Since the counter service extends the basic 5GridService portType, all of the SDEs declared in GridService are also present in the counter. 6These include the ‘osgi:interface’ SDE, whose value consists of one or more elements each of 7which contains the name of an interface (portType) implemented by the Instance. This, and 8the other SDEs defined by the GridService portType are described in Chapter 8. 9To be clear about the terminology, note that the singular ‘value of an SDE’ may actually 10consist of several ‘SDE value elements’. 11The serviceData Declaration may use attributes to describe the structure of the serviceData 12values. Some of these attributes parallel those of XML schema elements because, like XML 13declarations, they describe the structure of XML documents. The following attributes may be 14associated with a given SDE: 15 • name and type. 16 • minOccurs and maxOccurs. These constrain the number of occurrences of the 17 element. Simple values such as the counterValue are singletons (minoccurs=1 and 18 maxoccurs=1). Compound values such as ogsi:interface consist of an unordered 19 collection of elements. 20 • nillable (true or false). This can provide a special ‘nil’ value for the element. The 21 meaning of this nil depends on the particular SDE. An example of its use can be found 22 in the description of the gridServiceHandle SDE in Section 8.2. 23 • modifiable. If false, the serviceData element should be regarded as ‘read only’ by the 24 requester, though its values may change as a result of other operations on the Service’s 25 interface, or simply because the underlying state of the service changed. If true, the 26 setServiceData operation may be used to modify the value. 27 28 Note that in the Counter Service example the counterValue is technically not 29 modifiable, because its value is not changed via the setServiceData operation, but via 30 the ‘increase’ operation. The differences in the semantics of these operations are 31 discussed in Section 5.5.4. 32 • mutability. This describes the way in which the serviceData is initialised, and whether 33 its value can change during the lifetime of the Instance. 34 o An SDE declared with a mutability attribute of ‘static’ is initialized with a 35 value that is specified in the WSDL description, while a ‘constant’ declaration 4 Page 30 of 79 5 6
  31. 31. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 indicates that the value will be initialised by the Service Instance when it is 2 created. In both of these cases the SDE keeps the same value for the lifetime 3 of the Instance. 4 o An ‘extendable’ SDE can have new value elements added during the lifetime 5 of the service, but none of them can be subsequently changed or removed. 6 o A ‘mutable’ SDE has no constraints on its value elements: any and all may be 7 changed or removed and new ones may be added at any time – provided the 8 other constraints such as maxoccurs are still valid. 9 In the Counter Service example, the ‘counter:counterValue’ is mutable, because its 10 value changes over time. The ‘ogsi:interface’ SDE is constant. 11 5.5.2.Dynamic Addition and Removal of serviceData Elements 12Many SDEs are most naturally defined in a Service’s interface definition can be supplied with 13initial values that are also included with the definition. For example, the initial value of the 14static findServiceDataExtensibility SDE in the ogsi:GridService portType is defined by: 15 <sd:staticServiceDataValues> 16 <findServiceDataExtensibility 17 inputElement=”ogsi:queryByServiceDataNames”/> 18 </sd:staticServiceDataValues> 19However, situations can arise where it is useful to add or remove serviceData elements during 20the lifetime of an Instance. The means by which such updates are achieved is not defined by 21OGSI; for example, a Service Instance may implement operations for adding a new SDE. The 22GridService portType includes SDEs that allow a client to discover a Service’s serviceData 23definitions dynamically, and to find their values. 24 5.5.3.The Validity of serviceData Element Values 25ServiceData Element values may carry attributes defining their period of validity. These are: 26 • gsi:goodFrom: Declares the time from which the value is valid. This is typically the 27 time at which the report was created. 28 • ogsi:goodUntil: Declares the time until which the value is valid. 29 • ogsi:availableUntil: This declares the time until which the serviceData Element itself 30 is expected to be available, perhaps with updated values. After this time, a client may 31 no longer be able to get a copy of this element. 32When supplied, these attributes are intended to be useful to the client, but the Service is not 33required to supply them, and the client is free to use or ignore them as it sees fit. For example, 34a Service that reports the temperature of a device might poll the device’s temperature sensor 35once every minute. When a client requests the temperature, the Service might report the 36temperature value with a goodUntil value that corresponds to one second before the time of 37the next reading. With knowledge of the Service’s semantics the client might then store the 38value, and continue to use it until the value has expired, reasoning that if it were to make 39another request before that time it would receive the same value. 4 Page 31 of 79 5 6
  32. 32. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 5.5.4.ServiceData Operations 2The OGSI GridService portType defines operations which ‘find’ and ‘set’ the state reported 3by the serviceData Elements. The form of the operation and the relationship of the SDE 4values and the state were introduced in Section 4.3.2, and are shown in Figure 55-14 . 5 6 Figure 55-14: ServiceData Operations 7Here the Counter value is defined as an SDE using the XML in Section 4.3.2. A query 8operation uses the name of the SDE to select the value, and the Service returns a document 9similar to the following: 10 <ns1:serviceDataValues ..."> 11 <ns3:CounterValue ... 12 xsi:type="ns2:CounterValueType" 13 goodFrom="2002-04-27T10:20:00.000-06:00"> 14 <value xmlns="">111</value> 15 </ns3:CounterValue> 16 </ns1:serviceDataValues> 17The ‘findServiceData’ operation produces a report of the values of SDEs associated with the 18state of the Instance, and has two significant features. Firstly, the syntax of the operation 19which selects the values to be returned may be defined by the Service. OGSI defines default 20syntax, illustrated in Figure 55-14, which contains the names of the SDEs that are required, 21but each Grid Service can define its own syntax to provide greater power in the selection of 22reported values. This is an example of ‘operation extensibility’, which is described in more 23detail in Section 5.6. Secondly, the values that are reported need not be from the same point in 24time. Each element of the report may carry its own ‘goodFrom’ and ‘goodUntil’ attribute to 25indicate the freshness and longevity of the value. Even when times are not provided, the 26consumer of the report should make no assumptions about the coherence of the values. 27The ‘setServiceData’ operation has the same features as ‘findServiceData’; it also has an input 28syntax which is extensible and which can be defined by the Grid Service with defaults, 29defined by OGSI, called setByServiceDataNames and deleteByServiceDataNames. These 30systems use a collection of SDE names and values, and the values are used to update the state 31of the Instance. In the default systems, the client cannot assume that the replacement of any 32service data elements is carried out with any coherency: the way in which multiple values in 33the input data are treated, and their effect on the state of the Instance and on subsequent 34findServiceData operations, is defined as if each value is independent of all others, and 35independent of other processes which may be updating or querying the state of the Instance. 36As an example, consider the effect of the following input value to a setServiceData operation 37on an instance of the Counter Grid Service. 4 Page 32 of 79 5 6
  33. 33. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 <ogsi:setByServiceDataNames> 2 <counterValue> 100 </counterValue> 3 </ogsi:setByServiceDataNames> 4The implementation of the Service may store the new value in a temporary buffer before 5applying it to the underlying state of the Instance. A findServiceData operation which is 6invoked just after the completion of the setServiceData may report a counterValue that is 7different from 100 because the state has not, at that time, been updated. In the case of the 8Counter Service, the increase and getValue operations are provided to manipulate the 9counter in a synchronized way. 10An example of the use of the setServiceData operation is the description of configuration and 11management of services in the Common Configuration Model of OGSA . 125.6.Extensibility of Grid Service Operations 13Several OGSI operations accept an input argument that is an untyped extensibility element. 14This allows for a general pattern of behaviour to be expressed by the Service Description, 15including a specific default refinement of the pattern, while allowing for other refinements, 16via extensions, which may be appropriate to particular services or tasks. An extensible 17operation is a useful way to define interfaces, such as the OGSI portTypes, which are intended 18to be extended by more concrete and specific portTypes. In order to allow a client to discover 19the extensions that are supported by such an operation, OGSI defines a common approach for 20expressing extensible operation capabilities via static serviceData values. 21The findServiceData and setServiceData operations described in Section 5.5.4 and the 22NotificationSource::subscribe operation described in Section 5.7 are all examples of 23extensible operations. An extensible operation may contain one extensible input parameter, 24which can contain an XML element of a type described by the values of an SDE associated 25with the operation name. For example, the input arguments for the setServiceData operation 26are described by the serviceData values in the GridService portType: 27 <ogsi:setServiceDataExtensibility 28 inputElement=”ogsi:setByServiceDataNames” /> 29 30 <ogsi:setServiceDataExtensibility 31 inputElement=”ogsi:deleteByServiceDataNames” /> 32These declarations provide two initial value elements for the SDE named 33setServiceDataExtensibility, which can have any number of additional values, and has a 34mutability attribute of ‘static’. The two values permit two choices for input to the operation, 35and the service determines which kind of input is being used from the name attribute of the 36XML element used when the input message is received. 375.7.Introducing Notification 38Notification is a common software messaging style that allows clients (sinks) to be notified of 39changes that occur in a service (source). For example, instead of a client periodically asking a 40Counter Grid Service Instance if there are any changes to its counter value (a polling 41approach), it makes one single call to the Service Instance, requesting to be notified whenever 42a state change occurs. From then on the Counter Instance will contact the client as soon as any 43change occurs, and send it a notification message that may specify the type of change and/or 44information relating to the changed state. 4 Page 33 of 79 5 6
  34. 34. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1The notification framework allows for asynchronous, one-way delivery of messages from a 2source to a subscribed sink. Any service that wishes to support subscription of notification 3messages must support the NotificationSource interface. OGSI allows for notification on the 4service data elements of a Grid Service instance. As part of its serviceData, the 5NotificationSource maintains a set of SDEs to which a requester may subscribe for 6notification of changes. If notification on change of implementation-specific internal state is 7desired, then additional SDEs may be defined for that purpose. 8To start notification from a particular service a client must invoke the subscribe operation on 9the notification source interface, giving it the Handle of the notification sink. A subscription 10request also contains a subscription expression that is an XML element that describes what 11messages should be sent from the source to the sink, as well as when messages should be sent, 12based on changes to values within a service instance's serviceData values. 13 14 Figure 55-15: Typical Notification scenario 15As illustrated in Figure 5.4, a subscription request causes the creation of a Subscription Grid 16Service Instance that can be used by the client to manage the subscription, and to discover its 17properties. A Locator to this Subscription Instance is returned as part of the output from the 18subscribe operation, as well the currently-planned termination time. 19Following a successful subscription, a stream of notification messages then flows from the 20source to the sink as changes occur to the subscribed SDE's, until the subscription is either 21explicitly destroyed or is timed out. 4 Page 34 of 79 5 6

×