• Like
78
Upcoming SlideShare
Loading in...5
×
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
436
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 3 4 4 Page 2 of 79 5 6
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  • 35. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1For example, in the last Counter example from Section 3.2, the value of the counter is 2exposed through an SDE and is accessed through the queryByServiceDataNames operation 3(pull model). With notification support, the Counter Instance will automatically notify all 4sinks (subscribed clients) whenever changes occur to its value. The following example adds 5notification support to the counter example from Section 3.2 6 <ogsi:portType 7 name="NotificationcounterPortType" 8 extends="counter:CounterPortType ogsi:NotificationSource"/> 9Any client that is interested in receiving notification only has to support the NotificationSink 10portType. That is, a Web Service is not required to also implement the GridService portType 11in order to act as a notification sink. This enables the notification clients to live outside an 12OGSI hosting environment and still subscribe to notification messages. 13The OGSI Notification framework defines one simple type of subscription, as defined by the 14subscribeByserviceDataNames operation extensibility. For a subscribeByServiceDataNames 15subscription, the notification message that is sent from the source to the sinks is simply a 16serviceDataValues element. 17A client (sink) that uses a subscribeByServiceDataNames to the CounterValue SDE of a 18NotifcationCounter Instance will receive a serviceDataValues element similar to the one 19below whenever the value (111 in the example) in the CounterValue SDE is changed. 20 <ns1:serviceDataValues ..."> 21 <ns3:CounterValue ... 22 xsi:type="ns2:CounterValueType"> 23 <value xmlns="">111</value> 24 </ns3:CounterValue> 25 </ns1:serviceDataValues> 265.8.Operation Faults 27A common procedure is used for handling operation faults generated by Grid Services. This 28simplifies problem determination by having a common base set of information that all fault 29messages contain. It also allows for "chaining" of fault information up through a service 30invocation stack, so that a recipient of a fault can drill down through the causes to understand 31more detail about the reason for the fault. OGSI defines a base type (ogsi:FaultType) for all 32fault messages that Grid Services must return. This approach simply defines the base format 33for fault messages, without modifying the WSDL fault message model. All Grid Service 34operations must return the ogsi:fault (which is of type ogsi:FaultType) in addition to any 35operation-specific faults. For example an application-specific fault (myFault) could be 36included in the definition as follows 37 <wsdl:definitions ...> 38 <types> 39 <xsd:schema ...> 40 <xsd:complexType name="MyFaultType"> 41 <xsd:complexContent> 42 <xsd:extension base="ogsi:FaultType"/> 43 </xsd:complexContent> 44 </xsd:complexType> 45 <xsd:element name="myFault" type="tns:MyFaultType"/> 46 </xsd:schema> 47 </types> 4 Page 35 of 79 5 6
  • 36. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 <message name="myFaultMessage"> 1 <part name="fault" element="tns:MyFault"/> 2 </message> 3 <ogsi:portType ...> 4 <wsdl:operation ...> 5 <input ...> 6 <output ...> 7 <fault name="myFault" message="tns:myFaultMessage"/> 8 <fault name="fault" message="ogsi:faultMessage"/> 9 </wsdl:operation> 10 </ogsi:portType> 11 </wsdl:definitions> 13A Grid Service operation may return a more refined fault (i.e., an extension derived through 14the XML schema mechanisms) in place of a particular fault that is required by an operation 15definition. For example, if an operation is specified to return a fault with the element myFault 16under some circumstances, then a particular implementation of that operation may return an 17extension of myFault in its place. This should be done by returning the myFault message with 18an xsi:type of the more refined fault. 19It is recommended that all faults from a Grid Service either use the FaultType directly or use 20an extension of FaultType. However there may be circumstances in which faults from a Grid 21Service are not derived from FaultType, such as when the Grid Service uses legacy portTypes 22in addition to OGSI portTypes. 235.9.Basic Services and Their Roles 24Figure 55-16 shows an interaction between components defined by OGSI that is a typical 25pattern for the use of Grid Services. The Services are introduced in the subsections which 26follow, and are described in more detail in subsequent chapters. 27The starting point for the interaction is that the Requester is an end user or Web Server acting 28on behalf of end users, and has installed applications which need to make use of remote 29services. The Requester has configuration information which provides references to a 30Registry Service. 4 Page 36 of 79 5 6
  • 37. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 Figure 55-16: Main Components of OGSI Services 3 4 5.9.1.The Registry Service 5Although OGSI does not specify a Registry Service, a Registry can be described by using or 6extending the ServiceGroup or ServiceGroupRegistration portTypes. A Registry contains 7references to other Services, and a Requester can search for a Service that it needs by 8supplying the Registry with details of the Interface that it needs. The Registry responds with 9details of all the Services it knows about that match the search criteria. 10For example, a Requester that needs to create a Counter Service may search for a 11CounterFactory portType and receive back information, including a Handle, which identifies 12the Factory. 13 5.9.2. The HandleResolver Service 14It is convenient to the Requester for Services which supply Handles, such as Registry 15Services, to supply a WSDL document describing GSRs along with the Handle, but the GSRs 16can also be discovered from a HandleResolver. 17A HandleResolver Service is a fundamental part of an OGSI grid. Since Requesters need 18access to a HandleResolver before they can access any other service, they must be 19bootstrapped with information about which HandleResolver to use. This is typically done 20using configuration data. 21The HandleResolver is used to retrieve up-to-date or otherwise improved References to a 22Service identified by a Handle. A Requester can use the HandleResolver at any time to obtain 23the best available binding. 4 Page 37 of 79 5 6
  • 38. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 5.9.3.The Factory Service 2The Factory Service was described earlier, but is included here for completeness. 3A Requester invokes a createService operation on a Factory, and receives in response Handles 4and/or References for the newly-created Instance. See Section 5.2 for more information about 5Factory Services. 4 Page 38 of 79 5 6
  • 39. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 16. Implementing Web and Grid Services 2In this chapter, we examine the relationship between OGSI and the existing and developing 3Web Services framework (description languages, tools and implementation platforms) on 4which it builds and depends. We examine both the server-side programming patterns for Grid 5Services and several conceptual hosting environments for Grid Services. The patterns 6described in this chapter are enabled but not required by OGSI. We discuss these patterns in 7this chapter to help put into context concepts and details described in the other parts of the 8Primer and in the Specification. In particular, the discussion of implementing robust services 9provides more information on the relationship between handles and references, and the 10discussion of replicated service instances answers some questions about the issue of identity. 116.1.Server-Side Programming Patterns 12The OGSI Specification does not dictate any particular server-side implementation 13architecture. A variety of approaches are possible, ranging from implementing the Grid 14Service instance directly as an operating system process to a sophisticated server-side 15component model such as J2EE. In the former case, most, or even all, support for standard 16Grid Service behaviours (invocation, lifetime management, registration, etc.) is encapsulated 17within the user process - for example via linking with a standard library. In the latter case, 18many of these behaviours will be supported by the hosting environment. 19To illustrate a range of possibilities for implementation, and the features of the Specification 20that enable this range we describe different hosting patterns of increasing complexity in the 21following sections. 22 6.1.1.Monolithic Service Implementation 23In Figure 66-17, we depict a scenario where the entire behaviour of the Grid Service, 24including the demarshalling/decoding of the network message, has been encapsulated within a 25single executable. The protocol termination represents a communications component such as 26an http server with the Grid Service implemented directly using the servlet interface. 27Although this approach may have some efficiency advantages, it provides little opportunity 28for reuse of functionality between Grid Service implementations. 29 30 Figure 66-17: Simple monolithic Grid Service 4 Page 39 of 79 5 6
  • 40. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 6.1.2.Implementation within a Container 2 3 Figure 66-18: approach to the implementation of argument demarshalling functions. 4In Figure 66-18, the invocation message is received at a network protocol termination point 5(e.g., an http server, as is the case for many Grid Services.) This converts the data in the 6invocation message into a format consumable by the hosting environment. We illustrate two 7Grid Service instances (the circles) implemented as container-managed components (for 8example EJBs within a J2EE container). Here, the message is dispatched to these components, 9with the container frequently providing facilities for demarshalling and decoding the 10incoming message from a format such as an XML/SOAP message into an invocation of the 11component in native programming language. Demarshalling from protocol terminations to the 12native language is accomplished by generated components called skeletons that correspond to 13the stubs on the client-side. In some circumstances (the upper circle), the entire behaviour of a 14Grid Service is completely encapsulated within the component. In other cases (the lower 15circle), a component will collaborate with other server-side executables, to delegate certain 16operations to standard components or perhaps through an adapter layer designed to translate 17language invocation syntax, to complete the implementation of the Grid Service behaviour, or 18 6.1.3.Container-managed State 19A container implementation may provide a range of functionality beyond simple argument 20demarshalling. For example, the container implementation may provide lifetime management 21functions, automatic support for authorization and authentication, request logging, 22intercepting lifetime management functions and terminating service instances when a service 23lifetime expires or an explicit destruction request is received. Thus, we avoid the need to re- 24implement these common behaviours in different Grid Service implementations. 25Figure 66-35-19 shows a container that consists of multiple execution environments that can 26be selected to host a Grid Service instance and is a possible implementation of the J2EE 27container described in the EJB specification . In this implementation the state of the instance 28can be saved by the container at operation boundaries and restored in case a service instance 29fails due to software or hardware errors. 4 Page 40 of 79 5 6
  • 41. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 Figure 66-35-19: Container with state management 3Figure 66-35-19 includes Grid HandleResolver and Registry services so that the order of 4events required to create and access the service can be seen. The client has a permanent 5reference to the HandleResolver and uses it to resolve service Handles that become invalid. 6The client also has a handle to the registry service that it can use (1) to locate a suitable 7factory and, via the factory (2), create a Grid Service Instance (3a). The container is 8responsible for allocating the execution environment for the instance, establishing the service 9Reference and supplying this to the HandleResolver (4), and initialising the service state and 10managing the store/load operations. The factory returns to the client a Locator containing a 11Handle and a Reference to the new service Instance whichthat can be used to invoke service 12operations (5). If the execution environment fails, the container may allocate a new one with a 13new service Reference, load the state and supply the new reference to the HandleResolver. 14The client uses the Handle to obtain the updated Reference (6). 15 6.1.4.Replicated Copies of a Service Instance 16[This illustrates the use of multiple references simultaneously by different clients to access the 17same service Instance. See OpFAQHandleResolution for input material.] 4 Page 41 of 79 5 6
  • 42. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 Figure 66-45-20: Use of multiple references for the same Grid Service Instance 4 Page 42 of 79 5 6
  • 43. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 17.Using Grid Services 2This chapter introduces the following concepts that are needed to use the service instances 3described by the previous chapter. 4 • Locating services and communicating with them 5 • Ways in which collective information is used. 6We examine the client-side programming patterns for Grid Services. The patterns described in 7this section are enabled but not required by OGSI. We discuss these patterns in this section to 8help put into context concepts and details described in the other parts of the Primer and in the 9Specification. Ways of locating grid service instances, example use of a simple registry of 10factories, invoking and binding to grid service instances are also examined. 117.1.Client-Side Programming Patterns 12An important issue, that requires some explanation, particularly for those not familiar with 13Web Services, is how OGSI interfaces are likely to be invoked from client applications. 14OGSI exploits an important component of the Web Services framework: the use of WSDL to 15describe abstract interfaces and, separately, multiple protocol bindings, encoding styles, 16messaging styles (RPC vs. document-oriented), security tokens and so on, for a given Web 17Service. The Web Services Invocation Framework [WSIF] and Java API for XML RPC 18[JAXRPC] are examples of infrastructure software that provide the capability to separate 19interface from bindings and provide multiple bindings. There are many other examples. In 20each case, the basic structure is similar, and it provides a client-side architecture that can also 21be used to access OGSI services. 22 23 Figure 77-21: A client-side runtime architecture 24 25In Figure 77-21, the client application accesses a client-side representation of the Web 26Service, sometime called a proxy. The proxy calls, or uses components (shown as protocol- 4 Page 43 of 79 5 6
  • 44. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1specific stubs) that marshal parameters for the invocation of the Web Service over a chosen 2binding, and adds other necessary information such as protocol headers or security tokens 3obtained from the client’s runtime environment. 4There is a clear separation between the client application and the stub by the client-side 5interface that consists of the methods, procedure calls, parameters, exceptions and other 6interface features needed to invoke the service and receive responses and handle faults 7generated by the service. The client interface also defines exceptions that describe, in a 8generic way, errors arising from the binding mechanisms. These are dependent on the 9particular client infrastructure. 10The client’s interface to the service can be generated by taking the WSDL description of the 11Web Service interface and transforming it into interface definitions in a programming 12language specific way (e.g. Java interfaces or C#) suitable for the particular client-side 13architecture. The parameter marshalling and message routing stubs are generated from the 14various binding options provided by the WSDL. Generation of the interface and stubs can 15take place at various stages of development, deployment and execution of the client 16application: dynamic Web Service invocation leaves the generation of the binding and service 17address until execution time. 18This approach allows certain efficiencies, for example, detecting that the client and the Web 19Service exist on the same network host, and therefore avoiding the overhead of preparing for 20and executing the invocation using network protocols. 21It is possible, but not recommended, for developers to build customized code that directly 22couples client applications to fixed bindings of a particular service. Although certain 23circumstances demand potential efficiencies gained this style of customization, this approach 24introduces significant inflexibility into a system and therefore should only be used under 25extraordinary circumstances. 26We expect the stub and client side infrastructure model that we describe to be a common 27approach to enabling client access to Grid Service instances where each remote instance is 28represented by a proxy. This includes both application specific services as well as common 29infrastructure services that are defined by the OSGI Specification and described in this 30Primer. So, for most developers using Grid Services, the infrastructure and application level 31services appear in the form of a class library or programming language interface that is 32natural to the caller. 33The WSDL and the GWSDL extensions required by OGSI can be supported by heterogeneous 34tools and enabling infrastructure software by means of translation of GWSDL into WSDL . 357.2.Reasons for Registries 36Registries are sources of information about services (including resources) in a Grid. They are 37themselves Grid Services, and their function is to provide references to other services, 38perhaps based on some selection criteria such as the portType, or the capacity for resources to 39be allocated for a particular task. The criteria aren’t determined by the OGSI Specification 40and depend on the registry and the kind of information it provides. The following examples 41give a flavour of how registries and service information can be organized. 42 • Central directories are the starting point for enquiries about Grid Services and 43 resources. Their locations may be well-known to potential clients and they may keep 44 lists of more local registries. 4 Page 44 of 79 5 6
  • 45. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 • Partner Catalog registry [20]: Web Services to be used by a particular company can be 2 published to a Partner Catalog. A Partner Catalog registry sits behind the firewall and 3 contains only approved, tested, and valid Web Service descriptions from legitimate 4 business partners. The business context and metadata for these Web Services can be 5 targeted to the specific requestor. 6 • Local directories can contain references to factories capable of creating services 7 instances (including resource allocations, for example). Local information can contain 8 more detailed, precise and/or dynamic information. 9 • Factories may keep a list of the service instances they have created. 10Figure 77-22 shows the last two of alternatives described above as an example of the way 11information in registries can be related. 12 13 Figure 77-22: Factories and a dedicated Registry as information sources 14The example of a factory which also acts as a registry shows how a registry can be only one 15of several functions provided by a service. 16 7.2.1.The OGSI portTypes 17OGSI defines three portTypes that may be used to build registries: ServiceGroup. 18ServiceGroupEntry and ServiceGroupRegistration. 19A ServiceGroup is a collection of entries where each entry points to a member Grid service 20instance as well as a Grid service implementing the ServiceGroupEntry interface that is used 21for the purpose of managing the individual entries in the ServiceGroup (see Fig. 7.). All the 22member Grid service instances of a ServiceGroup must conform (i.e. be a, or subtype of,) at 23least one of the portTypes listed in the membershipContentRule SDE. Each 4 Page 45 of 79 5 6
  • 46. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1ServiceGroupEntry contains a locator for the member Grid service instance and information 2(content) about that service. The content element is an XML element advertising some 3information about the member service. The content model forms the basis on which search 4predicates can be formed and executed against the ServiceGroup with the findServiceData 5operation. The ServiceGroupRegistartion portType extends the ServiceGroup portType and 6provides a management interface (add and remove operations) for a ServiceGroup. The add 7operation creates a ServiceGroupEntry and adds it to the ServiceGroup while the remove 8operation removes each ServiceGroupEntry that matches an input expression. More details 9about the three ServiceGroup portTypes can be found in Chapter 11. 10 11 SDE membership Locator ContentRule ServiceGroupEntry content entry A member content GridService ServiceGroup Instance entry ServiceGroupEntry content content A member GridService Instance 12 Figure 77-3: ServiceGroup structure and its relation to ServiceGroupEntry 13 14 7.2.2.Example: a simple registry of service factories 15This example registry records the service factories currently running in one service container 16and is based on a ServiceGroup portType, not a ServiceGroupRegistration portType. It's a way 17of keeping track of current activity on one server. Any kind of factory can be registered: the 18registered services need have nothing in common except what is required by the OGSI 19standard. The main metadata of interest are the sets of port types provided by each service 20instance created by the factories. Hence, the metadata in this registry comes from the standard 21service data elements prescribed by OGSI for the Factory port-type. The 22ogsi:CreateServiceExtensibilityType elements in a factory port list as QNames of all the port- 23types of the service instances that the factory can create. 24For this example, suppose that there are just three factories, all for variants of a counter 25service. 26 • The basic counter factory which creates Instances that accept messages defined by the 27 counter portType and the GridService portType. 4 Page 46 of 79 5 6
  • 47. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 • The "private" counter factory, whose Instances enforce access control for a restricted 2 set of users, and which accept the messages defined by the SecureCounter portType 3 and the GridService portType. 4 • The "shared" counter factory, whose Instances are intended for concurrent use by more 5 than one client, and which accept messages defined by the Counter portType, the 6 NotificationSource portType and the GridService portType. 7As part of its entry serviceDataValues this registry (ServiceGroup) could contain the 8following values 9 <!-- Specific values for this registry. --> 10 <ns:serviceDataValues xmlns:ns=…> 11 <!-- Description of basic-counter factory. --> 12 <entry xmlns:ogsi= …> 13 <serviceGroupEntryLocator nil="true"/> 14 <memberServiceLocator> 15 <ogsi:handle> 16 http://exemplar.org/ogsa/services/CounterFactory 17 </ogsi:handle> 18 </memberServiceLocator> 19 <content> 20 <ogsi:CreateServiceExtensibilityType> 21 <createsInterface>Counter</createsInterface> 22 <createsInterface>GridService</createsInterface> 23 </ogsi:CreateServiceExtensibilityType> 24 </content> 25 </entry> 26 27 <!-- Description of private-counter factory. --> 28 <entry> 29 <serviceGroupEntryLocator nil="true"/> 30 <memberServiceLocator> 31 <ogsi:handle> 32 http://exemplar.org/ogsa/services/PrivateCounterFactory 33 </ogsi:handle> 34 </memberServiceLocator> 35 <content> 36 <ogsi:CreateServiceExtensibilityType> 37 <createsInterface>SecureCounter</createsInterface> 38 <createsInterface>GridService</createsInterface> 39 </ogsi:CreateServiceExtensibilityType> 40 </content> 41 </entry> 42 43 <!-- Description of shared-counter factory. --> 44 <entry> 45 <serviceGroupEntryLocator nil="true"/> 46 <memberServiceLocator> 47 <ogsi:handle> 48 http://exemplar.org/ogsa/services/SharedCounterFactory 49 </ogsi:handle> 50 </memberServiceLocator> 51 <content> 52 <ogsi:CreateServiceExtensibilityType> 53 <createsInterface>Counter</createsInterface> 54 <createsInterface>GridService</createsInterface> 55 <createsInterface>NotificationSource</createsInterface> 56 </ogsi:CreateServiceExtensibilityType> 4 Page 47 of 79 5 6
  • 48. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 </content> 2 </entry> 3 </ns:serviceDataValues> 4Notes on the example above 5 • Elements with the ‘ogsi’ prefix are defined in the OGSI standard. 6 • The serviceGroupEntryLocator elements are all annulled. The content of this registry 7 is build using standard OGSI GridService::setServiceData operation: it does not use 8 the add operation from the ServiceGroupRegistration portType. 9 • The memberServiceLocator elements contain handle elements that give the GSHs of 10 the registered factories. The given GSHs follow the HTTP scheme for GSHs used by 11 Globus Toolkit 3; other forms for handles are possible. 12A client can use the registry to select factories for particular kinds of counter as follows. 13The client invokes findServiceData on the registry's GridService port. The client includes this 14as the queryExpression parameter of the invoked operation: 15 <ogsi:queryByServiceDataNames> 16 <name>entry</name> 17 </ogsi:queryByServiceDataNames> 18The result of the operation is a dump of all the metadata for all the services (all entry 19elements) as shown in the serviceDataValues document above. 20The client runs these metadata through an XPath search-engine (an XSLT processor is a likely 21implementation of this) using this query: 22 //ogsi:EntryType[content/ogsi:CreateServiceExtensibilityType/createsInter 23 face="NotificationSource"] 24to find all the factories for counters that do notification. The client is then left with one entry 25element: 26 <entry> 27 <serviceGroupEntryLocator nil="true"/> 28 <memberServiceLocator> 29 <ogsi:handle> 30 http://exemplar.org/ogsa/services/SharedCounterFactory 31 </ogsi:handle> 32 </memberServiceLocator> 33 <content> 34 <ogsi:CreateServiceExtensibilityType> 35 <createsInterface>Counter</createsInterface> 36 <createsInterface>GridService</createsInterface> 37 <createsInterface>NotificationSource</createsInterface> 38 </ogsi:CreateServiceExtensibilityType> 39 </content> 40 </entry> 41The client runs a further XPath search using query 42 //ogsi:handle 43to extract the GSH of the selected service. 44 4 Page 48 of 79 5 6
  • 49. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 17.3.Service discovery and Invocation 2Depending on how a client intends to interact with a Grid service, it will need a GSH or GSR 3to start with. The client might read such information through an out-of-band mechanism such 4as a configuration file. If a Registry is used to locate a Grid Service or Factory for that Grid 5Service, then the GSH/GSR of the Registry service needs to be known up-front by the client. 6Different VOs may have very different needs for their bootstrap services, but these services 7must be available to clients through some out-of-band mechanism. Such services are managed 8by the hosting environment, are usually deployed and created at container start-up and live for 9as long as the container persists. 10 117.4.Binding to a Service 12[bootstrapping to find information about resources and factories] 13 14[Resolvers this needs an example] 15[Spec Section 3.3 Client Use of Grid Service Handles and References] 16A client gains access to a Grid Service instance through Grid Service Handles and Grid 17Service References. A Grid Service Handle (GSH) can be thought of as a permanent network 18pointer to a particular Grid Service instance. The GSH does not provide sufficient information 19to allow a client to access the service; the client needs to “resolve” a GSH into a Grid Service 20Reference (GSR). The GSR contains all the necessary information to access the service. The 21GSR is not a “permanent” network pointer to the Grid Service instance because a GSR may 22become invalid for various reasons; for example, the Grid Service instance may be moved to a 23different server. 24OGSI provides a mechanism, the HandleResolver (see §10) to support client resolution of a 25Grid Service Handle into a Grid Service Reference. In Figure 77-26-23, a client application 26needs to resolve a GSH into a GSR. 4 Page 49 of 79 5 6
  • 50. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 Figure 77-26-23: Resolving a GSH 3The client resolves a GSH into a GSR by invoking a HandleResolver Grid Service identif ied 4by some out-of-band mechanism. The HandleResolver can use various means to do the 5resolution; some of these means are depicted in Figure 2. The HandleResolver may have the 6GSR stored in a local cache. The HandleResolver may need to invoke another 7HandleResolver to resolve the GSH. The HandleResolver may use a handle resolution 8protocol, specified by the particular kind (or scheme) of the GSH to resolve to a GSR. The 9Handle resolver protocol is specific to the kind of GSH being resolved. For example, one kind 10of handle may suggest the use of HTTP GET to a URL encoded in the GSH order to resolve 11to a GSR. 4 Page 50 of 79 5 6
  • 51. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 18.The GridService portType 2To be a Grid Service a service must implement the interface and behaviour that enables clients 3to manage it like other Grid Services. In summary, the behaviours allow clients to locate or 4create service instances, call them and arrange for their destruction when they are no longer 5needed. These behaviours are defined in the Grid Service Specification as portTypes, 6beginning with the basic GridService that is common to all OGSI services. 78.1.The basic requirement: GridServiceportType 8[This is based on Section 9 of the spec]. 9We start with the GridService portType, which must be implemented by all Grid Services and 10thus serves as the base interface definition in OGSA. This portType is analogous to the base 11Object class within object -oriented programming languages such as Smalltalk or Java, in that 12it encapsulates the root behaviour of the component model. The behaviour encapsulated by 13the GridService portType is that of 14 • The required elements the serviceDataSet and the semantics associated with these 15 elements. 16 • Managing the termination of the instance 17 8.1.1.Terminology: Service Description and Service Instance 18(This is from the spec, Section 7.1) 19We distinguish in OGSA between the description of a Grid Service and an instance of a Grid 20Service: 21 • A Grid Service description describes how a client interacts with service instances. This 22 description is independent of any particular instance. Within a WSDL document, the 23 Grid Service description is embodied in the most derived portType (i.e. the portType 24 referenced by the wsdl:service element describing the service) of the instance, along 25 with its associated portTypes, serviceDataDescriptions, messages, and types 26 definitions. 27 • A Grid Service description may be simultaneously used by any number of Grid 28 Service instances, each of which: 29 o embodies some state with which the service description describes how to 30 interact; 31 o has one or more Grid Service Handles; 32 o and has one or more Grid Service References to it. 33A common form of Grid Service Reference (defined in Section ?) is a WSDL document 34comprising a service element, that carries an attribute that refers to a most derived portType 35defined by the service description of that instance. 36A service description is primarily used for two purposes. First, as a description of a service 37interface, it can be used by tooling to automatically generate client interface proxies, server 38skeletons, etc. Second, it can be used for discovery, for example, to find a service instance that 4 Page 51 of 79 5 6
  • 52. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1implements a particular service description, or to find a factory that can create instances with 2a particular service description. 3The service description is meant to capture both interface syntax, as well as (in a very 4rudimentary, non-normative fashion) semantics. Interface syntax is, of course, described by 5portTypes. 6Semantics may be inferred through the name assigned to the portType. For example, when 7defining a Grid Service, one defines zero or more uniquely named portTypes, and then 8collects a set of portTypes defined from a variety of sources into a final or most derived 9portType. Concise semantics can be associated with each of these names in specification 10documents – and perhaps in the future through Semantic Web or other formal descriptions. 11These names can then be used by clients to discover services with the sought-after semantics, 12by searching for service instances and factories with the appropriate names. Of course, the use 13of namespaces to define these names provides a vehicle for assuring globally unique names. 148.2.GridService Service Data 15[Enumerate the servicedata elements and describe their purpose.] 16 17 18[This is from Section 6.2 of the spec] 19For example, the following portType declares two serviceData elements, with qualified names 20“tns:sd1” and “tns:sd2”. Any service that implements this portType MUST have as part of its 21state these two ServiceDataserviceData elements. 22 <wsdl:definitions xmlns:tns=”xxx” targetNamespace=”xxx”> 4 Page 52 of 79 5 6
  • 53. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 <gwsdl:ogsi:portType name="exampleSDUse"> * 2 <wsdl:operation name=…> 3 … 4 <sd:serviceData name="sd1" type=”xsd:String” 5 mutability=”static”/> 6 <sd:serviceData name="sd2" type=”tns:SomeComplexType”/> 7 … 8 <sd:staticServiceDataValues> 9 <tns:sdl>initValue</tns:sd1> 10 </sd:staticServiceDataValues> 11 </gwsdl:ogsi:portType> 12 … 13 </wsdl:definitions> 14 8.2.1.Using serviceData, an Example from GridService portType 15[From Section 6.2.2 of the Spec] 16Let’s examine how serviceData can be used by reviewing an example, namely the 17GridService portType, described in §9. The (non-normative) serviceData elements declared 18for the Grid Service portType are as follows. 19 <wsdl:definitions … 20 <gwsdl:ogsi:portType name=”GridService” …> 21 <wsdl:operation name= …> 22 … 23 <sd:serviceData name=”interface” type=”xsd:QName” 24 minOccurs=”1” maxOccurs=”unbounded” 25 mutability=”constant”/> 26 <sd:serviceData name=”serviceDataName” type=”xsd:QName” 27 minOccurs=”0” maxOccurs=”unbounded” 28 mutability=”mutable” nillable=”false”/> 29 <sd:serviceData name=”factoryHandle” 30 type=”ogsi:HandleType” 31 minOccurs=”1” maxOccurs=”1 32 mutability=”constant” nillable=”true”/> 33 <sd:serviceData name=”gridServiceHandle” 34 type=”ogsi:HandleType” 35 minOccurs=”0” maxOccurs=”unbounded” 36 mutability=”extendable”/> 37 <sd:serviceData name=”gridServiceReference” 38 type=”ogsi:ReferenceType” 39 minOccurs=”0” maxOccurs=”unbounded” 40 mutability=”mutable”/> 41 <sd:serviceData name=”findServiceDataExtensibility” 42 type=”ogsi:OperationExtensibilityType” 43 minOccurs=”1” maxOccurs=”unbounded” 44 mutability=”static”/> 45 <sd:serviceData name=”terminationTime” type=”ogsi:terminationTime” 46 minOccurs=”1” maxOccurs=”1” 47The normative description of the individual serviceData elements are in (§9.1). 48The following is an example set of serviceData element values for a Grid Service. 49 … 50 xmlns:crm=”http://gridforum.org/namespaces/2002/11/crm” 51 xmlns:tns=”http://example.com/exampleNS” 52 xnlns=”http://example.com/exampleNS”> 4 Page 53 of 79 5 6
  • 54. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 <sd:serviceDataValues> 1 <ogsi:interface>crm:GenericOSPT</ogsi:interface> 2 <ogsi:interface>ogsi:GridService</ogsi:interface> 3 <ogsi:serviceDataName>ogsi:interface 4 </ogsi:serviceDataName> 5 <ogsi:serviceDataName>ogsi:serviceDataName 6 </ogsi:serviceDataName> 7 <ogsi:serviceDataName>ogsi:factoryHandle 8 </ogsi:serviceDataName> 9 <ogsi:serviceDataName>ogsi:gridServiceHandle 10 </ogsi:serviceDataName> 11 <ogsi:serviceDataName>ogsi:gridServiceReference 12 </ogsi:serviceDataName> 13 <ogsi:serviceDataName>ogsi:findServiceDataExtensibility 14 </ogsi:serviceDataName> 15 <ogsi:serviceDataName>ogsi:terminationTime 16 </ogsi:serviceDataName> 17 <ogsi:serviceDataName>ogsi:setServiceDataExtensibility 18 </ogsi:serviceDataName> 19 <ogsi:factoryHandle>someURI</ogsi:factoryHandle> 20 <ogsi:gridServiceHandle>someURI</ogsi:gridServiceHandle> 21 <ogsi:gridServiceHandle>someOtherURI</ogsi:gridServiceHandle> 22 <ogsi:gridServiceReference>…</ogsi:gridServiceReference> 23 <ogsi:gridServiceReference>…</ogsi:gridServiceReference> 24 <ogsi:findServiceDataExtensibility 25 inputElement=”ogsi:queryByServiceDataNames” /> 26 <ogsi:terminationTime after=”2002-11-01T11:22:33” 27 before=”2002-12-09T11:22:33”/> 28 <ogsi:setServiceDataExtensibility 29 inputElement=”ogsi:setByServiceDataNames” /> 30 8.2.2.ServiceData Initial values 31See example text in the spec (Section 6.3.1) 32 8.2.3.ServiceData and portType Inheritance 33See example text in the spec (Sections 6.4 and 6.4.1) 34 8.2.4.ServiceData Bindings 35[From the spec Section 6.2, last para] 36The wsdl:binding associated with various operations manipulating serviceData elements will 37indicate the encoding of that data between service requestor and service provider. For example, a 38binding might indicate that the serviceData element values are encoded as serialized Java objects. 398.3.GridService Operations 40[Summary of Querying and modyfing servicedata, termination time. Destrying a service. 41Sufficient to inform the following example] 42 8.3.1.Querying ServiceData 43[From Section 9.2.1.1 of the spec) 44For example, a findServiceData invocation with this QueryExpression: 4 Page 54 of 79 5 6
  • 55. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 <ogsi:queryByServiceDataNames> 2 <name>ogsi:findServiceDataExtensibility</name> 3 <name>ogsi:setServiceDataExtensibility</name> 4 </ogsi:queryByServiceDataNames> 5might return this Result:. 6 <sd:serviceDataValues> 7 8 <ogsi:findServiceDataExtensibility 9 inputElement=”ogsi:queryByServiceDataNames”/> 10 <ogsi:setServiceDataExtensibility 11 inputElement=”ogsi:setByServiceDataNames”/> 12 <ogsi:setServiceDataExtensibility> 13 inputElement=”ogsi:deleteByServiceDataNames”/> 14 </sd:serviceDataValues> 15 8.3.2.GridService Examples 17[Develop the example of the Counter with Servicedata defined] 18 19 20 Figure 88-24: Counter ServiceData 219. 4 Page 55 of 79 5 6
  • 56. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 110.Handle Resolution 2As discussed in Chapter 4, a Grid service instance is identified by one or more Grid Service 3Handles (GSHs). However, a GSH does not contain enough information for a consumer to 4communicate with the identified Grid service instance. The consumer needs to get hold of at 5least one Grid Service Reference (GSR) which contains the necessary information for 6communicating with the identified Grid service instance (Chapter 4). 7Grid service instances that implement the HandleResolver portType, also referred to as 8handle resolvers, can be used to map a GSH to one or more GSRs. The OGSI specification is 9silent on the semantics or the mechanisms of the mapping. It is up to service implementers to 10define the characteristics of the relationship between a GSH and its associated GSRs. 11Implementers are also responsible for the way the information about that relationship is made 12available to the handle resolver, as illustrated in Figure ??. Of course, as with any other Grid 13service instance, a handle resolver is free to implement any logic behind the HandleResolver 14portType. OGSI only requires a handle resolver to adhere to the following: 15 • It must include a Service Data Element called handleResolverScheme; and 16 • It must support an operation called findByHandle. 1710.1.The handleResolverScheme SDE 18A handle resolver advertises the URI schemes that it understands through the 19handleResolverScheme SDE. As already described in Chapter 4, a GSH is a URI for which 20OGSI does not impose a particular URI scheme. However, host environments or factories 21may decide to adopt a particular URI scheme for identifying new Grid service instances. It is 22expected that the community will agree on standard URI schemes. For example, a factory for 23counter Grid service instances may use the “counter:global-unique-identifier” scheme for the 24GSHs of new instances or another factory may use the 25http://www.counter.com/grid/service/instance/10 scheme.a host environment that 26automatically creates banking Grid service instances adopts the “bank:sort-code:account- 27number” scheme. 28A particular handler resolver may only understand GSHs of a particular URI scheme. A 29consumer of the Grid service instance implementing the HandleResolver portType may get 30the names of the supported URI schemes through the handleResolverScheme SDE. 31For example, a handle resolver for GSHs identifying counter Grid service instances will set 32the value of the handleResolverScheme SDE to “counter”. A handle resolver that also supports 33GSHs using the “http” schemepointing to banking Grid service instances will have two SDEs: 34“counter” and “httpbank”: 35 <serviceDataValues> 36 <handleResolverScheme>counter</handleResolverScheme> 37 <handleResolverScheme>httpbank</handleResolverScheme> 38 </serviceDataValues> 39The service data declaration of the handleResolverScheme SDE defines that its value can 40change throughout the lifetime of the handle resolver (mutability=”true”) but only by the 41handle resolver (modifiable=”false”). Also, a value of xsi:nil is allowable suggesting 42indicating that the handle resolver may be able to resolve all URI schemes. 4 Page 56 of 79 5 6
  • 57. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 110.2.The findByHandle operation 2 10.2.1.Input 3The only operation that is declared as part of the HandleResolver portType is the 4findByHandle operation, which accepts a locator as input, the HandleSet, containing one or 5more GSHs. As the definition of the locator dictates, the GSHs contained in the HandleSet 6must point to the same Grid service instance. The handle resolver is free to choose any of the 7GSHs in the HandleSet for the resolution process. 8The HandleSet may also contain one or more GSRs to the same Grid service instance. The 9implementer of the handle resolver is free to ignore these GSRs or use them for the resolution 10process. 11The GSRExclusionSet is an optional input to the findByHandle operation. It is a locator that 12contains one or more set of GSRs that the handle resolver must not return as part of the result 13of the resolution process. The handle resolver does not care why these GSRs had to be 14excluded. If the GSRExclusionSet locator contains any GSHs, they are going to be ignored by 15the handle resolver. 16 10.2.2.Output 17The output of the findByHandle operation is a locator that contains one or more GSRs, the 18outcome of the resolution process. All the GSHs in the HandleSet will also be included in the 19locator. The handle resolver may decide to include additional GSHs to the same Grid service 20instance, if it deems that this is necessary. 21 10.2.3.Faults 22A number of faults may be generated as a result of calling the findByHandleOperation 23operation. 24 • The InvalidHandleFault is returned when one of the GSHs in the HandleSet input 25 parameter violates the syntax of its URI scheme. 26 • When the resolver cannot return a GSR that is not already contained in the 27 GSRExclusionSet input parameter, the NoAdditionalReferencesAvailableFault is 28 returned. 29 • However, even if the GSRExclusionSet input parameter is empty but the resolver is 30 still unable to return a GSR, the NoReferencesAvailableFault is returned. which may 31 be extend to carry more information about what may have gone wrong: 32 NoSuchServiceFault, NoSuchServiceStartedFault, ServiceHasTerminatedFault, and 33 TemporarilyUnavailableFault. 34 • It is possible that the handle resolver knows of another handle resolver that may be 35 capable of performing the resolution. The RedirectionFault is returned in such a 36 situation with the GSH of the new handle resolver. 37 • If another fault occurs, the Fault is returned. 38[Suggestion: this is the place to answer questions about the relationship between a service 39implementation and the HandleResolver?. There is some input in OpFAQHandleResolution] 40[Suggestion: is this the place to explain solutions to the bootstrap problem - how to get a 41reference to the handle resolver] 4 Page 57 of 79 5 6
  • 58. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1[Suggestion: explain the rationale behind the GSRExclusionSet? input to findByHandle ] 2[Question: In Section 7.5.1.1. the spec recommends only including minumal info in the 3WSDL version of a GSR. What other information is possible? Why is it discouraged] 4 4 Page 58 of 79 5 6
  • 59. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 111.Finding Services: ServiceGroups and Registries 2In chapter 7 the rationale for Registries was given. The ServiceGroup, ServiceGroupEntry and 3ServiceGroupRegistration portTypes were introduced and the use of an example registry of 4factories, from the client perspective, was given. This chapter is mostly concerned with the 5problem of creating and managing registries of Grid services. Some explanation on how 6registries are organised and the details of the ServiceGroup portTypes are given. OGSA 7registries are expected to be built on these base ServiceGroup portTypes provided by OGSI . 8OGSA registries are also likely to implement other portTypes such as the NotificationSource 9portType which allows clients to subscribe to registry state changes. 1011.1.The Registry Interfaces 11There are two components to a registry – Registration and Discovery. Registration places a 12service Locator in the registry and Discovery allows a client to retrieve it. Though it’s logical 13to think of these as two parts of the same service, this is not necessarily the best way to 14organize the information. The Discovery service can use the registered Locators to find out 15more information about the services, for example dynamic information such as the current 16resource capacity and it may pass this on to a third party that provides selection among a 17collection of similar services. A Discovery service can also provide qualities of its own such 18as scalability which are independent of the qualities of the registration. 19 11.1.1.The purpose of registries in OGSA 20A registry is a very general concept. In computing, we may define it as a catalogue of objects, 21described and indexed by the objects’ metadata. The objects may be either inside the 22computing system (i.e. the objects consist entirely in data); or they may be real-world items, 23with only metadata inside the computing system; or they may be computing-system proxies 24for real-world objects. In all cases, the essence of the registry pattern is that a registry stores 25some part of an object’s metadata without storing either the object itself or (for a real-world 26object) its proxy. 27Given a registry, clients may inspect the metadata and use them to reason about the 28catalogued objects. Typically, clients then use the metadata to locate and access some of the 29catalogued objects. Often, the only use of the registry is to locate the objects. 30OGSI is concerned with registries of Grid Services. Grid Services can be used to build other 31kinds of registries, but OGSI has specific portTypes that can be used to build registries where 32the entries describe Grid Services. 33The essential requirement of a service registry is that the metadata include a Locator for each 34catalogued service. The registry itself need not resolve the Locators to include valid GSRs, 35although the service running the registry may also include a HandleResolver port for this 36purpose. From OGSA's point of view, "locating" a service instance through a registry means 37finding its persistent Handle. 38 11.1.2.OGSI support for service registries 39In OGSA, service registries have two uses: 40 • finding service factories from which to make new instances; 41 • finding existing instances. 4 Page 59 of 79 5 6
  • 60. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1Both uses are covered by the following three OGSI portTypes: 2 • serviceGroup 3 • serviceGroupEntry 4 • serviceGroupRegistration 5A ServiceGroup portType maintains information about a group of other Grid services. These 6services may be members of a group for a specific reason, such as being part of a federated 7service, or they may have no specific relationship, such as the services contained in an index 8or registry operated for discovery purposes. A classical Grid services registry (container 9registry) could be defined by a portType that extends the base behaviour described by 10ServiceGroup. The ServiceGroup portType extends the GridService portType. 11The serviceGroupEntry portType defines the interface through which the lifetime of 12individual entries in a service group may be managed. Each ServiceGroupEntry service refers 13to (is a proxy of) a Grid service instance that is a member of the ServiceGroup. Membership 14registration through a ServiceGroupEntry instance is a soft state operation that must be 15periodically refreshed, thus allowing discovery services to deal naturally with dynamic 16service availability. The ServiceGroupEntry portType extends the GridService portType. 17The ServiceGroupRegistration portType provides a management interface (add and remove 18operations) for a ServiceGroup. The add aperation creates a ServiceGroupEntry and adds it to 19the ServiceGroup. The remove operation removes each ServiceGroupEntry that matches the 20MatchExpression input parameter of the remove operation. The ServiceGroupRegistration 21portType extends the ServiceGroup portType. 22 23 11.1.3.Factory and instance registration 24An OGSI factory is normally created when the hosting environment is first started and lives 25for as long as the container lives. Registration of factories and other persistent services is best 26carried out during instantiation of the Registry service. 27Following a createService operation from a client, a factory creates a new Grid Service 28Instance and returns a locator to the client. OGSI does not prescribe the way in which new 29Instance is registered, or even whether it should be. Either the factory or the newly created 30Instance could use the ServiceGroupRegistration add operation to register the new Instance in 31a registry. As one example where it may be useful, note that instances created by Factories 32may support the Factory portType and as such are themselves Factories; registration allows 33these new factories to be discovered. 34 11.1.4.Making Discoveries 35The operations inherited from GridService portType may be used to query service data in a 36registry as shown in the example in chapter 7. The example illustrates the use of a simple 37queryByService on the content of a registry. More powerful discoveries could be built using 38XPath or XQuery. The Registry may implement other specialised operations for the purpose 39of querying its content. 4 Page 60 of 79 5 6
  • 61. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 111.2.Grouping services: The ServiceGroup portType 2 Below is a diagram of the WSDL markup elements that describe the ServiceGroup portType. 3 4 Figure 1010-25: GWSDL Description of Service Group. 5ServiceGroup allows a collection of Grid services to be maintained and managed. This 6portType has no operation and consists of two SDE elements: membershipContentRule and 7entry as well as the SDE’s and operations inherited from GridService. 8 11.2.1.The membershipContentRule SDE: 9This SDE can be used to restrict the membership Grid service instances in a ServiceGroup, by 10specifying the “rules” that must be satisfied before membership is allowed. The rules, as 11shown in Figure 10-1, specify the following: 12 • A list of interfaces the member Grid service instances may implement. Each service 13 instance that is a member of a ServiceGroup must implement one or more interfaces 14 from this list. 15 • For each interface, zero or more contents which describe the member. Typically these 16 are names of its SDEs, identifiable through QName, that are needed for a member to 17 become a part of this group. (The contents of QName are described in the 18 ServiceGroupEntry). 19This service data has a mutability value of "constant" and hence these rules are created by the 20runtime on ServiceGroup service startup. 21 22 11.2.2.The entry SDE: 23The entry SDE is a compound element made of three components as shown in Figure 10-1: 24 • a Locator element pointing to the registered service itself; 25 • an extensible content element that contains unconstrained metadata describing the 26 registered service. The content element is an XML element advertising some 27 information about the member service. 28 • a Locator element pointing to the registration proxy for the registered service; 4 Page 61 of 79 5 6
  • 62. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 211.3.Proxies for ServiceGroup members: The ServiceGroupEntry portType 3The registry facility also has one ServiceGroupEntry Instance for each registered member. 4The intention is to have the appearance of a registration proxy service in order to use the 5lifetime management facilities of the GridService portType and limit the lifetime of 6registration. In practice, a registry may implement these proxy services in some light-weight 7form in order to save resources. That is, a registry for a trivial number of services may use 8conventional service instances for its proxy services, using ordinary service containers, while 9a registry intended for thousands of registrants may be built as a specialized service container 10with a more scalable implementation of the proxies. The ServiceGroupRegistration portType 11provides an operation which creates the ServiceGroupEntry Instances. The 12ServiceGroupEntry portType extends the GridService portType to which it adds two new 13SDE: memberServiceLocator and content. 14 11.3.1.The memberServiceLocator SDE: 15This SDE contains a service locator to the Grid service instance whose membership of the 16ServiceGroup is managed by this ServiceGroupEntry. 17 11.3.2.The content SDE: 18This SDE contains information about the member Grid service instance. Since membership of 19a ServiceGroup is restricted by membershipContentRule SDE , this content SDE must satisfy 20any restrictions specified in the membershipContentRule SDE. If the member Grid service 21instance implements several memberInterfaces included in the membershipContentRule SDE 22values, all content elements associated with any of these memberInterfaces must be included 23in this content SDE. 2411.4.Managing ServiceGroup membership: The ServiceGroupRegistration 25portType 26In a registry implementing the ServiceGroupRegistration portType, clients can call the add 27operation of the ServiceGroupRegistration portType to register a service and the remove 28operation to de-register services. Each call to add registers one service. Each call to remove 29deregisters a set of related services. A registration proxy can be set to terminate at a certain 30time, in the normal manner of OGSI services, thus limiting the lifetime of a registration. 31The ServiceGroupRegistration portType extends the ServiceGroup portType by adding two 32new SDE: addExtensibility and removeExtensibility and two new operations: add and 33remove. The separation of the Registration operations from the Discovery operations of the 34ServiceGroup can be used to provide different access controls on these two aspects of 35registries. 36 11.4.1.The addExtensibility SDE: 37This contains a set of operation extensibility declarations for the add operation. Any 38inputElement declared by the value of his SDE may be used as the Content parameter to the 39instance’s add operation, and implies the add semantics and return values that may result from 40the add operation. These addExtensibility elements may be different from the elements listed 41in the membershipContentRule SDE because the content may be derived from them or 42referenced by them. 4 Page 62 of 79 5 6
  • 63. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 11.4.2.The add operation: 2The add operation creates a ServiceGroupEntry and adds a corresponding entry in the Service 3Group. This operation takes two mandatory parameters (Service Locator and Content) and an 4optional parameter (TerminationTime), outputs two parameters (ServiceLocator and 5CurrentTerminationTime) or may generate a number of Faults. 6 7The ServiceLocator input parameter is a locator for the member Grid service instance. The 8Content input parameter must conform to an input element declaration denoted by one of the 9addExtensibility SDE values. The add operation converts the value in the Content argument 10into an element conformant with one or more of the entries contained in the 11membershipContentRule. This transformation is based on the type of Grid service as inferred 12by the ServiceLocator and processed according to ServiceGroup specific semantics. The 13resulting transformed Content becomes the ServiceGroupEntry Content SDE. Finally the 14TerminationTime input parameter is used to specify the earliest and latest initial termination 15times of the created ServiceGroupEntry service instance. 16 17The ServiceLocator output parameter refers to the newly created ServiceGroupEntry. The 18CurrenTerminationTime time refers the ServiceGroupEntry’s currently planned termination 19time. 20 21The set of Faults that may be returned from the add operation are: 22ExtensibilityNotSupportedFault, ExtensibilityTypeFault, ContentCreationFailedFault, 23UnsupportedMemberInterfaceFault, AddRefusedFault and the generic OGSI Fault that 24encompasses all other Faults. 25 11.4.3.The removeExtensibility SDE: 26This contains a set of operation extensibility declarations for the remove operation. Any 27inputElement declared by value of his SDE may be used as the MatchExpression parameter to 28the instance's remove operation, and implies the remove semantics and return values that may 29result from the remove operation. OGSI defines one standard removeExtensibility SDE value: 30matchByLocatorEquivalence. 31 11.4.4.The remove operation: 32The remove operation removes all entries from the ServiceGroup that matches the operation’s 33input argument. This operation takes one input parameter (MatchExpression), has no output 34parameters except acknowledgement of the operation completion and may generate a number 35of Faults. 36 37The MatchExpression input parameter must conform to an inputElement declaration denoted 38by one of the removeExtensibility SDE values. The MatchExpression is evaluated against all 39entries in a ServiceGroup. Each entry that matches is removed. For example the 40matchByLocatorEquivalence expression compares one or more locators for textual equality 41with the canonical XML form of the memberServiceLocator of each entry contained in the 42ServiceGroup and removes the entries for which there is a match. This operation has no effect 43on the member Grid services referred to in the removed entries. 44 45The set of Faults that may be returned from the add operation are: 46ExtensibilityNotSupportedFault, ExtensibilityTypeFault, MatchFailedFault, 47RemoveFailedFault and the generic OGSI Fault that encompasses all other Faults. 4 Page 63 of 79 5 6
  • 64. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 4 Page 64 of 79 5 6
  • 65. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 312.Creating Transient Services: The Factory 4From a programming model perspective, a factory is an abstract concept or pattern. A 5consumer may use a factory to create an instance of a Grid Service and receive a locator for it. 6Any service may be a factory of other grid service instances without having to adhere to a 7specific interface. Nevertheless, the OGSI specification defines a standard portType for a 8factory Grid Service Instance for those service implementers wishing to provide a general, 9rather than service-specific, interface for creating new instances. 10The OGSI specification suggests that any newly created Grid Service Instance should be 11registered with a handle resolver in order to receive a GSH. The mechanism by which this 12may take place is implementation-specific. 13As with all Grid Services, the factory has to extend the GridService portType and introduces 14one SDE and one operation. 1512.1.The createServiceExtensibility SDE 16As explained in Section [??], for each extensible operation in a portType there should be a 17service data declaration of type OperationExtensibilityType. The createServiceExtensibility 18SDE is such a declaration. Its type is CreateServiceExtensibilityType which extends 19OperationExtensibilityType to include the set of portTypes that the grid service instance to be 20created should support. Implementers of the Factory portType may decide to provide 21additional extensibility elements that should be declared through this SDE. 22o The createService operation 23 12.1.1.Input 24The createService operation of the Factory portType accepts two arguments as input. 25 • TerminationTime. This is optional and allows the client calling the createService 26 operation to specify the earliest and latest initial termination times of the Grid Service 27 Instance to be created. The factory will select an initial termination time from the 28 window specified by the client and will return it. 29 • CreationParameters. This too is an optional argument and must conform to one of the 30 extensibility parameter declarations defined as values of the createServiceExtensibility 31 SDE. It is used when the requestor wishes to send additional information to the service 32 instance implementing the factory portType. For example, a factory may advertise 33 through the createServiceExtensibility SDE more than one supported combinations of 34 interfaces that created service instances can support. A requestor can use the 35 CreationParameters to select which of the combinations the new service instance 36 must support. 37 12.1.2.Output 38As a result of requesting the creation of a new service instance, the requestor receives: 39 • A Locator (refer to Section , page ) to the newly created service instance. 4 Page 65 of 79 5 6
  • 66. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 • The CurrentTerminationTime, which is an element identifying the planned termination 2 time for the newly created service instance. Of course, consumers may request for this 3 value to change through the operations provided by the GridService portType (Section 4 8, page 51). A consumer can also get the time that the grid service instance was 5 actually created from this element from the timestamp attribute. 6The service instance implementing the Factory portType may also decide to return an 7ExtensibilityOutput element which is specific to the service instance created. 8 12.1.3.Faults 9The different faults that may be communicated back to the consumer are: 10 • ExtensibilityNotSupportFault. The type of the CreationParameters was not supported 11 by the service instance that received the request. 12 • ExtensibilityTypeFault. The value of the CreationParameters input element could not 13 be validated its declared type. 14 • ServiceAlreadyExistsFaultI. If the service instance that was supposed to be created 15 already existed, this fault is returned which also carries the locator to it. 16 • Fault. Any other fault that may occur. 1712.2.Example 18[Savas to fill this in] 4 Page 66 of 79 5 6
  • 67. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 113.GridService Notification 213.1.Notification Source and Notification Sink 3A Grid Service which wants to notify its clients of changes to its state should implement 4NotificationSource portType. Such a grid service (also called source) can send notification 5messages to any number of clients. A client (also called a sink) that wish to receive 6notification messages should implement NotificationSink portType. 7A notification message is an XML element that is sent from the source to the sink. The type of 8the notification message is determined by the subscription expression. A subscription 9expression also describes what messages should be sent and when it should be sent based on 10changes to values within the serviceDataSet of the grid service instance implementing 11NotificationSource interface. 1213.2.Subscription Model 13To enable notifications, a Grid Service must implement the Notification Source portType. 14The following example adds notification support to the counter example explained in section 155.73.2 16 17 <definitions> 18 ……………………………… 19 <gwsdl:portType 20 name="NotificationcounterPortType" 21 extends="counter:CounterPortType ogsi:NotificationSource"/> 22 ……………………………… 23 </definitions> 24 25The NotificationSource portType extends the GridService portType and have two SDEs and 26one operation. 2713.3.NotificationSource : Service Data Declarations 28NotificationSource defines two SDEs to control the scope and nature of subscriptions. 29 13.3.1. notifiableServiceDataName 30The notifiableServiceDataName SDE is used to contains the QNames of the service data 31elements to which a client can subscribe for notification of changes. 32 13.3.2.subscribeExtensibility SDE 33The subscribeExtensibility SDE is used for expressing the nature of subscription. Every Grid 34service instance that implements the NotificationSource portType must support a 35subscribeExtensibility SDE value of subscribeByServiceDataNames. 36subscribeByServiceDataNames allows clients to receive notifications whenever the 37corresponding value(s) of SDE is changed. Every Grid service instance that implements the 38NotificationSource portType must support a subscribeExtensibility SDE value of 39subscribeByServiceDataNames. 40 41 4 Page 67 of 79 5 6
  • 68. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1However, a Grid service can choose to support other subscription expressions. For example, 2subscribeBySDEAndXPathRestriction as defined below can be supported by a Grid Service 3to allow the clients to specify an XPath expression based on which the notifications can be 4sent when the value of the SDEs’ change. 5 6 <xsd:element name="subscribeBySDEAndXPathRestriction"> 7 <xsd:complexType> 8 <sequence> 9 <xsd:element name="subscribeBySDEAndXPath" 10 type="tns:SDEXPathSubscriptionType"/> 11 </sequence> 12 </xsd:complexType> 13 </xsd:element> 14 <xsd:complexType name="SDEXPathSubscriptionType"> 15 <sequence> 16 <xsd:element name="name" type="QName"/> 17 <xsd:element name="xpath" type="string"/> 18 </sequence> 19 </xsd:complexType> 20 2113.4.NotificationSource :: subscribe operation 22Notification Clients can use this operation to subscribe to changes to the target instance's 23service data. The life-time of the subscription is managed by a separate grid service instance 24called subscription instance. 25This operation takes as input 26 • a subscription expression 27 • the locator of the notification sink to which messages will be delivered 28 • initial expiration time of the subscription as requested by the client 29This operation outputs 30 • the locator to the subscription instance 31 • initial termination time of the subscription as decided by the source 32Notification clients can discover the supported subscription expression types by a service 33instance by performing a findServiceData request on the instance, using a 34queryByServiceDataNames element, which contains the name “ogsi:subscribeExtensibility”. 35Clients can then choose a subscription expression in the subscribe operation to control the 36scope and nature of the subscription. subscribeByServiceDataNames subscription expression, 37which is supported by all Notification Source grid service instances, can be used to subscribe 38for notification messages whenever there are any changes in service data elements. 39The subscribeByServiceDataNames allows the client to set the minimum and maximum 40intervals between notification messages. 41A cClient invokes a subscribe operation on the grid service's NotificationSource port. As an 42example, a cClient can include this as the input parameter of the subscribe operation: 4 Page 68 of 79 5 6
  • 69. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 <ogsi:subscribebyServiceDataNames> 1 <name minInterval=PT15M maxInterval=PT30M>counterValue</name> 2 </ogsi:subscribebyServiceDataNames> 3 <sink> 4 <ogsi:handle> 5 http://localhost/ogsa/services/CounterNotificationClient 6 </ogsihandle> 7 </sink> 8 <ogsi:expirationTime>2003-12-12-26T10:20:00.000-06:00</ogsi:expi 9 rationTime> 10The minInterval property specifies the minimum interval between notification messages, 11expressed in xsd:duration. If this property is not specified, then the notification source may 12choose a minInterval. A notification source may also reject a subscription request if it cannot 13satisfy the minimum interval requested. 14 15The maxInterval property specifies the maximum interval between notification messages, 16expressed in xsd:duration. If this interval elapses without a change to the service data 17elements’ values, then the source will resend the same values. When the value is “infinity” the 18source need never resend a service data values if they do not change. If this property is not 19specified, then the notification source may choose a maxInterval. 20 21The sink element contains the locator of the notification sink to which messages will be 22delivered. This locator may contain only references. Specifying references will allow plain 23Web service that implements the NotificationSink portType to subscribe for notifications. 24Please note that Web Services does not have the concept of handles. 25 26The subscribe operation results in the creation of a subscription instance of type 27NotificationSubscription. The expirationTime element allows the client to specify an initial 28termination time of the newly created NotificationSubscription instance. 29 30A response from the NotificationSource grid service (for the invoking the subscribe operation 31as given above) might look like 32 <ogsi:subscriptionInstanceLocator> 33 <ogsi:handle>http://localhost/ogsa/services/CounterNotificationS 34 ubscription</ogsi:handle> 35 </ogsi:subscriptionInstanceLocator> 36 <ogsi:currentTerminationTime>2003-12-12-26T10:20:00.000-06:00 </ 37 ogsi:currentTerminationTime> 38 3913.5.Lifetime Management of the NotificationSubscription 40The subscribe operation discussed above results in the creation of a subscription instance of 41type NotificationSubscription. Notification Clients are responsible for managing the life-time 42of subscription using the soft-state life time management as explained in section 2.2. 43Additionally, clients can discover properties of the subscription such as 44subscriptionExpression and sinkLocator by querying the respective SDEs of the 45NotificationSubscription instance. 4 Page 69 of 79 5 6
  • 70. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1NotificationSubscription portType extends Grid Service portType and contains no operations. 2 313.6. Notification Clients 4Notification Clients can be a grid service or a Web Service and should implement the 5NotificationSink portType. The NotificationSink portType defines only one operation called 6deliverNotification which is used by the source to deliver the XML messages. 713.7.NotificationSource :: deliverNotification operation 8This operation has one input, and it does not return an output or faults. 9Input: 10• Message: An XML element containing the notification message that flows from the source 11to the sink. The XML type and the frequency of the message are dependent upon the 12subscription expression. 13For example, for the subscription request described above, a notification message might look 14like this: 15 <ns1:serviceDataValues 16 xmlns:ns1="http://www.gridforum.org/namespaces/2003/03/serviceData"> 17 <ns3:CounterValue 18 xmlns:ns2="http://www.gridforum.org/namespaces/2003/05/ogsiprimer/counter 19 /state" 20 xmlns:ns3="http://www.gridforum.org/namespaces/2003/05/ogsiprimer/counter 21 " 22 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 23 xsi:type="ns2:CounterValueType"> 24 <value xmlns="">111</value> 25 </ns3:CounterValue> 26 </ns1:serviceDataValues> 27 28A Web Service implementing the NotificationSink portType does not need to implement the 29Grid Service portType. This enables Web Services living outside an OGSI hosting 30environment to subscribe to notifications. 31 4 Page 70 of 79 5 6
  • 71. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 2 314.Grid Services Security 4Depending on the domain and the nature of the Grid Services, a service implementor can and 5would implement layers of security - from transport level to message level to service level. In 6this context most probably one would require an interoperable security layer that spans 7multiple administrative domains. 814.1.Approach & Scope 9This section addresses Grid Services security in a descriptive way (as opposed to prescriptive 10directions) and touches security only with respect to the primitives in OGSI/OGSA. This 11section : 12 1. summarizes the important ideas, topics and concepts (as resulted from discussions and 13 specifications from the various grid security wgs) 14 2. provides links to detailed work in each of the above areas (thus neither duplicating nor 15 reiterating the rest of the grid security work) 16 3. provides examples (abstract examples and patterns) how they could be used 17 4. will not have implementation details 18The most important is to explain how security is factored out of the application (and is 19orthogonal to OGSI) and provide references to introductory material that explains (in a 20generic fashion) how security protocols can be plugged in to Client and Server infrastructure. 21What those infrastructures do with the security is not the business of OGSI, but some simple 22examples would be reassuring to the Primer audience. 2314.2.List of Topics to address 24 • ServiceData access, visibility and exposure controls - how to express, exchange and 25 process serviceData security artifacts 26 • WSDL security - i.e. security of the exposed interfaces including restricting operations 27 • Standards for identity and access control policies 28 • Examples of how to handle resolution protocols 29 • Explain VOs and how they are achieved using Kerberos/X.509 30 • X.509 and Kerberos usage in a grid scenario 31 • Infosec issues - firewall traversal, any ACL and other requirements for grid installation 32 o Examples/explanation of how gateways can be constructed for Web Services as 33 part of a firewall. 34 • Trust mechanisms - establish, bootstrap and use 35 o Some simple examples of authorization for operations, and the importance of 36 propagation of the authorization would be reassuring to the Primer audience. 4 Page 71 of 79 5 6
  • 72. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 115.Advanced Topics 215.1.Advanced Registries [?] 315.2.Recommendations for Change Management 4< Change management from the gss spec> 515.3.Describing Operation semantics 6[How operations may interact with each other, where to document this] 715.4.Monitoring Execution 8[nice example – Monitoring a Datamining operation?] 4 Page 72 of 79 5 6
  • 73. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 116.Glossary of Terminology 2These terms and abbreviations are used in the text and are defined where they are first used. 3The list below may help you if you dip into the text without reading from the beginning. 4 5Web Service: A software identified by a URI [RFC 2396], whose public interfaces and 6bindings are defined and described using XML. Its definition can be discovered by other 7software systems. These systems may then interact with the Web Service in a manner 8prescribed by its definition, using XML based messages conveyed by Internet protocols. (Web 9Services Glossary, WS-Arch W3C Working Group, Draft 14 May 2003) 10Web Service Consumer: A software component that sends messages to a Web Service. 11Stateful Web Service: A Web Service that maintains some state between different operation 12invocations issued by the same or different Web Service Consumers. 13Grid Service: A general term used to refer to all aspects of OGSI. The term “Grid Service” is 14sometimes used to refer to a Grid Service Description document and/or a Grid Service 15Instance for a particular service. 16Grid Service Description: A WSDL-like document that defines the interface of Grid Service 17Instances. The defined interface must extend the OGSI GridService portType. 18Grid Service Instance: A stateful Web Service whose interface adheres to that defined by a 19Grid Service Description and whose lifetime management properties are well defined. 20Service Data Element: An attribute-like construct exposing state information through 21operations defined by the GridService portType. 22Grid Service Handle: A URI that permanently identifies a Grid Service Instance. 23Grid Service Reference: A temporal, binding-specific endpoint that provides access to a Grid 24Service Instance. 25 4 Page 73 of 79 5 6
  • 74. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1 217.Comparison with other Distributed Architectures 3 [Comparison to Corba, EJB, BPEL?] 4*This was 3.1. Relationship to Distributed Object Systems in the spec.* 5As we describe in much more detail below, a given Grid Service implementation is an 6addressable, and potentially stateful, instance that implements one or more interfaces 7described by WSDL portTypes. Grid Service factories (§12) can be used to create instances 8implementing a given set of portType(s). Each Grid Service instance has a notion of identity 9with respect to the other instances in the distributed Grid, (§7.5.2.1). Each instance can be 10characterized as state coupled with behaviour published through type-specific operations. The 11architecture also supports introspection in that a client application can ask a Grid Service 12instance to return information describing itself, such as the collection of portTypes that it 13implements. 14Grid Service instances are made accessible to (potentially remote) client applications through 15the use of a Grid Service Handle (§7.5.2) and a Grid Service Reference (§7.5.1). These 16constructs are basically network-wide pointers to specific Grid Service instances hosted in 17(potentially remote) execution environments. A client application can use a Grid Service 18Reference to send requests (represented by the operations defined in the portType(s) of the 19target service) directly to the specific instance at the specified network-attached service 20endpoint identified by the Grid Service Reference. 21We expect that in many situations, client stubs and helper classes isolate application 22programmers from the details of using Grid Service References. Some client side 23infrastructure software assumes responsibility for directing an operation to a specific instance 24that the GSR identifies. 25Each of the characteristics introduced above (stateful instances, typed interfaces, global 26names, etc.) is frequently also cited as a fundamental characteristic of so-called distributed 27object-based systems. However, there are also various other aspects of distributed object 28models (as traditionally defined) that are specifically not required or prescribed by OGSI. For 29this reason, we do not adopt the term distributed object model or distributed object system 30then describing this work, but instead use the term Open Grid Services Infrastructure, thus 31emphasizing the connections that we establish with both Web Services and Grid technologies. 32Among the object-related issues that are not addressed within OGSI are implementation 33inheritance, service mobility, development approach, and hosting technology. The Grid 34Service specification does not require, nor does it prevent, implementations based upon object 35technologies that support inheritance at either the interface or the implementation level. There 36is no requirement in the architecture to expose the notion of implementation inheritance either 37at the client side or the service provider side of the usage contract. In addition, the Grid 38Service specification does not prescribe, dictate, or prevent the use of any particular 39development approach or hosting technology for the Grid Service. Grid Service providers are 40free to implement the semantic contract of the service in any technology and hosting 41architecture of their choosing. 42We envision implementations in J2EE, .NET, traditional commercial transaction management 43servers, traditional procedural UNIX servers, etc. We also envision service implementations 4 Page 74 of 79 5 6
  • 75. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1in a wide variety of programming languages that would include both object-oriented and non- 2object-oriented alternatives. 4 Page 75 of 79 5 6
  • 76. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 118.Author Information and Acknowledegements 2Tim Banks (Editor) 3IBM 4Hursley Park, Winchester, UK. SO21 2JN. 5Email: tim_banks@uk.ibm.com 6 7Dr. Abdeslem Djaoui, 8CLRC 9Rutherford Appleton Laboratory, UK, OX11 0QX. 10Email: a.djaoui@rl.ac.uk 11 12Dr. Savas Parastatidis, 13North-East Regional e-Science Centre 14School of Computing Science, University of Newcastle upon Tyne, UK 15http://savas.parastatidis.name 16 17Also we acknowledge the authors of the OGSI Specification that provided source material: 18Steven Tuecke, Karl Czajkowski, Ian Foster, Jeffrey Frey, Steve Graham, Carl Kesselman, 19Tom Maguire, Thomas Sandholm, Dr. David Snelling and Peter Vanderbilt. 2018.1.Acknowledgements 21We are grateful to numerous colleagues for contributions and discussions on the topics 22covered in this document, in particular (in alphabetical order, with apologies to anybody 23we've missed): 24Marc Brooks, John Carter, Chris Dabrowski, Kate Keahey, Guy Rixon, Krishna Sankar, Jem 25Treadwell 26 27 4 Page 76 of 79 5 6
  • 77. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 119.Document References 2[1] Open Grid Services Infrastructure (OGSI) Version 1.0. June 27, 2003. S. Tuecke, K. 3 Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D. 4 Snelling, P. Vanderbilt, Graham, C. Kesselman, D. Snelling, P. Vanderbilt. 5 Available at: http://forge.gridforum.org/projects/ogsi- 6 wg/document/Final_OGSI_Specification_V1.0/en/1/Final_OGSI_Specification_V1.0.pdf 7[2] The Anatomy of the Grid: Enabling Scalable Virtual Organizations, I. Foster, C. 8 Kesselman, S. Tuecke, Authors. International Journal of High Performance Computing 9 Applications, 15 (3). 200-222. 2001. 10 Available at http://www.globus.org/research/papers/anatomy.pdf. 11[3] Globus Toolkit 3 12[4] The Physiology of the Grid: An Open Grid Services Architecture for Distributed 13 Systems Integration, I. Foster, C. Kesselman, J. Nick, S. Tuecke, Authors. Globus 14 Project, 2002. Available at http://www.globus.org/research/papers/ogsa.pdf 15[5] What is Service-Oriented Architecture? Hao He. Available at 16 http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html 17[6] A Model, Analysis, and Protocol Framework for Soft State-based Communication. 18 Suchitra Raman, Steven McCanne. 19[7] Description of RPC (tbd) 20[8] The Object Management Group CORBA specification. Available from the OGM Web 21 Site: http://www.omg.org/corba/ 22[9] Java RMI specification (tbd) 23[10] DCOM documentation (tbd) 24[11] Hypertext Transfer Protocol. RFC 2616. Available at 25 http://www.w3.org/Protocols/rfc2616/rfc2616.html 26[12] Web Services Description Language (WSDL) 1.1 W3C Note 15 March 2001 27 Available at http://www.w3.org/TR/wsdl 28[13] Web Services Description Language (WSDL) Version 1.2, W3C Working Draft 3. 29 March2003, World Wide Web Consortium. 30 Available at http://www.w3.org/TR/2003/WD-wsdl12-20030303 31[14] J2EE 32[15] Secure Grid Naming Protocol (SGNP): Draft Specification for Review and Comment. 33 GGF4 Submission May 3, 2002 34 Available at http://sourceforge.net/projects/sgnp/ 35[16] Java (TM) API for XML-Based RPC (JAX-RPC). 36 Available at http://java.sun.com/xml/jaxrpc/docs.html 37[17] Welcome to WSIF: Web Services Invocation Framework 38 Available at http://www.apache.org/wsif 39[18] OGSA. 40 Available at ? 4 Page 77 of 79 5 6
  • 78. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1[19] Enterprise JavaBeans TM Specification, Version 2.1. Sun Microsystems 2 Available at ? 3[20] The Web Services Architecture. Available at http://www.w3.org/TR/ws-arch/wsa.pdf 4[21] Universal Description, Discovery, and Integration (UDDI) 3.0 specification. Available 5 at http://uddi.org/pubs/uddi-v3.00-published-20020719.htm 6[22] The Web Services Interoperability Organisation. http://www.ws-i.org/ 7[23] The Grid Security Infrastructure. Described at http://www.globus.org/security/ 8[24] The Common Configuration Model Specification. 9[25] GWSDL to WSDL translation 1020.Copyright Notice 11Copyright © Global Grid Forum (2002). All Rights Reserved. 12 13This document and translations of it may be copied and furnished to others, and derivative 14works that comment on or otherwise explain it or assist in its implementation may be repared, 15copied, published and distributed, in whole or in part, without restriction of any kind, 16provided that the above copyright notice and this paragraph are included on all such copies 17and derivative works. However, this document itself may not be modified in any way, such as 18by removing the copyright notice or references to the GGF or other organizations, except as 19needed for the purpose of developing Grid Recommendations in which case the procedures 20for copyrights defined in the GGF Document process must be followed, or as required to 21translate it into languages other than English. 22 23The limited permissions granted above are perpetual and will not be revoked by the GGF or 24its successors or assigns. 25 26This document and the information contained herein is provided on an "AS IS" basis and THE 27GLOBAL GRID FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 28INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 29INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 30WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 31PURPOSE. 32 33Intellectual Property Statement 34The GGF takes no position regarding the validity or scope of any intellectual property or 35other rights that might be claimed to pertain to the implementation or use of the technology 36described in this document or the extent to which any license under such rights might or 37might not be available; neither does it represent that it has made any effort to identify any 38such rights. Copies of claims of rights made available for publication and any assurances of 39licenses to be made available, or the result of an attempt made to obtain a general license or 40permission for the use of such proprietary rights by implementers or users of this specification 41can be obtained from the GGF Secretariat. 42 43The GGF invites any interested party to bring to its attention any copyrights, patents or patent 44applications, or other proprietary rights which may cover technology that may be required to 4 Page 78 of 79 5 6
  • 79. 1GWD-I (draft-ggf-ogsi-gridserviceprimer-3) November 30th, 2003 2 3 1practice this recommendation. Please address the information to the GGF Executive Director 2(see contact information at GGF website). 3 4GLOBAL GRID FORUM 5office@gridforum.org 6www.ggf.org 821.The Index 9 4 Page 79 of 79 5 6