How this Book is organized

This book contains 15 chapters, which are organized into five parts. Part IGrid Computing Part 1 consists of Chapter 1. Chapter 1 provides a detailed but high-level introduction to the Grid Co puting evolution, the applications, and the infrastructure re!uire ents for an" Grid environ ent. #n addition, this chapter discusses Grid Co puting disciplines, and the factors developers and service providers ust consider during the i ple entation phases. Part 2Grid Computing Worldwide Initiatives Part $ consists of Chapter $, Chapter %, and Chapter &. This part is ore on defining Grid Co puting, its evolution, the factors that are affecting these evolutions and the organizations that are influencing'deciding the adoption of this new technolog". #n addition, we will see a general-purpose architecture solution for the e erging Grid Co puting infrastructure and a road ap for Grid Co puting technolog" initiatives. Chapter $( )Grid Co puting *rganizations and Their +oles.) There are a nu ber of organizations fro various industr" sectors including scientific research, co ercial, and standards organizations that are affecting the Grid Co puting adoptions, infrastructure develop ent, testing, standardization, and guideline develop ents. This chapter introduces us to the a,or pla"s in the Grid world. Chapter %( )The Grid Co puting -nato ".) This chapter defines the proble s of coordinated resource sharing, the concepts of virtual organization for ation, and a protocol architecture solution for the Grid proble s. #n addition, this chapter e.a ines the Grid in relation with other distributed technologies such as /eb, ob,ectoriented, distributed technologies, service provider0s fra eworks, clusters, and peerto-peer co puting. Chapter &( )The Grid Co puting +oad 1ap) is a brief. 2ere we will be discussing the current and pro inent technolog" initiatives that are affecting the recent Grid Co puting revolution. 3o e of the pro inent technolog" initiatives that are acting as catal"sts to the evolution are 4usiness *n 5e and environ ents, autono ic co puting, service oriented architectures and se antic Grid. Part 3The ew Generation o! Grid Computing "ppli#ations Part % consists of Chapter 5. #n this part we will e.plore the technolog" constructs of the 3ervice *riented -rchitecture 63*-7 that will set the stage for the new generation of Grid Co puting applications. Chapter 5( )1erging the Grid 3ervices -rchitecture with the /eb 3ervices -rchitecture.) This is an e.tensive chapter, which defines the 3ervice *riented -rchitecture 63*-7 and it0s respective i ple entations, /eb and /eb services. *ur discussion on /eb services covers the details on e.tensible 1arkup 8anguage 69187, 3i ple *b,ect -ccess Protocol 63*-P7, and /eb 3ervice 5escription

8anguage 6/358 1.1'1.$7. #n addition, we will e.plore the details of Global 918 -rchitecture 6G9-7 and so e e erging standards 6/3-3ecurit", /3-Polic", /3-ddressing7. -nother notable area covered in the chapter is the /eb service interoperabilit" 6/3-#7 basic profile and the tools to assert the interoperabilit" validations. /e will end the chapter with a detailed discussion on /eb service state anage ent, the concepts around stateful interactions'applications, and how Grid networking services relate to stateful /eb services. Part $The Grid Computing Te#hnologi#al %iewpoints Part & consists of Chapter :, Chapter ;, Chapter <, Chapter =, and Chapter 1>. This part introduces the concept of *pen Grid 3ervice -rchitecture and the otivations that drive *G3- standardization. #n addition to this, we will describe the *G3architecture and the core infrastructure co ponents for this architecture. This discussion will align Grid Co puting with the other e erging technologies. #n addition, we will define so e of the core base services defined b" the *G3platfor . Chapter :( )*pen Grid 3ervices -rchitecture 6*G3-7.) This chapter will introduce the new *G3- architecture defined for Grid Co puting. This is based on open standards and a Global Grid ?oru initiative. This discussion introduces us to the architectural la"ers as defined b" *G3-. This chapter will then set the stage for the forthco ing discussions on *G3-. Chapter ;( )3o e 3a ple @se Cases that 5rive the *G3-.) -n" well thought-out architecture is driven fro a set of use cases, which captures the scenarios, involved parties, and the solution re!uire ents for the architecture. This chapter will introduce so e representative sa ple use cases fro various industr" sectors to illustrate this process of re!uire ents gathering. Chapter <( )The *G3- Platfor Co ponents.) This is a si ple chapter with an illustration on #41 vision for *G3-. This chapter enhances the *G3- architecture with ore detailed la"ering and relationship with the other e.isting application and s"ste co ponents. Chapter =( )*pen Grid 3ervices #nfrastructure 6*G3#7.) This chapter discusses one of the ost i portant aspects of the *G3-, the core infrastructure foundation for all Grid services. #n this chapter we will cover the details on this infrastructure that will define the behaviors for all Grid services created for *G3-, including state anage ent, instance na ing, life c"cle anage ent, and fault handling. This chapter covers the core interfaces defined b" the specification and their significance and usage patterns. #n addition to this, we will define the relationship between /eb services and Grid services, the si ilarities and differences of their description echanis s, and the significance of the Grid /eb 3ervice 5escription 8anguage 6G/3587. #n this chapter, one will realize a tre endous a ount of valuable infor ation on the core infrastructure software. Chapter 1>( )*G3- 4asic 3ervices.) 4ased on the *G3# specification and the architecture re!uire ents, a nu ber of core services were developed in the Grid area. These services e erged fro the re!uire ents gathered fro the use cases collected

fro various industr" sectors. This chapter will introduce the readers to so e of these pro inent base services. This discussion covers the details on Grid services for resource anage ent odeling, polic" enforce ent, service grouping, securit", etering'accounting, logging, and distributed data anage ent. Part &The Grid Computing Toolkits Part 5 consists of Chapter 11, Chapter 1$, Chapter 1%, Chapter 1&, and Chapter 15. #n this part, we will learn about so e of the pro inent and e erging iddleware solutions i ple ented using the *pen Grid 3ervice #nfrastructure 6*G3#7 standard. The ost pro inent in this group is the Globus Toolkit. This part will cover the final release0s software fra ework, entitled )Globus Toolkit %) or GT%. *ur discussion includes the GT% architecture, progra ing odel, sa ple Grid service develop ent, and high-level services. #n addition to Globus GT%, we will see another ost notable software fra ework called *G3#.ABT, which is also a realization of the *G3# specification. Chapter 11( )G8*4@3 GT% Toolkit( -rchitecture.) This chapter is dedicated to the Globus GT% architecture odel. /e will discuss this la"ered architecture odel provided b" GT%. This software is built on Cava, and enables a container odel for the Grid service life c"cle and instance anage ent. This chapter introduces the reader to the architecture plug-abilit" of GT% with /eb service engines, and hosting capabilities in C$BB'C$3B containers. #n addition, this chapter e.plains the GT% securit" echanis s and client side architecture details. Chapter 1$( )G8*4@3 GT% Toolkit( Progra ing 1odel.) This chapter provides a detailed and in-depth anal"sis of the progra ing odel supported b" the GT% software. This discussion will introduce the reader to the core service progra ing concepts, service data anage ent, notification, and !uer" processing. #n addition we will discuss the service configurations, tools, and tracing options. The discussion on the client side-progra ing odel in this chapter is also worth entioning. *ther aspects that will be discussed include securit", and various essage e.change odels. Chapter 1%( )G8*4@3 GT% Toolkit( - 3a ple # ple entation.) #n this chapter we will e.plore a sa ple Grid service i ple entation using a top-down approach, starting with G/358 for a sa ple search service. *ur discussion will provide a detailed look into each step of this service i ple entation, with the tools involved and the respective codes generated. #n addition, the develop ent is done in a phased anner with added co ple.ities in each la"er. -nother ost valuable discussion provided includes the traces of the 3*-P essages e.changed during this service invocation. This helps the reader to understand the *G3# standards, and the GT% in particular, and will provide better interoperabilit". #n short, our sa ple will provide service data anage ent, and notification. ?inall" we end with an BC4 delegation odel support provided in GT%. Chapter 1&( )G8*4@3 GT% Toolkit( 2igh-8evel 3ervices.) These high-level services are for resource discover" and onitoring, including resource allocation and data anage ent. The pro inent services introduced in this chapter are #nde. services, +esource #nfor ation provider 6+#P7 services, Grid +esource -llocation and 1anage ent 6G+-17 services, and data anage ent services. #n addition, this

chapter introduces the co ponent odel for infor ation services. This discussion includes provider co ponents, service data aggregation co ponents, and registr" co ponents. Chapter 15( )*G3#.ABT 1iddleware 3olutions.) This chapter provides infor ation on another *G3# specification i ple entation in the 1icrosoft .ABT environ ent. The reader will find a detailed discussion on the architecture and progra ing odel for developing Grid services for .ABT.

Chapter 1. Introduction
#n toda"0s pervasive world of needing infor ation an"ti e and an"where, the e.plosive Grid Co puting environ ents have now proven to be so significant that the" are often referred to as being the world0s single and ost powerful co puter solutions. #t has been realized that with the an" benefits of Grid Co puting, we have conse!uentl" introduced both a co plicated and co ple. global environ ent, which leverages a ultitude of open standards and technologies in a wide variet" of i ple entation sche es. -s a atter of fact the co ple.it" and d"na ic nature of industrial proble s in toda"0s world are uch ore intensive to satisf" b" the ore traditional, single co putational platfor approaches.

Grid Computing equates to the world's largest computer

The Grid Co puting discipline involves the actual networking services and connections of a potentiall" unli ited nu ber of ubi!uitous co puting devices within a )grid.) This new innovative approach to co puting can be ost si pl" thought of as a assivel" large power )utilit") grid, such as what provides power to our ho es and businesses each and ever" da". This deliver" of utilit"-based power has beco e second nature to an" of us, worldwide. /e know that b" si pl" walking into a roo and turning on the lights, the power will be directed to the proper devices of our choice for that o ent in ti e. #n this sa e utilit" fashion, Grid Co puting openl" seeks and is capable of adding an infinite nu ber of co puting devices into an" grid environ ent, adding to the co puting capabilit" and proble resolution tasks within the operational grid environ ent. The incredible proble resolution capabilities of Grid Co puting re ain "et unknown, as we continue to forge ahead and enter this new era of assivel" powerful grid-based proble -solving solutions.

This )#ntroduction) section of the book will begin to present an" of the Grid Co puting topics, which are discussed throughout this book. These discussions in Chapter 1 are intended onl" to provide a rather high-level e.a ination of Grid Co puting. 8ater sections of the book provide a full treat ent of the topics addressed b" an" worldwide co unities utilizing and continuing to develop Grid Co puting.

The worldwide business de and re!uiring intense proble -solving capabilities for incredibl" co ple. proble s has driven in all global industr" seg ents the need for d"na ic collaboration of an" ubi!uitous co puting resources to be able to work together. These difficult co putational proble -solving needs have now fostered an" co ple.ities in virtuall" all co puting technologies, while driving up costs and operational aspects of the technolog" environ ents. 2owever, this advanced co puting collaboration capabilit" is indeed re!uired in al ost all areas of industrial and business proble solving, ranging fro scientific studies to co ercial solutions to acade ic endeavors. #t is a difficult challenge across all the technical co unities to achieve this level of resource collaboration needed for solving these co ple. and d"na ic proble s, within the bounds of the necessar" !ualit" re!uire ents of the end user. To further illustrate this environ ent and oftenti es ver" co ple. set of technolog" challenges, let us consider so e co on use case scenarios one ight have alread" encountered, which will begin to e.a ine the an" values of a Grid Co puting solution environ ent. These si ple use cases, for purposes of introduction to the concepts of Grid Co puting, are as follows(

- financial organization processing wealth anage ent application collaborates with the different depart ents for ore co putational power and software odeling applications. #t pools a nu ber of co puting resources, which can thereb" perfor faster with real-ti e e.ecutions of the tasks and i ediate access to co ple. pools of data storage, all while anaging co plicated data transfer tasks. This ulti atel" results in increased custo er satisfaction with a faster turnaround ti e. - group of scientists stud"ing the at ospheric ozone la"er will collect huge a ounts of e.peri ental data, each and ever" da". These scientists need efficient and co ple. data storage capabilities across wide and geographicall" dispersed storage facilities, and the" need to access this data in an efficient anner based on the processing needs. This ulti atel" results in a ore effective and efficient eans of perfor ing i portant scientific research. 1assive online ultipla"er ga e scenarios for a wide co unit" of international ga ing participants are occurring that re!uire a large nu ber of ga ing co puter servers instead of a dedicated ga e server. This allows international ga e pla"ers to interact a ong the selves as a group in a realti e anner. This involves the need for on-de and allocation and provisioning of co puter resources, provisioning and self- anage ent of co ple. networks, and co plicated data storage resources. This on-de and need is ver" d"na ic, fro o ent-to- o ent, and it is alwa"s based upon the workload in the s"ste at an" given o ent in ti e. This ulti atel" results in larger ga ing co unities, re!uiring ore co ple. infrastructures to sustain the traffic loads, delivering ore profits to the botto lines of ga ing corporations, and higher degrees of custo er satisfaction to the ga ing participants. - govern ent organization stud"ing a natural disaster such as a che ical spill a" need to i ediatel" collaborate with different depart ents in order to plan for and best anage the disaster. These organizations a" need to

si ulate an" co putational odels related to the spill in order to calculate the spread of the spill, effect of the weather on the spill, or to deter ine the i pact on hu an health factors. This ulti atel" results in protection and safet" atters being provided for public safet" issues, wildlife anage ent and protection issues, and ecos"ste protection atters( Aeedles to sa" all of which are ver" ke" concerns. Toda", Grid Co puting offers an" solutions that alread" address and resolve the above proble s. Grid Co puting solutions are constructed using a variet" of technologies and open standards. Grid Co puting, in turn, provides highl" scalable, highl" secure, and e.tre el" high-perfor ance echanis s for discovering and negotiating access to re ote co puting resources in a sea less anner. This akes it possible for the sharing of co puting resources, on an unprecedented scale, a ong an infinite nu ber of geographicall" distributed groups. This serves as a significant transfor ation agent for individual and corporate i ple entations surrounding co puting practices, toward a general-purpose utilit" approach ver" si ilar in concept to providing electricit" or water. These electrical and water t"pes of utilities, uch like Grid Co puting utilities, are available )on de and,) and will alwa"s be capable of providing an alwa"s-available facilit" negotiated for individual or corporate utilization. #n this new and intriguing book, we will begin our discussion on the core concepts of the Grid Co puting s"ste with an earl" definition of grid. 4ack in 1==<, it was defined, )- co putational grid is a hardware and software infrastructure that provides dependable, consistent, pervasive, and ine.pensive access to high-end co putational capabilities) 6?oster D Eessel an, 1==<7. The preceding definition is ore centered on the co putational aspects of Grid Co puting while later iterations broaden this definition with ore focus on coordinated resource sharing and proble solving in ulti-institutional virtual organizations 6?oster D Eessel an, 1==<7. #n addition to these !ualifications of coordinated resource sharing and the for ation of d"na ic virtual organizations, open standards beco e a ke" underpinning. #t is i portant that there are open standards throughout the grid i ple entation, which also acco odate a variet" of other open standards-based protocols and fra eworks, in order to provide interoperable and e.tensible infrastructure environ ents. Grid Co puting environ ents

ust be constructed upon the following foundations(

Coordinated resources. /e should avoid building grid s"ste s with a centralized controlF instead, we ust provide the necessar" infrastructure for coordination a ong the resources, based on respective policies and servicelevel agree ents. *pen standard protocols and fra eworks. The use of open standards provides interoperabilit" and integration facilities. These standards ust be applied for resource discover", resource access, and resource coordination.

-nother basic re!uire ent of a Grid Co puting s"ste is the abilit" to provide the !ualit" of service 6Go37 re!uire ents necessar" for the end-user co unit". These

Go3 validations ust be a basic feature in an" Grid s"ste , and ust be done in congruence with the available resource atrices. These Go3 features can be 6for e.a ple7 response ti e easures, aggregated perfor ance, securit" fulfill ent, resource scalabilit", availabilit", autono ic features such as event correlation and configuration anage ent, and partial fail over echanis s. There have been a nu ber of activities addressing the above definitions of Grid Co puting and the re!uire ents for a grid s"ste . The ost notable effort is in the standardization of the interfaces and protocols for the Grid Co puting infrastructure i ple entations. /e will cover the details later in this book. 8et us now e.plore so e earl" and current Grid Co puting s"ste s and their differences in ter s of benefits.

'arl( Grid "#tivities

*ver the past several "ears, there has been a lot of interest in co putational Grid Co puting worldwide. /e also note a nu ber of derivatives of Grid Co puting, including co pute grids, data grids, science grids, access grids, knowledge grids, cluster grids, terra grids, and co odit" grids. -s we e.plore careful e.a ination of these grids, we can see that the" all share so e for of resourcesF however, these grids a" have differing architectures. *ne ke" value of a grid, whether it is a co odit" utilit" grid or a co putational grid, is often evaluated based on its business erits and the respective user satisfaction. @ser satisfaction is easured based on the Go3 provided b" the grid, such as the availabilit", perfor ance, si plicit" of access, anage ent aspects, business values, and fle.ibilit" in pricing. The business erits ost often relate to and indicate the proble being solved b" the grid. ?or instance, it can be ,ob e.ecutions, anage ent aspects, si ulation workflows, and other ke" technolog"-based foundations. Barlier Grid Co puting efforts were aligned with the overlapping functional areas of data, co putation, and their respective access echanis s. 8et us further e.plore the details of these areas to better understand their utilization and functional re!uire ents. )ata The data aspects of an" Grid Co puting environ ent ust be able to effectivel" anage all aspects of data, including data location, data transfer, data access, and critical aspects of securit". The core functional data re!uire ents for Grid Co puting applications are(

The abilit" to integrate ultiple distributed, heterogeneous, and independentl" anaged data sources. The abilit" to provide efficient data transfer echanis s and to provide data where the co putation will take place for better scalabilit" and efficienc". The abilit" to provide data caching and'or replication network traffic. echanis s to ini ize

The abilit" to provide necessar" data discover" echanis s, which allow the user to find data based on characteristics of the data. The capabilit" to i ple ent data encr"ption and integrit" checks to ensure that data is transported across the network in a secure fashion. The abilit" to provide the backup'restore echanis s and policies necessar" to prevent data loss and ini ize unplanned downti e across the grid.

Computation The core functional co putational re!uire ents for grid applications are(

The abilit" to allow for independent anage ent of co puting resources The abilit" to provide echanis s that can intelligentl" and transparentl" select co puting resources capable of running a user0s ,ob The understanding of the current and predicted loads on grid resources, resource availabilit", d"na ic resource configuration, and provisioning ?ailure detection and failover Bnsure appropriate securit" access, and integrit" echanis s echanis s for secure resource anage ent,

8et us further e.plore so e details on the co putational and data grids as the" e.ist toda". Computational and )ata Grids #n toda"0s co ple. world of high speed co puting, co puters have beco e e.tre el" powerful as to that of 6let0s sa"7 five "ears ago. Bven the ho e-based PCs available on the co ercial arkets are powerful enough for acco plishing co ple. co putations that we could not have i agined a decade prior to toda". The !ualit" and !uantit" re!uire ents for so e business-related advanced co puting applications are also beco ing ore and ore co ple.. The industr" is now realizing that we have a need, and are conducting nu erous co ple. scientific e.peri ents, advanced odeling scenarios, geno e atching, astrono ical research, a wide variet" of si ulations, co ple. scientific'business odeling scenarios, and real-ti e personal portfolio anage ent. These re!uire ents can actuall" e.ceed the de ands and availabilit" of installed co putational power within an organization. 3o eti es, we find that no single organization alone satisfies so e of these afore entioned co putational re!uire ents. This advanced co puting power applications need is indeed analogous to the electric power need in the earl" 1=>>s, such that to provide for the availabilit" of electrical power, each user has to build and be prepared to operate an electrical generator. Thus, when the electric power grid beca e a realit", this changed the entire concept of the providing for, and utilization of, electrical power. This, in turn, paved the wa" for an

evolution related to the utilization of electricit". #n a si ilar fashion, the co putational grids change the perception on the utilit" and availabilit" of the co puter power. Thus the co putational Grid Co puting environ ent beca e a realit", which provides a de and-driven, reliable, powerful, and "et ine.pensive co putational power for its custo ers. -s we noted earlier in this discussion, a co putational Grid Co puting environ ent consists of one or ore hardware- and software-enabled environ ents that provide dependable, consistent, pervasive and ine.pensive access to high-end co putational capabilities 6?oster D Eessel an, 1==<7. 8ater in this book, in the )Grid -nato ") section, we will see that this definition has evolved to give ore e phasis on the sea less resource sharing aspects in a collaborative virtual organizational world. 4ut the concept still holds for a co putational grid where the sharable resource re ains a co puting power. -s of now, the a,orit" of the co putational grids are centered on a,or scientific e.peri ents and collaborative environ ents. The re!uire ent for ke" data for s a core underpinning of an" Grid Co puting environ ent. ?or e.a ple, in data-intensive grids, the focus is on the anage ent of data, which is being held in a variet" of data storage facilities in geographicall" dispersed locations. These data sources can be databases, file s"ste s, and storage devices. The grid s"ste s ust also be capable of providing data virtualization services to provide transparenc" for data access, integration, and processing. #n addition to the above re!uire ents, securit" and privac" re!uire ents of all respective data in a grid s"ste is !uite co ple.. /e can su

arize the data re!uire ents in the earl" grid solutions as follows( eta-data and other attributes of the data ove ent

The abilit" to discover data The access to databases, utilizing

The provisioning of co puting facilities for high-speed data

The capabilit" to support fle.ible data access and data filtering capabilities

-s one begins to realize the i portance of e.tre e high perfor ance-related issues in a Grid Co puting environ ent, it is reco ended to store 6or cache7 data near to the co putation, and to provide a co on interface for data access and anage ent. #t is interesting to note that upon careful e.a ination of e.isting Grid Co puting s"ste s, readers will learn that an" Grid Co puting s"ste s are being applied in several i portant scientific research and collaboration pro,ectsF however, this does not preclude the i portance of Grid Co puting in business-, acade ic-, and industr"related fields. The co ercialization of Grid Co puting invites and addresses a ke" architectural align ent with several e.isting co ercial fra eworks for i proved interoperabilit" and integration. -s we will describe in this book, an" current trends in Grid Co puting are toward service-based architectures for grid environ ents. This )architecture) is built for

interoperabilit" and is 6again7 based upon open standard protocols. /e will provide a full treat ent including an" of the details toward this architecture throughout subse!uent sections in this book.

Current Grid "#tivities

-s described earlier, initiall", the focused Grid Co puting activities were in the areas of co puting power, data access, and storage resources. The definition of Grid Co puting resource sharing has since changed, based upon e.periences, with ore focus now being applied to a sophisticated for of coordinated resource sharing distributed throughout the participants in a virtual organization. This application concept of coordinated resource sharing includes an" resources available within a virtual organization, including co puting power, data, hardware, software and applications, networking services, and an" other for s of co puting resource attain ent. This concept of coordinated resource sharing is depicted in ?igure 1.1.

Figure 1.1. Dynamic benefits of coordinated resource sharing in a virtual organization.

-s depicted in the previous illustration, there are a nu ber of sharable resources, hardware and software applications, fir ware i ple entations, and networking services, all available within an enterprise or service provider environ ent. +ather than keeping these resources isolated within an ato ic organization, the users can ac!uire these resources on a )de and) basis. Through i ple enting this t"pe of Grid Co puting environ ent, these resources are i ediatel" available to the

authenticated users for resolving specific proble s. These proble s a" be a software capabilit" proble 6e.g., odeling, si ulation, word processing, etc.7 or hardware availabilit" and'or co puting capacit" shortage proble s 6e.g., processor co puting resources, data storage'access needs, etc.7. /hile on another level, these proble s a" be related to a networking bandwidth availabilit" proble , the need for i ediate circuit provisioning of a network, a securit" event or other event correlation issue, and an" ore t"pes of critical environ ental needs. 4ased upon the specific proble di ension, an" given proble a" have one or ore resolution issues to address. ?or e.a ple, in the above case there is two sets of users, each with a need to solve two different t"pes of proble s. Hou will note that one has to resolve the weather prediction proble , while the other has to provide a financial odeling case. 4ased upon these proble do ains noted b" each of the user groups, their re!uire ents i pl" two t"pes of virtual organizations. These distinct virtual organizations are for ulated, sustained, and anaged fro a co puting resource viewpoint according to the abilit" to access the available resources. 8et us further e.plore this concept of )virtualization) b" describing in ore detail the usage patterns found within each of the virtual organizations.

- virtual organization for weather prediction. ?or e.a ple, this virtual organization re!uires resources such as weather prediction software applications to perfor the andator" environ ental si ulations associated with predicting weather. 8ikewise, the" will re!uire ver" specific hardware resources to run the respective software, as well as high-speed data storage facilities to aintain the data generated fro perfor ing the si ulations. - virtual organization for financial odeling. ?or e.a ple, this virtual organization re!uires resources such as software odeling tools for perfor ing a ultitude of financial anal"tics, virtualized bladesI1J to run the above software, and access to data storage facilities for storing and accessing data.

These virtual organizations anage their resources and t"picall" will provision additional resources on an )as-needed) basis. This on-de and approach provides tre endous values toward scalabilit", in addition to aspects of enhanced reusabilit". This approach is t"picall" found in an" )on-de and) environ ent. This capabilit" is based upon a utilit" infrastructure, where resources are allocated as, and when, the" are re!uired. 8ikewise, their utilit" pricing scenarios are alwa"s based upon the capturing of usage etrics. The following discussion introduces a nu ber of re!uire ents needed for such Grid Co puting architectures utilized b" virtual organizations. /e shall classif" these architecture re!uire ents into three categories. These resources categories ust be capable of providing facilities for the following scenarios(

The need for d"na ic discover" of co puting resources, based on their capabilities and functions. The i ediate allocation and provisioning of these resources, based on their availabilit" and the user de ands or re!uire ents.

The anage ent of these resources to agree ents 638-s7.

eet the re!uired service level

The provisioning of ultiple autono ic features for the resources, such as self-diagnosis, self-healing, self-configuring, and self- anage ent. The provisioning of secure access ethods to the resources, and bindings with the local securit" echanis s based upon the autono ic control policies. ust be capable of providing facilities for(

Kirtual organization

The for ation of virtual task forces, or groups, to solve specific proble s associated with the virtual organization. The d"na ic collection of resources fro heterogeneous providers based upon users0 needs and the sophistication levels of the proble s. The d"na ic identification and auto atic proble resolution of a wide variet" of troubles, with auto ation of event correlation, linking the specific proble s to the re!uired resource and'or service providers. The d"na ic provisioning and re!uired eeting the 38-s. anage ent capabilities of the resources on

The for ation of a secured federation 6or governance odel7 and co anage ent odel for all of the resources respective to the virtual organization. The secure delegation of user credentials and identit" do ain6s7.

apping to the local eet a

The anage ent of resources, including utilization and allocation, to budget and other econo ic criteria.

@sers'applications t"picall" found in Grid Co puting environ ents perfor the following characteristics(

ust be able to

The clear and una biguous identification of the proble 6s7 needing to be solved The identification and apping of the resources re!uired solve the proble The abilit" to sustain the re!uired levels of Go3, while adhering to the anticipated and necessar" 38-s The capabilit" to collect feedback regarding resource status, including updates for the environ ent0s respective applications

The above discussion helps us now to better understand the co on re!uire ents for grid s"ste s. #n the subse!uent chapters in this section, and oreover throughout this book, we discuss the an" specific details on the Grid Co puting architecture

odels and e erging Grid Co puting software s"ste s that have proven valuable in supporting the above re!uire ents.

The !ollowing se#tion will provide treatment toward some o! the more #ommon Grid Computing *usiness areas that e+ist toda(, and those areas that will t(pi#all( *ene!it !rom the a*ove #on#epts o! Grid Computing- It is worth( to mention that these *usiness areas are most o!ten *roadl( #lassi!ied, and *ased upon the industr( se#tor where the( reside- "n .verview o! Grid Business "reas
*ne of the ost valuable aspects of all Grid Co puting s"ste s are that the" attract the business the" are intended to address. #n an )on-de and) scenario, these Grid Co puting environ ents are the result of autono ic provisioning of a ultitude of resources and capabilities, t"picall" de onstrating increased co puting resource utilization, access to specialized co puter s"ste s, cost sharing, and i proved anage ent capabilities.

IBM Business On Demand Initiative

4usiness *n 5e and 6in the rest of the book we will refer to this as *n 5e and7 is not ,ust about utilit" co puting as it has a uch broader set of ideas about the transfor ation of business practices, process transfor ation, and technolog" i ple entations. Co panies striving to achieve the 4usiness *n 5e and operational odels will have the capacit" to sense and respond to fluctuating arket conditions in real-ti e, while providing products and services to custo ers in a 4usiness *n 5e and operational odel. The essential characteristics of on-de and businesses are responsiveness to the d"na ics of business, adapting to variable cost structures, focusing on core business co petenc", and resilienc" for consistent availabilit". This is achieved through sea less integration of custo ers and partners, virtualization of resources, autono ic'dependable resources, and open standards.

There have been a significant nu ber of co ercialization efforts, which support Grid Co puting in ever" sector of the arketplace. #n general ter s, the utilization of Grid Co puting in business environ ents provides a rich and e.tensible set of business benefits. These business benefits include 6but are not li ited to7(

-cceleration of i ple entation ti e fra es in order to intersect with the anticipated business end results. # proved productivit" and collaboration of virtual organizations and respective co puting and data resources. -llowing widel" dispersed depart ents and businesses to create virtual organizations to share data and resources.

+obust and infinitel" fle.ible and resilient operational infrastructures. Providing instantaneous access to assive co puting and data resources.

8everaging e.isting capital e.penditures invest ents, and operational e.penditure invest ents, which in turn help to ensure opti al utilization and costs of co puting capabilities. -voiding co on pitfalls of overprovisioning and incurring e.cess costs.

1an" organizations have started identif"ing the a,or business areas for Grid Co puting business applications. 3o e e.a ples of a,or business areas include 6but are not li ited to7(

8ife sciences, for anal"zing and decoding strings of biological and che ical infor ation ?inancial services, for running long, co ple. financial odels and arriving at ore accurate decisions 2igher education for enabling advanced, data- and co putation-intensive research Bngineering services, including auto otive and aerospace, for collaborative design and data-intensive testing Govern ent, for enabling sea less collaboration and agilit" in both civil and ilitar" depart ents and other agencies Collaborative ga es for replacing the e.isting single-server online ga es with ore highl" parallel, assivel" ultipla"er online ga es

8et us now introduce and e.plore the anal"tics of each of these industr" sectors b" identif"ing so e of the high-level business-area re!uire ents for Grid Co puting s"ste s. #n doing so, we will look at the facilities necessar" for grid s"ste s in order to eet these re!uire ents. /i!e 0#ien#es This industr" sector has noted an" dra atic advances in the life sciences sector, which have in turn provided rapid changes in the wa" that drug treat ent and drug discover" efforts are now being conducted. The anal"tics and s"ste efforts0 surrounding geno ic, proteo ics, and olecular biolog" efforts provides the basis for an" of these Grid Co puting advance ents in this sector. These advances have now presented a nu ber of technical challenges to the infor ation technolog" sector, and especiall" the Grid Co puting disciplines. Grid Co puting efforts have realized that these challenges include huge a ounts of data anal"sis, data ove ent, data caching, and data ining. #n addition to the co ple.it" of processing data, there needs to be additional re!uire ents surrounding data securit", secure data access, secure storage, privac", and highl" fle.ible

integration. -nother area that re!uires attention is the !uer"ing of nonstandard data for ats and accessing data assets across co ple. global networks. The above re!uire ents presented b" life sciences re!uire a Grid Co puting infrastructure to properl" anage data storage, providing access to the data, and all while perfor ing co ple. anal"sis respective to the data. The Grid Co puting s"ste s can provide a co on infrastructure for data access, and at the sa e ti e, provide secure data access echanis s while processing the data. Toda", life sciences utilizes the Grid Co puting s"ste s to e.ecute se!uence co parison algorith s and enable olecular odeling using the above-collected secured data. This now provides the 8ife 3ciences sector the abilit" to afford world-class infor ation anal"sis respective to this discussion, while at the sa e ti e providing faster response ti es and far ore accurate results. 1inan#ial "nal(sis and 0ervi#es This industr" sector has noted an" dra atic advances in the financial anal"sis and services industr" sector. The technological and business advances are ost noted in the infor ation technolog" areas, the e ergence of a co petitive arket force custo er satisfaction, and reduction of risk as the ost co petitive areas financial co unities continuall" strive to achieve. The re!uire ents related to sophistication, accurac", and faster e.ecution are a ong the ore salient ob,ectives across financial co unities. These ob,ectives are now achieved b" real-ti e access to the current and historical arket data, co ple. financial odeling based on the respective data, and faster response ti es to user !ueries. Grid Co puting provides the financial anal"sis and services industr" sector with advanced s"ste s delivering all the co petitive solutions in Grid Co puting. These solutions e.e plif" the infrastructure and business agilit" necessar" to eet and e.ceed the uni!ueness that the financial anal"sis and services industr" sector re!uires. This particular value state ent is acco plished b" the fact that an" of these solutions in this industr" are dependent upon providing increased access to assive a ounts of data, real-ti e odeling, and faster e.ecution b" using the grid ,ob scheduling and data access features. ?or this to be ost successful, these financial institutions tend to for virtual organizations with participation fro several different depart ents and other e.ternal organizations. #n addition to the use of e.isting resources, a grid s"ste can provide ore efficienc" b" easil" adapting to the rapidl" changing algorith s pertaining to the financial anal"tics. 2esear#h Colla*oration +esearch-oriented organizations and universities practicing in advanced research collaboration areas re!uire the anal"sis of tre endous a ounts of data. 3o e e.a ples of such pro,ects are subato ic particle and high energ" ph"sics e.peri ents, re ote sensing sources for earth si ulation and odeling, and anal"sis of the hu an geno e se!uence. These virtual organizations engaged in research collaboration activities generate petab"tesI$J of data and re!uire tre endous a ounts of storage space and thousands of co puting processors. +esearchers in these fields ust share data, co putational

processors, and hardware instru entation such as telescopes and advanced testing e!uip ent. 1ost of these resources are pertaining to data-intensive processing, and are widel" dispersed over a large geographical area. The Grid Co puting discipline provides echanis s for resource sharing b" for ing one or ore virtual organizations providing specific sharing capabilities. 3uch virtual organizations are constituted to resolve specific research proble s with a wide range of participants fro different regions of the world. This for ation of d"na ic virtual organizations provides capabilities to d"na icall" add and delete virtual organization participants, anage the )on-de and) sharing of resources, plus provisioning of a co on and integrated secure fra ework for data interchange and access. 'ngineering and )esign The enor ous co petitive pressure in the business and industr" sectors toda" afford ost engineering and design far less turnaround ti e. The" need echanis s to capture data, speed up the anal"sis on the data, and provide faster responses to arket needs. -s we alread" know, these engineering activities and design solutions are inherentl" co ple. across several di ensions, and the processing re!uire ents are uch ore intense than that of traditional solutions of the past. These co ple.ities fall into several areas of solutions in Grid Co puting that span across industr" sectors all over the world. These co ple.ities are described 6but are not li ited to7 the following areas(

The anal"sis of real-ti e data to find a specific pattern within a proble The para etric studies to verif" different aspects of the s"ste s The odeling e.peri ents to create new designs odels for accurac"

The si ulation activities to verif" the e.isting

Grid Co puting s"ste s provide a wide range of capabilities that address the above kinds of anal"sis and odeling activities. These advanced t"pes of solutions also provide co ple. ,ob schedulers and resource anagers to deal with co puting power re!uire ents. This enables auto obile anufacturers 6as an e.a ple7 to shorten anal"sis and design ti es, all while ini izing both capital e.penditures and operational e.penditures. Colla*orative Games There are collaborative t"pes of Grid Co puting disciplines that are involving e erging technologies to support online ga es, while utilizing on-de and provisioning of co putation-intensive resources, such as co puters and storage networks. These resources are selected based on the re!uire ents, often involving aspects such as volu e of traffic and nu ber of pla"ers, rather than centralized servers and other fi.ed resources. These on-de and-driven ga es provide a fle.ible approach with a reduced up-front cost on hardware and software resources. /e can i agine that these ga es use an

increasing nu ber of co puting resources with an increase in the nu ber of concurrent pla"ers and a decrease in resource usage with a lesser nu ber of pla"ers. Grid Co puting ga ing environ ents are capable of supporting such virtualized environ ents for enabling collaborative ga ing. Government The Grid Co puting environ ents in govern ent focus on providing coordinated access to assive a ounts of data held across various agencies in a govern ent. This provides faster access to solve critical proble s, such as e ergenc" situations, and other nor al activities. These ke" environ ents provide ore efficient decision aking with less turnaround ti e. Grid Co puting enables the creation of virtual organizations, including an" participants fro various govern ental agencies 6e.g., state and federal, local or countr", etc.7. This is necessar" in order to provide the data needed for govern ent functions, in a real-ti e anner, while perfor ing the anal"sis on the data to detect the solution aspects of the specific proble s being addressed. The for ation of virtual organizations, and the respective ele ents of securit", is ost challenging due to the high levels of securit" in govern ent and the ver" co ple. re!uire ents.

Grid "ppli#ations
4ased on our earlier discussion, we can align Grid Co puting applications to have co on needs, such as what is described in 6but not li ited to7 the following ite s(

-pplication partitioning that involves breaking the proble pieces 5iscover" and scheduling of tasks and workflow 5ata co re!uired unications distributing the proble

into discrete

data where and when it is nodes

Provisioning and distributing application codes to specific s"ste +esults

anage ent assisting in the decision processes of the environ ent

-utono ic features such as self-configuration, self-opti ization, selfrecover", and self- anage ent

8et us now e.plore so e of these Grid applications and their usage patterns. /e start with schedulers, which for the core co ponent in ost of the co putational grids. 0#hedulers 3chedulers are t"pes of applications responsible for the anage ent of ,obs, such as allocating resources needed for an" specific ,ob, partitioning of ,obs to schedule parallel e.ecution of tasks, data anage ent, event correlation, and service-level anage ent capabilities. These schedulers then for a hierarchical structure, with eta-schedulers that for the root and other lower level schedulers, while providing

specific scheduling capabilities that for the leaves. These schedulers a" be constructed with a local scheduler i ple entation approach for specific ,ob e.ecution, or another eta-scheduler or a cluster scheduler for parallel e.ecutions. ?igure 1.$ shows this concept.

Figure 1.2. The scheduler hierarchy embodies local, meta-level, and cluster schedulers.

The ,obs sub itted to Grid Co puting schedulers are evaluated based on their service-level re!uire ents, and then allocated to the respective resources for e.ecution. This will involve co ple. workflow anage ent and data ove ent activities to occur on a regular basis. There are schedulers that ust provide capabilities for areas such as 6but not li ited to7(

-dvanced resource reservation 3ervice-level agree ent validation and enforce ent Cob and resource polic" anage ent and enforce ent for best turnaround ti es within the allowable budget constraints 1onitoring ,ob e.ecutions and status +escheduling and corrective actions of partial failover situations an" of the ost notable scheduler

8ater in this book, full treat ent is provided for and eta-scheduler i ple entations. 2esour#e Broker

The resource broker provides pairing services between the service re!uester and the service provider. This pairing enables the selection of best available resources fro the service provider for the e.ecution of a specific task. These resource brokers collect infor ation 6e.g., resource availabilit", usage odels, capabilities, and pricing infor ation7 fro the respective resources, and use this infor ation source in the pairing process. ?igure 1.% illustrates the use of a resource broker for purposes of this discussion. This particular resource broker provides feedback to the users on the available resources.

#n general cases, the resource broker a" select the suitable scheduler for the resource e.ecution task, and collaborate with the scheduler to e.ecute the task6s7.

Figure 1.3. The resource broker collects information from the res ective resources, and utilizes this information source in the airing rocess.

The pairing process in a resource broker involves allocation and support functions such as(

-llocating the appropriate resource or a co bination of resources for the task e.ecution 3upporting users0 deadline and budget constraints for scheduling opti izations

/oad Balan#ing The Grid Co puting infrastructure load-balancing issues are concerned with the traditional load-balancing distribution of workload a ong the resources in a Grid Co puting environ ent. This load-balancing feature ust alwa"s be integrated into an" s"ste in order to avoid processing dela"s and overco it ent of resources. These kinds of applications can be built in connection with schedulers and resource anagers. The workload can be pushed outbound to the resources, based on the availabilit" state and'or resources, and can then pull the ,obs fro the schedulers depending on their availabilit". This level of load balancing involves partitioning of ,obs, identif"ing the resources, and !ueueing of the ,obs. There are cases when resource reservations ight be re!uired, as well as running ultiple ,obs in parallel. -nother feature that ight be of interest for load balancing is support for failure detection and anage ent. These load distributors can redistribute the ,obs to other resources if needed. Grid Portals Grid portals are si ilar to /eb portals, in the sense the" provide unifor access to the grid resources. ?or e.a ple, grid portals provide capabilities for Grid Co puting resource authentication, re ote resource access, scheduling capabilities, and

onitoring status infor ation. These kinds of portals help to alleviate the co ple.it" of task anage ent through custo izable and personalized graphical interfaces for the users. This, in turn, alleviates the need for end users to have ore do ain knowledge than on the specific details of grid resource anage ent. 3o e e.a ples of these grid portal capabilities are noted in the following list(

Guer"ing databases or 85-P servers for resource-specific infor ation ?ile transfer facilities such as file upload, download, integration with custo software, and so on 1anage ,ob through ,ob status feedbacks -llocate the resources for the e.ecution of specific tasks 3ecurit" anage ent

Provide personalized solutions

#n short, these grid portals help free end users fro the co ple.it" of ,ob anage ent and resource allocation so the" can concentrate ore on their do ain of e.pertise. There are a nu ber of standards and software develop ent toolkits available to develop custo portals. The e erging /eb services and /eb service portal standards will pla" a ore significant role in portal develop ent. Integrated 0olutions 1an" of the global industr" sectors have witnessed the e ergence of a nu ber of integrated grid application solutions in the last few "ears. This book focuses on this success factor. These integrated solutions are a co bination of the e.isting advanced iddleware and application functionalities, co bined to provide ore coherent and high perfor ance results across the Grid Co puting environ ent. #ntegrated Grid Co puting solutions will have ore enhanced features to support ore co ple. utilization of grids such as coordinated and opti ized resource sharing, enhanced securit" anage ent, cost opti izations, and areas "et to be e.plored. #t is straightforward to see that these integrated solutions in both the co ercial and nonco ercial worlds sustain high values and significant cost reductions. Grid applications can achieve levels of fle.ibilit" utilizing infrastructures provided b" application and iddleware fra eworks. #n the ne.t section we introduce and e.plain the grid infrastructure. Toda", the ost notable integrated solutions in the co ercial and industr" sectors are utilit" co puting, on-de and solutions, and resource virtualizations infrastructures. 8et us briefl" e.plore aspects of so e of these infrastructure solutions. /e will provide an additional, ore focused treat ent in subse!uent chapters of this book.

Grid In!rastru#ture

The grid infrastructure for s the core foundation for successful grid applications. This infrastructure is a co ple. co bination of a nu ber of capabilities and resources identified for the specific proble and environ ent being addressed. #n initial stages of delivering an" Grid Co puting application infrastructure, the developers'service providers ust consider the following !uestions in order to identif" the core infrastructure support re!uired for that environ ent( 1. /hat proble 6s7 are we tr"ing to solve for the userL 2ow do we address grid enable ent si pler, while addressing the user0s application si plerL 2ow does the developer 6progra aticall"7 help the user to be able to !uickl" gain access and utilize the application to best fit their proble resolution needsL $. 2ow difficult is it to use the grid toolL -re grid developers providing a fle.ible environ ent for the intended user co unit"L %. #s there an"thing not "et considered that would ake it easier for grid service providers to create tools for the grid, suitable for the proble do ainL &. /hat are the open standards, environ ents, and regulations grid service providers ust addressL #n the earl" develop ent stages of grid applications, nu erous vertical )towers) and iddleware solutions were often developed to solve Grid Co puting proble s. These various iddleware and solution approaches were developed for fairl" narrow and li ited proble -solving do ains, such as iddleware to deal with nu erical anal"sis, custo ized data access grids, and other narrow proble s. Toda", with the e ergence and convergence of grid service-oriented technologies,I%J including the interoperable 918I&J-based solutions beco ing ever ore present and industr" providers with a nu ber of reusable grid iddleware solutions facilitating the following re!uire ent areas, it is beco ing si pler to !uickl" deplo" valuable solutions. ?igure 1.& shows this topolog" of iddleware topics.

Figure 1.!. "rid middle#are to ic areas are becoming more so histicated at an aggressive rate.

#n general, a Grid Co puting infrastructure co ponent ust address several potentiall" co plicated areas in an" stages of the i ple entation. These areas are(

3ecurit" +esource

anage ent

#nfor ation services 5ata anage ent

8et us further e.a ine the significance of each of these above co ponents. 0e#urit( The heterogeneous nature of resources and their differing securit" policies are co plicated and co ple. in the securit" sche es of a Grid Co puting environ ent. These co puting resources are hosted in differing securit" do ains and heterogeneous platfor s. 3i pl" speaking, our iddleware solutions ust address local securit" integration, secure identit" apping, secure access'authentication, secure federation, and trust anage ent. The other securit" re!uire ents are often centered on the topics of data integrit", confidentialit", and infor ation privac". The Grid Co puting data e.change ust be protected using secure co unication channels, including 338'T83 and oftenti es in co bination with secure essage e.change echanis s such as /3-3ecurit". The ost notable securit" infrastructure used for securing grid is the Grid 3ecurit" #nfrastructure 6G3#7. #n ost cases, G3# provides capabilities for single sign-on, heterogeneous platfor integration and secure resource access'authentication. The latest and ost notable securit" solution is the use of /3-3ecurit" standards. This echanis provides essage-level, end-to-end securit" needed for co ple. and interoperable secure solutions. #n the co ing "ears we will see a nu ber of secure grid environ ents using a co bination of G3# and /3-3ecurit" echanis s for secure essage e.changes. /e will discuss the details of securit" echanis s provided b" these standards later in this book. 2esour#e 3anagement The tre endousl" large nu ber and the heterogeneous potential of Grid Co puting resources causes the resource anage ent challenge to be a significant effort topic in Grid Co puting environ ents. These resource anage ent scenarios often include resource discover", resource inventories, fault isolation, resource provisioning, resource onitoring, a variet" of autono ic capabilities,I5J and service-level anage ent activities. The ost interesting aspect of the resource anage ent area is the selection of the correct resource fro the grid resource pool, based on the service-level re!uire ents, and then to efficientl" provision the to facilitate user needs. 8et us e.plore an e.a ple of a ,ob anage ent s"ste , where the resource anage ent feature identifies the ,ob, allocates the suitable resources for the

e.ecution of the ,ob, partitions the ,ob if necessar", and provides feedback to the user on ,ob status. This ,ob scheduling process includes oving the data needed for various co putations to the appropriate Grid Co puting resources, and echanis s for dispatching the ,ob results. #t is i portant to understand ultiple service providers can host Grid Co puting resources across an" do ains, such as securit", anage ent, networking services, and application functionalities. *perational and application resources a" also be hosted on different hardware and software platfor s. #n addition to this co ple.it", Grid Co puting iddleware ust provide efficient onitoring of resources to collect the re!uired atrices on utilization, availabilit", and other infor ation. *ne causal i pact of this fact is 6as an e.a ple7 the securit" and the abilit" for the grid service provider to reach out and probe into other service provider do ains in order to obtain and reason about ke" operational infor ation 6i.e., to reach across a service provider environ ent to ascertain firewall and router volu e-related specifics, or networking switch status, or application server status7. This oftenti es beco es co plicated across several di ensions, and has to be resolved b" a eeting-of-theinds between all service providers, such as essaging necessar" infor ation to all providers, when and where it is re!uired. -nother valuable and ver" critical feature across the Grid Co puting infrastructure is found in the area of provisioningF that is, to provide autono ic capabilities for selfanage ent, self-diagnosis, self-healing, and self-configuring. The ost notable resource anage ent iddleware solution is the Grid +esource -llocation 1anager 6G+-17. This resource provides a robust ,ob anage ent service for users, which includes ,ob allocation, status anage ent, data distribution, and start'stop ,obs. In!ormation 0ervi#es #nfor ation services are funda entall" concentrated on providing valuable infor ation respective to the Grid Co puting infrastructure resources. These services leverage and entirel" depend on the providers of infor ation such as resource availabilit", capacit", and utilization, ,ust to na e a few. This infor ation is valuable and andator" feedback respective to the resources anagers discussed earlier in this chapter. These infor ation services enable service providers to ost efficientl" allocate resources for the variet" of ver" specific tasks related to the Grid Co puting infrastructure solution. #n addition, developers and providers can also construct grid solutions to reflect portals, and utilize eta-schedulers and eta-resource anagers. These etrics are helpful in service-level anage ent 638-7 in con,unction with the resource policies. This infor ation is resource specific and is provided based on the sche a pertaining to that resource. /e a" need higher level inde.ing services or data aggregators and transfor ers to convert these resource-specific data into valuable infor ation sources for the end user. ?or e.a ple, a resource a" provide operating s"ste infor ation, while "et another resource ight provide infor ation on hardware configuration, and we can then group this resource infor ation, reason with it, and then suggest a )best) price

co bination on selecting the operating s"ste on other certain hardware. This co binatorial approach to reasoning is ver" straightforward in a Grid Co puting infrastructure, si pl" due to the fact that all ke" resources are shared, as is the infor ation correlated respective to the resources. )ata 3anagement 5ata for s the single ost i portant asset in a Grid Co puting s"ste . This data a" be input into the resource, and the results fro the resource on the e.ecution of a specific task. #f the infrastructure is not designed properl", the data ove ent in a geographicall" distributed s"ste can !uickl" cause scalabilit" proble s. #t is well understood that the data ust be near to the co putation where it is used. This data ove ent in an" Grid Co puting environ ent re!uires absolutel" secure data transfers, both to and fro the respective resources. The current advances surrounding data anage ent are tightl" focusing on virtualized data storage echanis s, such as storage area networks 63-A7, network file s"ste s, dedicated storage servers, and virtual databases. These virtualization echanis s in data storage solutions and co on access echanis s 6e.g., relational 3G8s, /eb services, etc.7 help developers and providers to design data anage ent concepts into the Grid Co puting infrastructure with uch ore fle.ibilit" than traditional approaches. 3o e of the considerations developers and providers ust factor into decisions are related to selecting the ost appropriate data anage ent echanis for Grid Co puting infrastructures. This includes the size of the data repositories, resource geographical distribution, securit" re!uire ents, sche es for replication and caching facilities, and the underl"ing technologies utilized for storage and data access. 3o far in this introductor" chapter we have been discussing the details surrounding an" aspects of the iddleware fra ework re!uire ents, specificall" the e ergence of service provider-oriented architecturesI:J and, hence, the open and e.tre el" powerful utilit" value of 918-based interoperable essages. These co bined, provide a wide range of capabilities that deal with interoperabilit" proble s, and co e up with a solution that is suitable for the d"na ic virtual organizational grids. The ost i portant activit" noted toda" in this area is the *pen Grid 3ervice -rchitecture 6*G3-7 and its surrounding standard initiatives. 3ignificant detail is recorded on this architecture, and will be given full treat ent in subse!uent chapters in this book. The *G3- provides a co on interface solution to grid services, and all the infor ation has been convenientl" encoded using 918 as the standard. This provides a co on approach to infor ation services and resource anage ent for Grid Co puting infrastructures. This introductor" chapter has discussed an" of the chapters and so e of their detail that will be presented throughout this book. This introductor" discussion has been presented at a high level, and ore detailed discussions with si ple-to-understand graphics will follow.

Con#lusion
3o far we have been describing and walking through overview discussion topics on the Grid Co puting discipline that will be discussed further throughout this book,

including the Grid Co puting evolution, the applications, and the infrastructure re!uire ents for an" grid environ ent. #n addition to this, we have discussed when one should use Grid Co puting disciplines, and the factors developers and providers ust consider in the i ple entation phases. /ith this introduction we can now e.plore deeper into the various aspects of a Grid Co puting s"ste , its evolution across the industries, and the current architectural efforts underwa" throughout the world. The proceeding chapters in this book introduce the reader to this new, evolutionar" era of Grid Co puting, in a concise, hard-hitting, and eas"-to-understand anner.

otes
1. The ter )blades) refers to a s aller circuit inserted into a larger achine footprint, with an" other blades, where each blade is perfor ing, as it0s own distinct co puter. This notion is co onl" referred to as )blade co puting.) $. - petab"te is a ter that indicates a unit of co puter e or" or data storage capacit" e!ual to 1,>$& terab"tes 6or $5> b"tes7( one !uadrillion b"tes. %. Please refer to the book 4usiness *n 5e and( Technolog" and 3trateg" Perspectives 6?ellenstein, $>>&7 for further details and precision on i portant technologies, Grid Co puting, and ke" strateg" perspectives. &. 918 6B.tensible 1arkup 8anguage7 is a eta-language written in 3G18 63tandardized 1arkup 8anguage7 that allows one to design a arkup language used to allow for the eas" interchange of docu ents and data across the /orld /ide /eb. 5. Please refer to ?ellenstein 6$>>&7 for further details and precision on i portant technologies, Grid Co puting, and ke" strateg" perspectives. :. Please refer to ?ellenstein 6$>>&7 for further details and precision on i portant service provider technologies, Grid Co puting, and ke" strateg" perspectives on both topics.

Part 2: Grid Computing Worldwide Initiatives

The last decade has introduced a nu ber of changes to the wa" that co puting facilities have been traditionall" utilized. The e ergence of distributed co puting and its widespread acceptance has had an unprecedented i pact on the utilit" of co puting facilities. #nternet co puting e erged as the strong otivating factor to decentralize these co puting facilities. -s of now, the #nternet, and hence wide area networking, has beco e the ubi!uitous standard for the electronic world. 4" the beginning of this centur", the wide area distributed co puting discipline has taken a new turn with

ore e phasis on controlled and coordinated resource sharing a ong d"na ic groups of organizations and'or individuals. #n Chapter $, we discuss the contributions of the a,or Grid Co puting organizations that are working on an agreeable open process, standardization, and interoperable i ple entation of the grid to enable the co unit" for anageable resource sharing and coordination. The focus of Chapter % is the so-called )grid proble ,) a real grid proble , and how the grid architecture is defined to solve the proble . #n this part of the book, we e.plore the concepts around virtual organizations and how the new grid architecture is ade!uate to understand and solve the co ple. proble s of virtualization of resources and organizational grouping. #n Chapter &, we go through the grid co puting road ap where we will discuss how the grid is evolving with ore e phasis on open standard process, service orientation, and knowledge sharing. This includes an overview on the e.isting technolog" fabric for the grid, the evolving service-oriented architecture odel with ore interoperable solutions, and finall" the knowledge-based se antic grid with ore focus on interchangeable etadata.

Chapter . Grid Computing Organi!ations and "heir #oles

Grid Co puting organizations and their roles can be broadl" classified into four categories based on their functional role in Grid Co puting. These roles are best described as(

*rganizations developing grid standards and best practices guidelines *rganizations developing Grid Co puting toolkits, fra eworks, and iddleware solutions *rganizations building and using grid-based solutions to solve their co puting, data, and network re!uire ents *rganizations working to adopt grid concepts into co ercial products, via utilit" co puting, and 4usiness *n 5e andI1J co puting

?igure $.1 shows these categories, while also noting the technologies involved in the an" areas of Grid Co puting. #n subse!uent chapters of this book, we will e.plain these technologies in greater detail. There is also another book in this #41 4usiness *n 5e and book series which goes into deeper discussions on the sub,ect( 4usiness *n 5e and( Technolog" and 3trateg" Perspectives 6?ellenstein, $>>&7.

Figure 2.1. The basic classifications of "rid $om uting organizations.

Figure 2.2. %ome of rominent "rid $om uting organizations #orld#ide.

There are an" organizations in the world striving to achieve new and innovative Grid Co puting environ ents. #n this chapter we will e.plore not onl" the worldclass e.a ples of Grid Co puting environ ents, but we will also e.plore those organizations involved in the plight. The #41 Corporation is a leader in the pursuit of 4usiness *n 5e and Grid Co puting environ ents and the corporation itself has enabled a global 4usiness *n 5e and environ ent. #41 is, toda", working with a large nu ber of global custo ers in the sa e endeavor.

.rganizations )eveloping Grid 0tandards and Best Pra#ti#e Guidelines

These organizations are responsible for refining the grid standardization process and defining the best practice guidelines for the scientific and industr" usage of grid. The ost pro inent a ong such organizations is Global Grid ?oru 6GG?7. There are other standards organizations working closel" with GG? in this process, including *-3#3 6*rganization for the -dvance ent of 3tructured #nfor ation 3tandards7, /%C 6/orld /ide /eb Consortiu 7, #BT? 6the #nternet Bngineering Task ?orce7, and 51T? 6the 5istributed 1anage ent Task ?orce7.I$J GG? is ainl" working in

the Grid arena while others have ore broad-based progra s covering other parts of the co puting industr" such as network, resource, business, and #nternet standards. ?or e.a ple, /%C is working on the standardization of /eb and /eb-related technologies, including /eb services, e9tensible 1arkup 8anguage 69187, and 3e antic /eb. GG? is working closel" with these organizations in defining the grid standards aligned with the other open standard processes and providing inputs and re!uire ents to other standards organizations. Glo*al Grid 1orum 4GG15 The GG?I%J was established a couple of "ears ago as a public co unit" foru for the discussion of grid technolog" issues. The GG? enables a eans of coordinating Grid Co puting technolog" efforts, pro oting reuse and interoperabilit", and sharing the results. -s of now, there are ore than &>> organizations involved with GG? fro around the world. This includes scientific research institutions, universities, and co ercial organizations. The GG?0s pri ar" ob,ective is to pro ote and support develop ent, deplo" ent, and i ple entation of grid technologies and applications via creation and docu entation of best practicesMspecifications, use cases, architecture, and i ple entation guidelines. The basic goals of the GG? are to(

Create an open process for the develop ent of grid agree ents and specifications Create grid specifications, architecture docu ents, and best practice guidelines 1anage and version controls the docu ents and specifications 2andle intellectual propert" policies Provide a foru for infor ation e.change and collaboration

# prove collaboration a ong the people involved with grid research, grid fra ework builders, grid deplo" ent, and grid users Create best practice guidelines fro associated with Grid Co puting the e.perience of the technologies

Bducate on advances in the grid technologies and share e.periences a ong the people of interest

The organization consists of different work areas, with research groups and work groups for each area. The work groups are the ain activit" centers of the GG?. These work groups are created to address a research, i ple entation, and operational area related to the infrastructure for building an" )grid.) The a,or work areas of the GG? are as follows(

-pplication and progra -rchitecture 5ata

ing environ ents

#nfor ation s"ste s and perfor ance Peer-to-peer( 5esktop grids 3cheduling and resource 3ecurit" anage ent

-s of toda", one of the a,or activities in GG? that is attracting the grid co unit" is the architecture odel based on the open standard /eb service architecture, called *pen Grid 3ervice -rchitecture 6*G3-7. - detailed discussion on this e erging standard is a necessit" which we will undertake in a subse!uent chapter. /ith open standards as the foundation and software integration, *G3- has e erged as the core grid technolog" for future resource sharing, especiall" with the newl" added co ercial di ension to Grid solutions.

.rganizations )eveloping Grid Computing Toolkits and the 1ramework

To achieve a successful adoption of Grid Co puting re!uires an ade!uate infrastructure, securit" services, ke" services, applications, and portals. 8et us now e.plore and identif" so e of the ost pro inent organizations responsible for the toolkits, iddleware, and fra ework for Grid Co puting. Glo*us The GlobusI&J pro,ect is a ulti-institutional research effort to create a basic infrastructure and high-level services for a co putational grid. - co putational grid is defined as hardware and software infrastructure that provides dependable, consistent, pervasive, and ine.pensive access to high-end co putational capabilities 6?oster D Eessel an, 1==<7. The" have now evolved into an infrastructure for resource sharing 6hardware, software, applications, and so on7 a ong heterogeneous virtual organizations. These grids enable high creativit" b" increasing the average and peak co putational perfor ance available to i portant applications regardless of the spatial distribution of both resources and users. The details on Globus infrastructure provided in ?igure $.% are based on the latest release fro Globus called Globus GT%. Globus provides la"ered software architecture with a low-level infrastructure to host high-level services defined for grid. These high-level services are related to resource discover", allocation, onitoring, anage ent, securit", data anage ent, and access. The lower la"er infrastructure 6GT% Core7 provides a fra ework to host the high-level services.

Figure 2.3. "lobus "T3 middle#are, core, and high-level services resent a #ide variety of ca abilities.

3o e of the core high-level services included with the e.isting Globus toolkit are found in the following discussion.

"lobus &esource 'llocation (anager )"&'(*

G+-1 provides resource allocation, process creation, onitoring, and anage ent services. G+-1 si plifies the use of re ote s"ste s b" providing a single standard interface for re!uesting and using re ote s"ste resources for the e.ecution of ),obs.) The ost co on use of G+-1 is the re ote ,ob sub ission and control facilit". 2owever, G+-1 does not provide ,ob scheduling or resource brokering capabilities. /e could see that the ,ob scheduling facilities are nor all" provided b" the local s"ste . G+-1 uses a high-level +esource 3pecification 8anguage 6+387 to specif" the co ands and aps the to the local schedulers and co puters.

"rid %ecurity +nfrastructure )"%+*

G3# provides a single-sign-on, run an"where authentication service with support for local control over access rights and apping fro global to local user identities. /hile keeping the e.isting G3# echanis s, the current G3#% standard is in align ent with the /eb service securit" standards b" defining a G3# profile for /33ecurit".I5J

+nformation %ervices
- GT% #nfor ation service provides infor ation about grid resources, for use in resource discover", selection, and opti ization. The 1onitoring and 5iscover" 3ervice 61537 is an e.tensible grid infor ation service that co bines data discover" echanis s with the 8ightweight 5irector" -ccess Protocol 685-P7. The 153 provides a unifor fra ework for providing and accessing s"ste configuration and status infor ation such as co puter server

configuration, network status, or the locations of replicated datasets. The current GT% fra ework erges the 153 with the 918 data fra ework for better integration with e.isting /eb services and *G3-. The latest Globus Toolkit 6GT%7 is a ,ava i ple entation of the *G3# specification. The discussion on the architecture and progra ing odel of the GT% infrastructure software and the details on the high-level services are deferred to the last section of this book. /egion 8egion,I:J a iddleware pro,ect initiated b" the @niversit" of Kirginia, is ob,ect-based etas"ste s software for grid applications. The goal of the 8egion pro,ect is to pro ote the principled design of distributed s"ste software b" providing standard ob,ect representations for processors, data s"ste s, file s"ste s, and so on. 8egion applications are developed in ter s of these standard ob,ects. Groups of users can construct a shared virtual workspace to collaborate on research and e.change infor ation. ?igure $.& shows the architecture of a 8egion s"ste . 8egion sits on top of the user0s operating s"ste and acts as ediator between its own host6s7 and other re!uired resources. 8egion0s scheduling and securit" policies act on behalf of the user in undertaking ti e-consu ing negotiations with outside s"ste s and s"ste ad inistrators. To allow users to take advantage of a wide range of possible resources, 8egion offers a user-controlled na ing s"ste called conte.t space, so that users can easil" create and use ob,ects in distributed s"ste s.

Figure 2.!. ,egion a

lication architecture.

-n #nterface 5efinition 8anguage 6#587 is defined to describe the ethod signatures 6na e, para eter, and return values7 supported b" the ob,ect interface. /e could see

that these ob,ects provide a scalable persistence echanis ob,ects 6ob,ects in )inert) state7 to the secondar" storage.

b" storing the inactive arized below.

3o e of the i portant characteristics of 8egion s"ste s are su

-verything is an ob.ect
#n a 8egion s"ste , 8egion *b,ect represents a variet" of hardware and software resources, which respond to e ber function invocations fro other ob,ects in the s"ste . 8egion defines the essage for at and high-level protocol for ob,ect interaction 6through #587, but not the progra ing language or the co unications protocol.

$lasses manage their o#n instances

Bver" 8egion ob,ect is defined and anaged b" its class ob,ect. Class ob,ects are given s"ste -level responsibilit"F classes create new instances, schedule the for e.ecution, activate and deactivate the , and provide infor ation about their current location to client ob,ects. These classes whose instances are the selves classes are called etaclasses.

/sers can rovide their o#n classes

8egion allows its users to define and build their own )class) ob,ects. This enables the 8egion progra ers to have a fle.ible architecture odel for their ) etaclasses) with the capabilities to deter ine and even change the s"ste -level echanis s of their ob,ects.

$ore ob.ects im lement common services

8egion defines the interface and basic functionalit" of a set of core ob,ect t"pes that support basic s"ste services, such as na ing, binding, ob,ect creation, activation, deactivation, and deletion. 3o e of the core ob,ects defined b" the 8egion s"ste

are(

2ost ob,ects( -bstractions of processing resources which a" represent a single processor or ultiple hosts and processors Kault ob,ects( Provide persistent storage for scalable persistence of the ob,ects 4inding ob,ect( 1aps the ob,ect #5s to the ph"sical addresses # ple entation ob,ects( -llow legion ob,ects to run as processes in the s"ste and contain a achine code that is e.ecuted on a re!uest to create the ob,ect or activate it.

?igure $.5 shows 8egion ob,ect - with its class ob,ect 6 etaclass7 and the corresponding basic s"ste services.

Figure 2.0. ,egion core ob.ect and relationshi .

#n 1==;, the first 8egion toolkit was released, and in the following "ear, -pplied 1etaco puting 6later relaunched as -vaki Corporation7 was established to e.ploit the toolkit for co ercial purposes. Condor and Condor6G CondorI;J is a tool for harnessing the capacit" of idle workstations for co putational tasks. Condor is well suited for para eter studies and high throughput co puting, where ,obs generall" do not need to co unicate with each other. /e can classif" Condor as a specialized workload anage ent s"ste for co putation-intensive ,obs. 8ike other full-featured batch s"ste s, Condor provides a ,ob !ueuing echanis , scheduling polic", priorit" sche e, resource onitoring, and resource anage ent. @pon receiving serial or parallel ,obs fro the user, the Condor s"ste places the into a !ueue, chooses when and where to run the ,obs based upon a polic", carefull" onitors their progress, and ulti atel" infor s the user upon co pletion. /e can ake use of Condor to anage a cluster of dedicated co pute nodes. #t is suitable for effectivel" harnessing the CP@ power fro idle workstations. Condor has echanis s for atching resource re!uests 6,obs7 with resource offers 6 achines7. /hile Condor software tools focus on harnessing the power of opportunistic and dedicated resources, Condor-G is a derivative software s"ste , which leverages the software fro Condor and Globus with a,or focus on the ,ob anage ent services for grid applications. This is a co bination of interdo ain resource anage ent protocols of Globus 6G+-1, #nde. 3ervices7 with the intrado ain resource anage ent ethods of Condor. ?igure $.: shows a sa ple usage of Condor-G in co bination with Globus. -s shown, Condor-G contains a G-33 3erver, which is used to transfer ,obs to and fro the e.ecution center. The Condor-G Grid anager uses G+-1 to get the Cob progress infor ation fro Globus Gate Eeeper.

Figure 2.1. &emote e2ecution of $ondor-" on "lobus-managed resource using "lobus 3ob manager.

Condor software is used b" both scientific and co ercial organizations. The a,or scientific initiative that uses Condor includes A3? 1iddleware #nitiative 6A1#7, Grid Ph"sics Aetwork 6GriPh"A7, #nternational Kirtual 5ata Grid laborator" 6iK5G87, TerraGrid, and so on. 3o e of the pro inent co ercial uses of condor software involve solving co putational Grid Co puting proble s, as done b" 1icron Technologies, C*+B 5igital Pictures, and A@G%> *pti ization Proble 3olver. imrod Ai rodI<J provides a user interface for describing the )para eter sweep) proble s, with resulting independent ,obs being sub itted to a resource anage ent s"ste . Ai rod-G is a derivative software s"ste , which harnesses the software fro Ai rod and Globus to harness ulti-do ain resources as if the" all belong to the one personal do ain. #t provides a si ple declarative para etric language for e.pressing the para eters for e.ecution. This s"ste e.poses novel resource anage ent and ,ob scheduling algorith s based on the econo ic principles of co puting. 3uch a set of resource trading services is called G+-CB 6Grid -rchitecture for Co putational Bcono "7. G+-CB provides echanis s to negotiate on the Go3 para eters, deadlines, and co putational costs. #n addition, it offers incentive for rela.ing re!uire ents. /e could see that depending on users0 Go3 re!uire ents, these resource brokers d"na icall" lease Grid services at runti e depending on their cost, !ualit", and availabilit". 8everaging the services provided b" grid iddleware s"ste s develops the Ai rod-G toolkit and resource broker. These iddleware s"ste s include Globus, 8egion, G+-CB, and so forth. -s illustrated in ?igure $.;, the Ai rod architecture defines the following co ponents(

1. Ai rod-G clients, which can provide tools for creating para eter sweep applications, steering and control onitors, and custo ized end-user applications and G@#s $. The Ai rod-G resource broker, which consists of a Task far ing engine 6T?B7, a scheduler that perfor s resource discover", trading and scheduling features, a dispatcher and actuator, and agents for anaging the ,obs on the resource

Figure 2.4. 'rchitecture of 5imrod-".

#t is i portant to note that the Ai rod-G broker provides its services b" leveraging the grid iddleware s"ste s including Globus, 8egion, Condor, and so on. -s we have previousl" discussed, the core feature of the Ai rod-G toolkit is the support for user-defined deadlines. ?or e.a ple( )Get this si ulation done in 1> inutes with a budget of @35 N$>>.) -lso, budget constraint for scheduling opti izations is a part of the core features. Ai rod-G facilitates the e.ecution of the user re!uire ent b" anaging suppl" and de and of resources in the grid using a set of resource trading services. The

ost i portant scheduling algorith s used in Ai rod-G are( Cost opti izationM uses the cheapest resource Ti e opti izationsM results in parallel e.ecution of the ,ob Cost-ti e opti izationM si ilar to cost opti ization but if there are ultiple ,obs with the sa e cost, then the ti e factor is taken into consideration Conservative ti e strateg"M si ilar to ti e opti ization, but guarantees that each unprocessed ,ob has a ini u budget per ,ob

$arametric Computational %&periments

Para etric co putational e.peri ents are beco ing increasingl" i portant in science and engineering as a eans of e.ploring the behavior of co ple. s"ste s. ?or e.a ple, a flight engineer a" e.plore the behavior of a wing b" running a co putational odel of the airfoil ultiple ti es while var"ing ke" para eters such as angle of attack, air speed, and so on. The results of these ultiple e.peri ents "ield a picture of how the wing behaves in different parts of para etric space.

1an" practitioners of Grid Co puting believe that econo ic polic"'criteria-driven Grid Co puting, as depicted b" Ai rod-G, is a a,or interest to the utilit" co puting world. 7 IC.2' 47 i!orm Inter!a#e to C.mputer 2'sour#e5 The @A#C*+BI=J pro,ect is funded b" the Ger an 1inistr" of Bducation and +esearch with the design goal including a unifor and eas"-access graphical user interface 6G@#7, open architecture based on the concept of an abstract ,ob, a consistent securit" architecture, ini al interface with local ad inistrative procedures, and e.ploitation of the e.isting and e erging technologies including /eb and Cava. @A#C*+Bpro was produced within the @A#C*+B to provide a unifor interface for ,ob preparation and secure sub ission of the ,ob si ilar to a portal. This enables users to create workflow for ,ob e.ecution and control e.ecution behaviors. This is an open source pro,ect developed using Cava technolog". The @A#C*+Bpro server provides capabilities for authorization, ,ob anage ent, data transfer, and batch interface. - pro,ect called G+#P 6G+id #nteroperabilit" Pro,ect7 was started in $>>$ to achieve the interoperabilit" between @A#C*+B and Globus. The B@+*G+#5 software is based on the @A#C*+B s"ste developed and used b" the leading Ger an 2PC centers. 01 3iddleware Initiative 4 3I5 A1#I1>J was created b" the Aational 3cience ?oundation 6A3?7 to help scientists and researchers use the #nternet to effectivel" share instru ents, laboratories, and data and to collaborate with each other. 1iddleware is software that connects two or ore otherwise separate applications across the #nternet or local area networks. 1iddleware akes resource sharing see transparent to the end user, providing capabilities, consistenc", securit", and privac". A1# consists of two tea s(

Grid +esearch #ntegration 5eplo" ent and 3upport 6G+#537 Center. The G+#53I11J center is responsible for defining, developing, deplo"ing, and supporting an integrated and stable iddleware infrastructure created fro a nu ber of open source grid and other distributed co puting technolog" fra eworks. #t intends to support $1st-centur" science and engineering applications b" working closel" with a nu ber of universities and research organizations. 3o e of the open source packages included in this iddleware are Globus Toolkit, Condor-G, G3#-*pen332, Aetwork /eather service, Grid Packaging Tools, GridConfig, 1P#C2-G$, 1"Pro.", and so on. Bnterprise and 5esktop #ntegration Technologies 6B5#T7 Consortiu . B5#TI1$J develops tools, practices, and architectures to leverage ca pus infrastructures to facilitate ulti-institutional collaboration. B5#T provides software to support a wider variet" of desktop securit", video, and enterprise uses with a director" sche a. This facilitates the federated odel of director"-enabled interreal authentication and authorization. #n addition, the" are responsible for conventions and best practice guidelines, architecture docu ents, policies, and to provide services to anage the iddleware. 3o e of the open sources packages included in this iddleware are( 85-P *perational *+C- Eollector 68**E7, Privilege and +ole 1anage ent #nfrastructure 3tandards Kalidation 6PB+1#37, open3-1#8, and others. The latest release 6+elease %7 of the A1# iddleware consists of 1: software packages. The above two tea s of the A1# is creating production-!ualit" iddleware using open-source and open-standards approaches. The" continue to refine processes for tea -based software develop ent, docu entation, and technical support. The software packages included in the A1# solution have been tested and debugged b" A1# tea e bers, so that various users, ca puses, and institutions can easil" deplo" the . #n addition, it helps to facilitate director"-enabled 685-P7 sharing and e.changing of infor ation to support authentication and authorization a ong ca puses and institutions. The afore entioned best practices and polic" deliverables have been reviewed and deplo"ed b" leading ca puses and institutions. 3o e of the a,or initiatives using this iddleware suite include ABB3grid 6Aetwork for Barth!uake Bngineering 3i ulation7, GriPh"A, and the iK5G8.

.rganizations Building and 7sing Grid6Based 0olutions to 0olve Computing, )ata, and etwork 2e8uirements
These organizations and individuals are the real users of Grid Co puting. The" are benefiting fro resource sharing and virtualization. -s of now these pro,ects are ostl" in the scientific areas. /e will be discussing so e of the a,or grid pro,ects and infrastructures around the world. #n general, these grid users need(

*n-de and construction of virtual co puting s"ste with the capabilities to solve the proble s at hand including scarcit" of co puting power, data storage, and real-ti e processing

- provision for collaborative visualization of the results of the above process - d"na ic construction of virtual organizations to solve certain specific proble s at hand

7nited 0tates )epartment o! 'nerg(9 0#ien#e Grid 4).'5 The 5*B 3cience GridI1%J ai s to provide an advanced distributed co puting infrastructure based on Grid Co puting iddleware and tools to enable a high degree of scalabilit" in scientific co puting. The vision is to revolutionize the use of co puting in science b" aking the construction and use of large-scale s"ste s of diverse resources as eas" as using toda"0s desktop environ ents. The following describes characteristics of 5*B(

1ost of the 5*B pro,ects are widel" distributed a ong collaborators and noncollaborators. #t re!uires a c"berinfrastructure that supports the process of distributed science with sharable resources including e.pensive and co ple. scientific instru ents. -ll of the science areas need high-speed networks and advanced iddleware to discover, anage, and access co puting and storage s"ste s.

The 5*B 3cience Grid is an integrated and advanced infrastructure that delivers(

Co puting capacit" ade!uate for the tasks in hand 5ata capacit" sufficient for scientific tasks with location independence and anageabilit" Co unication power sufficient for the above tasks

3oftware services with rich environ ents that let scientists focus on the science si ulation and anal"sis aspects rather than on anage ent of co puting, data, and co unication resources

The construction of grids across five a,or 5*B facilities provides the co puting and data resources. To date a,or acco plish ents include the following(

#ntegration of 5*B0s *ffice of 3cience superco puting center providing large-scale storage s"ste s into the grid 5esign and deplo" ent of a grid securit" infrastructure for collaboration with @.3. and Buropean 2igh Bnerg" Ph"sics pro,ects, helping to create a singlesign-on solution within the grid environ ent

The following work is used b" the 5*B0s Particle Ph"sics 5ata Grid, Barth 3"ste s Grid, and ?usion Grid pro,ects(

- resource onitoring and debugging infrastructure for widel" distributed resources

anaging these

3everal 5*B applications use this grid infrastructure including co putational che istr", ground water transport, cli ate odeling, bio infor atics, and so on.

'uropean 7nion9 '72.G2I) Pro:e#t The B@+*G+#5I1&J pro,ect is a shared-cost +esearch and Technolog" 5evelop ent pro,ect 6+T57 granted b" the Buropean Co ission, with the participation of 11 partners and : Buropean @nion countries, in order to create an international network of high perfor ance co puting centers. This pro,ect will de onstrate the use of G+#5s in selected scientific and industrial co unities in order to address the specific re!uire ents of these co unities, and highlight the benefits of using G+#5s. The

a,or ob,ectives of the B@+*G+#5 pro,ect are( To establish a Buropean G+#5 network of leading high perfor ance co puting centers fro different Buropean countries To operate and support the B@+*G+#5 software infrastructure To develop i portant G+#5 software co ponents and to integrate the B@+*G+#5 6fast file transfer, resource broker, interface for coupled applications, and interactive access7 into

To de onstrate distributed si ulation codes fro different application areas 6bio olecular si ulations, weather prediction, coupled C-B si ulations, structural anal"sis, real-ti e data processing, etc.7 To contribute to the international G+#5 develop ent and work with the leading international G+#5 pro,ects

The application-specific work packages identified for the B@+*G+#5 pro,ect are described in the following areas( 4io Grid. The 4ioG+#5 pro,ect develops interfaces to enable che ists and biologists to sub it work to high perfor ance center facilities via a unifor interface fro their workstations, without having to worr" about the details of how to run particular packages on different architectures. 1etro Grid. The ain goal of the 1etro Grid pro,ect is the develop ent of an application service provider 6-3P7 solution, which allows an"one to run a high resolution nu erical weather prediction odel on de and. Co puter--ided Bngineering 6C-B7 Grid. This work pro,ect focuses on industrial C-B applications including auto obile and aerospace industries. #t ai s at providing services to high perfor ance co puting 62PC7 custo ers who re!uire huge co puting power to solve their engineering proble s. The a,or partners in this work package are 5ebis 3"ste 2aus and B-53 Corporate +esearch Center. The" are working to e.ploit the C-B features like code coupling 6to

i prove s"ste design b" reducing the protot"ping and testing costs7 and -3P-t"pe services 6designing application-specific user interfaces for ,ob sub ission7. 2igh Perfor ance Center 62PC7 +esearch Grid. This 2PC research grid is used as a test-bed for the develop ent of distributed applications, and as an arena for cooperative work a ong a,or scientific challenges, using co putational resources distributed on a Buropean scale. The a,or partners in this work-package are the 2PC centers. The B@+*G+#5 software is based on the @A#C*+B s"ste the leading Ger an 2PC centers. 'uropean 7nion9 )ata Grid Pro:e#t 5ataGridI15J is a pro,ect funded b" the Buropean @nion that ai s to enable access to geographicall" distributed co puting power and storage facilities belonging to different institutions. This will provide the necessar" resources to process huge a ounts of data co ing fro scientific e.peri ents in different disciplines. The three real data-intensive co puting applications areas covered b" the pro,ect are(

developed and used b"

2igh Bnerg" Ph"sics 4iolog" and 1edical # age Processing Barth *bservations

6igh -nergy 7hysics )led by $-&5, %#itzerland*

*ne of the ain challenges for 2igh Bnerg" Ph"sics is to answer longstanding !uestions about the funda ental particles of atter and the forces acting between the . #n particular, the goal is to e.plain wh" so e particles are uch heavier than others, and wh" particles have ass at all. To that end, CB+A is building the 8arge 2adron Collider 68237, one of the ost powerful particle accelerators. The search on 823 will generate huge a ounts of data. The 5ataGrid Pro,ect is providing the solution for storing and processing this data. - ultitiered, hierarchical co puting odel will be adopted to share data and co puting power a ong ultiple institutions. The Tier-> center is located at CB+A and is linked b" high-speed networks to appro.i atel" 1> a,or Tier-1 data-processing centers. These will fan out the data to a large nu ber of s aller ones 6Tier-$7.

8iology and (edical +mage 7rocessing )led by $5&%, France*

The storage and e.ploitation of geno es and the huge flu. of data co ing fro postgeno ics puts growing pressure on co puting and storage resources within e.isting ph"sical laboratories. 1edical i ages are currentl" distributed over edical i age production sites 6radiolog" depart ents, hospitals7. -lthough there is a need toda", as there is no standard for sharing data between sites, there is an increasing need for re ote edical data access and processing.

The 5ataGrid pro,ect0s biolog" test-bed is providing the platfor for the develop ent of new algorith s on data ining, databases, code anage ent, and graphical interface tools. #t is facilitating the sharing of geno ic and edical i aging databases for the benefit of international cooperation and health care.

-arth 9bservations )led by -%':-%&+5, +taly*

The Buropean 3pace -genc" issions download 1>> gigab"tes of raw i ages per da" fro space. 5edicated ground infrastructures have been set up to handle the data produced b" instru ents onboard the satellites. The anal"sis of at ospheric ozone data has been selected as a specific test-bed for the 5ataGrid. 1oreover, the pro,ect will de onstrate an i proved wa" to access and process large volu es of data stored in distributed Buropean-wide archives. TeraGrid The TeraGridI1:J pro,ect was first launched b" the A3? and was a ulti"ear effort to build and deplo" the world0s largest, fastest distributed infrastructure for open scientific research. The TeraGrid includes $> teraflopsI1;J of co puting power distributed at five sites, facilities capable of anaging and storing nearl" 1 petab"te of data, high-resolution visualization environ ents, and toolkits for Grid Co puting. These co ponents will be tightl" integrated and connected through a network that will operate at &> gigabits per secondMthis is the fastest research network on the planet toda". The a,or ob,ective of this pro,ect includes creation of a high-speed networkF grid services that provide data sharing, co puting power, and collaborative visualizationF and to provide facilities that create the technolog" re!uire ents 6e.g., data storage, bandwidth, etc.7. The five sites in the pro,ect are(

Aational Center for 3uperco puting -pplications 6AC3-7 at the @niversit" of #llinois 3an 5iego 3uperco puter Center 6353C7 at the @niversit" of California -rgonne Aational 8aborator" in -rgonne, #llinois Center for -dvanced Co puting +esearch 6C-C+7 at the California #nstitute of Technolog" in Pasadena Pittsburgh 3uperco puter Center 6P3C7

The TeraGrid pro,ect is so eti es called a )c"berinfrastructure) that brings together distributed scientific instru ents, terascale and petascale data archives, and gigabit networks. ?igure $.< shows different la"ers of the TeraGrid architecture.

Figure 2.;. Tera"rid architecture.

8ase "rid %ervices ,ayer )&esource ,ayer*

3o e of the base services re!uired for the TeraGrid are authentication and access anage ent, resource allocation and anage ent, data access and anage ent, resource infor ation service, and accounting. This la"er for s the building block for the other high-level services.

$ore "rid %ervices )$ollective ,ayer*

/ith a ain focus on coordination of ultiple resources, core grid services include functionalities for data ove ent, ,ob scheduling, onitoring, and resource discover".

'dvanced "rid %ervices

These are high-level application services, which provide super schedulers, repositories, categorization, resource discover", and distributed accounting. 4ased on the above architecture, the TeraGrid is defining protocols, sche a, and interfaces at each la"er of the above architecture but not i ple entation-specific details. These interfaces provide interoperabilit" between the sites i ple enting the TeraGrid pro,ect. "0" In!ormation Power Grid 4IPG5 A-3-0s #nfor ation Power GridI1<J 6#PG7 is a high-perfor ance co putational and data grid. Grid users can access widel" distributed heterogeneous resources fro an" location, with #PG iddleware adding securit", unifor it", and control. 3o e of the a,or pro,ects undertaken b" #PG are(

&esource 8roker
- grid user has to ake a resource selection fro a large nu ber and variet" of resources that the" could use for an application. ?or each potential resource, the resource selection s"ste considers the following factors(

Co puter s"ste characteristics, such as a ount of e or", a ount of disk space, CP@ speed, nu ber of CP@s, t"pe of operating s"ste , available software, and so on The ti e re!uired for the e.ecution of the ,ob The cost to use that resource or co puter s"ste

7erformance 7rediction
There are several t"pes of predictions that are useful when deciding where to run applications. These include ,ob'application e.ecution ti e on different co puter s"ste s, wait ti e in scheduling !ueues before the ,ob begins e.ecuting, and the ti e to transfer files between co puter s"ste s.

3ob (anager
Cob 1anager is used to reliabl" e.ecute ,obs and aintain infor ation about ,obs. These ,obs consist of file operations 6i.e., cop" a file between achines, create a director", delete a file or director", and so on7 and e.ecution operations 6i.e., e.ecute an application on a specific co puter s"ste 7.

7ortability (anager )7(*

Portabilit" is a ke" issue with the grid environ ent and P1 is responsible for the establish ent of a suitable environ ent for the e.ecution of the user application b" auto aticall" identif"ing the dependencies of each user progra .

Frame#ork for $ontrol and 9bservation in Distributed -nvironments )$9D-*

The C*5B pro,ect provides a secure, scalable, and e.tensible fra ework for aking observations on re ote co puter s"ste s. #t then trans its this observational data to where it is needed, perfor ing actions on re ote co puter s"ste s and anal"zing observational data to deter ine what actions should be taken. *bservational data is trans itted using a distributed event service.

Test and (onitoring %ervice

The #PG Test and 1onitoring 3ervice will provide a fra ework for e.a ining the health of the grid, so that proble s with, or degradation of, grid resources are pro ptl" detectedF the appropriate organization, s"ste ad inistrator, or user is notifiedF and solutions are dispatched in a ti el" anner.

Dynamic 'ccounting %ystem )D'%*

5-3 provides the following enhanced categories of accounting functionalit" to the #PG co unit"(

-llows a grid user to re!uest access to a local resource via the presentation of grid credentials 5eter ines and grants the appropriate authorizations for a user to access a local resource without re!uiring a pree.isting account on the resource to govern local authorizations B.changes allocation data between sites to anner instead of a site-specific anner anage allocations in a grid-wide

Provides resource pricing infor ation on the grid Collects and reports the necessar" data to ensure accountabilit" of grid users for the use of resources and to enable resource providers to better anage their grid resources

$9&8'-+7" +nfrastructure
The C*+4--#PG infrastructure gives C*+4--enabled applications, such as ob,ectoriented propulsion s"ste s being developed at A-3- Glenn +esearch Center, the abilit" to utilize the widel" distributed resources ade available b" the A-3- #PG.

Commer#ial .rganizations Building and 7sing Grid6Based 0olutions

#n the last couple of "ears we have seen a tre endous co ercial interest in Grid Co puting solutions. These co ercial aspects are centered on the concept of resource sharing and resource virtualization principles. Bver" co puting resource including clusters, servers, blades, operating s"ste s, and applications are viewed as utilities. The advance ent of Grid Co puting through the principles of open technologies, standard-based integration, and hardware and software technolog" aturit" are behind these utilit" concepts. The ke" strateg" areas of grid applicabilit" in the co ercial world are utilit" co puting, resource virtualization, and on-de and co puting. 3o e of the pro inent technologies helping the co ercial organizations in their vision are(

-dvance ent of service-oriented architectures, in particular /eb services, enables organizations to start working on interoperable software solutions 2ardware virtualizations capabilities including clusters, blades, and so forth 3oftware capabilities in resource anage ent and provisioning including polic"-driven architectures to eet !ualit" of service, usage and accounting easure ents, and so on -utono ic co puting principles enable high availabilit" of resources

'ome o( the core concepts introduced )* the ma+or commercial organi!ations include Business On Demand solutions )* IBM, the -tilit* computing and Data centers

o( .$, /1 technolog* initiative (rom 'un Micros*stems, and Microso(t's './et' strategies. "here are other organi!ations alread* pla*ing a ma+or role in Grid Computing in(rastructure deplo*ment. "hese participants include IBM Corporation, 0va1i, $lat(orm, and others. Chapter 2. "he Grid Computing 0natom*
#n ?oster 61==<7, the Grid concept is defined as the controlled and coordinated resource sharing and proble solving in d"na ic, ulti-institutional virtual organizations. This sharing of resources, ranging fro si ple file transfers to co ple. and collaborative proble solving, is acco plished within controlled and well-defined conditions and policies. The d"na ic grouping of individuals, ultiple groups, or organizations that defined the conditions and rules for sharing are called virtual organizations. #n this chapter, we will define the )grid proble ,) the core concepts of a )virtual organization,) and the architecture defined to solve the )grid proble .)

"he 3irtual Organi!ation Concept in Grid Computing Is 4e*

*ne of the significant operational concepts in Grid Co puting is the notion of the virtual organization. This involves the d"na ic co putation-oriented task of defining groupings of individuals, such as ultiple groups or organizations. -lthough this is perhaps si ple to understand, in theor", it re ains co ple. across several di ensions. The co ple.ities involved in this d"na ic asse bl" revolve around identif"ing and bringing in those hu ans that initiall" defined the conditions in order to instantiate the grid. ?or instance, auto ated consideration of the rules, the policies, and the specific conditions affecting operations in the grid are, hence, the generating force for processing and sharing the infor ation with those individuals in an" virtual organization of a grid. The si plest wa" of thinking about this advanced Grid Co puting concept is captured in the ter virtual organizations. This t"pe of co putation-oriented grouping serves as the basis for identif"ing and anaging the grid co puter groups, associated with an" particular grid co unit" of end users.

The e erging Grid Co puting technologies, especiall" the *pen Grid 3ervice -rchitecture 6*G3-7, is pla"ing a a,or role in the standardization of the activities in the grid space. /e will see the details on these standards later on in this book. O 5a" 5a" @p P

The Grid Pro*lem

Grid Co puting has evolved as an i portant field in the co puter industr" b" differentiating itself fro the distributed co puting with an increased focus on the resource sharing, coordination, and high-perfor ance orientation. Grid Co puting is tr"ing to solve the proble s associated with resource sharing a ong a set of individuals or groups. These Grid Co puting resources include co puting power, data storage, hardware instru ents, on-de and software, and applications. #n this conte.t, the real proble s involved with resource sharing are resource discover", event correlation, authentication, authorization, and access echanis s. These proble s beco e proportionatel" ore co plicated when the Grid Co puting solution is introduced as a solution for utilit" co puting, where industrial applications and resources beco e available as sharable. The best e.a ple of this is in the #41 Corporation0s 4usiness *n 5e and resource i ple entations in Grid Co puting. This co ercial on-de and utilit" concept spanning across Grid Co puting services has introduced a nu ber of challenging proble s to the alread" co plicated grid proble do ains. These challenging proble s include service-level anage ent features, co ple. accounting, utilization etering, fle.ible pricing, federated securit", scalabilit", open-ended integration, and a ultitude of ver" difficult arra"s of networking services to sustain. #t is ke" to understand that the networking services can no longer be taken for granted, as these ver" i portant services now beco e the central nervous s"ste for the enable ent of all worldwide Grid Co puting environ ents. The Con#ept o! %irtual .rganizations The concept of a virtual organization is the ke" to Grid Co puting. #t is defined as a d"na ic set of individuals and'or institutions defined around a set of resource-sharing rules and conditions 6?oster, Eessel an, D Tuecke7. -ll these virtual organizations share so e co onalit" a ong the , including co on concerns and re!uire ents, but a" var" in size, scope, duration, sociolog", and structure. The e bers of an" virtual organization negotiate on resource sharing based on the rules and conditions defined in order to share the resources fro the thereb" auto aticall" constructed resource pool. -ssigning users, resources, and organizations fro different do ains across ultiple, worldwide geographic territories to a virtual organization is one of the funda ental technical challenges in Grid Co puting. This co ple.it" includes the definitions of the resource discover" echanis , resource sharing ethods, rules and conditions b" which this can be achieved, securit" federation and'or delegation, and access controls a ong the participants of the virtual organization. This challenge is both co ple. and co plicated across several di ensions. 8et us e.plore two e.a ples of virtual organizations in order to better understand their co on characteristics. The following describes these two e.a ples in si pleto-understand ter s.

1. Thousands of ph"sicists fro different laboratories ,oin together to create, design, and anal"ze the products of a a,or detector at CB+A, the Buropean high energ" ph"sics laborator". This group for s a )data grid,) with intensive co puting, storage, and network services resource sharing, in order to anal"ze petab"tes of data created b" the detector at CB+A. This is one e.a ple of a virtual organization. $. - co pan" doing financial odeling for a custo er based on the data collected fro various data sources, both internal and e.ternal to the co pan". This specific virtual organization custo er a" need a financial forecasting capabilit" and advisor" capabilit" on their invest ent portfolio, which is based on actual historic and current real-ti e financial arket data. This financial institution custo er can then be responsive b" for ing a d"na ic virtual organization within the enterprise for achieving ore benefit fro advanced and assive for s of co putational power 6i.e., application service provider7 and for data 6i.e., data access and integration provider7. This d"na ic, financiall" oriented, virtual organization can now reduce undesirable custo er wait ti e, while increasing reliabilit" on forecasting b" using realti e data and financial odeling techni!ues. This is another e.a ple of a virtual organization. /ith a close observation of the above- entioned virtual organizations, we can infer that the nu ber and t"pe of participants, the resources being shared, duration, scale, and the interaction pattern between the participants all var" between an" one single virtual organization to another. -t the sa e ti e, we can also infer that there e.ist co on characteristics a ong co peting and so eti es distrustful participants that contributed to their virtual organization for ation. The" a" include 6?oster, Eessel an, D Tuecke7 so e of the following ite s for consideration( 1. Co on concerns and re!uire ents on resource sharing. - virtual organization is a well-defined collection of individuals and'or institutions that share a co on set of concerns and re!uire ents a ong the . ?or e.a ple, a virtual organization created to provide financial forecast odeling share the sa e concerns on securit", data usage, co puting re!uire ents, resource usage, and interaction pattern. $. Conditional, ti e-bound, and rules-driven resource sharing. +esource sharing is conditional and each resource owner has full control on aking the availabilit" of the resource to the sharable resource pool. These conditions are defined based on utuall" understandable policies and access control re!uire ents 6authentication and authorization7. The nu ber of resources involved in the sharing a" d"na icall" var" over ti e based on the policies defined. %. 5"na ic collection of individuals and'or institutions. *ver a period of ti e a virtual organization should allow individuals and'or groups into and out of the collectionF provided the" all share the sa e concerns and re!uire ents on resource sharing. &. 3haring relationship a ong participants is peer-to-peer in nature. The sharing relation a ong the participants in a virtual organization is peer-to-peer, which

e phasizes that the resource provider can beco e a consu er to another resource. This introduces a nu ber of securit" challenges including utual authentication, federation, and delegation of credentials a ong participants. 5. +esource sharing based on an open and well-defined set of interaction and access rules. *pen definition and access infor ation ust e.ist for each sharable resource for better interoperabilit" a ong the participants. The above characteristics and nonfunctional re!uire ents of a virtual organization lead to the definition of an architecture for establish ent, anage ent, and resource sharing a ong participants. -s we will see in the ne.t section, the focus of the grid architecture is to define an interoperable and e.tensible solution for resource sharing within the virtual organization. Grid "r#hite#ture - new architecture odel and technolog" was developed for the establish ent, anage ent, and cross-organizational resource sharing within a virtual organization. This new architecture, called grid architecture, identifies the basic co ponents of a grid s"ste , defines the purpose and functions of such co ponents and indicates how each of these co ponents interacts with one another 6?oster, Eessel an, D Tuecke7. The ain attention of the architecture is on the interoperabilit" a ong resource providers and users to establish the sharing relationships. This interoperabilit" eans co on protocols at each la"er of the architecture odel, which leads to the definition of a grid protocol architecture as shown in ?igure %.1. This protocol architecture defines co on echanis s, interfaces, sche a, and protocols at each la"er, b" which users and resources can negotiate, establish, anage, and share resources.

Figure 3.1. This illustrates a layered grid architecture and its relationshi to the +nternet rotocol architecture )Foster, <esselman, = Tuecke*.

?igure %.1 illustrates the co ponent la"ers of the architecture with specific capabilities at each la"er. Bach la"er shares the behavior of the co ponent la"ers described in the ne.t discussion. -s we can see in this illustration, each of these co ponent la"ers is co pared with their corresponding #nternet protocol la"ers, for purposes of providing ore clarit" in their capabilities.

Aow let us e.plore each of these la"ers in

ore detail.

Fabric ,ayer> +nterface to ,ocal &esources

The ?abric la"er defines the resources that can be shared. This could include co putational resources, data storage, networks, catalogs, and other s"ste resources. These resources can be ph"sical resources or logical resources b" nature. T"pical e.a ples of the logical resources found in a Grid Co puting environ ent are distributed file s"ste s, co puter clusters, distributed co puter pools, software applications, and advanced for s of networking services. These logical resources are i ple ented b" their own internal protocol 6e.g., network file s"ste s IA?3J for distributed file s"ste s, and clusters using logical file s"ste s I8?3J7. These resources then co prise their own network of ph"sical resources. -lthough there are no specific re!uire ents toward a particular resource that relates to integrating itself as part of an" grid s"ste , it is reco ended to have two basic capabilities associated with the integration of resources. These basic capabilities should be considered as )best practices) toward Grid Co puting disciplines. These best practices are as follows( 1. Provide an )in!uir") echanis whereb" it allows for the discover" against its own resource capabilities, structure, and state of operations. These are value-added features for resource discover" and onitoring. $. Provide appropriate )resource anage ent) capabilities to control the Go3 the grid solution pro ises, or has been contracted to deliver. This enables the service provider to control a resource for opti al anageabilit", such as 6but not li ited to7 start and stop activations, proble resolution, configuration anage ent, load balancing, workflow, co ple. event correlation, and scheduling.

$onnectivity ,ayer> (anages $ommunications

The Connectivit" la"er defines the core co unication and authentication protocols re!uired for grid-specific networking services transactions. Co unications protocols, which include aspects of networking transport, routing, and na ing, assist in the e.change of data between fabric la"ers of respective resources. The authentication protocol builds on top of the networking co unication services in order to provide secure authentication and data e.change between users and respective resources. The co unication protocol can work with an" of the networking la"er protocols that provide the transport, routing, and na ing capabilities in networking services solutions. The ost co onl" used Aetwork la"er protocol is the TCP'#P #nternet protocol stackF however, this concept and discussion is not li ited to that protocol. The authentication solution for virtual organization environ ents re!uires significantl" ore co ple. characteristics. The following describes the characteristics for consideration(

%ingle sign-on
This provides an" ultiple entities in the grid fabric to be authenticated onceF the user can then access an" available resources in the grid ?abric la"er without further user authentication intervention.

Delegation
This provides the abilit" to access a resource under the current users per issions setF the resource should be able to rela" the sa e user credentials 6or a subset of the credentials7 to other resources respective to the chain of access.

+ntegration #ith local resource s ecific security solutions

Bach resource and hosting has specific securit" re!uire ents and securit" solutions that atch the local environ ent. This a" include 6for e.a ple7 Eerberos securit" ethods, /indows securit" ethods, 8inu. securit" ethods, and @A#9 securit" ethods. Therefore, in order to provide proper securit" in the grid fabric odel, all grid solutions ust provide integration with the local environ ent and respective resources specificall" engaged b" the securit" solution echanis s.

/ser-based trust relationshi s

#n Grid Co puting, establishing an absolute trust relationship between users and ultiple service providers is ver" critical. This acco plishes the environ ental factor to which there is then no need of interaction a ong the providers to access the resources that each of the provide.

Data security
The data securit" topic is i portant in order to provide data integrit" and confidentialit". The data passing through the Grid Co puting solution, no atter what co plications a" e.ist, should be ade secure using various cr"ptographic and data encr"ption echanis s. These echanis s are well known in the prior technological art, across all global industries.

&esource ,ayer> %haring of a %ingle &esource

The +esource la"er utilizes the co unication and securit" protocols defined b" the networking co unications la"er, to control the secure negotiation, initiation, onitoring, etering, accounting, and pa" ent involving the sharing of operations across individual resources. The wa" this works is the +esource la"er calls the ?abric la"er functions in order to access and control the ultitude of local resources. This la"er onl" handles the individual resources and, hence, ignores the global state and ato ic actions across the other resource collection, which in the operational conte.t is the responsibilit" of the Collective la"er.

There are two pri ar" classes of resource la"er protocols. These protocols are ke" to the operations and integrit" of an" single resource. These protocols are as follows(

+nformation 7rotocols
These protocols are used to get infor ation about the structure and the operational state of a single resource, including configuration, usage policies, service-level agree ents, and the state of the resource. #n ost situations, this infor ation is used to onitor the resource capabilities and availabilit" constraints.

(anagement 7rotocols
The i portant functionalities provided b" the

anage ent protocols are(

Aegotiating access to a shared resource is para ount. These negotiations can include the re!uire ents on !ualit" of service, advanced reservation, scheduling, and other ke" operational factors. Perfor ing operation6s7 on the resource, such as process creation or data access, is also a ver" i portant operational factor. -cting as the service'resource polic" enforce ent point for polic" validation between a user and resource is critical to the integrit" of the operations. Providing accounting and pa" ent is andator". anage ent functions on resource sharing

1onitoring the status of an operation, controlling the operation including ter inating the operation, and providing as"nchronous notifications on operation status, is e.tre el" critical to the operational state of integrit".

#t is reco ended that these resource-level protocols should be ini al fro a functional overhead point of view and the" should focus on the functionalit" each provides fro a utilit" aspect.

The $ollective ,ayer> $oordinating (ulti le &esources

/hile the +esource la"er anages an individual resource, the Collective la"er is responsible for all global resource anage ent and interaction with a collection of resources. This la"er of protocol i ple ents a wide variet" of sharing behaviors 6protocols7 utilizing a s all nu ber of +esource la"er and Connectivit" la"er protocols. 3o e ke" e.a ples of the co on, Co puting s"ste are as follows( ore visible collective services in a Grid

Discovery %ervices
This enables the virtual organization participants to discover the e.istence and'or properties of that specific available virtual organization0s resources.

$oallocation, %cheduling, and 8rokering %ervices

These services allow virtual organization participants to re!uest the allocation of one or ore resources for a specific task, during a specific period of ti e, and to schedule those tasks on the appropriate resources.

(onitoring and Diagnostic %ervices

These services afford the virtual organizations resource failure recover" capabilities, onitoring of the networking and device services, and diagnostic services that include co on event logging and intrusion detection. -nother i portant aspect of this topic relates to the partial failure of an" portion of a Grid Co puting environ ent, in that it is critical to understand an" and all business i pacts related to this partial failure are well known, i ediatel", as the failure begins to occurMall the wa" through its corrective healing stages.

Data &e lication %ervices

These services support the anage ent aspects of the virtual organization0s storage resources in order to a.i ize data access perfor ance with respect to response ti e, reliabilit", and costs.

"rid--nabled 7rogramming %ystems

These s"ste s allow fa iliar progra ing odels to be utilized in the Grid Co puting environ ents, while sustaining various Grid Co puting networking services. These networking services are integral to the environ ent in order to address resource discover", resource allocation, proble resolution, event correlation, network provisioning, and other ver" critical operational concerns related to the grid networks.

?orkload (anagement %ystems and $ollaborative Frame#orks

This provides ultistep, as"nchronous, ultico ponent workflow anage ent. This is a co ple. topic across several di ensions, "et a funda ental area of concern for enabling opti al perfor ance and functional integrit".

%oft#are Discovery %ervices

This provides the echanis s to discover and select the best software i ple entation6s7 available in the grid environ ent, and those available to the platfor based on the proble being solved.

$ommunity 'uthorization %ervers

These servers control resource access b" enforcing co unit" utilization policies and providing these respective access capabilities b" acting as polic" enforce ent agents.

$ommunity 'ccounting and 7ayment %ervices

These services provide resource utilization etrics, while at the sa e ti e generating pa" ent re!uire ents for e bers of an" co unit". -s we can observe based on the previous discussion, the capabilities and efficiencies of these Collective la"er services are based on the underl"ing la"ers of the protocol stack. These collective networking services can be defined as general-purpose Grid Co puting solutions to narrowed-do ain and application-specific solutions. -s an e.a ple, one such service is accounting and pa" ent, which is ost often ver" specific to the do ain or application. *ther notable and ver" specialized Collective la"er services include schedulers, resource brokers, and workload anagers 6to na e a few7.

'

lication ,ayer> /ser-Defined "rid ' lications

These are user applications, which are constructed b" utilizing the services defined at each lower la"er. 3uch an application can directl" access the resource, or can access the resource through the Collective 3ervice interface -P#s 6-pplication Provider #nterface7. Bach la"er in the grid architecture provides a set of -P#s and 35Es 6software developer kits7 for the higher la"ers of integration. #t is up to the application developers whether the" should use the collective services for general-purpose discover", and other high-level services across a set of resources, or if the" choose to start directl" working with the e.posed resources. These user-defined grid applications are 6in ost cases7 do ain specific and provide specific solutions. Grid "r#hite#ture and 2elationship to .ther )istri*uted Te#hnologies #t is a known fact that in the technolog" of art that there are nu erous well-defined and well-established technologies and standards developed for distributed co puting. This foundation has been a huge success 6to so e e.tent7 until we entered into the do ain of heterogeneous resource sharing and the for ation of virtual organizations. 4ased on our previous discussions, grid architectures are defined as a coordinated, highl" auto ated, and d"na ic sharing of resources for a virtual organization. #t is appropriate that we turn our attention at this stage toward the discussion regarding how these architecture approaches differ fro the prior art of distributed technologies, that is, how the two approaches co pli ent each other, and how we can leverage the best practices fro both approaches. *ur discussion will now begin to e.plore notions of the widel" i ple ented distributed s"ste s, including /orld /ide /eb environ ents, application and storage service providers, distributed co puting s"ste s, peer-to-peer co puting s"ste s, and clustering t"pes of s"ste s.

?orld ?ide ?eb

- nu ber of open and ubi!uitous technologies are defined for the /orld /ide /eb 6TCP, 2TTP, 3*-P, 9187 that in turn akes the /eb a suitable candidate for the construction of the virtual organizations. 2owever, as of now, the /eb is defined as a

browserQserver essaging e.change odel, and lacks the odels re!uired for a realistic virtual organization.

ore co ple. interaction

-s an e.a ple, so e of these areas of concern include single-sign-on, delegation of authorit", co ple. authentication echanis s, and event correlation echanis s. *nce this browser-to-server interaction atures, the /eb will be suitable for the construction of grid portals to support ultiple virtual organizations. This will be possible because the basic platfor s, fabric la"ers, and networking connectivit" la"ers of technologies will re ain the sa e.

Distributed $om uting %ystems

The a,or distributed technologies including C*+4-, C$BB, and 5C*1 are well suited for distributed co puting applicationsF however, these do not provide a suitable platfor for sharing of resources a ong the e bers of the virtual organization. 3o e of the notable drawbacks include resource discover" across virtual participants, collaborative and declarative securit", d"na ic construction of a virtual organization, and the scale factor involved in potential resource-sharing environ ents. -nother a,or drawback in distributed co puting s"ste s involves the lack of interoperabilit" a ong these technolog" protocols. 2owever, even with these perceived drawbacks, so e of these distributed technologies have attracted considerable Grid Co puting research attention toward the construction of grid s"ste s, the ost notable of which is Cava C#A#.I1J This s"ste , C#A#, is focused on a platfor -independent infrastructure to deliver services and obile code in order to enable easier interaction with clients through service discover", negotiation, and leasing.

'

lication and %torage %ervice 7roviders

-pplication and storage service providers nor all" outsource their business and scientific applications and services, as well as ver" high-speed storage solutions, to custo ers outside their organizations. Custo ers negotiate with these highl" effective service providers on Go3 re!uire ents 6i.e., hardware, software, and network co binations7 and pricing 6i.e., utilit"-based, fi.ed, or other pricing options7. Aor all" speaking, these t"pes of advanced services arrange ents are e.ecuted over so e t"pe of virtual private network 6KPA7, or dedicated line, b" narrowing the do ain of securit" and event interactions. This is oftenti es so ewhat li ited in scope, while the KPA or private line is ver" static in nature. This, in turn, reduces the visibilit" of the service provider to a lower and fi.ed scale, with the lack of co ple. resource sharing a ong heterogeneous s"ste s and interdo ain networking service interactions. This being said, the introduction of the Grid Co puting principles related to resource sharing across virtual organizations, along with the construction of virtual organizations "ielding interdo ain participation, will alter this situation. 3pecificall", this will enhance this utilit" odel of application service providers and storage service providers 6-3P'33P7 to a ore fle.ible and ature value proposition.

7eer-to-7eer $om uting %ystems

3i ilar to Grid Co puting, peer-to-peer 6P$P7 co puting is a relativel" new co puting discipline in the real of distributed co puting. 4oth P$P and distributed co puting are focused on resource sharing, and are now widel" utilized throughout the world b" ho e, co ercial, and scientific arkets. 3o e of the a,or P$P s"ste s are 3BT#Rho eI$J and file sharing s"ste environ ents 6e.g., Aapster, Eazaa, 1orpheus, and Gnutella7. The a,or difference between Grid Co puting and P$P co puting is centered on the following notable points( 1. The" differ in their target co unities. Grid co unities can be s all with regard to nu ber of users, "et will "ield a greater applications focus with a higher level of securit" re!uire ents and application integrit". *n the other hand, the P$P s"ste s define collaboration a ong a larger nu ber of individuals and'or organizations, with a li ited set of securit" re!uire ents and a less co ple. resource-sharing topolog". $. The grid s"ste s deal with ore co ple., ore powerful, ore diverse, and a highl" interconnected set of resources than that of the P$P environ ents. The convergence of these areas toward Grid Co puting is highl" probable since each of the disciplines are dealing with the sa e proble of resource sharing a ong the participants in a virtual organization. There has been so e work, to date, in the Global Grid ?oru 6GG?7 focused on the erger of these co pli entar" technologies for the interests of integrating the larger audience.

$luster $om uting

Clusters are local to the do ain and constructed to solve inade!uate co puting power. #t is related to the pooling of co putational resources to provide ore co puting power b" parallel e.ecution of the workload. Clusters are li ited in scope with dedicated functionalit" and local to the do ain, and are not suitable for resource sharing a ong participants fro different do ains. The nodes in a cluster are centrall" controlled and the cluster anager is aware of the state of the node. This for s onl" a subset of the grid principle of ore widel" available, intra'interdo ain, co unication, and resource sharing.

Chapter 5. "he Grid Computing #oad Map

The last decade has noted a substantial change in the wa"s global industries, businesses, and ho e users appl" co puting devices, including a wide variet" of ubi!uitous co puting resources and advanced /eb services. #nitiall", the focus was on localized co puting resources and respective servicesF however, the capabilities have changed over ti e and we are now in an environ ent consisting of sophisticated, virtualized, and widel" distributed 4usiness *n 5e and utilit" services.

1a,or global organizations, solutions providers, service providers, and technolog" innovators, who we have alread" discussed in the earlier chapters 6and even those we have not "et discussed7, have absolutel" contributed to this technolog" evolution. #n the previous chapter, we e.plored several grid architecture points, and the architectural relationships between grid and other distributed co puting technologies. -s we can see fro this discussion and the following illustration, the evolution of Grid Co puting is progressing at a ver" rapid rate. This co puting evolution is tightl" aligned with the incredible and ver" rapid evolution of the #nternet and other open standards architectures. -s shown in ?igure &.1, the evolution of Grid Co puting is broadl" classified into three generations. This Grid Co puting evolution is discussed in detail b" +oure, 4aker, Cennings, and 3hadbolt.

Figure !.1. The "rid $om uting technology road ma is sim ly illustrated in terms of generations.

#n previous chapters, we e.plored so e of the a,or pro,ects and organizational initiatives that contributed to the first generation and second generation of Grid Co puting. The first two phases were concentrating on large-scale resource discover", utilization, and sharing within the virtual organizational boundaries. The a,or drawback in these two phases was the lack of transparenc" a ong the iddleware, which contributed to onolithic and noninteroperable solutions for each grid environ ent. This difference in the first two stages results in a vertical tower of solutions and applications for resource sharing a ong organizations. Toda", we are in the third generation of Grid Co puting where the applications and solutions are focusing on open technolog"-based, service-oriented, and horizontall"-oriented solutions that are aligned with the other global industr" efforts. The grid infrastructures are clearl" transitioning fro infor ation aware to that of knowledge-centric fra eworks. #n this chapter we begin to e.plore a detailed discussion on the third generation of technologies, and the respective grid architectures and the road ap that is guiding the ne.t generation of grid technolog" initiatives.

The ne.t generations of Grid Co puting technologies that are channeling this third generation of grid initiatives are noted as(

-utono ic co puting 4usiness *n 5e and and infrastructure virtualization 3ervice-oriented architecture and grid 3e antic grids

"utonomi# Computing
The ter )autono ic) co es fro an analog" to the autono ic central nervous s"ste in the hu an bod", which ad,usts to an" situations auto aticall" without an" e.ternal help. /ith the increasing co ple.it" in dealing with distributed s"ste s, solutions, and shared resources in grid environ ents, we re!uire a significant a ount of autono ic functions to anage the grid. -s detailed in ?igure &.$, basic autono ic co puting s"ste s basic principles(I1J

ust follow the four

3elf-configuring 6able to adapt to the changes in the s"ste 7 3elf-opti izing 6able to i prove perfor ance7 3elf-healing 6able to recover fro istakes7

3elf-protecting 6able to anticipate and cure intrusions7

Figure !.2. 'utonomic com uting vision is robust across several com limentary dimensions.

*rchestrating co ple. connected proble s on heterogeneous distributed s"ste s is a co ple. ,ob and re!uires a nu ber of autono ic features for the infrastructure and resource anage ent. Thus, it is i portant that our s"ste s be as self-healing and self-configuring as possible in order to eet the re!uire ents of resource sharing and to handle failure conditions. These autono ic enhance ents to the e.isting grid

fra ework at the application and dependable grid infrastructure.

iddleware fra ework level provide a scalable and

#41, the pioneer in worldwide autono ic co puting initiatives, has alread" i ple ented a nu ber of pro,ects around the world in this general concept, while keeping in ind the s"nergies to create global grid solutions. These global grid solutions are continuousl" being enhanced to include autono ic co puting capabilities. Grid Co puting and autono ic co puting disciplines will continue to work closel" together to develop highl" reliable, efficient, self- anaging grids. #t is these two co puting disciplines that alone serve as the basis for the #41 Corporation0s global strategies underpinning 4usiness *n 5e and.I$J

Business .n )emand and In!rastru#ture %irtualization

@tilit"-like co puting is one of the ke" technolog" resources that help businesses to develop 4usiness *n 5e and capabilities. 2owever, 4usiness *n 5e and is not ,ust about utilit" co puting, as it has a uch broader set of ideas about the transfor ation of business practices, process transfor ation, and technolog" i ple entations. Co panies striving to achieve the 4usiness *n 5e and operational odels will have the capacit" to sense and respond to fluctuating arket conditions in real ti e, while providing products and services to custo ers in a 4usiness *n 5e and operational odel. #n general, on-de and business has four essential characteristics 6?igure &.%7(I%J 1. +esponsive. 4usiness *n 5e and has to be responsive to d"na ic, unpredictable changes in de and, suppl", pricing, labor, and co petition. $. Kariable. 4usiness *n 5e and has to be fle.ible in adapting to variable cost structure and processes associated with productivit", capital, and finance. %. ?ocused. 4usiness *n 5e and has to focus on their core co petenc", its differentiating tasks and assets along with closer integration with its partners. &. +esilient. - 4usiness *n 5e and co pan" has to be capable of anaging changes and co petitive threats with consistent availabilit" and securit".

Figure !.3. 8usiness 9n Demand characteristics are shared across four distinct areas.

#n order to achieve the above core capabilities, a 4usiness *n 5e and operating environ ent, as shown in ?igure &.&, ust possess the following essential capabilities( 1. #ntegrate. #ntegrated s"ste s enable sea less linkage across the enterprise and across its entire range of custo ers, partners, and suppliers. $. Kirtualization. +esource virtualization enables the best use of resources and ini izes co ple.it" for users. /e can achieve the virtualization of resources through the use of a nu ber of e.isting and e erging technologies including clusters, 8P-+s, server blades, and grid. 4ased on our earlier discussions, we know that grids provide the best use of the virtualized resources for its virtuall" organized custo ers within the constraints of service-level agree ents and policies. %. -uto ation. -s we discussed in the last section, the autono ic capabilities provides a dependable technolog" fra ework for an on-de and operating environ ent. &. *pen standards. -n open, integrateable technolog" allows resource sharing to be ore odular. 3o e of the ost notable open standards are 918, /eb services, and *G3- standards.

Figure !.!. The 8usiness 9n Demand o erating environment is rich #ith autonomic rocess enablement combined #ith advanced conce ts in "rid $om uting, like virtualization.

-s previousl" discussed, we have seen that the infrastructure virtualization transfor ation can be achieved b" the utilization of the Grid Co puting infrastructure. These sharable virtualized resources for the backbone for a 4usiness *n 5e and environ ent. 4e"ond the need for virtualization of hardware resources, the virtualization of data and software applications ust also occur. This enables access to resources as a single entit", and enabling applications to respond !uickl" to the d"na ic needs of the enterprise. This virtualization provides co putational and'or data grids for high co putation-intensive throughput, as well as a unifor data access echanis .

0ervi#e6.riented "r#hite#ture and Grid

- distributed s"ste consists of a set of software agents that all work together to i ple ent so e intended functionalit". ?urther ore, the agents in a distributed s"ste do not operate in the sa e processing environ ent, so the" ust co unicate b" hardware'software protocol stacks that are intrinsicall" less reliable than direct code invocation and shared e or". This has i portant architectural i plications because distributed s"ste s re!uire that developers of infrastructure and applications consider the unpredictable latenc" of re ote access, and take into account issues of concurrenc" and the possibilit" of an unplanned partial failure 6Eendall, /aldo, /ollrath, D /"ant, 1==&7. - service-oriented architecture 63*-7 is a specific t"pe of distributed s"ste in which the agents are )software services) that perfor so e well-defined operation 6i.e., it provides a service7, and this t"pe of architecture can be invoked outside of the conte.t of a larger application. 4" this, we can infer a service is acting as a user-facing software co ponent of a larger application. This separation of functionalit" helps the users of the larger application to be concerned onl" with the interface description of the service. #n addition, the 3*- stresses that all services have to be a network-addressable interface that co unicates via standard protocols and data for ats called essages. The a,or functionalit" of an 3*- is the definition of the essages 6i.e., its for at, content, and e.change policies7 that is e.changed between the users and the services. The /eb architectureI&J and the /eb 3ervices -rchitectureI5J are instances of a service-oriented architecture 63*-7.

Grid is a distributed s"ste for sharing of resources a ong participants. -s we have seen in the first paragraph of this chapter, grid, being a distributed architecture, has to deal with proble s of the distributed co puting grid, including latenc", concurrenc", and partial failures. /e have discussed in earlier chapters of the grid architecture section that the current Grid Co puting architecture is built upon the e.isting distributed technologies with a a,or focus on resource sharing, interoperation, and virtual organizational securit". The 3*- is a distributed architecture with ore focus on the service interoperabilit", easier integration, and e.tensible and secure access. The /eb services architecture is gaining the ost attention in the industr" as an open, standards-based architecture with a ain focus on interoperabilit". The /%C is leading this initiative. The core co ponents of the /eb service architecture are shown in ?igure &.5.

Figure !.0. ?eb services architectures are a key enabler in the overall com uting disci line of "rid $om uting.

?ro a closer look at the above figure we can infer that 918 and related technologies 6918, 5T5, 918 3che a7 for the base technologies of the /eb services. /eb services are invoked and results are provided via essages that ust be e.changed over so e co unications ediu , where a co unication ediu can be a low-level networking services transport protocol 6e.g., teleco unications protocol ITCPJ7, and'or a high-level co unication protocol 62TTP7, and'or a co bination of both. The essage for at can be specified through the 3i ple *b,ect -ccess Protocol 63*-P7 and its e.tensions, but this capabilit" is not ,ust li ited to 3*-P. The 3*-P functionalit" provides a standard wa" for e.changing the essages. #nteroperabilit" across heterogeneous s"ste s re!uires a echanis to define the precise structure and data t"pes of the essages that has to be e.changed between a

essage producer and a consu er. The /eb 3ervice 5escription 8anguage 6/3587 is another desirable choice to describe the essage and e.change pattern. The 3*-P specification provides the definition of the 918-based infor ation that can be used for e.changing structured and t"ped infor ation between peers in a decentralized, distributed environ ent. 3*-P is funda entall" a stateless, one-wa" essage e.change paradig , but applications can create ore co ple. interaction patterns 6including re!uest'response and re!uest' ultiple responses7. 3*-P is silent on the se antics of an" application-specific data it conve"s. -t the sa e ti e 3*-P provides a fra ework 63*-P header7 b" which application-specific infor ation a" be conve"ed in an e.tensible anner. -lso, 3*-P provides a full description of the re!uired actions taken b" a 3*-P node on receiving a 3*-P essage. #n short, a 3*-P essage is a 3*-P envelope with a 3*-P header and a 3*-P bod" where the header contains se antic and etadata infor ation about the contents of the 3*-P bod", which for the essage. 1ost of the /eb service vendors toda" uses 3*-P as their essage pa"load container. The /358 provides a odel and an 918 for at for describing /eb services. /358 enables one to separate the description of the abstract functionalit" offered b" a service fro concrete details of a service description. Grid Co puting is all about resource sharing b" integrating services across distributed, heterogeneous, d"na ic virtual organizations for ed fro disparate sources within a single institution and'or e.ternal organization. This integration cannot be achieved without a global, open, e.tensible architecture agreed upon b" the participants of the virtual organization. The *G3- achieves these integration re!uire ents b" providing an *pen 3ervice*riented odel for establishing Grid Co puting architectures. The *G3- is described in detail in the )ph"siolog") paper 6?oster, Eessel an, Aick, D Tuecke7. The *G3- is aligned with the service-oriented architecture as defined b" the /%C and utilizes a /eb service as its fra ework and essage e.change architecture. Thanks to the valuable and innovative concepts of the *G3-, and the open nature of the standard, the GG? for ed an architecture work area to discuss the *G3- and its progra ing odel. The basic approach the *G3- has taken is to integrate itself with the /eb services architecture and define a progra ing odel using this e erging architecture. The *pen Grid 3ervice #nfrastructure 6*G3#7 uses /358 as its service description echanis and /eb service infrastructure for the essage e.change. /e will further e.plore the details surrounding the *G3- and its core co ponents that constitute this architecture in a later section of the book.

0emanti# Grids
The /%C initiated a ) etadata activit",) which defines a standard for a etadata definition surrounding a 3e antic /eb. The 3e antic /eb is defined as the ne.t generation of /eb services.

"he 'emantic 6e) De(ines the /e&t Generation o( 6e) 'ervices

The 3e antic /eb is an e.tension of the current /eb in which infor ation is given well-defined eaning, better enabling co puters and people to work in cooperation. #t0s the idea of having data on the /eb defined and linked in a wa" that it can be used for ore effective discover", auto ation, integration, and reuse across various applications. The /eb can reach its full potential if it beco es a place where data can be shared and processed b" auto ated tools as well as critical people skills 6/%C-3B17.

?igure &.: shows the se antic evolution. /e will start e.ploring this evolution with the understanding of the 3e antic /eb.I:J

Figure !.1. The %emantic ?eb and grid evolution is straightfor#ard across several dimensions, as sho#n in this illustration.

The two ost i portant technologies for building 3e antic /ebs are 918 and +esource 5escription ?ra ework 6+5?7. 918 allows users to add arbitrar" structure to docu ents through arkup tags, but sa"s nothing about the eaning of the structures. 1eaning is e.pressed b" the +5?, which encodes itself in sets of triples, wherein each triple represents the sub,ect, ob,ect, and the predicate of an ele entar" sentence. These triples can be written using 918 tags. The sub,ect and ob,ect are each identified b" a @niversal +esource #dentifier 6@+#7. -n +5? docu ent akes assertions that particular things, for instance, people and /eb pages, have properties 6e.g., )is a sister of) or )is the author of)7 with certain values 6e.g., another person, another /eb page7. ?or further clarification consider the e.a ple, )Ceff is the author of the book -4C.) #n this e.a ple, the sub,ect is )Ceff,) the predicate is )the author of,) and the ob,ect is )the book.) This structure turns out to be a natural se antic, eaning to describe the vast a,orit" of the data processed b" achines. The +5? has, hence, evolved as a data odel for logic processing.

-nother i portant aspect of the 3e antic /eb is the use of )ontolog") to describe collections of infor ation like concepts and relationships that can e.ist in an" se antic situations. This se antic ta.ono " defines classes of ob,ects and relations a ong the . ?igure &.; illustrates the 3e antic /eb architecture la"ers. The real power of the 3e antic /eb will be realized when people create an" progra s that collect data fro diverse sources, process the infor ation, and e.change the results with other progra s.

Figure !.4. The %emantic ?eb architecture is sho#n in this illustration #ith the necessary security and encry tion re@uired across all levels.

The 3e antic GridI;J is a natural evolution in Grid Co puting, toward a knowledgecentric and etadata-driven co puting paradig . The 3e antic Grid is an effort to utilize 3e antic /eb technologies in Grid Co puting develop ent efforts, fro the grid infrastructure to the deliver" of grid applications. These concepts will enhance ore auto ated resource and knowledge'infor ationbased resource sharing. Enowing this i portance of the evolution of a 3e antic /eb and its usabilit" in Grid Co puting, the GG? has created a research group for 3e antic Grid under the Grid -rchitecture area. /e can find a nu ber of 3e antic Grid pro,ects including Corporate *ntolog" Grid,I<J grid-enabled co binatorial che istr",I=J Collaborative -dvanced Enowledge TechnologiesI1>J in the Grid, and an" other significant initiative

0ummar(
The Grid Co puting technolog" road ap leads the natural evolution of distributed co puting with ore e phasis on open architecture odels, knowledge-centric solutions, and si pler for s of integration. This Grid Co puting evolution will enable easier resource discover", virtualization, and autono ic enhance ents for grid solutions.

#n the subse!uent sections of this book, we discuss the details of these highl" a bitious operating environ ents, software standards, and innovative progra odels.

ing

Part 3: The New Generation of Grid Computing Applications

#n toda"0s new generation of services, al ost weekl" we find new e erging approaches to applications processing and service deliver". -long with these new innovative applications are the open-ended architectures re!uired to sustain these advanced for s of s"ste atic operations. -long with these new and innovative services deliver" approaches are the incredible applications serving ultiple continents of end users. #n this part of the book, we will further e.plore in greater detail the service architecture odels, the service deliver" odels, advanced languages, advanced essaging sche es, innovative /eb services paradig s, and ore aspects of Grid Co puting disciplines. 3everal of the discussions will beco e rather technical as related to co puter language i ple entations. These are i portant, low-level details to understand, as it is b" virtue of these language i ple entations that Grid Co puting i ple entations are instantiated. 5etailed aspects of securit" will also be discussed. B.a ples of language i ple entations will be shown, at the coding level, to afford readers a clear understanding of the deep co ple.it" in establishing the grid, fro the language i ple entation view.

"his part o( the )oo1 on the new generation o( Grid Computing applications, discusses in great detail an unprecedented series o( capa)ilities never )e(ore reali!ed in computing solutions. "his, in turn, has ena)led (or the (irst time a unique opportunit* (or the trans(ormation o( )usiness enterprises, research capa)ilities, and academic endeChapter 7. Merging the Grid 'ervices 0rchitecture with the 6e) 'ervices 0rchitecture
The co puter progra ing and software odeling disciplines have gone through an incredible nu ber of changes during the last two decades. /e started with structured progra ing odels, then oved on to ob,ect-oriented progra ing odels, and then oved to co ponent-oriented progra ing and software design. Bach level of this progression was see ingl" built on top of the other. 3oftware design concepts then e erged fro si ple onolithic software design into a state of highl" collaborative and distributed software design. The latest approach in this progression is service-oriented architecture 63*-7 6see ?igure 5.17.

Figure 0.1. +n the %9', the e2change of messages is @uite straightfor#ard as a high-level conce t.

#n the earlier periods of software develop ent, the basic pre ise of the co ponent software ignores the details on interoperable essages and e.change patterns, while concentrating on the cohesive abstraction on software odels. 2owever, 3*- is concerned with interoperable essage interchange to and'or fro a essage producer to a essage consu er, while hiding the details of the essage processing. There are a nu ber of derivatives of this essage e.change pattern, based upon the s"nchronous'as"nchronous nature, the protocol e.change odel, the data for at, and the end points.avors.

0ervi#e6.riented "r#hite#ture
- service-oriented architecture is intended to define loosel" coupled and interoperable services'applications, and to define a process for integrating these interoperable co ponents. #n 3*-, the s"ste is deco posed into a collection of network-connected co ponents. -pplications and resources within a service-oriented architecture should not be built as a tightl" coupled onolithic odel. +ather, these applications are co posed d"na icall" fro the deplo"ed and available services in the network. These services are d"na icall" discovered and bound together in a loosel" coupled anner. This d"na ic construction allows the s"ste to !uickl" respond to new business re!uire ents. 4ecause these applications are not tightl" coupled to their co ponents, the" provide increased stabilit" and availabilit" to users, reacting to co ponent failure b" finding and binding to e!uivalent co ponents without re!uiring hu an intervention. The ost co onl" understood 3*- architectures are /eb and /eb services. The /eb architecture has evolved even before we started talking about the 3*-. *n careful e.a ination of the interaction odel e.hibited b" the /eb, it is inherent that it is a ediu for essage e.change between a consu er and producer using a co on, well understandable, and interoperable data odel, 2T18'92T18. There is no tight coupling that e.ists between the client and service. The above odel 6?igure 5.$7 was ade!uate for the co on user agent-based interaction. 4ut when the interaction pattern beco es co ple., such as business-tobusiness, the above /eb architecture odel needs ore polished essage e.change patterns to adapt to an" user agent and'or applications of choice. There co es the concept of a ore generalized solution, /eb services. The /eb service architecture e.tends the above interaction pattern further b" adding the power and e.pressiveness of 918.

Figure 0.2. (essaging interaction bet#een the ?eb bro#ser end user and the services roducer.

-s we can see in ?igure 5.%, the e.change essages centered on 918 and the interaction pattern have evolved to an an"-to-an" scenario. This fle.ible interaction pattern using 918 essages as the core data for at increases the value of 3*-s. This produces the interaction re!uestQresponse patterns, as"nchronousl", for better interoperabilit" between consu ers and an" of its producers. This is a ver" loosel" coupled s"ste .

Figure 0.3. (essaging interaction bet#een the end user and the roducer.

#n order to better align with 3*- principles, this architecture is polished with ore e phasis on standard definitions of the service description, registration, discover", and interactions. ?igure 5.& shows a co onl" used interaction pattern.

Figure 0.!. The %9' interaction attern.

?igure 5.& shows the following concepts(

- service provider creates a service for interaction and e.poses the service0s description for the consu ers with the necessar" essage for at and transport bindings. The service provider a" decide to register this service and its description with a registr" of choice. The service consu er can discover a service fro a registr" or directl" fro the service provider and can start sending essages in a well-defined 918 for at that both the consu er and service can consu e.

This is a si ple "et powerful concept of providing essage interactions. Bach of these interactions can be further broken down into different la"ers. -s an e.a ple, the interaction pattern between the consu er and the service is a co bination of essage, essage packaging, and transport protocols. This architecture needs to further e.tend b" adding Go3 re!uire ents, securit", and anage ent aspects. /e will cover these details in the co ing pages. 8et us now open discussion on the /eb services architecture as our e.a ple candidate to e.plore 3*-.

We* 0ervi#e "r#hite#ture

- /eb service is a software s"ste identified b" a @+#, whose public interfaces are defined and described using 918. The other software s"ste s can interact with these s"ste s using 918 essages. This definition closel" atches the /%C /eb service architecture group0s definition.I1J ?igure 5.5 e.plains this architectural definition.

Figure 0.0. The ?eb service architecture.

The core infor ation pro,ected b" ?igure 5.5 includes(

The /eb service architecture is built around the 918 technologies. The /eb service is independent of the underl"ing transport echanis . The essages e.changed between a custo er and services for s the base la"er of this architecture. These essages a" be packaged and e.changed using envelopes including 3*-P and its e.tension odels. The 3*-P e.tension odels provide a nu ber of 3*-P header essages for essage correlation, transactional capabilities, essage reliabilit", and service addressing. There is a high-level description on the essages to e.change and the interaction pattern. This description can be given through an" description language of choice. The ost notable a ong these description languages are the /eb 3ervice 5escription 8anguage, or si pl" /358. /e can build a nu ber of technologies around this architectural odel. These technologies can be high-end applications, infrastructure software, and iddleware solutions. *ther notable features are the vertical pillars for securit" and anage ent, which are needed for all the horizontal architecture co ponents.

Aow we will go through the details of these la"ers. /e will start our discussion on the core technolog" builder, 918.

;3/, 2elated Te#hnologies, and Their 2elevan#e to We* 0ervi#es

/e have seen earlier that the /eb service agents 6re!uesters and providers7 e.change infor ation in the for of essages. These essages are defined in ter s of 918 #nfoset.I$J The i portance of 918 lies on the concepts of a standard-based, fle.ible, and e.tendable data for at. The /eb service essages are defined using 918 #nfoset, 918 3che a, and 918 Aa espace standards. @nderstand that these base concepts of 918 essages is i portant to adhere to in order to develop interoperable solutions. The 918 #nfoset defines a set of infor ation ite s and their properties, which describes an 918 docu ent. These definitions help the standards and tools to validate the 918 docu ents created. ?or e.a ple, the /358 standard ust confor to the 918 #nfoset definition of an 918 docu ent. This is also valid for the essages e.changed between agents. - well-for ed 918 essage enables interoperation and easier integration. *ne i portant concern that a" arise is the serialization for at of the 918 docu ents for transport and binding. There are an" serialization for ats available for 918 including si ple 918 te.t strea s to binar" 918 strea s. Aote that the wire for at of the essage is transport and binding dependent. The other notable 918 construct is the essage sche a or essage for at definition. These sche as can be defined using the 918 sche aI%J standard, but a" not be sufficient for ore co ple. t"pes and assertions. -s of toda", ost of the 918 s"ste s tend to use 918 sche a as the standard for t"pe definition. #n the co ing "ears we will witness ore evolution in this area with the aturit" and inter ingling of 918 sche a with other standards such as +5?,I&J +B8-9-AG.I5J /e can observe in an" i ple entation situations that the co ple.ities of the 918 essages are growing with nu erous applications and standards. - proper partitioning of 918 docu ents is needed for the correct description and e.change of the essages. The 918 co unit" addresses this docu ent versioning and partitioning proble with 918 na espaceI:J definitions. -s we have seen in the previous illustration, these 918 technologies for the basis for all /eb services-related standards and essages. This list can be e.tended to other 918 fa il" suites of protocols such as 918 4ase,I;J 9Path,I<J and 9Pointer.I=J

;3/ 3essages and 'nveloping

#n this section we will see how 918 /eb service essages are packaged and enveloped. The ost notable echanis available is 3*-P. 2owever, we ust be aware that this is not the onl" enveloping echanis available for /eb services. There are other technologies available including 4BBP,I1>J 2TTP,I11J and ##*P.I1$J ?or e.a ple, we could send 918 essages over 2TTP operations 6GBT'P*3T'P@T'5B8BTB, etc.7, which provide so e basic enveloping constructs. 3ince 3*-P is the ost pro inent for 918 /eb services, we will concentrate our discussion on that protocol and its supported e.tension echanis s.

0."P 3*-PI1%J is a si ple and lightweight 918-based echanis for creating structured data packages that can be e.changed between network applications. *ur discussion on 3*-P is based on the latest 3*-P specification, 3*-P 1.$, which passes the reco endation criteria of the /%C organization. The 3*-P specification defines the following funda ental co ponents(

-n envelope that defines a fra ework for describing essage structure - set of encoding rules for e.pressing instances of application-defined data t"pes - convention for representing re ote procedure calls 6+PC7 and responses - set of rules for using 3*-P with 2TTP 1essage e.change patterns 61BP7 such as re!uestQresponse, one-wa", and peer-to-peer conversations

3*-P can be used in co bination with a variet" of network protocols, such as 2TTP, 31TP, 4BBP, ?TP, and +1#'##*P. -s we have noted fro previous i ple entation of /eb services, 3*-P is currentl" being used as the de facto standard for 918 essaging including enveloping and e.changing essages. 3*-P provides a si ple enveloping echanis and is proven in being able to work with e.isting networking services technologies, such as 2TTP. 3*-P is also ver" fle.ible and e.tensible. #t provides capabilities to add-on standards and applicationdefined e.tensions. The wide acceptance of 3*-P is based on the fact that it builds upon the 918 infoset. The for at of a 3*-P essage is for all" defined in 3*-P 1.$ Part 1F specificall", the 1essaging ?ra ework specification.I1&J ?igure 5.: illustrates a si ple 3*-P essage structure, as defined b" this specification.

Figure 0.1. %9'7 message formats.

-s illustrated in ?igure 5.:, a 3*-P essage is packaged in a 3*-P(Bnvelope, which consists of zero or ore 3*-P(2eader and e.actl" one 3*-P(4od". The 3*-P bod" and header can be further divided into blocks. /hile the 3*-P bod" blocks are

intended for the final receiver, the header blocks can be interpreted b" the 3*-P inter ediaries. ?igure 5.; illustrates such a essage e.change pattern.

Figure 0.4. %9'7 intermediaries.

The 3*-P header blocks carr" infor ation such as securit", transactional infor ation, correlation, and so on. These inter ediaries a" act on these header blocks, add ore blocks, change the , or leave the untouched. These header blocks can be targeted to so e inter ediar" or final receiver b" the use of )roles) attributes 6)actors) in 3*-P 1.17. The value 6specified b" @+#7 of the )roles) attribute can be an address or a standard role na e as defined b" the 3*-P specification, which are(

)ne.t)M each 3*-P inter ediar" and the ulti ate receiver role )none)M the 3*-P nodes ust not act in this role )ulti ate+eceiver)M the ulti ate receiver

ust act on this

ust act in this role

- sa ple 3*-P

essage with roles is defined in 8isting 5.1.

,isting 0.1. %am le %9'7 message #ith roles.

<?xml version="1.0" ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap envelope"> <env:!ea"er> <a:#irsthea"er$lo%& xmlns:a="http://ph.%om" env:role="http://ph.%om/example/role"> ... </a:#irsthea"er$lo%&> <':se%on"$lo%& xmlns:'="http://ph.%om" env:role="http://www.w3.org/2003/05/soap envelope/role/next"> ... </':se%on"$lo%&> </env:!ea"er> <env:$o"( >

... </env:$o"(> </env:Envelope>

2ere <a:#irsthea"er$lo%&> is targeted to 3*-P nodes who are acting on the role http(''ph.co 'e.a ple'role, whereas the <':se%on"$lo%&> ust need to be processed b" all 3*-P nodes in the path, and finall" b" the ulti ate receiver. #f no )role) is specified, it is assu ed for the ulti ate receiver. /e ust be cautious in the distinction of these roles, in that we ust identif" the actor on a essage header for the correct processing of the essage. There are two other attributes that we ust co bine with the )role) attribute. The" are ) ust@nderstand) and )rela".) /e will note the details in the processing odel in the following section. Thus far, we are discussing topics regarding the for at of the essage. 2owever, 3*-P is uch ore than si pl" a essage for at, it also provides a si ple fra ework for e.tensible essages and essage processing features. The 0."P Pro#essing 3odel The processing of a 3*-P essage is dependent on the role assu ed b" the processor. -s we have entioned above, the 3*-P headers are targeted using a )role) attribute. #f the 3*-P inter ediar" pla"s the role as defined b" the 3*-P essage, it can then process the essage. There are two options related to processing. #f the 3*-P header is targeted to this node and specifies a ) ust@nderstand) flag set to )true,) then the processing node ust process that header. #f there is no such re!uire ent 6i.e., ust@nderstand flag is not set7, it is up to the processing node to decide on the processing of the essage. *nce the processing is co pleted, the essage will be directed to the ne.t node. The decision on the ne.t node selection is not specified b" the 3*-P specification. Therefore, it is now the choice of the processing node to ake such a decision. 2owever, there are so e standards that e.ist to specif" co on routing echanis s, I15J I1:J such as /3-+outing and /3--ddressing. -nother interesting aspect of this essage-forwarding paradig is the concept of rela"ing 3*-P headers. - header can have a )rela") attribute value 6i.e., true or false7 to indicate that nonprocessed headers get forwarded to the ne.t node. The default value is )false.) This indicates a 3*-P node, which is targeted b" this header, will not forward this header to the ne.t node. #f we refer back to the 3*-P 1.1 specification 63*-P1.17, we could see that there is no standard processing rules for 3*-P e.tensions 6header7 processing. This causes a nu ber of interoperabilit" proble s. 2owever, the 3*-P 1.$ specification introduces the following core 3*-P constructs in order to support 3*-P e.tensions. 0."P 1eatures

- 3*-P feature is an e.tension to the 3*-P essaging fra ework. These features are co on in distributed co puting such as reliabilit", securit", correlation, routing, and essage e.change patterns such as re!uest'response, one-wa", and peer-to-peer conversations. +eaders ust be aware that this is an abstract concept with the indication that there is so e processing needs to be done in the 3*-P nodes but it does not specif" how this processing is done. - 3*-P feature has the following characteristics( 1. - uni!ue na e used to identif" the feature and its properties. This enables us to identif" whether a 3*-P node supports a specific feature. ?or e.a ple, if we have a feature called )secure-ssl-channel,) then we can ask the 3*-P nodes, including the ulti ate receiver, whether the" support that feature or not. $. - set of properties associated with a feature that can be used to control, constrain, or identif" a feature. ?or e.a ple, we can see in the 3*-P re!uestQ response essage e.change pattern there are properties for accessing the inbound or outbound essages, the i ediate sender, and ne.t destination. #t is i portant to understand that 3*-P provides two these features( echanis s for i ple enting

1. 3*-P header blocks. #n this kind of i ple entation 3*-P header blocks are used to specif" a feature. These headers are processed b" the 3*-P nodes. -s we have seen, the 3*-P processing odel defines the behaviors of a single processing 3*-P node in order to process an individual essage. The ost co on e.a ple of such a feature is the securit" features as defined b" /33ecurit" specifications. $. 3*-P binding protocol. #n this case the features are directl" i ple ented in the protocol binding level. ?or e.a ple, a binding e.tension to support the 3*-P over 338 protocol. -s we have noted, in the first case it is ore protocol independent and fle.ible, but this a" cause unnecessar" processing overhead. The second case is protocol dependent and the fle.ibilit" is li ited. #n addition to the e.tensions as specified in the above cases, the 3*-P specification defined a standard feature for the essage e.change pattern called 1BP. 8et us now e.plore in further detail e.actl" how this is defined. 3essage '+#hange Pattern *ne special t"pe of 3*-P feature is the 1BP. - 3*-P 1BP is a te plate that establishes a pattern for the e.change of essages between 3*-P nodes. 3o e e.a ples of 1BPs include re!uest'response, one-wa", peer-to-peer conversation, and so on. To clarif" further, we could consider a special 1BP, a re!uest for proposal 6+?P7 1BP, where we could define a essage e.change pattern for the +?P such as sub itting a re!uest to the service provider, getting a response fro the provider at a

later period, and other subpatterns. /e can envision building these kinds of e.change patterns.

essage

1BP, si ilar to other features, is i ple ented either as headers or using protocol bindings. - 1BP a" be supported b" one or ore underl"ing protocol binding instances either directl" or indirectl" with support fro the software. This software i ple ents the re!uired processing to support the 3*-P feature, e.pressed as a 3*-P odule. 0."P 3odules The co bined s"nta. and se antics of a set of 3*-P headers are known as a 3*-P odule. - 3*-P odule realizes one or ore 3*-P features. This enables us to specif" a ore general-purpose concept such as a secure purchase order, with a co bination of one or ore features, including the purchase order 1BP as described above, the securit" feature, and ore. 3o far we have discussed essage packaging, trans ission, and processing in a transport in a rather independent anner. These 3*-P essages can be transported through different transport bindings, such as 2TTP, TCP, and 4BBP. The 3*-P defined so e protocol bindings for its transport ethods. The ost notable one is 3*-P over 2TTP utilizing the GBT and P*3T operations.

0ervi#e 3essage )es#ription 3e#hanisms

- service description 6?igure 5.<7 is a set of docu ents that collectivel" describe the interface to a service 6i.e., service e.pectations and functionalities7. #n addition to the interface definition, and as it i plies in the na e, it ust describe the se antics of a service, such as the relationship between operations on a service, the eaning of an interface, and'or the basic behavior of an operation.

Figure 0.;. %ervice descri tion for ?eb services.

- service ust be cohesive, and it ust provide service descriptions with the details on its utilization s"nta. and se antics. Aor all" speaking, these service descriptions are intended for progra atic processing rather than hu an processing. - sa ple service description and its usage is shown in ?igure 5.<, where a search engine service is e.posing so e of its capabilities to the e.ternal world so that its clients can understand the s"nta. and se antics of that service, and interact with the service. This service a" then interact with other services using the description provided b" those services, such as other search engines or news services. This description can be e.pressed in an" available description languages, such as /eb 3ervice 5escription 8anguage 6/3587, 5"na ic -gent 1arkup 8anguage 65-18I1;J7, or +esource 5escription ?ra ework 6+5?7. 2owever, we should note that this description can be e.pressed in a co bination of languages. *ne such e.a ple co bination a" be using /358 for service s"nta. description while using +5? for service se antic description in association with /358. ?igure 5.= shows how this can be e.pressed for the above search service.

Figure 0.A. %am le service descri tion #ith semantic information.

8et us now e.plore /358 to understand the basic constructs provided to describe a /eb service. We* 0ervi#e )es#ription /anguage 4W0)/5 This discussion is based on the /358 1.1 specification.I1<J /e will cover so e core concepts of /358 1.$, which is a work activit" in the /%C.I1=J 3o e of the /358 1.$ constructs are of i portance to the grid services co unit".

Buick 9vervie# of ?%D, 1.1

/358 is an 918 #nfoset-based docu ent, which provides a odel and 918 for at for describing /eb services. This enables services to be described, and enables the client to consu e these services in a standard wa" without knowing uch on the lower level protocol e.change binding including 3*-P and 2TTP. This high-level abstraction on the service li its hu an interaction and enables the auto atic generation of pro.ies for /eb services, and these pro.ies can be static or d"na ic. /358 allows the description of both docu ent-oriented and +PC-oriented essages. -s shown in ?igure 5.1>, a /358 docu ent can be divided into abstract definitions and agreed-upon definitions. The abstract section defines the 3*-P essages in a platfor -independent language and a neutral anner. The abstract definitions help to e.tend service definitions and enhance the reusabilit" where the agreed-upon definition enables ultiple protocol bindings such as 2TTP and 31TP and end points of choice 6e.g., service end points7. The abstract service definition co ponents are T"pes, 1essages, *perations, PortT"pe, and 4inding. -greed-upon definition co ponents are 3ervice, Port, and 4inding. These agreed-upon definitions specif" the wire essage serialization, transport selection, and other protocol i ple entation aspects. The /358 binding ele ents are used to specif" the agreed-upon gra ar for input, output, and fault essages. There are specific binding e.tensions defined b" /358 for 3*-P and 2TTP.

Figure 0.1C. The ?%D, 1.1 abstract and agreed-u on com onents.

There can be two kinds of essage encodingF that is, literal encoding and 3*-P encoding. 8iteral encoding specifies that the essages will be constructed according to the 918 sche a )literal,) and 3*-P encoding occurs according to the 3*-Pencoding rules )encoded,) defined in the 3*-P specification. The other i portant concepts in /358 are the essage transfer for atF essages can be transferred as )docu ent) or )rpc) para eters. 5ocu ent eans that the essage part is the bod" of the essage, while +PC eans that the parts are ,ust para eters of the call, with specific signatures that are wrapped in an ele ent. These transfer for ats confir to the 3*-P se antic of the 3*-P essage e.change. There has been a nu ber of li itations with this odel including service se antic clarifications, e.tension echanis s, and the support for new constructs in the 3*-P 1.$ specification. /358 1.$ is tr"ing to resolve these proble s.

Buick 9vervie# of ?%D, 1.2

3o e of the a,or changes are introduced to align the /358 1.1 specification with the 3*-P 1.$ specification, and the overall service-oriented architecture standards such as /eb architecture and /eb service architecture.

*ne of the a,or se antic clarifications we can discuss is regarding the concept of the service. 8et us e.plore the se antic details of this concept. /e will start with the concept of a resource. - resource is an"thing that can be addressable b" a @+#. These resources can be software applications, hardware abstractions, or /eb resources 6e.g., 2T18 pages or for s7. Bver" resource can be logicall" represented b" a set of interfaces, such as anageabilit" interfaces, operational interfaces, and other such interfaces. - service is then treated as a realization of a single interface of a resource. This is represented in ?igure 5.11.

Figure 0.11. The ?%D, 1.2 abstract and agreed-u on com onents.

Aote that a service can have an" nu ber of end points and bindings. 4ut ever" service is a representation of a single interface. This interface a" be a co bination of ultiple interfaces through derivation. /e discuss the details of the interface inheritance toward the end of this section on /358 1.$. This view is different fro the /358 1.10s view, where a single service can be bound to ultiple interfaces through bindings. This causes confusion on the se antic of a service. #t is a fact that in /358 1.1, it is difficult to e.press service se antics through the description language. - binding a" select to i ple ent an" interfaces

of choice. This confusion is later clarified in /358 1.$ b" having a service as a representation of a single interface of a resource. - service a" then have ultiple end points with different addresses and bindings, however, alwa"s bound to the sa e resource using the sa e interface. There is another construct introduced to clarif" the resource that a service is i ple enting. This is done using a new construct called )target+esource.) This )target+esource) is an attribute of a service ele ent, with a @+# value representing the resource @+#. 4ased on the above discussion, a service ele ent is defined in 8isting 5.$(

,isting 0.2. ' service element definition in ?%D, 1.2.

<"e#initions> ..................................................................... <serviname="xs:)*)ame" inter#a%e="xs:+)ame" target,eso-r%e="xs:an(.,/"? > <en" point />0 </servi%e> </"e#initions>

/e can see the /358 1.$ description infor ation ele ents in the following illustration. The concept of )+esource) is logical. -s shown in ?igure 5.11, the service developers have to define the abstract concepts of a service and attach a service to the target resource and the corresponding interface. The binding selection ust then be a runti e activit". #n addition to the clarification on the se antic of a service, /358 1.$ has introduced the concept of features, properties, and so on. These concepts are in line with the 3*-P 1.$ counterparts and can be e.tended to other protocols of choice. 4" defining features and properties in /358, a reader 6i.e., software agents or hu ans7 can identif" the following characteristics( 1. 3o e re!uire ents on the interface'operations for its successful e.ecution. ?or e.a ple, so e operations need to provide a /3-3ecurit" assertion of t"pe 918 signature. $. 3o e indications on the availabilit" of so e feature so that we can rel" on the . ?or e.a ple, a service can state that a feature called )privac" polic") is available for verification. %. General infor ation on the values of the features and its properties.

These features a" oftenti es appear at the interface level or at the binding level. #n addition to these e.tensions for features and odules, there are so e a,or changes that have been introduced, as described below. 1. *peration overloading is re oved fro /358. Aote that /358 1.1 supports the operation overloading facilities. Thus, we have to take care when designing /358, especiall" with interface inheritance. $. -s we have noticed, the )PortT"pe) construct in /358 1.1 is now changed to )interface) to align with the e.isting distributed technologies and #58. This interface supports the inheritance capabilit". #t is worth" to note that this e.tensibilit" of interfaces is one of the core concepts in the grid service specification. 8isting 5.% shows a sa ple interface hierarch".

,isting 0.3. ' sam le interface hierarchy rovided in ?%D, 1.2.

<1e#initions ..............> ..................................................... <inter#a%e name="2"> <operation name="a"""> </operation> </inter#a%e>

<inter#a%e name="$" exten"s="2"> <operation name="s-3tra%t"> </operation> </inter#a%e> ..................................................... </"e#initions>

/e will see the details on this interface hierarch" and its usage pattern in the ne.t chapter during our discussion on Grid Co puting.

The )ports) construct in /358 1.1 has changed to )end points) in /358 1.$. -nother feature that is valuable is the ) echanis s) to include other sche a languages to describe the t"pes of the essage. 1ost notable works in this area are inclusion of 5T5 and +B8-9-AG. - nu ber of 1BPs has been defined to support co ple. essage e.change scenarios, such as re!uestQresponse, input, and output. /358 1.$ defined these 1BPs as well-defined features with specific properties.

The Glo*al ;3/ "r#hite#ture %ision /e have discussed earlier in this chapter that /eb services are tr"ing to unif" software integration a ong partners, through advanced networking services and ethods of interoperable essaging. These interoperabilit" and integration points can be achieved onl" through the definition of interoperable essages, e.change patterns, and processes. The #41 Corporation, 1icrosoft, and a nu ber of other vendors are working on a Global 918 -rchitecture 6G9-7, which provides a odular, 918-based, open standards-based, and federated 918 /eb services suite. These are infrastructurelevel protocols for building /eb service applications. These protocols include standards for securit", reliabilit", addressing, transactions, and ultipart" agree ents. The vision behind such an 918 architecture includes( 1. Providing standards-based and interoperable protocol definitions $. +educing develop ent efforts b" separating infrastructure protocols fro application and transport protocols %. Providing open standards-based designs for interoperable ultiple vendors essaging across

4ased on ?igure 5.1$, we can further e.plore the basic principle of G9-.

Figure 0.12. The "D' and de endencies.

The D(, Data (odel

The core of /eb services is the 918 data odel or the 918 infor ation set. This is defined b" the /%C and for s the core of all 918 specifications including 3*-P and /358. This co on base allows creation of adaptable tools and 918 processors.

(odularity
#n an earlier section, we have discussed that 3*-P provides an enveloping and processing echanis , respective to the essages being e.changed. The ost co on proble found with the e.isting protocols is the lack of the interoperable wire for at. 3*-P is tr"ing to adopt a transport-independent wire for at for 918 essages. This is based on the 3*-P encoding for at as specified b" the 3*-P specification, or using 918 sche a as the wire for at. The 918 sche a encoded essages are reco ended and often called )docu ent'literal) essages. 3ince 918 sche a is an industr" standard, and based on infoset, the interoperabilit" is essentiall" guaranteed. The G9- architecture is building on top of 3*-P. The G9- protocols 6for the ost part7 are 3*-P e.tensions based on 3*-P headers or features. The architecture akes use of the knowledge of 3*-P inter ediaries and supports 3*-P actors 6e.g., )role) in 3*-P 1.$7.

Decentralization and Federation

-n observation we could ake at this stage is that there e.ists the concept of constraint agree ent between the parties involved in /eb service integration. This agree ent is on the s"nta. and se antics of the essages being e.changed. The" a" disagree on the software accepting the essage, progra ing languages used to build the s"ste , operating s"ste utilized, and the database s"ste utilized. The G9- accepted the concept of decentralization, allowing the parties involved to ake their own decision on all parts of essage processing including( securit", policies re!uire ents, and processing. Therefore, this concept of )federation) still allows these parties to e.change infor ation in eaningful for ats. ?or e.a ple, a part" can e.change a essage with another part", even though both disagree on the securit" i ple entation echanis s.

'

lication and Trans ort 5eutral

3*-P and hence G9- does not dictate on the transport echanis for essage e.change. This is a binding-level decision done b" the agree ent between the service and the re!uester. This binding agree ent is independent of the essage being e.changed. The application neutralit" co es fro the fact that it is not defining an" specific essage e.change protocol but instead defining standards-based 918 essages that needed to be e.changed.

9 en %tandards +nitiatives
Toda", an" of the specifications and standard protocol definitions are being sub itted to various standards organizations, including *-3#3 and /%C. This standardization process will help to further refine these specifications and their adoptabilit" across various heterogeneous application and protocol stacks. These standards organizations, together with the /eb 3ervice #nteroperabilit" *rganization 6/3-#7, can provide the desired infrastructure standards the industries re!uire to continue de onstrating progress in this area of Grid Co puting and /eb services.

The

a,or building blocks identified b" the G9- includes facilities for( essages

1. 1essage-level securit" $. B.changing transaction-aware

%. 1essage e.change coordination a ong participants &. +eliable essage e.change patterns

5. 1essage routing and referral processes :. -ddressing ;. 3ervice and echanis s to dispatch essages to the intended part" essage handling essages

essage policies for proper

<. -ttach ents to foreign bodies that won0t fit with regular 918 =. 1etadata infor ation e.change

3ince these co ponents are leading the wa" to beco ing the core technolog" building blocks and interoperabilit" solutions, we ne.t e.plore the ost co onl" used co ponents and its internal design details. #n this ne.t discussion, we e.plore policies, securit", and addressing. 0ervi#e Poli#( The /eb service polic" fra ework provides a general-purpose odel and the corresponding s"nta. to describe and co unicate the respective policies of a /eb service. #t is i portant to understand that this polic" fra ework does not provide a negotiation fra ework for /eb services. /e have to use these polic" building blocks in con,unction with other /eb service standards and specific application-level polic" negotiation services. 4asicall", /3-Polic" enables a odel and fra ework to e.press polic" assertions about a /eb service. These assertions are e.tensible gra ar for e.pressing capabilities, re!uire ents, and the general characteristics of a service. Aote that so e of these assertions a" anifest into wire essages 6e.g., securit" credentials7, while so e others are ,ust infor ation and checkpoints for service users 6e.g., privac" polic"7. This polic"

odel and fra ework defines the following co ponents(

Polic" e.pression. -n 918 #nfoset representation of one or ore polic" assertions. Polic" sub,ect. -n entit" 6e.g., an end point, ob,ect, or resource7 to which a polic" can be bound.

Polic" assertion. -n individual preference, re!uire ent, capabilit", or other propert" 6e.g., securit", privac", and so on7. Polic" attach ent. The echanis for associating polic" with one or sub,ects is referred to as a polic" attach ent. ore

The following discussion will introduce us to the above co ponents of this polic" odel. 8isting 5.& shows a sa ple polic" e.pression, with two polic" state ents containing the na es )G-) and )G4,) respectivel". #t is i portant to pa" close attention to the 918 ele ents defined in this listing. /e will also reuse this listing as a reference for the following discussion on the polic" language features.

,isting 0.!. ' sam le olicy e2 ression.

<wsp:4oli%( xmlns:wsp="..." xmlns:ws-="..." xmlns:x="..." xml:3ase="http://www.a%me.%om/poli%ies" ws-:/"="2" )ame="+2" 5arget)amespa%e="http://www.a%me.%om/poli%ies"> <wsse:6e%-rit(5o&en> <wsse:5o&en5(pe>wsse:7er3erosv5585</wsse:5o&en5(pe> </wsse:6e%-rit(5o&en>

<wsse:/ntegrit(> <wsse:2lgorithm 5(pe="wsse:2lg6ignat-re" .,/="http://www.w3.org/2000/09/xmlen%:aes" /> </wsse:/ntegrit(> </wsp:4oli%(>

<wsp:4oli%( xmlns:wsp="..." xmlns:ws-="..." xmlns:x="..." xml:3ase="http://www.a%me.%om/poli%ies" ws-:/"="$" )ame="+$" wsp:4re#eren%e ="1" 5arget)amespa%e="http://www.a%me.%om/poli%ies"> <x:Expe"ite"1eliver( wsp:.sage="wsp:,e'-ire"" />

</wsp:4oli%(>

Poli#( '+pressions and "ssertions - polic" e.pression is a echanis to conve" a set of polic" assertions 6e.g., securit", privac", and other polic"-related ite s7. #n the above listing we are specif"ing a securit" polic" assertion. - polic" e.pression is an 918 #nfoset with a co bination of a top level Owsp(polic"P container ele ent, the polic" operators 6Owsp(allP, Owsp(B.actl"*neP, Owsp(*neor1oreP, and Owsp(Polic"P7, and so e attributes 6wsu(#d, Aa e, wsp(Preference, and so on7 to distinguish the polic" usage. The attributes Aa e and #5 are used to uni!uel" identif" the polic" e.pression. This e.pression contains zero or ore do ain-specific assertions. These assertions can be standard defined 6/3-3ecurit" assertions7 and'or service provider defined 6as shown in 8isting 5.&7. #t is i portant to understand that the evaluations of these e.pressions are application-specific behavior for a given sub,ect. /e will e.plore later, in the polic" attach ent section, e.planations on e.actl" how we can associate a polic" sub,ect with a polic" e.pression. #n the previous listing, the polic" e.pression )G-) contains two assertions( )wsse(3ecurit"Token) and )wsse(#ntegrit".) -s described in the previous listing, there are two polic" e.pressions with a default operation of Owsp(allP. This indicates that with all the polic" assertions e.pressed, there is a present need to be satisfied. This eans that for the first polic" e.pression )G-,) both the assertions )wsse(3ecurit"Token) and )wsse(#ntegrit") ust be satisfied.

' (echanism for 7olicy -2 ression 'ttachment

There are two echanis s b" which we can attach a polic" e.pression with one or ore sub,ects or resources. ?irst is the 918-based resources to attach polic" e.pressions as part of the definition. This can be done b" the definition of two global 918 sche a attributes, as shown in 8isting 5.5.

,isting 0.0. ' global schema attribute to define olicy e2 ression references.
<xs:s%hema> <xs:attri3-te name="4oli%(.,/s" t(pe="wsp:t4oli%(.,/s" /> <xs:attri3-te name="4oli%(,e#s" t(pe="wsp:t4oli%(,e#s" /> </xs:s%hema>

/e can use the above-defined attributes to attach the polic" references with a resource 918 definition, as shown in 8isting 5.:.

,isting 0.1. 'n instance of a resource #ith the olicy e2 ression references.
<;(Element xmlns:wsp="http://s%hemas.xmlsoap.org/ws/2002/12/poli%(" wsp:4oli%(.,/s="http://www.a%me.%om/poli%ies:2 http://www.a%me.%om/poli%ies:$" />

This shows how to attach polic" e.pressions to resources independentl" fro their definition. #n the above case we know the 918 resource ele ent and can change its representation. 2owever, this a" not be possible in all cases. #n such cases, we need to define the polic" attach ent and appl" that to the sub,ect or resource of interest. 8isting 5.; shows how we can do this using the wsp(Polic"-ttach ent ele ent.

,isting 0.4. 7olicy attachment.

<wsp:4oli%(2tta%hment> <wsp:2pplies5o> <wsa:En" point,e#eren%e > <<=%an 3e an( reso-r%e/servi%e </wsa:En" point,e#eren%e> </wsp:2pplies5o> <wsp:4oli%(,e#eren%e .,/="http://www.a%me.%om/m( poli%(.xml" /> </wsp:4oli%(2tta%hment> >

8isting 5.; shows how we can attach a polic" reference 918 file 6 "-polic".. l7, which contains the polic" e.pressions to an" resource identifiable through /3-ddress specification Bnd-point+eference. The developer will discover this is a ore fle.ible approach. #nterested readers could discover how these polic" e.pressions are attached to /358 and @55# definition ele ents in /3-Polic"-ttach ent.I$>J -lso, there is so e work underwa" to standardize so e of the co on sets of assertions 6/3-Polic"-ssertions7. I$1J 0e#urit( 1ost of the e.isting securit" is dealing with point-to-point securit" solutions. This point-to-point securit" can be achieved b" different wa"s, including 338'T83 and #P3ec as e.a ples. ?igure 5.1% shows point-to-point securit" establish ent.

Figure 0.13. 7oint-to- oint security establishment.

-s shown in ?igure 5.1&, /eb services securit" involves achieving end-to-end essage securit" between the initial sender of the essage to the final receiver of the essage. These essages a" go through an" inter ediaries on the wa".

Figure 0.1!. -nd-to-end security.

This essage securit" is a co bination of different levels of securit" re!uire ents including end-point authentication and authorization, essage integrit", essage confidentialit", privac", trust, and federation a ong collaborators. #n general, to achieve the end-to-end securit", the following points acco odated(

ust be

- /eb service end point can ask the re!uester to sub it the necessar" clai s. - re!uester can send the essage along with proof of the clai , which is nor all" called )securit" tokens) such as userna e'password, Eerberos tickets, and 95>= certificates. #f the re!uester does not have the re!uired clai s, the re!uestor can obtain the clai s fro so e other trusted agenc" and pass these clai s along with the essage. These trusted authorities are called )securit" token services.)

/e know that achieving the above level of securit" is a challenge. The G9architecture tries to address the previous proble of securit" with a set of interoperable and industr"-accepted standards. The following diagra shows the core securit" standards identified b" G9- in order to achieve the re!uired end-to-end securit". *ur discussions will be focused on /3-3ecurit",I$$J which for s the base securit" standard as illustrated in ?igure 5.15.

Figure 0.10. ?%-%ecurity stack #ith the highlighted bo2es indicating the available standards.

There are a nu ber of distributed technologies that e.ist toda", including Eerberos, public ke", and others. The widespread acceptance of these technologies helps the creators of the /3-3ecurit" specifications decide how to use the effectivel" in the /eb services environ ent, instead of creating new securit" technologies. This decision paved the wa" for creating 918 standards that uses e.isting technologies and future ones. /ith these re!uire ents in ind, the /3-3ecurit" standard defines a 3*-P header with a nu ber of securit" assertions and etainfor ation. This provides !ualit" of protection through essage integrit" and essage confidentialit". #n general, the base /3-3ecurit" specification addresses

3ecurit" credential e.change 3ignatures Bncr"ption

?irst, we will e.plore a basic 3*-P header annotated with /3-3ecurit" infor ation. Then, we will use this sa ple /3-3ecurit" header, as shown in 8isting 5.<, to e.plain the previous add-on securit" constructs.

,isting 0.;. ?%-%ecurity header in %9'7 message.

<?xml version="1.0" en%o"ing="-t# >"?> <s:Envelope xmlns:s="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://s%hemas.xmlsoap.org/ws/2002/12/se%ext"> <s:!ea"er> <wsse:6e%-rit(> ??? </wsse:6e%-rit(> </s:!ea"er>

<s:$o"(> ??? </s:$o"(> </s:Envelope>

-s we can infer fro the sa ple skeleton, /3-3ecurit" defined its own na espace and a 3*-P header with O3ecurit"P as its root ele ent. /e have previousl" entioned that /3-3ecurit" addresses essage integrit", which allows a receiver to be sure that the data is not ta pered with in an" wa", and the essage confidentialit" and integrit" is aintained. This ensures that the data cannot be co pro ised while in transit. /3-3ecurit" allows us to send securit" tokens, such as user na e'password co binations, Eerberos tickets, or an 9.5>= certificate. /e will e.plore each of these in the following sections.

Message Integrit* is a $ractice to %nsure Integrit*

1essage integrit" allows a receiver to be sure that the data is not ta pered with on the wa" to and fro its origin'destination. This is nor all" achieved using digital signatures created using public ke" technologies. 918 signature allows public ke" echanis s. #n addition, it also allows the concept of encr"pting the essage digest using a s" etric ke" 6known to both parties7. - essage digest is a checksu on the essage content created using different algorith s such as 155. 1essage confidentialit" eans that onl" the intended receiver6s7 can decode the received essage. *thers on the wa" cannot decode the infor ation in the essage. This confidentialit" of the essage e.change can be achieved using encr"ption echanis s.

-2changing the %ecurity $redential +nformation

?or proper authentication of the sender and receiver to occur, there needs to be an e.change of tokens showing their identit". This enables the parties to verif" with who the" are e.changing infor ation. There are a nu ber of securit" tokens available, including Eerberos, signatures, and user na e'password. /3-3ecurit" provides a standard echanis for e.changing an" of these credentials, along with the essages. #t is i portant to understand that /3-3ecurit" does not address the application'service authentication process, which is an application'service run-ti e specific issue. /hile it is legal to e.change an" kind of token with /3-3ecurit", it specifies two possible kinds of tokens, su arized below.

@serna eToken. 8isting 5.= presents an e.a ple of how we can pass a userna e and password with a /3-3ecurit" header.

,isting 0.A. 7assing username token #ith ?%-%ecurity.

<wsse:6e%-rit( xmlns:wsse="http://s%hemas.xmlsoap.org/ws/2002/12/se%ext"> <wsse:.sername5o&en> <wsse:.sername>3o3</wsse:.sername> <wsse:4asswor">x@AB>r</wsse:4asswor"> </wsse:.sername5o&en> </wsse:6e%-rit(>

This is a ver" si ple process of securit" anage ent but a" get co pro ised on the network transfer. #n ost situations these tokens are passed in an encr"pted transport network connection si ilar to 3ecure 3ocket 8a"er 63387. 4inar"3ecurit"Token. 4inar" tokens send tokens encoded as binar" strea s. These binar" encoding sche es a" be of different t"pes, such as 4ase:& encoding. 8et us e.plore how we can use this echanis to send Eerberos tickets and 9.5>= digital signatures. These essage for ats are specified b" the /3-3ecurit" specifications.

<erberos Tokens
8isting 5.1> provides an e.a ple of how the 4inar"3ecurit"Token can be utilized to send a Eerberos ticket.

,isting 0.1C. 7assing binary tokens #ith ?%-%ecurityE<erberos.

<wsse:6e%-rit( xmlns:wsse="http://s%hemas.xmlsoap.org/ws/2002/12/se%ext"> <wsse:$inar(6e%-rit(5o&en Cal-e5(pe="wsse:7er3erosv565" En%o"ing5(pe="wsse:$aseD@$inar("> EsE".tt... </wsse:$inar(6e%-rit(5o&en> </wsse:6e%-rit(>

The above listing shows a Eerberos ticket securit" token e bedded with the O4inar"3ecurit"TokenP ele ent. -s we can see fro this e.a ple, this is not

uch

different fro the previousl" entioned userna e token. This ele ent KalueT"pe attribute indicates that this is a Eerberos Kersion 5 service ticket, which 6in this e.a ple7 is utilized to authenticate this client to a particular service.

D0CA $ertificates
8isting 5.11 provides an e.a ple of how the 4inar"3ecurit"Token can be utilized to send an 95>= certificate.

,isting 0.11. 7assing binary tokens #ith ?%-%ecurityED0CA certificate.

<wsse:6e%-rit( xmlns:wsse="http://s%hemas.xmlsoap.org/ws/2002/12/se%ext"> <wsse:$inar(6e%-rit(5o&en Cal-e5(pe="wsse:F509v3" En%o"ing5(pe="wsse:$aseD@$inar("> F"#5r ... </wsse:$inar(6e%-rit(5o&en> </wsse:6e%-rit(>

The above listing illustrates how to e bed an 95>= certificate within the O4inar"3ecurit"TokenP ele ent. This ele ent KalueT"pe attribute indicates that this is an 95>= Kersion % certificate, which is used to authenticate this client to a particular service. 8et us now e.plore a discussion regarding how to achieve /3-3ecurit" echanis . "ttaining 3essage Integrit( To aintain the integrit" of the 3*-P essage, it is re!uired to digitall" sign the 918 docu ent. The 918 3ignatureI$%J echanis provides a standard to digitall" sign 918 docu ents 6or a frag ent of7 the 918 docu ent. /3-3ecurit" utilizes this capabilit" of 918 3ignature to aintain its essage integrit". 8et us discover how 918 3ignature works, and how /3-3ecurit" utilizes this feature to protect essages. 918 3ignature defines a signature ele ent whose contents include the digital signature and the infor ation related to that specific signature. Aor all" speaking, the O3ignatureP ele ent used with 3*-P contains the O3igned#nfoP, O 3ignatureKalueP, and OEe"#nfoP ele ents. essage integrit" using the

,isting 0.12. /sing ?%-%ecurity and D(, Digital %ignature to rotect the message integrity.

<s:Envelope ............ <s:!ea"er> <wsse:6e%-rit(> <wsse:$inar(6e%-rit(5o&en Cal-e5(pe="wsse:F509v3" En%o"ing5(pe="wsse:$aseD@$inar(" ws-:/"="F509*ert"> F"#5r... </wsse:$inar(6e%-rit(5o&en>

<"s:6ignat-re xmlns:"s="http://www.w3.org/2000/09/xml"sig:"> <"s:6igne"/n#o> <"s:*anoni%aliGation;etho" 2lgorithm="http://www.w3.org/2001/10/xml ex% %1@)"/> <"s:6ignat-re;etho" 2lgorithm="http://www.w3.org/2000/09/xml"sig:rsa sha1"/> <"s:,e#eren%e .,/=":;essage$o"(1"> <"s:1igest;etho" 2lgorithm= "http://www.w3.org/2000/09/xml"sig:sha1"/> <"s:1igestCal-e> i.trDo-... </"s:1igestCal-e> </"s:,e#eren%e> </"s:6igne"/n#o> <"s:6ignat-reCal-e> 61,5B3!H... </"s:6ignat-reCal-e> <"s:7e(/n#o> <wsse:6e%-rit(5o&en,e#eren%e> <wsse:,e#eren%e .,/=":F509*ert"/> </wsse:6e%-rit(5o&en,e#eren%e> </"s:7e(/n#o>

</"s:6ignat-re> </wsse:6e%-rit(> </s:!ea"er> <s:$o"( ws-:/"=";essage$o"(1"> ??? </s:$o"(> </s:Envelope>

8isting 5.1$ shows a sa ple 918 digital signature utilized with the /3-3ecurit" 3*-P header in order to protect the integrit" of the 3*-P bod" identified b" )1essage4od"1.) Considering the above listing sa ple, we can list the core ele ents of 918 3ignature and discover how well it fits with /3-3ecurit" and the overall 3*-P essage. -s shown in 8isting 5.1$, OCanonicalization1ethodP identifies the 918 canonicalization algorith .

Canonical 8M9
The rules for 918 authoring are fle.ible so that the sa e docu ent structure and the sa e piece of infor ation can be represented b" different 918 docu ents, and even 918 sche a or 5T5 can be validated fro the . ?or e.a ple, the following two 918 docu ents are se anticall" e!ual. 2owever, the" contain the attributes in a different order. -nother ite that can be noted in these docu ents is that the second listing contains ore white space.
<?xml version="1.0" ?> <a""ress t(pe=".6"> <Gip%o"e val-e="123@5" </ a""ress > t(pe="-s Gip"/>

<?xml version="1.0" ?> <a""ress t(pe=".6">

<Gip%o"e

t(pe="-s Gip" val-e="123@5"/>

</ a""ress >

This is a a,or proble with 918, as it is a te.t-based docu ent and the treat ent of each character a" have a significant effect on the bit-b"-bit validit" of the docu ent even though the docu ent a" be se anticall" e!ual. This causes proble s especiall" when dealing with essage integrit". The 918 canonicalization algorith is used to convert the 918 docu ent to a standards for at, bit b" bit, to avoid proble s b" ensuring the docu ent will be identifiable as the sa e docu ent, bit b" bit, b" ever"one.

#n the previousl" illustrated e.a ple of code, "ou will note we are using the algorith identified as )http(''www.w%.org'$>>1'1>'. l-e.c-c1&A) and defined b" the /%C 918 3ignature working group. The O3ignature1ethodP identifies the algorith used to create the digital signature. These algorith s include the 3ecure 2ash -lgorith 632-7 along with 53- or +3-. #n the above e.a ple code we are using )+3-.) The O+eferenceP identifies the resource to be signed. This reference a" be 3*-P bod" parts identified through essage part ids 6wsu(id7. #n addition, the reference carries the algorith used and the digest value. #n this specific e.a ple we are creating a digest using the 32- algorith and signing the 3*-P bod" identified as )1essage4od"1.) O3ignatureKalueP contains the real signature of the essage.

OEe"#nfoP identifies the ke" that should be used to validate the above signature. This is optional provided that the recipient of the essage knows how to obtain the ke". #n the previous discussion we entioned that a fle.ible and efficient approach to achieve the 918 essage integrit" has so e proble s, especiall" regarding the processing overhead on converting the essages to canonical for at, creating the digest on that for at, and adding signatures using that digest. #n short, the processing re!uired to support 918 3ignatures is highl" process intensive. This can beco e co plicated when we start checking the integrit" of the essage parts with the sa e 6or different7 algorith s. -nother challenging proble is the creation of certificates and the e.change of the a ong the parties of interest. #t is i portant to understand that we ust e.ert the highest degree of care regarding these circu stances, and when we should use the 918 signature. 8et us now e.plore the topic of attaining a essage e.change with confidentialit", especiall" in the conte.t of end-to-end essaging transfers.

6o# to Transfer (essages #ith $onfidentiality

The above discussed essage integrit" echanis will tell us whether the essage is ta pered with on the wa" or notF however, it won0t prevent so eone on the essage path fro peeking into the essage. ?or that we need to encr"pt the 918 essage or frag ents of the essage using so e standard echanis . The 918 encr"ption I$&J standard helps us achieve this level of confidentialit". 8et0s discuss how the 918 encr"ption works and how /3-3ecurit" uses that to protect our private essages. 8isting 5.1% illustrates a sa ple 3*-P essage encr"ption echanis using /33ecurit".

,isting 0.13. 'n encry ted D(, message using ?%-%ecurity.

<s:Envelope xmlns:s="http://s%hemas.xmlsoap.org/soap/envelope/"

xmlns:wsse="http://s%hemas.xmlsoap.org/ws/2002/12/se%ext" xmlns:ws-="http://s%hemas.xmlsoap.org/ws/2002/0B/-tilit(" xmlns:"s="http://www.w3.org/2000/09/xml"sig:" xmlns:xen%="http://www.w3.org/2001/0@/xmlen%:"> <s:!ea"er> <wsse:6e%-rit(> <xen%:En%r(pte"7e(> <xen%:En%r(ption;etho" 2lgorithm="http://www.w3.org/2001/0@/xmlen%:rsa 1I5"/> <"s:7e(/n#o>

<"s:7e()ame> *)=7e(13J *=.6 </"s:7e()ame> </"s:7e(/n#o> <xen%:*ipher1ata> <xen%:*ipherCal-e> -t(#KBs"# . . </xen%:*ipherCal-e> </xen%:*ipher1ata> <xen%:,e#eren%eList> <xen%:1ata,e#eren%e .,/=":En%r(pte"$o"(1"/> </xen%:,e#eren%eList> </xen%:En%r(pte"7e(> </wsse:6e%-rit(> </s:!ea"er> <s:$o"(> <xen%:En%r(pte"1ata ws-:/"="En%r(pte"$o"(1"> <xen%:En%r(ption;etho" 2lgorithm=Mhttp://www.w3.org/2001/0@/xmlen%:triple"es %3%M/> <xen%:*ipher1ata> <xen%:*ipherCal-e> E618K9-nsC . . . </xen%:*ipherCal-e> </xen%:*ipher1ata> </xen%:En%r(pte"1ata> </s:$o"(> </s:Envelope>

/3-3ecurit" utilizes three parts of the 918 encr"ption( OBncr"pted5ataP, OBncr"ptedEe"P, and O+eference8istP. 8et us further e.a ine each of these parts.

OBncr"pted5ataP. -s shown in 8isting 5.1%, this ele ent contains the actual encr"pted data in a subele ent called OCipher5ataP. This ele ent can also contain subele ents that indicate the encr"ption algorith that was used, the ke" that was used in order to perfor the encr"ption. Aor all", the ke"s are again encr"pted and will be added to the header, as shown in O Bncr"ptedEe"P. This is the case we have presented in the above sa ple listing. OBncr"ptedEe"P. 3i ilar to OBncr"pted5ataP and in 8isting 5.1%, it has three subele ents( OBncr"ption1ethodP, OEe"#nfoP, and OCipher5ataP. The ain difference lies in the fact that what is being encr"pted here is a s" etric ke". This header0s OBncr"ption1ethodP describes how this ke" was encr"pted rather than how the actual data was encr"pted. The data is encr"pted using the OBncr"pted5ataP echanis , as we have noted earlier in the te.t. -s defined b" /3-3ecurit", 918 encr"ption can be used in a nu ber of wa"s with 3*-P essages. /e can encr"pt the entire bod", so e bod" parts, and certain header ele ents, or even attach ents sent with the essage. The inter ediaries on the path of the 3*-P essage can add their own encr"pted headers or decr"ption, and process parts intended solel" for the selves. Aow we can define so e of the higher-level securit" standards. /e are not planning to go into detailsF however, we will present their usage and relationship with /33ecurit". 0ome High6/evel G;" 0e#urit( 0tandards The high-level securit" standards associated with G9- are further e.plored in this discussion.

?%-Trust
/e have seen earlier that the re!uester ust possess a secure token to establish a secure essage channel to the /eb service end point. There a" be cases where the re!uestor or the service a" need to re!uest tokens fro other trusted parties, called secure token services. These re!uests for tokens, and the issuance of securit" tokens and trust relationship anage ent aspects, are specified in the /3-Trust specification.I$5J -s shown in ?igure 5.1:, the /3-Trust deals with different aspects of secure token services, including how to re!uest a token and the issuing of tokens in a trusted anner. This issuance of tokens ust be secure and built on top of /3-3ecurit". The secure token services can be a contact point for secure negotiation through delegation and i personation.

Figure 0.11. %ecure Token services and the security token e2change.

?%-%ecure$onversation
This specification defines e.tensions that build on /3-3ecurit" to provide secure co unication. The echanis s provided include provisions for establishing and sharing securit" conte.ts, and deriving session ke"s fro securit" conte.ts 6see ?igure 5.1;7.

Figure 0.14. ' secure conversation using the ?%-%ecure$onversation header.

?%-Federation
/3-?ederation defines echanis s that are used to enable identit", attribute, authentication, and authorization federation across different trust environ ents. Thus far, we have been discussing how to achieve end-to-end securit" in /eb service applications. Aow we will e.plore one of the latest specifications in the G9- related to this, which addresses the end-point identification echanis . The end-point identification is si ple in ost of the cases 6i.e., stateless services7F however, this a" beco e ore co ple. when the end points are stateful instances, or a realization of a co bination of custo properties. /e need to have a deep understanding of this specification since it is going to be utilized in all other specifications to address the end points. "ddressing 4W06"ddressing5

/3--ddressing 6/3-7I$:J provides transport-neutral services and essages.

echanis s to address /eb

This capabilit" is provided b" the specification using two constructs( 1. - fle.ible and e.tendable end-point reference description odel ap the above

$. - set of 3*-P essage headers 63*-P features7 and rules to reference ele ents to the header ele ents

Aor all" speaking, /eb services are invoked b" the /358-provided service endpoint infor ation. ?or e.a ple, /358 service ports have a location address, which identifies the end point. This infor ation is suitable in ost of the cases until we start e.ploring stateful /eb services and'or adding ore d"na ic infor ation to the address 6e.g., instance infor ation, polic" constructs, etc.7. This re!uires a client or runti e s"ste to uni!uel" identif" a service at runti e based on this runti e infor ation. These ele ents of binding specific infor ation on the address a" include a pri ar" ke", uni!ue identifier, and other ke" ele ents. Currentl", there is no standard wa" that this infor ation can be e.changed, and the apping of that e.changed infor ation to the run-ti e engine while accessing the service. #n general, the current /358 1.1 is not suitable for the following situations( 1. 5"na ic generation and custo ization of the service end-point descriptions $. #dentification and description of specific service instances that are created as the result of stateful interactions %. ?le.ible and d"na ic e.change of end-point infor ation The /3--ddressing specification tries to solve the above proble b" providing a lightweight echanis for identif"ing and describing end-point infor ation, and apping that infor ation to the 3*-P essage headers. 8isting 5.1& illustrates how to define a sa ple end-point description using the /3-ddressing specification.

,isting 0.1!. ' sam le ?%-'ddress end- oint identification mechanism.

<wsa:En" point,e#eren%e xmlns:wsa="..." xmlns:a%me="..." xmlns:ogsi="..."> <wsa:2""ress>http://www.a%me.%om/3ase</wsa:2""ress> <wsa:,e#eren%e4roperties> <ogsi:instan%eN#>m(6ervi%e</ogsi: instan%eN# > </wsa:,e#eren%e4roperties> <wsa:4ort5(pe>a%me:2%me6ear%h4ort5(pe</wsa:4ort5(pe>

</wsa:En" point,e#eren%e>

-s shown in the preceding listing, a /3--defined Bnd-point+eference contains a nu ber of subele ents, such as O-ddressP, O+eferencePropertiesP, OPortT"peP, O3erviceAa eP, and /3-Polic". The O-ddressP ele ent is a @+# that identifies the end point. This end point a" be a network address or logical address. /e can infer fro the specification that with the e.ception of the O-ddressP subele ent, all other subele ents are optional. 4ased on the service end point re!uire ents, these ele ents a" appear in the description. -s shown in the above sa ple listing, our -c e service end point needs so e reference properties, which uni!uel" identifies this instance of -c e service. /e can have an" nu ber of reference properties and the usabilit" of these properties is binding and runti e specific. ?or e.a ple, in the above case the *G3# runti e directs the calls to the specific -c e service instance identified b" ) "3ervice.) The PortT"pe is another optional para eter but a" help the client-side binding stubs for validation on the operation, prior to aking the call to the destination. /e can also attach an" nu ber of /3-Polic" e.pressions, along with this end point, to further !ualif" the end point. The above discussion helps to clarif" that /3--ddressing provides uch ore infor ation, and is rather d"na ic in nature, when co pared to the nor al /358 service location address. #n addition to the description language, there needs to be a echanis to bind this infor ation with a 3*-P essage. #n the ne.t section, we will e.a ine the /3-defined essage headers and how the apping is occurring fro an end point to 3*-P headers. 8isting 5.15 illustrates how to add a 3*-P header with /3- constructs and endpoint apping.

,isting 0.10. ?%' #ith %9'7 header.

<6:Envelope xmlns:6="http://www.w3.org/2002/12/soap envelope" xmlns:a%me="..." xmlns:ogsi="..."> <6:!ea"er> ... <wsa:5o> http://www.a%me.%om/3ase</wsa:5o> <ogsi:instan%eN#>123@5DB>9</ogsi: instan%eN# > ... </6:!ea"er> <6:$o"(>

... </6:$o"(> </6:Envelope>

The preceding listing shows how the service end-point description, defined in the previous listing, is actuall" apped into the 3*-P headers. The ost i portant apping is the apping of O-ddressP aps to OToP ele ent, which is a re!uired ele ent. The reference properties are copied as header ele ents. This, in turn, enables the 3*-P processors to handle the .

The %ignificance of ?%-'ddressing in the $onte2t of "rid %ervices

Grid services created using the *G3# standard, which we will cover later in the book in greater detail, faces the sa e proble of instance addressing. Currentl", the grid service instance lookup is handled in two steps. ?irst, the resolution process where it is establishing a handle resolution to convert the grid service uni!ue handle 6G327 to a service reference. This a" result in a d"na ic grid service reference 6G3+7 with the current address of the service instance infor ation e bedded in the 3*-P address location, and in so e cases, in the newl" defined Oinstance*fP /358 ele ent. This d"na ic is an *G3# platfor -specific solution, and the tools have to be built to handle and ap this d"na icall" generated address to the stub. /3--ddressing can avoid this proble when the end-point reference is constructed such that it is rich enough to carr" the specific instance address with its associated properties. These can be directl" apped to 3*-P headers as specified b" the /3- specification. This enables an" client-side fra ework that is capable of working with the stateful service.

2elationship *etween We* 0ervi#e and Grid 0ervi#e

Throughout this chapter, we have been discussing /eb services, and the respective technical underpinnings of /eb services. The basic pre ise of this architecture is the creation of interoperable services and their respective applications. +eaders are b" now aware that Grid Co puting is the process of resource sharing a ong a collection of participants( This involves interoperable access to sharable resources. The architectural evolution of Grid Co puting selects /eb services as the technolog" for defining these interoperable resources. The ain criteria on this selection are the open protocol base and the interoperable essaging solutions, as proposed b" the /eb services architecture. /e have alread" discussed the evolution of grid services and its adaptabilit" to the e erging technologies. #n the ne.t section, we will e.plore the details on how grid services are defined around /eb services architectures, and the standardization process of grid services. Given the previous discussion, we can now spend so e ti e in e.ploring the relation between /eb services and grid services, how we can differentiate each of the , and in what situations the" share si ilarities.

-n application or service a" have the abilit" to aintain a state, and that state a" be pertaining to the user of that application. ?or e.a ple, a purchase order s"ste keeps a user0s order infor ation between the interaction, the user, and the s"ste 6i.e., verif" order, change order, update order, etc.7, until the order is sub itted for deliver". This state infor ation 6i.e., purchase order7 a" be local to the application or the service, or it a" be stored in an e.ternal state achine6s7 such as databases, other resources, local session state, and the resource'service ob,ect. #t is noteworth" to understand how the above state is anaged in /eb service scenarios. Generall" speaking, we can classif" service state anage ent into two for s. These two for s are as follows( 1. #nteraction aware state. Aor all", in the world of the /eb and /eb services, a client a" interact with a service for a long period of ti e, as we have discussed in the above purchase order case. These interactions are correlated using so e infor ation passed fro the client to the service, along with the essage. This can be a si ple cookie, a session #5, or co ple. correlation infor ation. The advantage of this architecture design point is that the server side is not anaging an" specific client state infor ation, or creating a specific instance for a client. The server-side i ple entation is ver" scalable and stateless in nature. #t is not preventing the real state being persisted in a state achine e.ternal to the applicationF instead, this is correlated to a specific client0s state using the session #5. This is, t"picall", how nor al /eb and /eb services are defined. $. -pplication aware state. #n these situations, services are aware of its client and create a specific instance of the service for the specific client, and pass that instance infor ation 6e.g., pri ar" ke"7 back to the client for interaction. -t this stage, the client is holding a reference to the specific instance of the service'application, and hence, can interact with the service instance without passing an" correlation infor ation. These services are t"picall" referred to as stateful services, because the state infor ation is held in the service itself and not passed back to the client. *ne i portant ite to notice about this state anage ent, si ilar to the above case, is that the service need not sustain the stateF rather, the service a" delegate the state to other state achines. The onl" re!uire ent is that the client owns a reference to the service instance. Grid services are stateful /eb services with a well-defined set of interfaces and behaviors for interaction. The following discussion e.plores the above concepts. Intera#tion "ware 0tate In!ormation This discussion addresses the previous introductor" topic, interaction aware state infor ation, which is related to state anage ent. ?igure 5.1< depicts these state achine scenarios we have ,ust introduced, and subse!uent discussions further e.a ine this concept.

Figure 0.1;. +nformation a#are stateless ?eb services.

?igure 5.1< depicts a client talking to a /eb service na ed )-.) #n this scenario, the client is aintaining so e session #5, and each ti e it interacts with the /eb service, it passes that correlation infor ation 6e.g., purchase order ke"7 to the service end point. This enables the runti e function to dispatch the calls to an" /eb service of the t"pe )-.) The service is then able to handle the re!uest for the client, based upon the session #5 passed along with the respective re!uest. This is a ver" scalable approach. "ppli#ation "ware 0tate In!ormation This discussion addresses the previous introductor" topic, application aware state infor ation, which is related to state anage ent. ?igure 5.1= depicts these state achine scenarios we have ,ust introduced, and subse!uent discussions further e.a ine this concept.

Figure 0.1A. ' lication-based stateful ?eb services.

%tateful ?eb %ervices

#n this case, the service itself aintains so e state infor ation for the client. 2ence, each client is provided a specific instance of a /eb service to engage. This is analogous to the ob,ect-based s"ste , whereb" the ob,ect clients create an ob,ect instance of the t"pe of ob,ect class, and then aintains a pointer to that instance, and subse!uentl" interacts with that instance. Bach ob,ect instance aintains its nonstatic state infor ation in its e or" location. 3i ilarl", the /eb service client aintains a reference to an instance of the service, and then co unicates to that specific service instance. The instance holds the state

of the client, and can ake and e.ecute the business decision based on that current state infor ation. ?or e.a ple, the service instances aintaining a purchase order within a given instance.

"rid %ervices
This discussion provides infor ation related to grid services, and the co parisons to stateful /eb services. ?igure 5.$> shows the *G3# interaction with the stateful /eb services achine6s7.

Figure 0.2C. "rid services.

Grid services are, in fact, stateful /eb services. The service itself aintains so e state infor ation, and it e.poses a set of standard interfaces to enable interactions with its client. These e.posed interfaces enable the client to get'set the state infor ation, in addition to the nor al service behaviors. These e.posed interfaces are defined in the *G3# specification. This specification provides echanis s to(

3ervice lifec"cle anage ent #nstance state introspection and discover" #nstance state change event notification

#n addition to the above behaviors, *G3# provides for a uni!ue handle for the stateful /eb service, called the grid service handle 6G327. Generall" speaking, a grid service can be accessed through a grid service reference 6G3+7, which then for s the binding-level infor ation to access a service instance. This interface-enabled access to a stateful /eb service then provides interoperabilit" at the essage level.

We* 0ervi#e Interopera*ilit( and the 2ole o! the W06I .rganization

/e conclude our discussions on e erging /eb services with so e for of introduction to the works initiated b" the /eb 3ervice #nteroperabilit" 6/3-#I$;J7 organization. This i portant organization is an open-standards industr" organization that is responsible for handling the interoperabilit" issues of /eb services b" defining well-

defined profiles for /eb services interoperabilit". These profiles can be treated as best practice guidelines for ost service interoperabilit" concerns. 2owever, these profiles are not necessaril" standards b" the selvesF rather, these profiles are based on the e.isting standards, such as 3*-P, /358, and @55#. The ter )guidelines) a" be a ore appropriate for of understanding. #n addition to these interoperable profile guidelines fro /3-#, the organization provides tools to validate the essages to verif" their confor it" with the defined profiles. -s of toda", this organization defined a basic profileI$<J for an 918 essage e.change, using 3*-P 1.1, /358 1.1, and 918 sche a as the core standards. 3ince this is appearing to aintain its for as the a,or interoperabilit" guideline for /eb service essages, we will spend so e ti e in reviewing these details related to these best practices in order to better understand how the" are defined. Introdu#tion to Basi# Pro!ile Guidelines The current released version of basic profile is version 1.>. The /3-# board alread" accepted this /eb service basic profile 1.> as a candidate reco endation. This basic profile 1.> is built upon the following specifications(

3*-P 1.1, including aterial related to o Aa espaces in 918

o

918 1.> 3econd Bdition aterial related to

/358 1.1, including

o o

918 3che a $>>1 Part 1( 3tructures 918 3che a $>>1 Part $( 5atat"pes

@55# $.> 6which includes support for @55# 1.> interfaces7 3*-P 1essages with -ttach ents, /%C note, 11 5ece ber $>>>

#t is i portant to understand the basic profile version and its base standards, including their respective versions. 4ased upon prior discussion, we are aware that these standards are evolving. The best practice usage odel a", therefore, differ regarding co binations of these standards. The actual scope of the profile is bound b" the standards it depends upon. #t should be further understood that at develop ent and test ti e, one a" need to select a profile that atches the environ ent. 8et us now begin to review ore of the details surrounding this topic. 0ome )etails on the Basi# Pro!ile, with 0amples The basic pre ise of this profile is to ensure that /eb services are able to co unicate. The basic profile does not define an" application se anticsF rather, it ensures that the essages can be e.changed between an" re!uester and the provider.

The re!uire ents are nu bered 6e.g., +$>>17 such that the validation tools and readers can refer to the as appropriate. The basic profile provides interoperabilit" in the following areas.

(essaging
The essaging aspect of /eb service re!uires the the re!uired level of interoperabilit". ost attention in order to achieve

/eb service essages are specified as 918 essages. These 918 essages are packaged into the 3*-P envelope, and then transported through 3*-P nodes to the final end-point destination. These essages a" go through a nu ber of inter ediaries and processors. This co ple.it" re!uires a high level of interoperabilit" a ong all the parties involved. The basic profile defines so e core re!uire ents around this essage e.change pattern, including 918 representation of 3*-P essages, encoding re!uire ents, 3*-P processing odel re!uire ents, 3*-P fault handling se antics, and 3*-P binding over transport protocols. The profile prefers the use of )literal) 6nonencoded7 918 essages rather than )encoded) 918 essages. #f we are using encoding, we ust specif" a soap(encoding3t"le attribute to specif" the re!uired encoding sche es, including an" restrictions such as )encoding3t"le) which ust not be present in Osoap(envelopeP, and in the child ele ents of the Osoap(bod"P. The )soap( ust@nderstand) attribute ust accept onl" a )>) or a )1) value. The afore entioned sa ple validation rule helps us understand the depth and details of the profile. /e will review a real validation using the profile tool later in the book in order to understand the details.

%ervice Descri tion

The profile defines the best usable scenarios for /358 to describe interoperable essages. This section defines a nu ber of correct usage scenarios for /358. This is to be considered an e.tended set of re!uire ents. W0)/ )o#ument 0tru#ture This section covers a wide nu ber of re!uire ents on the possible construction of a /358 docu ent as a whole. This includes docu ent validation, i porting other sche as, encoding, place ent of ele ents, and na espace anage ent. The following e.a ple rules e.plain the correct usage patterns. The +$>>; re!uire ent specifies that the Owsdl(i portP attribute. #t ust not be e pt". ust specif" a location

The above e.a ple relates to the i porting of other 918 sche as fro other locations. The ne.t e.a ple specifies the re!uire ents on the above i port state ent place ent. The +$>$$ re!uire ent defines that the Owsdl(i portP ele ents ust precede all other ele ents fro the /358 na espace, e.cept Owsdl(docu entationP. There are a nu ber of such structure. andator", optional, and re!uired rules on the docu ent

8est 7ractices /sage of ?%D, Ty es, (essages, ortTy es, and 8indings
There are a lot of andator" and optional rules that have been specified in this section related to the areas of /358 portT"pe definitions, essage usage, and essage t"pe construction. The binding area covers the best usage pattern over different bindings, such as 2TTP. -n incorrect e.a ple of a declaration for Owsdl( essageP is shown below(
<message name="8et5ra"e4ri%e/np-t"> <part name="ti%&er6(m3ol" element="xs":string"/> <part name="time" element="xs":time/nstant"/> </message>

or, another for

of the sa e declaration is shown below(

<message name="8et5ra"e4ri%e/np-t"> <part name="ti%&er6(m3ol" element="xs":string"/> </message>

-s entioned, the above Owsdl( essageP usage is incorrect, even though it is valid with reference to /358. 4ased on +$$>:, a wsdl( essage in a Owsdl(descriptionP containing a wsdl(part that uses the ele ent attribute ust refer to a global ele ent declaration. The correct i ple entation of the declaration is shown below(
<t(pes xmlns:test="http://example.org/test/">> <xs":element name="6-3s%ri3e5o+-otes" t(pe="test:6-3s%ri3e5o+-otes5(pe" /> </t(pes>

<message name="8et5ra"e4ri%e/np-t"> <part name="3o"(" element="test:6-3s%ri3e5o+-otes"/> </message>

/358 1.1 has not clearl" specified the child ele ent structure in the case of a docu ent-literal approach. The basic profile avoids confusion b" clearl" andating the re!uire ents on the Osoap(bod"P essage. The child ele ent of Osoap(bod"P ust be an instance of the global ele ent declaration referenced b" the corresponding Owsdl( essageP part. 4ased upon the above declaration of the )3ubscribeToGuotes) essage, the correct 3*-P essage ust be constructed as shown below(
<s:Envelope xmlns:s="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:test=" http://example.org/test/"> <s:!ea"er/> <s:$o"(> <test: 6-3s%ri3e5o+-otes xmlns:test=" http://example.org/test/"> ............... </test: 6-3s%ri3e5o+-otes> </s:$o"(> </s:Envelope>

3i ilar to the above e.a ples, there are about :>Q;> re!uire ents listed in the basic profile to clarif" the /358 description echanis .

/se of D(, %chema

/358 1.1 uses the 918 sche a as one of its t"pe s"ste s. The basic profile andates the use of 918 sche a in accordance with the 918 sche a 1.> reco endation.

%ervice 7ublication and Discovery

The use of registries in /eb service is an optional feature. The ost co on registr" suitable for /eb service publication is @niversal 5escription 5iscover" and #ntegration 6@55#7.I$=J The basic profile lists so e co on rules for this publicationF however, the usage odel is not 6"et7 alwa"s co patible with @55# $.>.

%ecurity
The basic profile incorporates the networking services transport-level securities, such as 2TTP3. The re!uire ent is si ple, in that it re!uires the 3*-P address to specif" an )https) address, rather than nor al )http.) The rest of the processing is a bindinglevel functionalit".

Tools
The tools pla" an i portant role in the basic profile validation. The basic profile re!uire ents are co ple. for a service developer to verif", related to its accurac". The tools should help in each stage of the develop ent effort. The service developer can validate the /358 for interoperabilit" concerns. ?urther ore, runti e efforts should provide for the facilities to introspect the 918 essages, through the wire, for interoperabilit" concerns, and accordingl" advise as to an" situations encountered in this stage. These tools provide so e interesting capabilities(

The" validate the 918 3*-P essage against its corresponding /358 and sche a. The" log the response on validation in a confor ance report for review 6nor all" an 2T18 file7. *n review we can deter ine each of the tests and validation results. #f there is a validation failure or a need for so e e.planation or an" reco endation, the" a" point us to the corresponding basic profile reco endation.

The current specification for tools defines two i portant aspects.

(onitoring %9'7 messages

This allows tools to onitor the 3*-P essages fro a re!uester to a /eb service. These 3*-P essages are redirected to another port through tunneling echanis s. -s we can see, these onitors output the data in for at as needed b" the anal"zer.

'nalyzing %9'7 messages

These tools are responsible for anal"zing the logged essages in con,unction with the service /358, 918 sche a, and @55# profiles. These essages are validated against the test assertion docu ent, and finall" a confor ance report is produced. These t"pes of anal"tical tools provide powerful validation capabilities when properl" co bined with these basic profile reco endations. This overall tools architecture is depicted in ?igure 5.$1.

Figure 0.21. The basic rofile validation tools.

%ecurity 7rofiles and 9ther 'reas to $onsider

#n addition to the basic profile we have ,ust discussed, there are other i portant works underwa" throughout the global technical co unities to define a co on interoperable securit" profile that atches the /3-3ecurit" standards. This work is also intended to define other testing tools to validate secure essage e.change interactions. -nother notable area is the develop ent of sa ple applications and their usage scenarios. /e reco end using /3-#-defined tools to validate the 918 essage for better interoperabilit". #n the co ing "ears, we will ost likel" witness that an" of the e.isting /eb service vendors will be incorporating these tools in their products for the purpose of testing interoperabilit".

Part : The Grid Computing Technological !iewpoints

#n toda"0s world of high technolog" achieve ents, there are none ore i pressive than the global ove ent into Grid Co puting. Grid Co puting acco plish ents can now prove to be able to present a virtual co puting environ ent that appears to be ore powerful, and sustain ore processing power, than the world0s largest co puter. #n Part &, we e.plore the vast nu ber of co ple. technologies that co prise the real of Grid Co puting. /e describe e.actl" how, through specific co binatorial designs, the world is able to leverage these innovative solutions to assist in the resolution of so e of the ost difficult, co putation-intensive proble -solving activities. -lso in this part of the book, full treat ent will be provided to allow the reader to better understand how to achieve )true) distributed resource sharing across heterogeneous and d"na ic )virtual organizations.) Grid Co puting technologies re!uire several i prove ents in align ent with an" of the traditional co puting technologies.

#n the earl" da"s of Grid Co puting, a nu ber of custo iddleware solutions were created to solve the )grid proble ) 6as we defined the so-called )grid proble ) in earlier parts of the book7. 2owever, this resulted in noninteroperable solutions, while at the sa e ti e, integration a ong the participants beca e a challenging e.perience. -s we have also discussed earlier, the third wave of the Grid Co puting era is now focusing on the easier integration, securit", and !ualit" of control aspects of resource sharing. ?oster, Eessel an, Aick, and Tuecke describe the *pen Grid 3ervice -rchitecture 6*G3-7 as a solution to the above proble . This architectural concept is a result of the align ent of e.isting grid standards with the e erging service-oriented architecture as well as the /eb. The /eb service standards define an open standard echanis for service creation, service na ing, and service discover". #t provides an interoperable essage e.change pattern between client and service b" using 918 as the essage for at. The *G3- defines standard essage for ats and essage e.change patterns for Grid Co puting. This standardization of essages and e.change patterns enables interoperabilit" a ong grid services. -lso, this eli inates the need to worr" about the underl"ing operating s"ste where the #T resources are hosted, and'or transport level networking services, and'or protocols used for essage e.change. These are treated as the funda ental runti e binding issues. The *G3- provides a unifor wa" to describe grid services and defines a co on pattern of behavior for all grid services. #n short, this architecture defines grid service behaviors, service description echanis s, and protocol binding infor ation b" using /eb services as the technolog" enabler. The architecture thus developed uses the best features fro both the grid and /eb services co unit". The core technologies that for s the basis of *G3- are(

e9tensible 1arkup 8anguage 69187. This arkup language is used to define the essage e.change for at and structure. /eb 3ervice 5escription 8anguage 6/3587. This is a service description language for /eb servicesF the sa e is used for describing grid services.

The co panion technologies that are of interest for our discussion are(

3i ple *b,ect -ccess Protocol 63*-P7. This is a standard-based essage enveloping echanis . #n addition to this essage for at, it defines a set of standard essage e.change patterns. @niversal 5escription, 5iscover", and #ntegration 6@55#7. - standard and interoperable platfor that enables co panies and applications to !uickl", easil", and d"na icall" find and use /eb services over the #nternet.

+efer to the last chapter for a detailed discussion on these technologies. These core technologies are the basic building blocks for the *pen Grid 3ervice #nfrastructure 6*G3#7 that for s the base la"er of the grid service architecture. #n the opening two chapters we e.plore details of the *G3- and the platfor co ponents including the *G3# specification.

Introdu#tion
The grid infrastructure is ainl" concerned with the creation, anage ent, and the application of d"na ic coordinated resources and services. These d"na ic and coordinated resources and services are co ple.. The" a" be individual or a collection of entities with a short or long lifespan. These resources a" be constituted fro single or fro ultiple institutions so as to provide a ho ogeneous or heterogeneous set of functionalities. Bven though the co ple.it" and difference in resources and services a" var" within ever" virtual organization, the" are all agreed to deliver a set of Go3 features including co on securit" se antics, workflow, resource anage ent, proble deter ination, failover, and service-level anage ent. These Go3 features re!uire a well-defined architecture to achieve the desired level of service !ualit". This pro pted for the introduction of *pen Grid 3ervice -rchitecture 6*G3-7 to support the creation, aintenance, and application of ense bles of services aintained b" virtual organizations 6K*7 6?oster, Eessel an, D Tuecke7.

Clari(ication o( the -sage o( #esource and 'ervice

#n ost of the technolog" papers and specifications, the definition of the ter )resource) and )service) are used interchangeabl" to represent an"thing that is sharable and'or can be used b" an e.ternal user. Bven though this a" look conceptuall" correct for the specific scenarios the" a" be representing, for our discussion we would like to further clarif" the resource and service concepts. - resource is so ething sharable or a representation of a logical or ph"sical entit" 6e.g., software application, hardware, operating s"ste , cluster, etc.7 and has a nu ber of interfaces or application provider interfaces 6-P#7 to ange, access, and onitor the resource. - service is a realization of one of the interfaces with the necessar" binding and essage e.change pattern infor ation for the use of the client. This is represented in ?igure :.1.

Figure 1.1. &elationshi bet#een resource and service.

.G0" "r#hite#ture and Goal

*G3- architecture is a la"ered architecture, as shown in ?igure :.$, with clear separation of the functionalities at each la"er. -s "ou can see fro the figure, the core architecture la"ers are *G3#, which provides the base infrastructure, and *G3- core platfor services, which are a set of standard services including polic", logging, service-level anage ent, and so on. The high-level applications and services use these lower la"er core platfor co ponents and *G3# that beco e part of a resourcesharing grid.

Figure 1.2. 9"%' latform architecture.

The

a,or *G3- goals are( #dentif" the use cases that can drive the *G3- platfor co ponents #dentif" and define the core *G3- platfor co ponents 5efine hosting and platfor -specific bindings 5efine resource odels and resource profiles with interoperable solutions

-s of toda" there have been a lot of activities in the GG? to define the use cases and core platfor services. /e are going to concentrate ost of our discussion on these two areas. -s "ou can see, there is not uch activit" going on in the platfor binding and resource odels'profile areas. /e are assu ing that these areas will beco e ore active when people start i ple enting ore *G3--based grid solutions in their environ ents and ore sharable resources beco e e.posed to the grid co unit". #n addition to the broad goals defined above, *G3- defines including(

ore specific goals,

?acilitating distributed resource anage ent across heterogeneous platfor s Providing sea less !ualit" of service deliver" 4uilding a co Providing co towers) on base for autono ic anage ent solutions

on infrastructure building blocks to avoid )stovepipe solution essages

*pen and published interfaces and

#ndustr"-standard integration solutions including /eb services

?acilities to acco plish sea less integration with e.isting #T resources where resources beco e on-de and services'resources Providing ore knowledge-centric and se antic orientation of services

/e start with so e use cases that drive the architecture behind *G3-. /e then e.plore core services that are developed as part of the platfor solutions for the re!uire ents gathered during the )use case) phase. #n the chapter )#ntroduction to *G3# 3pecification,) we cover the details of the *G3# specification through e.a ples.

Chapter :. 'ome 'ample -se Cases "hat Drive the OG'0

The *G3- architecture working group defines a nu ber of use cases fro a wide variet" of application scenarios including those related to e-science and e-business applications. The

ain purposes of these use cases are( To identif" and define core *G3- platfor functionalities To define core platfor co ponents based on the functionalit" re!uire ents To define the high-level re!uire ents on these core co ponents and identif" their interrelationship

These use cases are defined as part of the *G3--/G charter definition specified b" GG?, which sa"s, )To produce and docu ent the use cases that drive the definition and prioritization of *G3- platfor co ponents, as well as docu ent the rationale for our choices.) -s we can see, so e of these use cases defined below fro the e-business and escience world helps identif" the general *G3- platfor features, co ponents, and their interrelationships. This will pave the wa" for the detailed discussion on the *G3- architecture platfor co ponents. 2ere are the representational use cases fro which we will use in our discussion(

the *G3- -rchitecture working group,I1J

Co ercial 5ata Center 6Co ercial Grid7 Aational ?usion Collaborator" 63cience Grid7 *nline 1edia and Bntertain ent 6Co ercial Grid7

/e will discuss the core aspects, scenarios, and the re!uire ents drawn fro these use cases. This will for the basis for our discussion on the *G3- core platfor co ponent.

Commer#ial )ata Center 4C)C5

0ummar( 5ata centers are co on in ost of the big enterprises in order to consolidate the huge nu ber of servers to reduce the total cost of ownership. 5ata centers pla" a ke" role in the outsourcing business where a,or businesses outsource their #T resource anage ent to concentrate on their core business co petence and e.cellence. These data centers are re!uired to anage a huge nu ber of #T resources 6servers, storages, and networks7. 3ince these data centers are providing resource-sharing capabilities across virtual organization, grid co puting for s the technolog" of choice for their resource anage ent. #n order to support such a co ercial grid, the grid technolog" platfor , iddleware, and applications should possess a nu ber of core functionalities. /e identif" and enlist these functionalities b" defining the custo ers of this data center and their usage scenarios. Customers<Providers 4"#tors5

Grid -d inistrator. -n ad inistrator wants to get the a.i u utilization of the resources in the data center and the anage ent of the resource sharing to be controlled through resource policies. #T 3"ste #ntegrator. - s"ste integrator wants to reduce the co ple.it" of the distributed and heterogeneous s"ste . -lso, the" are responsible for the construction of the heterogeneous s"ste and anage ent of service changes. #T 4usiness -ctivit" 1anager. - business anager needs a scalable and reliable platfor at a lower cost and an agreed-upon !ualit" of service.

0#enarios

1ultiple in-house s"ste s support within the enterprise. Consolidate all the in-house s"ste s in one place and ake resources available on an on-de and basis. This reduces the cost of ownership and increases resource utilization. This scenario is suitable for hu an resource services, custo er resource anage ent, finance, and accounting s"ste s. Ti e-constrained co ercial ca paign. Provides the resources on de and in order to run ti e-constrained ca paigns and lev" charges on the basis of usage. B.a ples of these ca paigns include sales pro otion ca paigns, ga e ticket sales, and so on. 5isaster recover". -n essential part of the a,or #T s"ste s toda". Co ercial G+#5 s"ste could provide standard disaster recover" fra eworks across re ote C5C at low cost. Global load balancing. Geographicall" separated data centers can share high workload and provide scalable s"ste s.

1un#tional 2e8uirements on .G0"

-fter a thorough and careful e.a ination of the static and d"na ic behavior present in this use case, the following functional re!uire ents of the grid architecture can be identified(

5iscover" of the available resources 3ecure authentication, authorization, and auditing on resource usage +esource brokering services to better utilize and use the resources and to achieve the level of !ualit" re!uire ents 3calable and anageable data-sharing echanis s

Provisioning of resources based on need 3cheduling of resources for specific tasks -dvanced reservation facilities to achieve the scale of Go3 re!uire ents Bnable units etering and accounting to !uantif" the resource usage into pricing

Bnable s"ste capabilities for fault handling and partial failure detection'correction @se static and d"na ic policies 1anage transport and essage levels and end-to-end securit" on functionalities and

Construct d"na ic virtual organizations with co agree ents ?acilitate resource onitoring

Bnable the facilities for disaster recover" in case of outages

Aow let us ove on to another use case where we will discuss a scientific research pro,ect with geographicall" distributed participants. O 5a" 5a" @p P

ational 1usion Colla*orator( 4 1C5

0ummar( The A?C pro,ect defines a virtual organization devoted to fusion research and provides the )codes) developed b" this co unit" to the end users 6researchers7. Barlier, this )code) software was installed in the end user0s achine. This beca e a co ple. and un anageable process of software anage ent, distribution, versioning, and upgrade. 5ue to this change anage ent and configuration proble

the fusion co unit" decided to adopt the -3P odel, known as )network services odel,) where the )code) is aintained b" the service provider and ade accessible to the re ote clients. This eli inates the burden on the end user but adds so e Go3 re!uire ents on the service provider, including e.ecuting the )code) as efficientl" as possible, e.ecuting within a certain ti e fra e, and producing the results with accurac". -s "ou can i agine, this is the best-case usage odel for a co putational grid. Aow, we can drill down into the usage scenarios of this grid and derive the functional re!uire ents on Grid Co puting architecture. Customers 4"#tors5 3cientists. The" are custo ers of the fusion code provided b" the fusion service provider. 3o e of the custo er re!uire ents are(

The abilit" to run the )code) in re ote resources on the condition of end-toend !ualit" of service with a guarantee of ti e-bound e.ecution. -vailabilit" of the resource 6code e.ecution7 in the co putational grid. - polic"-based anage ent of resourcesF including who can run the code, how an" hardware resources are available, etc. -bilit" to use co unit" services b" getting accredited with the co unit" rather than an individual service provider. This is a for of )d"na ic account) creation and usage.

0#enarios

- re ote client 6scientist at an A?C facilit"7 can run code on a re ote site within a ti e fra e. The service provider downloads the necessar" data and e.ecutes a workflow script. - onitoring agent starts and watches the sub itted ,ob for service-level agree ent 638-7 validation. This helps the service provider to provision ore resources or recover fro failure conditions, etc. #ntegrate with e.ternal applications and resources for data and'or code e.ecution and fle.ible delegation of rights.

1un#tional 2e8uirements on .G0" -fter a thorough and careful e.a ination of the static and d"na ic behavior present in this use case, the following functional re!uire ents of the grid architecture can be identified(

5iscover" of available resources /orkflow anage ent for ,ob distribution across resources 3cheduling of service tasks Bnabling the facilities for disaster recover" in case of outages

Provisioning of resources based on the need +esource brokering services to better utilize and use the resources and to achieve the level of !ualit" re!uire ents 8oad balancing to Aetwork transport anage workloads anage ent anage ent

#ntegration with legac" applications and their

2andling application and network-level firewalls 3ervice-level agree ent and agree ent-based interaction Providing end-to-end securit" and securit" authorization and use policies

Ae.t we discuss an online edia and entertain ent pro,ect with so e highl" interactive content and data sharing a ong participants. This is an on-de and edia and entertain ent s"ste , which can be a classic representation of the ne.t generation of on-de and applications.

.nline 3edia and 'ntertainment

0ummar( The entertain ent contents a" consist of different for s 6e.g., ovie on de and or online ga es7 with different hosting capacit" de ands and lifec"cle properties. *ne of the pri ar" goals of this use case is the abilit" to d"na icall" anage the resources based on workload de and and current s"ste configuration. -nother observation with edia entertain ent is the change of the content during its lifec"cle and changes in the roles of the actors involved. @ser involve ent and responsiveness with the entertain ent content drives this use case into two categories(

The consu ption of the user interaction

edia content,

ovie on de and, with ver" li ited

?re!uent user interaction with the content, as we can see in online ga es.

- nu ber of new co ercial consu er e.periences will e erge fro the econo ic factors of content subscription, usage-based pricing, content availabilit", and differentiation a ong co petitors. 1ost of online edia entertain ent 6ga es and video on de and7 are designed based on a stovepipe solution for each edia entertain ent and each solution is anaged separatel". This will beco e a cu berso e solution because of the lack of reusabilit" and overprovisioning of the resources. The grid architecture should provide

echanis s for on-de and provisioning, new business resource-sharing odels. "#tors

odels 6pricing

odels7, and

1. - custo er who consu es the entertain ent content $. - service provider who hosts the entertain ent content %. - publisher who offers the entertain ent content &. - developer who consu es the entertain ent content 0#enarios

- consu er, for e.a ple a ga e pla"er, accesses the ga e portal and authenticates with the ga e server and starts the ga e. There are several providers that are working in concert to provide the re!uired service for the consu er. ?or e.a ple, the network service provider offers the re!uired bandwidth, the hosting provider provides the server and storage, and the application service provider offers co on services like ga e engine, accounting and billing applications, and help. The content provider or e.perience. edia studio provides the content for the custo er

Bach of the above activities is an interaction between actors. 1un#tional 2e8uirements on .G0" -fter a thorough and careful e.a ination of the static and d"na ic behavior present in this use case, the following functional re!uire ents of the grid architecture can be identified(

5iscover" of resources #nstantiating new service 3ervice-level Bnabling anage ent to eet user e.pectations

etering and accounting to !uantif" resource usage into pricing units

1onitoring resource usage and availabilit" 1anaging service policies Providing service grouping and aggregation to provide better inde.ing and infor ation 1anaging end-to-end securit" 3ervicing lifec"cle and change anage ent

?ailure

anage ent anage ent

Provisioning /orkload

anage ent

8oad balancing to provide a scalable s"ste

/e can see that the re!uire ents enlisted in each of the use cases are co ple.. Providing a solution to these co ple. re!uire ents is a challenging task. /e will see in the co ing chapter how the *G3- architecture is tr"ing to provide so e basic solutions to the above re!uire ents.

0ummar(
The above use cases introduced so e of the core scientific and co ercial usage patterns for grid co puting. -fter going through the above representative use cases and the functional re!uire ents e.hibited b" each of the , we can classif" the into four categories( 1. 4asic functions $. 3ecurit" functions %. +esource &. 3"ste anage ent functions

properties

5iscussion of the details of these classifications will be covered when we discuss the platfor co ponents. 4ased on the above functional re!uire ents, *pen Grid 3ervice -rchitecture /G started identif"ing the platfor services and the co ponent odel definitions for each of the identified services.

Chapter ;. "he OG'0 $lat(orm Components

The ,ob of the *G3- is to build on the grid service specification 6*pen Grid 3ervice #nfrastructure, or *G3#7 to define architectures and standards for a set of )core grid services) that are essential co ponents to ever" grid. -s we have discussed in the previous chapter, a set of core *3G- use cases are developed, which for s a representative collection fro different business odels 6e.g., business grids and science grids7 and are used for the collection of the *G3- functional re!uire ents. /e have identified so e core basic functions across all the grid services. 8et us now further e.plore the details of these core platfor services and their definitions in the conte.t of *G3- and their interrelationships. /e are assu ing that these core grid service co ponents ust be present in ever" *G3--based interoperable Grid Co puting fra ework for the best !ualit" of control features. -s shown in ?igure <.1, the basic *G3- architectural organization can be classified into five la"ers(

native platfor services and transport *G3- hosting environ ent *G3- transport and securit" *G3- infrastructure 6*G3#7

echanis s

*G3- basic services 6 eta-*3 and do ain services7

Figure ;.1. 9"%' core latform com onentsEan +8( vision on 9"%' and integrated soft#are com onents.

The above defined *G3- la"ers for the foundation for new high-level anage ent applications and iddleware Grid solutions and new class of Grid applications.

ative Plat!orm 0ervi#es and Transport 3e#hanisms

The native platfor s for the concrete resource-hosting environ ent. These platfor s can be host resources specific to operating s"ste s or hardware co ponents, and the native resource anagers anage the . The transport echanis s use e.isting networking services transport protocols and standards.

.G0" Hosting 'nvironment

/e will cover in subse!uent chapters e.actl" how the standard interface definitions defined b" the grid service specification allows for two services'resources interoperating together. These definitions do not, however, address the portabilit" of services i ple entations. Portabilit" across hosting environ ents still needs to be addressed b" both grid co unities and other hosting environ ents, including C$BB or .ABT. These co unities are working together on this, and solutions will be

forthco ing over the ne.t relativel" short period of ti e. O 5a" 5a" @p P

Core etworking 0ervi#es Transport and 0e#urit(

-n *G3- standard does not define the specific networking services transport, nor the securit" echanis s in the specification. #nstead, it assu es use of the platfor specific transport and securit" at the runti e instance of operation. #n other words, these properties are defined as service binding properties, and the" are d"na icall" bound to the native networking services transport and securit" s"ste s at runti e. These binding re!uire ents are fle.ibleF however, the co unities in collaboration with the hosting and platfor capabilities ust work together to provide the necessar" interoperabilit" aspects.

.G0" In!rastru#ture
The grid service specification developed within the *G3# working group has defined the essential building block for distributed s"ste s. This is defined in ter s of /eb service specifications and description echanis s 6i.e., /3587. This specification provides a co on set of behaviors and interfaces to discover a service, create service instance, service lifec"cle anage ent, and subscribe to and deliver respective notifications.

.G0" Basi# 0ervi#es

3o e of the

ost notable and interesting basic services are as follows(

Co on 1anage ent 1odel 6C117 3ervice do ains 5istributed data access and replication Polic" 3ecurit" Provisioning and resource -ccounting' etering Co on distributed logging anage ent

1onitoring 3cheduling

These representational services are derived fro the use cases, which we have discussed in the last chapter. #n subse!uent chapters we will cover each of the above

core services in greater detail. This discussion will include these services and their behaviors, the interfaces and infor ation odel, and their relevance to the grid co unit" and *G3- in particular. 3o e of these basic services have alread" been defined and others are still evolving. 2owever, we believe these services are representational services and, hence, re!uire a ore thorough discussion.

0ummar(
This chapter introduced us to the platfor co ponents of the *G3- architecture and their relationships. #n addition, we identified so e of the core services that should be presented for consideration. The ne.t chapter will introduce us to the base infrastructure co ponents of the *G3-, entitled the *pen Grid 3ervice #nfrastructure 6*G3#7. This *G3# discussion is one of detail, covering all aspects of the specification and its relationship with other core technologies.

Introdu#tion
Grid Co puting has attracted global technical co unities with the evolution of 4usiness *n 5e and co puting and -utono ic Co puting. Grid Co puting is a process of coordinated resource sharing and proble solving in d"na ic, ultiinstitutional virtual organizations. #n the conte.t of 4usiness *n 5e and and -utono ic Co puting 6i.e., self-regulating7, Grid Co puting deserves special attention. #t is a technical challenge to achieve a highl" a bitious interaction a ong resources being shared across virtual organizations with less centralized control, while at the sa e ti e ensuring the highest !ualit" of service. The GG? is striving to standardize this process of resource sharing through a set of software architecture standards and other i portant fra ework initiatives. The GG? started a nu ber of architecture standardization efforts in order to provide better software interoperabilit", higher levels of securit", ore enco passing resource definitions, discover" capabilities, polic" anage ent, and overall environ ental anageabilit" aspects. *ne such architecture standardization process is the*G3-, discussed in the previous chapter.

The *ase #omponent o! that ar#hite#ture is the .G0I- The .G0I is a grid so!tware in!rastru#ture standardization initiative, *ased on the emerging We* servi#es standards Grid 0ervi#es
4ased on the *G3# specification,I1J a grid service instance is a /eb service that confor s to a set of conventions e.pressed b" the /358 as service interfaces, e.tensions, and behaviors. - grid service provides the controlled anage ent of the distributed and often long-lived state that is co onl" re!uired in sophisticated distributed applications. -ccording to the definition of *G3#, ever" grid service is a /eb serviceF however, the converse need not be true. The *G3# specification defines the following(

2ow grid service instances are na ed and referenced 2ow the interfaces and behaviors are co on to all G+#5 services

2ow to specif" additional interfaces, behaviors, and their e.tensions

The grid services specification does not address the co on service hosting behaviors, including how grid services are created, anaged, and destro"ed in a hosting environ ent. +ather, the specification reco ends essage-level interoperabilit", whereb" an" grid service client following the *G3# standard can interact with ever" grid service hosted b" an" hosting environ ent. This essagelevel interoperabilit" is the core feature of this standard, and it is achieved b" using 918 as the core essage for at and sche a.

"he Grid 'ervice 'peci(ication Does /ot 0ddress Common 'ervice .osting
This discussion is based on the proposed final draft published b" the GG? *G3# /G, dated Cune $;, $>>%. This specification has gone through the GG? :>-da" public review process and incorporated public reco endation and will soon be accepted b" the GG? as a grid standard. The acceptance of this specification will provide significant effects across global Grid Co puting co unities.

?or purposes of this particular discussion, the *G3#, and the concepts introduced b" the specification, we will now introduce a sa ple fro the anage ent aspect of grid services, as specified through the 1eta-*3 service of the Co on 1anage ent 1odel.I$J This sa ple is an operating s"ste resource i ple entation with its associated factor" service i ple entation. /e will be focusing on the *G3# concepts used b" this sa ple service i ple entation, and not on the anageabilit" features. 3ince *G3# is la"ered on top of the /eb service standard, fa iliarit" with the core /eb service concepts, including 918, 918 sche a, /358, 3*-P, and the /eb services progra ing odel, 6i.e., client and server side7 will help us to better understand the *G3# in greater depth. /e can find greater details on these technologies in the previous discussion and b" visiting their /eb sites. The interface inheritance diagra , as shown in ?igure =.1, introduces the following concepts of a grid service, enabled b"(

Providing a stateful /eb service i ple entation of the operating s"ste service with public interface 6*perating3"ste portT"pe7 to access the service and its state. 3upporting interface inheritance. The operating s"ste service i ple ents *perating3"ste portT"pe, which is derived fro the 4ase1anageable+esource interface, which in turn e.tends the Grid3ervice interface. 3pecif"ing the co on grid service behaviors 6public )state data) and )operations)7 using Grid3ervice portT"pe as defined b" the *G3#.

-llowing the operating s"ste services to inherit the public state data and operations fro its parent port t"pes. 1anipulating the state of a service through the Grid3ervice operations such as )find3ervice5ata) and )set3ervice5ata.) Bnabling the client so that it can discover the state and eta-data of the service through )find3ervice5ata) of the Grid3ervice interface. /e will see the co on *G3#-defined service eta-data later in this chapter. Bstablishing a pattern i ple entation for the operating s"ste service, whereb" the factor" service inherits fro the *G3# factor" interface. This is an optional feature and hence a" not present itself in the real grid service i ple entation environ ents.

Figure A.1. The 9"%+ 7ort Ty e +nheritance model for o erating system service and the o erating system factory service sam le )the solid arro# indicates the inheritance*.

*ne of the re!uire ents of services defined b" the *G3# is the abilit" to describe the preceding concepts using an *G3# description odel, which is a co bination of /eb service /358 and *G3# G/358. /e will see the details in later sections.

" High6/evel Introdu#tion to .G0I

This high-level introduction will set the stage for the detailed technical discussion on *G3#. The *G3# specification defines a co ponent odel using a /eb service as its core base technolog", with /358 as the service description echanis and 918 as the essage for at. -s we know, /eb services in general are dealing with stateless services, and their client interaction is ostl" stateless. *n the other hand, grid services are a long-running process, aintaining the state of the resource being shared, and the clients are involved in a stateful interaction with the services. There are two di ensions to the stateful nature of a /eb service( 1. - service is aintaining its state infor ation. These are nor all" classified as application state and in the case of grid service it directl" aps to the state of the resource. $. The interaction pattern between the client and service can be stateful. There are nu erous architecture st"les and progra ing odels for defining these I%J stateful interactions including 4PB8&/3 and +B3T 6?ielding7. -s of now, the *G3# is atte pting to answer the first di ension of the state proble b" creating a progra ing odel for how and where an application'service resource state can be logicall" aintained, and how these states are e.posed to the client. This does not ean, however, that the service contains all its ph"sical state. The ph"sical state a" be held in the real resource being odeled as the grid service. This publicl" known state can be a subset of the overall application state. /e believe that the *G3# should address the stateful essage e.change pattern in coordination with the stateful interaction specifications. ?igure =.$ introduces a nu ber of concepts surrounding *G3#, and its relation to /eb services. The following list describes points of interest related to this odel.

Grid services are la"ered on top of /eb services. Grid services contain application state factors, and provide concepts for e.posing the state, which is referred to as the service data ele ent. 4oth grid services and /eb services co e.changing 918 essages. unicate with its client b"

Grid services are described using G/358, which is an e.tension of /358. G/358 provides interface inheritance and open port t"pe for e.posing the service state infor ationMreferred to as service data. This is si ilar to interface properties or attributes co onl" found in other distributed description languages. The client progra ing odel is the sa e for both grid service and /eb service. 4ut grid services provide additional essage e.change patterns such as the handle resolution through *G3# port t"pes.

The transport bindings are selected b" the runti e. 1essage encoding and decoding is done for the specific binding and high-level transport protocol 63*-P'2TTP7.

Figure A.2. Ty ical ?eb service and grid service layers.

'ome o( the "erminologies 6e Must Be <amiliar with (or "hese Discussions 0re=
/eb service( - software co ponent identified using a @+#, whose public interfaces and binding are described using 918. These services interact with its clients using 918 essage e.changes. 3tateful /eb service( - /eb service that between clients0 interactions. aintains so e state infor ation

Grid service( This is a stateful /eb service with a co on set of public operations and state behaviors e.posed b" the service. These services are created using the *G3#-defined specification. Grid service description( - echanis to describe the public operations and behaviors of a grid service. This is e.pressed using a co bination of /358 and G/358 language specifications. The /358 is a language specified b" /%C, whereas G/358 is an e.tension echanis for /358 and is specified b" *G3# specification. Grid service instance( -n instance of a grid service created b" the hosting container and identified b" a uni!ue @+# called grid service handle 6G327. Grid service reference( - te poral binding description of a grid service endpoint. This binding lists the interfaces, endpoint address, protocol for co unication, and essage encoding rules. #n addition, it a" contain service policies and other eta-data infor ation. 3o e e.a ples of G3+ are /358, #*+, and so forth. 3ervice data ele ent( These are publicl" accessible state infor ation of a service included with the /358 portT"pe. These can be treated as interface attributes.

/ith this high-level infor ation on *G3# and the grid service, let us ove on to the technical details of the specification. /e will tr" to e.plain the core concepts through so e si ple code snippets. 8ater in subse!uent sections of the book, we will be discussing so e of the fra ework i ple entation of *G3# standards, and then we will discuss how we can i ple ent real sa ples based on the *G3# specification.

Te#hni#al )etails o! .G0I 0pe#i!i#ation

The last section provides us with the basic concepts of grid service, the ter inologies used, relationships with distributed technologies, and how we can align grid services and /eb services. 8et us now e.plore the core technical underpinnings of the *G3# specification with ore elaborate sa ples and e.planations. This discussion helps grid services developers, and tool vendors, to get detailed infor ation on the *G3# usage odel. /e reco end referring to the *G3# specification for ore

clarification on these concepts. /e will start with the *G3# e.tensions on /358. .G0I and Its 7se o! W0)/ *G3# is based on /eb services and it uses /358 as a echanis to describe the public interfaces of the grid service. There are two core re!uire ents for describing /eb services based on the *G3#(

The abilit" to describe interface inheritance The abilit" to describe additional infor ation ele ents 6state data'attributes'properties7 with the interface definitions

3i ilar to ost /eb services, *G3# services use /358 as a service description echanis , but the current /358 1.1I&J specification lacks the above two capabilities in its definition of portT"pe. The /358 1.$I5J working group has agreed to support these features through portT"pe 6now called )interface) in /358 1.$7 inheritance and an open content odel for portT"pes. -s an interi solution, *G3# developed a new sche a for portT"pe definition 6e.tended fro nor al /358 1.1 sche a portT"pe T"pe7 under a new na espace definition, G/358. This being one of the ost i portant and challenging parts of the *G3# specification, we need to spend so e ti e anal"zing the G/358 sche a and its relation to /358.

,isting A.1. The ?%D, 7ortTy e definition schema in the "?%D, names ace.
... <s%hema target)amespa%e = http://www.gri"#or-m.org/namespa%es/2003/03/gri"E61LExtensions xmlns:gws"l = http://www.gri"#or-m.org/namespa%es/2003/03/gri"E61LExtensions xmlns:ws"l="http://s%hemas.xmlsoap.org/ws"l/" ... <import namespa%e="http://s%hemas.xmlsoap.org/ws"l/"/>

<element name="port5(pe" t(pe="gws"l:port5(pe5(pe"/> <%omplex5(pe name="port5(pe5(pe"> <%omplex*ontent> <extension 3ase="ws"l:port5(pe5(pe"> <se'-en%e> <an( namespa%e="::other"

minN%%-rs="0" maxN%%-rs="-n3o-n"e""/> </se'-en%e> <attri3-te name="exten"s" -se="optional"> <simple5(pe> <list item5(pe="+)ame"/> </simple5(pe> </attri3-te> <an(2ttri3-te namespa%e="::other"/> </extension> </%omplex*ontent> </%omplex5(pe> </s%hema>

8isting =.1 shows the /358 sche a definition in the G/358 na espace. The i portant infor ation conve"ed b" this sche a definition includes(

-n 918 ele ent )portT"pe) is defined in the G/358 na espace 6)gwsdl(portT"pe)7. The 918 ele ent )portT"pe) is e.tending 6918 sche a e.tension7 the )wsdl(portT"peT"pe,) which is defined b" /358 1.1 sche a. -n open content ele ent odel for port t"pe content fro an" other na espace using Oan" na espaceS)TTother)U'P. This enables us to e bed an" 918 ele ents fro na espaces other than )gwsdl) inside the gwsdl(portT"pe ele ent. This new ele ent adds an optional attribute called )e.tends,) which takes the GAa e list. Aote that these GAa es ust be either a wsdl(portT"pe or gwsdl(portT"pe na e. -n open content attribute odel b" using Oan"-ttributeU'P. This provides us with the fle.ibilit" of adding an" attributes to )gwsdl(portT"pe.)

4ased on the previous discussion regarding the G/358 portT"pe declaration, let0s create a sa ple G/358 port t"pe definition.

,isting A.2. ' sam le "?%D, ortTy e.

<gws"l:port5(pe name="Nperating6(stem" exten"s="%rm:$ase;anagea3le,eso-r%e ogsi:8ri"6ervi%e">

<ws"l:operation name="re3oot"/> <ws"l:operation name="sh-t"own"/>

<s":servi%e1ata name="li#e%(%le;o"el" <s":servi%e1ata name="servi%e8ro-p5(pe" </gws"l:port5(pe>

..... /> ..... />

#n 8isting =.$, we are utilizing the )gwsdl(portT"pe) with the na e )*perating3"ste ) and it e.tends two other port t"pes, cr (4ase1anageable+esource and ogsi(Grid3ervice, respectivel". The open content odel of the gwsdl(portT"pe now allows new ele ents into the portT"pe definition fro other na espaces such as )sd(service5ata,) as shown in the listing. 0igni!i#an#e o! Trans!orming GW0)/ to W0)/ )e!inition #t is, however, a known fact that none of the /358 1.1 tools can handle these e.tensions. 1ost of the will fail on /358 validation. The current /358 1.1 anipulation tools are used to create native language interfaces, stubs, and pro.ies fro /358, and for the converse process of creating /358 fro the services i ple ented in native language. These functions have to be intelligent in order to handle these e.tensions. 4asicall", G/358 e.tensions are to be transfor ed to /358 1.1 artifacts. This includes(

-ll the )e.tends) port t"pes, and their operations, which are brought down to a single ost derived portT"pe. This process is called )flattening) of the interface hierarch" to the ost derived t"pe. -ll the service data ele ents and G/358 e.tensions are retained for the reverse transfor ation process.

3o e work has been acco plished in the GG? *G3# /G to define a nor al process of defining the above transfor ation process.I:J 8et us e.plore and illustrate this transfor ation process through the following discussion and e.a ple illustration. ?igure =.% shows a si ple transfor ation process 6i.e., port t"pe flattening7, where the G/358 portT"pe *perating3"ste e.tends the 4ase1anageable+esource and Grid3ervice declarations. These declarations are subse!uentl" flattened to a /358 portT"pe *perating3"ste , with all operations fro its parent. #t is worth" to note that the /358 1.1 tools can all work on this newl" e erged portT"pe definition.

Figure A.3. The ?%D, 2 ?%D, transformation rocess.

.perator .verloading 0upport in .G0I Port T(pe -nother i portant aspect of the *G3# is the na ing convention adopted for the portT"pe operations, and the lack of support for operator overloading. #n these situations, the *G3# follows the sa e conventions as described in the suggested /358 1.$ specification. This now beco es rather co ple. across several different di ensions, especiall" in the conte.t of interface inheritance, and the process of transfor ation to a single inheritance odel as previousl" described. #n these kinds of situations, we have to adhere to the *G3# reco endation. The *G3# reco ends that if two or ore port t"pe operation co ponents have the sa e value for their na e and target na espace, then the co ponent odel 6i.e., the se antic and operation signature7 for these operations ust be identical. ?urther ore, if the port t"pe operation co ponents are e!uivalent, then the" can be considered as candidates to collapse into a single operation.

$ort "*pe Operation Considerations 0re 4e*

There is a consensus a ong *G3# work group e bers to follow the /358 1.$ specification in all respects. This agree ent a" eli inate the new sche a and na espace 6G/3587 introduced b" the *G3# when /358 1.$ reaches the reco endation stage. Therefore, related to current utilization and for backward co patibilit", developers of tools and applications should consider the use of the G/358 e.tensions. #n addition to the /358 1.$ reco endation, one should beco e fa iliar with the /eb 3ervices-#nteroperabilit" 6/3-#7 basic profile best practices guidelines for interoperable /eb services and grid services.

8et us now e.plore one of the

ost interesting concepts of a so ewhat co

on

approach to describe the publicl" available state infor ation of a service and its architectural odel.

Introdu#tion to 0ervi#e )ata Con#epts

- grid service is a stateful /eb service. 4ecause of this architecture odel design fact, the service data concept re!uires the *G3# to identif" a co on echanis to e.pose the state data of the service instance to the service re!uestor of the !uer", the update action itself, and finall" enable the change notification to occur. #n this case, the *G3# utilized the )service data declaration) as a echanis for publicl" e.pressing the available state infor ation of a service. This concept, however, is not li ited to grid services. The service data concept can be e.tended to an" stateful /eb service for declaring its publicl" available state infor ation through the service data concepts. Therefore, developers that were e.posed to so e of the ore traditional distributed technologies, and their interface declaration 6#587 approaches, will be fa iliar with this so ewhat si ilar concept. 3o e of the ob,ect-oriented distributed language interfaces use attributes declaration to indicate the e.posed state'properties of the services the" describe. The following describes the service data concepts introduced b" the *G3# specification(

3ervice data declaration 63557 is a echanis to e.pose a publicl" available state of a service. 3ervice data ele ents 635B7 are accessible through the co on grid service interfaces 6)find3ervice5ata) and )set3ervice5ata)7. The internal state of a service should not be a part of the service data declaration.

Provided that we have now discussed the usabilit" of service data, let us now e.plore the concepts, se antics, and usage odel of service data in the conte.t of a grid service. How to )e#lare 0ervi#e )ata with a portT(pe

,isting A.3. The service data element declaration and some static service data values.
<gws"l:port5(pe name="Nperating6(stem" exten"s="%rm:$ase;anagea3le,eso-r%e ogsi:8ri"6ervi%e"> <ws"l:operation name="re3oot"> ................................ </ws"l:operation>

......................................... <s":servi%e1ata name="li#e%(%le;o"el" t(pe="%rm:li#e%(%le;o"el5(pe" minN%%-rs="1" maxN%%-rs="1" nilla3le="tr-e" m-ta3ilit(="stati%"/>

<s":servi%e1ata name="servi%e8ro-p5(pe"

..... />

.................................................................... <s":stati%6ervi%e1ataCal-es> <%rm:li#e%(%le;o"el> <li#e%(%le6tate name=""own"> <s-36tate name="restarta3le"/> <s-36tate name="re%overe""/> </li#e%(%le6tate> <%rm:li#e%(%le;o"el/> ................................................ </s":stati%6ervi%e1ataCal-es> ................................................ </gws"l:port5(pe>

8isting =.% shows how we can e.tend the G/358 portT"pe 6na eS)*perating3"ste )7 with the contents of service5ata, which is used to define service data ele ents 635B7. 3tatic service data values are defined in the /358 portT"pe and are available to all services that i ple ent this portT"pe.

<our 'ervice Data Concepts

3ervice 5ata Ble ents 635B7. The publicl" accessible service data 918 ele ents that are defined inside gwsdl portT"pes are called service data ele ents, or 35Bs 6e.g., as shown in the above listing, there are two 35Bs, lifec"cle1odel and serviceGroupT"pe7. 3ervice 5ata 5eclaration 63557. The 35Bs in the port t"pe are referred to as service data declaration, or 355 6e.g., the above listing indicates that there are two 355s available in the *perating3"ste portT"pe7. 3ervice 5ata Ble ent Kalues 635 values7. These are values of the service data ele ents. These values are 918 frag ents. There a" be a sche a for the 918 ele ent frag ent as defined b" the 35B )t"pe) attribute. There are two t"pes of 35 values based on service data ele ent0s utabilit" attribute value )static) and )d"na ic) 6e.g., the above listing shows that two service data ele ents and their values as static service data values, which are declared in the port t"pe using Osd(static3ervice5ataKaluesP ele ent7. 3ervice 5ata 3et 635 set7. This can be a logical or ph"sical collection of service data ele ents and their values for a service instance. This set is e.posed through Grid3ervice portT"pe public interfaces 6)find3ervice5ata,) )set3ervice5ata)7. This is an aggregated collection of 35Bs fro all the port t"pes in the interface hierarch", which the service i ple ents.

0ervi#e )ata 0tru#ture 3ervice data is clearl" odeled in the *G3#-defined na espace attribute, which is elaborated in the /eb site www.gridforu .org'na espaces'$>>%'>%'service5ata. This new *G3# sche a t"pe for service data 6)sd(service5ata)7 contains seven predefined attributes, including na e, t"pe, in*ccurs, a.*ccurs, odifiable, utabilit", and nilable. 1ost of these attributes are standard 935 t"pes, with the e.ception of the ) utabilit") attribute. This is further defined b" *G3# as an enu erated t"pe, with values of )static,) )constant,) )e.tendable,) and ) utable.) Aote that this sche a allows us to alwa"s add additional attributes of choice. There is another notable, "et often underutilized feature in this instance provided b" this t"pe of definition. #t is the open content odel related to content fro an" other na espace. This feature a" be utilized in the future to e.pose so e policies or eta-data about the service data, including securit" profiles. Table =.1 lists these attributes of service data and their default values.

Table A.1. Defines the details of the %ervice Data -lement 'ttributes
0)' "ttri*utes Aa e )es#ription and )e!ault %alues

This is a re!uired attribute with a uni!uel" identifiable na e of the service data ele ent in the target na espace. This is the other re!uired attribute, which defines the 918 sche a t"pe of the service data value, the 35 value. The 35 value is based upon this sche a and can be defined as si ple or co ple. in a anner related to 935 sche a t"pes, and'or one a" define this in ter s of other co ple. t"pes.

T"pe

This indicates the a.i u nu ber of 35B values that can appear in a.*ccurs the service instance0s 35B value set, or the portT"pe static3ervice5ata Kalues. 5efault value S 1 This indicates the ini u nu ber of 35B values that can appear in in*ccurs the service instance0s 35B value set or the portT"pe static3ervice5ataKalues. #f in*ccurs S >, then this 35B is optional. 5efault value S 1 nilable This indicates whether an 35 value can have a nil value. *ne can declare this 35B as(
<s":servi%e1ata name="li#e%(%le;o"el" t(pe="%rm:li#e%(%le;o"el5(pe" nilla3le="tr-e"/>

-nother valid 35B value is(

<s": li#e%(%le;o"el xs":nil="tr-e" />.

5efault value S false This is a echanis to specif" a read-onl" and changeable service data odifiable ele ent. #f changeable, "ou can use )set3ervice5ata) operation to change its 35B value based on the other attribute 6 utabilit", in, and a.7 constraints. This odifiable attribute is applicable to the service re!uestor onl". #nternall" a service can change its 35B values if other constraints are et. 5efault value S false 6all 35Bs are b" default )read onl")7

Table A.1. Defines the details of the %ervice Data -lement 'ttributes
0)' "ttri*utes utabilit" )es#ription and )e!ault %alues This is an indication of whether and how the values of a service data ele ent can change. Possible values are )static) V )constant) V )e.tendable) V ) utable) 6see Table =.& for detailed infor ation7. 5efault value S )e.tendable) This attribute set is e.tensible through the open attribute declaration of the sche a0s 35B. Therefore, the service can add ore se antic infor ation about a service data through attribute e.tensibilit". -n e.a ple of this e.tensibilit" is presented later with life c"cle attributes for a service data ele ent. +e e bering the default values of these attributes will help us to understand and define a good state anage ent fra ework for grid services. 4ased on the 35 definition, and as shown in the above table, the re!uired attributes for an 35B are )na e) and )t"pe) attributes and the service developer is e.pected to provide the . The other attributes have default values assigned to the . How 3uta*ilit( "ttri*utes "!!e#t 0ervi#e )ata *ne of the ost co ple. concepts of the service data ele ent is its utabilit" attribute. Table =.$ below shows the possible utabilit" attributes and the resulting 35B values. #t also shows how we can define and initialize those values.

Table A.2. %ervice data element mutability attributes

0)' 3uta*ilit( "ttri*ute %alue 3tatic

How to )e!ine and Initialize This 0)' )es#ription o! 0)' %alue %alue -nalogous to a language #nside G/358 portT"pe using class e ber variable. -ll Ostatic3ervice5ataKaluesP. /e can see portT"pe declarations carr" this e.a ple in the previous listing. this service data value. This 35B value is constant and ust not change. This 35B value is assigned on the creation of grid service 6runti e behavior7.

Constant

Table A.2. %ervice data element mutability attributes

0)' 3uta*ilit( "ttri*ute %alue B.tendable

How to )e!ine and Initialize This 0)' )es#ription o! 0)' %alue %alue 3i ilar to the notion of appending values. *nce added, these values re ain with the 35B, while new values are appended. The 35B values can be re oved and others can be added. Progra aticall" speaking, we can append new 35B values. The new values are appended while the old ones re ain.

1utable

Progra aticall" speaking, we can change these 35B values and add new ones.

T(pes o! 0ervi#e )ata 'lements and 0ervi#e )ata %alues Bver" service instance has a collection of service data ele ents it e.poses through public interfaces. These service data ele ents can be classified into two t"pes of attributes, based upon the creation se antics. These are( 1. 3tatic. 5eclared as part of the service0s interface definition 6G/358 portT"pe definition7. $. 5"na ic. -dded to a service instance d"na icall". This behavior is i ple entation specific. The client a" know the se antics 6t"pe and eaning7 of the service data, or can ac!uire that infor ation fro so ewhere 6service or third part"7 through eta-data e.change. ?or e.a ple, in order to process the d"na ic 35B values, "ou a" need to get the sche a t"pe infor ation for the 35B values fro a re ote location.

.ow to Discover 0vaila)le 'ervice Data %lements >'tatic and D*namic? in a 'ervice
To support both t"pes of service data, the client ust get the co plete list of service data ele ents in a service during runti e. The client can !uer" a service to get the current list of service data ele ents using the find3ervice5ata ethod of the grid service 6the service instance keeps a list of 35B ele ents, both static and d"na ic, in its )service5ataAa e) service data 35B7. /e will see the details later when we discuss the Grid3ervice portT"pe.

/e have alread" noted that the initial values of the service data ele ent are specified in /358, "et onl" for 35Bs with a utabilit" value of )static.) /e can see that in the afore entioned listing e.a ple.

'ervice Data Implementation /otes

The *G3# specification did not direct how the service data values for an 35B are stored in a service instance. The service i ple entation can ake this decision, based upon the d"na ic, persistence, and other constraints of the 35 values. ?or real-ti e data behavior in a service, one a" i ple ent a )pull) echanis for the respective service data value, whereas caching of 35 values in a logical service data set can provide faster response. Bven though the specification does direct the need for a prescribed 35B storage echanis in the service side, it necessitates the need for a logical 918 docu ent odel with )service5ataKalues) as the root ele ent. This root ele ent a" contain service data ele ent values in an" encoding for at. This is an i ple entation-specific behavior.

The GW0)/ portT(pe Inheritan#e "!!e#ts the 0ervi#e )ata - grid service can support the portT"pe inheritance odel as defined b" the G/358. /e have alread" discussed this in this interface hierarch". 8et us now e.plore the causal i pacts of how this inheritance odel can affect the service data declarations that are associated with each portT"pe in the inheritance chain. 8isting =.& describes how the portT"pe hierarch" and service data declarations work together.

,isting A.!. ' ort ty e hierarchy e2am le to e2 lain the service data aggregation scenarios.
<gws"l:port5(pe name="3ase"> <s":servi%e1ata name="3aseIs"" t(pe="xs":string" minN%%-rs="1" maxN%%-rs="1" m-ta3ilit(="stati%" />

<<=lo%al 61E "e%laration an" not a3stra%t

>

<s":servi%e1ata name="lo%alIs"" t(pe="xs":string" minN%%-rs="0" m-ta3ilit(="stati%" />

<s":stati%6ervi%e1ataCal-es> < 3aseIs">3ase</ 3aseIs"> </s":stati%6ervi%e1ataCal-es> </gws"l:port5(pe>

<gws"l:port5(pe name=""erive"I2" exten"s="3ase"> <s":servi%e1ata name=""erive"I2Is"" t(pe="xs":string" minN%%-rs="1" maxN%%-rs="1" m-ta3ilit(="stati%" /> <s":stati%6ervi%e1ataCal-es> < "erive"I2Is" >"erive" 1</"erive"I2Is" > </s":stati%6ervi%e1ataCal-es> </gws"l:port5(pe>

<gws"l:port5(pe name=" "erive" I$" exten"s="3ase"> <s":servi%e1ata name=""erive" $Is"" t(pe="xs":string" minN%%-rs="1" maxN%%-rs="1" m-ta3ilit(="stati%" /> <s":stati%6ervi%e1ataCal-es> < "erive" $Is"> "erive" 2</"erive" $Is" > </s":stati%6ervi%e1ataCal-es> </gws"l:port5(pe>

<gws"l:port5(pe name="mostI"erive"" exten"s=""erive"I2

"erive"I$">

<s":servi%e1ata name="mostI"erive"Is"" t(pe="xs":string" minN%%-rs="1" maxN%%-rs="1" m-ta3ilit(="stati%" /> <s":servi%e1ata name="lo%alIs"" t(pe="xs":string" m-ta3ilit(="stati%" /> <s":stati%6ervi%e1ataCal-es> < mostI"erive"Is" >most "erive"</ mostI"erive"Is" > <lo%alIs"> lo%al val-e 1 </lo%alIs"> </s":stati%6ervi%e1ataCal-es> </gws"l:port5(pe>

The service contains a union of all the service data ele ents defined in the portT"pes that it i ple ents. Table =.% shows how a service data aggregation occurred, with the inheritance hierarch" based on the above listing. This aggregation is based on the na e of the service data ele ent 6GAa e7 and, hence, onl" one service data ele ent with the sa e GAa e is present in the service.

Table A.3. %ervice Data -lement 'ttributes

I! a servi#e implements9 4ase 5erivedW5erivedW4 ostWderived The servi#e data set then must #ontain9

baseWsd, localWsd baseWsd, derivedW-Wsd, localWsd baseWsd, derivedW4Wsd, localWsd baseWsd, derivedW-Wsd, derivedW-Wsd, ostWderivedWsd, localWsd 6with a value of 0local value 507

?or e.a ple, 8isting =.& utilizes onl" one OlocalWsdP ele ent in the ostWderived portT"pe because the base portT"pe0s OlocalWsdP and ostWderived portT"pe0s OlocalWsdP has the sa e local na e, and the" belong to the sa e targetAa espace. -nother i portant aspect to pa" close attention to is on the static service data value aggregation odel in the case of port t"pe inheritance. This process adds the following conclusions(

The values of the static ele ents are aggregated down the interface hierarch"(

#f a portT"pe contains a static 35 ele ent, "et does not specif" a static service data value, then that portT"pe can be treated as( o -bstract if the in*ccurs is not >, and we ust provide so e value in our derived port t"pes.
o

#f

in*ccurs is >, then the static service data will not be initialized.

The cardinalit" re!uire ents 6i.e., in*ccurs and a.*ccurs7 on service data ele ents ust be preserved. This is especiall" true in the case of static inheritance. ?or e.a ple, if the a.i u service data ele ent values allowed is set to 1, then the derived t"pes ust confor to that rule, as it cannot set ore than a single value.

/e should refer to the *G3# specification for ore e.a ples, and best practices guidelines, on these cardinalit" constraints. /e can also see infor ation on how to define an abstract portT"pe with the 35B, how the i ple entation and tools should check for cardinalit" violation, and so on. =uali!(ing 0ervi#e )ata 'lement with /i!etime "ttri*utes #n addition to the e.pressed features of the service data as previousl" discussed, there is also a )hidden) concept in the specification with respect to the lifeti e properties associated with the service data ele ents. The concept is hidden because it is ,ust a reco endation that the service'client i ple entation could possibl" ignore. 2owever, good designs, progra s, and tools should be aware of this feature. The service data ele ent represents the real-ti e observations of the d"na ic state of a service instance. This real-ti e observation forces the clients to understand the validit" and availabilit" of the state representation. That is, certain service data ele ents, especiall" within d"na ic 35Bs, a" have a li ited lifeti e. #f there is lifeti e infor ation associated with the 35B, it can help the client to ake decisions on whether an 35B is available, has validit", and when it is to revalidate the 35B. The ost helpful develop ent i ple entation of this concept a" be the client-side service data cache, and an associated revalidation echanis . 4ased on the preceding re!uire ents, the specification provides three kinds of lifeti e properties(

The ti e fro which the contents of this ele ent are valid 6ogsi(good?ro 7 The ti e until which the contents of this ele ent are valid 6ogsi(good@ntil7 The ti e until which this ele ent itself is available 6ogsi(available@ntil7

The first two properties are related to the lifeti e of the contents, while the third, the available@ntil attribute, defines the availabilit" of the ele ent itself. ?or e.a ple, we a" see a d"na ic 35B with availabilit" until a specific ti e, and thereafter, it ceases to e.ist. This is a good indication for the users of this specific service data ele ent not to use that 35B after that specified ti e.

-ccording to the specification, these values are optional attributes of the 35B ele ent and the 35B valuesF however, it is alwa"s reco ended to include the optional attributes in the 918 sche a design of the t"pes for the service data ele ents. 8isting =.5 includes a service data declaration 6 "PortT"pe7, its t"pe 6 "T"pe7, and these lifeti e attributes, through open content 918 sche a t"pe attribute declarations 6TTan"7.

,isting A.0. 'n %D- Fmy7ortTy eF and the %D- ty e FmyTy eF #ith the o en content attributes )any'ttribute* for a lifetime attribute declaration.
<ws"l:t(pes> <xs":%omplex5(pe name="m(5(pe"> <xs":se'-en%e> <xs":element name="m(Elem" t(pe="xs":string"/> </xs": se'-en%e > <an(2ttri3-te namespa%e="::an(" /> </xs":%omplex5(pe> </ws"l:t(pes>

<gws"l:port5(pe name ="m(4ort5(pe"> <s":servi%e1ata name="m(61E" t(pe="m(5(pe" /> .......... </gws"l:port5(pe>

4ased on the service data declaration in the above listing, one a" assu e that an instance of a service data ele ent a" contain the following values 68isting =.:7(

,isting A.1. +nstantiated service data values for an %D- based on the lifetime service data declaration )in ,isting A.0*, and its ossible lifetime ro erties.
<s":servi%e1ataCal-es> < m(61E goo"Orom="2003 0@ 01 2B510:20:00.000 0D:00" goo".ntil="2003 05 20 2B510:20:00.000 0D:00" availa3le.ntil="200@ 05 01 2B510:20:00.000 0D:00"> <m(Elem goo".ntil="2003 0@ 20 2B510:20:00.000 0D:00" >

test </ m(Elem> </ m(61E> </s":servi%e1ataCal-es>

8isting =.: has instantiated service data values inside of the service instance, for the ) "35B) 35B, grouped under the logical Oservice5ataKaluesP root ele ent. 8isting =.: shows that the subele ents in the 35B values 6 "Ble 7 can override the good@ntil lifeti e propert" to a new ti e earlier than that of the parent 6 "35B7. The attribute e.tension 6an"-ttribute7 of the 35B ele ent sche a and the 918 sche a t"pe of the 35B 6shown in 8isting =.57 values akes this override feature possible. This is a best practice reco endation for service developers and odelers for finegrain control of lifeti e properties of a service data ele ent value. #f the service data ele ent and its value do not contain the declaration of these properties, then the good?ro , good@ntil, and available@ntil properties are unknown. 0ummar( on .G0I6)e!ined 0ervi#e )ata Con#epts To conclude our discussion on service data, we list the core advantages of using this progra ing odel(

Provides an aggregated view of the service state rather than individual state values or properties Gives a docu ent-centric view 6918 docu ents7 of the data, thereb" avoiding specific ethods for state access 3hows fle.ibilit" in supporting d"na ic state infor ation and service state introspection Provides lifeti e and subscription support on the state properties Bnables d"na ic construction of state data infor ation ele ents and values and the declaration of static values for the state

Grid 0ervi#e9 aming and Change 3anagement 2e#ommendations

This is a critical area in distributed s"ste s where a service a" undergo changes, including the publicl" available interface and'or i ple entation, over so e specified period of ti e. 8et us now e.plore how these changes are handled in *G3# Grid services, and what best practices one should adhere to when dealing with such d"na ics. *ne should contend with the se antics of grid services as follows(

The se antic of a grid service instance ust be well defined b" its interface definitionF a co bination of portT"pes, operations, essages, t"pes, and service data declarations. The i ple entation se antics ust be consistent with the interface se anticsF otherwise, it a" confuse the client and a" result in wa"ward behavior.

4ased on the previous observations, here are so e i portant best practices to consider(

3ervice interfaces and i ple entations should agree on the se antics of the service. #f there is a change to the interface 6e.g., s"nta. and'or se antics7 it is reco ended to provide a new interface to the client, as opposed to changing the e.isting interface. -ll the ele ents of a grid service ele ent ust be i utable. This eans that the GAa e of the portT"pe, operation, essage, service data declaration, and associated t"pes are i utable. -n" changes in an" of these should result in a new interface portT"pe. Aew interfaces should alwa"s be created using a new portT"pe GAa e 6i.e., a local na e and a na espace co bination7.

Grid 'ervice Inter(ace Change Management

4ased on the above best practices, the port T"pe designs 6i.e., the grid service public interfaces7 are to be acco plished b" taking into account that once a service interface is published to the custo ers, one cannot change itF instead, one can onl" provide a new interface with a new na e. This is one of an" best practices identified in this chapter.

Grid 0ervi#e Instan#e Handles, 2e!eren#es, and 7sage 3odels Bver" grid service i ple ented utilizing the *G3# specification should adhere to certain practices, which are i portant to the overall integrit" of the service. *ne or ore G32s ust be uni!ue. This is ke" due to the fact that these handles uni!uel" identif" a grid service instance that is valid for the entire life of a service. 2owever, handles do not carr" enough infor ation to allow a client to co unicate directl" with the service instance. The service0s G32 is based on a @+# sche eI;J 6e.g., http(''7 and the specific infor ation 6e.g, abc.co ' "#nstance7. - client ust resolve the G32 infor ation to a service specific to the G3+ discussed in the ne.t section, in one of three wa"s( b" itself, b" using the echanis s provided

fro the service provider 6e.g., a 2andle+esolver service, which i ple ents a 2andle-+esolver portT"pe7, or b" delegating to a third-part" handle resolving service 6e.g. www.handle.net7. *ne or ore G3+s are ke" to access integrit". - client can access a grid service through the use of a G3+, which can be treated as a pointer to a specific grid service instance. - G3+ is a re ote service )reference) and contains all the infor ation to access the service. The for at of a G3+ is specific to the binding echanis used b" the client to co unicate with the service. 3o e e.a ples of these binding for ats include the following(

#nteroperable ob,ect reference 6#*+7 for clients utilizing the +e ote 1ethod #nvocation'#nternet #nter-*+4 Protocol 6+1#'##*P7 /358 for clients utilizing the 3*-P protocol .ABT re oting reference

- grid service instance a" have one or ore G3+s available to it. The G3+s are associated with a lifec"cle that is different fro the service lifec"cle. /hen the G3+ is no longer valid, the client should get a reference to the service using an available G32. #t is i portant to note that the specification reco ends a /358 encoding of a G3+ for a service. Thus, we a" find that ost of the grid service i ple enters will support /358 encoding as the default encoding, and based upon the perfor ance and !ualit", can switch to other encoding.

,isting A.4. 9"%+ schema definition for "%&.

target)amespa%e = "http://www.gri"#or-m.org/namespa%es/2003/03/N86/" <xs":element name="re#eren%e" t(pe="ogsi:,e#eren%e5(pe"/>

<xs":%omplex5(pe name=",e#eren%e5(pe" a3stra%t="tr-e"> <xs":attri3-te re#="ogsi:goo"Orom" -se="optional"/> <xs":attri3-te re#="ogsi:goo".ntil" -se="optional"/> </xs":%omplex5(pe>

8isting =.; shows the sche a definition for the G3+. The optional lifeti e attributes defined b" the G3+ sche a provide the validit" of that specific G3+. 2e#ommended G02 'n#oding in W0)/ -s of toda", ost of the acco plish ents on binding are perfor ed around the /358 encoding of a G3+. This fact is of interest to the developers now faced with the construction of grid services. - discussion on /358 encoding of a G3+ with so e sa ples is i portant. 8isting =.< depicts this point of interest.

,isting A.;. D(, schema for ?%D, encoding of a "%&.

target)amespa%e = http://www.gri"#or-m.org/namespa%es/2003/03/N86/" <xs":%omplex5(pe name="E61L,e#eren%e5(pe"> <xs":%omplex*ontent> <xs":extension 3ase="ogsi:,e#eren%e5(pe"> <xs":se'-en%e> <xs":an( namespa%e="http://s%hemas.xmlsoap.org/ws"l/" minN%%-rs="1" maxN%%-rs="1" pro%ess*ontents="lax"/> </xs":se'-en%e> </xs":extension> </xs":%omplex*ontent> </xs":%omplex5(pe>

8isting =.< depicts the 918 sche a for /358 encoding of a G3+. The best practices on this encoding sche e are(

The G3+ reference ust contain a /358 definition ele ent 6i.e., with one service7 as the child ele ent. The /358 definition ele ent ust contain onl" one /358 service ele ent, and a" contain other ele ents fro the )wsdl) na espace. The 918 processing is set to )la.,) which eans 918 parser validation is co pleted on this content ele ent, based upon the availabilit" of the )wsdl) definition sche aF otherwise, no validation will be perfor ed. This is acco plished b" a runti e parser configuration, or b" including )sche a8ocation) for /3580s 935 definition along with the 918 essage.

,isting A.A. ' sam le ?%D, encoding schema of a "%&.

<ogsi:re#eren%e xsi:t(pe="ogsi:E61L,e#eren%e5(pe"> < ws"l:"e#initions name="Nperating6(stem1e#inition" xmlns="http://s%hemas.xmlsoap.org/ws"l/" xmlns:ws"l="http://s%hemas.xmlsoap.org/ws"l/"> ........................................................ <ws"l:servi%e name="Nperating6(stem6ervi%e"> < ws"l:port..........................</ ws"l:port> </ ws"l:servi%e>

</ws"l:"e#initions> </ogsi:re#eren%e>

-s the developer of the grid service, one should be aware of another helpful practice defined b" the specification called service locator. This is a grid service locator class with zero or ore G32s, G3+s, and portT"pes 6identified b" portT"pe GAa e7 i ple ented b" the service. -ll of the G32s and G3+s ust refer to the sa e grid service, and the service ust i ple ent all of the defined port t"pes. This logical grouping helps client devices have a uni!ue view of an" given service instance. /i!e C(#le o! a Grid 0ervi#e Instan#e The hosting environ ent anages the lifec"cle of a grid service b" deter ining how and when a service is created, and how and when a service is destro"ed. #t is i portant to understand that the *G3# specification does not direct that behavior. ?or e.a ple, a grid service based on an Bnterprise Cava 4ean 6BC47 has the sa e lifec"cle properties and anageabilit" interfaces and policies as defined b" that BC4 specification. The following describes lifec"cle service creation patterns, as defined b" the *G3#, to assist the clients of a grid service(

- co on grid service creation pattern is defined through the grid service factor" interface 6as discussed in the ne.t sections7 and through a create3ervice operation. The service can decide whether or not to support this behavior, based upon the respective policies defined for the service. Two destruction echanis s are defined( 1. Calling an e.plicit destruction operation 6i.e., destro" the operation on a specific Grid3ervice portT"pe7 $. @sing a service-supported soft-state echanis , based on the ter ination ti e attribute of a service

0ervi#e /i!e#(#le 3anagement 7sing a 0o!t60tate "pproa#h The soft-state lifeti e anage ent approach is a reco ended ethod in the grid service lifec"cle anage ent process. Bver" grid service has a ter ination ti e set b" the service creator or factor". - client device with appropriate authorization can use this ter ination ti e infor ation to check the availabilit" 6i.e., lease period7 of the service, and can re!uest to e.tend the current lease ti e b" sending a keep-alive essage to the service with a new ter ination ti e. #f the service accepts this re!uest, the lease ti e can be e.tended to the new ter ination ti e re!uested b" the client. This soft-state lifec"cle is controlled b" appropriate securit" and polic" decisions of the service, and the service has the authorit" to control this behavior. ?or e.a ple, a service can arbitraril" ter inate a service, or a service can e.tend its ter ination ti e, even while the client holds a service reference. -nother point to keep in ind is

whether or not to actuall" destro" a service, or ,ust to ake it unavailable. This is a service hosting environ ent decision. 3o e of the behaviors that we can infer fro the specification are(

- grid service can send lifeti e event notifications using the standard grid service notification process. - grid service0s support for the lifeti e is i ple entation dependent, and one ust consult the service docu entation for the details on this behavior. - Client with proper authorit" can re!uest for an earl" ter ination of a grid service. - grid service can e.tend the service ter ination ti e, or ter inate itself, at an" ti e during its lifec"cle.

0ervi#e .peration '+tensi*ilit( 1eatures o! Grid 0ervi#es -nother interesting feature introduced b" the specification is the concept of e.tensible operations through the use of unt"ped para eters using the 918 sche a .sd(an" construct. This feature allows grid service operations a.i u fle.ibilit" b" allowing )an") para eters 6i.e., 918 frag ents7 for that operation. 2owever, this feature introduces confusion on the client side regarding the kind of para eters it can pass to the service. To avoid that confusion, the specification provides the client base with a echanis 6i.e., !uer" capabilities7 to ask the service about the supported e.tensible para eter and its t"pe 6918 sche a7 infor ation. This e.a ple will ake the preceding idea clearer. /e have alread" discussed that we can use find3ervice5ata of Grid3ervice to !uer" the service data of a service instance. - service can support different t"pes of !ueries, including !uer" b" service data na es and !uer" b" 9Path. The specification defines the input para eter of find3ervice5ata as e.tensible, utilizing ogsi(B.tensibilit"T"pe. #n this e.a ple, one can retrieve all the possible !ueries supported b" the service instance fro the 35B values of the service0s )findservice5ataB.tensibilit") service data ele ent. 4" default, a service provides a static !uer" t"pe value called )!uer"4"3ervice5ataAa es) defined b" utilizing the static3ervice5ataKalue. These static 35B values are defined for Grid3ervice portT"pe in the ogsi.gwsdl. /e will see ore details on the operation e.tensibilit" features when we discuss the grid service portT"pes. 0ervi#e 1ault Handling in .G0I - Owsdl(operationP can define a fault essage in the case of an operation failure. #n an" cases, a service developer decides on the essage for at and the contents. The *G3# defines a co on fault essage t"pe to si plif" the proble of different fault essage t"pes being defined. The *G3# defines a base 935 fault t"pe 6ogsi(faultT"pe7 that ever" grid service ust return. 8isting =.1> e.plains the usage odel of this fault t"pe.

,isting A.1C. Fault definitions in 9"%+.

<"e#initions name="Nperating6(stem" ....> <t(pes> <element name="target/nvali"Oa-lt" t(pe="5arget/nvali"Oa-lt5(pe"/> <%omplex5(pe name="5arget/nvali"Oa-lt5(pe"> <%omplex*ontent> <extension 3ase="ogsi:Oa-lt5(pe"/> </%omplex*ontent> </%omplex5(pe> ............................................... </t(pes> <message name="5arget/nvali"Oa-lt;essage"> <part name="#a-lt" element="target/nvali"Oa-lt"/> </message> ..................... <gws"l:port5(pe name="Nperating6(stem"> <operation name="re3oot"> <inp-t...> <o-tp-t...> <#a-lt name=" 5arget/nvali"Oa-lt;essage " message="5arget/nvali"Oa-lt;essage "/> <#a-lt name="Oa-lt" message="ogsi:#a-lt;essage"/> </operation> </gws"l:port5(pe> ........................... <"e#initions>

2ere our reboot operation returns a fault essage of the t"pe Target#nvalid?aultT"pe, which is of the *G3#-defined co on fault t"pe ogsi(?aultT"pe. This provides applications to define and process a co on odel for all the fault essages. #t is a andator" reco endation that all grid service in addition to the operation-specific fault essages ust return a )ogsi(fault1essage.) This fault essage is to return all

the faults that are not defined b" the service developer. 8isting =.1> above shows these re!uire ents. Grid 0ervi#e Inter!a#es The grid service interfaces and their associated behaviors are described b" the *G3# specification. The @18 interface hierarch" diagra , as shown in ?igure =.&, describes the *G3#defined interfaces. 8et us now e.plore the basic and essential infor ation pertaining to service interface behaviors, essage e.changes, and interface descriptions.

Figure A.!. 9"%+-defined ortTy es.

/e can classif" *G3# interfaces into three sets of interfaces based upon their functionalit". These are the *G3# core, notification, and service groups. Table =.& describes the interface na e, description, and service data defined for these interfaces, as well as the predefined static service data ele ents. -s noted in the interfaces in Table =.&, all grid services are re!uired to i ple ent the Grid3ervice portT"pe and its respective behaviors. This interface and its associated service data set provide service-specific eta-data and infor ation that one can use for d"na ic service introspection, and being the core co ponent of the *G3# specification, this interface warrants ore attention.

Table A.!. ortTy es That %u ort "rid %ervice 8ehaviors, %ervice Data -lements, and %ta
PortT(pe ame Grid3ervice 6re!uired7 Inter!a#e )es#ription and .perations 0ervi#e )ata 'lements )e!ined *( This portT(pe

)e!ault 0er

-ll Grid services i ple ent this 1. interfaces interface and provides these operations and behaviors. $. service5ataAa e *perations( 1. find3ervice5ata $. set3ervice5ata %. re!uestTer inationTi e-fter %. factor"8ocator &. Grid3ervice2andle 5. Grid3ervice+eference

<ogsi: #in"6er

inp-tElement=" />

<ogsi: set6erv

inp-tElement="

<ogsi: set6erv

inp-tElement=" :. /> &. re!uestTer inationTi e4efore find3ervice5ataB.tensibilit"

5. destro"

;. set3ervice5ataB.tensibilit" <. ter inationTi e

To create a new grid service. ?actor" 6optional7 1. create3erviceB.tensibilit" Aone *perations( 1. create3ervice - service-provided echanis 2andle+esolver resolve a G32 to a G3+. 6optional7 *perations( 1. ?ind4"2andle Inside the Grid0ervi#e portT(pe The @18 notations in ?igure =.5 show the details of this interface. to 1. handle+esolver3che e Aone

Figure A.0. The /(, re resentation of "rid%ervice 7ortTy e.

-s shown in ?igure =.5, this interface provides a nu ber of service state attributes, and a nu ber of operations co on to all grid services. ?ocusing attention on the above interface definition, one can infer that the )find3ervice5ata) and )set3ervice5ata) are both e.tensible operations. The" also provide the basic capabilit" of passing an" input para eters and returning an" output para eter fro the service. /e will see the specific se antics in the following sections. Grid 0ervi#e>Provided 0ervi#e )ata =uer( Capa*ilities9 0(nta+ and 0emanti#s The *G3# is provided as a co on approach for discovering the state infor ation fro a grid service. Bver" grid service i ple ents the Grid3ervice portT"pe, and thereb" a client can use the )find3ervice5ata) operation on a grid service passing a !uer" e.pression. The for at and se antics of the !uer" e.pression para eter is based upon the !uer" support provided b" the service. 4" default, ever" grid service ust support the )!uer"4"3ervice5ataAa e) !uer" e.pression. This is a si ple !uer", utilized b" )find3ervice5ata) b" passing the GAa e of the service data ele ent of interest to get the service data ele ent values for that 35B. - grid service a" support other !uer" e.pressions, including 9Path'9Guer". -ll !uer" t"pes including the predefined !uer" t"pes are stored in the )find3ervice5ataB.tensibilit") and )set3ervice5ataB.tensibilit") service data ele ent values. Table =.5 lists the predefined static e.tensibilit" t"pes 6)!uer"4"3ervice5ataAa es,) )set4"3ervice5ataAa es,) and )delete4"3ervice5ataAa es)7. The grid service i ple entation tea ust provide both the se antic and essage for ats of the e.tended !uer" e.pressions. Consult the service and interface docu entation to find out the specific details on this additional !uer" support. 4ased on the previous discussion, let us now e.a ine so e e.a ples of using the find operation. 8et us first find all the supported !uer" e.pressions fro a service 6a read-onl" !uer"7. The !uer" s"nta. for this operation is as follows( find3ervice5ata 6B.tensibilit"T"pe !uer"4"3ervice5ataAa es7, where the e.tensibilit" t"pe contains the input essage as shown in 8isting =.11.

,isting A.11. ' @uery by a service data in ut message.

<ogsi:'-er($(6ervi%e1ata)ames> <name>ogsi:#in"6ervi%e1ataExtensi3ilit(</name> <<= name o# the servi%e "ata element </ogsi:'-er($(6ervi%e1ata)ames> >

-s described in 8isting =.11, note that the e.a ple is passing a known t"pe of !uer" e.pression )!uer"4"3ervice5ataAa es) and the service data na e of interest in this !uer". #n this case, the e.a ple is utilizing the )find3ervice5ataB.tensibilit") service5ata na e, which is the holder of the read-onl" !uer"B.pressions t"pe supported b" this specific service. The above operation a" return an output essage as shown in 8isting =.1$(

,isting A.12. ' @uery by service data out ut message.

<s":servi%e1ataCal-es> <ogsi:#in"6ervi%e1ataExtensi3ilit( inp-tElement="ogsi:'-er($(6ervi%e1ata)ames"/> <<=this is a man"ator( ret-rn <ogsi:#in"6ervi%e1ataExtensi3ilit( inp-tElement="ogsi:'-er($(F4ath"/> <<=ma( present </s":servi%e1ataCal-es> > >

8isting =.1$ suggests that the service supports the default )!uer"4"3ervice5ataAa es) and a service-specific additional !uer" e.pression )!uer"4"9Path.) #t is also possible to d"na icall" deter ine all of the interfaces e.posed b" the grid services. The !uer" s"nta. for this operation is utilizing find3ervice5ata 6B.tensibilit"T"pe interface357, where e.tensibilit" t"pe contains the input essageF this is shown in 8isting =.1%.

,isting A.13. ' @uery by service data in ut message.

<ogsi:'-er($(6ervi%e1ata)ames> <name>ogsi:inter#a%e</name> </ogsi:'-er($(6ervi%e1ata)ames>

The above operation

a" result in an output

essage as shown in 8isting =.1&.

,isting A.1!. The result of a find @uery for all su ort interfaces.
<s":servi%e1ataCal-es> <ogsi:inter#a%e> ogsi:8ri"6ervi%e <<=alwa(s will 3e present >

%mm:$ase;anagea3le,eso-r%e %mm:Nperating6(stem </ogsi:inter#a%e> ......................................................... </s":servi%e1ataCal-es>

8isting =.1& suggests that this service i ple ents interfaces, including the ogsi(Grid3ervice, c (4ase1anageable+esource, and the c (*perating3"ste . Grid 0ervi#e>Provided 0ervi#e )ata 7pdate Capa*ilities9 0(nta+ and 0emanti#s The previous section e.plains the )read-onl") behavior of the service state. 3o e state infor ation in a grid service is updateable or changeable b" the client. This is si ilar to using set operations to update ob,ect properties in Cava 4eans or other language ob,ects. -s discussed earlier in this book, an *G3# service can specif" whether a state data value is changeable b" e.plicitl" setting the odifiable attribute to )true.) Bver" grid service ust support the )set3ervice5ata) operation with the )updateB.pression) e.tensibilit" t"pe para eter. The for at and se antics of the update e.pression para eter are based on the update feature support provided b" the service. ?or e.a ple, a service can provide si ple state data, update data, or a co ple. 9@pdateI<J update e.pression. /e have noted that b" default, ever" grid service provides two update e.pressions of t"pe )set4"3ervice5ataAa es,) and )delete4"3ervice5ataAa es.) 8et us now e.plore so e additional utilization e.a ples. 8et us find all the update e.pressions supported b" the service. The !uer" s"nta. is find3ervice5ata 6B.tensibilit"T"pe !uer"4"3ervice5ataAa es7, where the e.tensibilit" t"pe contains the input essage as shown in 8isting =.15(

,isting A.10. ' @uery by service data in ut message.

<ogsi:'-er($(6ervi%e1ata)ames> <name>ogsi:set6ervi%e1ataExtensi3ilit(</name> <<=this is a man"ator( -p"ate expression t(pe #or all servi%e >

</ogsi:'-er($(6ervi%e1ata)ames>

The above operation a" result in an B.tensibilit"T"pe, with an output shown in 8isting =.1:(

essage as

,isting A.11. %u orted u date e2 ressions.

<s":servi%e1ataCal-es> <ogsi:set6ervi%e1ataExtensi3ilit( inp-tElement="ogsi:set$(6ervi%e1ata)ames"/> <ogsi:set6ervi%e1ataExtensi3ilit( inp-tElement="ogsi:"elete$(6ervi%e1ata)ames"/> </s":servi%e1ataCal-es>

-s shown in 8isting =.1:, this service supports two t"pes of updates, )set4"3ervice5ataAa es) and )delete4"3ervice5ataAa es.) 8et us now appl" a set operation on service data, with a ) utable) attribute of )true,) using the supported )updateB.pression) retrieved fro the above step. The !uer" s"nta. is set3ervice5ata 6B.tensibilit"T"pe update4"3ervice5ataAa es7, where the e.tensibilit" t"pe contains the input essage as shown in 8isting =.1;(

,isting A.14. 'n in ut message for the set o eration.

<ogsi:set$(6ervi%e1ata)ames> <some6ervi%e1ataElement )ame5ag> new 61E val-ePsQ </some6ervi%e1ataElement )ame5ag> </ogsi:set$(6ervi%e1ata)ames>

The service handling of the set operation on service data is based upon a nu ber of rules defined b" *G3#. These rules include(

The service5ata )true.) The service5ata

ust be

odifiableF the 35B- odifiable attribute

ust be

utabilit" attribute should not be )static) or )constant.) ust

#f the service5ata utabilit" attribute is )e.tendable,) the set operation append the new 35B values to the e.isting 35B values. #f the service5ata utabilit" attribute is ) utable,) the set operation replace the e.isting 35B values with the new 35B values.

ust

The 35B values, )append) and )replace), a.*ccurs attributes on 35B values.

ust adhere to the

in*ccurs and

The partial failure on update and delete operations involving service data ele ents a" be co on due to the distributed nature of grid services and lack of concurrenc" in the distributed odel. Therefore, the grid service provides partial failure indication faults and the client should be aware of dealing with that. This fault t"pe e.tends )ogsi(?aultT"pe) and ust contain all the service data ele ents that cannot be updated with the one or ore fault cause infor ation sche as. Grid 0ervi#e 1a#tor( Con#epts This is an abstract concept or pattern that can be utilized to create a service instance b" the client. This is an optional interface and provides an operation called )create3ervice.) ?igure =.: illustrates the basic service creation pattern for a grid service instance. *nce the creation process has been successfull" e.ecuted, the factor" returns the grid service locator 6G32 and G3+7 infor ation, which can then be utilized b" the client to locate the service.

Figure A.1. The grid service factory usage attern.

The pattern does not andate the creation of the instanceF in the case of laz" creation, it a" ,ust return a G32 for the serviceF however, it will postpone the creation of the actual service instance. -nother point to note regarding creation se antics is the dependenc" on the hosting environ entsF the specification does not andate an" i ple entation se antics. ?or e.a ple, we can infer that if the grid service instance is an BC4 entit", the factor" a" correspond to the BC4 ho e, which is responsible for the creation of an BC4 entit" bean. Grid 0ervi#e Handle 2esolution Con#epts 2andle resolving is a standard echanis to resolve a G32 into a G3+. This is an optional feature based on the 2andle+esolver portT"pe. - grid service instance that i ple ents the 2andle+esolver portT"pe is called a )handle resolver.) This handle resolution process is i ple entation dependent and a" be tied to the hosting environ ent. ?or e.a ple, in a C$BB environ ent, this handle resolution can

be tied to the C$BB CA5# lookup, and hence, a CA5# server can be a 2andle+esolver service. -nother e.a ple a" be a global handle resolution service provider that can resolve the handle to an" services registered with it. #n so e cases, a client can perfor the resolution of service instance handle to a service reference. ?igure =.; shows a si ple handle resolution process. These resolving services a" contain a cache of handles and G3+s and are capable of collaborating with other )resolvers) in order to resolve the handle. *nce the handle is resolved, it returns a G3+ for the service instance.

Figure A.4. ' sim le handle resolution rocess.

.G0I6)e!ined Grid 0ervi#e oti!i#ation 1ramework 8et us now e.plore so e of the as"nchronous essaging capabilities provided b" the grid services. Aotification is re!uired in the process of sending as"nchronous one-wa" essages fro a service to the interested client. The *G3# defined a set of standard echanis s for sending notification essages. This specification defines a rich set of concepts.

OG'I Message /oti(ication Concepts 0re #o)ust

- notification source is a grid service instance that i ple ents the Aotification3ource portT"pe and is the source of the notification. - notification sink is a grid service instance that receives the notification essages fro an" nu ber of sources. - sink ust i ple ent the Aotification sink portT"pe. - notification essage is an 918 ele ent sent fro the source to sink and the t"pe of this ele ent is based on the subscription e.pression. - subscription e.pression is an 918 ele ent that describes what essages should be sent fro the notification source to the sink and when the essage was sent. - subscription grid service is created on a subscription re!uest and helps the clients anage the lifeti e of the subscription. These subscription services are created on subscription and these services should i ple ent Aotification3ubscription portT"pe.

This for of Table =.5.

essaging is ke" in Grid Co puting discipline, and is described in

Table A.0. ortTy es That %u ort "rid %ervice 5otification Frame#ork, %ervice Data -lemen Galues
Inter!a#e )es#ription and .perations This enables a client to subscribe for notification based on a service data value change. *perations( 1. subscribe Aotification3ink 6optional7 # ple enting this interface enables a grid Aone service instance to receive notification essages based on a subscription. Aone 0ervi#e )ata 'lements )e!ined *( This portT(pe notifiable3ervice5ataAa e subscribeB.tensibilit"

PortT(pe ame Aotification3ource 6optional7

)e!ault 0ervi#e

<ogsi: s-3s%ri3eEx

inp-tElement="s-3s />

Table A.0. ortTy es That %u ort "rid %ervice 5otification Frame#ork, %ervice Data -lemen Galues
Inter!a#e )es#ription and .perations *perations( 1. deliverAotification Calling a subscription of a 3ubscriptionB.pression Aotification3ubscription Aotification 3ource results in the creation of a sink8ocator 6optional7 subscription grid service. *perations( Aone defined The *G3#-defined notification portT"pes and their associated service data are shown in Table =.5. ?igure =.< depicts the notification flow. Aone 0ervi#e )ata 'lements )e!ined *( This portT(pe

PortT(pe ame

)e!ault 0ervi#e

Figure A.;. The sim le se@uence notification flo#.

- sa ple notification process, as illustrated in ?igure =.<, involves the client creating a sink ob,ect to receive notification. This sink ob,ect is i ple enting the Aotification3ink interface. The client discovers the available subscription t"pes supported b" the notification source b" the !uer" s"nta. find3ervice5ata 6B.tensibilit"T"pe subscribe4"3ervice5ataAa es7, where the e.tensibilit" t"pe contains the input essage as shown in the following 918 frag ent.

,isting A.1;. ' @uery by service data in ut message.

<ogsi:'-er($(6ervi%e1ata)ames>

<name>ogsi:s-3s%ri3eExtensi3ilit(</name> </ogsi:'-er($(6ervi%e1ata)ames>

The operation in 8isting =.1< a" result in an B.tensibilit"T"pe response with an 918 essage as shown in 8isting =.1=(

essage,

,isting A.1A. %ubscri tion e2 ressions.

<s":servi%e1ataCal-es> <ogsi:s-3s%ri3eExtensi3ilit( inp-tElement="ogsi:s-3s%ri3e$(6ervi%e1ata)ame"/> </s":servi%e1ataCal-es>

-s shown in 8isting =.1<, this service supports a )subscribe4"3ervice5ataAa e) subscription t"pe.

'u)scri)eB*'erviceData/ame 'u)scription
This subscription results in notification essages being sent whenever an" of the na ed service data ele ents change. This subscription results in essages being sent based on two i portant attributes of this subscription, in#nterval and a.#nterval. -s shown in this e.a ple, the ele ent values. essage sent contains all the service data

8et us now e.plore where the client calls the service to subscribe for the service data na e to pass the subscription e.pression of the t"pe )subscribe4"3ervice5ataAa e) with the associated interval properties and the G32 to where the essages ust deliver the value. The service receiving this )subscribe) operation initiates the following actions(

This subscription results in the creation of a subscription grid service. The service returns the locator for this subscription service.

/henever there is a service data change, and the criteria set for ini u and a.i u interval eets acceptance, the source delivers an 918 essage to the sink after for atting the essage based on the subscription criteria. ?inall", when the client operation is co pleted with the service, it can kill the subscriptions b" calling destro" on the subscription service. The behavior of this operation, such as re oving the subscription, is a service i ple entation specific.

0ervi#e Grouping Con#epts in .G0I The third set of portT"pes provides the grouping concepts for grid services. The grid services can be grouped based on certain classification sche es, or the" can utilize si ple aggregation echanis s. 3o e e.a ple of grouping includes(

3i ple registries or inde. services where there is no specific classification sche e but are aggregated collections of services for discover" purposes. - federated service group to solve so e specific proble s including weather prediction, distributed load balancing, service cluster, and so on.

Table =.: lists the *G3#-defined service group related to port t"pes, operations, and service data ele ents.

Table A.1. ortTy es That %u ort the "rid %ervice "rou ing 8ehavior, %ervice Data -lemen Data Galues
0ervi#e )ata 'lements )e!ined *( This portT(pe

PortT(pe ame 3erviceGroup 6optional7

Inter!a#e )es#ription and .perations

)e!ault 0ervi#e )at

-n abstract interface to represent a grouping of 1e bershipContent+ule Aone zero or ore services. entr" This interface e.tends the Grid3ervice portT"pe. *perations( Ao operations are defined but can use operations defined in a Grid3ervice portT"pe.

This interface e.tends the addB.tensibilit" 3erviceGroup+egistration 3erviceGroup interface and provides operations re oveB.tensibilit" 6optional7 to anage a 3erviceGroup including add'delete a service to'fro a group. *perations( 1. add $. re ove

Oogsi( re oveB.tensibil

inputBle entS) atch4" 'P

Table A.1. ortTy es That %u ort the "rid %ervice "rou ing 8ehavior, %ervice Data -lemen Data Galues
0ervi#e )ata 'lements )e!ined *( This portT(pe

PortT(pe ame 3erviceGroupBntr" 6optional7

Inter!a#e )es#ription and .perations

)e!ault 0ervi#e )at

This is a representation of an individual entr" of a e ber3ervice8ocator 3erviceGroup and is content created on 3erviceGroup+egistration )add.) Bach entr" contains a service locator to a e ber grid service, and infor ation about the e ber service as defined b" the service group e bership rule 6content7. *perations( Aone defined

The service group concepts introduced b" *G3# are useful to build registries for grid services. Table =.: lists the *G3#-defined interfaces associated with this grouping. 4ased upon the observation on *G3# interfaces, and their service data, there can be two t"pes of registries. These registries are locall" anaged registries and grid anaged registries. 8ocall" anaged registries are created for internal use inside a grid s"ste . These registries are derived fro serviceGroup portT"pe, and the registr" entries 6grid services7 are created at start-up. The entries are added through configuration or using custo -P#s. This grouping is )local) because no e.ternal grid operations are e.posed fro 3erviceGroup portT"pe. *ne t"pical use of such a registr" is for the creation of a registr" with a collection of service factories. Grid anaged registries are derived fro the 3erviceGroup+egistration portT"pe. This interface provides e.ternal operations to add and delete group entries into the registr". This portT"pe is derived fro 3erviceGroup, and hence provides a private registr" to hold the group contents. ?igure =.= illustrates this concept. The 3erviceGroup+egistrion is derived fro 3erviceGroup and the broken line indicates a logical operation.

Figure A.A. ' se@uence diagram sho#ing the service grou in action.

The best practice is applied for the registries to be e.ternall" anaged, to create a service group deriving fro 3erviceGroup+egistration, and for all other cases 6i.e., private, static, and internal7 to create registries derived fro 3erviceGroup. 8et us now e.plore the internal concepts introduced b" the service group, including e bership rules, service entries, and anage ent. 3em*ership 2ules !or a 0ervi#e Group 5eriving a service fro the 3erviceGroup portT"pe, and utilizing the )1e bershipContent+ule) service data for the classification echanis s can create a grouping concept si ilar to a registr". This )rule) 61e bershipContent+ule7 service data is used to restrict the e bership of a grid service in the group. This rule specifies the following(

- list of interfaces that the e ber grid services ust i ple ent. Xero or ore contents, identifiable through GAa e, that are needed to beco e a part of this group. The contents of GAa e are listed with the 3erviceGroupBntr" utilizing the )content) service data ele ent. This service data has a utabilit" value of )constant,) and hence these rules are created b" the runti e on 3erviceGroup service startup 6i.e., in ost of the cases7.

/hat follows is a sa ple rule definition with two rules(

,isting A.2C. ' service grou membershi rule sam le.

<mem3er6hip*ontent,-le> <mem3er/nter#a%e> %rm:Nperating6(stemOa%tor( </mem3er/nter#a%e> <%ontent> ogsi:*reate6ervi%eExtensi3ilit(5(pe

</%ontent> </mem3er6hip*ontent,-le> < mem3er6hip*ontent,-le> <mem3er/nter#a%e> %rm:Nperating6(stem<mem3er/nter#a%e> <%ontent> ogsi:*reate6ervi%eExtensi3ilit(5(pe </%ontent> </mem3er6hip*ontent,-le>

4ased upon the above rules, this service group contains grid services that i ple ent either *perating3"ste ?actor" or *perating3"ste interfaces. #n addition, the above rules specif" a content rule, which states that the corresponding 3erviceGroupBntr", created for each service in the group, ust define the content with GAa e )ogsi(Create3erviceB.tensibilit"T"pe.) /e will later e.plore this content infor ation. The specific as to e.actl" how this rule is validated is an i ple entation decision. ?or e.a ple, using runti e t"pe checking on the service can test the interface validit". 0ervi#e 'ntries in a 0ervi#e Group -nother ver" i portant construct in the registr" is the storage for the collection of services. The 3erviceGroup provides a service data ele ent called )entr",) which provides a structure for the constituent e bers of the 3erviceGroup. Bach of these 35B values contains(

- locator pointer to the serviceGroupBntr" grid service instance that anages the constituent grid service instanceMa pro." to the real service instance - locator pointer to the e ber grid service instance The contents of the entr"

-n e.a ple of such an entr" is shown in 8isting =.$1.

,isting A.21. ' %ervice"rou -ntry sam le.

<ogsi:Entr(5(pe> <servi%e8ro-pEntr(Lo%ator> <ogsi:han"le> http://lo%alhost/ogsi/6ervi%e8ro-pEntr(/osEntr(

</ogsi:han"le> </servi%e8ro-pEntr(Lo%ator> <mem3er6ervi%eLo%ator> <ogsi:han"le> http://lo%alhost/ogsi/%rm/Nperating6(stemOa%tor( </ogsi:han"le> </mem3er6ervi%eLo%ator> <%ontent> <ogsi:*reate6ervi%eExtensi3ilit(5(pe> <%reates/nter#a%e>Nperating6(stemOa%tor(</%reates/nter#a%e> </ogsi:*reate6ervi%eExtensi3ilit(5(pe> </%ontent> </ogsi:Entr(5(pe>

0ervi#eGroup'ntr( This portT"pe defines the interface through which the individual entries in 3erviceGroup can be effectivel" anaged. Bver" service in the group contains a corresponding 3erviceGroupBntr" instance. #n fact, this can be treated as a )pro.") of a sort to the service instance. #n the @18 diagra shown earlier, a service client using a 3erviceGroup+egistration service creates this pro.", and then adds the pro." to the 3erviceGroup collection. " 0imple 2egistr( 7tilizing the .G0I 0ervi#e Group Con#epts 8et us now e.plore how a si ple private registr" holds factories responsible for the creation of grid services in a container. This is a locall" anaged registr" for the factories of the services running in a container. -n e.a ple is si pl" constructed, based upon the *perating3"ste ?actor" service, which is responsible for *perating3"ste creation. This registr" i ple ents the 3erviceGroup portT"pe. The eta-data in the registr" co es fro ogsi(?actor" portT"pe, where the service data specifies all the services that a factor" can create. The following discussion is focused on creating this grouping service. 3ince ost of the eta-data for the factor" registr" is well defined and !uite static in nature, the data can be defined in a G/358 description as static service data values.

,isting A.22. ' service grou containing grid service factories.

<gws"l:port5(pe name="#a%tor(6ervi%e8ro-p" exten"s="6ervi%e8ro-p"/>

<s":stati%6ervi%e1ataCal-es> <ogsi:Entr(5(pe> <servi%e8ro-pEntr(Lo%ator nil="tr-e"/> <mem3er6ervi%eLo%ator> <ogsi:han"le> http://lo%alhost/ogsi/%rm/Nperating6(stemOa%tor( </ogsi:han"le> </mem3er6ervi%eLo%ator> <%ontent> <ogsi:*reate6ervi%eExtensi3ilit(5(pe> <%reates/nter#a%e>Nperating6(stem</%reates/nter#a%e> <%reates/nter#a%e>8ri"6ervi%e</%reates/nter#a%e> </ogsi:*reate6ervi%eExtensi3ilit(5(pe> </%ontent> </ogsi:Entr(5(pe>

<ogsi:Entr(5(pe> <servi%e8ro-pEntr(Lo%ator nil="tr-e"/> <mem3er6ervi%eLo%ator> <ogsi:han"le> http://lo%alhost/ogsi/poli%(/4oli%(En#or%ementOa%tor( </ogsi:han"le> </mem3er6ervi%eLo%ator> <%ontent> <ogsi:*reate6ervi%eExtensi3ilit(5(pe> <%reates/nter#a%e>4oli%(6ervi%e</%reates/nter#a%e> <%reates/nter#a%e>8ri"6ervi%e</%reates/nter#a%e> </ogsi:*reate6ervi%eExtensi3ilit(5(pe> </%ontent> </ogsi:Entr(5(pe>

<s":stati%6ervi%e1ataCal-es>

The i portant infor ation we can derive fro

the above listing is(

3ince these services are anaged locall", the serviceGroupBntr"8ocator is not utilized. The e ber8ocator rule provides the handle to the factor" instance, where we have two factories registered with this registr". The content rule states what t"pe of services each factor" can create. These services ust confor to the interfaces identified in the logic.

This registr", upon startup, loads this infor ation and updates 3erviceGroup0s ) e bership-+ules) and )entr") service data fields. The client can utilize the standard grid service calls to discover the factor" instances that can be utilized for creating the )operating s"ste ) services. The client can !uer" the registr" for all the 3erviceGroup entries using the )find3ervice5ata) operation, and passing the !uer" e.pression as shown in 8isting =.$%.

,isting A.23. ' @uery to the registry.

<ogsi:'-er($(6ervi%e1ata)ames> <name> ogsi:entr( </name> <ogsi:'-er($(6ervi%e1ata)ames>

The preceding !uer"

a" result in the following result(

,isting A.2!. %ervice grou @uery results.

<s":servi%e1ataCal-es> <ogsi:Entr(5(pe> <servi%e8ro-pEntr(Lo%ator nil="tr-e"/> <mem3er6ervi%eLo%ator> <ogsi:han"le> http://lo%alhost/ogsi/%rm/Nperating6(stemOa%tor( </ogsi:han"le> </mem3er6ervi%eLo%ator> <%ontent> <ogsi:*reate6ervi%eExtensi3ilit(5(pe>

<%reates/nter#a%e>Nperating6(stem</%reates/nter#a%e> <%reates/nter#a%e>8ri"6ervi%e</%reates/nter#a%e> </ogsi:*reate6ervi%eExtensi3ilit(5(pe> </%ontent> </ogsi:Entr(5(pe> </s":servi%e1ataCal-es>

The clients can now run an 9Path !uer" on the above results to find out the factor" that can be used to create an )*perating3"ste ) service using the 9Path e.pression in the following logic( ''ogsi(Bntr"T"peIcontent'ogsi(Create3erviceB.tensibilit"T"pe'create#nstanceS)*pera ting3"ste )J. This results in a list of Bntr"T"pes that will create an operating s"ste service. -gain, to obtain the specific handle to the factor" e.ecution, this 9Path !uer" is( ''ogsi(handle. The client can utilize this G32 to the factor", obtained b" e.ecution of the above step, in order to create the operating s"ste service. /e can now reduce the nu ber of client-side 9Path operations if the service supports a !uer" b" the 9Path )operationB.tensibilit") t"pe. #n these cases, the client can issue the )find3ervice5ata) call with the 9Path infor ation, and can then directl" obtain the factor" handle. Grid 0ervi#es and Client Programming 3odels -s presented in previous discussions, the details surrounding the concepts of *G3# are rich and robust across several di ensions. 8et us now focus on e.actl" how to define the client-side progra ing patterns that interact with an *G3#-defined grid service. Barlier discussions were focused on how the *G3# is based upon /eb services concepts, and how the core direction of this standardization process is on the interoperabilit" between grid services and /eb services. This interoperabilit" can be achieved b" using the *G3# standards-driven 918 essages and the e.change patterns. The *G3# is not defining a new progra ing odel, rather the *G3# is grounding itself upon the e.isting /eb service progra ing odel. -t the sa e ti e, the *G3- provides so e standard interaction pattern including conversion of the G32 to the G3+. The grid services are uni!uel" identified b" the G32. - client should convert the G32 6i.e., a per anent network-wide pointer7 to a G3+ prior to accessing the services. The G32 does not conve" tre endous a ounts of infor ationF instead, the

G32 provides the identit" of a service. *nce the client retains a G3+, it can access the service. There are two t"pes of clients( 3tatic. These kinds of clients have pluralit" of a priori knowledge on the runti e binding infor ation. This includes aspects of native host s"ste essage apping capabilities, the language aps, t"pes for arshalling'de- arshalling of essages, creation of service helpers, and pro.ies. Aor all" speaking, the client uses the /358'G/358 infor ation to create these artifacts. These kinds of clients are faster, "et less fle.ible in operations. -n" change in service description re!uires the recreation of the above artifacts. 5"na ic. These t"pes of clients are fle.ible and the" are not bound to an" predefined artifacts. The" start fro the service description discover" and runti e creation of interaction artifacts, including binding and t"pe- apping infor ation. These t"pes of clients are highl" fle.ible, "et a" perfor with less efficiencies. The locator helper class, as defined b" *G3#, provides an abstraction for the service binding process and handle resolution process. 1ost of the grid toolkits toda" a" generate this artifact to help the client deal with G32s, G3+s, and interactions between the two entities. The client fra ework is, in theor", si ple, as illustrated in ?igure =.1>.

Figure A.1C. The client-side frame#ork.

The client alwa"s needs to be aware of the G/358 e.tension, and should rel" on the tools for the transfor ation of G/358 portT"pes to /358 portT"pes for si plified aspects involving interoperabilit" with e.isting /358 1.1 tools and fra eworks. #n the ne.t section, we introduce specific i ple entations of the client-side artifacts fro the perspectives of different grid toolkits. Grid 0ervi#es and 0ervi#e Programming 3odel The *G3# specification does not dictate particular service i ple entation architectures. There are nu erous wa"s b" which a developer can achieve this

architectural environ ent, ranging fro i ple enting grid services as operating s"ste services, to the ore sophisticated server-side co ponent odel as specified b" C$BB or C*1Y. The *G3# services can be hosted in the s aller footprint pervasive devices, all the wa" up to the ore sophisticated ainfra e environ ents. - grid services i ple entation can provide host service protocol ter ination, and service behaviors, in the sa e e.ecutable or operating s"ste service environ ents. ?igure =.11 shows an application providing protocol ter ination and the grid service i ple entation.

Figure A.11. ' sim le grid service im lemented as an a

lication.

Grid services can be i ple ented as co ponents 6e.g., 3ervlets, BC4, etc.7 that can be hosted in a container, and the container along with the host environ ent provides the service protocol ter ination points and arshalling and de- arshalling of the essages. #n this scenario, there a" be re!uire ents to adapt to the container behaviors and the odels. ?or e.a ple, if a service is i ple enting itself as an BC4, the service lifec"cle a" need to be coherent with the BC4 lifec"cle odel. 1ost of the grid toolkits tend to use this odel for their iddleware i ple entation. ?igure =.1$ shows such a service i ple ented in C$BB /eb containers.

Figure A.12. ' container model for a service im lementation.

3o e of the ke" core service i ple entation re!uire ents are as follows(

-bilit" to provide a well-defined service description in G/358'/358 -dhere to the 918 essage for ats, as defined in the service description based on the *G3# specification

8everage the /eb service infrastructure 6and standards7 for achieving essage-level interoperabilit"

0ummar(
The *G3# specification successfull" addresses a nu ber of ver" i portant issues associated with distributed s"ste s 6i.e., lifec"cle, na ing, references, and state anage ent7. -t the sa e ti e, so e incoherence e.ists when the specification adopts so e of the /eb services concepts( instance addressing, stateful services concepts 6i.e., referencing and state representation7, and /eb services best practices guidelines 6e.g., the docu ent-centric view7. These issues can be sorted out with the e ergence of stateful /eb services and correlations, in addition to the aturit" of /3--ddressing and related specifications. The *G3# specification handles an" ke" grid services re!uired behaviors, it is e.tensible, and it achieves a.i u interoperabilit" across service i ple entations. 3everal software fra eworks available toda" are based on the *G3# specification. The Globus GT% is the ost pro inent and practical i ple entation of this specification. #n a later chapter, we will e.plore in great detail e.actl" how the Globus Grid Toolkit and other iddleware providers have i ple ented the *G3# specifications.

Common 3anagement 3odel 4C335

The *pen Grid 3"ste -rchitecture 6*G3-7 Co on 1anage ent 1odelI1J 6C117 is an abstract representation of real #T resources such as disks, file s"ste s, operating s"ste s, network ports, and #P addresses. The C11 can also be an abstract representation of logical #T resources, which can be a co position of the ph"sical #T resources to build services and co plete business applications. 3o e of the ost i portant and co onl" utilized ter s in the anage ent of resources are ) anageable resource,) ) anageabilit",) and resource ) anage ent.)

4e* "erms to -nderstand

1anageable resource is an" #T entit" that has so e state to which the anage ent operations can be applied. - anageable resource can be an" entit", hardware 6hard drives7, software co ponents 6a database7, co plete applications 6help desk s"ste 7, and even transient things such as print ,obs. 1anageabilit" is a concept whereb" a resource defines infor ation that can be utilized to anage the resource. 1anageabilit" details all the aspects of a resource that support anage ent, including interaction with a resource fro the anage ent applications. 1anage ent is the process of onitoring, odif"ing, and aking decisions about a resource, including the capabilities that use anageabilit" infor ation, to perfor activities or tasks associated with anaging #T resources.

The C11 is a )single) odel for anage ent that can be utilized with, and e.tended for, ultiple grid resource odelsF however, it does not define a resource infor ation odel 6e.g., C#1, 3A1P, C197, which is the ,ob of the other standards organizations 6e.g., 51T?, CCP7. The C11 defines a set of co on anage ent interfaces b" which these anageable resources are e.posed to the e.ternal anage ent applications for the sole purposes of anaging these resources. #n C11, ever" anage ent resource is represented as a grid service instance that possesses a state, a uni!ue instance identifier, and operational interfaces. ?igure 1>.1 depicts the grid services facade.

Figure 1C.1. The manageable resource grid services facade.

?igure 1>.1 shows a anageable resource and its facade grid service that provides C11-specific anageabilit" interfaces and do ain-specific interfaces. *ne ust be certain on the difference between anageabilit" interfaces and do ain-specific interfaces. 3anagea*ilit( Inter!a#es Bver" resource represented b" C11 has a grid service facade that represents the underl"ing resource, and e.poses a set of canonical interfaces and behaviors co on

to all the C11 services. This grid service has a state that corresponds to the resource state and a anaged lifec"cle odel. )omain60pe#i!i# Inter!a#es Bver" C11 resource e.poses a nu ber of do ain-specific interfaces, in addition to the canonical anageabilit" interfaces for its anage ent applications. These do ain-specific interfaces are tightl" coupled to the do ain in which these resources are defined. -s an e.a ple, we can consider the case of a resource instru ented in C#1. This resource e.poses a standard C11 anageabilit" interface and, in addition, e.poses so e C#1-specific interfaces 6e.g., a C#1 *perating 3"ste interface7 to deal with the resources. These interfaces provide access to the resources but do not represent the C11- anaged resource behavior. The *G3- C11 specification defines three aspects of anageabilit"( anageabilit" infor ation

1. -n 918 sche a 69357 for odeling the resource $. - collection of anageabilit" portT"pes %. Guidelines for odeling resource

ew Constru#ts !or 2esour#e 3odeling - resource0s anageabilit" infor ation is odeled using the 918 sche a. C11defined e.tensions and additional data t"pes 6i.e., 918 attributes7 allow those anageable resources to provide additional infor ation to the anage ent applications. #n order to better capture the data, C11 defined the following new data t"pes( counter and gauge. #n addition to these data t"pes, C11 defined 918 attributes that are classified as(

Kersioning related o Kersion

o o

5eprecated B.peri ental

@nit related
o

@nits

8ifec"cle characteristics
o o o

Kalid Changeable Kolatile

8atenc" on anage ent odel.

8et us now e.a ine the core port t"pes e.posed b" the co C336)e!ined 3anagea*ilit( Inter!a#es

The C11-defined anageabilit" interfaces are the /358 portT"pes that are defined as part of the anage ent interfaces of a anageable resource. /e can see that C11 is tr"ing to factor out the co on set of interfaces that can function against all the resources. These interfaces are called )canonical port t"pes) that provide a consistent behavior and functionalit" to the anage ent applications 6?igure 1>.$7.

Figure 1C.2. $(( manageability ort ty es.

There are two ost i portant canonical port t"pes defined for C11. -s we have previousl" seen in the *G3# specification, the Grid3ervice port t"pe is the core interface and is present in all grid services, and it provides a set of co on behaviors and operations. The other interface defined b" C11 is the 4ase1anageablePortT"pe. This contains co on behaviors 6e.g., service data7 that ust be i ple ented b" all anageable resources. The behaviors represented b" this port t"pe include resource lifec"cle data, relationships to other resource t"pes and data, searchable resource properties, and resource groups to which this resource instance belongs within the respective environ ent. #n addition to these standard canonical port t"pes, a C11 resource can utilize other grid service port t"pes as defined b" the *G3# specification. *ne co onl" utilized port t"pe is service groupF it is utilized to represent a grouping and collection behavior for a certain group of resources, or for enu eration of resources of the sa e t"pes. 2esour#e 3odeling Con#epts The pri ar" co ponents of the Co on 1anage ent 1odel are data t"pes 6i.e., e.isting and new7, additional 918 attributes, service data, and their associated service data descriptions and port t"pes.

#n general, a resource t"pe is represented as a port t"pe, the anaged properties of the resource are represented as service data of the port t"pe, and ethods on the resource are port t"pe operations. 8et us now e.plore an i portant odeling concept of the C11 service co position, and how it odels the granular resource odels. The resources defined using C11 are generall" coarse-grained services rather than granular or nor alized resource odel definitions. #n other words, the service is self-contained with nor alized resource odels, and contains a few relationships to other services. /e further e.plore this concept b" using the case of a disk resource that has a odel for anageabilit" containing characteristics of the disk, a odel for a set of error statistics, a odel for its disk etrics, and a relationship odel to a co puting s"ste resource. /hen we set forth to odel this as a C11 service, all these behaviors are aggregated into the serviceF a C11 service is co posed of anageabilit" characteristics, error statistics, and etric odels. #n addition to this notion, all of this e.presses a contain ent relationship to a co puter s"ste . 8et us now e.plore further to better understand so e of the core concepts defined in the C11 specification. These concepts are as follows(

3ervice data and resource properties. Properties of a anageable resource are e.pressed as service data and grid service port t"pe operations. )find3ervice5ata) and )set3ervice5ata) can be utilized to access and odif" these properties. 4ase anage ent port t"pe and its behavior. This 64ase1anageable+esource7 canonical port t"pe contains service data ele ents that ust be i ple ented b" all anageable resources. This port t"pe e.tends the *G3# Grid3ervice port t"pe and adds service data that has valuable infor ation about a anageable resource. Table 1>.1 lists the co on service data ele ents of this port t"pe.

Table 1C.1. %ervice Data -lements in 8ase (anagement ortTy e

0ervi#e )ata ame lifeC"cle1odel )es#ription 5escribes the states of the resource and'or substates through which the resource will transition. These are static service data values, which we will further e.plore later in )C11 +esource 8ifec"cle odel.)

current8ifeC"cle3tat The current state of the resource and substate infor ation, e which we will further e.plore later in )C11 +esource 8ifec"cle odel.) serviceGroupT"pe The portT"pe of the anageable resource that provides the service group function for anageable resource of this t"pe.

Table 1C.1. %ervice Data -lements in 8ase (anagement ortTy e

0ervi#e )ata ame )es#ription This static value is set in /358 and ust present onl" with the pri ar" ape.-derived port t"pe in the hierarch". This helps to )locate) a service group that holds these resource instances. searchPropert" Xero 6or ore7 service data ele ents 6i.e., properties7 that are utilized for searching for a anageable resource. - service can use these values for caching and for searching. These are static service data values. B.presses the relationship between anage ent resources )instance,) which we will further e.plore in the )+elationship and 5ependenc") section. B.presses the relationship between anage ent resources )t"pe,) which we will further e.plore in the )+elationship and 5ependenc") section.

related#nstance

relatedT"pe

-s previousl" discussed, these service data values are accessed b" the grid service port t"pe0s )find3ervice5ata) and )set3ervice5ata) operations. The )related#nstance) service data is the onl" service data value in the 4ase1anageable+esource port t"pe that is utable, and hence, the set3ervice5ata operation is applicable to that service data for adding new related instances to the current resource instance. 2esour#e /i!e#(#le 3odeling ?or purposes of this discussion, a lifec"cle is a set of states that a resource can sustain, including the valid transitions between those states. #n C11, this lifec"cle is represented b" the lifec"cle odel service data of the base anage ent port t"pe. This is the ost co ple. odeling process in the C11F the resource e.ists fro the ti e the" are created until the" are destro"ed, and the" transition through a variet" of states in between these two states. This co ple.it" forces C11 to co e up with a reco endable and generic lifec"cle odel for all the resources. 8et us now e.plore this lifec"cle odel reco ended b" the C11. #t is i portant to understand that this is not the onl" possible odel based on the resource co ple.it", lifec"cle states, and transition logicF there a" be other lifec"cle odels. This lifec"cle odel is different fro a grid service lifec"cle odel, and there is no effort 6as of toda"7 to erge these odels together. 8et us now e.plore the proposed lifec"cle odel.

4ased on the proposed C11 co on lifec"cle odel, there are five possible lifec"cle states for a resource and the proposed operational state of that resource. These are noted as follows(

5own #n this state, a resource is created but cannot do useful work until it is up. *perational states are(
o o

+estartable( This resource is stopped but can be restarted. +ecovered( This resource is down but can be restarted.

3tarting This is a transient state indicating that the resource is starting and the ne.t state a" be either up or failed. *perational states are(
o o

*E( The resource is e.pected to attain the up state soon. Brror( The resource is e.pected to attain the failed state soon.

@p #n this state, the resource is available and read" to perfor *perational states are(
o o o

the work.

#dle( The resource is read" but is now not processing an" ,ob. 4us"( The resource is read" but is bus" with another ,ob. 5egraded( The resource is read" but is in a degraded condition where we cannot eet the e.pected !ualit" of service re!uire ents.

3topping This is a transient state where the resource is in the process of stopping. The ne.t state a" likel" be either ?ailed or 5own. *perational states are(
o o

*E( The resource is e.pected to attain the down state soon. Brror( The resource is e.pected to attain the failed state soon.

?ailed #n this state, the resource is not available e.cept for proble deter ination.

*perational states are(

o

dependenc"?ailure( This resource cannot be restarted because of the loss of a supporting'hosting resource. non+ecoverableBrror( This resource is not capable of being restarted because of critical errors.

4ased upon the above observations and conditions of the resource state, the following artifacts are defined b" the C11(

-n 935 that describes the structure of the lifec"cle state ele ent - service data ele ent that defines the lifec"cle odel utilized b" a resource - service data ele ent that holds the current lifec"cle value of a resource The 918 attributes that describe the lifec"cle characteristics of a service, including changeabilit", validit", volatilit", and latenc". These values are critical for anage ent applications. odel t"pe as defined b" the

The following 935 68isting 1>.17 describes the lifec"cle C11(

,isting 1C.1. The schema definition for a lifecycle model.

<xs":%omplex5(pe name="li#e%(%le;o"el5(pe"> <xs":se'-en%e> <xs":element re#="%rm:li#e%(%le6tate" minN%%-rs="1" maxN%%-rs="-n3o-n"e""/> </xs":se'-en%e> </xs":%omplex5(pe> <xs":element name="li#e%(%le6tate" t(pe="%rm:li#e%(%le6tate5(pe"/>

<xs":%omplex5(pe name="li#e%(%le6tate5(pe"> <xs":se'-en%e> <xs":element name="s-36tate" minN%%-rs="0" maxN%%-rs="-n3o-n"e""> <xs":%omplex5(pe> <xs":attri3-te name="name" t(pe="xs":)*)ame"/> </xs":%omplex5(pe> </xs":element>

</xs":se'-en%e> <xs":attri3-te name="name" t(pe="xs":)*)ame"/> </xs":%omplex5(pe>

The G/358 port t"pe defines the service data description for a lifec"cle shown in 8isting 1>.$.

odel, as

,isting 1C.2. The service data definition for a lifecycle model.

<s":servi%e1ata name="li#e%(%le;o"el" t(pe="%rm:li#e%(%le;o"el5(pe" minN%%-rs="1" maxN%%-rs="1" nilla3le="tr-e" m-ta3ilit(="stati%"/>

-s one will notice b" observing the above constructs, this lifec"cle odel for service data is static, and hence, the G/358 constructs contain the possible values of this service data description in the Ostatic3ervice5ataKaluesP section of G/358 portT"pe. - co onl" utilized lifec"cle value and its substates for the lifec"cle data are described in 8isting 1>.%. odel service

,isting 1C.3. The static service data values.

<s":stati%6ervi%e1ataCal-es> <%rm:li#e%(%le;o"el> <li#e%(%le6tate name=""own"> <s-36tate name="restarta3le"/> <s-36tate name="re%overe""/> </li#e%(%le6tate> <li#e%(%le6tate name="starting"> <s-36tate name="N7"/> <s-36tate name="error"/> </li#e%(%le6tate> <li#e%(%le6tate name="-p">

<s-36tate name="i"le"/> <s-36tate name="3-s("/> <s-36tate name=""egra"e""/> </li#e%(%le6tate> <li#e%(%le6tate name="stopping"> <s-36tate name="N7"/> <s-36tate name="error"/> </li#e%(%le6tate> <li#e%(%le6tate name="#aile""> <s-36tate name=""epen"en%(Oail-re"/> <s-36tate name="nonre%overa3leError"/> </li#e%(%le6tate> </%rm:li#e%(%le;o"el> </s":stati%6ervi%e1ataCal-es>

This concludes our introduction to the resource lifec"cle odeling. #t should be noted that based on what has been previousl" discussed, the lifec"cle odel is a generalpurpose lifec"cle odel, and we a" need to also deal with new lifec"cle state odels for C11. 2esour#e Grouping Con#epts in C33 The anage ent applications need to locate anageable resources in the s"ste . This anageable resource collection size a" var" depending on the s"ste and the environ ent. There is a proble of locating fine-grained resources in the s"ste , as nor al )registries) are not sophisticated enough to retain that uch infor ation. The service do ain concept, which we will cover later in this book, will address this proble of service location with a federation of infor ation across registries. 2owever, it is still not sufficient to address the fine-grained resource proble . The C11 works to resolve this fine-grained resource proble b" utilizing the natural grouping of resource concepts that e.ist in the s"ste . To appropriatel" e.plain this natural grouping, based on resource t"pes, we can consider the sa ple of a database server hosting so e databases, and these databases in turn contain the tables. /e can also infer that these containers are responsible for the anage ent of the resources that it contains. The C11 container resource and the contained resource for a resource group. The C11 then uses the 3ervice Group concept in the *G3# for anaging these resources. Bver" anageable resource defined b" C11 ust i ple ent the 4ase1anageable+esource port t"pe. -s we have previousl" discussed, it is possible

that a resource can be a container, which holds the sa e t"pe of resources instance, in addition to the regular anage ent port t"pe. This use case is e.plained in ?igure 1>.%.

Figure 1C.3. -2am le of a manageable ort ty e.

#n this e.a ple, the database, the table, and the database server are anageable resourcesF however, the database server has ore functionalit" and acts as a container 6i.e., i ple enting *G3# 3erviceGroup7 for the resources belonging to that server. 2elationship and )ependen#( among 2esour#es There a" oftenti es be relationships e.isting a ong an" instances of anageable resources. This relationship odel is not specific to the C11F the service relationships e.ist in the grid and /eb service environ ents. 8et us take a look at these ideas in order to better fa iliarize ourselves with the two core concepts here( 1. +elationships describe which resources are connected to each other and what t"pe of connection e.istsF however, the" do not describe the details of how one resource depends on the other. $. 5ependencies add additional infor ation to the relationship on e.actl" how one resource depends on another. ?or e.a ple, a database resource indicates that it uses a storage device and provides ore details on the needs such as storage space. /e will begin our discussion on the C11 relationship odel with a si ple e.a ple on relationships. Processes are created b" operating s"ste and the operating s"ste

is hosted b" the co puter s"ste , which is a part of a cluster. C11 provides echanis s to odel these t"pes of resource relationships 6see Table 1>.$7. #n C11, the 4ase1anageable+esource port t"pe provides two service data definitions 6related#nstance and relatedT"pe7 to deal with a relationship.

Table 1C.2. $((-defined relationshi ty es.

2elationship T(pe 2osts )es#ription

-n" resource )-) hosts another resource )4) if resource )-) provides an environ ent in which resource )4) is created and runs. The lifec"cle of resource )4) is a subset of the lifec"cle of resource )-) and resource )4) cannot e.ist without resource )-.) ?or e.a ple, a database hosts the table within it. -n" resource a" consist of a nu ber of other resources. -n" contained resource has the sa e lifeti e as the containing resource. #f resource )-) contains resource )4,) then if )-) installs )-,) )4) gets installed and if )-) stopped )4) gets stopped. ?or e.a ple, a deplo"ed C$BB application containing various odules. -n" nu bers of resources are in different hosting environ ents and are utilized together to for another resource. ?or e.a ple, an application includes a database and !ueue and the" do not know each other but work together in the application. - nu ber of resources are grouped together. ?or e.a ple, a resource that represents all co puters in a depart ent. - resource uses another resource. #t is different fro federates. ?or e.a ple, a securit" s"ste uses a 85-P registr" to hold user infor ation. *ne resource is utilized to i ple ent the function of another. ?or e.a ple, a database server is i ple ented as a 8inu. or /indows service.

Contains

?ederates

-ggregates

@ses

# ple ents

These t"pes of relationships e.ist in current progra ing environ ents and are e.plained !uite well b" the @18 relationship odel and dependenc" graphs. /e believe that this C11-specific relationship odel should be elevated to the grid service and /eb service worlds, with the appropriate odifications.

/e have now discussed the new concepts and canonical infor ation provided b" C11. The resource0s anageabilit" infor ation can be i ple ented using an" of the e.isting anage ent instru entation ethods, such as Co on #nfor ation 1odel 6C#17, 3i ple Aetwork 1anage ent Protocol 63A1P7, and 8ightweight 5irector" -ccess Protocol 685-P7. The C11 resource odel and anage ent grid service are independent of the underl"ing service i ple entation and resource instru entation. *ne i portant !uestion that a" co e across is( /hat is the value C11 provides over a nor al service interface to an" e.isting resource instru entation odelsL The answer lies in the fact that C11 is not ,ust an algorith ic apping fro a grid service to resource instru entation. #nstead, C11 contains a ore behavior-specific and self-contained resource anage ent odel. -lso, the sa e resource odel a" ap to ultiple instru entation choices, and this is a binding choice. 0ummar( /e can su arize the C11 discussion with the characteristics it e.poses to the resource anage ent world. These characteristics are as follows(

C11 provides an abstract representation of the real-world ph"sical resource or logical resources. C11 provides co on anageabilit" operations. C11 can overla" ultiple resource instru entations.

+esources are now grid services containing four capabilities. 1. Co $. Co %. Co &. Co on lifec"cle anage ent

on resource discover" on event notification on resource attribute !uer"

C11 provides well-defined resource states. ature are as follows( odels into the C11 base

Two areas where the architecture needs to

Provisions to plug in new lifec"cle Blevating the relationship level architecture

odel presence in C11 to the core grid service

0ervi#e )omains
The *G3- service do ain architectureI$J proposes a high-level abstraction odel to describe the co on behaviors, attributes, operations, and interfaces to allow a collection of services to function as a single unit. This is acco plished through

collaboration with others in a full" distributed, heterogeneous, grid-enabled environ ent. This provides the users of an" service do ain access environ ent to be aggregated into the appropriate services operations, si pl", as if the" are erel" a part of a single service. #n general, the services in a service do ain can be thought of as the following(

+esource oriented, including CP@, storage space, and network bandwidth 3"ste s and infrastructure oriented, including securit", routing, and anage ent -pplication-oriented services such as purchase orders, stock transactions, insurance, etc.

These do ains can be ho ogeneous or heterogeneous, co pute intensive, transactional, and business process function providers. 1ultiple service do ains can be co posed and i.ed for the re!uire ent of the enterprise. -s depicted in ?igure 1>.&, service do ain co ponents provide the following functionalities(

3ervice registration and collection 3ervice routing and selection 3ervice interoperation and transfor ation ?le.ible service co position -uto atic service orchestration

Figure 1C.!. The service domain and orchestration.

4ased upon this discussion, we can see that the *G3- architecture for service do ain defines an *G3# 3erviceCollection port t"pe and provides functionalities for register 6add7 and unregister 6re ove7 service instances fro the service do ain. The core concept of service do ain surrounds these interfaces and behaviors that it e.poses.

8et us now further e.plore so e of these behaviors and interfaces. These behaviors can be thought of as(

?ilter( 3upports choosing'selecting a service instance as part of a service collection. 3election( Bnables choosing a particular service instance as part of the service collection. Topolog"( -llows a service collection to i pose so e topological order for the instances of the services. Bnu eration( Bnu erates the services in a service do ain and'or across other service do ains. 5iscover"( -llows a service do ain to discover services fro one or ore registries and'or other service do ains. These discovered services are included as part of their collection. Polic"( Provides so e )intelligence) on the service do ain operations. These t"pes of polic" rules include 6but are not li ited to7 service-level definitions, recover", event handling, discover"'selection, service apping, and business guidelines.

0ummar( -s of toda", there is no standard or architecture-driven process for efficient building block co ponents that enable grid services and /eb services to be organized, filtered, deplo"ed, grouped, discovered, dispatched, recovered, and opti ized d"na icall" in real ti e. This *G3--driven service do ain concept addresses these shortco ings b" providing a service collection odel that includes the do ain sche a, attributes, and operations to control the behaviors of service registration, auto atic service routing, heterogeneous service interoperabilit", polic" rule-based operations, d"na ic service sharing, and aggregation of the collections

Poli#( "r#hite#ture
The definition of the ter )polic") is often confusing and conte.tual. #n the conte.t of the *G3-, we can define )polic") as a definitive goal, course, or ethod of action based on a set of conditions to guide and deter ine present and future decisions. Policies are i ple ented and utilized in a particular conte.t. ?or e.a ple, there are policies for securit", workload, networking services, business processes, and a ultitude of other areas. #n the conte.t of grid services, the *G3- polic" service provides a set of rules or policies to ad inister, anage, and control access to an" grid service. The *G3--defined polic" service provides a fra ework for creating, anaging, validating, distributing, transfor ing, resolving, and enforcing policies in a distributed grid environ ent. The *G3- polic" work uses a derivative of the #BT?I%J'51T?I&J Polic" Core #nfor ation 1odel 6#BT? +?C %>:> '51T? 53P>1><7 as its infor ation odel. 4" getting polished b" the resource anage ent tea s

across the industr", these policies are naturall" ost suitable for #T resource anage ent. *G3- policies are based on an 918 sche a, which is a derivative of the C#1 Polic" Core #nfor ation 1odel B.tension 6PC#1e7 and is suitable for ost of the known polic" representations. The @18 diagra , in ?igure 1>.5, e.plains the polic" infor ation odel.

Figure 1C.0. The D(TF:+-TF 7olicy +nformation (odel.

$olic* Management Is 'imple in Concept, *et Incredi)l* Important

The definition of the ter )polic") is often a biguous and rather conte.tual. #n the conte.t of the *G3-, we can define )polic") as a definitive goal, course, or ethod of action based on a set of conditions to guide and deter ine present and future decisions. This, in part, affords autono ic decision support aspects in Grid Co puting solutions. Policies are i ple ented and utilized in a particular conte.t. ?or e.a ple, there are policies for securit", workload, networking services, business processes, and a ultitude of other areas. #n the conte.t of grid services, the *G3- polic" service provides a set of rules or policies to ad inister, anage, and control access to an" grid service.

The *G3- polic" odel is a collection of rules based on conditions and actions. #n general, policies are e.pressed as )if OconditionP then OactionP) rule-t"pe of s"nta.. #n addition to the polic" sche a definition, it provides classification and grouping of rules and scope of policies, based upon the anage ent discipline and rules. -nother i portant aspect is the support for notification on polic" state changes, whereb" a client is notified of the policies when it beco es effective, e.pired, or updated. The following shows sa ple policies that are in the conte.t of this discussion(

Go3 polic" e.a ple( #f 6custo ers are )e.ecutives)7 then 6provide a )gold) Ialwa"s availableJ level service7

/orkload polic" e.a ple( #f 6toda" is the Govern ent ta. return last/eek7 then 6allocate 1>,>>> ore servers fro server pool to ?ar 1, ?ar $ to provide better response ti e7 #f 6toda" is the Govern ent ta. return last5a"7 then 6allocate $5,>>> ore servers fro server pool to ?ar 1, ?ar $, ?ar % to provide better response ti e7

/evels o! Poli#( "*stra#tion The ultiple levels of polic" abstraction helps the polic" service to differentiate the roles of the polic" actors 6i.e., polic" ad inistrators who are responsible for polic" creation and aintaining7, polic" enforce ent points 6i.e., the consu er of policies7, and polic" transfor ation re!uire ents. -s illustrated in ?igure 1>.:, these levels of abstraction are business level, do ain level, and device level. The policies are created as high-level business definitions, such as 38-, event anage ent, and are then translated to a canonical for as prescribed b" the *G3- polic" fra ework, based on the #BT? e.tension odel. These do ain-level policies are transfor ed to specific device-level for ats understandable to the enforce ent points where the" are applied in the decision- aking process.

Figure 1C.1. The conce tual levels of olicy abstraction.

0utomated $olic* %n(orcement Is 4e* to 0utonomic Business Operations

Policies are created as high-level business definitions, such as 38-, event anage ent, and networking services 6 onitoring, etc.7 The" are then translated to a canonical for as prescribed b" the *G3- polic" fra ework, based on the #BT? e.tension odel. These do ain-level policies are transfor ed to specific device-level for ats understandable to the enforce ent points where the" are applied in the decision- aking process. Progra atic director tools for polic" enforce ent are then able to ascertain, sustain, and anage business operations based on d"na ic policies dictated b" business leaders involved in specific operational aspects of the business enterprise.

" 0ample Poli#( 0ervi#e 1ramework ?igure 1>.; shows so e of the core polic" service co ponents. These ver" i portant autono ic ele ents can be further understood according to the following definitions.

Figure 1C.4. The defined 9"%' 7olicy %ervice $ore.

$olic* Managers 0re 3er* $ower(ul 0utonomic Components in Grid Computing

Polic" 1anager This is a anager service responsible for controlling access to the polic" repositor" for the creation and aintenance of polic" docu ents. This anager is e.pecting policies in a canonical for as defined b" the standard. There should be onl" one anager in a polic" service infrastructure. Polic" +epositor" This is a repositor" service, which provides a set of abstract interfaces to store the polic" docu ents. #n realit", this can be an" t"pe of storage 6e.g., re ote'local disk, database, file s"ste , e or", etc.7 accessed and abstracted through the 5ata -ccess #nterfaces 3ervice 65-#37. /e will cover this data access and integration service interface and fra ework in detail in a later section of this book. Polic" Bnforce ent Points These are the fra ework and software co ponents that are e.ecuting the polic" enforce ent decisions. The" work in con,unction with the polic" service agent to retrieve, transfor , and resolve an" conflict resolution of the polic". Polic" 3ervice -gent These are the polic" decision aker agents, and the" work with the polic" enforce ent points and the polic" anager. The" e.pect and inspect the data in a canonical for at. Polic" Transfor ation 3ervice These services are responsible for transfor ing the business ob,ectives and the canonical polic" docu ent to the device-level configurations. Polic" Kalidation 3ervice These services act as ad inistrators and toolsF the act of validating the polic" changes is acco plished using these services. Polic" +esolution 3ervice These services act as )guardians) of the polic" resolution process, and evaluate the policies in the conte.t of business 38-s. Polic" Tools and -utono ic 1anagers These tools are responsible for the creation of polic" docu ents, and

Poli#( 0ervi#e Inter!a#es The *G3- Polic" fra ework defines so e core interfaces and functionalities to i ple ent a robust, end-to-end, distributed polic" anage ent set of services. -s we have previousl" discussed high-level ele ents of this fra ework, this fra ework should alwa"s include the following(

- canonical representation for e.pressing the polic" 6i.e., the Polic" #nfor ation 1odel IP#1J and the core 918 sche a7 - anage ent control point for defining and sustaining the polic" lifec"cle 6i.e., the Polic" 3ervice 1anager #nterface7 -n interface for polic" consu ers to retrieve policies 6i.e., the Polic" 3ervice -gent #nterface7 - eans to ensure that a service is full" polic" aware, and will validate a polic" as re!uired 6i.e., the Polic" Bnforce ent Point #nterface7 - eans to effect changes on a resource 6i.e., utilizing the Co 1anage ent 1odel7 on

W06Poli#( .verview and Its 2elation to .G0" Poli#( #n an earlier chapter we covered the /3-Polic" 8anguage and its utilization in the /eb service environ ent. -t the current point in ti e, the grid co unities are unable to identif" uch activit" in the GG? to align the *G3- Policies with the /3Polic"6s7. 0ummar( The polic" work in *G3- is pri aril" derivative work fro the #BT? and 51T? polic" work, with added ele ents of grid service abstractions and behaviors. This polic" work is ostl" suitable for #T resource anage ent. /e are e.pecting ore works on defining the relationship between different polic" standards including /3Polic", *-3#3-initiated business-level polic" works, and service-level agree ents and how these polic" infor ation odels can collaborate and co pli ent the *G3polic".

0e#urit( "r#hite#ture
#n this section, we will approach grid service securit"I5J with a detailed discussion on the securit" challenges faced b" the grid co unit" in general, and then e.plore the details of securit" solutions provided b" the *G3-. +esource sharing a ong heterogeneous virtual organization participants is a co ple. process because of the challenges faced in integration, interoperabilit", and trust relationship. /e can further e.plain this b" e.a ining the following factors(

#ntegration Challenge. There are nu erous securit" fra eworks, co prehensive standards, and i ple entation available toda". The a,orit" of these organizations, individuals, and'or resources have their own preferences about the securit" re!uire ents that are ost suitable for their own environ ent. /e cannot replace all these securit" fra eworks, nor are we able to co e up with a co on alternative. This places the burden on the participants to honor the e.isting securit" fra eworks and'or sea lessl" integrate with the . This, in turn, re!uires that the *G3- securit" architecture be )i ple entation agnostic,) so that it can be instantiated in ter s of the e.isting securit" echanis sF that is, )e.tensible) so that it can incorporate new securit" services when availableF and capable of integration with the e.isting securit" services. #nteroperabilit" Challenge. The resource sharing of these interoperable resources a" e.tend into an" do ains of securit" real s, and their respective needs securit" interoperabilit" at each la"er of service i ple entation. 8et us e.a ine these various levels in the following points(

-t protocol level, different do ains need to e.change essages across their protocol la"ers and the" need to have interoperabilit" at each la"er of the protocol stack. -t the polic" level, secure interoperabilit" re!uires each part" to specif" an" polic" it a" wish to enact in order to enter into a secure conversation, and these policies need to be interoperable and utuall" co prehensible. -t identit" level, we re!uire echanis s for identif"ing a user fro one do ain to another do ain. ?or an" cross-do ain invocation to succeed in a secure environ ent, the apping of identities and credentials to the target do ain identit" is absolutel" re!uired.

Trust +elationship Challenge. The trust a ong the participants in a d"na ic virtual organization is the ost co ple. thing to achieve, and this trust ust be evaluated for each session or re!uest. This re!uires federation of a trust relationship a ong the participants. To su arize, for the securit" challenges in a grid environ ent, one following points are addressed while categorizing the solution areas(

ust ensure the

#ntegration solutions where interfaces should be abstracted to provide an e.tensible architecture. #nteroperable solutions, to enable services to invoke each other even when the" are hosted b" different virtual organizations with different securit" echanis s and polic" re!uire ents. 5efine, anage, and enforce trust policies within a d"na ic grid environ ent.

?igure 1>.< depicts these securit" ite s.

Figure 1C.;. The categories of security challenges are com le2 in a grid environment.

?igure 1>.< e phasizes the securit" challenges we have discussed earlier in this discussion, and their solution dependenc". -s indicated b" the relationship arrows, a solution within a given categor" will often depend on another categor". .G0" 0e#urit( "r#hite#ture The *G3- securit" architecture addresses the above proble s and challenges through securit" echanis s that are plug-and-pla" at the client and service side. These design points are discoverable b" the service re!uester fro a service description. The grid environ ent re!uires an *G3- platfor securit" echanis to support, integrate, and unif" popular securit" odels, echanis s, protocols, platfor s, and technologies.

Common 'ecurities %lements #equired (or a Grid %nvironment

-uthentication Provide integration points for ultiple authentication echanis s and the eans for conve"ing the specific echanis s utilized in an" given authentication operation. 5elegation Provide facilities for delegation of access rights fro re!uestors to the services. These delegated access rights ust be transferred to the tasks to be perfor ed, and for a li ited ti e, fra ed in order to li it the risk of isuse. 3ingle 3ign *n This capabilit" allows a service user to utilize ultiple resources with one e.plicit logon process, and thereafter, auto aticall" delegate the sa e authenticated credential for the ne.t resource access without user intervention, within a specific period of ti e. These single-sign-on sessions a" include accessing of resources in other do ains using a service credential delegation. Credential 8ifespan and +enewal Credentials have a li ited ti e span associated with the , and ost of the grid ,obs a" take ore ti e to e.ecute. This a" cause credentials to get invalidated, rendering the s"ste to an invalid state. #n order to avoid this, a grid s"ste ust support credential e.pir" notifications to the users and credential revalidation facilities. -uthorization This odel allows for controlling access to *G3- services based on authorization policies 6i.e., who can access a service, and under what conditions7 attached to each service. #n addition, it allows the re!uesters to specif" invocation policies 6i.e., to who does the client trust to provide the re!uested service7. -uthorization should acco odate various access control odels and i ple entations. Privac" Privac" policies a" be treated as a t"pe of authorization polic" that brings privac" se antics to a service usage session. 3i ilar to authorization, *G3securit" ust allow both a re!uester and a service to enforce privac" policies, for instance, taking into account things like personall" identifiable infor ation 6P##7, purpose of invocation, etc. Confidentialit"

0e#urit( 0ervi#es The *G3- securit" architecture has an insur ountable task of establishing a securit" odel to capture all the above re!uire ents. -s a natural progression, the *G3securit" architecture is aligned with the /eb services securit" odel. ?igure 1>.= shows the securit" architecture odel of the *G3-.

Figure 1C.A. The 9"%' security architecture.

?igure 1>.= shows the core securit" odels utilized in the grid environ ent. -ll grid services co unicate with each other based on a set of bindings specified b" the services. These bindings ust deal with the securit" details including essage confidentialit", integrit", and authentication. Aor all" speaking, these bindings are initialized on a runti e-based set of policies, specified b" the service providers. These securit" policies can be specified as static docu ents, such as /358 or /3-Polic" docu ents, or can be negotiated at runti e based on the capabilities of the client and service. The co on policies specified include supported ele ents such as authentication echanis s, re!uired integrit"'confidentialit", trust policies, privac" policies, and securit" assertions 6e.g., polic" assertions7. *nce the grid service client and service providers discover the receptive securit" polic", the" can then enter into a secure conversation ode and establish a secure channel for the essaging e.change. This channel ust then also enforce all of the agreed-upon securit" Go3 guarantees. 8et us now e.plore the details of each of these co ponents in ore detail, and better understand the technologies of interest in each la"er of the securit" co ponent odel. Binding 0e#urit( The binding transport includes 3*-P, ##*P, C13, 2TTP, and so on, and each of these transport protocols have different securit" re!uire ents for authentication, essage

integrit", and confidentialit". ?or e.a ple, 2TTP and 338 co bined co prises )https) as its secure conversation channel, guaranteeing essage integrit" and confidentialit", "et with the li itation of a point-to-point protocol channel. This networking services protocol a" also re!uire higher-level coordination services for end-to-end flow across inter ediaries 6e.g., firewalls, pro." servers, etc.7. #n the case of 3*-P essages, the /3-3ecurit" odelI:J provides a secure essage e.change pattern utilizing the 3*-P headers as the securit" infor ation e.change carrier. The integrit" and confidentialities of 3*-P essages can then be protected utilizing 918 digital signatures and encr"ption standards,I;J and /3-3ecurit" then provides secured profiles for e.change of this infor ation. *ther binding level securit" infrastructure includes C3#v$ for ##*P-based co unications adopted b" C*+4- vendors, and the C$ee 1.& as a andator" standard for secure ##*P essages. Poli#( '+pression and '+#hange #n order for a secure essage e.change to e.ist, both the service re!uester and service provider ust agree on the certain policies for the receptive secure essage and conversation to occur. This polic" agree ent can be acco plished a priori 6i.e., static infor ation7 or at runti e 6i.e., d"na ic7, and the best possible securit" binding selections ust be perfor ed at both the service provider and service re!uester sides of the conversation. The grid, being a highl" d"na ic environ ent, also re!uires d"na ic policies and decisions to be e.ecuted at runti e. These d"na ic policies can be associated with the service /358, service0s service data, or can be e.changed through collaborative negotiations. #n addition to the conversational re!uire ents, there a" often be a re!uire ent for the respective polic" infor ation to be present in order to provide secure binding to native platfor services. *ne of the notable technolog" candidates in polic" e.change areas is /3-Polic", which specifies how service providers and service re!uesters can, in turn, specif" their respective re!uire ents and capabilities. -t this stage of the discussion, we have e.plored the binding and polic" e.change la"ers, which allows the service re!uester and service provider to discover the policies the" re!uire for a secure conversation to occur. The ne.t la"er is related to the nature and enforce ent of these policies. That is, a secure association between service endpointsF apping of identities and translation of credentialsF and authorization policies and privac" policies, which provide access control to services. 0e#ure "sso#iation #n the grid conte.t, the co unications between a service re!uester and the service provider are oftenti es long-running conversations through various essage e.changes. The *G3- securit" architecture specifies creating a secure conte.t during the initial negotiation between the client and the service, while utilizing the sa e conte.t for protecting the subse!uent essages. The secure conte.t is then coupled with networking services transport binding, and this concept is alread" available with ost of the securit" protocols 6e.g., 338 and ##*P-C3#v$7. ?or the *G3- Grid Co puting environ ent, the secure conversation

support is provided using the /3-3ecureConversation protocol. +ecalling fro an earlier chapter discussion, the /3-3ecureConversation describes how a utual authentication between service re!uester and service provider is acco plished and how to establish utuall" authenticated securit" conte.t. Identit( and Credential 3apping<Translation - grid environ ent consists of ultiple trusts 6i.e., virtual organizations7 and securit" do ains. To cross the do ain boundaries re!uires a utual authentication. Therefore, a re!uire ent e.ists to ap and'or translate the credentials fro one do ain into another. This interoperation needs a )federation) of do ains and their securit" echanis s. This federation can be acco plished through the apping and'or translation of identities and'or credentials fro one do ain to another utilizing so e trusted inter ediar" services, gatewa"s, or pro.ies. #n the conte.t of /eb services, there is so e ongoing work to define this federation essage e.change pattern and odel. The grid co unit" of practitioners can e.pect the /3-?ederation to beco e a published approach for *G3--based grid services so e ti e in the not too distant future. "uthorization 'n!or#ement -uthorization to access a resource is controlled b" policies enforced in the resource provider side of the environ ent. Toda", there are several different co ercial authorization echanis s available across the industries. The ost pro inent ones are role-based authorization, rule-based authorization, and identit"-based authorization. The selection of these echanis s is entirel" based on the service re!uire ents, hosting platfor capabilities, and the application do ain 6e.g., 4$4, 4$C, G$C, etc.7. /3--uthorization provides ore specific details on how access policies for grid services and /eb services are specified and anaged. #n toda"0s grid scenarios, ost of the access to the resources is controlled, based upon the identit" of the re!uester. This re!uires the resource to aintain an access control list 6-C87 with the identit" of the end user, or with the apped identit" of the end user. #n the second case, a apping or translation of identit" ust occur before the end user can access the resource6s7. Priva#( 'n!or#ement 1aintaining anon" it", or the abilit" to withhold private infor ation, is one of the core re!uire ents in an" grid service environ ents. *rganizations involved in the grid environ ent a" need to declare their privac" re!uire ents, and conversel" a" need to onitor the privac" polic" enforce ent results. The /3-Privac" specification provides echanis s to describe a odel for e bedding privac" infor ation and e.changing this infor ation in con,unction with the essages. #n the case of protecting privac" re!uire ents, and declaring the to custo ers, the grid environ ent ust adhere to the /3-Polic" odel, and therefore align with the /%C0s P%P efforts.I<J

Trust Bver" e ber of a K* is likel" to have a securit" infrastructure that includes authentication service, user registr", authorization engine, firewalls, network-level protection, and other securit" services. These securit" policies are defined to the securit" do ain in which the" e.ist. This self-containing securit" odel re!uires a trust a ong the K* e bers before the" can access the above services. This trust relation can be called ) e bership in the K*) and will enable a set of policies a ong the K* participants, identit" and credential apping policies, and'or a e bership with the trusted part" through so e pro.ies or gatewa"s. The grid trust odel is based on the /3-Trust specification. Core 0e#urit( 0ervi#es !or .G0" #n previous sections of the book we have discussed the securit" features and these re!uire ents for a grid environ ent. /e have discussed how we can achieve an" of these securit" re!uire ents, and the specific details of each of the securit" odels. /e have alread" noted that in a grid do ain, the interoperabilit" and integration a ong the e.isting securit" technologies is an absolute re!uire ent. #n order to achieve these afore entioned capabilities, the *G3- grid securit" standard has defined a set of abstract services on the top of the e.isting securit" platfor s and fra ework. These services are e.posed through the /358. ?igure 1>.1> details the *G3# securit" platfor services and their relationship with other *G3- co ponents. 8et us now e.plore the possible *G3- securit" service candidates in greater detail(

-uthentication service. Kalidates the service re!uester0s identit". *ne e.a ple can be the basic authentication echanis where user identit" and password are validated within the user registr". #dentit" apping service. Provides an identit" apping function where one service0s identit" can be apped to another service0s identit" in another do ain. These services are not concerned with the authentication to the service. -uthorization service. +esolves the re!uest to access a service b" verif"ing the access policies associated with the re!uester. The *G3- securit" service relies on the hosting environ ent0s access control echanis s using the service re!uestor0s identit" and policies associated with the service. Kirtual organization polic" service. The *G3- securit" service can utilize the *G3- polic" fra ework in order to provide polic" storage, polic" enforce ent, and polic" validation. Credential conversion service. +esponsible for the conversion of user credentials to another t"pe and'or for of credentials. -udit service. +esponsible for producing the records of the securit" activities and logging the based upon the specified policies.

Profile service. Concerns the creation and storage of profiles, including personalization data. Privac" service. Concerns the polic"-driven classification of P##. These services can be utilized to enforce the privac" re!uire ents for a service re!uester and provider.

Figure 1C.1C. The 9"%' 7latform security com onents.

0ummar( #n su ar", the grid securit" odel ust be able to leverage these e.isting securit" standards for their Go3 re!uire ent on secure essage e.change. The *G3- securit" architecture asserts that the *G3- securit" odel needs to be consistent with the /eb service securit" odel. 1an" practitioners in the Grid Co puting discipline believe that the /3-3ecurit" odel, and its core co ponents, are going to beco e the default standard for interorganizational and interenterprise secure essaging e.change brokering services. This /3-3ecurit" odel is not si pl" li ited to 3*-P bindings, and can alwa"s be e.tended to an" essage protocols that can e.change 918 essages, while having an associated infor ation odel.

3etering and "##ounting

There is a general re!uire ent that resource utilization should be onitored for cost allocation, capacit" anal"sis, d"na ic provisioning, grid-service pricing, fraud and intrusion detection, and'or billing. The *G3- platfor architecture is defining a co on set of interfaces and behaviors for these etering and accounting re!uire ents. *ne presu ption inherent in this architecture approach is the utilization of the C11 6Co on 1anage ent 1odel7 as a provider for resource perfor ance and utilization infor ation odels, this is related directl" with the etering and accounting architecture. ?or e.a ple, an operating s"ste resource i ple ented as a C11 service can provide critical infor ation, including average CP@ utilization, #'* activities, file s"ste utilization, interprocess co unications, e or" buffer utilization, and ore. This infor ation is andator" for deter ining the etrics for etering and accounting services.

8et us now e.plore the concepts of etering, rating, accounting, and bill pa" ent in the conte.t of the *G3- grid platfor environ ent, and anal"ze what critical infor ation it provides, and how the *G3- utilizes this infor ation. 3etering 0ervi#e Inter!a#e Grid services will oftenti es consu e ultiple resources, and these resources will often be shared b" ultiple service instances. /e know that ost of the current operating s"ste s have etering subs"ste s for easuring the resource consu ption and aggregating their own respective utilization easure ents. The *G3- etering service provides access to s"ste s 6i.e., operating s"ste and'or s"ste -level software7 providing aggregated utilization data 6i.e., onitored data7. This aggregated data is e.posed through a etering service data ele ent. The ost co on factor affecting this aggregated data is the ti e window for aggregation 6e.g., da"s, hours, seconds7 and a" var" between the data producers 6i.e., the services7 and enforcers 6i.e., the ad inistrators, operating s"ste s, etc.7. 1etering involves the capabilit" to easure the resource consu ption in a workflow odel e.ecuting on widel" distributed, loosel" coupled servers, storages, and network resources. The *G3- provides these end-to-end etering capabilities involving a nu ber of resources and associated workflows. These easure ents are valuable for d"na ic resource provisioning and grid pricing. The above *G3- etering e.planations are associated with resource consu ption, and the etering of that consu ption. There is a need to provide aggregated application-level consu ption easure ent, for e.a ple, a service fee for each service invocation across a worldwide enterprise.

Metering is 4e* to the Business On Demand 'ervices Model

1etering involves the capabilit" to easure the resource consu ption in a workflow odel e.ecuting on widel" distributed, loosel" coupled servers, storages, and network resources. This workflow can be directl" involved with 4usiness *n 5e and services 6for e.a ple7 and a" be ke" to the operations of an" enterprise. The *G3- provides these end-to-end etering capabilities involving a nu ber of resources and associated workflows. These easure ents are valuable for d"na ic resource provisioning and grid pricing.

2ating 0ervi#e Inter!a#e - rating interface is responsible for the following(

Converting the

etered resource infor ation into financial

easure ents.

Providing valuable financial infor ation to the business service 6i.e., financial advice7 including the cost of the co ponents utilized to deliver the service. This helps the service to advertise its esti ated cost and usage pricing sche es, and enables custo ers to ake the best econo ic decision.

"##ounting 0ervi#e Inter!a#e -ccounting services can ake use of the rated financial infor ation retrieved through rating services in order to calculate user subscription costs over a specific period of ti e, per use 6i.e., *n 5e and7, or on a onthl" basis. This service provides user subscription and account-related infor ation to other services for decision aking on user subscription 6e.g., suspend, revoke, activate, etc.7, bill pa" ent, and other relevant business operational e.penses. Billing<Pa(ment 0ervi#e Inter!a#e These services work in collaboration with the accounting service to collect the pa" ents, provide ediation capabilities, and a wide variet" of financial interface re!uire ents. 0ummar( -s we have described in an earlier chapter, the grid econo " is still in its evolutionar" stages, and to get successful adoption of Grid Co puting environ ents, we need a grid with a variet" of cost odels that are based on cost and ti e odels. - best reco endation on the econo " of grid can be arrived at onl" if we can easure the resource utilization in such an environ ent. To co plicate the situation, in a grid environ ent, these resources a" be involving a co plicated and co ple. workflow, involving other resources across one or ore virtual organizations. This involves the accurate correlation of resource etrics. The *G3- is working to provide a solution, and co on pattern, to these challenges through the above services and interfaces. /e can find this infor ation e.tre el" valuable for d"na ic provisioning and costQti e anal"sis features. The value of these services depends on the identification and generation of critical algorith s and dataining echanis s utilizing these etrics. The authors of this book welco e an" reports of progress in these areas, and other areas being discussed in this book.

Common )istri*uted /ogging

The distributed logging capabilit" can be viewed as t"pical essaging applications where essage producers generate log essages 6e.g., infor ational, trace, error, or debug essages7, and which a" or a" not be consu ed b" the interested essage consu ers over a period of ti e. The *G3- logging facilit" is an architecture odel to separate the *G3- logging specific i ple entations to an inter ediar" or logging service. These logging services or inter ediaries should provide facilities for(

1. 5ecoupling. This helps to provide a clear separation of the roles of the log producers and log consu ers. The producer has no previous knowledge of the essage consu ers, and how the essage gets transfor ed. $. Transfor ation and co on representation. This facilit" provides plug-in transfor ation scripts to convert fro one log for at to another. 1ost notable a ong these transfor ation scripts is 938T, which acts as an 918 data transfor ation script. There is also a desirable approach to convert to a co on data for at based on a )co on logging sche a) representation suitable for canonical representation. This canonical sche a can eli inate so e transfor ation process and reduce the processing overheads. %. ?iltering and aggregation. 1ost of the logging a" result in a huge a ount of data and filtering of these data into certain buckets of desirable seg entsF this is a value-added feature. The *G3- logging service provides registration of such filtering criteria for each consu er, and aggregates the essages based on these criteria. &. Configurable persistenc". The durabilit" of the logs is a a,or feature provided b" the *G3- fra ework. /e can enable this feature based on a per service and'or a per essage basis 6i.e., *n 5e and7. ?or e.a ple, securit" logs and audits are kept intact for "ears to retrace so e securit" vulnerabilit" later on, should co puter forensics beco e an issue. 5. Consu ption patterns. 8ogging services should provide both s"nchronous 6pull7 and as"nchronous 6push7 odels of interaction of essages b" the consu ers. This service ust provide out-of-band essaging facilities for critical essages and logs. :. 3ecure logging. -s we alread" know, an" of these logs are critical, sensitive, and privateF therefore, the need to store the and transport the in a secure fashion is an absolute re!uire ent. ?igure 1>.11 shows the *G3- logging service architecture and essage flows. This facilit" utilizes the *G3# Aotification fra ework for essaging se antics and includes consu er subscription for logs b" providing filtering criteria and essage deliver" end points. The logs are delivered as essages based on specific notification topic changes and filtering criteria.

Figure 1C.11. The 9"%' logging service architecture model.

)istri*uted )ata "##ess and 2epli#ation

5istributed data for s a bottleneck for ost of the grid s"ste s. Barlier, we have discussed such grid applications 6e.g., the B@+*G+#5 pro,ect7. This co ple.it" of data access and anage ent on a grid arises fro the scale, d"na is , autono ", and the geographical distribution of the data sources. These co ple.ities should be ade transparent to grid applications through a la"er of grid data virtualization services. These services provide location transparenc" and easier data anage ent techni!ues. 5ata virtualization services, such as federated access to distributed data, d"na ic discover" of data sources b" its content, d"na ic igration of data for workload balancing, and sche a anage ent, all help to provide transparencies 6e.g., location, na ing, distribution, ownership, etc.7 to the data. These virtualization services need to address various t"pes of data including flat files, relational, ob,ects, and strea ing data. #n order to derive a co on data anage ent and interface solution to data access and integration, the *G3- initiative has started a working group titled the 5-#3 65ata -ccess and #ntegration 3ervice7 group. The 5#-3 group is responsible for data virtualization services and standard interfaces for data access and integration. /e will begin this discussion with *G3- platfor re!uire ents on data anage ent, and then we will spend ti e reviewing the work done b" the 5-#3 group on data access, integration interfaces, and the fra ework definition. 3o e *G3- re!uire ents on data

anage entI=J are(

5ata access service. B.poses interfaces that help the clients to access the data in a unifor anner fro heterogeneous data sources. 5ata replication. -llows local co pute resources to have local data, and thereb" i proves the perfor ance. 3ervices that a" be applied for data replica functions can include(

o o o o o

Group services for clustering and failover @tilit" co puting for d"na ic provisioning Polic" services for Go3 re!uire ents 1etering and accounting services 2igher-level services such as workload recover" services anage ent and disaster

The *G3- still needs to address these data replication re!uire ents b" providing co on interfaces to replication services. The i ple entation has to provide an adapter that can ove data in and out of the heterogeneous ph"sical and logical environ ents, without an" changes to the local data access s"ste s.

5ata caching service. @tilized to i prove data access perfor ance. 1etadata catalog and services. -llow us to search for a ultitude of services, based upon the ob,ect etadata attributes. 3che a transfor ation services. -llow for the conversion of sche a fro one for to another. -n e.a ple of this transfor ation is the conversion of 918 data using 938 transfor ation engines. 3torage services. 3torage activities are treated as resources and can be odeled as C11 services.

/e have now provided discussions to better understand the re!uired *G3- platfor services. 8et us now e.plore so e of the initial work activities in this area. Con#eptual 3odel The conceptual odel captures the data anage ent s"ste s, the data resources the" contain, and the data sets resulting fro the data re!uests perfor ed on these data resources. 4ased upon the principle of keeping the e.isting data anage ent s"ste s and its interfaces intact, this odel atte pts to e.pose the underl"ing data odel and native language'-P# of the resource anager. There are two t"pes of resources( resources that are )e.ternal) to the *G3#-co plaint grid and their *G3# resource service logical counterparts. ?igure 1>.1$ represents both the e.ternal resources and its logical counter parts.

Figure 1C.12. The e2ternal resources and ,ogical resources of a database management system.

8et us review this conceptual relationship

odel in the following details(

B.ternal 5ata +esource 1anager 6B5+17 and the 5ata +esource anager 65+17. This represents a data anage ent s"ste , such as relational database anage ent s"ste , or a file s"ste . The 5ata +esource 1anager is a Grid service that represents the e.ternal data resource anager and it binds to an e.isting B5+1. This provides anage ent operations, including start and stop. These anage ent functionalities are anaged b" specific vendors, and hence, a" be out of scope for 5-#3. ?igure 1>.1% shows the relation between 5+1 and B5+1.

Figure 1C.13. The conce tual model for the Data &esource (anager "rid service.

B.ternal 5ata +esource 6B5+7 and 5ata +esource 65+7. The e.ternal data resource is the data anaged b" the B5+1. This can be a database in a 5413 or a director" in a file s"ste . The 5ata recourse is a Grid service that binds to B5+. 5ata resource is the contact point to the data and it e.poses the etadata about the e.ternal data resource. #t ust provide the data anage ent 6access and update7 and !uer" capabilities. ?igure 1>.1& shows the relation between 5+, B5+, and B5+1.

Figure 1C.1!. ' logical data resource.

B.ternal data set 6B537 and data set 6537. This is the logical data si ilar to a relational database view or file cache that is separate fro the B5+1 or B5+, however, it can be retrieved and stored in the B5+ 6see ?igure 1>.157. The data set for s a service wrapper for the B53. These logical views e.posed so e challenging interfaces to anage the data.

Figure 1C.10. ' logical data set.

#n addition to the above e.ternal and logical resources for the following topics(

odels, the 5-#3 proposed so e logical

5ata -ctivit" 3ession. This is a logical data session for all data access operations. #t ust aintain and anage the conte.t data operations. ?igure 1>.15 illustrates this activit" session for a re!uester. 5ata +e!uest. This is logical infor ation regarding a re!uest sub itted b" a re!uester to the data access session. There is currentl" no grid service to anage this activit". This re!uest can be a !uer", data anipulation operations, or other such related activities.

0ervi#e Implementation There have been so e previous discussions regarding the GG?. These discussions are focusing on the service i ple entation odeling fro the above grid services portT"pes. There are two proposed odels with their own advantages and disadvantages.

1. Bach portT"pe beco es a Grid service. The co ple.it" surrounds the clientside utilization where it has to be concerned with a nu ber of grid service instances 6G32 and G3+s7 in order to anage a database. $. -ll portT"pes are i ple ented in a single service i ple entation. This si ple case provides an aggregated service view. The co ple.it" lies with the service i ple enter to aintain state infor ation on the client0s discrete activities. 2owever, the client has to anage onl" one G32 and its corresponding G3+s. The 5-#3 portT"pes are designed with the following principles in

ind( echanis s

*G3# co plaint B.tensible and pluggable with new storage s"ste s and access Bas" to understand and use b" the client This solution ust satisf" /eb service and grid service co

unities

Basier integration with the e.isting data

anagers and resources

4ased on the above design goals, the 5#-3 constructs the following logical portT"pe hierarch" with a clear separation of the interface functionalit" 6?igure 1>.1:7.

Figure 1C.11. ' logical ortTy e functionality se aration.

?or ore infor ation on this topic, it is i portant to refer to the 5-#3 specifications for details. 0ummar(

The )I"0 is a work6in6progress a#tivit( in the GG1- The spe#i!i#ation has not (et matured, hen#e, we #an e+pe#t a num*er o! #hanges to this spe#i!i#ation espe#iall( with the involvement o! ma:or data*ase vendors- There are some re!eren#e implementations that e+ist toda(- The .G0"6)"I?@AB pro:e#t is one su#h ma:or

pro:e#t that is #on#erned with the #onstru#tion o! a middleware to assist with a##ess and integration o! data Con#lusion
#n this chapter, we discussed the core *G3- platfor co ponents that are identified as suitable candidates for i ple entation with an" *G3--based infrastructure. These provide value-added functionalities and enhance the co on utilit" of the grid. /e are acknowledging that the *G3- /G a" identif" other functional services and co ponents over a period of ti e, and a" standardize upon the , define behaviors, service interfaces, and infor ation sche a. This will occur and enrich the *G3architecture odel. -s we have seen earlier, use cases are core for this evolutionar" architectural transfor ation activit". fro separate data sources, via the grid.

Part ": The Grid Computing Tool#its

#n the real of Grid Co puting, there are an" ver" innovative toolkits available to the Grid Co puting co unit" of developers and service providers. These toolkits are supported b" so e of the world0s fore ost participants in the Grid Co puting disciplines. This part of the book will unveil these toolkits, their application to industrial applications develop ent, service provider deliver" re!uire ents, and the aintenance of Grid Co puting environ ents. These toolkits address both the develop ent of Grid applications as well as creating the necessar" Grid Co puting infrastructure for deliver" of innovative services. #ncluded in the presentation discussions is the develop ent of applications and sa ples of how to acco plish this, Grid progra ing odels, sa ple i ple entations, definitions of high-level services, and iddleware solutions.

Chapter 11. G9OB-' G"2 "ool1it= 0rchitecture

#n a previous section, we were introduced to the Grid Co puting concepts, the new open standard software architecture odel 6i.e., *G3-7, and the new progra ing odel for Grid Co puting 6i.e., *G3#7. The G8*4@3 software technolog" toolkit 6Globus GT%7 version %I1J is the a,or reference i ple entation of the *G3# standard. The Globus GT% software is utilized b" a nu ber of worldwide technolog" initiatives, including utilit"-based co puting, #410s 4usiness *n 5e and co puting, virtualized resource sharing, and distributed ,ob schedulers. These activities serve as proof of concept of open standard resource sharing and interoperabilit" in Grid Co puting. This software and its surrounding architectures are in the process of evolution, and we will therefore concentrate our discussions in this chapter to the recent 6ver" stable7 release of the Globus GT% toolkit. The Globus GT% toolkit is the ost widel" utilized and e.plored infrastructure software for grid iddleware develop ent, worldwide, a ong grid practitioners.

2ence, we e.plore this toolkit in depth. /e introduce the Globus GT% software architecture and the progra ing odel using sa ple code listings. /e divide this discussion on GT% into three subse!uent chapters. ?irst, we discuss the high-level architecture of this toolkit, and in the ne.t chapter we cover the progra ing odel and tools introduced b" GT%. ?inall", our discussion ends with an i ple entation sa ple of a grid service to e.plain the concepts we have learned in the previous chapters of this book. -lso, we devote an entire chapter to discuss the high-level service defined b" GT%. 8et us now begin to e.plore the GT% software architecture.

GT3 0o!tware "r#hite#ture 3odel

-s shown in ?igure 11.1, the GT% architecture is a co bination of(

GT% core 4ase services @ser-defined services

Figure 11.1. The "lobus "T3 core architecture.

The GT% core for s the basic building blocks for grid services. This core consists of(

*G3# reference i ple entation. Provides *G3#-defined interfaces, essages, and grid behaviors. This i ple entation enables interoperabilit" with the /eb service engine and hosting platfor s. Tools provided with this i ple entation infrastructure assists us with grid services creation. 3ecurit" infrastructure. Provides the basic grid securit", including essage and transport level protection, end-to-end utual authentication, and authorization. This securit" fra ework is working in con,unction with the /3-3ecurit" specifications. 3"ste -level services. #ncludes logging services, ad inistrative services, handle resolver services, routing services, and other i portant co pli enting services. These services are built on the top of the *G3# reference

i ple entation and securit" i ple entation. The" provide s"ste -level services available to other *G3# services for better anageabilit" and custo ization. The higher-level base services are built on the top of the GT% core. 3o e of the services provided b" the GT% base are infor ation services, data anage ent services, and ,ob e.ecution services. /e are postponing this discussion until Chapter 1&, which will focus on these topics. #n Chapter 1&, we also address each of these services available within the GT% software bundle, the infor ation odel e.posed b" these services, and its usage patterns. @ser-defined services are application-level services that are created to e.ploit the *G3# reference i ple entations and securit" infrastructure. These services a" in turn work with other high-level services to provide an i proved collective behavior related to resource anage ent. 3o e such services include eta schedulers, resource allocation anagers, and collaborative onitoring services. This GT% software introduces the notion of a grid service container, which for s an abstract notion of a runti e environ ent. This runti e environ ent provides capabilities for grid service persistence anage ent, lifec"cle anage ent, and instance anage ent. /e call this container )abstract) because the real functionalit" i ple entation is likel" to be using so e e.isting hosting environ ent capabilities. ?or e.a ple, a service i ple ented as BC4 a" have a lifec"cle anaged b" the C$BB BC4 container. The current GT% container is i ple ented on a C$3B'C$BB /eb container. -t the sa e ti e, we can create grid services BC4s b" using the delegation service progra ing odel defined b" GT%. Aote that the service lifec"cle and anage ent is still under the preview of the /eb container. Het another i portant co ponent re!uires our continued attention. This is the /eb service engine, which is 6again7 responsible for anaging the 918 essages fro a grid service client to the service. The functionalit" includes essage decoding, un arshalling, t"pe apping, and dispatching calls to the service ethods. The la"ered architecture enables *G3# reference i ple entations to utilize an" /eb service engine of choice. Bven though we can be selective in our choice of /eb service e.ecution engines, the current GT% i ple entation is not entirel" fle.ible. The current GT% relies on the -pache -.is /eb service engine for so e of its progra ing odels 6i.e., 1essageBle ent and t"pe apping7 and essage flows 6i.e., grid handlers7. /e can further e.plore the details of the i ple entation architecture odel with the default software fra ework i ple ented in the Globus GT% toolkit. /e will begin our discussion with the server-side fra ework co ponents. )e!ault 0erver60ide 1ramework -s shown in ?igure 11.$, the fra ework are as follows( a,or architecture co ponents of the server-side

1. /eb service engine provided b" -pache -9#3 fra ework. The GT% software uses the -pache -9#3 fra ework to deal with nor al /eb service behaviors

such as 3*-P essage processing, C-9-+PC handler processing, and /eb services configuration. $. Globus container fra ework. The GT% software provides a container to anage the stateful /eb service through a uni!ue instance handle, instance repositor", and lifec"cle anage ent that includes service activation'passivation and soft-state anage ent.

Figure 11.2. The current "T3 server-side reference im lementation model.

(essage 7rocessing Details

-s alread" entioned, GT% utilizes -pache -9#3 as their /eb service engine, which e.ecutes in a C$BB'C$3B /eb container, and provides a 3*-P essage listener 6i.e., the -9#3 3ervlet7. #t is responsible for 3*-P re!uest'response serialization and deserialization, C-9-+PC handler invocation, and grid service configuration. -s shown in ?igure 11.$, the GT% container provides a )pivot) handler to the -9#3 fra ework in order to pass the re!uest essages to the Globus container. The Globus GT% container architecture is utilized to anage the stateful nature of /eb services 6readers ust be aware that grid service instances are stateful /eb services7 and their lifec"cle. *nce a grid service instance is created b" the service factor", a uni!ue G32 is created for that instance b" the fra ework. Aote that the actual creation of a service depends on the service configuration properties, and the details are deferred to the progra ing odel discussion in the ne.t chapter. This instance is registered with the container repositor". This container repositor" acts as a repositor" of all the stateful service instances. The other fra ework co ponents and handlers contact the repositor" to invoke service ethods, get'set service properties 6e.g., instance G32, G3+, etc.7, activate'passivate service, resolve grid service handles to reference, and persist the service.

$ivot .andlers
Pivot handlers are responsible for creating /eb service instance and invoking operations on the service. There are different t"pes of handlers available based on the st"le 6docu ent'rpc7 of the 3*-P essage. #n GT%, we are using )wrapped)-st"le essaging, which is a special case of )docu ent)-st"le essaging, where each para eter is bundled and treated separatel". GT% provides )+PC@+#2andler) as a special case i ple entation of a )CavaProvider) of the -9#3 fra ework. #t handles wrapped essages and contacts the container repositor", based on the service instance handle, to find the correct service and invoke the operations on it.

4ased on the above discussion, now we are fa iliar with the high-level default fra ework i ple entation that co es with GT%. 8et us now e.plore the GT% architecture co ponents in detail, using the above server-side i ple entation odel. Glo*us GT3 "r#hite#ture )etails This section introduces the Globus GT% architecture discussion. This architecture is an open-ended reference fra ework, with specific i ple entations worth" of review. Grid 0ervi#e Container The Globus container odel is derived fro the C$BB- anaged container odel, where the co ponents are free fro co ple. resource anageabilit" and runti e infrastructure usage. These co ple. anage ent processes include transaction, concurrenc", connectivit", persistence, lifec"cle, and securit" anage ent. #n such a anaged environ ent, the container is responsible for anaging and controlling these attributes. This helps to achieve a basic Go3 re!uire ent for the co ponents. #n addition, the progra ing odel beco es less co ple. to i ple ent. The *G3# specification introduces and i poses a nu ber of Go3 re!uire ents and behaviors on a grid service. The rendering of *G3# in a anaged environ ent forces GT% to reinvent a container odel for grid services. #n our previous discussions, we have e.plained these default i ple entation behaviors. The GT% container is responsible for instance anage ent, persistence, lifec"cle anage ent, and activation'deactivation of grid services. #t also provides a repositor" for service instance identit" and anage ent. #n general, this container provides the following value-added features(

8ightweight service introspection and discover" 5"na ic deplo" ent and soft-state anage ent of stateful grid services Transport-independent, essage-level securit" infrastructure supporting credential delegation, essage signing, encr"ption, and authorization

.G0I 2e!eren#e Implementation The *G3# +eference i ple entation is a set of pri itives i ple enting the standard *G3# interfaces, such as Grid3ervice, ?actor", Aotification 63ource'3ink'3ubscription7, 2andle+esolver, and 3erviceGroup 6i.e., Bntr"'+egistration7. - ong these, GT% i ple entation provides the base i ple entation of Grid3ervice and ?actor" interfaces. This for s the basis of GT% service i ple entation, container configuration, and the service invocation design pattern. These i ple entations can be e.tended to provide ore behaviors. /e will see the i ple entation and configuration details of these interfaces later in the ne.t chapter. GT% provides i ple entations for all other interfaces defined b" the *G3#. 2owever, these i ple entations are dependent on the service re!uire ents. #n co ple. scenarios, these i ple entations can be replaced with ore sophisticated services pertaining to the service re!uire ents. ?or e.a ple, the si ple point-to-point notification fra ework provided b" GT% a" not alwa"s be sufficient, and should be replaced b" as"nchronous C13-based essage !ueues. 0e#urit( In!rastru#ture GT% supports transport-level and essage-level securit". -nother notable feature provided b" GT% is a declarative securit" echanis for authentication and authorization using the service deplo" ent descriptors. This provides an e.tended plug-and-pla" securit" architecture using the C--3 fra ework. Transport6/evel 0e#urit( This is based on the G3# securit" echanis , as it e.ists toda" in GT$. To co unicate over this secure transport la"er we need to use a different invocation sche e other than httpF this is called httpg. /e have to be aware that the current transport-level securit" a" be depreciated in favor of the essage-level securit" introduced through the /3-3ecurit" architecture. 3essage6/evel 0e#urit( -s we have seen in the previous section regarding /3-3ecurit", the essage-level securit" is i ple ented at the 3*-P essage level. /e can see that there are two essage-level securit" echanis s( G3# 3ecure Conversation and G3# 918 3ignature.

"%+ %ecure $onversation

8et us further e.plore a few points, as illustrated in ?igure 11.%. 1. #nitiall" the client establishes a securit" conte.t with the service, utilizing a s"ste -level service known as the )3ecure Conversation 3ervice.) This securit" establish ent is acco plished utilizing the Generic 3ecurit" 3ervices 6G337 -P#.

$. *nce the securit" conte.t is established, the client will use this conte.t to sign on, verif", encr"pt, and decr"pt the re!uest'response essages. %. *n subse!uent calls, it passes the shared secret ke" along with the essage.

Figure 11.3. The establishment of a secure conversation.

"%+ D(, %ignature

The G3# 918 signature is a si ple 918 essage encr"ption echanis , where the essage is encr"pted using the 9.5>= certificate capabilit". This provides additional fle.ibilit", as an" inter ediar" can validate the certificates and, hence, the essage. /e will discuss the details of the essage, the transport-level securit" echanis s, securit" progra ing, and the declarative securit" odel for grid services in the ne.t chapter. 0e#urit( )ire#tions The future securit" in GT% will be aligned with the Global 918 architecture standards on securit". The /3-3ecurit" then beco es the default essage-level securit" echanis . The /3-Trust capabilit" is used for securit" conte.t creation, /3-3ecureConversation for secure e.change of the afore entioned tokens. ?igure 11.& shows this architectural direction.

Figure 11.!. -merging security standards and its im lementation #ith a grid service.

The plug-and-pla" nature of GT% securit" enables us to create the above architectural odel, with our choice of service'securit" provider options. #n addition, the future securit" echanis s ust provide facilities for supporting /3-?ederation, for federating across virtual organizations and trust do ains. 0(stem6/evel 0ervi#es 3o e of the s"ste -level services are introduced to provide a fra ework to achieve the re!uired Go3 in a production environ ent. These services ust provide logging, anage ent, and ad inistrate provisions for a grid environ ent. The functions can be used as standalone facilities, or the" can be used in concurrence with each other. 3o e of the e.isting GT% s"ste -level services are(

8ogging service. This enables d"na ic odifications of logging filters for the current runti e environ ent, or this can be persisted for subse!uent e.ecutions. #n addition, this service enables the grouping of log essage producers to ad,ust the size of backlogs and to provide custo izable essage views. 1anage ent service. This service provides a facilit" to onitor the current status and the load of a service container. #t also provides functionalities to activate and deactivate service instances. -d in service. This service provides ad inistrative activities, including pinging the hosting environ ent and shutting down the container.

Hosting 'nvironments The current GT% code is developed in Cava and supports the following t"pes of hosting environ ents( 1. B bedded utilities to be utilized with client and lightweight service deplo" ents $. 3tandalone containers for service hosting %. 3ervlet-based environ ents, as we noted in ?igure 11.$ &. BC4-based environ ents utilizing a delegation co ponents, i ple ented as services /oad Balan#ing 1eatures in GT3 Generall" speaking, a grid service is created in the sa e hosting environ ent where its factor" is located. This is fine in ost casesF however, there a" be cases when the service needs to be created in a different hosting environ ent than the local hosting scenario. The reason a" be an", including load balancing, user account restrictions, and backend resource re!uire ents. #n such situations, the factor" needs to create a service in a hosting environ ent other than the local one, and the service calls ust then be routed to the hosting environ ent where the service is operating. The local host now acts as a virtual hosting environ ent, but the client is unaware of odel to support e.isting BC4

this. The client perfor s the nor al operations as usual and the GT% fra ework handles the routing. This routing infor ation is e bedded with the 3*-P header. ?igure 11.5 illustrates such a virtual-hosting and load-balancing process. The ost pro inent e.a ple is the GT% G+-1 i ple entation. This environ ent provides a virtual-hosting environ ent for user account restrictions and load balancing.

Figure 11.0. ' virtual host and load balancing environment.

#n the ne.t chapter, regarding progra ing discussions, we will further e.plore the details of this load-balancing feature provided b" the GT% fra ework. Client60ide 1ramework GT% does not dictate an architectural fra ework for grid service clients. The default i ple entation co es with a nu ber of tools supporting -pache -9#3 and the corresponding Cava code generation. The fra ework follows the C-9-+PC progra ing odel. The -9#3 fra ework provides the runti e C-9-+PC engine for client-side essage processing and dispatching. -s shown in ?igure 11.: Globus GT% uses the nor al C-9-+PC client-side progra ing odel and the -9#3 client-side fra ework.

Figure 11.1. "T3 soft#are frame#ork, focusing on as ects of the client-side architecture com onents.

#n addition to the nor al C-9-+PC progra ing odel, Globus provides a nu ber of helper classes at the client side in order to hide the details of the *G3# client-side progra ing odel. /e will further address these details in the ne.t chapter on the progra ing odel. 3essage Prepro#essing Handlers 2andlers provide the echanis for processing raw 3*-P essages. This is ainl" utilized for handling 3*-P headers that are i ple ented to co unicate securit", correlation, and transactional se antics about a essage e.change. The GT% architecture utilizes the C-9-+PC handlers and the -9#3 handlers to acco plish this 3*-P essage-processing functionalit". These handlers are applicable at both clientand server-side i ple entations. /e will see further details of this in the following chapter.

0ummar(
The GT% architecture is a la"ered architecture with the e phasis on separating the functionalit" at each la"er. This fle.ibilit" enables high-level services to utilize the lower-la"er services in a plug-and-pla" anner in order to facilitate si pler s"ste designs. The provisioning for host environ ent independence and the provisioning to integrate into a /eb service engine of choice akes this ore attractive. Bven though this is highl" desirable, this level of e.tensibilit" is not "et available in Globus GT%, where the current /eb service engine of choice is -pache -.is. #n the ne.t chapter, we will see how this architecture can be converted into a fle.ible and e.tensible progra ing odel. 8ater in the book, we will see so e GT%provided high-level services and their respective functionalities.

Introdu#tion
The GT% software is providing *G3# functionalities, based on /eb services and the Cava progra ing odel. The core software is written in Cava and, hence, our discussion on the progra ing odel will be based on that language. This progra ing odel discussion includes the client'server-side progra ing odels, tools available to help construct those progra ing odels, and the deplo" ent artifacts needed for the container. #n the ne.t chapter, we will design a sa ple grid

service using a top-down approach, starting with /358, to validate the discussion points in this chapter.

0ervi#e Programming 3odel

The 3ervice Progra ing odel is based on the illustration in ?igure 1$.1, which shows the ob,ect s"ste and the relationships as i ple ented b" GT%. The core concepts we can infer fro this odel include grid service base and its i ple entation, grid service callback echanis s, operation providers, factor" and its callback concepts, and the service data. The ne.t few sections e.plain the details on these concepts.

Figure 12.1. The %ervice 7rogramming (odel.

Grid 0ervi#e Behavior Implementation The *G3#-defined grid service behaviors are defined in the Grid3ervice interface, and is i ple ented b" the default GT%-provided Grid3ervice4ase interface. This Grid3ervice4ase interface for s the basis of all grid services created b" GT%. This base interface provides operations for *G3#-defined grid service behaviors, service instanceQspecific properties anage ent, service data !uer" and odifications, service data set anage ent, and service facilities to add'delete operation providers. ?igure 1$.$ lists all the operations available with a GT%-created grid service. -ll these interface operations are not e.posed to the clientF onl" Grid3ervice interface operations are e.posed through /358.

Figure 12.2. This illustration de icts the "T3 "rid %ervice e2 osed o erations.

This fra ework utilizes the rest of the interfaces to control grid service behavior. This separation of responsibilities is controlled through a securit" authorization echanis . #n addition to these standard interfaces, the grid service a" i ple ent custo -e.posed interfaces defined through /358. -nother echanis b" which we can e.pose the service interfaces is through operation providers, and registering the with the service i ple entation. The ne.t section provides the details on this topic. -s we have discussed in ?igure 1$.1, GT% provides two default i ple entations of the Grid-3ervice4ase interface. These are(

Grid3ervice# pl. This i ple entation for s the base class for services that are transient. These services are created through the *G3# factor" echanis . Persistent3ervice# pl. This for s the base class for all persistent services, which are created through configuration entries and alwa"s available in the container. These services are not created through the *G3# factor" echanis .

These base classes provide a nu ber of functionalities, including service data anage ent, operation provider anage ent, and service instance lifec"cle anage ent. /e are deferring the ore detailed discussion on persistent and transient services to later sections of this book. 4ased upon this discussion, there are two design patterns available for our service creation. These are( 1. 3ervice e.tending Grid3ervice# pl, or Persistent3ervice# pl i ple enting our service e.posed interface6s7.

Figure 12.3. The grid service im lementation attern utilizing the service interface im lementation.

$. 3ervice e.tending Grid3ervice# pl or Persistent3ervice# pl while using operation providers to i ple ent our service interfaces 6?igure 1$.&7.

Figure 12.!. The "rid %ervice im lementation attern utilizing the o eration rovider.

.peration Providers The above discussion addressed the base i ple entation classes 6i.e., Persistent3ervice# pl and Grid3ervice# pl7 provided b" GT%. These are useful for service developers to hide a nu ber of co ple.ities associated with the service creation. 2owever, so e have a nu ber of e.tensibilit" proble s with this approach, which are(

5ue to the unavailabilit" of ultiple inheritances in Cava, service developers utilize the default interface hierarch", as provided b" the fra ework. 3o e of the behaviors i ple ented b" the afore entioned classes are specific to the GT% container, and hence porting the service i ple entation a" not be possible. 5"na ic configurations of service behaviors are not possible.

+elated to resolving these proble s, GT% has introduced a d"na ic delegation odel for service operations. This is a fle.ible and d"na icall" custo izable odel, where these operation providers are integrated into the service configuration at deplo" ent ti e. #n addition to the above static deplo" ent odel, there are provisions available with Grid3ervice4ase to d"na icall" add the operation providers during e.ecution. This fle.ibilit" allows one to progra the business logic into these providers, and the grid service i ple entation will then delegate the service calls 6as described in the /3587 to these providers. Given this, we can change the , add new functionalities, and add new interfaces with new operations to e.pose ore functional capabilities 6i.e., provided these operations are listed in /3587. To assist grid service developers to handle so e co on design patterns, the default GT% co es with three different t"pes of operation providers( factor" provider, 3erviceGroup provider, and Aotification3ource provider 6respectivel"7. 3ince these providers enable so e of the i portant functionalities for an" service0s @tilit" value, we are providing a detailed discussion on these special t"pes of providers later in this chapter. 8et us now e.a ine so e specific code seg ents behind an operation provider. 1. The following will create an )*perating3"ste ) grid service that i ple ents service behaviors, and then deplo"s this functionalit" to the GT% container.

,isting 12.1. The o erating system service im lementation )most of the im lementation is omitted for code clarity*.
p-3li% %lass Nperating6(stem/mpl exten"s 4ersistent8ri"6ervi%e/mplR p-3li% Nperating6(stem/mpl PQ R s-perP"Nperating s(stem 6ervi%e"QS T

p-3li% voi" post4ersistent*reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eption R T ......................................... T

,isting 12.2. The o erating system service de loyment in a configuration file.

1. <servi%e name="ogsa/%mm/Nperating6(stem6ervi%e" provi"er="!an"ler" st(le="wrappe"" -se="literal">

2. 3.

<parameter name="allowe";etho"s" val-e="0"/> <parameter name="%lass)ame" val-e="org.ogsa.%ore.%mm.Nperating6(stem4ort5(pe"/>

@.

<parameter name="3ase*lass)ame" val-e=" org.ogsa.%ore.%mm .Nperating6(stem/mpl "/>

5. D.

<parameter name="persistent" val-e="tr-e"/> <parameter name="s%hema4ath" val-e="s%hema/%ore/%mm/ operatings(stemIservi%e.ws"l"/>

B.

<parameter name="han"ler*lass" val-e="org.glo3-s.ogsa.han"lers.,4*.,/4rovi"er"/>

>.

<parameter name="se%-rit(*on#ig" val-e="org/glo3-s/ogsa/impl/ %ore/management/se%-rit( %on#ig.xml"/>

9. </servi%e>

8istings 1$.1 and 1$.$ show how we are able to create a service and configure that service for the container. 2ere we are deplo"ing the service into the default -pache -9#3 /eb service container using the /eb 3ervice 5eplo" ent 5escriptor 6/3557. *nce this service is deplo"ed onto the container, the client should be able to start invoking ethods on the service using the base *G3# Grid3ervice portT"pe. $. 8ater we decide that the above grid service needs to support *G3# Aotification source behaviors so that interested clients can subscribe for service state change notifications. #f we find that the default Aotification3ourceProvider function that is offered b" GT% is sufficient 6see the discussion later on regarding this default provider7, then we can establish that behavior ,ust b" changing the deplo" ent configuration 6ne.t7 fro what was previousl" shown in 8isting 1$.$.

,isting 12.3. The o erating system service de loyment #ith a 5otification%ource7rovider.

1. <servi%e name="ogsa/%mm/Nperating6(stem6ervi%e" provi"er="!an"ler" 2. 3. @. 5. D. st(le="wrappe"" -se="literal"> <parameter name="allowe";etho"s" val-e="0"/> <parameter name="%lass)ame" val-e="org.ogsa.%ore.%mm.Nperating6(stem4ort5(pe"/> <parameter name="3ase*lass)ame" val-e=" org.ogsa.%ore.%mm

.Nperating6(stem/mpl "/> B. >. <parameter name="persistent" val-e="tr-e"/> <parameter name="s%hema4ath"

9. val-e="s%hema/%ore/%mm/operatings(stemIservi%e.ws"l"/> 10. <parameter name="han"ler*lass" val-e="org.glo3-s.ogsa.han"lers.,4*.,/4rovi"er"/> 11. 12. <parameter name="se%-rit(*on#ig" val-e="org/glo3-s/ogsa/impl/%ore/management/ se%-rit( %on#ig.xml"/> 13. 1@. <parameter name="operation4rovi"ers" val-e="org.glo3-s.ogsa.impl.ogsi .)oti#i%ation6o-r%e4rovi"er"/> 15. </servi%e>

Aote these changes in the configuration infor ation in 8isting 1$.% on line 1%. #n addition to the nor al grid service behaviors, the client can subscribe for notifications on the operating s"ste service. This provides an a azing degree of fle.ibilit" for grid service developers. -nother wa" to add an operation provider is b" using the )add*perationProvider) operation on the Grid3ervice4ase# pl class. This is perfor ed in the service postCreate67 or postPersistentCreate67 calls, as shown in 8isting 1$.&.

,isting 12.!. The dynamically adding o eration rovider.

1. p-3li% voi" post*reateP8ri"*ontext %ontextQR 2. a""Nperation4rovi"erPnew )oti#i%ation6o-r%e4rovi"er PQQS 3. T

%. -fter a while, the operating service provider now decides to use a new notification source provider with ore co ple. functionalities. ?or e.a ple, the service developer decided to provide a C13 essage !ueueing facilit" rather than the si ple point-to-point echanis for notification. ?or this functionalit", the service developer ust create a new Aotification3ource provider and register that with the container. 8isting 1$.5 shows a sa ple skeleton of the C13Aotification3ourceProvider.

,isting 12.0. The 3(%5otification%ource7rovider im lementation )the lo#level details on the im lementation are avoided for the sake of sim licity and clarity*.
p-3li% %lass U;6)oti#i%ation6o-r%e4rovi"er implements Nperation4rovi"erJ .......R

private stati% #inal +)ameVW operations = new +)ameVW Rnew +)ameP"http://www.gri"#or-m.org/namespa%es/2003/03/ N86/"J"s-3s%ri3e"QT

p-3li% )oti#i%ation6o-r%e4rovi"erPQRT

p-3li% voi" s-3s%ri3eP Extensi3ilit(5(pe s-3s%riptionExpressionJ Lo%ator5(pe sin&J Exten"e"1ate5ime5(pe expiration5imeJ Lo%ator5(pe!ol"er s-3s%ription/nstan%eLo%atorJ 5ermination5ime5(pe!ol"er %-rrent5ermination5imeQR //N-r implementation goes hereX. T .......................... T

#n order for the service to use this new C13 Aotification provider described in 8isting 1$.5, we need to change the class na e in 8ine 1% of 8isting 1$.% with the new operation provider class na e. The fra ework will take care of the rest of the processing.

Internal Details o( Operation $rovider $rocessing

*ne a" be asking at this stage e.actl" how operation provider processing is happening inside the GT% fra ework. 8et us e.plore so e basic infor ation, as this will help us construct ore robust services. 1. Aotification3ource provider e.poses the GAa es of the operations it is e.posing to the clients. These ust atch the /358-described operations na e and their na espace. #n 8isting 1$.5, we can see that the class contains a static GAa e list of the service operations 6i.e., )subscribe) operation in the )*G3#) na espace7 it is e.posing. This operation atches the /358 Aotification3ource portT"pe0s )subscribe) operation. /e can alwa"s add wildcard characters for GAa e para eters, na espace na e, and operation na e. ?or e.a ple, in order to e.pose all public operations in a provider, create a GAa e with new GAa e6)Z).)Z)7. This is a fle.ible approach to e.pose all public operations in the provider. Aote that for the standard interfaces defined b" *G3#, it is re!uired to provide the na espace !ualifier that atches the *G3# operation na espace. $. -ll notification providers e.pose the )get*perations67) ethod for retrieving the e.posed operations 6as described above7. %. ?or correct operation na e lookup and invocation, all the e.posed operations ust follow the sa e signature, as described b" the corresponding /358 operation. &. The above se!uence diagra 6?igure 1$.57 illustrates how the fra ework handles this operation provider, and then the corresponding invocation ethod.

Figure 12.0. ' se@uence diagram for handling the o eration roviders.

1a#tor( Call*a#k 3e#hanism

The *G3# and GT% provides standard echanis s for the construction of grid services using a factor" pattern. The factor" e.tracts the grid service construction echanis s as an abstraction. GT% provided the )factor" callback) echanis , and enables the facilities for adding custo factories for additional services. These custo factories provide capabilities to create services in a re ote hosting environ ent, and can then align with the native host'container-specific service creation patterns, for e.a ple, work with BC4 2o e to create an BC4 service. GT% provides a default factor" i ple entation through a factor" provider, which delegates the service creations to the )default factor" callback.) This default factor" callback is capable of creating services inside the sa e class loader where the factor" is. #n 8isting 1$.:, we can see how to configure the deplo" ent descriptor to add a factor" provider and the GT%-provided default factor" callback i ple entation.

,isting 12.1. The factory rovider and the default factory callback.
1. <servi%e name=" ogsa/%mm/Nperating6(stem6ervi%e#a%tor(6ervi%e" provi"er="!an"ler" st(le="wrappe""> 2. .................................................................. 3. <parameter name="operation4rovi"ers" val-e="org.glo3-s.ogsa.impl.ogsi.#a%tor(4rovi"er"/> @. <parameter name="#a%tor(*all3a%&" val-e="org.glo3-s.ogsa.impl.ogsi.1(nami%#a%tor(*all3a%&/mpl"/> 5. .................................................................. D. </servi%e>

The previous 918 configuration frag ent describes the factor" operation provider and the callback i ple entation for the service. 8et us now i ple ent a custo factor" callback facilit" that is capable of connecting to an BC4 2o e to create an BC4 service. 8isting 1$.; e.plains how we can i ple ent such a custo factor" using the factor" callback i ple entation.

,isting 12.4. The custom factory callback im lementation.

1. p-3li% %lass EU$#a%tor(*all3a%&/mpl implements #a%tor(*all3a%& R 2. 3. @. p-3li% voi" initialiGeP8ri"6ervi%e$ase 3aseQ throws 8ri"6ervi%eEx%eptionR private 8ri"6ervi%e$ase 3aseS

5. D. B. >. 9. 10. 11. 12. 13. 1@. T

this.3ase = 3aseS

s(n%hroniGe" p-3li% 8ri"6ervi%e$ase %reate6ervi%eN3Ye%tP Extensi3ilit(5(pe extensi3ilit(Q throws 8ri"6ervi%eEx%eption R ................................ *ontext initial = new /nitial*ontextPenvQS //loo& -p the home inter#a%e -sing Yn"i N3Ye%t homeN3Y = initial.loo&-pPeY3Loo&-p6tringQS EU$!ome home = PEU$!omeQ 4orta3le,emoteN3Ye%t.narrowPhomeN3YJ EU$!ome.%lassQS

15. 1D. 1B. 1>. 19. 20. T T

// *reate EU$ o3Ye%t ................................. // *reate 8ri" servi%e o3Ye%t an" assign with the EU$ N3Ye%t

<<other private metho"s>>

,isting 12.;. The register and the ne# callback im lementation, as sho#n in the configuration.
1. <servi%e name=" ogsa/%mm/Nperating6(stem6ervi%e#a%tor(6ervi%e" provi"er="!an"ler" st(le="wrappe""> 2. .................................................................. 3. <parameter name="operation4rovi"ers" val-e="org.glo3-s.ogsa.impl.ogsi.#a%tor(4rovi"er"/> @. <parameter name="#a%tor(*all3a%&" val-e="EU$#a%tor(*all3a%&/mpl "/> 5. .................................................................. D. </servi%e>

8istings 1$.; and 1$.< describe how one can register the new factor" callback i ple entation with a service.

*ne can now deplo" the above service and all the calls to create the service 6i.e., create3ervice call on factor"7 and attain delegation to the BC4factor"Callback# pl0s )create3ervice*b,ect) ethod. /e can see ore infor ation on the internals of this factor" pattern in the following discussion.

Internal Details o( <actor* Call)ac1 $rocessing

The services can be configured to use an *G3#-provided factor" echanis b" setting a factor" operation provider for that service. *n a service container startup, it reads the configuration and loads the necessar" configurations to the 3ervice container repositor", and then activates the factor" service based on the configuration propert" 6i.e., 0activate*n3tartup07. ?ollowing this activation, when a client atte pts to create a service instance, the +PC@+#2andler follows the pattern as depicted in the ?igure 1$.:.

Figure 12.1. The factory callback rocessing se@uence.

The ne.t section discusses the GT%-provided grid service lifec"cle odel, where we will e.a ine a grid service lifec"cle, service state persistence echanis s, and recover" capabilities. Grid 0ervi#e /i!e#(#le Call*a#ks and /i!e#(#le 3anagement 1an" of the distributed co ponent odels support efficient and scalable e or" anage ent through autono ic co ponent activation and deactivation facilities. The GT% container odel is providing so e basic scalabilit" anage ent functionalities. The following points describe these functionalities.

3ervices getting activated onl" on the first utilization b" the container, even if the services are staticall" deplo"ed and persistent in nature.

Container provides scalabilit" echanis s b" deactivating unutilized services. 3o e of the ost co onl" deactivated services include notification subscriptions and service group entries. Aor all" speaking, these service instances are created in large nu bers. GT% utilizes algorith s for this deactivation process. These are referred to as(
o o

TT8M Ti e to 8ive 8+@M 8east +ecentl" @sed

/e are able to configure the TT8 propert" in the configuration file. *ne notable thing about this deactivation is that the container still holds so e etadata that is re!uired to activate these services.

3ervices are deactivated to a persistent storage in its entiret". GT% provides a facilit" called )3ervice8oader,) which we can use to achieve this kind of deactivation. This loader is also responsible for d"na icall" deplo"ing and activating a service on its first activation. - provision for )laz" creation) enables a factor" to return a uni!ue handle for the service instance without an" e.plicit deplo" ent or activation of that service instance. The service deplo" ent and activation happens later on, when the client tries to resolve the handle to a reference. ?or this, a laz" creation callback is involved.

-ll these scalabilit" anage ent functions are part of the container and transparent to the user of the container. Aow we can take a closer inspection on these capabilities, and the progra atic'configuration re!uire ents of a service to achieve these behaviors. These services transition fro activate to deactivate, and vice versa, and are enabled b" the Grid3erviceCallback interface, as described in 8isting 1$.=.

,isting 12.A. The service lifecycle interface.

p-3li% inter#a%e 8ri"6ervi%e*all3a%& R

p-3li% voi" pre*reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS p-3li% voi" post*reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS p-3li% voi" a%tivateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS p-3li% voi" "ea%tivateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS p-3li% voi" pre1estro(P8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS T

-ll grid services i ple ented fro Grid3ervice4ase, in turn, i ple ent this interface 6as shown in ?igure 1$.$7. The operation providers and factor" callbacks should i ple ent this interface to aintain fine-grain control on the underl"ing resource that the" provide. -nother ver" i portant interface associated with this service behavior is the 3ervice8ifeC"cle1onitor, as shown in 8isting 1$.1>. This is an interceptor to a grid service lifec"cle state transition.

,isting 12.1C. The service lifecycle interce tor.

p-3li% inter#a%e 6ervi%eLi#e%(%le;onitor R p-3li% voi" %reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS p-3li% voi" pre*allP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS p-3li% voi" post*allP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS p-3li% voi" "estro(P8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionS T

?or e.a ple, if there is a lifec"cle onitor configured with a grid service, utilizing the )life-c"cle1onitor) propert", then the factor" provider calls this interface operation )create) following the service instance creation. This factor" provider onl" calls this operation after the service instance creation, and following the preCreate, postCreate, and activation calls on the created service. The diagra in ?igure 1$.; details the lifec"cle interfaces and their interaction patterns. 8et us now discuss the lifec"cle anage ent options available with a grid service in ore detail.

Figure 12.4. The service lifecycle interfaces and integration rocess.

0ervi#e "#tivation 3ervice activation is a ke" operation in an" grid service. The following discussion provides treat ent to the operations involved in this process.

'ctivate /tilizing the ,azy $reation (echanism

-s shown in ?igure 1$.;, the factor" provider utilizes a ethod called laz"Create67, which will create a G32, and then returns that handle to the client without actuall" creating the real service instance. -n e.a ple of such a laz" creation is shown in ?igure 1$.; where the 3erviceGroup+egistration calls the factor"Provider )laz"Create) operation to create the service entries. The laz" creation can be enabled b" setting the )entr"#nstanceCreation) propert" to )true) in the configuration file. 8ater, when the client tries to utilize that service, the handle resolver provider calls the service0s parentF this is because the specific service instance node is not in the repositor". #n this case, the handle provider calls the 3erviceGroup+egistration service0s )laz"Create) ethod with the handle of the instance it wants to invoke. This service, in turn, creates the child service instance for that handle b" calling create3ervice in the factor".

'ctivation on %ervice %tartu

Aor all" speaking, a service is activated on its first usage. This activation results in an activate call to the grid service lifec"cle interface. 0ervi#e )ea#tivation The default polic" adopted b" the fra ework is that activated services never get deactivated. The fra ework provides a default deactivation echanis based upon the ti e to live 6TT87 polic". This is eas" to configure, as shown in 8isting 1$.11.

,isting 12.11. The default service deactivator configuration.

<servi%e name=" ogsa/%mm/Nperating6(stem6ervi%e#a%tor(6ervi%e" provi"er="!an"ler" st(le="wrappe""> <parameter name="%lass)ame" val-e="=" org.ogsa.%ore.%mm.impl.Nperating6(stem/mpl "/> <parameter name="persistent" val-e="tr-e"/> ................................................. <parameter name="li#e%(%le;onitor*lass" val-e="org.glo3-s.ogsa.repositor(.1e#a-lt6ervi%e1ea%tivator"/>

<<

i"le55L 3e#ore "ea%tivation in millise%on"s

>

<parameter name="instan%e1ea%tivation" val-e="10000"/>

</servi%e>

This deactivator is configured with a factor", as shown in 8isting 1$.11. This helps to onitor all the service instances created b" a factor". The functionalit" of this deactivator is to integrate into the described 3ervice8ifeC"cle1onitor interface calls, and update the service usage ti esta p. This current usage ti e is utilized b" a Ti er task, alread" e.ecuting, based on a Cava Ti er event. This is to validate the ti e to live para eter of a service, and calls the deactivate ethod on the service if the TT8 ti e e.pires. This a" not, however, be sufficient for ore co ple. scenarios. There are provisions available to integrate deactivators with a service factor", or instance, using the )lifec"cle1onitorClass) configuration option. 0ervi#e 0tate )ata Persisten#e 3e#hanisms This discussion addresses the state of the data, the persistence of the data, and the operations that affect this process.

%ervice ,oader
1ost of the services re!uire state data to be persistent, such that it can be recovered fro the subse!uent startups, as re!uired. ?or this reason, the fra ework provides a service persistence echanis through a 3ervice8oader interface, as shown in 8isting1$.1$. This allows a service to store and load the service related state into a persistent storage area.

,isting 12.12. The service,oader interface.

p-3li% inter#a%e 6ervi%eLoa"er R p-3li% 3oolean loa"P6tring i"Q throws 6ervi%eLoa"erEx%eptionS

p-3li% voi" storeP6tring i"Q throws 6ervi%eLoa"erEx%eptionS p-3li% voi" removeP6tring i"Q throws 6ervi%eLoa"erEx%eptionS T

The fra ework provides default 3i ple?ile8oader i ple entation that can be used with an" service. This is a pri itive echanis , and can be e.tended with backend database storage for aintaining all the configuration data and state data. #n addition to the above fra ework echanis , GT% provides a default echanis of storing the configuration infor ation for a transient service in the deplo" ent configuration file, utilizing the )3ervice5eplo" ent) fra ework co ponent. #n these situations, we can observe that the service instance specific configuration infor ation is written to the /355 configuration file. GT36Provided 0ervi#e T(pes 8et us e.a ine the t"pes of services available with the GT% fra ework, its configuration properties, and its creation se antics. There are two t"pes of services( transient services and persistent services.

Transient %ervices
These kinds of services are created b" the *G3# factor" and deplo"ed at runti e to the deplo" ent descriptor. These services are e.tensions of the Grid3ervice# pl base class, suppl"ing a factor" provider and a callback i ple entation class in the configuration.

7ersistent %ervices
- persistent service is deplo"ed when it is added to the deplo" ent descriptor through so e t"pe of out-of-band echanis . These services usuall" e.tend the PersistentGrid3ervice# pl GT% class. These services usuall" do not have a factor" or provider. Grid 0ervi#e /i!e#(#le 3odel #n addition to the above service lifec"cle, there are two kinds of lifec"cle odels associated with the state data recover" on service restart( persistent and transient.

7ersistent
?or the lifec"cle to be recoverable, all persistent services need to have a configuration propert" in their configuration file with 0lifec"cleS)persistent)0.
<parameter name="instan%eLi#e%(%le" val-e="persistent"/>

The fra ework creates deplo" ent infor ation for these service instances and will be stored in the deplo" ent configuration file. This deplo" ent infor ation is re oved fro the configuration file upon service destruction and deactivation using a 3ervice8oader, as shown above.

Transient
This is the default behavior and no infor ation is persistent in the deplo" ent descriptor. To conclude, Table 1$.1 shows the GT%-provided service lifec"cle properties, their options, and their default values.

Table 12.1. The Default %tate (anagement %u ort in "T3

0ervi#e Propert( 3ervice T"pe 8ifec"cle 1odel -ctivation 5eactivation .ptions Persistent 6default7, Transient Persistent, Transient 6default7 3tartup, 8az" 6default7 Aone 6default7, TT8'8+@

GT360upported Programming 3odel !or 0ervi#e )ata 3anagement The service data for s the globall" e.posed state of a service. /e have alread" discussed the details and i portance of service data during our discussion on the *G3#. 8et us now see how GT% is i ple enting this core *G3# feature. #n GT%, there is a concept called service data set 63ervice5ata3et class7, which holds all the service data for a service. ?igure 1$.< shows this relationship odel. Bver" grid service instance has a service data set that holds a collection of service data wrapper ob,ects. This service data set is responsible for sending notification of an" service data changes, with the changed service data wrapper ele ent, to the interested listeners. - service data wrapper 63ervice5ata class7 is holding the service data values, or uses a callback echanis often referred to as service data )pull,) to get the value fro other registered data providers. These callbacks ust then i ple ent the 3ervice5ataKalueCallback interface, and ust be registered with the service data wrapper class.

Figure 12.;. The service data classes and relationshi s.

There are three wa"s b" which we can create and add service data to a service data set( 1. Predefined service data ele ents in G/358. Aor all" speaking, on the service startup, all the service data is loaded into the service data set. There are -P#s in service data set 6create'add're ove7 to d"na icall" add service data, provided that the" are confor ing to their descriptions in /358 6service data descriptions7. /e will e.plore this process in detail in the following discussion. 3ervice data ele ents are defined in the /358. Bver" standard *G3#-defined interface alread" contains so e 35B definitions. 8isting 1$.1% shows the *G3# Grid3ervice portT"pe G/358 with 35 ele ents defined.

,isting 12.13. 9"%+-defined "rid%ervice ortTy e #ith service data elements and static values.
<< 8ri" 6ervi%e 4ort 5(pe >

<gws"l:port5(pe name="8ri"6ervi%e"> <operation name="#in"6ervi%e1ata"> .................................................. </operation> .................................................. <s":servi%e1ata name="inter#a%e" t(pe="xs":+)ame" minN%%-rs="1"

maxN%%-rs="-n3o-n"e"" m-ta3ilit(="%onstant" mo"i#ia3le="#alse" nilla3le="#alse"/>

<s":servi%e1ata name="gri"6ervi%e!an"le " t(pe="ogsi:!an"le5(pe " minN%%-rs="0" maxN%%-rs="-n3o-n"e"" m-ta3ilit(="exten"a3le" mo"i#ia3le="#alse" nilla3le="#alse"/>

.................................................... <s":stati%6ervi%e1ataCal-es> <ogsi:#in"6ervi%e1ataExtensi3ilit( inp-tElement="ogsi:'-er($(6ervi%e1ata)ames"/> <ogsi:set6ervi%e1ataExtensi3ilit( inp-tElement="ogsi:set$(6ervi%e1ata)ames"/> <ogsi:set6ervi%e1ataExtensi3ilit( inp-tElement="ogsi:"elete$(6ervi%e1ata)ames"/> </s":stati%6ervi%e1ataCal-es> </gws"l:port5(pe>

@pon service startup, these alread" defined service data ele ents are created and added to the service data set during the Grid3ervice4ase0s postCreate67 call. 3ee the sa ple algorith code in 8isting 1$.1&, which is taken fro the Grid3ervice4ase# pl class to illustrate this process.

,isting 12.1!. %ervice data #ra definition elements.

er ob.ects creation from "?%D, %D-

1. private voi" a""6ervi%e1ataPQ throws 8ri"6ervi%eEx%eption R 2. // 2ll 6ervi%e 1ata elements are "e#ine" in E61L 86,

3.

8et the 86, PE61LQ #or the %-rrent servi%e

@. 8et all the M8E61LM port5(pes in the 86, Pnot the E61L port5(pesQ 5. Oor ea%h 8E61L port5(pe Pport5(pes '-ali#ie" with 8E61L namespa%eQ D. B. >. 9. 10. attri3-tes 11. 12. 13. 1@. 15. 1D. 1B. Erapper // )ow get the "e#a-lt stati% val-es "e#ine" in 8E61L 8et the 6tati% 6ervi%e 1ata val-es in the 8E61L port5(pe Oor ea%h 6tati% 6ervi%e 1ata 8et ea%h stati% servi%e "ata val-e 2"" the all servi%e "ata val-es to the 6ervi%e 1ata %lass provi"e" their name an" namespa%e mat%hes 1>. T // *reate 61 wrapper %lasses -sing 61E "e#inition in 8E61L 8et the servi%e "ata elements "e#ine" in that port5(pe Oor ea%h servi%e "ata element 8et the 6ervi%e "ata name an" its namespa%e *reate a servi%e 1ata Erapper %lass with the a3ove 2"" wrapper to the 6ervi%e 1ata 6et

The above postCreate67 echanis in the Grid3ervice4ase# pl class sets up the service data set with the appropriate service data wrappers, and their associated predefined 6static7 values. 8ater, if there is a need to update so e service data value that alread" has a wrapper in the service data set, 8isting 1$.15 e.plains how to do this.

,isting 12.10. $reating and adding service data values.

1. 8et the 6ervi%e 1ata Erapper %lass #rom the servi%e "ata set -sing the +)ame o# the servi%e "ata element as "e#ine" in E61L #or example: 5o get the pre"e#ine" Palrea"( %reate" #rom 8E61LQ "!an"le" 6ervi%e

1ata elementJ -se the %o"e 3elow.

6ervi%e1ata han"le6ervi%e1ataElement = this.servi%e1ata6et.%reateP"gri"6ervi%e!an"le"QS

2. )ow %reate the val-e #or that servi%e "ata element. 5his element m-st 3e o# the 6ervi%e1ataElement t(pe. 5hese t(pes are "e#ine" in the F61 an" the #ramewor& m-st have alrea"( %reate" %orrespon"ing Uava t(pes P-sing tools E61L2U2C2Q. !ere "gri"servi%e!an"le" is o# the t(pe "!an"le5(pe" an" hen%e %an %reate an" a"" the val-e to the 6ervi%e1ataElement wrapper %lass: !an"le5(pe han"le = new !an"le5(pePhan"leQ han"le6ervi%e1ataElement.setCal-ePhan"leQS

3. .p"ate the servi%e "ata set with 6ervi%e 1ata Erapper an" the new val-e #or example: this.servi%e1ata6et.a""Phan"le6ervi%e1ataElementQS

$. 5"na ic service data ele ents and values. 3o far, we have been discussing the service data ele ents, which are staticall" defined in the /358. There a" be cases when a grid service needs to create the service data ele ents and add the d"na icall" to the service data set. Creating )(nami# 0ervi#e )ata 'lements The code in 8isting 1$.1: shows how to construct a d"na ic service data ele ent for a service. Aor all" speaking, this is done on a postCreate call to ake the service data available to the clients upon service startup.

,isting 12.11. $reating and adding dynamic service data elements.

// *reate 6ervi%e 1ata Element servi%e1ata = this.get6ervi%e1ata6etPQ.%reateP";(6ervi%e1ata"QS // 6et the val-e o# the 61E to a ;(6ervi%e1ata5(pe instan%e ;(6ervi%e1ata5(pe s" = new ;(6ervi%e1ata5(pe PQS

servi%e1ata.setCal-ePs"QS // 6et initial val-es o# ;(6ervi%e1ata a".set)ameP"test"QS // 2"" 61E to 6ervi%e 1ata 6et this.get6ervi%e1ata6etPQ.a""Pservi%e1ataQS

-s shown in 8isting 1$.1:, these are the steps we add it to the service data set(

ust follow to create an 35B and

Create a new 35B b" calling the create ethod of the service instance0s service data set with a uni!ue na e or GAa e. This 35B is initiall" e pt" and has no value. #n our e.a ple, the na e of the 35B will be 1"3ervice5ata with an e pt" na espace. 3et a value for the 35B. The value of the 35B of t"pe 1"3ervice5ataT"pe. 3et the initial values of 1"3ervice5ataT"pe. -dd the 35B to the service data set.

The client ust be aware of this 35B and 35B t"pe to work with the above e.a ple. #t can find out the available 35Bs through service introspection using the )find3ervice5ata) operation on the grid service with )service5ataAa e.) This operation should list all the available 35Bs in the service. 0ervi#e )ata !rom 0ervi#e "nnotation /e can now turn our attention to the third echanis of creating service data using Cava service docu entation and associated tools, or doclets. This process includes a service annotation, running tools to create the service data callback classes and corresponding service data ele ent /358, and finall" registering these callbacks with the service data wrapper upon service startup. 8et us go through each step(

-nnotate Cava service i ple entation with service data ele ent infor ation

,isting 12.14. ' service 3ava file decorated #ith %ervice data element definition.
/00 0 5he %-rrent val-e o# the li#e%(%le. 0 Zogsa:servi%e "ata 0 0 0 name = "%-rrentLi#e%(%leCal-e" minN%%-rs = "1" maxN%%-rs = "1"

0 0/

m-ta3ilit( = "m-ta3le"

p-3li% string getCal-ePQ throws ,emoteEx%eption R ret-rn %-rrentLi#e%(%leCal-eS T

8isting 1$.1; illustrates two concepts( how to define the service data ele ent using the service annotation and how we can define the callback for service data values. The above callback ethod gets registered with the service data wrapper class upon service instance startup. This ethod is invoked each ti e so eone tries to access the service data ele ent )current8ifec"cleKalue.)

+un tools to create the corresponding service data wrapper class and service data ele ent definition.

*nce we are done with the above annotation on the service, then we can run the ),avadoc) co and with a GT%-provided )3ervice5ata5oclet) callback class on this service file. This e.tracts all the service data and creates a 3ervice5ata-nnotation class that corresponds to the above definition, and stores it in a disk file with an e.tension of )-sd-nnotation.) *nce we have created the above file, we can e.port the service data ele ent definitions to the /358 using the )Generate355) tool.

+egister the callbacks with the service i ple entation.

The registration of the 3ervice5ata-nnotation classes as callbacks are done during service initialization using the calls found in 8isting 1$.1<.

,isting 12.1;. %ervice data annotation callback setu

// li#e%(%le %all3a%&s

rocess.

p-3li% voi" post*reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eption R 6ervi%e1ata2nnotation.set-p6ervi%e1ataPthisJ servi%e1ataQS T

This results in the 3ervice5ata-nnotation class loading the alread" created )sd-nnotation) file, setting up the callback with the service data wrappers, and adding the service data ele ent with the service data set.

Important In(ormation on 'ervice Data %lement "*pes and "heir 3alues

Bach service data ele ent has a t"pe associated with it, which can be used to define an 918 sche a t"pe of the 35 value. This is shown below in the 35B definition.
<s":servi%e1ata name="gri"6ervi%e!an"le " t(pe="ogsi:!an"le5(pe " minN%%-rs="0" maxN%%-rs="-n3o-n"e"" m-ta3ilit(="exten"a3le" mo"i#ia3le="#alse" nilla3le="#alse"/>

The above e.a ple shows a )t"pe) attribute associated with the service data ele ent. Aor all" speaking, upon running the tools 6/358$Cava7 a corresponding Cava t"pe gets generated fro the above 935 t"pe. /e can use this t"pe directl" in our progra to create new 35B values. The e.a ple below shows the t"pe generated b" running /358$Cava.
pa%&age org.gri"#or-m.ogsiS p-3li% %lass !an"le5(pe implements Uava.io.6erialiGa3leJ org.apa%he.axis.en%o"ing.6imple5(pe R

private org.apa%he.axis.t(pes..,/ val-eS

p-3li% !an"le5(pePQ R

// 6imple 5(pes m-st have a 6tring %onstr-%tor

p-3li% !an"le5(pePorg.apa%he.axis.t(pes..,/ val-eQ R this.val-e = val-eS T

0ervi#e )ata =uer( 0upport in GT3 Guer" on service data is the ost co ple. and powerful capabilit" provided b" the *G3# specification. 4ased on *G3#, ever" grid service e.poses a )find3ervice5ata) operation which allows the client to !uer" the service for the service data. The default !uer" supported b" the fra ework is based on the service data na e 6)!uer"4"3ervice5ataAa e)7. 2owever, we know that the specification provides an e.tensible !uer" capabilit" b" allowing service to provide different !uer" echanis s. 3o e of the notable !ueries we can think of are Guer" b" 9Path, 9Guer", and 3G8. GT% supports a plug-and-pla" !uer" fra ework to support these re!uire ents to an agreeable level. #t provides facilities for e.tensible !uer" engine support. - service provides support to add a !uer" e.ecution engine of our choice. This !uer" engine provides capabilities for adding an" nu ber of !uer" e.pression evaluators. 3o e of the e.pression evaluators supported in GT% are( 1. 3ervice5ataAa eBvaluator $. 3ervice5ataAa e3etBvaluator %. 3ervice5ataAa e5eleteBvaluator &. 3ervice5ata9PathBvaluator /e can see the Guer" ?ra ework ob,ect odel in ?igure1$.=.

Figure 12.A. %ervice @uery frame#ork.

8et us go through these available evaluators found in GT%. /e will e.plore the details on the !uer" e.ecution feature in the ne.t section.

3ervice5ataAa eBvaluator. This is a si ple evaluator that enables the client to call the service to get service data values, using the service data ele ent na es. The client invokes a )find3ervice5ata) operation to start the !uer" e.ecution process. 3ervice5ataAa e3etBvaluator. This evaluator enables the client to call the service to set service data values for service data ele ents identified b" their GAa e. The addition of ele ents to a service data value depends on the other constraints, including in*ccurs, a.*ccurs and utabilit". The client invokes a )set3ervice5ata) operation to start this !uer" e.ecution process. 3ervice5ataAa e5eleteBvaluator. This evaluator enables the client to call the service to delete service data ele ents identified b" their GAa e. The client invokes a )set3ervice5ata) operation to start the !uer" evaluation process. 3ervice5ata9PathBvaluator. This is a co ple. evaluator to enable the client to call the service to evaluate an 9Path e.pression on service data ele ents. The client invokes a )find3ervice5ata) operation to start the !uer" evaluation process. /e will e.plore the details below. -nother notable feature is the abilit" to register the engine and evaluators at different levels. Aor all" speaking, these ob,ects are registered at the service level, but we can also register the at the global factor" level. This enables the service to use an engine of choice at runti e.

%ervice Data &etrieval and Transformation %u ort

The 3ervice 5ata fra ework provides a nu ber of echanis s to enable !uer" support. This includes echanis s to transfor service data values to(

918 docu ent where we can appl" the 9Path 918 string -pache -9#3 1essageBle ent *b,ect arra"s

+nternal Buery 7rocessing +nformation

Bver" service instance has a !uer" engine and each !uer" engine has a nu ber of !uer" evaluators. - service-specific !uer" engine a" contain a parent engine to delegate e.pressions that it cannot handle. The global !uer" engines are nor all" initialized at the factor" level 6global !uer" engines7. The local engines are set at the service instance level. The nor al processing se!uence of a !uer" engine is in ?igure 1$.1>.

Figure 12.1C. 5ormal rocessing se@uence of a @uery engine in "T3.

Custom =uer( 'ngines and 'valuators /e can write our own !uer" engine b" inheriting fro Guer"Bngine interface. This !uer" engine can be registered as part of the service instance, or can beco e a global engine. -s shown in the configuration in 8isting 1$.1=, we can set the default evaluators available for the container.

,isting 12.1A. Buery engine and evaluator configurations.

<parameter name="'-er(Engine" val-e="%om.ph.test.m(+-er(Engine/mpl"/> <parameter name="'-er(Eval-ators" val-e="org.glo3-s.ogsa.impl.%ore.servi%e.6ervi%e1ata)ameEval-ator org.glo3-s.ogsa.impl.%ore.servi%e.6ervi%e1ataF4athEval-ator org.glo3-s.ogsa.impl.%ore.servi%e.6ervi%e1ata)ame1eleteEval-ator org.glo3-s.ogsa.impl.%ore.servi%e.6ervi%e1ata)ame6etEval-ator"/>

-s shown in ?igure 1$.1>, on the )find3ervice5ata) call, our engine will be called to e.ecute the !uer" with the current service data set of the service instance and the !uer" e.pression. *ne thing to notice is that the real !uer" e.ecution functionalit" is occurring at the evaluators registered with the engine. #t is possible to register a global !uer" engine with our local !uer" engine, such that we can delegate the calls to that engine for the e.pressions we have not designed. This is a fle.ible and hierarchical approach. ?or e.a ple, it helps us write global !uer" engines with ore general !uer" handling echanis s 6Guer"3ervice5ata4"Aa e or 9Path7, while our service can i ple ent ore specific evaluators for the service.

-nother interesting aspect of *G3# and GT% is the capabilit" to discover the !ueries supported b" a service using the )find3ervice5ata) operation with the input e.pression )find3ervice5ataB.tensibilit".)

D7ath Buery %u ort in "T3

8et us e.a ine how the 9Path !uer" is supported b" the GT% fra ework. /e can perfor an 9Path !uer" b" issuing a )find3ervice5ata) operation on the service instance and passing a 3ervice5ata9PathGuer"B.pressionT"pe ob,ect as the para eter. The structure of this e.pression t"pe is shown in 8isting 1$.$>.

,isting 12.2C. D7ath e2 ression ty e.

<%omplex5(pe name="6ervi%e1ataF4ath+-er(Expression5(pe"> <se'-en%e> <element name="name" t(pe="+)ame"/> <element name="F4ath" t(pe="string"/> <element name="namespa%es" t(pe="string" minN%%-rs="0" maxN%%-rs="-n3o-n"e""/> </se'-en%e> </%omplex5(pe>

3ince 9Path !ueries are going to be the fle.ible approach for service data !uer", we need a detailed discussion on its capabilities and usage odel. These ele ents in 8isting 1$.$> are(

The na e ele ent denotes the na e of the service data ele ent to which we are appl"ing the !uer". This can be a wildcard, which specifies appl"ing the 9Path on the service data ele ents that atch. This a" result in an arra" of result ele ents for the 9Path !uer". The 9Path para eter represents the real 9Path e.pression for the service data ele ent identified b" the na e para eter. ?inall", a set of na espace arra"s that re!uire special attention. This na espace arra" is used to conve" the na espace of the nodes of the service data ele ent in the 9Path !uer". #f na espace appings are not provided, the default behavior is to use the current conte.t node, the 35B root ele ent, to resolve the na espaces. 2owever, this a" not be sufficient when searching for child nodes, which contain na espace attributes that are not present in the root node. *ne ust be careful to provide all possible na espaces of interest that are likel" to be encountered when traversing the 35B. There are so e

9Path -P#s, including local-na e67 and na space-uri67, to overco e this proble but a" not be sufficient for all cases. 8et us now review so e sa ple 9Path !ueries. ?or e.a ple, the code in 8isting 1$.$1 e.plains how we can do this in GT%. This code shows how to write an 9Path to test whether the service supports 9Path !ueries.

,isting 12.21. ' sam le D7ath e2 ression.

xmlns:gs"l=http://www.gri"#or-m.org/namespa%es/2002/10/gri"6ervi%es //gs"l:'-er(Expression5(peV.=Mgs"l:'-er($(6ervi%e1ataF4athM

/e will see in the ne.t chapter so e runti e sa ple codes that detail the service data usage and the application of !uer" on the service data. 0ervi#e )ata Change oti!i#ation The ost i portant part of a distributed s"ste is the capabilit" to send as"nchronous essages to the interested parties on so e topic of interest. The *G3# specification provides a standard echanis to send as"nchronous essages on state changes. This provision is handled through a set of *G3#-provided interfaces, Aotification3ource, Aotification3ubscription, and Aotification3ink, respectivel". /e have alread" discussed the behaviors e.hibited b" these interfaces in the last section. Aow we will focus our discussion on the GT% i ple entation aspects of these interfaces. There are two i portant aspects to this notification( ake service available for notification and enable service data to send notification essages on its state change. 8et us now discuss these concepts in greater detail.

(ake %ervice 'vailable for 5otification

- service can e.pose to its clients, for Aotification purposes, b" i ple enting the Aotification3ource interface. /e have alread" discussed the operation provider concepts, which allow a service to e.pose so e of the core operations through an e.ternal echanis , rather than i ple enting this b" itself. GT% provides a default Aotification3ource provider, which enables us to do that. 3ee 8isting 1$.%, which shows how we can e.pose our operating s"ste service with the Aotification3ource interface. The client can now subscribe for notifications on service data changes. The default i ple entation supports subscription of the t"pe )subscribe4"3ervice5ataAa es) subscription. The other possible subscriptions a" include )subscribe4"9Path.)

Figure 12.11. The "T3- rovided service notification rocess.

-nother notable feature is that this fra ework is a topic-based essaging fra ework. 4" default, when the client subscribes for notification on a service data change, a topic will be created for the service data na e. This topic will be evaluated before sending a change notification to the client. /e can now e.tend the above topic-based concept to other areas of notifications, such as enabling a service to send a notification on so e topic of interest other than the service data na e. ?or e.a ple, our operating s"ste service wants to send a notification on a call to its ethod )reboot.) /e can do that easil" b" letting the service instance register a new topic called )+eboot) with the notification provider. This is, nor all" speaking, on our service preCreate67 ethod. The service instance can then send a notification essage during the reboot operation. This is illustrated in 8isting 1$.$$.

,isting 12.22. %ervice sending notifications.

p-3li% %lass Nperating6(stem/mpl exten"s 8ri"6ervi%e/mpl R )oti#i%ation4rovi"er provi"er = n-llS p-3li% voi" post*reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eption R tr( R s-per.post*reateP%ontextQS this.provi"er = P)oti#i%ation4rovi"erQ get4ropert(P6ervi%e4roperties .)N5/O/*25/N)I6N.,*EQS

// %reate a 5opi% an" a"" that to the provi"er this.provi"er.a""5opi%P",e3oot)oti#i%ation;essage"Jnew

+)ameP"http://%om.ph.sample/%mm/Nperating6(stem"J ",e3oot)oti#1ata5(pe"QQS T %at%h PEx%eption eQ R throw new 8ri"6ervi%eEx%eptionPeQS T T

p-3li% voi" re3ootPQ throws ,emoteEx%eption R // "o re3oot an" in#orm o-r listeners tr( R this.provi"er.noti#(P " ,e3oot)oti#i%ation;essage"J new ,e3oot)oti#1ata5(pe P"5he s(stem re3oote""Q QS T %at%h PEx%eption eQ R T T ............................ T

-nable %ervice Data to %end 5otification on %tate $hange

The service data set is associated with a service instance, and it provides echanis s to register listeners to receive notifications on service data changes. +egarding a service data change, the service data wrapper sends a change notification essage to the service data set, and it will then evaluate the change and send the essage to the interested parties. -s shown in the above se!uence diagra , the listener can evaluate the change with the topic created during subscription. #f the change is valid for the constraints e.pressed in the topic, then a separate thread is created to deliver the change essage. The process we have ,ust described and shown is a si ple notification echanis service data change. /e can envision and progra this to co ple. situations, including service stage changes, d"na ic notification topics, and so forth. on

-nother value-added enhance ent a" be the support for a broker, and how it can reside between the grid service clients and the service instance, as shown in ?igure

1$.1$. This enables a ore fle.ible odel with different transport bindings and notification echanis s 6e.g., pub-sub'topic, and so forth7.

Figure 12.12. The notification broker.

Client Programming 3odel /e discussed in the architecture chapter that the *G3#, and in turn the GT%, do not dictate an" specific progra ing odels for the client. The client is based on the C-9-+PC progra ing odel. 4" default, it provides -pache -9#3 client-side fra ework, tools, and runti e. GT% provides a set of helper classes to deal with the concepts surrounding G32s, its resolution to G3+, and G3+ introspection without client involve ent. GT%, in fact, provides a nu ber of tools to deal with these e.tensions and add grid service behaviors to the nor al C-9-+PC stubs. /e will discuss the details on these tools later in this chapter. ?igure 1$.1% shows the e.tension to the C-9-+PC progra service locator construct. ing odel through the

Figure 12.13. "rid service client hel er class and usage.

The basic client-side invocation pattern is(

- client accesses the G32 to a service fro a registr", or so e other out-ofband echanis s. The client passes this handle to the service grid locator, that in turn talks to the handle resolution service to dereference the G32 to a service G3+. The resolution process constructs and associates the instance address with the

necessar" stub. The pro.", so generated, e.poses the C-9-+PC st"le interface to the service.

The client calls service invocation odel.

ethods on that pro." using the nor al C-9-+PC

8et us now spend so e ti e understanding aspects of the client-side progra ing odels provided b" C-9-+PC. /e can alwa"s write GT% clients that can support the entire C-9-+PC progra ing odel invocations. 4ased on C-9-+PC specifications, there are three different service endpoint fro a client, as shown in ?igure 1$.1&. odels for invoking a

Figure 12.1!. 3'D-&7$ client-side rogramming models.

These client-side progra ing odels are independent of an" specific service i ple entation or endpoint odel, however, provide well-defined interfaces for the users. /e will e.plore the details of each in the following discussion.

%tub-8ased (odel )%tatic %tubs*

These static stub classes are created either fro the /358 or fro a service endpoint interface. - generated stub class is re!uired to i ple ent both Cava... l.rpc.stub and the service endpoint interface. This stub interface provides -P#s to configure stubs b" setting properties such as endpoint address, t"pe apping, session, user na e, password, and so on.

Dynamic 7ro2ies
#n contrast to the static stubs discussed above, the client at runti e creates these d"na ic pro." stubs using the Cava... l.rpc.3ervice interface. The client has a priori knowledge of the /358 and the service it is going to invoke. #t uses the 3ervicefactor" classes to create the service and get the pro.".

D++ )Dynamic +nvocation +nterface*

This software pattern eli inates the need for clients to know in advance a service0s e.act na e, operations, and para eters. - 5## client can discover this infor ation at runti e using a service broker that can look up the service description 6/3587.

GT3 Tools

Transformation Tools
/e know fro our earlier discussion that grid services are stateful /eb services and are hosted in a /eb service hosting environ ent. ?or e.a ple, GT% is deplo"ed to the -pache -9#3 /eb service container environ ent. This necessitates the need to convert so e of the grid-specific e.tensions to /eb service operateable entities. 1ost notable of this transfor ation is the transfor ation of ultiple interface inheritance in *G3# grid service to a single interface /eb service odel. This re!uires tooling to do the transfor ation fro *G3#-defined G/358 to /358 1.1. G/358$/358. This is an interesting tool that re!uires a detailed discussion. #n the previous section, we have discussed the G/358 na espace and how *G3# supported the open portT"pe e.tensions and portT"pe inheritance odel using the G/358 portT"pe. *G3# allows ultiple portT"pe inheritance and open content odel for portT"pes. This fle.ibilit" is not available with /358 1.1 and hence developers can use the new G/358 na espace and G/358 portT"pe provided b" *G3# specification to create this ultiple inheritance and portT"pe e.tensibilit" odel. *nce /358 1.$ beco es standard, fra eworks and tools will support this feature. 2owever, in order to support the current /3581.1 tools and fra ework, *G3# G/358 portT"pes are converted to the /358 1.1 based single portT"pe odel. This tool is used to transfor G/358 portT"pe definitions to the corresponding /358 1.1 definition. ?igure 1$.15 illustrates how a G/358 with the )*perating3"ste ) portT"pe has an inheritance hierarch" is converted to a /358 1.1 )*perating3"ste ) portT"pe odel single interface using the G/358$C-K- tool.

Figure 12.10. Transformation of 9"%+ "?%D, to ?%D, 1.1 using the "?%D,2?%D, tool.

-s developers and senior technical leaders, we should be aware of the i portant aspects about this conversion( 1. - new /358 port t"pe is constructed containing the sa e operations as the G/358 port t"pe, as well as all operations fro the e.tended port t"pes. $. -ll operations essages are !ualified with the na espace definitions as defined originall" and hence no operation overloading is allowed. %. The na e of the new /358 portT"pe is the sa e as the na e of the old G/358 portT"pe. &. The newl" generated /358 keeps the old G/358 portT"pe as a /358 e.tensibilit" ele ent, but does not contain an" operationsMonl" service data. 0ervi#e and Client60ide arti!a#ts #n order to avoid client-side and server-side developers fro dealing with the co ple.it" arshalling and de arshalling of para eter t"pes, creation of artifacts to deal with the /eb service essaging 63*-P7 and support to the progra ing odels 6C-9-+PC7 tools are re!uired. These tools are used to create stubs'pro.ies, language artifacts, t"pe- apping, deplo" ent infor ation, and helper classes. 4elow are so e of the co onl" used GT% tools.

Generate4inding. - /358 file can be divided into an abstract portT"pe representation, and a valid binding representation. Aor all" speaking, clients do not need to be concerned with the valid binding generation. GT% provides this tool to generate the necessar" binding infor ation for a given portT"pe.

The default values used b" this tool are )http) for transport binding protocol, )docu ent) for 3*-P essage st"le, and )literal) for essage encoding. This fle.ibilit" helps the clients concentrate on the design of the portT"pe definitions and then use this tool to generate the necessar" bindings. 3a ple usage(
8enerate$in"ing <#ilename>.ws"lJ where the inp-t #ile %ontains the port5(pe "e%laration.

This will generate Ofilena ePWservice.wsdl and Ofilena ePWbinding.wsdl, respectivel".

G358$Cava. This is a special case i ple entation of the /358$Cava tool provided b" -9#3, which is used b" the clients to generate the stubs, bindings, service interfaces, server-side service i ple entation skeletons, and client locator classes. /e can use this tool against a /358 file, which contains the Owsdl(serviceP ele ent declaration to achieve a top-down design odel.

3a ple usage(
861L2Uava servi%e.ws"l

3ervice5ata5oclet. This is running ,avadoc on the Cava service i ple entation code with GT%-provided )doclet) callback class )org.globus.ogsa.utils.3ervice5ata5oclet.) This results in the creation of 3ervice5ata-nnotation class for each service data ele ent defined in the service file. ?inall", all these generated 3ervice5ata-nnotation classes will be du ped into a file with OclassAa eP)-sd-nnotation.)

@sage(
Uava"o% <org.glo3-s.ogsa.-tils.6ervi%e1ata1o%let> <servi%e implementation Uava #ile>

Generate355. This utilit" tool reads the above generated service class file with 35 annotations and collects all the service data ele ents in the file stored as 3ervice5ata-nnotation list and then adds those service data ele ents to the specified /358.

3a ple usage(
8enerate611 <ws"l "e#inition #ile> <%lass name with servi%e "ata annotations>

GT3 Con!iguration GT% uses -9#3 /355 to configure

the services and its para eters C-9-+PC and -9#3 handlers and the para eters needed for the handlers +e!uest and response flow with the handlers Global para eters for -9#3 engine and the GT% container

8isting 1$.$% shows such a deplo" ent configuration file with one service in it. /e will use this listing for our discussion of the server-side deplo" ent configuration.

,isting 12.23. ' sam le server-config.#sdd.

<"eplo(ment ....> <glo3al*on#ig-ration> <parameter name="a"min4asswor"" val-e="a"min"/> <parameter name="sen";-lti,e#s" val-e="tr-e"/> ............................................. <re'-estOlow> <han"ler t(pe=".,L;apper"/> <han"ler t(pe="4ersistent6ervi%e!an"ler"/> ............................................. <re'-estOlow>

<responseOlow> <han"ler t(pe=",o-ting,esponse!an"ler"/> ............................................ </responseOlow> </glo3al*on#ig-ration> <transport name="http"> <re'-estOlow> <han"ler t(pe=".,L;apper"/> <re'-estOlow> <responseOlow>

............................................ </responseOlow> </transport>

<servi%e name="ogsa/%mm/Nperating6(stem6ervi%e" provi"er="!an"ler" st(le="wrappe"" -se="literal">

<<= servi%e #a%tor( name

>

<parameter name="name" val-e="Nperating s(stem 4rovi"er #a%tor("/>

<<= servi%e instan%e spe%i#i% in#ormation

>

<parameter name="instan%e name" val-e=" Nperating s(stem 6ervi%e"/> <parameter name="instan%e s%hema4ath" val-e= "s%hema/%ore/%mm/operatings(stemIservi%e.ws"l"/> <parameter name="instan%e %lass)ame" val-e= "org.ogsa.%ore.%mm.Nperating6(stem4ort5(pe"/> <parameter name="instan%e 3ase*lass)ame" val-e= "/> "org.ogsa.%ore.%mm.impl.Nperating6(stem/mpl <parameter name="instan%e operation4rovi"ers" val-e= "org.ogsa.%ore.%mm.impl.Nperating6(stem4rovi"er"/>

<<= servi%e #a%tor( spe%i#i% in#ormation

>

<parameter name="s%hema4ath" val-e="s%hema/ogsi/ ogsiInoti#i%ationI#a%tor(Iservi%e.ws"l"/> <parameter name="3ase*lass)ame" val-e="org.glo3-s.ogsa.impl.ogsi.4ersistent8ri"6ervi%e/mpl"/> <parameter name="han"ler*lass"

val-e="org.glo3-s.ogsa.han"lers.,4*.,/4rovi"er"/> <parameter name="%lass)ame" val-e="org.gri"#or-m.ogsi.)oti#i%ation#a%tor("/> <parameter name="allowe";etho"s" val-e="0"/>

<parameter name="#a%tor(*all3a%&" val-e="org.glo3-s.ogsa.impl.ogsi.1(nami%#a%tor(*all3a%&/mpl"/> <parameter name="operation4rovi"ers" val-e="org.glo3-s.ogsa.impl.ogsi.#a%tor(4rovi"er org.glo3-s.ogsa.impl.ogsi.)oti#i%ation6o-r%e4rovi"er"/>

<<=5his servi%e is a 8ri" servi%e

>

<parameter name="persistent" val-e="tr-e"/> <parameter name="allowe";etho"s" val-e="0"/> </servi%e> </"eplo(ment>

/e will e.a ine the service-specific configuration re!uire ents. @pon careful e.a ination of 8isting 1$.$%, we can see that the service has a uni!ue service na e 6re otel" accessible na e of the service7 using a )wrapped) essage st"le and the provider is a handler. This enables the -9#3 achine to dispatch the calls to the GT%provided container and instantiate the service inside the GT% container. 8et us now see the specific para eters utilized for the grid service. Aote that we a" find an -.is /eb service along with grid services in a container. /e can easil" identif" grid services if the" have a para eter )persistent) with a value of )true.) /e ust be aware of this i portant distinction. Table 1$.$ lists all the para eters of interest for grid services. To help us understand better, note that the para eters starting with instance are specific to the service instance while others a" be for a factor" or other providers.

Table 12.2. De loyment and $onfiguration 7arameters

Parameter classAa e )es#ription This class specifies a class or an interface that has public

Table 12.2. De loyment and $onfiguration 7arameters

Parameter )es#ription ethods corresponding to all operations in the /358. This interface'class ust e.pose all the operations e.posed b" the service and providers. persistent #f this attribute value is true, it represents a G+#5 service. *therwise, a nor al /eb service using -pache -.is. The na e of the class that i ple ents the service. #f this is the sa e as the classAa e para eter, this is optional. The list of classes to be loaded along with the service. Aote that order indicates the initialization order. This handler specifies the dispatcher to use at the server side. -9#3 engine dispatches the call to this dispatcher 6pivot handler7. The /358 of the service identified b" classAa e. The factor" callback class used to create a service. This identifies the na e of the service instance to be created.

baseClassAa e

operationproviders

handlerClass

sche aPath factor"Callback instance-na e

instance-sche aPath This indicates the service instance /358. instance-classAa e instancebaseClassAa e instance*perationproviders This indicates the service instance class na e. This indicates the service instance base class na e.

8ists the service instanceQspecific operation providers.

#n addition to the above configuration para eters, there are other service-specific and global configurations, such as static t"pe- apping, !uer" engine'evaluator, lifec"cle, and container-specific configurations, which act upon host na e, port na e, and apping. GT36Provided )e!ault Implementation Classes

GT% provides a nu ber of built-in classes to provide so e default functionalit", which helps the service and client developer to hide the co ple.it" of a grid service progra ing odel. /e have alread" covered ost of these classes in the earlier sections. #n Table 1$.%, we list so e of these classes for !uick reference.

Table 12.3. "T3-7rovided Default +m lementation $lasses

7sed B( 40ervi#e<Client5 )eveloper 3ervice

Class ame
8ri"6ervi%e$ase/mpl, 4ersistent8ri"6ervi%e/mpl

)es#ription Provides the basic grid service behaviors and lifec"cle anage ent functionalities. Grid service can be i ple ented b" deriving fro these classes.

#a%tor(4rovi"er, 1(nami%#a%tor(*all3a%&/mpl, 1(nami%#a%tor(Li#e%(%le*all3a%&/mpl

This factor" provider 3ervice is an operation provider and these classes together provide a service instance creation fra ework. 5efault handle 3ervice resolution service operation provider. 4" default it supports http and https protocols. These classes 3ervice together provide the support for a service notification fra ework. This fra ework enables a topic whereb" a service can support different topics. 4"

!an"le,esolver4rovi"er

)oti#i%ation6o-r%e4rovi"er, )oti#i%ation6-3s%ription/mpl

Table 12.3. "T3-7rovided Default +m lementation $lasses

7sed B( 40ervi#e<Client5 )eveloper

Class ame

)es#ription default all service supports notification on )service data na e.)

<port5(pe)ame>6ervi%e8ri"Lo%ator

- client-side helper Client class that provides the C-9-+PC progra ing odel but hides the details of grid e.ecution workflow including handle resolution, G3+ validation, and stub address anage ent through G3+ location address. #n addition, supports the nor al /eb service calls.

/e will see the utilization of these default classes in the ne.t chapter. 0igni!i#an#e o! 3essage Handlers in GT3 1essage handlers provide additional essage-handling facilities to the /eb'grid service endpoints 6both client and server7 as e.tensions to the basic service i ple entation logic. -s we have seen in the architecture section, these handlers can anage encr"ption and decr"ption, logging and auditing, and so on. 4" now we are alread" fa iliar with this powerful feature and its use with GT%. There are two t"pes of handlers supported in -9#3, C-9-+PC handlers and the default -9#3 handlers. The C-9-+PC handlers are based on the C-9-+PC specification whereas the -9#3 handlers are native to -9#3 fra ework. *n runti e, -9#3 wraps these C-9-+PC handlers using an -9#3 standard handler 6C-9+PC2andler7. 4eing the core i ple entation part of the s"ste , we can spend so e ti e anal"zing these handlers and their usage patterns. C";62PC Handlers

The current C-9-+PC runti e s"ste defines onl" 3*-P essage handlers. The C-9-+PC runti e s"ste can fle.ibl" define other handlers and is free fro an" processing odel of the essages. The C-9-+PC 2andlers -P# defines three basic ethods, as shown in 8isting 1$.$&. ethods, along with two lifec"cle

,isting 12.2!. 3'D-&7$ handler methods.

pa%&age Uavax.xml.rp%.han"lerS p-3li% %lass !an"lerR han"le,e'-estP;essage*ontext %ontextQS han"le,esponseP;essage*ontext %ontextQS han"leOa-ltsP;essage*ontext %ontextQS

initP!an"ler/n#o in#oQS "estro(PQS // ret-rn the hea"ers pro%esse" 3( this han"ler +)ameVW get!ea"ersPQS T

The handler invocation pattern is shown in ?igure 1$.1:. - handler should be i ple ented as a stateless instance. 4" providing the initialization interface 62andler.init I2andler#nfo infoJ7, the runti e s"ste can pass the re!uired conte.t infor ation to the handler. This will help a handler obtain access to container-specific value-added features, including authentication echanis s, transaction processing, logging fra ework, and so on.

Figure 12.11. %ervice and handler invocation model.

- handler chain represents an ordered list of handlers. This grouping helps to define policies that we want to associate with the handler invocation odel. B.a ples of

such policies include order of invocation, st"le of invocation 6for e.a ple, one-wa" call invokes onl" handle+e!uest67F no handle+esponse677, and so on. This association can be configured to the handler through the 2andler.init67 ethod passing a 2andler#nfo ob,ect. The handler chain continues processing the handlers onl" if the current processing handler returns )true.) 8isting 1$.$5 shows a sa ple i ple entation of a handler that can access a 3*-P essage header.

,isting 12.20. %am le handler im lementation.

4-3li% %lass E66e%-rit(!an"ler exten"s 8eneri%!an"lerR 4-3li% $oolean han"le,e'-estP;essage*ontext %txQR tr(R 6N24;essage*ontext m% = P6N24;essage*ontextQ%txS 6N24;essage msg = m%.get;essagePQS 6N244art sp = msg.get6N244artPQS 6N24Envelop se = sp.getEnvelopPQS 6N24!ea"er hea"er= se.get!ea"erPQS

// )ow we %an pro%ess the hea"er 1o%-ment "o% = E66e%-rit(,e'-estEngine.getEnginePQ. pro%ess6e%-rit(!ea"erPseJ %txQS i# Pse%-rit( vali"ation is #ine Q ret-rn tr-eS //%ontin-e pro%essing elseR //,et-rn #alse res-lts in %haining to stop ret-rn #alseS T T%at%hPEx%eption exQR T T ....................... T

-s shown in 8isting 1$.$5, this is a si ple handler i ple entation to validate /33ecurit" headers. The Generic2andler is a C-9-+PC-provided default )2andler) i ple entation class. #t is reco ended to use C-9-+PC handlers wherever possible for interoperabilit" purposes. These are C$BB'C$3B standard based and, hence, can be ported to an" environ ent. ";I0 Handlers 4efore C3+ 1>1, the -9#3 decided to establish a standard for 3*-P essage processing, resulting in the generation of widel" accepted -9#3 handlers. This is different fro C-9-+PC handlers. The ost co onl" used interface ethod is the )invoke.) 3ee 8isting 1$.$:.

,isting 12.21. 6andler methods.

pa%&age org.apa%he.axis S p-3li% %lass !an"lerR p-3li% voi" invo&eP;essage*ontext msg*ontextQ throws 2xisOa-lt S p-3li% voi" onOa-ltP;essage*ontext msg*ontextQS p-3li% 3oolean %an!an"le$lo%&P+)ame 'nameQS p-3li% voi" initPQS ....................... T

-s shown in the code in 8isting 1$.$:, the C-9-+PC handlers -P# defines three basic ethods, along with two lifec"cle ethods. The code in 8isting 1$.$; e.plains a sa ple i ple entation of a handler that can access a 3*-P essage header.

,isting 12.24. %am le 'D+% handler im lementation.

p-3li% %lass !an"le,esolver!an"ler exten"s $asi%!an"ler R

p-3li% voi" invo&eP;essage*ontext message*ontextQ throws 2xisOa-lt R tr( R 6tring target = P6tringQ message*ontext.get5arget6ervi%ePQS ....................................

T%at%h PEx%eption eQ R throw 2xisOa-lt.ma&eOa-ltPeQS T T p-3li% voi" onOa-ltPQR // to "o a #a-lt pro%essing T T

/e have alread" noticed that one of the ain differences between the -9#3 handler and the C-9-+PC handler is the return value. #n C-9-+PC a value of true or false indicates the continuation of the e.ecution process. - value of )false) will stop the handler chain e.ecution process. #n the case of -9#3 handler an e.ception ust be thrown to stop the processing. -ll the handlers that previousl" processed this specific essage get a chance to do so e fault processing using an )on?ault) operation. This feature is not andated in the C-9-+PC handlers. GT3 0e#urit( Implementation and Programming 3odel #n the previous architecture section, we did ention the available securit" echanis in GT%, which are transport-level G3# securit" and essage-level securit". /e also entioned that the transport level securit" would be depreciated in the co ing Globus toolkit releases in favor of essage-level securit". The GT% essage-level securit" is based on /3-3ecurit" and associated standards 6/3-3ecureConversation, /3-Trust, and so forth7. *ur discussion would concentrate around the essage-level securit" part of the GT%. This discussion includes the details on securit" architecture, the progra ing aspects, and deplo" ent'configuration re!uire ents. The essage-level securit" is based on /3-3ecurit", 918 Bncr"ption, and 918 3ignature standards. /e did cover these topics earlier in the book when we talked about /eb services and global 918 architecture. The GT% fra ework provides two different essage-level authentication echanis s(

G3# 3ecure Conversation. #n this protocol, at first, a secure conte.t is established between the client and the service. *n the subse!uent calls to the service this conte.t is used to sign'verif"'encr"pt'decr"pt the essages. ?igure 1$.1; illustrates a high-level view of this secure conversation.

Figure 12.14. "%+ secure conversation.

G3# 918 3ignature. This process is si ple, where a given set of credentials.

essage is signed with a

GT3 0e#urit( Handlers #n GT% the securit" is handled b" using a nu ber of -9#3 and C-9-+PC handlers. ?igure 1$.1; shows the essage flow and the available handlers 6so e of the 7. The figure depicts a secure conversation establish ent between the client and server. This needs an e.change of tokens to establish a conte.t. *nce the conte.t is established, that conte.t token is used to secure the essage. GT% provides services to establish the token, and revalidate the token in case of e.pir". /e will discuss internal details on the secure conte.t establish ent process later in this section. Aow, let us do a !uick overview on so e of the ost co secure the essage e.change in GT% using Table 1$.&. onl" used handlers to

Table 12.!. $ommon %erver-%ide 6andlers

GT3 0e#urit( Handlers 2e8uest<2esponse )es#ription +esponsible for apping inco ing G3# 3ecure Conversation re!uests to authentication service.

-uthentication3ervice2andler +e!uest

/33ecurit"2andler

+e!uest'+esponse +esponsible for processing /33ecurit" 2eader ele ents in a 3*-P essage. These essages are delegated to a /33ecurit"Bngine for 918 signature handling and 918 encr"ption'decr"ption. +e!uest This handler in turn loads and e.ecutes two other handlers,

3ecurit"Polic"2andler

Table 12.!. $ommon %erver-%ide 6andlers

GT3 0e#urit( Handlers 2e8uest<2esponse )es#ription -uth2andler and +un-s2andler. -uth2andler is responsible for checking whether the invocation of a ethod on a service is allowed or not. #f the service is available, it needs to be activated to get the ethod-level securit" info. +un-s2andler is used to set the sub,ect for invocation of the ethod. This enables service of a ethod to specif" the identit" re!uired to run. These identities are Caller, 3"ste , or 3ervice level. -uthorization2andler +e!uest The above handlers set the sub,ect for ethod invocation. This handler is tr"ing to authorize the sub,ect based on the service authorization needs. 3ervice specifies this through configuration 6we will discuss details later7. This can be none, self, or grid ap. #f signature is re!uested for the response essage, this handler is used. This handler uses a C--3 lookup to get the credential of the call originator. This originator a" be different fro the threadlevel sub,ect. @sed with G3# 918 signature. #n a G3# secure conversation, the return essage is protected either b" 918 signature or 918 encr"ption.

95>=3ign2andler

+esponse

G332andler

+esponse

The handlers described in Table 1$.& are the ost co onl" used handlers. *ne thing we ust pa" close attention to is the processing se!uence of these handlers. 3o we ust be careful of their order in the configuration file. -nother i portant aspect we ust be aware of is the t"pe of handler. There are two t"pes of handlers available, C-9-+PC and -9#3. The difference is ainl" on the signature and para eters processing. 8isting 1$.$< describes the handler flow.

,isting 12.2;. %ecurity handler configuration in the service side.

<glo3al*on#ig-ration> <parameter name="a-thenti%ation6ervi%e" val-e="gsi/2-thenti%ation6ervi%e"/> <re'-estOlow> ........................ <han"ler t(pe= "Uava:org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation.servi%e .2-thenti%ation6ervi%e!an"ler"/> <han"ler t(pe="Uava:org.glo3-s.ogsa.han"lers.,o-ting6e%,e'-est!an"ler"/>

<han"ler t(pe="Uava:org.glo3-s.ogsa.-tils.U2F,4*!an"ler"> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation.wsse% .E66e%-rit(!an"ler"/> </han"ler>

<han"ler t(pe="Uava:org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation .6e%-rit(4oli%(!an"ler"/> <han"ler t(pe="Uava:org.glo3-s.ogsa.impl.se%-rit(.a-thoriGation .2-thoriGation!an"ler"/> <han"ler t(pe="Uava:org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation .*re"ential,e#resh!an"ler"/> .................................

</re'-estOlow>

<responseOlow> ................................... <han"ler t(pe="Uava:org.glo3-s.ogsa.-tils.U2F,4*!an"ler"> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation.F5096ign!an"ler"/ > </han"ler> <han"ler t(pe="Uava:org.glo3-s.ogsa.-tils.U2F,4*!an"ler"> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation.866!an"ler"/> </han"ler> </responseOlow> </glo3al*on#ig-ration>

<servi%e name="gsi/2-thenti%ation6ervi%e" provi"er="!an"ler" -se="literal"> <parameter name="3ase*lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation.servi%e .2-thenti%ation6ervi%e/mpl"/> .................................. </servi%e> st(le="wrappe""

%ecure 'uthentication %ervice

This grid service 6-uthentication3ervice7 is used to establish a securit" conte.t. This service is configured in the configuration section, as shown in 8isting 1$.$<. #f the authentication service handler is present in the re!uest handler chain, and the service call is targeted toward a secure authentication 6i.e., the target endpoint ends with )'auth3ervice)7, then the calls will be directed to this )-uthentication3ervice) for creating or refreshing the secure conte.t.

This )-uthentication3ervice# pl) class is responsible for secure conte.t establish ent and i ple ents )continueTokenB.change) and )initTokenB.change) ethods. /e will see the internal i ple entation of this call later in the section.

$onfiguring %ervice-% ecific %ecure 'uthentication and 'uthorization +nformation

- service can specif" its authentication and authorization re!uire ents through an e.ternal configuration file. - service infor s the fra ework about this configuration file through its configuration propert" in the /355 file. This is shown in 8isting 1$.$=. The sa ple specifies a )self) authorization process and provides an 918 file for securit" configuration.

,isting 12.2A. $onfiguring a service #ith security information.

<servi%e name="ogsa/%mm/Nperating6(stem6ervi%e" provi"er="!an"ler" st(le="wrappe""> ................................... <parameter name="se%-rit(*on#ig" val-e=" ogsa/%mm/impl/se%-rit( %on#ig.xml"/> <parameter name="a-thoriGation" val-e="sel#"/> ................................... </servi%e>

/e can now e.plore the details of the securit" configurations, as specified through the securit"-config.. l file. - sa ple configuration discussing a secure service is in 8isting 1$.%>.

,isting 12.3C. "T3 security ma

ing file.

<se%-rit(*on#ig xmlns="http://www.glo3-s.org"> <metho" name="%mm:re3oot" xmlns:%mm="http://ogsa.org/%mm/operatings(stem"> <r-n as> <%aller i"entit(/> </r-n as> <a-th metho"> <gsi/> </a-th metho"> </metho">

<<

"e#a-lts

>

<a-th metho"> <none/> </a-th metho">

</se%-rit(*on#ig>

The authorization infor ation in the configuration file enables a service to specif" ethod-level authorization and code e.ecution polic" 6run-as identit"7. ?or e.a ple, this enables the operating s"ste service to specif" the reboot operation to run under the caller0s identit" and use a G3# authorization echanis . This provides finegrained control over ethod e.ecution. #n addition, it enables a service to specif" the authentication ode of choice fro the list of )none,) )gsi,) and )self.) /e can now Table 1$.5. ove on to the co onl" defined client-side securit" handlers listed in

Table 12.0. $lient-%ide %ecurity 6andlers

GT3 0e#urit( Handlers 2e8uest<2esponse 95>=3ign2andler +e!uest )es#ription #f signature is re!uested for the re!uest essage, this handler is used. This is used with G3# 918 signature. This is the core securit" handler responsible for establishing the securit" conte.t. *nce the conte.t is established, it will be associated with the stub. #n a G3# secure conversation, the re!uest essage is protected either b" 918 signature or 918 encr"ption using the conte.t established using 3ecConte.t2andler. +esponsible for handling the response fro the service either with G3# 918 signature or secure

3ecConte.t2andler

+e!uest

G332andler

+e!uest

/33ecurit"Client2andler +esponse

Table 12.0. $lient-%ide %ecurity 6andlers

GT3 0e#urit( Handlers 2e8uest<2esponse conversation )es#ription essages.

The handlers, as shown in Table 1$.5, are the ost co onl" used for the client-side securit" enabling echanis s. The processing se!uence of these handlers is ver" i portant. 3o, we ust be careful of their order in the configuration file. 8isting 1$.%1 shows the usage.

,isting 12.31. $lient-side security configuration.

<glo3al*on#ig-ration> <re'-estOlow> ........................................ <han"ler t(pe="Uava:org.glo3-s.ogsa.-tils.U2F,4*!an"ler"> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation .F5096ign!an"ler"/> </han"ler> <han"ler t(pe="Uava:org.glo3-s.ogsa.-tils.U2F,4*!an"ler"> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation .6e%*ontext!an"ler"/> <parameter name="a-th6ervi%e" val-e="a-to"/> </han"ler> <han"ler t(pe="Uava:org.glo3-s.ogsa.-tils.U2F,4*!an"ler"> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation .866!an"ler"/> </han"ler> </re'-estOlow>

<responseOlow> .................................... <han"ler t(pe="Uava:org.glo3-s.ogsa.-tils.U2F,4*!an"ler"> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.impl.se%-rit(.a-thenti%ation.wsse% .E66e%-rit(*lient!an"ler"/> </han"ler> </responseOlow> </glo3al*on#ig-ration>

$lient-%ide 7rogramming (odel to -nable %ecurity

The following G3# properties can be set on the client stub to control the authentication'authorization process(

The credential to use #t is used to pass a specific set of credentials for authentication. @ser can specif" a credential of t"pe )org.ietf.,gss.G33Credential) instance. 4" default, if not specified, the default user pro." credential is used.

-uthorization

echanis

to use

#t is used to set authorization t"pe to perfor . There are different authorizations available( 3elf-uthorization, 2ost-uthorization, 4asic3ub,ect-uthorization and so on. 4" default, if not specified, host authorization is perfor ed.

G3# delegation This delegation

o o

ode ode can be one of(

G3#Constants.G3#W1*5BWA*W5B8BGM perfor s no delegation 6default7 G3#Constants.G3#W1*5BW8#1#TB5W5B8BGM perfor s li ited delegation G3#Constants.G3#W1*5BW?@88W5B8BGM perfor s full delegation These constants are used for G3# 3ecure Conversation or transport securit" onl". #t is used to set G3# delegation ode.

o o

2ere is a sa ple client-side code snippet that illustrates the usage pattern of these properties(
N86/6ervi%e8ri"Lo%ator #a%tor(6ervi%e = new N86/6ervi%e8ri"Lo%atorPQS #a%tor( #a%tor( = #a%tor(6ervi%e.get#a%tor(4ortPnew !an"le5(pePhan"leQQS

// ena3le 86/ 6e%-re *onversation message level se%-rit( PP6t-3Q#a%tor(Q.Iset4ropert(P*onstants.86/I6E*I*N)CJ *onstants.6/8)25.,EQS // ena3le limite" "elegation PP6t-3Q#a%tor(Q.Iset4ropert(P86/*onstants.86/I;N1EJ86/*onstants.86/I; N1E IL/;/5E1I1ELE8QS // set %lient a-thoriGation to none PP6t-3Q#a%tor(Q.Iset4ropert(P*onstants.2.5!N,/[25/N)J )o2-thoriGation.get/nstan%ePQQS

The handlers described in Table 1$.5 will kick off the securit" enabling process. #t provides essage level securit" through essage signatures and encr"ption without user involve ent. Internal 0e#urit( )esign Work!low )etails

%ecure $onte2t -stablishment

GT% provides a plug-and-pla" echanis for secure conte.t establish ent process. #t defines 3ecure -uthentication service, which i ple ents 3ecureConte.tBstablish entPortT"pe. This service is a stateless Grid service, which in turn talks to other securit" anagers to get hold of a secure token for that service. #n the client-side, a secure conte.t is established for each instance of the stub the client is using to co unicate with the service. These stubs in turn use )3ecConte.t2andler) handler 6defined in client-config.wsdd7 to create and hold the conte.t infor ation. 3ince the conte.t is established for the user associated with the current thread, it is illegal to use the sa e stubs fro other thread. This conte.t is negotiated each ti e there is a change in the G3# ode. The allowable odes include(

?ull delegation 8i ited delegation Ao delegation

Figure 12.1;. $lient-side secure conversation establishment.

This secure conte.t is established b" co unicating to the 3ecure -uthentication 3ervice deplo"ed in the server. ?or this the client has to get the current C--3 sub,ect and credential. ?or G3#, the client contacts the G33 1anager to get the conte.t b" calling anager.createCredentialCall6U7 using the sub,ect and conte.t. Then the client calls the authentication service0s )initTokenB.change) or )continueTokenB.change) ethod depending on whether the call is first ti e or not. This operation is a nor al 3*-P call through an 338. The authentication service returns a conte.t #5 and a binar" token. The client runs this authentication process till the" get the conte.t. *nce the client gets the conte.t, it is attached with the current stub.

?%-%ecurity 6andling
The above secure negotiation creates a secure token and the /3-3ecurit" handler uses this token to sign the essage and encr"pt the essage. This token is passed along with the 3*-P essage header. /ork is going on to define a standard securit" profile for this G3# token e.change through /3-3ecurit" header. 0ervi#e 3essage '+#hange /ogging 4ased upon our e.periences, we find that the ost valuable infor ation we need to collect during essage interaction between a client and a service is the real essages e.changed between the . This is valuable during develop ent of services. The current default GT% configuration enables 3*-P essage e.change over 2TTP. This essage helps us understand the target service, the operations to be invoked, and the essage e.changed. /e can do a nu ber of debugging and co patibilit" tests with these essages. ?or e.a ple, if we can collect a 3*-P essage fro a client to a service, we can do a /3-# basic profile validation on the collected essage to check for co patibilit" with other i ple enters. #n fact, /3-# basic profile tools are working in a si ilar fashion, as we can see in the TCP1on case below. There are three echanis s we can do to enable this essage capture(

1. @sing GT%-provided 1essage2andler in both client and service side. This is the si plest process b" putting a global handler on the client and server side. 8isting 1$.%$ below shows how we can perfor this in our server-config.wsdd and client-config.wsdd files. 2ere is how we account for that in server-config.wsdd(

,isting 12.32. (essaging,ogging6andler configuration.

<re'-estOlow> <han"ler t(pe="Uava:org.glo3-s.ogsa.han"lers.;essageLogging!an"ler"/> ....................... </re'-estOlow>

<responseOlow> <han"ler t(pe="Uava:org.glo3-s.ogsa.han"lers.;essageLogging!an"ler"/> ....................... </responseOlow>

Aote that the essage displa"ed b" this handler is dependent on their position in the configuration handler list. This is because so e handler a" odif" the essage. 3ince handlers are using -pache co on logging echanis s for essage logging, we ust configure that to displa" the essages correctl". 8isting 1$.%% shows a sa ple essage displa"ed b" the above setting.

,isting 12.33. ' sam le %9'7 message.

VB/22/03 13:@0:50:D@9 E15W #9#2320 ;essageLoggin / org.glo3-s.ogsa.han"lers.;essageLogging!an"ler 6N24Envelope: <soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e"> <soapenv:$o"(> <%reate6ervi%e xmlns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <termination5ime ns1:3e#ore="in#init(" ns1:a#ter="in#init(" xmlns:ns1="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <%reation4arameters xsi:nil="tr-e"/>

</%reate6ervi%e> </soapenv:$o"(> </soapenv:Envelope>

$. @sing the TCP1on utilit" with so e configuration changes. @sing the TCP1on utilit", we can rela" all the essages through a TCP port. 3tart the tcp on using
Uava org.apa%he.axis.-tils.t%pmon Vlisten4ort target!ost target4ortW

This will help us displa" ost of the essages flowing through the wire. ?or co ple. situations we a" need to do ore work on the server configuration to get all the essages. This is because the server is odif"ing the d"na ic soap address for the G3+ using the infor ation available with it. This is nor al in the case of handle resolution. #n such situations the client0s call using the above soap address a" not be directed to the tcp on0s port unless we change so e configurations in the server. This includes changing )httpPort) and )sche a+oot) properties. #n so e cases 6distributed achines7 we a" need to change the server host na e too. 8isting 1$.%& indicates how to change the default port nu ber to be displa"ed in the G3+ soap address 6and instance of ele ents7.

,isting 12.3!. ' sam le configuration for setting internal service ort numbers.
<glo3al*on#ig-ration> << to %hange the port n-m3er >

<parameter name="http4ort" val-e=">0>0"/>

<<

to %hange the E61L retrieval s%hema root

>

<parameter name="s%hema,oot" val-e="http://lo%alhost:>0>0/ogsa/"/> ............................................... </glo3al*on#ig-ration>

%. @sing the -pache -9#3 logging feature. This enables us to configure the select -pache -9#3 classes for essage logging. The properties 6ogsilogging.properties7 needed to set are shown in 8isting 1$.%5.

,isting 12.30. $onfiguring message log for ' ache 'D+% messages.
org.apa%he.%lient.*all=%onsoleJ"e3-g

org.apa%he.axis.transport.http.!5546en"er=%onsoleJ"e3-g

.ther Important 'lements in GT3 4efore we conclude our discussion on the progra ing odel aspects of GT% grid service, there are so e concepts needing special discussion. These concepts include(

1essage encoding T"pe- apping and serialization support ore detail.

8et0s e.a ine these concepts in 3essage 0t(le and 'n#oding

/e know that there are two 3*-P essage st"les, docu ent and rpc, which define how a 3*-P essage bod" is for atted. #n addition, there are two odes to encode an operation0s para eters, literal and encoded.

%9'7 (essage -ncoding

1essage encoding. This encoding is based on 3*-P graph encoding, as described in the 3*-P specification. 8iteral encoding. This 3*-P encoding is using 918 sche a for description. essage

%9'7 (essage %tyle

+PC. This is based on )rpc)-st"le essage for atting where operation na e and signatures are defined correctl" in 918 and e bedded in the 3*-P bod". The process is co plicated, as each bod" ele ent ust ap to the para eter of the operation. 5ocu ent. #n this case, the operation na e aps to a docu ent, and the 3*-P bod" contains that docu ent with the operation na e as the first ele ent. #n ost of the i ple entations 6-9#3 and .ABT7 this encoding is actuall" resulting in )wrapped)st"le essaging. #n -9#3, we can see this configuration for each service in the serverconfig.wsdd and the generated 3*-P stubs. To conclude, readers ust note that the /3-# organization is encouraging the use of docu ent'literal essaging and deprecating the other encoding for ats. -s we can see, GT% also encourages the use of the docu ent'literal approach. The botto line is, unless we have strong reasons in favor of other kinds of encoding, we should use the docu ent'literal approach. T(pe63apping and 0erialization The t"pe apping and serialization'deserialization process involves

Creating native language t"pes fro 918 sche a ele ents. The -9#3provided /358$Cava can convert the 935 t"pes defined in the /358s to its corresponding Cava t"pes. 1apping the 918 essages frag ents to native language t"pe created in the previous process and vice versa. This apping process needs the conversion guidelines to be defined b" the client-side stub or the service container. The client-side process is si ple based on the fact that these t"pes are created and registered with the stubs. The fra ework can handle this conversion on runti e during 3*-P essage parsing. There we a" need to register this t"pe- apping infor ation with the configuration files. 8isting 1$.%: shows how we can register t"pe- apping infor ation staticall" in a container. There are d"na ic -9#3 -P#s available to set the t"pe- apping on runti e.

,isting 12.31. ' sam le ty e-ma

<t(pe;apping

ing configuration.

xmlns:ns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/" 'name="ns:han"le6et" t(pe="Uava:org.gri"#or-m.ogsi.Lo%ator5(pe" serialiGer="org.apa%he.axis.en%o"ing.ser.$ean6erialiGer#a%tor(" "eserialiGer="org.apa%he.axis.en%o"ing.ser.$ean1eserialiGer#a%tor(" en%o"ing6t(le="" />

GT% handles 918 t"pes using generic 918 #nfoset t"pe for the cases where these t"pe- appings are not available.

5eserializing the native language t"pes to 918 frag ents.

0ummar(
#n this chapter, we have covered uch of the progra ing odel infor ation related to the Globus GT% software. This discussion was ai ed at providing an introduction into the basic co ponents present in the fra ework, how the" are working together, the GT%-provided helper classes, and so e basic infor ation on the inner working details of these co ponents. #n the ne.t chapter, we will develop a sa ple application using this progra ing odel.

Chapter 12. G9OB-' G"2 "ool1it= 0 'ample Implementation

#n this chapter, we e.plore a sa ple Globus GT% i ple entation. This sa ple will introduce the concepts we have discussed in the previous two chapters, in ter s of a Grid Co puting i ple entation. #n order to better understand this, fa iliarit" with the basic concepts of /eb services is a ust. This includes understanding the

concepts of the basic structure of 3*-P odel,I1J and -pache -9#3 runti e.I$J

essages, the C-9-+PC progra

ing

This sa ple discussion will discuss ost of the progra ing aspects of grid services, which we can also find in the Globus GT% toolkit. 3hould one desire to i ple ent this sa ple as we are describing it, we are assu ing that GT% is correctl" installed on the develop ent achine 6e.g., http(''localhost(=><>7I%J as a /eb application with a root na e of )ogsa.) 4efore we begin working, we have to ensure that GT% sa ples are properl" working in the achine. This is because we are not including an" service deplo" ent and installation infor ation in this chapter. *ur intension is to introduce the concepts of GT%, fro the point of view of the service developers and clients. This is a sa ple that is intended to be si ple in nature. The sa ple is that of a search engine i ple ented as ultiple grid services. ?igure 1%.1 shows this sa ple.

Figure 13.1. The 'cme %earch -ngine service utilized as the sam le in this cha ter.

#t is i portant to understand that, although si ple, this is a real functional sa pleF however, this sa ple is ver" pri itive for purposes of understanding. This is, however, a powerful and e.tensible sa ple service i ple entation to e.plain the progra ing details on GT%. *ne a" want to think about e.tending this sa ple to a real search engine, or delegate this to an e.isting search engine. The @18 diagra i ple entation. in ?igure 1%.$ shows the interface hierarch" of this service

Figure 13.2. /(, diagram sho#ing the 'cme ortTy es and service im lementation.

This sa ple will be developed in a step-b"-step fashion b" adding functionalities one b" one. The approach taken is a top-down approach, where we will start with a G/358 description of the service to be i ple ented

"#me 0ear#h 0ervi#e Implementation in a Top6)own "pproa#h

Base 0ervi#e Implementation This discussion surrounds the base i ple entation.

Figure 13.3. &ecommended develo ment rocess.

"?%D, $reation
#n a top-down develop ent effort, we ust start with a G/358, and the necessar" artifacts that the service should e.pose to the e.ternal world. These artifacts include service interfaces and their hierarch", public operations, essages e.changed between a client and service, and the e.posed public state data infor ation. This infor ation is coded 6i.e., e.cept for public state data, which we will add later7 in the G/358 description shown in 8istings 1%.1, 1%.$, and 1%.%. 8isting 1%.1 describes the co plete General3earchPortT"pe.gwsdl.

,isting 13.1. The com lete "eneral%earch7ortTy e.g#sdl.

<?xml version="1.0" en%o"ing=".5O >"?> <"e#initions name="8eneral6ear%h" target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/general" xmlns:general="http://org.ph.gri"3oo&.sample/3ase/general" xmlns="http://s%hemas.xmlsoap.org/ws"l/" xmlns:ogsi="http://www.gri"#or-m.org/namespa%es/2003/03/N86/" xmlns:gws"l="http://www.gri"#or-m.org/namespa%es/2003/03/

gri"E61LExtensions" xmlns:xs"="http://www.w3.org/2001/F;L6%hema"> <<= 5he 3elow E61L #ragment imports ogsi.gws"lJ whi%h is part o# the %ore 853 "istri3-tion an" "e#ines the N86/ "e#ine" servi%e port5(pes. > <import lo%ation="../../ogsi/ogsi.gws"l" namespa%e="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/>

<t(pes> <xs":s%hema target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/general" xmlns:general="http://org.ph.gri"3oo&.sample/3ase/general" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" attri3-teOorm1e#a-lt="'-ali#ie"" elementOorm1e#a-lt="'-ali#ie""> <xs":%omplex5(pe name="6ear%h5(pe"> <xs":se'-en%e> <xs":element name="phrase" t(pe="xs":string"/> </xs":se'-en%e> </xs":%omplex5(pe> <xs":%omplex5(pe name="6ear%h,esponse5(pe"> <xs":se'-en%e> <xs":element name=".,L" t(pe="xs":string"/> <xs":element name="s-mmar(" t(pe="xs":string"/> <xs":element name="%a%he"" t(pe="xs":3oolean"/> </xs":se'-en%e> </xs":%omplex5(pe> <xs":element name="sear%h"> <xs":%omplex5(pe> <xs":se'-en%e> <xs":element name="sear%h/np-t" t(pe="general:6ear%h5(pe"/> </xs":se'-en%e>

</xs":%omplex5(pe> </xs":element> <xs":element name="sear%h,esponse"> <xs":%omplex5(pe> <xs":se'-en%e> <xs":element name="sear%h,es-lt" t(pe="general:6ear%h,esponse5(pe"/> </xs":se'-en%e> </xs":%omplex5(pe> </xs":element> </xs":s%hema> </t(pes> <message name="6ear%h/np-t;essage"> <part name="parameters" element="general:sear%h"/> </message> <message name="6ear%hN-tp-t;essage"> <part name="parameters" element="general:sear%h,esponse"/> </message> <gws"l:port5(pe name="8eneral6ear%h4ort5(pe" exten"s="ogsi:8ri"6ervi%e"> <operation name="sear%h"> <inp-t message="general:6ear%h/np-t;essage"/> <o-tp-t message="general:6ear%hN-tp-t;essage"/> </operation> </gws"l:port5(pe> </"e#initions>

8isting 1%.$ describes the co plete Cache3earchPortT"pe G/358.

,isting 13.2. The com lete $ache%earch7ortTy e "?%D,.

<?xml version="1.0" en%o"ing=".5O >"?> <"e#initions name="8eneral6ear%h"

target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/%a%he" xmlns:%a%he="http://org.ph.gri"3oo&.sample/3ase/%a%he" xmlns="http://s%hemas.xmlsoap.org/ws"l/" xmlns:ogsi="http://www.gri"#or-m.org/namespa%es/2003/03/N86/" xmlns:gws"l="http://www.gri"#or-m.org/namespa%es/2003/03/ gri"E61LExtensions" xmlns:xs"="http://www.w3.org/2001/F;L6%hema"> <<= 5he 3elow ws"l #ragment imports ogsi.gws"lJ whi%h is part o# the %ore 853 "istri3-tion an" "e#ines the N86/ "e#ine" servi%e port5(pes. > <import lo%ation="../../ogsi/ogsi.gws"l" namespa%e="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/>

<t(pes> <xs":s%hema target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/%a%he" xmlns:general="http://org.ph.gri"3oo&.sample/3ase/%a%he" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" attri3-teOorm1e#a-lt="'-ali#ie"" elementOorm1e#a-lt="'-ali#ie""> <xs":%omplex5(pe name="*a%he6ear%h;essage5(pe"> <xs":se'-en%e> <xs":element name="%a%he6ear%h" t(pe="xs":3oolean"/> <xs":element name="phrase" t(pe="xs":string"/> </xs":se'-en%e> </xs":%omplex5(pe>

<xs":%omplex5(pe name="*a%he6ear%h;essage,esponse5(pe"> <xs":se'-en%e> <xs":element name=".,L" t(pe="xs":string"/>

<xs":element name="s-mmar(" t(pe="xs":string"/> <xs":element name="%a%he"" t(pe="xs":3oolean"/> </xs":se'-en%e> </xs":%omplex5(pe> <xs":element name="%a%he6ear%h"> <xs":%omplex5(pe> <xs":se'-en%e> <xs":element name="%a%he6ear%h/np-t" t(pe="%a%he:*a%he6ear%h;essage5(pe"/> </xs":se'-en%e> </xs":%omplex5(pe> </xs":element> <xs":element name="%a%he6ear%h,esponse"> <xs":%omplex5(pe> <xs":se'-en%e> <xs":element name="%a%he6ear%h,es-lt" t(pe="%a%he:*a%he6ear%h;essage,esponse5(pe"/> </xs":se'-en%e> </xs":%omplex5(pe> </xs":element> </xs":s%hema> </t(pes>

<message name="*a%he6ear%h/np-t;essage"> <part name="parameters" element="%a%he:%a%he6ear%h"/> </message> <message name="*a%he6ear%hN-tp-t;essage"> <part name="parameters" element="%a%he:%a%he6ear%h,esponse"/> </message>

<gws"l:port5(pe name="*a%he6ear%h4ort5(pe" exten"s="ogsi:8ri"6ervi%e">

<operation name="%a%he6ear%h"> <inp-t message="%a%he:*a%he6ear%h/np-t;essage"/> <o-tp-t message="%a%he:*a%he6ear%hN-tp-t;essage"/> </operation> </gws"l:port5(pe> </"e#initions>

8isting 1%.% describes the co plete -c e3earchPortT"pe G/358.

,isting 13.3. The com lete 'cme%earch7ortTy e "?%D,.

<?xml version="1.0" en%o"ing=".5O >"?> <"e#initions name="2%me6ear%h" target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/a%me" xmlns:a%me="http://org.ph.gri"3oo&.sample/3ase/a%me" xmlns:general="http://org.ph.gri"3oo&.sample/3ase/general" xmlns:%a%he="http://org.ph.gri"3oo&.sample/3ase/%a%he" xmlns="http://s%hemas.xmlsoap.org/ws"l/" xmlns:ogsi="http://www.gri"#or-m.org/namespa%es/2003/03/N86/" xmlns:gws"l="http://www.gri"#or-m.org/namespa%es/2003/03/ gri"E61LExtensions" xmlns:xs"="http://www.w3.org/2001/F;L6%hema"> <<= 5he 3elow %o"e imports ogsi.gws"l an" other gws"lMs "e#ine" earlier > <import lo%ation="../../ogsi/ogsi.gws"l" namespa%e="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <import lo%ation="../../gri"3oo&/3ase/generalIsear%hIportIt(pe.gws"l" namespa%e="http://org.ph.gri"3oo&.sample/3ase/general"/> <import lo%ation="../../gri"3oo&/3ase/%a%heIsear%hIportIt(pe.gws"l" namespa%e="http://org.ph.gri"3oo&.sample/3ase/%a%he"/>

<t(pes>

<xs":s%hema target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/a%me" xmlns:a%me="http://org.ph.gri"3oo&.sample/3ase/a%me" xmlns:xs"=http://www.w3.org/2001/F;L6%hema attri3-teOorm1e#a-lt="'-ali#ie"" elementOorm1e#a-lt="'-ali#ie"">

<xs":%omplex5(pe name="6pell*he%&;essage5(pe"> <xs":se'-en%e> <xs":element name="wor"" t(pe="xs":string"/> </xs":se'-en%e> </xs":%omplex5(pe>

<xs":%omplex5(pe name="6pell*he%&;essage,esponse5(pe"> <xs":se'-en%e> <xs":element name="wor"" t(pe="xs":string"/> <xs":element name="%orre%t" t(pe="xs":3oolean"/> <xs":element name="%orre%te"Eor"" t(pe="xs":string"/> </xs":se'-en%e> </xs":%omplex5(pe> <xs":element name="spell*he%&"> <xs":%omplex5(pe> <xs":se'-en%e> <xs":element name="spell*he%&/np-t" t(pe="a%me:6pell*he%&;essage5(pe"/> </xs":se'-en%e> </xs":%omplex5(pe> </xs":element> <xs":element name="spell*he%&,esponse"> <xs":%omplex5(pe> <xs":se'-en%e> <xs":element name="spell*he%&,es-lt" t(pe="a%me:6pell*he%&;essage,esponse5(pe"/>

</xs":se'-en%e> </xs":%omplex5(pe> </xs":element> </xs":s%hema> </t(pes> <message name="6pell*he%&/np-t;essage"> <part name="parameters" element="a%me:spell*he%&"/> </message> <message name="6pell*he%&N-tp-t;essage"> <part name="parameters" element="a%me:spell*he%&,esponse"/> </message> <gws"l:port5(pe name="2%me6ear%h4ort5(pe" exten"s="ogsi:8ri"6ervi%e general:8eneral6ear%h4ort5(pe %a%he:*a%he6ear%h4ort5(pe"> <operation name="spell*he%&"> <inp-t message="a%me:6pell*he%&/np-t;essage"/> <o-tp-t message="a%me:6pell*he%&N-tp-t;essage"/> </operation> </gws"l:port5(pe> </"e#initions>

The design of /358 is a co ple. process. Therefore, care needs to be taken and we ust follow so e design patterns for creating interoperable, standards-based, and error-free G/358'/358. /hat follows are so e of the i portant design decisions we take into account when we create the above service description language. These considerations are(

/hile creating grid services for *G3#, it is reco ended to use G/358'*G3# na espaces for declaring and use *G3#-related concepts including service data, open and e.tendable portT"pes, and co on data t"pes. /e ust i port the *G3# behaviors fro the GT%-provided )ogsi.gwsdl) declaration file. /e need to create onl" )portT"pe) declarations 6as shown in the above listings7 in the G/358 files( There is no need to create a service and the binding declarations. The GT% tools 6G/358$/358 and Generate4inding7 generate the necessar" /358s for services, bindings, and portT"pes fro the

G/358 portT"pe definition. The default binding support is 3*-P'2TTP with )docu ent'literal) encoding.

@tilize the )docu ent-literal) approach when designing /358 for interoperabilit" a ong i ple entations. 3ince there are so e ano alies with the -9#3 tools, one ust e bellish the appropriate design patterns in order to get the )best) generated code. This code generates 3*-P essages that are interoperable, and could be validated with /3-# basic profile tools.I&J The )targetAa espace) declaration ust be done with care and this value is used to create the default package structure. /e will see later how we can override this default tool generation feature. 935 t"pes ust be defined with the 935 sche a attribute of )ele ent?or 5efault) and )attribute?or 5efault) to get !ualified with the appropriate na espace declarations.

#ecommended 6'D9 Coding $attern (or Document@9iteral Messages

-s shown in 8isting 1%.%, the Owsdl( essageP ust contain Owsdl(para etersP referring to 918 ele ents with the sa e na e as the Owsdl(operationP na e. These 918 ele ents in turn a" contain .sd(Co ple.T"pe'3i pleT"pe t"pes to hold the real essage t"pe. This is analogous to sending essage docu ents with the na e of the operation within a 3*-P bod" as the first ele ent. ?or e.a ple, 8isting 1%.& is the 3*-P essage generated for the )search) operation based on the above /358 sche a. The highlights indicate that we are sending an 918 docu ent based on its sche a definition.

,isting 13.!. ' sam le %9'7 message for document:literal ?%D, definition.
<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/"

xmlns:xs"="http://www.w3.org/2001/F;L6%hema" instan%e"> <soapenv:$o"(> <sear%h xmlns="http://org.ph.gri"3oo&.sample/3ase/general"> <sear%h/np-t> <phrase>/$; 8ri" %omp-ting</phrase> </sear%h/np-t> </sear%h> </soapenv:$o"(> </soapenv:Envelope> xmlns:xsi="http://www.w3.org/2001/F;L6%hema

"enerating ?%D, from "?%D,

/e have now co pleted our service portT"pe definition in G/358s, and it0s ti e to focus on creating the real /358.

This is a transfor ation process fro G/358 to /358 and is done using the G/358$/358 tool, which we have discussed in the last chapter. 8isting 1%.5 shows the generated /358 file with the generated /358 portT"pe declaration. 8isting 1%.5 addresses the /358 file generated fro operation. the G/358 transfor ation

,isting 13.0. ?%D, file generated from the "?%D, transformation.

<?xml version="1.0" en%o"ing=".5O >"?> <"e#initions name="2%me6ear%h" target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/a%me" xmlns="http://s%hemas.xmlsoap.org/ws"l/" xmlns:a%me="http://org.ph.gri"3oo&.sample/3ase/a%me" xmlns:%a%he="http://org.ph.gri"3oo&.sample/3ase/%a%he" xmlns:general="http://org.ph.gri"3oo&.sample/3ase/general" xmlns:gws"l="http://www.gri"#or-m.org/namespa%es/2003/03/gri"E61LExte nsions" xmlns:ogsi="http://www.gri"#or-m.org/namespa%es/2003/03/N86/" xmlns:xs"="http://www.w3.org/2001/F;L6%hema">

<import lo%ation="../../ogsi/ogsi.gws"l" namespa%e="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <import lo%ation="../../gri"3oo&/3ase/generalIsear%hIportIt(pe.gws"l" namespa%e="http://org.ph.gri"3oo&.sample/3ase/general"/> <import lo%ation="../../gri"3oo&/3ase/%a%heIsear%hIportIt(pe.gws"l" namespa%e="http://org.ph.gri"3oo&.sample/3ase/%a%he"/>

<t(pes> <<=omitte" #or %larit( S 6ame as what we have "e#ine" in the 2%me6ear%h4ort5(pe > </t(pes>

<message name="6pell*he%&/np-t;essage"> <part element="a%me:spell*he%&" name="parameters"/> </message> <message name="6pell*he%&N-tp-t;essage"> <part element="a%me:spell*he%&,esponse" name="parameters"/> </message>

<port5(pe name="2%me6ear%h4ort5(pe">

<operation name="spell*he%&"> <inp-t message="ns0:6pell*he%&/np-t;essage" xmlns:ns0="http://org.ph.gri"3oo&.sample/3ase/a%me"/> <o-tp-t message="ns1:6pell*he%&N-tp-t;essage" xmlns:ns1="http://org.ph.gri"3oo&.sample/3ase/a%me"/> </operation>

<operation name="sear%h"> <inp-t message="ns31:6ear%h/np-t;essage" xmlns:ns31="http://org.ph.gri"3oo&.sample/3ase/general"/> <o-tp-t message="ns32:6ear%hN-tp-t;essage" xmlns:ns32="http://org.ph.gri"3oo&.sample/3ase/general"/> </operation>

<operation name="%a%he6ear%h"> <inp-t message="nsD2:*a%he6ear%h/np-t;essage" xmlns:nsD2="http://org.ph.gri"3oo&.sample/3ase/%a%he"/> <o-tp-t message="nsD3:*a%he6ear%hN-tp-t;essage" xmlns:nsD3="http://org.ph.gri"3oo&.sample/3ase/%a%he"/> </operation>

<operation name="set6ervi%e1ata"> <inp-t message="nsB0:6et6ervi%e1ata/np-t;essage" xmlns:nsB0="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <o-tp-t message="nsB1:6et6ervi%e1ataN-tp-t;essage" xmlns:nsB1="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <#a-lt message="nsB2:Extensi3ilit()ot6-pporte"Oa-lt;essage" name="Extensi3ilit()ot6-pporte"Oa-lt" xmlns:nsB2="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <<=Nther #a-lts are omitte" #or %larit( S </operation> >

<operation name=""estro(">

<inp-t message="ns>9:1estro(/np-t;essage" xmlns:ns>9="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <o-tp-t message="ns90:1estro(N-tp-t;essage" xmlns:ns90="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <<=Nther #a-lts are omitte" #or %larit( S </operation> <operation name="re'-est5ermination2#ter"> <inp-t message="ns>1:,e'-est5ermination2#ter/np-t;essage" xmlns:ns>1="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <o-tp-t message="ns>2:,e'-est5ermination2#terN-tp-t;essage" xmlns:ns>2="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> </operation> >

<operation name="re'-est5ermination$e#ore"> <inp-t message="ns>5:,e'-est5ermination$e#ore/np-t;essage" xmlns:ns>5="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <o-tp-t message="ns>D:,e'-est5ermination$e#oreN-tp-t;essage" xmlns:ns>D="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <<=Nther #a-lts are omitte" #or %larit( S </operation> >

<operation name="#in"6ervi%e1ata"> <inp-t message="nsD@:Oin"6ervi%e1ata/np-t;essage" xmlns:nsD@="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <o-tp-t message="nsD5:Oin"6ervi%e1ataN-tp-t;essage" xmlns:nsD5="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <<=Nther #a-lts are omitte" #or %larit( S </operation> >

</port5(pe>

<gws"l:port5(pe exten"s="ogsi:8ri"6ervi%e general:8eneral6ear%h4ort5(pe %a%he:*a%he6ear%h4ort5(pe" name="2%me6ear%h4ort5(pe">

</gws"l:port5(pe>

</"e#initions>

#n 8isting 1%.5, we note that a new Owsdl(-c e3earchPortT"peP was created with all the operations of the portT"pes that we have e.tended in the G/358. This process is e.plained in the @18 diagra below in ?igure 1%.&.

Figure 13.!. The "?%D, to ?%D, transformation rocess.

*ne ite to note regarding this process is that the generated /358 is still keeping the G/358 portT"pe infor ation for backward transfor ation purposes, and to help at runti e with the GT% tools.

"enerating 9ther ?%D, Files

*nce we have co pleted the above process, the ne.t step in the process is to create the necessar" /358 files for service and binding. These files are created fro the /358 portT"pe created in the above step. GT% provides a helper class to assist us in this step. /e are using the )Generate4inding) tool to create default binding and service i ple entation.

"ools -sed in the 0)ove "wo 'teps 0re=

1. G/358$/358 @sage( Cava G/358$/358 ac eWsearchWportWt"pe.gwsdl ac eWsearchWportWt"pe.wsdl $. Generate4inding @sage( Cava Generate4inding ac eWsearchWportWt"pe.wsdl ac eWsearchWservice.wsdl

/e now have all of the /358s we re!uire for our service. #n our sa ple, the generated files are( 1. ac eWsearchWbindings.wsdl $. ac eWsearchWportWt"pe.wsdl %. ac eWsearchWportWt"pe..sd &. ac eWsearchWservice.wsdl

"enerating %tubs, 6el er $lasses

3o far we have been working with 918, /358, and 935 sche a. 8et us now begin to generate the native language i ple entation artifacts fro the /358 files. /e need to ake sure that the default i ple entation is using the correct na e for the Cava package, because the default code generation process generates the source infor ation in a package, constructed fro the targetAa espace of the /358s. The sidebar below illustrates how we can override the targetAa espace to a eaningful package na e of our choice, should we need to do this.

Overriding the De(ault $ac1age Creation $rocess in the 0pache 0&is 6'D9 A030 "ool
#n /358$C-K- , there are three options to defined package na e( -A, --A3toPkg Oargu entPSOvalueP 1apping of na espace to package -f, --fileA3toPkg Oargu entP ?ile of A3toPkg appings 6default A3toPkg.properties7 ap the na espace to so e user-

-p, --package Oargu entP *verride all na espace to package appings, use this package na e instead

2ere, we are using the default A3toPkg.properties file. The new package definitions are( http[(''org.ph.gridbook.sa ple'base'ac eSorg.ph.gridbook.base http[(''org.ph.gridbook.sa ple'base'ac e'bindingsSorg.ph.gridbook.base.bindings http[(''org.ph.gridbook.sa ple'base'ac e'serviceSorg.ph.gridbook.base.service

*nce we have decided on the package na es, the ne.t step is the process of generating the Cava sources for stubs, endpoint interface, helpers, and t"pes. GT% co es with a nu ber of tools to help us acco plish this. /e have alread" discussed the details on these tools in the last chapter. +eaders can see how these tools are used for this sa ple. G/358$Cava @sage( G/358$Cava ac eWsearchWservice.wsdl

This results in a nu ber of Cava classes. /e will see so e of the i portant Cava classes that are generated, and we will then spend so e ti e anal"zing these Cava files. These files for the base i ple entation artifacts for the grid services at both the client and the server side. 3o, fa iliarit" with these Cava classes is a ust for proper service and client-side develop ent.

'cme%earch7ortTy e

This is the service endpoint interface generated fro the /358 portT"pe definition. 3ervice developers e.tend their service i ple entations fro these service endpoint interfaces. This class is generated in accordance with the C-9-+PC specification, in the service endpoint interface definition. 8isting 1%.: shows the interface generated for our sa ple.

,isting 13.1. The 'cme %earch interface.

pa%&age org.ph.gri"3oo&.3aseS

p-3li% inter#a%e 2%me6ear%h4ort5(pe exten"s org.gri"#or-m.ogsi.8ri"6ervi%e R

// ;ost o# the Ex%eptions are not shown #or %o"e %larit(............. p-3li% org.gri"#or-m.ogsi.Extensi3ilit(5(pe #in"6ervi%e1ataPorg.gri"#or-m.ogsi.Extensi3ilit(5(pe '-er(ExpressionQ throws Yava.rmi.,emoteEx%eptionJ ..................................S

p-3li% org.ph.gri"3oo&.3ase.6ear%h,esponse5(pe sear%hPorg.ph.gri"3oo&.3ase.6ear%h5(pe sear%h/np-tQ throws Yava.rmi.,emoteEx%eptionS

p-3li% voi" "estro(PQ throws Yava.rmi.,emoteEx%eptionJ.........S

p-3li% org.ph.gri"3oo&.3ase.*a%he6ear%h;essage,esponse5(pe %a%he6ear%hPorg.ph.gri"3oo&.3ase.*a%he6ear%h;essage5(pe %a%he6ear%h/np-tQ throws Yava.rmi.,emoteEx%eptionS

p-3li% org.ph.gri"3oo&.3ase.6pell*he%&;essage,esponse5(pe spell*he%&Porg.ph.gri"3oo&.3ase.6pell*he%&;essage5(pe spell*he%&/np-tQ throws Yava.rmi.,emoteEx%eptionS

// some metho"s are not shown #or %o"e rea"a3ilit(................... T

/e should not tr" to code this )b" hand.) /e ust use the tools because the code generation is dependent on a nu ber of /358 constructs. This includes encoding 63*-P encoding'literal7, st"le 6rpc'docu ent7, and the operation para eter direction 6in'out or inout7. /e could see C-9-+PC holder classes getting generated for the Owsdl(inoutP operation para eter t"pe.

-nother helpful feature of using the tools is the creation of the corresponding Cava t"pes for the essage para eters, and for the 935 ele ents defined in the /358. ?or e.a ple, a 3earchT"pe Cava class is generated for the 935 co ple. t"pe )3earchT"pe) defined in the earlier /358 listing. These ob,ects are 918serializable Cava classes, and the fra ework can arshal'de arshal the into 3*-P essage bod" ele ents. Aow let0s ove on to the other valuable construct, )-c e3earch3ervice,) an i ple entation of ,ava... l.rpc.3ervice.

'cme%earch%ervice
The C-9-+PC client at runti e creates )d"na ic pro.") stubs using the ,ava... l.rpc.3ervice interface. The client has a priori knowledge of the /358, the service it is going to invoke, and the service ports defined. #t uses the )3ervice?actor") classes to create the service and get the pro.". #n the last chapter, we have discussed this C-9-+PC service i ple entation class and its progra ing odel. 8isting 1%.; shows the service class for -c e 3earch 3ervice.

,isting 13.4. The 3'D-&7$ service im lementation class.

p-3li% inter#a%e 2%me6ear%h6ervi%e exten"s Yavax.xml.rp%.6ervi%e R p-3li% Yava.lang.6tring get2%me6ear%h4ort2""ressPQS p-3li% org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe get2%me6ear%h4ortPQ throws Yavax.xml.rp%.6ervi%eEx%eptionS p-3li% org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe get2%me6ear%h4ortPYava.net..,L port2""ressQ throws Yavax.xml.rp%.6ervi%eEx%eptionS T

'cme%earch%ervice"rid,ocator
This locator class is the ost i portant GT% specific helper class. This class is generated to help the grid service client b" hiding the co ple.it" of grid service essage e.change patterns including G32 to G3+ conversion, G3+ validation, handle e.traction fro G3+, and so on. 8isting 1%.< shows the grid locator class for the -c e 3earch 3ervice. 4" careful observation on the class definition described in 8isting 1%.<, we could see that there are three public operations with different signatures available to the client. #t enables the client to pass the following infor ation(

- handle 6G327 for a service instance - locator of a service instance. This locator is nor all" returned on a service creation 6?actor".create3ervice7. - nor al @+8 for the service instance.

-s listed above, the utilization of this client helper class is based on the service instance availabilit" infor ation. #n the last chapter, we discussed the internals of these operations. /e will see the value of this helper class, and its utilization odel, when we start working with our client code.

,isting 13.;. 'cme%earch%ervice"rid,ocator, #hich is a grid service s ecific hel er class.

p-3li% %lass 2%me6ear%h6ervi%e8ri"Lo%ator exten"s org.glo3-s.ogsa.impl.%ore.servi%e.6ervi%eLo%ator implements org.glo3-s.ogsa.8ri"Lo%ator R p-3li% org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe get2%me6ear%h4ort Porg.gri"#or-m.ogsi.!an"le5(pe han"leQ org.gri"#or-m.ogsi.Oa-lt5(peJ org.glo3-s.ogsa.8ri"6ervi%eEx%eption R throws

set6t-3*lassPorg.ph.gri"3oo&.3ase.3in"ings.2%me6ear%h6N24$in"ing6t-3. %lassQS ret-rn Porg.ph.gri"3oo&.3ase.2%me6ear%h4ort5(peQ get6ervi%e4ortPhan"leQS T p-3li% org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe get2%me6ear%h4ort Porg.gri"#or-m.ogsi.Lo%ator5(pe lo%atorQ throws org.gri"#or-m.ogsi.Oa-lt5(peJ org.glo3-s.ogsa.8ri"6ervi%eEx%eption R

set6t-3*lassPorg.ph.gri"3oo&.3ase.3in"ings.2%me6ear%h6N24$in"ing6t-3. %lassQS ret-rn Porg.ph.gri"3oo&.3ase.2%me6ear%h4ort5(peQ get6ervi%e4ortPlo%atorQS T p-3li% org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe get2%me6ear%h4ortPYava.net..,L -rlQ throws org.glo3-s.ogsa.8ri"6ervi%eEx%eption R

set6t-3*lassPorg.ph.gri"3oo&.3ase.3in"ings.2%me6ear%h6N24$in"ing6t-3. %lassQS ret-rn Porg.ph.gri"3oo&.3ase.2%me6ear%h4ort5(peQ get6ervi%e4ortP-rlQS

T T

'cme%earch%ervice,ocator
This is also a service locator helper class located at the client side. This is ainl" utilized for /eb service clients. This locator class 68isting 1%.=7 is different fro the previousl" discussed locator class. /e can see the difference b" a careful e.a ination of the na e of the locator. The GT% grid service specific locator has a na e, OportT"pePGrid3ervice8ocator, whereas the nor al /eb service locator has a na e of OportT"peP3ervice8ocator.

,isting 13.A. The ?eb service locator class.

p-3li% %lass 2%me6ear%h6ervi%eLo%ator exten"s org.apa%he.axis.%lient.6ervi%e implements org.ph.gri"3oo&.3ase.servi%e.2%me6ear%h6ervi%e R // .se to get a prox( %lass #or 2%me6ear%h4ort private #inal Yava.lang.6tring 2%me6ear%h4ortIa""ress = "http://lo%alhost:>0>0/ogsa/servi%es/"S

p-3li% Yava.lang.6tring get2%me6ear%h4ort2""ressPQ R ret-rn 2%me6ear%h4ortIa""ressS T p-3li% org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe get2%me6ear%h4ortPQ throws Yavax.xml.rp%.6ervi%eEx%eption R T ............................. T

This previous class i ple ents -c e3earch3ervice to e.pose the C-9-+PC d"na ic pro." behaviors.

'cme%earch%9'78inding%tub
This is a core client-side static stub, which contains all the infor ation about the service, and i ple ents the service endpoint interface for co patibilit" verifications. The code in 8isting 1%.1> illustrates these concepts. This stub connects to the -pache 3*-P client )Call) ob,ect to create a 3*-P essage for the corresponding ethod invocation. This stub contains the entire t"pe- apping and serialization infor ation

to ap Cava t"pes in the operation signatures to the corresponding 3*-P bod" ele ents, and vice versa.

,isting 13.1C. The client-side static %9'7 binding stub.

p-3li% %lass 2%me6ear%h6N24$in"ing6t-3 exten"s org.apa%he.axis.%lient.6t-3 implements org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe R private Yava.-til.Ce%tor %a%he"6er*lasses = new Yava.-til.Ce%torPQ p-3li% 2%me6ear%h6N24$in"ing6t-3PQ throws org.apa%he.axis.2xisOa-lt R thisPn-llQS T

p-3li% 2%me6ear%h6N24$in"ing6t-3PYava.net..,L en"point.,LJ Yavax.xml.rp%.6ervi%e servi%eQ throws org.apa%he.axis.2xisOa-lt R thisPservi%eQS s-per.%a%he"En"point = en"point.,LS T p-3li% 2%me6ear%h6N24$in"ing6t-3PYavax.xml.rp%.6ervi%e servi%eQ throws org.apa%he.axis.2xisOa-ltR ........................ T p-3li% org.gri"#or-m.ogsi.Extensi3ilit(5(pe set6ervi%e1ataPorg.gri"#or-m.ogsi.Extensi3ilit(5(pe -p"ateExpressionQ throws Yava.rmi.,emoteEx%eptionJ org.gri"#or-m.ogsi.;-ta3ilit(CiolationOa-lt5(peJ XXXXXR T p-3li% org.ph.gri"3oo&.3ase.6ear%h,esponse5(pe sear%hPorg.ph.gri"3oo&.3ase.6ear%h5(pe sear%h/np-tQ throws Yava.rmi.,emoteEx%eption R // /mplementation %alls the 2pa%e 2xis %all o3Ye%t T // 2 n-m3er o# operations are not shown

....................... T

3ince we have co pleted the code generation process, it is ti e to ove on to the real service creation constructs. @tilizing these tools to continue to generate code, we will now be able to write a service skeleton i ple entation !uickl". Implementing 0ear#h Grid 0ervi#e /e will now begin with a si ple server-side i ple entation to e.plain the basic service constructs. /e will ove on to the co ple. features later in this chapter. 8isting 1%.11 illustrates how we are i ple enting this basic service. )-c e3earch3ervice# pl) i ple ents -c e3earchPortT"pe, the endpoint service interface. #t also i ple ents the Globus-provided Grid3ervice# pl class, which provides the default i ple entations for the grid service behaviors, service data set, and service properties. /e alread" covered the details on this helper i ple entation class in the previous chapter.

,isting 13.11. The 'cme %earch %ervice im lementation.

pa%&age org.ph.gri"3oo&.impl.3aseS

import org.glo3-s.ogsa.impl.ogsi.8ri"6ervi%e/mplS import org.glo3-s.ogsa.8ri"*ontextS import org.glo3-s.ogsa.8ri"6ervi%eEx%eptionS import org.glo3-s.ogsa.6ervi%e4ropertiesS import org.apa%he.axis.;essage*ontextS import Yava.rmi.,emoteEx%eptionS

import org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(peS import org.ph.gri"3oo&.3ase.0S

p-3li% %lass 2%me6ear%h6ervi%e/mpl exten"s 8ri"6ervi%e/mpl implements 2%me6ear%h4ort5(pe R p-3li% 2%me6ear%h6ervi%e/mpl PQ R s-perP"6imple 6ear%h 6ervi%e"QS T p-3li% 2%me6ear%h6ervi%e/mplP6tring nameQ R

s-perPnameQS T p-3li% voi" post*reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eption R s-per.post*reateP%ontextQS T p-3li% 6ear%h,esponse5(pe sear%hP6ear%h5(pe sear%h/np-tQ throws Yava.rmi.,emoteEx%eptionR // /gnore the inp-t // %reate the o-tp-t o3Ye%t 6ear%h,esponse5(pe response = new 6ear%h,esponse5(pePQS response.set.,LP"www.i3m.%om"QS response.set6-mmar(P"/$;"QS response.set*a%he"Ptr-eQS ret-rn responseS T p-3li% *a%he6ear%h;essage,esponse5(pe %a%he6ear%hP*a%he6ear%h;essage5(pe %a%he6ear%h/np-tQ throws Yava.rmi.,emoteEx%eptionR ret-rn n-llS T p-3li% 6pell*he%&;essage,esponse5(pe spell*he%&P6pell*he%&;essage5(pe spell*he%&/np-tQ throws Yava.rmi.,emoteEx%eptionR ret-rn n-llS T

This is a full" functional grid service i ple entation for the -c e search engine. The onl" functional ethod here is the search ethod, which accepts the search re!uest and returns the search responses. /e will see the 3*-P essage flows, the instance creation process, and other details in the client-side code described in the ne.t section.

Prior to this, let us e.plore the configuration of this service for the deplo" ent of the service to the -9#3 container. Grid 0ervi#e Con!iguration -s of now, the GT% supports the -pache -9#3 as their /eb service engine. 5ue to this fact, we have to utilize the -9#3 service configuration and deplo" ent process. -9#3 uses the /355 to configure service for an -9#3 engine. ?or our sa ple service, see the configuration listed in 8isting 1%.1$.

,isting 13.12. The 'cme %earch %ervice de loyment configuration.

1. <servi%e name="ph/a%me/2%me6ear%h6ervi%e" provi"er="!an"ler" st(le="wrappe""> 2. <parameter name="name" val-e="2%me 6ear%h 6ervi%e Oa%tor("/> 3. <parameter name="instan%e name" val-e="2%me 6ear%h servi%e /nstan%e"/> @. <parameter name="instan%e s%hema4ath" val-e="s%hema/gri"3oo&/3ase/a%meIsear%hIservi%e.ws"l"/> 5. <parameter name="instan%e 3ase*lass)ame" val-e="org.ph.gri"3oo&.impl.3ase.2%me6ear%h6ervi%e/mpl"/> D. << 6tart %ommon parameters >

B. <parameter name="allowe";etho"s" val-e="0"/> >. <parameter name="persistent" val-e="tr-e"/> 9. <parameter name="%lass)ame" val-e="org.gri"#or-m.ogsi.Oa%tor("/> 10. <parameter name="3ase*lass)ame" val-e="org.glo3-s.ogsa.impl.ogsi.4ersistent8ri"6ervi%e/mpl"/> 11. <parameter name="s%hema4ath" val-e="s%hema/ogsi/ogsiI#a%tor(Iservi%e.ws"l"/> 12. <parameter name="han"ler*lass" val-e="org.glo3-s.ogsa.han"lers.,4*.,/4rovi"er"/> 13. <parameter name="#a%tor(*all3a%&" val-e="org.glo3-s.ogsa.impl.ogsi.1(nami%Oa%tor(*all3a%&/mpl"/> 1@. <parameter name="operation4rovi"ers" val-e="org.glo3-s.ogsa.impl.ogsi.Oa%tor(4rovi"er"/> 15. </servi%e>

/e have previousl" discussed these configuration properties. The -c e 3earch 3ervice specific para eters are seen in lines $Q5, which lists the na e, instance na e, /358 sche a path, and service i ple entation class. The rest are default configurations with the GT%-provided default factor" provider 6?actor"Provider7, a callback 65"na ic?actor"Callback# pl7 to create the service, and the pivot handler

6+PC@+#Provider7. -nother i portant point is the use of a )wrapped) st"le and using a )handler) provider. *nce we have the service and the configuration read", we can deplo" the into the service container b" updating the class path and e.tending the e.isting serverconfig.wsdd with the above configuration frag ent. -nd, fro this point forward, when the container starts up, the -c e 3earch 3ervice will be available for the client to use. A*TB Aor all", we will use the deplo" ent files )client-config.wsdd) and )serverconfig.wsdd,) respectivel", for client and server /eb service configuration. These default na es and locations can be overridden b" providing a Cava s"ste propert" variable with a.is.3erverConfig?ile and a.is.ClientConfig?ile. ?or e.a ple, to use the configuration file ) "-server-config.wsdd,) one should provide the Cava s"ste propert", Q5a.is.3erverConfig?ileS "-server-config.wsdd.

0imple Client Implementation 8et us list the client-side re!uire ents, first, and then start coding for those re!uire ents. 1. Create an -c e 3earch 3ervice using the *G3#-defined factor" pattern. $. Call the )search) operation on the service using the locator returned fro the above step. %. -fter so e ti e we need to call the service again. Aow use a service handle we got during the first step. &. Aow get so e grid service specific properties or service data. 5. ?inall", we are now done with the service, b" calling an e.plicit destro" on the service. This process is shown in ?igure 1%.5.

Figure 13.0. The client-side interaction /(,.

/e will discuss each of these steps in detail, with the annotated code in 8isting 1%.1%. /e ust pa" close attention to the co ents and the se!uence of the process.

,isting 13.13. The 'cme %earch %ervice sim le client.

pa%&age org.ph.gri"3oo&.impl.3ase.%lientS

import org.glo3-s.ogsa.ws"l.86,S import org.gri"#or-m.ogsi.0S import org.glo3-s.ogsa.-tils.0S

import Yava.net..,LS import Yavax.xml.namespa%e.+)ameS

import org.ph.gri"3oo&.3ase.servi%e.2%me6ear%h6ervi%e8ri"Lo%atorS import org.ph.gri"3oo&.3ase.2%me6ear%h4ort5(pe import org.ph.gri"3oo&.3ase.0S S

p-3li% %lass 2%me6ear%h*lient1 R p-3li% stati% voi" mainP6tringVW argsQ R tr(R // 8et %omman" line arg-ments .,L 86! = new .,LP"http://lo%alhost:90>0/ogsa/ph/a%me/2%me6ear%h6ervi%e"QS

// 8et the 853 provi"e" 8ri" lo%ator helper #or N86/ servi%e N86/6ervi%e8ri"Lo%ator gri"Lo%ator = new N86/6ervi%e8ri"Lo%atorPQS

// 8et the #a%tor( -sing the .,L to the #a%tor( Oa%tor( #a%tor( = gri"Lo%ator.getOa%tor(4ortP86!QS 8ri"6ervi%eOa%tor( a%me6ear%hOa%tor( = new 8ri"6ervi%eOa%tor(P#a%tor(QS

// *reate a new 2%me6ervi%e instan%e -sing the 8ri" servi%e #a%tor( inter#a%e // 8et a lo%ator pointing to the 2%me 6ear%h servi%e Lo%ator5(pe lo%ator = a%me6ear%hOa%tor(.%reate6ervi%ePQS // 1one %reating an 2%me 8ri" servi%e instan%e

//)ow we got an 2%me sear%h servi%e instan%eJ rea"( to invo&e sear%h on it // 8et the 853 %reate" 8ri" lo%ator helper 2%me6ear%h6ervi%e8ri"Lo%ator a%me6ear%hLo%ator = 2%me6ear%h6ervi%e8ri"Lo%atorPQS 2%me6ear%h4ort5(pe sear%h6ervi%e = a%me6ear%hLo%ator.get2%me6ear%h4ortPlo%atorQS new

// *all remote metho" Msear%hM 6ear%h,esponse5(pe response = sear%h6ervi%e.sear%hPn-llQS 6(stem.o-t.printlnP"6ear%h response -rl = " \ response.get.,LPQQS 6(stem.o-t.printlnP"6ear%h response s-mmar( = " \ response.get6-mmar(PQQS

// )ow we are r-nning a han"le resol-tion to the servi%e 3e#ore ma&ing a servi%e %all // 8et the 86, #rom the lo%ator %reate" ret-rne" 3( the #a%tor( 86, re#eren%e = 86,.new/nstan%ePlo%atorQS

// 8et the han"le #rom the re#eren%e -sing 86, helper %lass 6tring lo%ation = re#eren%e.get!an"lePQ.to6tringPQS !an"le5(pe han"le = new !an"le5(pePlo%ationQS

// Ee got a han"le to the instan%e now. Let -s r-n a han"le resol-tion pro%ess 3e#ore servi%e %all sear%h6ervi%e = a%me6ear%hLo%ator.get2%me6ear%h4ortPhan"leQS // 5he a3ove %all will go thro-gh a !an"le resol-tion pro%ess // Oinall( will ret-rn a servi%e re#eren%e

//)ow we %an %all remote metho" Msear%hM response = sear%h6ervi%e.sear%hPn-llQS

// 4ro"-%es the res-lts 6(stem.o-t.printlnP"6ear%h response -rl = " \ response.get.,LPQQS 6(stem.o-t.printlnP"6ear%h response s-mmar( = " \ response.get6-mmar(PQQS

// )ow we %an explore some 8ri" servi%e spe%i#i% %alls //1. $ase" on N86/ spe%J ever( 8ri" servi%e has "servi%e1ata)ames" servi%e "ata element // 8et the a3ove servi%e "ata val-e #rom o-r a%me sear%h gri" servi%e.

// )ames o# 6ervi%e 1ata o##ere" 3( this 8ri" 6ervi%e extensi3ilit( =

sear%h6ervi%e.#in"6ervi%e1ataP+-er(!elper.get)ames+-er(P"servi%e1ata) ame"QQS servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPextensi3ilit(QS N3Ye%tVW servi%e1ata)ames = 2n(!elper.get2sN3Ye%tPservi%e1ataQS #orPint i=0S i<servi%e1ata)ames.lengthS i\\QR

+)ame servi%e1ata)ame = P+)ameQ servi%e1ata)amesViWS 6(stem.o-t.printlnP"servi%e "ata name: " \ servi%e1ata)ameQS T // inter#a%es // )ames o# inter#a%es expose" 3( this 8ri" 6ervi%e extensi3ilit( = sear%h6ervi%e.#in"6ervi%e1ataP+-er(!elper.get)ames+-er(P"inter#a%e"QQ S servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPextensi3ilit(QS N3Ye%tVW inter#a%es = 2n(!elper.get2sN3Ye%tPservi%e1ataQS #orPint i=0S i<inter#a%es.lengthS i\\QR +)ame i#a%e = P+)ameQ inter#a%esViWS 6(stem.o-t.printlnP"inter#a%e name: " \ i#a%eQS T // Oinall( get a re#eren%e to the 8ri"6ervi%e 4ort5(pe an" "estro( the instan%e 8ri"6ervi%e gri"6ervi%e = gri"Lo%ator.get8ri"6ervi%e4ortPlo%atorQS gri"6ervi%e."estro(PQS T%at%hPEx%eption eQR e.print6ta%&5ra%ePQS T T T

1. Create an -c e 3earch 3ervice. The client uses the nor al GT%-provided )*G3#3erviceGrid8ocator) class to get hold of the factor" stub and calls create service on that stub using the well-known -c e 3earch 3ervice factor" @+8. To better understand, we will show the 3*-P essages flowing through the wire. This will give us a clear understanding of the process. 8isting 1%.1& shows the 3*-P essage generated for the )create3ervice) operation on the factor". The target address @+8 we used to connect to the factor" is http(''localhost(=><>'ogsa'ph'ac e'-c e3earch3ervice.)

,isting 13.1!. The %9'7 re@uest message for the Factory create%ervice o eration.
<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/"

xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e"> <soapenv:$o"(> <%reate6ervi%e xmlns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <termination5ime ns1:3e#ore="in#init(" ns1:a#ter="in#init(" xmlns:ns1="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <%reation4arameters xsi:nil="tr-e"/> </%reate6ervi%e> </soapenv:$o"(> </soapenv:Envelope>

8isting 1%.15 describes the response fro the server after the creation of the -c e 3earch 3ervice using the default GT% factor" provider. This listing illustrates the encoded /58 reference infor ation of the -c e 3earch 3ervice 6ac eWsearchWservice.wsdl7. The G3+ helper class can convert the /358 reference to the corresponding )/358+eferenceT"pe) class and can retrieve the handle to the service instance.

,isting 13.10. The %9'7 res onse message for the Factory create%ervice o eration.
<soapenv:$o"(> <%reate6ervi%e,esponse xmlns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <lo%ator> <re#eren%e xsi:t(pe="ns1:E61L,e#eren%e5(pe" xmlns:ns1="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <"e#initions name="2%me6ear%h" target)amespa%e=http://org.ph.gri"3oo&.sample/3ase/a%me/servi%e xmlns="http://s%hemas.xmlsoap.org/ws"l/" xmlns:a%mesear%h3in"ing="http://org.ph.gri"3oo&.sample/3ase/a%me/3in" ings" xmlns:soap="http://s%hemas.xmlsoap.org/ws"l/soap/"> <import lo%ation="http://lo%alhost:90>0/ogsa/s%hema/gri"3oo&/3ase/a%meIsear%h I3in"ings.ws"l"

namespa%e="http://org.ph.gri"3oo&.sample/3ase/a%me/3in"ings"/>

<servi%e name="2%me6ear%h6ervi%e" xmlns:gs"l="http://ogsa.glo3-s.org/"> <gs"l:instan%eN# han"le="http://9.5D.3B.@3:90>0/ogsa/servi%es/ph/a%me/2%me6ear%h6ervi% e /hash 2D20>950@ 105>>95D>1D9@" xmlns=""/> <gs"l:instan%eN# han"le="http://9.5D.3B.@3:90>0/ogsa/servi%es/instan%e" xmlns=""/> <port 3in"ing="a%mesear%h3in"ing:2%me6ear%h6N24$in"ing" name="2%me6ear%h4ort"> <soap:a""ress lo%ation="http://9.5D.3B.@3:90>0/ogsa/servi%es/ph/a%me/2%me6ear%h6erv i%e/hash 2D20>950@ 105>>95D>1D9@"/> </port> </servi%e> </"e#initions> </re#eren%e> </lo%ator> <ns2:%-rrent5ermination5ime xsi:t(pe="ns2:5ermination5ime5(pe" ns2:3e#ore="in#init(" ns2:timestamp="2003 0B 2251B:@1:22.@05[" ns2:a#ter="in#init(" xmlns:ns2="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"/> <extensi3ilit(N-tp-t xsi:nil="tr-e"/> </%reate6ervi%e,esponse> </soapenv:$o"(> </soapenv:Envelope>

Pa"ing close attention to 8isting 1%.15, we can observe that(

The factor" creates the handle of the service instance. The 3*-P address location is updated with the new instance address and the necessar" instance infor ation.

The current ter ination ti e ele ent is related to the service instanceQcreated ti e, and with a ter ination ti e of infinit".

*nce the client can establish a relationship with this reference, it can alwa"s go back to the service until the e.plicit ter ination of the service b" client'container, or the soft state service e.piration occurs. $. Call the )search) operation on the service using the locator returned fro the above step. /e have seen earlier that the OportT"pePGrid3ervice8ocator class can be called with three t"pes of para eters, 8ocatorT"pe, 2andleT"pe, and @+8, respectivel". /e will invoke the )search) operation on the server using the 8ocatorT"pe class returned fro the above )create3ervice) call. 8isting 1%.1: shows how it is done.

,isting 13.11. The client invoking the FsearchF o eration on the service.
2%me6ear%h6ervi%e8ri"Lo%ator a%me6ear%hLo%ator = 2%me6ear%h6ervi%e8ri"Lo%atorPQS 2%me6ear%h4ort5(pe sear%h6ervi%e = a%me6ear%hLo%ator.get2%me6ear%h4ortPlo%atorQS 6ear%h5(pe sear%h,e'-est = new 6ear%h5(pePQS sear%h,e'-est.set4hraseP"/$; 8ri" %omp-ting"QS 6ear%h,esponse5(pe response = sear%h6ervi%e.sear%hPsear%h,e'-estQS new

Aote that the target address utilized is http(''localhost(=><>'ogsa'ph'ac e'-c e3earch3ervice'hash-$:$><=5>&1>5<<=5:<1:=&. This address points to a specific instance of the search service created b" the client. The above grid service call resulted in the 3*-P essage in 8isting 1%.1;.

,isting 13.14. The %9'7 message trace on the FsearchF method call to the 'cme %earch %ervice.
<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e"> <soapenv:$o"(> <sear%h xmlns="http://org.ph.gri"3oo&.sample/3ase/general"> <sear%h/np-t> <phrase>/$; 8ri" %omp-ting</phrase> </sear%h/np-t> </sear%h>

</soapenv:$o"(> </soapenv:Envelope>

The results are retrieved fro the 3earch+esponseT"pe ob,ect. 8isting 1%.1< below describes the 3*-P return essage for the above call.

,isting 13.1;. The %9'7 message trace on the FsearchF method call return from the 'cme %earch %ervice.
<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e"> <soapenv:$o"(> <sear%h,esponse xmlns="http://org.ph.gri"3oo&.sample/3ase/general"> <sear%h,es-lt xsi:t(pe="ns1:6ear%h,esponse5(pe" xmlns:ns1="http://org.ph.gri"3oo&.sample/3ase/general"> <.,L>www.i3m.%om</.,L> <s-mmar(>/$;</s-mmar(> <%a%he">tr-e</%a%he"> </sear%h,es-lt> </sear%h,esponse> </soapenv:$o"(> </soapenv:Envelope>

-t this stage, we are done creating an ac e search grid service instance, and we have invoked a )search) call on that instance using the service locator returned fro the create3ervice operation. Aow, assu e that we are holding the service instance for a long period of ti e. 4" now, the service G3+ a" have changed but the G32 holds validit". #n this kind of situation, we a" need to go back to the container to do a handle resolution process before we start accessing the service. This should happen without the client0s involve ent. Aow, let us see how we can do this in a real-world scenario. %. -fter so e ti e we need to call the service again. This ti e around, we will use a service handle that we received during the first step. The client can still use the nor al )-c e3earch3erviceGrid8ocator) class, however, the onl" difference is the use of a different operation signature. This ti e we will use the 2andleT"pe para eter. This e.a ple code is described in 8isting 1%.1=.

,isting 13.1A. "etting a handle from the locator and calling service.
86, re#eren%e = 86,.new/nstan%ePlo%atorQS // 8et the han"le #rom the re#eren%e -sing 86, helper %lass 6tring lo%ation = re#eren%e.get!an"lePQ.to6tringPQS !an"le5(pe han"le = new !an"le5(pePlo%ationQS // Ee got a han"le to the instan%e now. Let -s r-n a han"le resol-tion pro%ess 3e#ore servi%e %all sear%h6ervi%e = a%me6ear%hLo%ator.get2%me6ear%h4ortPhan"leQS

The above operation results in a call to the container0s handle revolver service to perfor a handle to the reference resolution 6G32 to G3+ resolution7 for that specific handle. This is happening in an autono ic sense. This handle resolution 3*-P re!uest, and the response essage, is shown in 8istings 1%.$> and 1%.$1.

,isting 13.2C. The invoking handle resolution service #ith the handle to resolve to a service instance reference.
<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e"> <soapenv:$o"(> <#in"$(!an"le xmlns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <han"le6et> <han"le>http://9.5D.3B.@3:90>0/ogsa/servi%es/ph/a%me/2%me6ear%h6ervi% e/hash 2D20>950@ 105>>95D>1D9@</han"le> </han"le6et> <gsrEx%l-sion6et/> </#in"$(!an"le> </soapenv:$o"(> </soapenv:Envelope>

,isting 13.21. ' handle resolution result from the handle resolution service, #ith a "%& )?%D, reference*.
<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/"

xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e"> <soapenv:$o"(> <#in"$(!an"le,esponse xmlns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <lo%ator> <re#eren%e xsi:t(pe="ns1:E61L,e#eren%e5(pe" xmlns:ns1="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <"e#initions name="2%me6ear%h" target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/a%me/servi%e" <<="elete" #or %larit( >

<servi%e name="2%me6ear%h6ervi%e" xmlns:gs"l="http://ogsa.glo3-s.org/"> <<="elete" #or %larit( >

<port 3in"ing="a%mesear%h3in"ing:2%me6ear%h6N24$in"ing" name="2%me6ear%h4ort"> <soap:a""ress lo%ation="http://9.5D.3B.@3:90>0/ogsa/servi%es/ph/a%me/2%me6ear%h6erv i%e/hash 2D20>950@ 105>>95D>1D9@"/> </port> </servi%e> </"e#initions> </re#eren%e> </lo%ator> </#in"$(!an"le,esponse> </soapenv:$o"(> </soapenv:Envelope>

Aow we are finished with this handle resolution, and the stubs are updated with the new location infor ation. The client can begin using these stubs and start invoking operations on the service. /e have previousl" discussed the grid service client-side invocation odels and the corresponding 3*-P essages generated for each process. This infor ation provides us with valuable infor ation, including essage interoperabilit", validation facilit" infor ation, and derived infor ation about the client service interaction. /e can now ove on to our ne.t step of working with grid service behaviors.

&. Get so e grid serviceQspecific properties or service data. 4" now, readers are fa iliar with the *G3#-provided grid service behaviors, and can assert that the -c e3earch3ervice is a grid service based upon our server-side i ple entation and configuration options. Aow we will spend ti e anal"zing the grid service e.posed state data and the operations provided to access these service behaviors. ?irst, let us e.plore the state data e.posed b" the grid service. /e can use the *G3#provided introspection -P#, )find3ervice5ata,) to get the list of e.posed service data ele ents. /e can do this b" asking the grid service to send back the list of GAa e of service data ele ents kept in the )service5ataAa e) 35B0s service data values. This operation is invoked as shown in 8isting 1%.$$.

,isting 13.22. $alling find%erviceData o eration on a service.

extensi3ilit( = sear%h6ervi%e.#in"6ervi%e1ataP+-er(!elper.get)ames+-er(P"servi%e1ata) ame"QQS servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPextensi3ilit(QS N3Ye%tVW servi%e1ata)ames = 2n(!elper.get2sN3Ye%tPservi%e1ataQS #orPint i=0S i<servi%e1ata)ames.lengthS i\\QR +)ame servi%e1ata)ame = P+)ameQ servi%e1ata)amesViWS 6(stem.o-t.printlnP"servi%e1ata)ame: " \ servi%e1ata)ameQS T

The above routine results in the output

essage in 8isting 1%.$%.

,isting 13.23. &esults of find service data o eration on a service.

6ervi%e "ata name: #in"6ervi%e1ataExtensi3ilit( 6ervi%e "ata name: termination5ime 6ervi%e "ata name: #a%tor(Lo%ator 6ervi%e "ata name: servi%e1ata)ame 6ervi%e "ata name: gri"6ervi%e,e#eren%e 6ervi%e "ata name: set6ervi%e1ataExtensi3ilit( 6ervi%e "ata name: gri"6ervi%e!an"le 6ervi%e "ata name: inter#a%e

This lists all the *G3#-defined service data ele ents. 8ater on we will see how we will add our own service-specific service data ele ents, including d"na ic and static 35Bs.

Details o( (ind'erviceData Operation Input %&tensi)ilit* %lement

The find3ervice5ata input e.tensibilit" ele ent is constructed using a !uer" t"pe )!uer"4"3ervice5ataAa es) !uer". This !uer" t"pe definition is si ple, as shown below(
<element name="'-er($(6ervi%e1ata)ames" t(pe="ogsi:+)ames5(pe"/> <%omplex5(pe name="+)ames5(pe"> <se'-en%e> <element name="name" t(pe="+)ame" minN%%-rs="0" maxN%%-rs="-n3o-n"e""/> </se'-en%e> </%omplex5(pe>

The wire representation is shown below(

<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e"> <soapenv:$o"(> <#in"6ervi%e1ata xmlns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <'-er(Expression> <'-er($(6ervi%e1ata)ames xsi:t(pe="ns1:+)ames5(pe" xmlns:ns1="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <name>servi%e1ata)ame</name> </'-er($(6ervi%e1ata)ames> </'-er(Expression> </#in"6ervi%e1ata> </soapenv:$o"(>

-s shown in 8isting 1%.$&, now we can go back to the service and ask each of the above listed service data ele ents for its value using the sa e )find3ervice5ata) operation and )!uer"4"3ervice5ataAa es) e.pression.

,isting 13.2!. Find service data o erations on a service to get the interfaces im lemented by the service.
extensi3ilit( = sear%h6ervi%e.#in"6ervi%e1ataP+-er(!elper.get)ames+-er(P"inter#a%e"QQ S servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPextensi3ilit(QS N3Ye%tVW inter#a%es = 2n(!elper.get2sN3Ye%tPservi%e1ataQS #orPint i=0S i<inter#a%es.lengthS i\\QR +)ame i#a%e = P+)ameQ inter#a%esViWS 6(stem.o-t.printlnP"inter#a%e: " \ i#a%eQS T

The above client-side i ple entation code accesses the )interfaces) 35Bs values defined for our service. The results are shown in 8isting 1%.$5.

,isting 13.20. &esults of the find service data o erations to get the interfaces im lemented by the service.
inter#a%e name: Rhttp://org.ph.gri"3oo&.sample/3ase/a%meT2%me6ear%h4ort5(pe inter#a%e name: Rhttp://org.ph.gri"3oo&.sample/3ase/%a%heT*a%he6ear%h4ort5(pe inter#a%e name: 8ri"6ervi%e

inter#a%e name: Rhttp://org.ph.gri"3oo&.sample/3ase/generalT8eneral6ear%h4ort5(pe

8isting 1%.$5 illustrates a runti e behavior of a grid service whereb" we can infer the interfaces e.posed b" the services. 3o far our discussion was centered on the grid service0s default public e.posed state. /e will see ore co ple. behaviors later in this chapter when we cover advanced topics on service data and notification. 5. ?inall", we are now done with the service. /e can re ove the service instance b" calling an e.plicit destro" on the service instance.

- client can control the service lifec"cle using soft state echanis s or b" e.plicitl" calling the Gridservice )destro") operation on the service. 8isting 1%.$: illustrates the use of the e.plicit )destro") operation b" the client.

,isting 13.21. $alling e2 licit destruction on the grid service instance.

8ri"6ervi%e gri"6ervi%e = gri"Lo%ator.get8ri"6ervi%e4ortPlo%atorQS gri"6ervi%e."estro(PQS

The success of the above routine depends on various factors including the service policies applicable to the client and the service hosting environ ent properties. /e can enable a soft state destruction b" using the ter ination ti e of the create3ervice call para eter or b" e.plicitl" odif"ing the odifiable service data ele ent )ter inationTi e.) #n such cases the GT% container will take the responsibilit" to destro" the service after the ter ination ti e e.piration. The destruction se antic is depending on container i ple entation logic with the onl" assertion that, once destructed, the clients cannot access the service instance an" ore using the sa e G32. 4" now we have been introduced to the basic service i ple entation, configuration, and grid service behaviors. Aow we can ove on to ore co ple. service i ple entation concepts. /e ust note that enabling the logging and tracing infor ation helps us understand the essage flow between the client and the service. #n the previous chapter on the progra ing odel, we have covered the details on the various options to enable this feature. "dvan#ed Grid 0ervi#e #n this section we will go through so e advanced concepts around grid services. These include the use of operation providers to i ple ent service port t"pes, different t"pes of service data, its creation and usage patterns, and notification echanis s. /e will start with service data concepts. "dvan#ed 0ervi#e )ata Con#epts These are publicl" available states of a service. There are two t"pes of service data ele ents, static and d"na ic. The static service data ele ents are declared in the G/358 and added to the service instance service data set upon service instance startup. The fra ework does this b" reading the G/358 descriptions of the service. These service data ele ents will be available in the data set of the instance throughout the lifeti e of the service. 2owever, their values and availabilit" are depending on the configuration of these ele ents, including utabilit" attributes and lifeti e attributes. #n our e.a ple, we are going to create two service data ele ent declarations, one in the Cache3earchPortT"pe and the other in the General3earchPortT"pe. 8istings 1%.$;

and 1%.$< are e.tensions to the portT"pe declarations we have created earlier in this chapter.

,isting 13.24. -2tended "eneral%earch7ortTy e ortTy e #ith service data elements.

<"e#initions name="8eneral6ear%h" .................................................. <t(pes> <xs":s%hema .................................................. <xs":%omplex5(pe name="6ear%h4rovi"er5(pe"> <xs":se'-en%e> <xs":element name="name" t(pe="xs":string"/> <xs":element name="-rl" t(pe="xs":string"/> </xs":se'-en%e> </xs":%omplex5(pe>

</xs":s%hema> </t(pes> .................................................. <gws"l:port5(pe name="8eneral6ear%h4ort5(pe" exten"s="ogsi:8ri"6ervi%e"> <operation name="sear%h"> ...................................................... </operation>

<s":servi%e1ata name="sear%h4rovi"er" t(pe="general:6ear%h4rovi"er5(pe" minN%%-rs="1" maxN%%-rs="-n3o-n"e"" m-ta3ilit(="stati%" mo"i#ia3le="#alse"

nilla3le="#alse"/>

<s":stati%6ervi%e1ataCal-es> <general:sear%h4rovi"er> <name>8oogle</name> <-rl>www.google.%om</-rl> </general:sear%h4rovi"er> <general:sear%h4rovi"er> <name>;6)</name> <-rl>www.msn.%om</-rl> </general:sear%h4rovi"er> </s":stati%6ervi%e1ataCal-es>

</gws"l:port5(pe> </"e#initions>

4" careful observations we can see that this publicl" e.posed state )searchProvider) is a static service data ele ent and needs to be initialized in the /358 using static3ervice5ataKalues, as shown in 8isting 1%.$;.

,isting 13.2;. -2tended $ache%earch7ortTy e ortTy e #ith service data elements.

<?xml version="1.0" en%o"ing=".5O >"?> <"e#initions name="8eneral6ear%h" .......................................

<t(pes> <xs":s%hema ..................................... <xs":%omplex5(pe name="sear%h*a%he6iGe5(pe"> <xs":se'-en%e> <xs":element name="new6iGe" t(pe="xs":int"/> </xs":se'-en%e>

</xs":%omplex5(pe>

</xs":s%hema>

</t(pes> .................................. <gws"l:port5(pe name="*a%he6ear%h4ort5(pe" exten"s="ogsi:8ri"6ervi%e"> <operation name="%a%he6ear%h"> ............................................ </operation>

<s":servi%e1ata name="sear%h*a%he6iGe" t(pe="%a%he:sear%h*a%he6iGe5(pe" minN%%-rs="1" maxN%%-rs="-n3o-n"e"" m-ta3ilit(="m-ta3le" mo"i#ia3le="tr-e" nilla3le="#alse"/>

</gws"l:port5(pe>

</"e#initions>

-s shown in 8isting 1%.$<, the publicl" e.posed state )sear%h*a%he6iGe) is a utable service data ele ent. This enables the service clients to odif" 6 odifiableS0true07 this service data value using the )set3ervice5ata) operation. *ne thing to notice is the t"pe of 35B and their corresponding 918 sche a t"pe. The 35B values are initialized using those t"pes. -s we have noticed earlier, these t"pes are converted to their corresponding Cava t"pes b" the tool /358$Cava. The above 935 t"pes in the e.a ple generate )6ear%h*a%he6iGe5(pe), )6ear%h4rovi"er5(pe) classes.

4" default, these service data ele ents are loaded to the -c e 3earch 3ervice instance0s service data set upon service initialization. /e ust be aware that the -c e3earchPortT"pe e.tends the above portT"pes and thereb" has all these 35Bs with it. *ne thing to notice is that these service data ele ents defined b" the super t"pes can be overridden b" the derived t"pes. +efer back to our discussions in the *G3# chapter for ore details on these capabilities. *n the assu ption that we have deplo"ed this service to the container, let us the client side to start working with these service data constructs. ove to

Aow, if running the client code shown in 8isting 1%.$$, it ust displa" two ore additional service data ele ents in addition to the standard Grid3ervice defined ones. /e can ask the service for the specific values of the static service data ele ent )sear%h4rovi"er) using the find3ervice5ata ethod shown in 8isting 1%.$=.

,isting 13.2A. $alling find service data to get the statically configured search roviders.
// 8et the servi%e "ata val-es #or 61E "sear%h4rovi"er" extensi3ilit( = sear%h6ervi%e.#in"6ervi%e1ataP+-er(!elper.get)ames+-er(P"sear%h4rovi" er"QQS // 8et the 3ase the servi%e "ata val-e t(pe servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPextensi3ilit(QS

// *onvert the elements to the &now t(pe 6ear%h4rovi"er5(pe N3Ye%tVW provi"erCal-es = 2n(!elper.get2sN3Ye%tPservi%e1ataJ6ear%h4rovi"er5(pe.%lassQS

// "ispla( the sear%h provi"er in#ormation #orPint i=0S i<provi"erCal-es.lengthS i\\QR 6ear%h4rovi"er5(pe sear%h4rovi"er = P6ear%h4rovi"er5(peQ provi"erCal-esViWS 6(stem.o-t.printlnP"sear%h4rovi"er name: " \ sear%h4rovi"er.get)amePQQS T

The routine in 8isting 1%.$= should displa" the infor ation in 8isting 1%.%>, which are configured as static service data ele ent values.

,isting 13.3C. &esults on calling the find service data o eration.

sear%h4rovi"er name: 8oogle sear%h4rovi"er name: ;6)

*ne of the service data ele ents 6searchCache3ize7 we have added to the /358 is changeable b" the client. /e have entioned earlier that for this to be successful we need to set service data ele ent attribute ) odifiable) with a value of )true.) This enables the client to invoke a set3ervice5ata operation on this service data ele ent with a new value for the )6ear%h*a%he6iGe5(pe) ob,ect. The code in 8isting 1%.%1 illustrates this process.

,isting 13.31. %et service data o eration on a service data element.

6ear%h*a%he6iGe5(pe new*a%heCal-e = new 6ear%h*a%he6iGe5(pePQS // set a new %a%he new*a%heCal-e.set)ew6iGeP3@QS

org.apa%he.axis.message.;essageElement elem = Porg.apa%he.axis.message.;essageElementQ2n(!elper.to2n(Pnew*a%heCal-e QS org.apa%he.axis.message.;essageElement setErapper = new org.apa%he.axis.message.;essageElementPQS setErapper.set+)amePorg.glo3-s.ogsa.8ri"*onstants.6E5I$HI)2;EQS setErapper.a""*hil"PelemQS

Extensi3ilit(5(pe an( = new Extensi3ilit(5(pePQS an(.setIan(Pnew org.apa%he.axis.message.;essageElementVW R setErapper TQS

// %alls the set6ervi%e1ata operation to -p"ate the servi%e "ata sear%h6ervi%e.set6ervi%e1ataPan(QS

To further illustrate this, let us e.a ine the 3*-P above update essage.

essage in 8isting 1%.%$ for the

,isting 13.32. %9'7 re@uest message for set service data.

<soapenv:Envelope xmlns:soapenv="http://s%hemas.xmlsoap.org/soap/envelope/" xmlns:xs"="http://www.w3.org/2001/F;L6%hema" xmlns:xsi="http://www.w3.org/2001/F;L6%hema instan%e">

<soapenv:$o"(> <set6ervi%e1ata xmlns="http://www.gri"#or-m.org/namespa%es/2003/03/N86/"> <-p"ateExpression> <set$(6ervi%e1ata)ames> <ns2:val-e xsi:t(pe="ns1:sear%h*a%he6iGe5(pe" xmlns:ns1="http://org.ph.gri"3oo&.sample/servi%e"ata/%a%he" xmlns:ns2="http://ogsa.glo3-s.org/"> <ns1:new6iGe>3@</ns1:new6iGe> </ns2:val-e> </set$(6ervi%e1ata)ames> </-p"ateExpression> </set6ervi%e1ata> </soapenv:$o"(> </soapenv:Envelope>

3o far we have been dealing with the static service data ele ents declared as part of G/358. Aow let0s turn our attention to so e d"na ic service data ele ents created b" the service. The d"na ic service data ele ents can be created at an" ti e and can be added to the service data set. This is done with the help of an instance-specific service data set ob,ect. The routine in 8isting 1%.%% illustrates how our -c e 3earch 3ervice instantiates a d"na ic service data ob,ect and adds that to the service data set.

,isting 13.33. $reating dynamic service data element.

//*reate 6ervi%e 1ata Element 6ervi%e1ata servi%e1ataElement = this.get6ervi%e1ata6etPQ.%reateP";(6ervi%e1ata"QS // *reate a servi%e "ata val-e an" set that val-e // *an 3e %omplex o3Ye%ts or simple. Ehat is shown here is a simple Yava MstringM servi%e1ataElement.setCal-eP"m( simple servi%e "ata element"QS //2"" 61E to 6ervi%e 1ata 6et this.get6ervi%e1ata6etPQ.a""Pservi%e1ataElementQS // now onwar"s availa3le #or %lient "is%over(

*nce this d"na ic service data is added to the service data set, the client can !uer" for the and can work with the 68isting 1%.%&7.

,isting 13.3!. 'ccessing the dynamic service data element.

extensi3ilit( = sear%h6ervi%e.#in"6ervi%e1ataP+-er(!elper.get)ames+-er(P";(6ervi%e1at a"QQS

servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPextensi3ilit(QS N3Ye%tVW m(61Cal-e = 2n(!elper.get2sN3Ye%tPservi%e1ataQS #orPint i=0S i<m(61Cal-e.lengthS i\\QR 6tring m(Cal-e = P6tringQ m(61Cal-eViWS 6(stem.o-t.printlnP"1(nami% s" val-e : " \ m(Cal-eQS T

The clients can do d"na ic service introspection on the service to find the available 35Bs 6static and d"na ic7 at an" point in ti e. The proble with d"na ic service data ele ents is the unavailabilit" of the se antics of the service state data to the clients. This a" get co plicated on the processing of these d"na ic service data unless the client knows or there is an a priori agree ent on the se antics and t"pe of this data. .peration Providers The concept of operation providers helps the server-side developers to separate the application logic e.ternal to the service i ple entation code. /e have discussed the value-added features provided b" this fra ework. Aow we will see how we can co e up with an e.tendable and anageable application design for our service. /e decided that all our business logic should be e.ternal to the service i ple entation so that the" can grow as the service gets atured. ?or e.a ple, our caching search service is ver" pri itive at this stage. 2owever, later we a" co e up with ore co ple. and valuable i ple entations for the sa e without disrupting the e.isting service i ple entation. /e can plug in the new provider through the service configuration options. This provides a highl" fle.ible approach. /e are going to i ple ent the General3earchPortT"pe and Cache3earchPortT"pe interfaces in different providers. /e will create two providers, General3earchProvider and Cache3earchProvider. *ur service i ple entation looks si ilar to the @18 diagra shown in ?igure 1%.:.

Figure 13.1. 'cme service im lementation using 9 eration7rovider.

8et us now take a look into the code of one provider, Cache3earchProvider in 8isting 1%.%5.

,isting 13.30. 9 eration rovider im lementation.

p-3li% %lass 8eneral6ear%h4rovi"er implements Nperation4rovi"er R p-3li% stati% +)ameVW operations = new +)ameVW R "sear%h" TS p-3li% +)ameVW getNperationsPQ R ret-rn operationsS T new +)amePhttp://org.ph.gri"3oo&.sample/3ase/generalJ

p-3li% voi" initialiGeP8ri"6ervi%e$ase 3aseQ throws 8ri"6ervi%eEx%eption R T

p-3li% 8eneral6ear%h4rovi"er PQ R T

p-3li% 6ear%h,esponse5(pe sear%hP6ear%h5(pe sear%h/np-tQ Yava.rmi.,emoteEx%eptionR throws

6ear%h,esponse5(pe response = new 6ear%h,esponse5(pePQS response.set.,LP"www.i3m.%om"QS response.set6-mmar(P"/$;"QS

response.set*a%he"Ptr-eQS ret-rn responseS T T

8isting 1%.%5 illustrates how we can separate our portT"pe i ple entation out of the service code and ove that to an operation provider. *n careful e.a ination, we can see that the public operations we are e.posing are listed in the GAa e list. These operations correspond to their /358 counterparts. These are e.posed through the get*perations67 ethod. *ur service i ple entation onl" i ple ents the spellCheck ethod. 3ince our -c e3earchPortT"pe lists all the abstract interfaces, we need to add these additional operations to our service code as te plates to satisf" our co pilers. The client code re ains the sa e. 2owever, we need to add the above provider to the configurations list, as shown in 8isting 1%.%:.

,isting 13.31. $onfiguring o eration rovider #ith the service configuration.

<servi%e name="ph/a%me/operationprovi"er/2%me6ear%h6ervi%e" provi"er="!an"ler" st(le="wrappe""> ............................ <parameter name=" instan%e operation4rovi"ers" val-e="org.ph.gri"3oo&.impl.operationprovi"er.*a%he6ear%h4rovi"er "/> org.ph.gri"3oo&.impl.operationprovi"er.8eneral6ear%h4rovi"er

</servi%e>

/e are now done with the service configuration and our client can start invoking operations on our service using the sa e client code shown earlier.

7roviding 'synchronous 8ehaviors through 5otification

The notification echanis defined b" *G3# is ver" fle.ible. #t provides a fle.ible subscription echanis b" allowing different t"pes of subscription e.pressions as specified b" the service. -ll service is re!uired to provide the )subscribe4"3ervice5ataAa e) e.pression. This enables clients to register for notification on service data ele ent value changes. The Globus GT% fra ework supports this default behavior. #n addition, it can be e.tensible to support a topicbased subscription, which is a derivative odel fro the above, )subscribe4"3ervice5ataAa e) t"pe of subscription. #n the previous chapter, we have covered the details on the GT% architectural and progra ing support for notifications. Aow it0s code ti eF we will discuss the topics we have covered in the last chapter with so e sa ple code. /e will e.tend our -c e3earch3ervice as a notification provider. These sa ples will illustrate(

1. 3ubscribing for service data change using service data na e ele ent $. 3ubscribing for so e interesting topics e.posed b" the -c e3earch3ervice. 8et us e.plore the details.

%ubscribing for %ervice Data $hange /sing %ervice Data 5ame -lement
?igure 1%.; illustrates the basic concept. Clients can subscribe for service data value change through subscription b" providing the interested service data ele ent na e.

Figure 13.4. 5otification based on service data change.

?irst and fore ost, the change we have to ake is to let the service i ple ent the Aotification 3ource portT"pe as defined b" *G3#. /e can do this b" changing the G/358 portT"pe definition of our service. 8isting 1%.%; shows how we will change the -c e3earchPortT"pe in the gwsdl.

,isting 13.34. 'cme service e2tending notification source ortTy e.

<?xml version="1.0" en%o"ing=".5O >"?> <"e#initions name="2%me6ear%h" target)amespa%e="http://org.ph.gri"3oo&.sample/3ase/a%me" ..............................."> ..................................... <gws"l:port5(pe name="2%me6ear%h4ort5(pe" exten"s="ogsi:8ri"6ervi%e ogsi:)oti#i%ation6o-r%e general:8eneral6ear%h4ort5(pe %a%he:*a%he6ear%h4ort5(pe"> <operation name="spell*he%&"> <inp-t message="a%me:6pell*he%&/np-t;essage"/> <o-tp-t message="a%me:6pell*he%&N-tp-t;essage"/> </operation> </gws"l:port5(pe>

</"e#initions>

-s shown in 8isting 1%.%;, we have e.tended our portT"pe fro ogsi(Aotification3ource interface. /hile running the tools 6G/358$/358, Generate4inding, and then G/358$Cava7, we will be able to generate the necessar" stubs and portT"pes that can handle the notification subscription process. #n the previous chapter, we described these listed tools and their utilization odel. The generated -c e3earchPortT"pe interface contains a )subscribe) operation, in addition to the other operations we saw earlier. This interface is in 8isting 1%.%<.

,isting 13.3;. -nd oint interface for 'cme %earch %ervice #ith notification o erations.
pa%&age org.ph.gri"3oo&.noti#i%ationS

p-3li% inter#a%e 2%me6ear%h4ort5(pe exten"s org.gri"#or-m.ogsi.8ri"6ervi%e R

// ;ost o# the Ex%eptions are not shown #or %o"e %larit(.............. p-3li% org.gri"#or-m.ogsi.Extensi3ilit(5(pe #in"6ervi%e1ataPorg.gri"#or-m.ogsi.Extensi3ilit(5(pe '-er(ExpressionQ throws Yava.rmi.,emoteEx%eptionJ ...................S

p-3li% voi" s-3s%ri3ePorg.gri"#or-m.ogsi.Extensi3ilit(5(pe s-3s%riptionExpressionJ org.gri"#or-m.ogsi.Lo%ator5(pe sin&J org.gri"#or-m.ogsi.Exten"e"1ate5ime5(pe expiration5imeJ org.gri"#or-m.ogsi.hol"ers.Lo%ator5(pe!ol"er s-3s%ription/nstan%eLo%atorJ org.gri"#or-m.ogsi.hol"ers.5ermination5ime5(pe!ol"er %-rrent5ermination5imeQ throws Yava.rmi.,emoteEx%eptionJ....S .......................................... p-3li% voi" "estro(PQ throws Yava.rmi.,emoteEx%eptionJ.............S

p-3li% org.ph.gri"3oo&.noti#i%ation.6pell*he%&;essage,esponse5(pe spell*he%&Porg.ph.gri"3oo&. noti#i%ation.6pell*he%&;essage5(pe spell*he%&/np-tQ throws Yava.rmi.,emoteEx%eptionS

// some metho"s are not shown #or %o"e rea"a3ilit(................. T

The GT% fra ework co es with a nu ber of fra ework co ponents to deal with the service data change notification. The default Aotification3ourceProvider class provides ost of the re!uired functionalit", so we need to configure our service to use the default notification source provider. 8isting 1%.%= shows how to add this new instance operation provider to our configuration.

,isting 13.3A. %ervice configuration #ith notification source rovider.

<servi%e name="ph/a%me/operationprovi"er/2%me6ear%h6ervi%e" provi"er="!an"ler" st(le="wrappe""> ................................ <parameter name=" instan%e operation4rovi"ers" val-e="org.ph.gri"3oo&.impl.operationprovi"er.*a%he6ear%h4rovi"er org.ph.gri"3oo&.impl.operationprovi"er.8eneral6ear%h4rovi"er org.glo3-s.ogsa.impl.ogsi.)oti#i%ation6o-r%e4rovi"er"/> </servi%e>

-t the client side we need to provide two i ple entation artifacts(

Create a sink listener to receive notification. - sink should i ple ent the *G3# Aotification3ink interface and e.pose the )deliverAotification) operation. This sink is a grid service with a uni!ue handle 6G327 and the client sends this handle to the service during subscription in order to receive notification callbacks. This process is si pler if our client is a grid service. 2owever, since our current client is a Cava application, we need a container to support this at the client side to create the sink service, and to listen for the essage deliver". ?or this to occur, we will ake use of the lightweight client container included with GT%.

The routine in 8isting 1%.&> e.plains how we are initializing this container and listening on a port. /e can alwa"s configure so e of the properties, including the port, protocol, and hostna e of this client-side container through the client-serverconfig.wsdd file.

,isting 13.!C. $onfiguring the client sink container.

// *reate a sin& managerJ whi%h provi"es a lightweight %ontainer %apa3ilit( )oti#i%ation6in&;anager noti#;anager = )oti#i%ation6in&;anager.get;anagerPQS

// 6tart listening on a port noti#;anager.startListeningP)oti#i%ation6in&;anager.;2/)I5!,E21QS

// )ee" to %reate a sin& %all3a%& o3Ye%tJ whi%h implements the )oti#i%ation6in&*all3a%& inter#a%e )oti#i%ation6in&*all3a%& %lient = new m()oti#i%ation6in&*all3a%&/mplPQS

Create a subscription with the service. The subscription process is si ple, provided we are using the notification anager as shown above. The onl" re!uire ent is to add a deliver" essage listener of t"pe Aotification3inkCallback and add that listener to the anager along with the service data ele ent na e 6identified using na e or GAa e7 for which we are listening for changes. This listener i ple ents a )deliverAotification) operation, which will be called on notifications fro the service. The routine in 8isting 1%.&1 shows how we will be enabling the callback and sending a subscribe call to the source service.

,isting 13.!1. %ubscribing for service data change notifications.

// 6-3s%ri3e #or servi%e "ata noti#i%ation 3( passing the servi%e "ata nameJ han"le o# the servi%e instan%e whose 61 %hanges we are wat%hingJ an" the noti#i%ation sin& %all3a%& metho" 6tring sin& = noti#;anager.a""ListenerP";(6ervi%e1ata"J n-llJ han"leJ %lientQS

Ae.t, we will i ple ent the notification receiver to receive change notification essages fro the service instance 68isting 1%.&$7.

,isting 13.!2. &eceiving messages from the service.

*lass m()oti#i%ation6in&*all3a%&/mpl implements )oti#i%ation6in&*all3a%& R p-3li% voi" "eliver)oti#i%ation PExtensi3ilit(5(pe an(Q throws ,emoteEx%eptionR 6ervi%e1ataCal-es5(pe servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPan(QS N3Ye%tVW m(61Cal-e = 2n(!elper.get2sN3Ye%tPservi%e1ataQS #orPint i=0S i<m(61Cal-e.lengthS i\\QR 6tring m(Cal-e = P6tringQ m(61Cal-eViWS

6(stem.o-t.printlnP",e%eive" a noti#i%ation #rom servi%e with val-e: " \ m(Cal-eQS T T T

#t is i portant to understand whenever there is a change in the service data ele ent 6identified b" )1"3ervice5ata)7, a notification essage will be sent to the client. -s shown in 8isting 1%.&%, we can force this notification push fro our service code using a )notif"Change67) essage.

,isting 13.!3. %ervice code to ush an %D notification change to the client.

/0 Ee saw earlier that this is a "(nami% servi%e "ata element an" it is alrea"( "e#ine" an" %reate" #or the servi%e. )ow get the 61E an" %hange its val-e 0/ 6ervi%e1ata servi%e1ataElement= get6ervi%e1ata6etPQ.getP";(6ervi%e1ata"QS servi%e1ataElement.setCal-eP"2 %hange" servi%e "ata val-eX"QS // )oti#( the servi%e "ata element %hange servi%e1ataElement.noti#(*hangePQS

Pa"ing close attention to the above i ple entation logic, we can infer that the above process is static in nature, based upon the service data and its t"pe. /e can e.tend this odel to a ore generalized solution for as"nchronous essages, where the topics can be broader than the service data ele ents, and the data can be of an" t"pe.

%ubscribing for %ome +nteresting To ics -2 osed by the 'cme%earch%ervice

?igure 1%.< e.plains a d"na ic notification process using the concept of )topics.) service can e.pose so e topics, to which it feels relevant for the clients to subscribe. These topics can be created d"na icall" upon service startup. These topics are added to the provider. The provider currentl" e.poses these d"na ic topics in the service data ele ent set. The routine in 8isting 1%.&& e.plains how we can do this. There is no configuration change needed for the service.

,isting 13.!!. $reating dynamic to ics and adding to the rovider.

)oti#i%ation4rovi"er provi"er =P)oti#i%ation4rovi"erQ get4ropert(P 6ervi%e4roperties.)N5/O/*25/N)I6N.,*EQS

// a""ing a topi% o# interest with the noti#i%ation provi"er with a namespa%e an" message t(pe provi"er.a""5opi%P"6ervi%e1estro()oti#i%ation"J new +)ameP"http://org.ph.gri"3oo&.sample/noti#i%ation/a%me"J "xs":string"Q

Figure 13.;. Dynamic to ic-based subscri tion.

The clients can now discover this topic through the )find3ervice5ata) operation and can register for that d"na ic topic 68isting 1%.&57.

,isting 13.!0. Finding the dynamic to ics adding to the rovider.

extensi3ilit( = sear%h6ervi%e.#in"6ervi%e1ataP+-er(!elper.get)ames+-er(P"servi%e1ata) ame"QQS servi%e1ata = 2n(!elper.get2s6ervi%e1ataCal-esPextensi3ilit(QS N3Ye%tVW servi%e1ata)ames = 2n(!elper.get2sN3Ye%tPservi%e1ataQS #orPint i=0S i<servi%e1ata)ames.lengthS i\\QR +)ame servi%e1ata)ame = P+)ameQ servi%e1ata)amesViWS 6(stem.o-t.printlnP"servi%e1ata)ame: " \ servi%e1ata)ameQS T

The above call should list \http(''org.ph.gridbook.sa ple'notification'ac e( 3ervice5estro"Aotification] as one of the service data ele ents. This is the e.posed )topic) and the clients can register their interest in this topic using the routine shown in 8isting 1%.&:.

,isting 13.!1. 'dding a listener on the dynamic to ics.

+)ame s"name = new +)ameP"http://org.ph.gri"3oo&.sample/noti#i%ation/a%me"J " 6ervi%e1estro()oti#i%ation "QS

6tring sin& %lientQS

noti#;anager.a""ListenerPs"nameJ n-llJ han"leJ

*n running the code in 8isting 1%.&:, the client is read" to receive notification fro the service instance when it is tr"ing to destro" the service. 8et us now see how the service is sending the change notifications related to the above topic. The routine in 8isting 1%.&; shows how we can do this.

,isting 13.!4. %ending a notification.

provi"er.noti#(P"6ervi%e1estro()oti#i%ation"J"/ am "estro(ing..."QS

*ne thing we didn0t ention is regarding the lifec"cle of the subscription. *n a subscription essage fro the client, the grid service instance creates a Aotification3ubscription ob,ect with the necessar" subscription infor ation, including the subscription lifeti e. This is a grid service instance and a G32 is passed back to the client. The client can control the lifec"cle of a subscription through soft state anage ent echanis s. *nce the client feels that the subscription is no longer needed, it can call the nor al grid service )destro") operation on the subscription ob,ect to get the subscription re oved. The above-described notification echanis s can be further e.tended to support ore co ple. echanis s including the subscription criteria for filtering, essage batching, and the use of a ore reliable essage e.change odel.

-38 Delegation
-s shown in ?igure 1%.=, GT% provides a delegation logic i ple ented in the BC4. odel to support the business

Figure 13.A. Delegation-based grid services.

The default factor" can be configured to have an BC4 callback i ple entation provided with GT%, which provides support to connect to BC4 ho e and create an BC4 re ote ob,ect of choice. The configuration for the CA5# na e for the ho e lookup is configured as a service configuration para eter. The service developers are re!uired to derive their service i ple entations fro the abstract BC43ervice# pl class to provide a constructor that can accept the BC4 2o e and BC4 +e ote ob,ects. The @18 diagra 6logical7 in ?igure 1%.1> shows a delegation odel.

Figure 13.1C. -38 delegation model.

The internal i ple entation of the callback ob,ect is si ple. 4ased on the t"pe of BC4, it either creates the BC4 or tries to find the BC4. This is done b" introspection on the etadata provided b" the BC4 ho e ob,ect 6through the call ho e.getBC41eta5ata677. This introspection provides infor ation such as the t"pe 6stateless, stateful, or entit"7 of BC4. 4ased on these etadata infor ation it either creates the bean or tries to find the bean using the pri ar" ke". -fter the retrieval of the ho e and re ote ob,ects, the callback creates the grid service instance and initializes the service with the BC4 ho e and re ote ob,ects. Aow let us see how our -c e service0s cache can be i ple ented in an BC4 entit" bean. /e won0t talk about the BC4 i ple entation. *ur assu ption is that we have alread" created an entit" BC4 bean ob,ect, and its corresponding 2o e ob,ect, and both are deplo"ed to the C$BB container. The ho e is identified through the CA5# na e )ph'cache'B,bCache.) 8et us now create our -c e 3earch grid service, and the delegate calls to the )cache3earch) for the corresponding BC4 re ote operation. 8isting 1%.&< shows how we can do this.

,isting 13.!;. "rid service im lemented #ith -38 delegation mechanism.

p-3li% %lass m(EU$6ervi%e/mpl exten"s EU$6ervi%e/mpl implements 2%me6ear%h4ort5(pe R p-3li% m(EU$6ervi%e/mplP 6tring nameJ EU$!ome IhomeJ EU$N3Ye%t IremoteQ R s-perPnameJ IhomeJ IremoteQS T p-3li% *a%he6ear%h;essage,esponse5(pe %a%he6ear%hP*a%he6ear%h;essage5(pe %a%he6ear%h/np-tQ throws Yava.rmi.,emoteEx%eptionR // extra%t the sear%h inp-t "ata

// %onvert to EU$ a%%epta3le serialiGa3le o3Ye%ts // %all metho" on the remote o3Ye%t get,emotePQ.%a%he6ear%hPQS // get the res-lts an" %onvert that to *a%he6ear%h;essage,esponse5(pe // sen" 3a%& the res-lt ret-rn new *a%he6ear%h;essage,esponse5(pe PQS T .................................... T

The deplo" ent of the service with the BC4 ho e CA5# na e is in the configuration frag ent in 8isting 1%.&=.

,isting 13.!A. "rid service and delegation -38 home 35D+ configuration.
<servi%e name="ph/a%me/eY3/2%me6ear%h6ervi%e" provi"er="!an"ler" st(le="wrappe""> ..................................... <parameter name="eY3Loo&-p6tring" val-e=" ph/%a%he/EY3*a%he"/>

<parameter name="#a%tor(*all3a%&" val-e="org.glo3-s.ogsa.impl.%ore.#a%tor(.EU$Oa%tor(*all3a%&"/> <parameter name="operation4rovi"ers" val-e="org.glo3-s.ogsa.impl.ogsi.Oa%tor(4rovi"er"/> ..................................... </servi%e>

Con#lusion
/e have been discussing the GT% toolkit, providing a reference i ple entation of *G3# and e.plaining the core concepts of a grid service and its behaviors through so e rather si ple e.a ples. The ain idea of this discussion was to introduce the toolkit core co ponents and capabilities. This GT% fra ework provides a rich enough environ ent to support a nu ber of co ple. service creation scenarios. -s we have noted, the Globus GT% high-level services, such as inde. services, infor ation services, and G+-1 are all built upon this core GT% fra ework. #n the ne.t chapter, we will see ore details on these high-level grid services.

Introdu#tion
Grid technologies enable large-scale sharing of resources within a group of individuals and'or institutions. There are three co ple. areas in the grid environ ent that re!uires our attention( resource discover"' onitoring, resource allocation, and data anage ent. This chapter will address these ke" areas.

2esour#e )is#over( and 3onitoring

The co ple. grid environ ent, with a nu ber of d"na ic behaviors and co ple. geographical distribution, introduces a nu ber of challenges, including discover", opti ization, classification, aggregation, and onitoring of sharable resources. These resources can be broadl" classified as co putational data resources. #n order to reduce this co ple.it" fro the end user of the grid s"ste , a nu ber of infor ation services are generated with funda ental capabilities of resource discover", classification, and onitoring. *nce the clients are able to discover and onitor these resources, these resources will help clients to plan the resource utilization, and can then adapt clients to the application behavior. These t"pes of services are generall" classified as infor ation services

2esour#e "llo#ation
-llocation of resources in a grid environ ent is co ple.. #t re!uires the knowledge of user re!uire ents, resource capabilities, and other econo ic criteria 6e.g., price and ti e etrics7. The ore precise the allocation process, the ore efficient the resource utilization is, and ulti atel" the user satisfaction. There are provisions available toda" to acco plish advance resource reservations in order to provide *n 5e and, d"na ic resource provisioning.

)ata 3anagement
1an" of the grid s"ste s that e.ist toda" are data intensive and ust be capable of transporting ver" large a ounts of data, both static and in real ti e. The abilit" to access and anage data is another i portant area in co putational and data grids. This involves oving data between grid resources, and'or allowing resource access to the data, *n 5e and. These kinds of data ove ent activities are ver" co on in ,ob schedulers. ?igure 1&.1 shows the logical la"ers in grid architecture. The base services and the data services together provide ost of the basic facilities we have previousl" discussed. These are re!uired for high-level grid applications and services, including ,ob anagers, schedulers, resources, and provisioning agents. These high-level services and applications utilize these base services for resource discover", classification, resource allocation, resource usage planning, onitoring, and scheduling.

Figure 1!.1. This illustration de icts a logical vie# of the levels of grid services.

#t is reco ended that one i ple ent a iddleware tool to provide so e of these base services. Globus Toolkit 6GT%7 provides a nu ber of these high-level services. These high-level services are utilizing the core GT% fra ework as the funda ental set of building blocks. #n GT%, there are infor ation services, resource allocation services, and data services available to the developer. /e will discuss each of these co ponent details in the co ing pages.

In!ormation 0ervi#es
#n the conte.t of GT%, infor ation services have to fulfill the following re!uire ents(

- basis for configuration and adaptation in heterogeneous environ ents @nifor and fle.ible access to static and d"na ic infor ation 3calable and efficient access to data -ccess to ultiple infor ation sources aintenance capabilities

5ecentralized

*ur discussion will be focused on GT%, the latest toolkit based on the *G3#. #n the GT% base, the infor ation services consist of a broad fra ework that includes an" part of GT%.

This fra ework can generate i portant capabilities, such as register, inde., aggregate, subscribe, onitor, !uer", and'or displa" service data. The core concepts of infor ation services in GT% are centered on how to create, update, and !uer" service dataF this for s the public state of a service'resource. GT% provides a set of infor ation services built utilizing a service data co ponent odel. @tilizing the GT% core progra ing features, which we have discussed in the last two chapters, develops this co ponent odel. The develop ent of a co ponent odel helps service developers to deal with the co ple.it" of software anage ent in relativel" s all anageable software odules. The GT%-offered co ponent odel is based upon Cava. ?igure 1&.$ shows the a,or infor ation services available with the GT% base, and the co ponents utilized b" these services. The details related to this discussion on this co ponent odel and services are as follows( 1. The GT% fra ework provides a co ponent odel that can be utilized to create and deliver infor ation services. $. The GT% fra ework provides high-level applications and services, built upon the above co ponent odel.

Figure 1!.2. The "T3 com onents and information services.

Component 3odel !or In!ormation 0ervi#es These co ponents provide a standard

eans

to create the service data fro other grid services and e.ternal applications. to aggregate the service data values and categorize the in a for re!uired b" the

application.

to provide the storage location6s7 to register and store grid service handles. These registered grid services provide service data either through a provider )pull) or through notification on the service data change.

Generall" speaking, there are three t"pes of co ponents available( service data provider co ponents, service data aggregation co ponents, and registr" co ponents. 8et us now further e.plore each of these co ponents, their functionalities, and their progra ing odels.

%ervice Data 7rovider $om onents

These providers enable a standard echanis for d"na ic service data generation fro e.ternal progra s. The GT% core provides a set of providers, which provides so e co on set of functionalities. /e will cover the usage of these providers later in this chapter when we introduce the inde. services. /e can e.tend these providers, or add on new providers. The service data provider interfaces are designed to support the e.ecution in either s"nchronous 6pull7 or as"nchronous 6push7 odes. 5ifferent provider interfaces are available and selected based on their functionalities. These provider interfaces are( 3i ple5ataProvider. This is a s"nchronous provider that is capable of producing output in 918 for at in a Cava *utput3trea .

,isting 1!.1. The sim leData7rovider interface.

p-3li% inter#a%e 6imple1ata4rovi"er R ........................................................ /0 5riggers the exe%-tion o# the provi"er in or"er to -p"ate the provi"erMs internal stateJ 3-t "oes not per#orm an( o-tp-t.0/

voi" -p"ateP6tring argsQ throws Ex%eptionS

/0 5riggers the provi"er to serialiGe its %-rrent internal state to the spe%i#ie" N-tp-t6tream 0/

voi" o-tp-tPYava.io.N-tp-t6tream o-t6treamQ throws Ex%eptionS

/05riggers the exe%-tion o# the provi"er in or"er to -p"ate the provi"erMs internal stateJ sen"ing the o-tp-t to the spe%i#ie" N-tp-t6tream. 0/

voi" r-nP6tring argsJ Yava.io.N-tp-t6tream o-t6treamQ throws Ex%eptionS T

8isting 1&.1 shows the i portant operations allowed on a si ple5ataProvider. 5*15ataProvider. 3i ilar to the above 3i ple5ataProvider, this ob,ect, shown in 8isting 1&.$, is also a s"nchronous provider that can generate 918 output in a w%c.do .5ocu ent 918 for at.

,isting 1!.2. The D9(Data7rovider interface.

p-3li% inter#a%e 1N;1ata4rovi"er exten"s 6imple1ata4rovi"erR p-3li% org.w3%."om.1o%-ment o-tp-t1o%-mentPQ throws Ex%eptionS T

This is an e.tension to the 3i ple5ataProvider, and provides an additional output the internal state of the provider as a 5*1 5ocu ent.

ethod to

-s"nc5ataProvider. 3hown in 8isting 1&.%, this is an as"nchronous provider that can support the above two data for ats 6i.e., 918 data in *utput3trea ob,ect, and 918 docu ent in w%c.do .docu ent for at7.

,isting 1!.3. The 'syncData7rovider. )$ontinued*

p-3li% inter#a%e 2s(n%1ata4rovi"er exten"s 6imple1ata4rovi"erR /0 5riggers the as(n%hrono-s exe%-tion o# the provi"erJ sen"ing the o-tp-t to the spe%i#ie" %all3a%& o3Ye%t. /t will exe%-te the %all3a%& name on the %all3a%& o3Ye%t. *ontext is "e#ine" 3( the %alling threa". 0/

voi" r-nP6tring argsJ 6tring %all3a%&)ameJ 6ervi%e1ata4rovi"er1o%-ment*all3a%& %all3a%&J N3Ye%t %ontextQ throws Ex%eptionS

/0 6ignals the provi"er to sh-t "ownJ %ease "ata %all3a%&sJ an" #ree an( asso%iate" reso-r%es 0/

voi" terminatePQ throws Ex%eptionS

/0 ,etrieve the %-rrent state 0/ int get6tatePQS T

This provider enables an as"nchronous call to a specified ob,ect. The following section describes so e of the internal details on this provider i ple entation.

Internal Details on $rovider %&ecution

There is a provider anager 63ervice5ataProvider1anager7 that is responsible for scheduling and anaging the provider e.ecution. This provider anager is a GT% operation provider with two e.posed ethods, )enu Provider) and )e.ecuteProvider.) These operations are e.posed in the /358 portT"pe definition for the provider anager. The provider anager, in turn, delegates the e.ecution to the provider of choice. These available providers are listed in a configuration file. ?or e.a ple, to register the provider called 2ost3criptProvider, add the following entr" in the configuration file(
<provi"er %lass="org.glo3-s.ogsa.impl.3ase.provi"ers.servi%e"ata.impl .!ost6%ript4rovi"er"/>

The list below describes a si ple 3ervice5ataProvider1anager i ple entation(

p-3li% %lass 6ervi%e1ata4rovi"er;anager implements 6ervi%e1ata4rovi"erExe%-tion4ort5(peJ 6ervi%e4rovi"erExe%-tion*all3a%&J 6ervi%e1ata4rovi"er1o%-ment*all3a%&J Nperation4rovi"erR .................................... p-3li% 6ervi%e1ata4rovi"erEn-m5(peVW en-m4rovi"erP3oolean res%an*on#igQR T p-3li% voi" exe%-te4rovi"erP6ervi%e1ata4rovi"erExe%-tion5(pe R T ................................................... T new6ervi%e1ataJ N3Ye%t %all3a%&Q

Aor all" speaking, the provider anager will convert the provider output to an 918 essage in a 3ervice5ataBle ent, and then add that to the service0s

-s we have ,ust discussed, a provider anager can aintain two uni!ue t"pes of operations, )enu Providers) and )e.ecuteProvider.) The )e.ecuteProvider) operation e.pects to receive a para eter of co ple. t"pe, defined in /358, with the anticipated infor ation, such as provider na e, provider i ple entation class, provider argu ent, and service data na e. This is relevant infor ation for the provider for three reasons, which are instructions regarding service data t"pe, refresh fre!uenc", and whether to e.ecute in s"nchronous or as"nchronous fashion. /e will later see how this powerful feature is utilized in the inde. service i ple entation.

%ervice Data 'ggregation $om onents

This discussion will e.plore another ver" interesting aspect of service data anage ent, where we will begin to better understand the aggregation co ponent. 3ervice data co ing fro various providers can be aggregated in different wa"s, and then inde.ed to provide for i proved efficiencies related to !uer" processing. This aggregator co ponent is si ilar to server-side notification sink.I1J #n addition to listening for notification of a service data change, this operation provides a echanis to cop" the inco ing notification data as local service data ele ents. This co ponent is i ple ented as an operation provider with the e.posed operations )add3ubscription,) )re ove3ubscription,) and )deliverAotification.) 8isting 1&.& shows an e.a ple of this i ple entation, with the e.tended interfaces.

,isting 1!.!. The serviceData aggregation o eration.

p-3li% %lass 6ervi%e1ata2ggregator/mpl implements 6ervi%e1ata2ggregator4ort5(peJ Nperation4rovi"erJ )oti#i%ation6in&*all3a%&R ................................. p-3li% 6tring a""6-3s%riptionP2ggregator6-3s%ription5(pe t(peQR T p-3li% voi" remove6-3s%riptionP6tring s-3s%ription/1QR T p-3li% voi" "eliver)oti#i%ationPExtensi3ilit(5(pe messageQR T

&egistry $om onents

+egistr" co ponents are sets of available grid services that are aintained in a registr". This provides a soft state registration echanis to periodicall" update service availabilit".

This registr" is i ple ented using the *G3# 3erviceGroup

echanis s.

' %am le 7rovider $reation

2ere are the steps for constructing a sa ple provider that can read s"ste and send these as an 918 docu ent to the provider anager. configurations,

1. /rite a sa ple e.ecutable that can run and read s"ste properties fro the current runti e and du p the results to the output strea as a 5*1 docu ent 6here we are using 3"ste .out7

,isting 1!.0. ' sam le e2ecutable reading the system information and emitting a D9( document.
p-3li% %lass 6(stem/n#ormation*olle%torR p-3li% stati% voi" mainP6tring argsVWQ R tr( R 6(stem/n#ormation*olle%tor s(s/n#o*olle%tor = new 6(stem/n#ormation*olle%torPQS // pass the "e#a-lt arg-ments an" 6(stem.o-t as parameters s(s/n#o*olle%tor.r-nPargstrJ6(stem.o-tQS T %at%hPEx%eption eQ R e.print6ta%&5ra%ePQS T T p-3li% voi" r-nP6tring argsJ Yava.io.N-tp-t6tream o-t6treamQ throws Ex%eptionR 1o%-ment "o% = get6(stem/n#oPQS // Erite the 1N; "o%-ment to the provi"e" o-tp-t stream o-t6tream.writeP"o%.to6tringPQQS T

prote%te" 1o%-ment get6(stem/n#oPQ throws Ex%eptionR ,-ntime r-ntime = ,-ntime.get,-ntimePQS // sample s(stem in#ormation

long total;em = r-ntime.total;emor(PQS long #ree;em = r-ntime.#ree;emor(PQS long -se";em = total;em #ree;emS

1o%-ment "om = "o% = org.apa%he.axis.-tils.F;L.tils.new1o%-mentPQS // initialiGe the 1N; "o%-ment with the a3ove s(stem in#ormation

ret-rn "omS T T

$. /rite a sa ple provider, following the progra ing odel that is discussed earlier, that can start the above e.ecutable we have created in step 1 and read the output fro the output strea .

,isting 1!.1. ' sam le D9(Data7rovider emitting org.#3c.dom.Document.

p-3li% %lass 6impleExe%-tion4rovi"er implements 1N;1ata4rovi"erR prote%te" 1o%-ment res-lt1o% = n-llS prote%te" 4ro%ess pro%ess = n-llS prote%te" 6tring error6tring = ""S

/00 *reates a new instan%e o# 6impleExe%-tion4rovi"er 0/ p-3li% 6impleExe%-tion4rovi"er PQ R T

/00 0 5riggers the exe%-tion o# the provi"er in or"er to -p"ate the provi"erMs 0 internal stateJ sen"ing the o-tp-t to the spe%i#ie" N-tp-t6tream 0/ p-3li% org.w3%."om.1o%-ment r-nP6tring argsQ throws Ex%eptionR 1o%-ment "o% = n-llS /0000

Exe%-te the in#ormation provi"er appli%ation with the ne%essar( arg-ments as we "e#ine" earlier 00/ this.exe%PargsQS

// rea" the o-tp-t stream o# the a3ove %reate" pro%ess tr(R i# Pthis.pro%ess <= n-llQ R // ass-ming the res-lts are written in F;L #ormat as spe%i#ie" in the earlier listing "o% = org.apa%he.axis.-tils.F;L.tils.new1o%-mentPthis.pro%ess.get/np-t6treamPQQS T T%at%h PEx%eption eQR throw eS T#inall(R // %he%& #or the exit state int exit = 0S tr( R exit = this.pro%ess.exitCal-ePQS T%at%h P/llegal5hrea"6tateEx%eption itseQ R // i# the pro%ess is r-nning wait #or that pro%ess to en". exit = this.pro%ess.waitOorPQS T T ret-rn "o%S T

// exe%-te the a3ove "e#ine" sample s(stem in#ormation appli%ation private voi" exe%P6tring argsQ throws Ex%eptionR // r-n the sample

,-ntime r-ntime = ,-ntime.get,-ntimePQS tr( R this.pro%ess = r-ntime.exe%PargsQS T %at%h PEx%eption eQ R PQS this.error6tring = "4rovi"er Exe%-tion error: " \ e.get;essage throw new Ex%eptionPthis.error6tringQS T T T

8isting 1&.5 and 1&.: de onstrate how to construct a sa ple provider and how to the data. Con#lusion

anage

Thus far, we have been discussing the co ponent odel introduced b" GT% for infor ation services. #n addition, we provided treat ent to the progra ing odel, and the interfaces associated with the core co ponents. GT% provides a set of standard co ponents to support so e of the built-in infor ation services that co es with the toolkit. Hou can alwa"s create new co ponents and add the to the high-level services through si ple configuration options. 2aving discussed the co ponent odel in detail, now it is ti e to e.plore so e of the GT% high-level services that are integrated with the GT% Toolkit. These infor ation services are providing a wide variet" of value-added features, and have re ained in the Globus toolkit fro its inception. This discussion covers the details of the infor ation services, including their value, usage, and i ple entation aspects. B.ploring the designs of these services help us to better understand the co ponent odel we have previousl" discussed. 3o e of the high-level services we will be reviewing include inde. services, resource infor ation provider 6+#P7, and container'virtual organization registr". O 5a" 5a" @p P

Inde+ 0ervi#es
*ne of the ost i portant high-level services delivered with the GT% infor ation services is the inde. services capabilit". This service is responsible for anaging static and d"na ic state data for grid services. ?igure 1&.% shows the inde. service high-level overview. -s shown is the illustration, the i portant co ponents in the inde. service core are(

3ervice data providers 5ata aggregators Grid service registries

Figure 1!.3. 'n overvie# of the "T3 +nde2 %ervice.

The GT%-provided inde. service has the capabilit" of constructing an interface for connecting e.ternal service data provider progra s to grid service instances. These providers enable a standard echanis for d"na ic service data generation fro e.ternal progra s. The GT% core provides a set of sa ple providers via the 3i ple3"ste #nfor ation and 2ost3criptProvider ob,ects. These providers are(

3i ple3"ste #nfor ation. These are native s"ste probes. This enu erates the following data( CP@ count, e or" statistics, *3 t"pe, and logical disk volu es. 2ost3criptProvider. These are 8inu.-specific shell scripts that s"ste -specific host data. onitor

*ne can alwa"s e.tend these providers or add on new custo providers, depending on the re!uire ents. #t is i portant to note that these providers are configured using the )inde.-service-config.. l) file.

These providers are si ple Cava applications that are rendering their results of e.ecution to the Cava output strea . #n the above two cases, the output strea is apped to Cava 3"ste .out. #n our previous discussions, we reviewed a sa ple i ple entation of a provider. *ne can alwa"s add their own provider and register the in a configuration file. - generic fra ework for aggregating data fro other services involves service data originating fro various providers 6and other services7 that can be aggregated and inde.ed to provide efficient !uer" processing. This inde. service utilizes the standard *G3# notification echanis s for subscription, notification, and updating of the service data. - +egistr" of grid services is a set of available grid services that is aintained in the registr". The registr" allows a soft state registration echanis for services to periodicall" update the overall services availabilit". - d"na ic data generating and inde.ing node is another valuable feature of the inde. service. The inde. service co bines 3ervice5ataProviderB.ecution co ponents with 3ervice5ata-ggregator and 3erviceGroup co ponents to create a d"na ic data generating and inde.ing node. This capabilit" can be utilized to create hierarchical inde. services. Inde+ 0ervi#e In!ormation 3odel The base infor ation data odel used b" the inde. service is 918. The service data is an 918 construct and both client and service know how to deal with this data odel. The inde. service infor ation odel provides the e.posure of the service data to the clients and aggregation of service data fro heterogeneous grid services. -s we know, ever" grid service has service data associated with it and the purpose of inde. services is to provide an interface to access, aggregate, generate, and !uer" this data. The *G3#-defined Grid3ervice interface e.posed b" all grid services provide a uni!ue wa" to access and update the service data. These operations are )find3ervice5ata) and )set3ervice5ata.) The constructs that are of i portance for inde. service are(

?actor", the creator of a grid service. G32, the uni!ue instance identifier. These G32s should be converted to G3+ before use. G3+, the reference to a grid service with infor ation that includes portT"pes e.posed b" a service, and how the client can co unicate with a service.

- service data !uer" echanis enables a service to be !ueried for the service data infor ation. /e have alread" e.plained in earlier chapters that this is one of the strong areas in the grid service specification and GT%. These !ueries can be of different t"pes based on the service and the service container capabilities. The t"pes of !ueries supported b" GT% include !uer" b" service data na e and !uer" b" 9Path.

+egistries are used as a co on repositor" for grid services. These registries allow soft state registration of grid services. The ost i portant aspect of inde. service is the abilit" to get notified on service data changes an"where in the grid s"ste . The *G3#-defined notification echanis provides this powerful feature. This provides a d"na ic resource state and the availabilit" of the updates. 1un#tional "spe#ts o! Inde+ 0ervi#e - pri ar" function of inde. service is to provide an interface to a !uer" on an aggregated view of service data collected fro other services. The find3ervice5ata operation of the Grid3ervice interface is utilized to e.ploit this !uer". The inde. service engine beco es registered as notification sink to other grid services. These notification-enabled grid services establish the subscriptions for notifications on topics of interest that are related to service data. - notification is sent to the sink on state changes. This is illustrated in ?igure 1&.%. These as"nchronousl" sent notification essages 6i.e., 918 essages7 are used to onitor the status of the resource, and the current service state infor ation. This notification process can be considered as a push echanis . The other facilit" provided b" GT% is the provider concept, where the service data gets pulled fro the resource utilizing the service data providers. Globus GT% has a plug-and-pla" provider echanis that enables inde. services to d"na icall" pull the service data fro other services. /e can find so e integrated clients with GT% inde. services, which are service data browsers and a co and-line tool called )ogsi-find-service-data.) These tools are used to get the service data fro a service and displa" the data for the user. The input for the !uer" can be si ple, based on a service data na e !uer", or a" be a co ple. 9Path e.pression. Inde+ 0ervi#e Con!iguration 3odel There can be an" nu ber of inde. services in a service container. The configuration of each of the is available in the server-congif.wsdd file.

,isting 1!.4. The %erviceData aggregation.

<servi%e name="3ase/in"ex//n"ex6ervi%e" provi"er="!an"ler" st(le="wrappe""> <parameter name="name" val-e="/n"ex 6ervi%e"/> <parameter name="s%hema4ath" val-e="s%hema/3ase/in"ex/in"exIservi%e.ws"l"/> <parameter name="%lass)ame" val-e="org.glo3-s.ogsa.3ase.in"ex./n"ex6ervi%e"/> <parameter name="3ase*lass)ame"

val-e="org.glo3-s.ogsa.impl.3ase.in"ex./n"ex6ervi%e/mpl"/> ...................................... <parameter name="servi%e*on#ig" val-e="in"ex servi%e %on#ig.xml"/> </servi%e>

The #nde. service deplo" ent shown in 8isting 1&.; is si ilar to other grid services with one notable e.ception( there is a configuration para eter indicating the inde. service configuration file. This inde.-service-config.. l file warrants so e further discussion. The functions of the inde. service configuration file are as follows(

3pecifies the service data provider to be enabled for each of the services referencing this configuration file. 3pecifies which of the enabled providers are to be e.ecuted at startup and'or when the configuration file is read. #t contains the necessar" para eters relevant to the provider0s e.ecution. 3pecifies notification and subscription of service data to other service instances, which allows for aggregation of service data fro ultiple services.

- sa ple configuration is described in 8isting 1&.<.

,isting 1!.;. The service data aggregation.

<servi%e*on#ig-ration ...> <installe"4rovi"ers> <provi"erEntr( %lass="org.glo3-s.ogsa.impl.3ase.provi"ers.servi%e"ata .impl.6imple6(stem/n#ormation4rovi"er"/>

<provi"erEntr( %lass="org.glo3-s.ogsa.impl.3ase.provi"ers.servi%e"ata .impl.!ost6%ript4rovi"er" han"ler="%om.test.m(*all$a%&N3Ye%t"/> </installe"4rovi"ers>

<exe%-te"4rovi"ers>

<provi"er exe%:6ervi%e1ata4rovi"erExe%-tion>

<provi"er exe%:servi%e1ata4rovi"er)ame>6(stem/n#ormation </provi"er exe%:servi%e1ata4rovi"er)ame>

<provi"er exe%:servi%e1ata4rovi"er/mpl> org.glo3-s.ogsa.impl.3ase.provi"ers.servi%e"ata.impl .6imple6(stem/n#ormation </provi"er exe%:servi%e1ata4rovi"er/mpl> <provi"er exe%:servi%e1ata4rovi"er2rgs></provi"er exe%:servi%e1ata4rovi"er2rgs> <provi"er exe%:servi%e1ata)ame xmlns:m"s="http://gl-e.3ase.ogsa.glo3-s.org/%e/1.1"> m"s:!ost </provi"er exe%:servi%e1ata)ame> <provi"er exe%:re#reshOre'-en%(> D0 </provi"er exe%:re#reshOre'-en%(> <provi"er exe%:as(n%> tr-e </provi"er exe%:as(n%> </provi"er exe%:6ervi%e1ata4rovi"erExe%-tion> </exe%-te"4rovi"ers>

<aggregate"6-3s%riptions> <aggregator:2ggregator6-3s%ription> <aggregator:servi%e1ata)ame xmlns:%e="http://gl-e.3ase.ogsa.glo3-s .org/%e/1.1"> %e:*l-ster </aggregator:servi%e1ata)ame>

<ogsi:so-r%e> http://12B.0.0.1:>0>0/ogsa/servi%es/3ase/gram/ ;asterOor&;anage"Uo3Oa%tor(6ervi%e </ogsi:so-r%e> <aggregator:li#etime> 1200 </aggregator:li#etime> </aggregator:2ggregator6-3s%ription> </aggregate"6-3s%riptions> </servi%e*on#ig-ration>

8isting 1&.< illustrates so e of the i portant configuration infor ation for an inde. service provider. There are three sections in this configuration file. 1. #nstalled providers. These are the available providers in the container. These a" be GT%-provided or custo Cava providers. These providers ust i ple ent either of the 5*15ataProvider, 3i ple5ataProvider, or -s"nc5ataProvider interface. #n 8isting 1&.<, we have two providers installed, 3i ple3"ste #nfor ationProvider and 2ost3criptProvider. There is onl" one re!uired para eter for each provider entr", a )class) attribute that infor s the i ple entation class na e of the provider. There can be an optional )handler) attribute indicating a user-provided custo callback ob,ect for post-processing of the data. This handler ust i ple ent the 3ervice5ataProvider5ocu entCallback interface. $. B.ecuted providers. These providers are e.ecuted, producing one or ore service data results. This configuration allows one to pass para eters to this e.ecution behavior. The service data na e para eter indicates the na e of the new service data to create. #f this para eter is not present, the service data na e will be created fro the tag na e of the root ele ent of the 918 docu ent produced b" the e.ecution. The )refresh) propert" indicates how often the provider should e.ecute. %. -ggregated subscriptions. These subscriptions specif" the grid services to be inde.ed b" the inde. service. 2ere, we are specif"ing the G32 of the grid service fro which we are receiving notifications, and the service data na e for which we are subscribing. These subscriptions are controlled b" the lifeti e attributes. 3onitoring and )is#over( The 153 in GT% is erged with the core GT% 6i.e., service data and notification odel7, and the higher-level inde. service 6i.e., the collective la"ers functionalities7. *ne ust be aware of this funda ental change. This wa", there will not be a specific

153 co ponent in GT%. 2owever, at the sa e ti e GT% provides all the facilities available with 153 6version $7 through the previousl" described core and inde. services. 0ummar( The above inde. service architecture provides a data aggregation 6push and pull echanis s7 fro e.ternal services and data sources, service collection anage ent, while providing an infor ation odel based on service data aggregation 918 sche a. These are valuable sources of infor ation for applications built upon Globus GT% high-level services. The sources can e.ploit these inde.ing behaviors of the data collected fro various services'resources for purposes of creating eaningful odels, such as resource utilization, availabilit"

2esour#e In!ormation Provider 0ervi#e

The resource infor ation provider service 6+#P37 is a part of the G+-1. This service utilizes service data providers to e.ecute s"ste -level infor ation-gathering scripts and tools. /hen used in con,unction with G+-1, it0s purpose is to onitor forked processes, scheduled !ueues, and host s"ste statistics. ?igure 1&.& shows the a,or co ponents utilized b" the +#P3 operation. The interested parties can register for subscriptions, based on service data of interest. The illustration also shows how the G+-1 aster hosting environ ent is using data aggregator co ponents to collect aggregated service data.

Figure 1!.!. The resource information rovider service o eration.

Internal .perations o! 2IP0

,isting 1!.A. The &+7% im lementation rototy e.

p-3li% %lass ,/46/mpl exten"s 4ersistent8ri"6ervi%e/mpl implements 6ervi%e1ata4rovi"er1o%-ment*all3a%& R // this is the %all3a%& metho" name p-3li% 6tring get1e#a-lt*all3a%&;etho")amePQ R ret-rn "Yo31ata!an"ler"S T p-3li% *lassVW get*all3a%&4aram6igP6tring metho")ameQ R

*lassVW param6ig = R *lass.#or)ameP"org.w3%."om.1o%-ment"QJ *lass.#or)ameP"Yava.lang.N3Ye%t"QJ *lass.#or)ameP"Yava.lang./nteger"QTS ret-rn param6igS T p-3li% voi" post4ersistent*reateP8ri"*ontext %ontextQ throws 8ri"6ervi%eEx%eptionR // "o initialiGation T

p-3li% 6ervi%e1ata4rovi"erEn-m5(peVW en-m4rovi"ersP3oolean res%an*on#igQ throws ,emoteEx%eption R

// these %alls are "elegate" to the 6ervi%e1ata4rovi"er;anagerJ whi%h we have seen earlier T p-3li% voi" exe%-te4rovi"erP6ervi%e1ata4rovi"erExe%-tion5(pe new6ervi%e1ataQ throws ,emoteEx%eption R

// these %alls are "elegate" to the 6ervi%e1ata4rovi"er;anager T p-3li% voi" s-3s%ri3ePExtensi3ilit(5(pe s-3s%riptionExpressionJ Lo%ator5(pe sin&J

Exten"e"1ate5ime5(pe expiration5imeJ Lo%ator5(pe!ol"er s-3s%ription/nstan%eLo%atorJ 5ermination5ime5(pe!ol"er %-rrent5ermination5imeQ R /02n( s-3s%ri3ers %an s-3s%ri3e to the "(nami% servi%e "ata generate" an( 3( this servi%e thro-gh this metho". /nitiall(J there ma( not 3e

servi%e "ata availa3le an" hen%e "-mm( servi%e "ata will 3e %reate" will #or the servi%e "ata name spe%i#ie" 3( s-3s%ri3e. 5his "-mm( 61 3e "elete" i# no val-e is %oming #rom the provi"er #or a spe%i#i% perio" o# time 0/ T p-3li% 3oolean Yo31ata!an"lerPorg.w3%."om.1o%-ment "o%J N3Ye%t %ontextJ /nteger provi"er6tateR /05his is the %all3a%& #-n%tion that is "oing the real Yo3 o# splitting the F;L "o%-ment into servi%e "ata elements an" -p"ating the servi%e "ata set o# this servi%e 0/ T

8isting 1&.= describes the ain operations provided b" the +#P3 co ponent. 3o e of the points of interest related to the +#P3 topic are as follows(

The providers are polled at specified intervals. There are two wa"s we can control the poll ti e0s values( 1. These values can be configured through the e.ternal configuration file, and then this value is applicable to all instances of the provider. $. -nother possibilit" is to configure this poll ti e value b" the client on the call to )e.ecuteProvider.) This new ti er value will be applicable to the specific provider instance.

+#P3 perfor special processing utilizing its custo ),ob5ata2andler) function b" separating out the specific child )Cob) ele ents fro the logical

result docu ent. This creates individual 35Bs b" assigning the appropriate TT8 etadata to the new entries, and updating the TT8 data on the e.isting 35Bs.

+#P3 e.ecute a separate thread called a sweeper, which periodicall" traverses the service0s internal 35B list and invalidates an" entries that have not received updates to the specified ti esta p etadata.

0ummar( #n general, +#P3 provides service data aggregation echanis s and anage ent of data utilizing the service provider co ponents included with the GT%. -n" interested service can register for notification on the service data of choice. This is a fle.ible architecture when integrated with other high-level services such as resource anagers.

2esour#e 3anagement 0ervi#es

Grid resource anage ent involves the coordination of a nu ber of co ponents, including resource registries, factories, discover", onitoring, allocation, and data access. The Globus toolkit includes a set of co ponents to help users have a standard set of interfaces for the coordination of the above activities. The ain functionalities of these co ponents 6called G+-17 are ,ob sub ission and resource anage ent. ?igure 1&.5 shows the architectural co ponents of the G+-1. Bven though this architecture appears co ple., in practice it is an aggregation and collective functionalit" of a set of well-defined co ponents. -nother advantage of this architecture is that the client is free fro these architecture co ple.ities.

Figure 1!.0. The architecture of "&'(.

"he Ma+or Components o( the G#0M 0rchitecture

1aster 2ost Bnviron ent and @ser 2ost Bnviron ent This concept enables the separation of functionalities and provides an i proved abstraction on the functions supported b" each environ ent. The aster host is responsible for providing infor ation on aggregated resource state'status, and to anage its user hosts start and launch services. This is the direct point of contact for the client. The user host environ ent 6@2B7 provides specific abstraction capabilities and securities to e.ecute a ,ob. -ll the ,obs are e.ecuted in the @2B. 1aster 1anaged Cob ?actor" 3ervice This factor" is alwa"s available and responsible for receiving the client re!uest on aggregated resource !ueries and subscriptions. This factor" anages the aggregated service data through aggregation providers for resource status, and notifications fro resources. Kirtual 2ost +edirect 2andler This is the core co ponent responsible for redirecting all of the calls to the @2B. These calls include creation of the ,ob and invoking ,ob operations on the created ,ob service. 3tarter @2B'8aunch @2B *n a client re!uest to e.ecute a ,ob, the virtual hosting engine directs the calls to the starter. This Cava class is responsible for securit" apping, user validation, and for ensuring that the ,ob is e.ecuting so that the virtual host can redirect the calls to the e.ecuting ,ob service. #f the user host is not up and running, then it uses the help of the 8aunch @2B Cava class to start that host under the user0s credentials. 1anaged Cob ?actor" 3ervice'1anaged Cob 3ervice The 1C? service e.poses a Create3ervice ethod, which accepts an +38specified ,ob. The 1C? then creates a anaged ,ob instance for the user. #t acts as a local scheduler, onitoring its status and sending notifications. #n addition to this, the 1C3 will start two file strea ing factor" servicesF one for the ,ob0s stdout, and the other for the ,ob0s stderr. ?ile 3trea ?actor" 3ervice'?ile 3trea 3ervice

These are helpful services to anage the data needed for the ,ob e.ecution. The factor" service creates two file strea services( stdout and stderr. Bach of these services has two service data results( the @+8 for the strea destination, and a flag to indicate the activit". Grid +esource #dentit" 1apper 6G+#17

Two "spe#ts to the G2"3 "r#hite#ture 1. Cob sub ission. - user starts the ,ob scheduling with the creation of a anaged ,ob service. This process involves ultiple steps. o The client knows about the aster host environ ent and the aster anaged factor" service. #t sends a re!uest to create a ,ob to the aster factor" service in the 12B.
o

The Kirtual 2osting +edirect handler anages this re!uest with the help of the starter'launch Cava classesF it then creates and'or connects to the user hosting s"ste . *ne ust be aware that these processes are created under user credentials. *nce the @23 is available, the +edirect handler transfers the Create Cob re!uest to the anaged ,ob factor" service in @23. The 1anaged Cob ?actor" creates a anaged ,ob service instance for the user with the necessar" ,ob description para eter encoded in the +esource 3pecification 8anguage. -lso, it creates the necessar" file strea ing classes to handle the data for the ,ob. ?ro this stage forward, the client is able to talk to the anaged ,ob created in the user hosting environ ent. -ll the calls are then redirected to the correct ,ob instance.

$. +esource anage ent. - client knows about the aster host environ ent and the aster anaged factor" service. This process involves ultiple steps.
o

The aster factor" provides an aggregated view of the state of the ,ob and other resource infor ation. The aster factor" gathers this infor ation using the +#P service. The client can now find and register for notification on the aggregated service state fro the aster factor". The client can now locate the state infor ation fro instance. the ,ob service

2esour#e 0pe#i!i#ation /anguage The power of G+-1 is associated with its capabilities to describe a ,ob. The +esource 3pecification 8anguage 6+387 is an 918 standard for describing a ,ob. The +38 includes 918 standard ele ents for specif"ing e.ecutables, director", argu ents, and data files. The +38 is created b" the client, and passed to the anaged ,ob service 61C37 where it is then converted to the local scheduler-specific language. The current standard language is +38$. 8isting 1&.1> describes this +38 e.a ple.

,isting 1!.1C. 'n &%, e2am le.

<rsl:rsl << insert 8,2; ,6L )amespa%e <gram:Yo3> <gram:exe%-ta3le> <rsl:pathElement path="/3in/ls"/> </gram:exe%-ta3le> <gram:"ire%tor(> <rsl:pathElement path="/-ser/YYp"/> </gram:"ire%tor(> <gram:arg-ments> <gram:arg-ment> l</gram:arg-ment> <gram:arg-ment> a</gram:arg-ment> </gram:arg-ments> </gram:Yo3> </rsl:rsl> >

0ummar( G+-1 provides a set of standard interfaces and co ponents to collectivel" anage a ,ob task, and to provide resource infor ation including ,ob status and resource configuration. This infor ation can then be utilized for resource allocation of a specific Cob. /e can build high-level eta-,ob schedulers, and resource brokers' anagers on the top of this la"er, while using the resource infor ation provided b" this la"er. The other aspect of using this standardized iddle la"er is that we can also build lowerla"er local ,obs and resource anage ent functions, without affecting the high-level schedulers and onitors. This la"er provides an abstraction fro high-level anageabilit" to lower-la"er anageabilit" functionalities. *ne notable aspect of the G+-1 is the absence of accounting and billing features

)ata 3anagement 0ervi#es

The data anage ent services provide standard Grid Co puting environ ent. Grid 1ile Trans!er Proto#ol 4Grid1TP5 eans for helping to anage the

Grid?TP is a standard e.tension to the nor al ?TP 6?ile Transfer Protocol7 that works with the Grid Co puting data re!uire ents. This is a high-perfor ance, secure, reliable, data transfer protocol that is opti ized for high bandwidth across wide area networks. This is a standard that provides G3# securit", parallel transfer capabilities, and channel reusabilit". 2elia*le 1ile Trans!er 421T5 The reliable file transfer service 6+?T7 is an *G3--based service that provides interfaces for controlling and onitoring third-part" file transfers using the Grid?TP servers. The client controlling the transfer is hosted inside of a grid service so that it can then be anaged using the soft state odel, and !ueried using the service data interfaces available to all grid services. 2epli#a /o#ation 0ervi#e 42/05 The replica location service 6+837 aintains and provides access to apping infor ation fro logical na es regarding data ite s to target na es. These target na es a" represent ph"sical locations of data ite s, or an entr" in the +83 a" ap to another level of logical na ing for the data ite . 0ummar( /e su arize the data anage ent services discussion b" si pl" addressing their usabilit", which enables(

Co putational grids to anage a ,ob b" allowing the data re!uired for the processing of the ,ob to be transferred in a secure, reliable anner. 5ata grids to utilize these anage ent features providing scalable and secure access and integration facilities for data storage.

Con#lusion
These introductions on the high-level services help us to better understand the basic functionalities provided b" the in the conte.t of the Globus GT% fra ework. The ain utilit" value of GT% lies with these high-level servicesF it provides a fra ework for the creation of a co putational grid. The basic re!uire ents for co putational grids address scalable ,ob anage ent and resource onitoring aspects. GT% provides these capabilities through G+-1, inde. services, service data constructs, and a co on language definition for ,ob descriptions. /e can now better understand that there are a nu ber of applications and services re!uired in order to start using G+-1, and the resource anage ent features of GT%. 1a,or acco plish ents in this area include Condor-G and Ai rod-G. Practitioners in the grid co unit" are e.pecting these eta-schedulers and resource anagers to continue evolving toward utilization of the GT%-provided inde. services, G+-1, and the e.posed 918-based infor ation odel. - co on agree ent on +38, or a

si ilar co on language for ,ob description, will further strengthen these high-level applications.

Chapter 17. OG'I./%" Middleware 'olutions

/e have discussed throughout this book an" of the architectural benefits provided b" *G3- to /eb services and grid services co unities. 8ikewise, we have discussed throughout this book the benefits the *G3# specifications provide as a co on set of 918 essages and definitions using /358 for interoperable grid service i ple entations. #n the previous chapters, we also learned about the a,or infrastructure develop ents for hosting an *G3#-based grid services i ple entation. Those develop ents were centered on Cava and C$3B'C$BB. #n this chapter, we will see other reference i ple entations of *G3# in 1icrosoft .ABT, another pro inent hosting platfor . The ain value additions of these i ple entations are to validate the interoperabilit" between services hosted b" different environ ents, and to influence the *G3# co unities on interoperable essage definitions and standardizations. This will provide a eans for a wide range of acceptabilit" advance ents for the *G3# standard. There are a nu ber of reference i ple entations of *G3# in .ABT, which are available toda". The ost pro inent reference i ple entations are( *G3#.ABT b" the @niversit" of KirginiaI1J and 13.ABTGrid b" Aational e3cience Center 6Ae3C7.I$J 4oth of the above i ple entations are available for distribution. /e will e.plore the architecture, progra ing odel, and a sa ple i ple entation on these platfor s. #n this final chapter of the book, we will concentrate on the *G3#.ABT toolkit fra ework i ple entation

.G0I- 'T 1ramework Implementation

The *G3#, as we have alread" noted, provides a rich and robust infrastructure for the i ple entation of Grid Co puting environ ents. This section addresses the .ABT solutions, in con,unction with the *G3#. "r#hite#ture .verview The concept of the .ABT fra ework is centered on the service instance re!uire ents for the anage ent between the client invocations, and using the #nternet #nfor ation 3erver 6##37 to dispatch the client re!uest to the actual instance. -lthough .ABT provides a rich set of /eb services capabilities, the evidence of these two basic re!uire ents for a grid service being apparent is so ewhat less than re arkable. To satisf" these re!uire ents, the *G3#.ABT tea ust construct the architecture to aintain the service instances between the client invocations, and the abilit" to then dispatch the re!uests to the correct service instances. The architecture suggests the introduction of a concept of grid service wrappers and a dispatcher. These are .ABT -pp5o ains, self-contained entities that can e.ecute ob,ects in its own e or" space. This concept provides a nu ber of advantages

including scope the code e.ecution, fault isolation, and securit" isolation. The grid service wrappers 6G3/7 are *G3# grid service instances that are created in its own -pp5o ain. The dispatcher is the pivot -pp5o ain that contains references to the grid service wrapper ob,ects in another -pp5o ain and e.ecutes ethods upon it. This concept of creating grid services using wrappers with -pp5o ain isolation provides securit", e or", and code isolation. -n" proble 6fault or e.ceptions7 with the specific service a" not affect other services in the sa e container. Het another i portant functionalit" of these wrappers is that the" are self-contained with the necessar" serializer, deserializers, and portT"pe i ple entations re!uired for the service operation dispatch. -nother i portant architectural decision is the e.tension of the re!uest dispatching functionalities of the ##3. - client re!uest is filtered b" the *G3#.ABT #3-P# 6#nternet 3erver -P#7 filter. This filter intercepts the client re!uests, then rewrites the re!uest and dispatches this re!uest to the 2ttp2andler provided b" the *G3#.ABT fra ework. This 2ttp handler routes the essages to the *G3#.ABT container process. This process, in turn, handles this raw essage in one of its threads. The 5ispatcher -pp5o ain takes over the raw re!uest essage in the thread and this dispatcher routes the essages to the Grid3ervice/rapper class for further processing. This dispatching is done based on the instance @+8. The above re!uest processing is illustrated in ?igure 15.1.

Figure 10.1. The 9"%+.5-T architecture and re@uest flo#.

8et us now spend so e ti e anal"zing the internal functionalities of the Grid3ervice/rapper. This wrapper is running in its own -pp5o ain. #t aintains a list of portT"pes i ple ented b" the service and contains the necessar" infor ation to serialize and deserialize the 3*-P essages co ing fro the client. The fra ework also provides capabilities to plug in essage handlers for 3*-P essage header processing. The standard 3*-P-based headers 6for e.a ple, /33ecurit"7 are processed using the /eb service Bnhance ent 6/3B7 handlers.I%J *nce the essage is deserialized and the operation is identified fro the raw 3*-P essage, a runti e reflection is e.ecuted on the service to invoke the operation. The responses fro the ethod invocations are serialized and sent back to the client. The discussion topics below on the architectural co ponents helps us to better address an i proved progra ing odel.

)ispat#her The ain function of the 5ispatcher -pp5o ain is to route the re!uest fro the client to the appropriate service instance and return the results to the client without an" processing. #t keeps a list of @+#s to the service instance for proper instance dispatching. This architecture helps to isolate the securit" and other runti e proble s to an isolation level of service instance -pp5o ain. Grid 0ervi#e Wrapper This is a wrapper e.ecuting in its own -pp5o ain and providing functionalities, such as(

Pluggable, service-specific essage handlers to process essages prior to dispatching to the service instance 1echanis to specif" portT"pes si ilar to *perationProviders in GT% Pluggable i ple entations for s"ste -defined portT"pes 4uilt-in support of e.tended standard-based 3*-P headers using /3B

The wrapper is initialized with the necessar" asse blies needed for the service as specified b" the service class. This includes portT"pe i ple entations, serializers, deserializers, and essage handlers. *ne i portant thing to notice is that the co plete processing of the essage is acco plished on the thread provided b" the container. 3o if the service needs to create ore threads it ust create the .ABT-provided soft threads in the -pp5o ain using the .ABT-provided 3"ste .Threading.Thread class. 1a#tor( ?actories are service instances that can create other service instances and wrappers in different -pp5o ains. The" i ple ent *G3# ?actor" portT"pe with create3ervice operation. These service instance wrappers are re ote referable ob,ects of the t"pe 1arshal4"+ef*b,ect and stored in the 5ispatcher -pp5o ain. The 5ispatcher stores these ob,ects in a table with service instance handle 6G327 as the ke". 3essage Handlers *G3#.ABT provides two essage handlers, one for 3*-P essages and the other for .ABT )re oting) essage for ats. /e will see how we can configure these handles later in the configuration section. These essage handlers will deserialize the re!uest essage and identif" the operation to invoke and create the needed para eters fro 3*-P bod". *n the co pletion of the call, the client serializes the essage to b"te strea and returns the binar" strea back to client. The current runti e uses the 1icrosoft /3B pipeline echanis to process the standard defined 3*-P headers such as /3-3ecurit" and /3--ddressing. ?or application specific headers we ust provide custo handlers.

0e#urit( The essage-level securit" is handled using /3-3ecurit" and the /3B e.tensions for /3-3ecurit". *ne thing to notice is that this is handled in the service instance wrapper do ain. The concept of wrapping service instance in an -pp5o ain provides securit", e or" protection, and other .ABT protections including code access, asse bl" access, and so forth. Persisten#e The fra ework provides a soft state service destruction pattern as defined b" *3G# specification. This enables a service client to define a lifec"cle ti e for a service instance. There is a garbage collector thread running with the dispatcher -pp5o ain, which is responsible for this service destruction on ti eouts. Programming 3odel Aow let us discuss the progra ing odel constructs provided with this fra ework. *ne noticeable feature of this fra ework is its align ent with the .ABT progra ing odel for /eb services. The use of )attributes) in service class is one such interesting aspect of the progra ing odel. "ttri*ute6Based Programming *ne of the ost attractive and powerful features in .ABT is the attribute-based progra ing. This feature is used to annotate the classes, ethods, and code blocks with etadata. This language feature is e.tensivel" used in .ABT to support /eb services. *G3#.ABT uses this facilit" to define so e co onl" defined attributes for grid services to help the service developer for the inner details of the i ple entations. .G0IPortT(pe"ttri*ute This tells the G3/ that the service i ple ents a particular portT"pe. oti!i#ation0our#ePortT(pe This service i ple ents a Aotification3ourcePortT"pe functionalit" as defined b" the *G3# *G3#*peration*verride-ttribute. This enables a service author to override so e of the portT"pe ethods using *G3#PortT"pe-ttribute, *G3#3oap2eader-ttribute, and *G3#+e oting2eader-ttribute. These attributes provide additional header infor ation to these operations. This is a replace ent for the .ABT 3oap2eader-ttribute, which provides no t"pe infor ation, as shown below(
VN86/6oap!ea"erP"invo%ation/1"J "http://ogsa.glo3-s.org/"J t(peo#P/nvo%ation/1QQW

versus
V6oap!ea"erP"invo%ation/1"QW

8isting 15.1 illustrates the use of attributes in a service class.

,isting 10.1. ' sam le attribute-based rogramming for 9"%+.

VN86/4ort5(pePt(peo#P8ri"6ervi%e4ort5(peQQW VN86/4ort5(pePt(peo#P)oti#i%ation6o-r%e4ort5(peQQW p-3li% %lass 2%me6ervi%e : 8ri"6ervi%e6&eletonR T

8isting 15.1 specifies that -c e 3ervice is i ple enting the Grid3ervicePortT"pe and Aotification3ourcePortT"pe. Con!iguration 8et us now ove on to the configuration of a service. /e can best e.plain the configuration process through 8isting 15.$.

,isting 10.2. The grid service configuration.

<servi%e name="ph/a%me/2%me6ear%hOa%tor(6ervi%e"> <parameter name="s%hema4ath" val-e="s%hema/%ore/#a%tor( #a%tor(Iservi%e.ws"l"/>

<parameter name="%lass" val-e="ph.a%me.Oa%tor(.2%me6ear%hOa%tor(6ervi%eJ phIa%me."ll"/>

<parameter name="message!an"lers" val-e=".Ca.8ri".6oap;essage!an"lerLi3.6oap;essage!an"lerJ 6oap;essage!an"lerLi3."llS .Ca.8ri".6oap;essage!an"lerLi3.,emoting;essage!an"lerJ 6oap;essage!an"lerLi3."ll"/>

<parameter name="%reate6%hema4ath" val-e="s%hema/gri"3oo&/3ase/ a%meIsear%hIservi%e.ws"l"/> <parameter name="%reate*lass" val-e="ph.a%me.3asi%.impl.2%me6ear%h6ervi%eJ phIa%me."ll"/>

<parameter name="%reate;essage!an"lers" val-e=".Ca.8ri".6oap;essage!an"lerLi3.6oap;essage!an"lerJ 6oap;essage!an"lerLi3."llS .Ca.8ri".6oap;essage!an"lerLi3.,emoting;essage!an"lerJ 6oap;essage!an"lerLi3."ll"/> </servi%e>

@pon careful e.a ination of the above grid service configuration, we could infer that(

Bver" service factor" has a uni!ue na e and uses the *G3#-defined factor" Wservice.wsdl. The real i ple entation factor" class is defined using the )class) para eter, which accepts the class na e and the asse bl" na e. - list of handlers for the service factor" is specified in the ) essage2andlers) propert". The service ust provide its wsdl and class na e using create3che aPath and createClass para eters, respectivel". - list of handlers for the service instance is specified in the )create1essage2andlers) propert".

0ummar(
This reference i ple entation successfull" illustrates the *G3# i ple entation in .ABT platfor s. There are a nu ber of issues that still need to be addressed at this ti e, including securit", scalabilit", and interoperabilit" between GT% and *G3#.ABT. 1ost of these are platfor dependent and will beco e ature with .ABT. -dopting /3B for ost of the standard 3*-P header processing will alleviate the s"ste architecture fro a nu ber of these co ple.ities. /e are assu ing that adapting a docu ent'literal approach can solve ost of the interoperabilit" issues with regard to the essage e.change topic. This reference

i ple entation will indeed be a beneficial addition for Grid Co puting applications using .ABT as their core platfor .