grid and cloud computing: opportunities for integration ... · cloud computing, by contrast,...
TRANSCRIPT
J Grid Computing (2009) 7:375–393DOI 10.1007/s10723-009-9132-5
Grid and Cloud Computing: Opportunities for Integrationwith the Next Generation Network
Thomas Rings · Geoff Caryer · Julian Gallop ·Jens Grabowski · Tatiana Kovacikova ·Stephan Schulz · Ian Stokes-Rees
Received: 7 November 2008 / Accepted: 13 August 2009 / Published online: 28 August 2009© Springer Science + Business Media B.V. 2009
Abstract Carrier-grade networks of the future arecurrently being standardized and designed un-der the umbrella name of Next Generation Net-work (NGN). The goal of NGN is to providea more flexible network infrastructure that sup-ports not just data and voice traffic routing, butalso higher level services and interfaces for third-party enhancements. Within this paper, oppor-tunities to integrate grid and cloud computing
T. Rings (B) · G. Caryer · J. Gallop · J. Grabowski ·Institute of Computer Science,University of Göttingen, Goldschmidtstr. 7,37077 Göttingen, Germanye-mail: [email protected]
G. Caryere-mail: [email protected]
J. Gallope-mail: [email protected]
J. Grabowskie-mail: [email protected]
T. KovacikovaUniversity of Zilina, Zilina, Slovakiae-mail: [email protected]
S. Schulz · I. Stokes-ReesEuropean Telecommunications Standards Institute,Sofia Antipolis, France
S. Schulze-mail: [email protected]
I. Stokes-Reese-mail: [email protected]
strategies and standards into NGN are considered.The importance of standardized interfaces and in-teroperability testing demanded by carrier-gradenetworks are discussed. Finally, a proposal howthe testing methods developed at the EuropeanTelecommunications Standards Institute (ETSI)can be applied to improve the quality of standardsand implementations is presented.
Keywords Interoperability · Next generationnetwork · NGN · Grid · Cloud · Standards ·Testing · ETSI
1 Introduction
Carrier-grade networks form the global commu-nications infrastructure that support millions ofphone calls each day and, even more importantly,the massive global data transfers, predominantlyresulting from the Internet. These carrier-gradenetworks are operated by hundreds of companiesoften deployed on top of physical infrastructure(cabling and switches). These infrastructures areusually not owned by the network operator buthave to follow different regulations in each coun-try and likely traverse several billing domains atany given point-to-point connection.
This globally integrated system operates withextremely low down time and transparently tothe end users. This has been achieved through
376 T. Rings et al.
decades of development and standardization ofinterfaces, a process which has now become wellestablished in the telecommunications industry.The latest evolution of the global communicationsnetworks, the Next Generation Network (NGN),is designed to support converged fixed and wire-less networks carrying both voice and data traffic.Furthermore, these future networks incorporatea richer set of features to provide more servicesto customers, and hence increased revenue op-portunities for the network providers. Increasedflexibility around network-level services has alsoopened the door to third party services built ontop of the NGN infrastructure.
With increasing interest in grid computing overthe past several years and more recently, cloudcomputing, a major question that needs to beanswered is how these technologies, concepts, andcapabilities can be incorporated into NGN. Gridand cloud computing systems would benefit fromenhanced capabilities of NGN, the global reach ofexisting communications networks, and the stabil-ity of carrier-grade networks.
Interoperability has been one of the key con-tributors to widespread commercial success oftechnologies used in the telecommunications sec-tor, due to the interconnected nature of networks,and the plethora of network operators. Interoper-ability fosters diversity as well as competition ina market. Vendors can achieve interoperability oftheir products only if they agree and implementa common set of open standards. The value ofstandardization has also been recognized by thegrid community, and is predominantly champi-oned by the Open Grid Forum (OGF) [50] forgrid-specific standards. Standardization, however,does not necessarily lead to interoperability. Stan-dards have to be engineered for interoperability.Similarly, implementations of standards have tobe assessed for their interoperability with otherimplementations and have to demonstrate thatthey follow these standards. At the standardiza-tion level, this can be facilitated with the availabil-ity of open and validated test specifications.
In this article, the accomplishments of the workcompleted by the Technical Committee GRID(TC GRID) of the European TelecommunicationsStandards Institute (ETSI) are reported. This workincludes studies about the state of grid comput-
ing, existing standards, and any gaps or overlapsthat would need to be addressed for a cohesivecarrier-grade grid computing environment to beprovided by a network operator. The standardslandscape around grid computing, the tension be-tween grid standards and operational grids arediscussed. In addition, the ETSI approach towardsinteroperability testing, standards evaluation, andthe preparation of ETSI interoperability events,the so-called Plugtests™ [11] are presented. Theinteroperability events are used to compare var-ious implementations in a controlled setting andcan provide detailed feedback on the quality ofa standard based on the level of interoperabilitythat is achieved. In the longer term, ETSI plans toestablish standards that will support the conver-gence between NGN, grid, and cloud computingenvironments.
The article is structured as follows: the stan-dards landscape for grid, cloud and NGN domainsare presented in Section 2. Their convergence isdescribed in Section 3. In Section 4, the inter-operability between grid systems is assessed. InSection 5, ETSI’s approach to grid testing is intro-duced. Finally, we conclude with a summary andan outlook in Section 6.
2 Standards Landscape for Grid, Cloudand NGN Domains
The wide range of organizations involved with oneor more of grid, cloud, and NGN technology eachhave their own priorities. Where operational sys-tems have been designed or deployed, this rangeof priorities has resulted in competing architec-tures and interfaces. Although NGN does not yetexist as an integrated global telecommunicationsplatform, there is a coordinated effort to developthe suite of standards to cover a high level NGNarchitecture [14]. In contrast, grid computing of-fers a few high level conceptual models, typicallyusing the hour-glass middleware imagery. Thisenvisages a wide range of high level applicationsconnected to a wide range of heterogeneous lowlevel resources via a limited number of interme-diate standard interfaces. In addition, there area few concrete architectural models for grid in-frastructures [26, 47]. These concrete models have
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 377
a distinct disconnection: either they present anarchitecture which is not or only partially imple-mented in any operational grid, or an architecturewhich describes a particular grid infrastructurewith limited references to standards or interfaces.In the cloud domain, there is currently a preva-lence of independent services with minimalinterest in interoperability or consideration ofstandards. While this is in the process of changing,there is currently no sufficient activity in this areato report on.
While the original motivation for grid com-puting originated with large scientific collabora-tions, it is now established that the same newtechnology and perspective on distributed com-puting is applicable in many domains. The Net-worked European Software and Services Initiative-Grid (NESSI-Grid) review considered the im-pact of grid technology on business IT infrastruc-ture [45], while several projects have consideredthe application of grid computing to eHealth (seecase study in Section 4.1). The recent popular-ity of cloud computing also demonstrates the in-dustry benefits of shared, distributed computinginfrastructure.
2.1 Differentiating Cloud Computingand Grid Computing
It is important to distinguish grid computing fromcloud computing. Grid computing has a longerhistory and has primarily been adopted by publicsector compute or data intensive user groups. Thiscommunity has a pressing need for large scale fed-erated computing systems, and the developmentof standards has been in support of this.
Cloud computing, by contrast, originated in theprivate sector where virtualization technology andlarge data centers have been turned into the foun-dation for products and services to be resold. Thissection will help clarify the difference betweenthe two. Subsequent sections will focus primarilyon grid computing, as cloud computing still lacksany substantive standards or possibilities for in-teroperation, making any discussion around cloudcomputing and the telecommunications industrypurely speculative.
The grid concept has a complementary but in-dependent relationship to the concept of cloud
computing. The similarities are that both aim toprovide access to a large computing (CPU) orstorage (disk) resource. Beyond that, a cloud uti-lizes virtualization to provide a uniform interfaceto a dynamically scalable underlying resource,with the intention that the virtualization layerconceals physical heterogeneity, geographical dis-tribution, and faults. Current cloud environmentsonly provide direct support for single user or sin-gle organization access, and current models typi-cally have a high cost to integrate computing, data,or network transfers from outside of the cloud.This model suits environments where computingand data resource needs can be isolated to a singlelocation and rapid scaling (up or down) of com-puting, network, and data availability are impor-tant. Pricing models are variations on normalizedCPU-hours, GB/day storage, and MB networkI/O, or are based on a cloud product that can belicensed and used with local physical resources.
In contrast, grid computing aims to providea standard set of services and software that en-able the collaborative sharing of federated andgeographically distributed computing and storageresources. It provides a security framework foridentifying inter-organizational parties (both hu-man and electronic), managing data access andmovement, and utilization of remote computingresources.
Cloud computing offers a solution to the prob-lem of organizations that need resources (comput-ing, storage, or network bandwidth) either quicklyor with a highly dynamic level of demand. Op-erating in steady state at or near full capacity,cloud computing is still more expensive than di-rect ownership of computing resources, even ifthese are co-located in a shared data center. Cloudcomputing, at the present time, also only offersrelatively bare bones systems on top of which auser or organization needs to deploy and managetheir applications and data.
Grid computing addresses different issuesaround federated interoperation of computingfacilities, security, shared data management, ap-plication deployment, system monitoring, andapplication or job execution. Grid computing canbenefit from the development of cloud computingby harnessing new commercially available com-puting and storage resources, and by deploying
378 T. Rings et al.
cloud technology on grid-enabled resources toimprove the management and reliability of thoseresources via the virtualization layer.
Cloud computing can benefit from grid con-cepts by integrating standard interfaces, federatedaccess control, and distributed resource sharing.The current state of the art favors cloud com-puting for single organization commercial appli-cations that can be deployed in their entirety ontoa cloud environment. The dynamic provisioningof storage, computing power, and network band-width allows rapid scaling for intensive utilizationeither directly by the organization or by the publicvia Internet-based interfaces.
Grid technology continues to dominate pub-lic sector scientific computing environments dueto the collaborative nature of this work and theneed to manage existing data sets and computingresources across organizational boundaries. Themore advanced state of interface standardizationwithin grid technology allows some degree ofchoice between various software and hardwaresystems. Deploying data and applications into acloud environment, however, limits an organiza-tion to a single cloud provider or requires dupli-cated effort to repeat the deployment process foradditional cloud environments.
2.2 Development and Adoptionof Grid Standards
Grid computing is a concept, not a product, asolution, or a single global network akin to theInternet. This concept is most succinctly commu-nicated by I. Foster, C. Kesselman, and S. Tueckein “The Anatomy of the Grid” [25]. The gridconcept is realized through numerous grid (andgrid-related) projects, (open-source) software, in-ternational collaborations, physical infrastructure,and operational grids. While the various aspectsof the grid computing concept are still undergoingevaluation (standards, software, hardware config-urations, and human organizational issues), it isdifficult to form a single grid infrastructure or evengrid architecture. Given the inherent collabora-tive and interoperable promise of grid comput-ing, this is a major obstacle to its adoption inwider domains such as the business and privatesector. In this section, we review the current state
of grid standardization and standards adoption,considering standards bodies, de facto standards,formal architectures, and informal or ad hocarchitectures.
The OGF [50] was formed by many of theoriginal advocates and adopters of grid technologywith the goal of identifying requirements for thevarious aspects of grid computing and then todevelop standards that would allow the imple-mentation of interoperable grid systems. Otherstandardization bodies and industry fora such asthe Organization for the Advancement of Struc-tured Information Standards (OASIS) [52], theWorld Wide Web Consortium (W3C) [67], theInternet Engineering Task Force (IETF) [36], andrecently ETSI’s TC GRID have also directly or in-directly participated in the process of establishingstandards that are central to the realization of astandards-based interoperable grid environment.
There are some major grid projects that doaim to implement standards-based systems, suchas the Globus Alliance [59] which develops theGlobus Toolkit [22, 32], a low-level open sourcesoftware toolkit used for building grid systems andapplications. The Uniform Interface to Comput-ing Resources (UNICORE) forum [63], based inGermany, and the Open Middleware Infrastruc-ture Institute (OMII) for Europe [48] provide soft-ware environments that are standards conformantand cover a significant portion of the requiredcomponents to realize an operational grid. TheUNICORE software [57, 62] is used by the Dis-tributed European Infrastructure for Supercom-puting Applications (DEISA) [8], and also by theGerman Grid Initiative (D-Grid) [30].
In contrast, several large national and interna-tional grid infrastructures consist predominantlyof custom-made software developed without ref-erence to standards. These include the lightweightmiddleware for grid computing (gLite) softwaredistribution [31, 38], developed by the EnablingGrids for E-sciencE (EGEE) project (primarily tosupport of the Worldwide Large Hadron ColliderComputing Grid (WLCG)), the Open ScienceGrid (OSG) [51] and TeraGrid [58] projects inthe US, Grid Operation System (GOS) [64, 68] thesoftware developed by the China National Grid(CNGrid) [6], and Fura, a commercial productdeveloped by Grid Systems [34].
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 379
The numerous grid research projects also playan important role in establishing the grid valuechain. For example, within the European Union(EU)-funded Sixth Framework Programme (FP6)from 2002 to 2006, a number of research projectswere funded in the area of advanced grid tech-nologies, systems and services. These projectsinitiated collaborations between dozens of uni-versities, research institutes, and large and smallcompanies from across Europe to muster the crit-ical mass of experience and resources necessaryto stress test system interoperability, standards,and implementations of standards. Ongoing FP6-projects and projects started in the Seventh Frame-work Programme (FP7) build on the results of FP6and broaden it to encompass software servicesover the Internet.
An Eurescom report about business opportu-nities for telecom operators in the grid marketconcluded that telecom operators are bound tobecome key players in the grid value chain, asthey provide connectivity and own computingresources [21]. Moreover, they have establishedcustomer relationships and accounting/billing ex-perience, which is essential for business grids.Several major players including American Tele-phone & Telegraph Corporation (AT&T), BritishTelecommunications (BT), Deutsche Telekom(DT), France Telecom (FT) and Telefonica ofSpain continue to invest resources required formeasuring the market potential of grids andclouds.
To enable NGN support for grid and cloudservices, it is necessary to identify the require-ments of these services and to select existingstandards, or develop new standards that ensureinteroperability.
2.3 Standard Grid Models
Grid models are either explicitly stated or im-plicitly defined in a particular implementation.As a minimum, all grid models address security,networking, computing resources, storage re-sources, and information systems. How theseareas are brought together, and what services,systems, and sub-systems provide a specific capa-bility or interface, form the grid model and actas the basis for any standardization effort. The
Globus project proposed the Open Grid ServiceArchitecture (OGSA) in 2002 [24], later refined in2006 [26]. This model presents a grid as a ServiceOriented Architecture (SOA).
To discuss grid infrastructure in a telecoms con-text, ETSI TC GRID has a developed a workingmodel [15]. This can be depicted as a layeringof services which can be utilized independentlyor together. In Fig. 1, these are grouped by thetype of services they deliver. The lowest levelrepresents the foundation of the infrastructure:networking, storage, computing power, and pre-existing software applications. These are wrappedand presented as software services. The next layerrepresents services that are central to the oper-ation of the grid, while the outer layer providesuser-focused services.
These services are utilized by consumers, cus-tomers and providers. The consumer models theindividual or organization using a grid services.The customer models the entity responsible forcontracting the grid services, and pays for usageby consumers they have authorized. The providermodels the entity providing grid services.
2.4 The Architecture of NGN
The NGN [46] is a global initiative from thetelecoms industry using standards developed byETSI and the International Telecommunication
ConsumerConsumer
Client
InterfaceSecurity
Virtualized
Application
ManagementData
Computing
Software
ApplicationsVirtualized
Resource
Services Operational
Management
g
Information
Management
Applications
Storage
Supplier
Management
Execution
ManagementNetworks
Core Grid
Services
Business
Offer
Management
Resource
Management
User Focused
Services
Customer
Provider
Business
Management
Customer
Fig. 1 ETSI conceptual model of a grid and associatedroles [15]
380 T. Rings et al.
Union-Telecommunication Standardization Sector(ITU-T) [35]. This involves also members of ETSITC Telecoms and Internet converged Services andProtocols for Advanced Network (TISPAN) thatinclude telecom operators such as British Tele-com, German Telecom, and France Telecom.
Like with other telecommunications technolo-gies, such as ISDN or GSM, NGN standards intentto achieve interoperability. Thus, they shall enableequipment manufacturers to develop equipmentthat performs one or more NGN functions andthat can interoperate with other manufacturer’sequipment and service providers. The goal is toconstruct an NGN that supports the range of mul-timedia services that they wish to offer and thatshould interoperate with other networks. Basedon proposals from members, ETSI and the ITU-Tdevelop NGN standards to provide a consistentkit of building blocks, which allow manufacturersand service providers flexibility without compro-mising interoperability.
NGN is being designed to provide interopera-ble, inter-domain all IP-based network standardswith enhanced multimedia capabilities. There is aglobal effort within the industry to transition toNGN and re-develop existing services to lever-age NGN capabilities. Architecturally, service-related functions are independent from underly-ing transport-related technologies. As such, NGNoffers unrestricted access by users to differentservice providers. Independently from the accesstechnology, the NGN standards support mobil-ity, nomadicity and multiple services. These in-clude voice telephony, data services, multimediaservices, virtual private networks, public networkcomputing, and unified messaging [7]. The NGNdesign has aimed to support a dynamic architec-ture and can, therefore, accommodate new ser-vices as they are identified.
The NGN functional architecture that is de-fined by TISPAN [14] identifies two NGN layers.These are the Service Layer and the IP-basedTransport Layer as shown in Fig. 2. Both layersare composed from subsystems which are spec-ified as a set of functional entities and relatedinterfaces.
IP-connectivity is provided to NGN user equip-ment (UE) by the transport layer, under thecontrol of the Network Attachment Subsystem
Applications
Service Layer
User
profiles
Other
Subsystem
U
profiles
O
Core IMS
PSTN/ISDN
Emulation
User E
qu
Oth
er n
e
Emulation
Subsystem
uip
ment
Transport Layer
etw
ork
st
Network
Attachment
Subsystem
Resource and
Admission Control SubsystemSubsystem
Transport processing functions
Fig. 2 TISPAN NGN overall architecture
(NASS) and the Resource and Admission ControlSubsystem (RACS). These subsystems hide thetransport technology that is used in access andcore networks below the IP layer.
The service layer comprises the following sub-systems:
– PSTN/ISDN Emulation Subsystem (PES):PES supports the emulation of PSTN/ISDNservices through residential gateways or accessgateways for legacy terminals connected to theNGN.
– Core Internet Protocol (IP) Multimedia Sub-system (IMS): IMS supports the provisionof Session Initiated Protocol (SIP)-basedservices.
– Other subsystems, e.g. Internet Protocol Tele-vision (IPTV) dedicated subsystem) andapplications.
– Common components for accessing applica-tions, charging functions, user profile manage-ment, security management, routing databasesthat are used by several subsystems.
This subsystem-oriented architecture enablesthe addition of subsystems to cover new demandsand service classes. In addition, it provides theability to import and adapt subsystems definedby other standardization bodies. As depicted inFig. 2, applications reside on the top of the servicelayer and can be accessed by other subsystemsin this layer. TISPAN also defines an Applica-tion Server Function (ASF) [14] that can provide
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 381
standalone services or value added services on topof a basic session.
3 Convergence of NGN, Gridand Cloud Computing
For telecom operators, the future lies in converg-ing fixed, mobile and data services onto NGN.Historically, each service had its own platformwith minimal interoperability. Integrating newservices was made difficult by the lack of inter-operability, resulting in high development anddeployment costs, and consequently unattractiverates for the end users. Extending the NGN sub-system model to directly provide grid services,or at least provide mechanisms by which thirdparties can develop and deploy onto NGN gridservices, would be the basis for significant newrevenue potential and opportunities for a new eraof networked applications and services.
With advances in commodity computer com-ponents in terms of speed, cost, and reliability,many parts of NGN can utilize commercial-off-the-shelf (COTS) hardware, rather than high costspecialized chips, switches, and associated hard-ware. This opens a second avenue for the inte-gration of NGN with cloud computing approacheswhich would allow a network operator to vir-tualize various NGN subsystems, thus providingdynamic scalability, load-balancing, and fault tol-erance. Past studies [28] have already identifiedthe potential for cost savings if the current verti-cally siloed infrastructure, provisioned to handlepeak loads which may be two or three times higherthan the average load, could be re-deployed ontoa more efficient shared physical infrastructure.With expertise in the domain of managing virtu-alized servers for NGN operations in large datacenters, it is a small step for network operatorsto consider partitioning their virtualized serverplatforms and making these available as cloudcomputing services in a manner similar to thecloud services offered by Amazon [1, 29]. Tele-com operators are increasingly considering SOAin order to:
– decouple applications via middleware from ITserver/storage/network resources,
– flexibly compose new services usingstandards-based technologies and protocols,
– reuse architectural components to lower costs,and time-to-revenue.
There are features of grid technology that candirectly benefit from different aspects of NGNby addressing control and sharing between het-erogeneous system components. These are, forexample, resource optimization and billing, highperformance content rendering and encoding inthe service layer, and co-allocation and cross opti-mization of network resources and grid resources(computer, storage). In summary, there are fourpossible scenarios:
1. Grid-enabled NGN application2. NGN subsystems offering grid and cloud
services3. Combining grid and networking resources in a
new architecture4. Grid and cloud technology for implementing
NGN functionality
In the first scenario, as depicted in Fig. 3, a grid-enabled NGN application is deployed as an ap-plication server. The NGN is already designed tosupport a wide range of Application Servers andis capable of incorporating additional types devel-oped by other groups. These application serversare available via a standard interface. The grid-enabled application server would access interfacesfrom the Core IMS sub-system. In this scenario,the NGN could provide IP connectivity, autho-
ISC/M
profiles s
ISC/M
profiles s
Emulation
U OUu
Oeu
t
e
t
SubsystemSubsystem
Grid AS/Grid-enabled ApplicationsApplications
Service Layer
UserOther
Subsystem
a
Core IMS
PSTN/ISDN
ser E
q
ther n
Subsystem
ipm
en
Transport Layer
two
rks
Network
Attachment Resource and
Admission Control
Subsystem
Transport processing functions
Emulation
Fig. 3 Grid-enabled NGN application
382 T. Rings et al.
r
PSTN/ISDNO ti C
q n
O ti C
n s
Admission Control
s
Grid AS/Grid-enabled ApplicationsApplications
Option A
Service
Layer UseGrid
Servicesprofiles
Core IMS
Oth
er Option B
Emulation
Subsystem
p on
Transport Layer
etw
ork
Network
Attachment Resource and
Subsystem
Subsystem
Transport processing functions
Admission Control
qn
User E
uip
me
t
PSTN/ISDN
n
Fig. 4 NGN subsystems offering grid and cloud services
rization, security, Quality of Service (QoS), andcharging.
In the second scenario, as depicted in Fig. 4,a new NGN subsystem is added to the NGNService layer to support the provisioning of gridor cloud services. This Grid Services Subsystem(GSS) gives access to virtualized grid-enabledcloud resources, through a new service interfaceto the virtual resources and grid services. Suchan integration of a GSS presents three differentoptions:
(A) Grid-enabled applications as defined in thefirst scenario. The GSS interfaces wouldprovide common grid functionality and re-source access, thereby accelerating develop-ment of higher-level applications.
(B) Direct access by end-user applications, pro-viding them with resources managed by theGSS in the same way that non-IMS IPTVservices are offered.
(C) Updating other subsystems to leverage newcapabilities offered by the GSS. This op-tion requires the current NGN service layersubsystems to be enhanced to support gridservices in the same way that IMS basedIPTV services are offered.
In the third scenario “Combining grid and net-working resources in a new architecture” a sepa-rate grid service manages shared resources suchas computing power, network and storage. Thiswould enable the assignment of resources to thegrid or the NGN in a flexible, generic way.
Layer ULayer
Transport LayerLayer
Attachmentg
pp cat o spp cat o s
U rrr
kk
Grid enabledGrid enabled
EEee
A li i n
Grid-enabled
...Service
Core IMS
se
profiles
Oth
e
PSTN/ISDN
Emulation
Subsystem
Grid
User
netw
or
quip
m
Network Resource and
s
Grid-enabled
Application
Mana ement
nt
Subsystem Subsystem
-
Equipment
Transport processing functions
Attachmentg
Ad i i C t lAd i i C t lm ss on on ro
Services
Transport
Fig. 5 Grid and cloud technology for implementing NGNfunctionality
The fourth scenario “Grid and cloud tech-nology for implementing NGN functionality”enhances the entire NGN architecture with capa-bilities for harnessing virtualized cloud resourcesand grid-enabled services, as depicted in Fig. 5.This is the most disruptive and ambitious scenario,where logical NGN functions and entire NGNsubsystems are refined in light of grid and cloudcapabilities. This allows the optimization of theresources used by these functions and providesgreater flexibility in the deployment and operationof various NGN subsystems.
As part of the ETSI TC GRID activities aroundNGN, grid, and cloud computing, these scenarioshave all been documented in greater detail in [18].
4 Grid Interoperability
The focus of the ETSI TC GRID interoperabilitystudy was to consider areas where interoperabilitybetween grid and cloud infrastructures is possibleeither in theory or in practice. As the cloud com-puting domain is dominated by provider-specificinterfaces, suitable to the single provider model ofcurrent cloud services, it was assessed that thereis currently no significant opportunity to discussinteroperability in this area. Furthermore, thereare no established standard interfaces applicablespecifically to cloud computing, although someefforts have started to establish these. In contrast,there are a range of standards covering grid com-puting. This section considers those standards,
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 383
the associated implementations, and the resultingstate of interoperability.
4.1 Case Studies: Integrated EmergencyManagement and eHealth
An important case study is Integrated EmergencyManagement (IEM), which clearly demonstratesthe value and need for interoperability betweenconventional network services and enhanced dis-tributed applications. IEM involves setting up anenvironment in which the contributions of mul-tiple agencies can be planned and coordinatedin a coherent way [61]. The European Access toKnowledge through the Grid in a mobile World(Akogrimo) project [40] demonstrated such a sys-tem in 2007, as described in a preparatory paperissued in 2006 [5]. IEM typically involves planningfor emergencies, response when an emergencyoccurs, and a recovery period. In the responsephase, this application is characterized by strin-gent QoS requirements in the presence of diffi-cult conditions: resilience to broken connections; arequirement to cross conventional organizationalboundaries; a need to be able to trust peoplefrom multiple organizations in the field; a need tooptimize the brokering of a range of expert andspecialist resources; and detecting and managingcontext changes.
Another important and illustrative applicationarea is eHealth [19]. Within this application areaare many different potential scenarios, but twothat we mention here are Computerized DecisionSupport (CDS) and Patient Monitoring (PM). Inone example of CDS, a medical research study
called CREDO [27] highlights the needs of pa-tients with medical conditions that must be servedby many medical professionals, each offering dif-ferent services, which need to form an effectivewhole. In one example, there were over 200 ser-vices and 65 critical decision points requiring sup-port. Screening, diagnosis and planning involvethe use of data and computational resources onan on-demand basis that require QoS negotiation.Authentication and security of patient data is criti-cal. PM illustrates other problems, which were ad-dressed in another Akogrimo demonstrator [40].Patient monitoring away from a medical settinghas the potential to use sensors and a wirelessnetwork connection, delivering measurements toan evaluation point. Requirements include mobilegrid services, secure communication, occasionalbursts of intensive computing, initiation of con-ference calls between available, relevant expertsand tailoring the visualization to the results ofdiscovery of visual displays.
Identity management, security, and reliabilityare critical and multi-agency heterogeneous re-sources are inherent in the way health and emer-gency resources are managed. Authentication ofa professional not previously involved with theparticular case must be efficient. The need forinteroperability is critical since these scenariosinvolve multiple conventional organizations.
4.2 Standards Adoption
Figure 6 illustrates the standards that are in usein several popular grid software packages. Theseare dominated by OGF standards associated
Standard Unicore 6 GT 4 GLite GOS v3.2 FuraSecurity X.509
Security Assertion Markup Language (SAML)extensible Access Control Markup Language (XACML)Virtual Organization Membership Service (VOMS)WS-Security (Transport Level Security (TLS))
Execution Job Submission Description Language (JSDL)OGSA-BES (Basic Execution Service)Distributed Resource Management Application API (DRMAA)
Data OGSA-ByteIOGridFTP (defacto)
Information Web Service Resource Framework (WSRF)OGSA RUS (Resource Usage Service)OGSA-RUS (Resource Usage Service)OGSA-UR (Usage Record)
Fig. 6 Comparison of implemented standards in grid middleware
384 T. Rings et al.
with OGSA and WSRF. Clearly the Public-Key-Infrastructure (PKI) X.509 certificate system hasfound wide-spread adoption in all grid domains.The table also shows that the OGSA-Basic Ex-ecution Service (OGSA-BES), OGSA-ResourceUsage Service (OGSA-RUS), and OGSA-UsageRecords (OGSA-UR) standards have the broad-est adoption amongst the middleware underconsideration.
One aspect that is not captured by this figureis the number of grid infrastructures that utilizevery few standards. In the US, TeraGrid and OSGboth are dominated by custom-made software,or packages distributed through the Virtual DataToolkit (VDT) [60]. In these cases, the only visiblestandards are GridFTP and the X.509 identitysystem. Even authorization by X.509 certificates ishandled in quite different ways on different grids.In actuality, no operational grid infrastructuresrely exclusively (or even predominantly) on gridstandards, but instead use a patchwork of custom-made and third-party software packages, expect-ing “interoperable” sites to be running the sameversion of the software in order to maximize thepossibility of successful interoperability.
It is also essential to note that higher level gridapplications will rely on underlying grid middle-ware services in such a way that interoperabilityis not always possible, even when two implemen-tations support the same underlying set of stan-dards. This also occurs because of incomplete orpatchwork standards environment.
4.3 Current Approaches to Interoperability
Two approaches are pursued and partially ap-plied to address grid middleware interoperabil-ity: gateway/adapter and standardization. The firstapproach introduces a gateway between two sys-tems. This is a short term solution, since a changein one implementation may break the adapter andthus the interoperability.
The gateway approach has been used by [65] toachieve interoperability between the EGEE gridinfrastructure based on the gLite middleware andthe CNGrid based on the GOS middleware. Inthis case, the gateway approach has been appliedbecause gLite and GOS implement very differentarchitectures. A gateway has been applied for
their job and data management service to submitjobs and access data by the other middleware.For example, when a job is submitted, a JobDescription Language (JDL) file required bygLite is translated into a Job Submission Descrip-tion Language (JSDL) file expected by GOS andvice versa.
Standardization as a basis for interoperabilityhas been analyzed by [41]. This work focusedon interoperability of job submissions betweengLite and UNICORE since the other core ser-vices of each have custom-made implementations.However, UNICORE and gLite adopt commonopen standards such as OGSA-BES [23] and theJSDL [3] specification which means that the sameclient can invoke operations based on these stan-dards within UNICORE or gLite. In addition tothese common interfaces, it was found that bothimplementations needed to handle X.509 useridentity tokens and permissions in a similar way.OMII-UK [49] also includes projects which focuson implementing standards-based grid services,such as GridSAM, the JSDL application reposi-tory and OMII-SAGA.
Finally, the OGF has formed a specific com-munity group to consider interoperability issues,galled Grid Interoperation Now (GIN) [33]. Thisgroup reviews the current state of grid interop-erability and works towards improving interop-erability [53]. GIN provides feedback to OGFstandards bodies and leaders of grid softwareprojects in cases where interoperability is notpossible.
4.4 Standardization Gaps
Building confidence in interoperability relies onwell scoped, well-specified and achievable stan-dards. Gaps and overlaps within and betweenstandards cause problems which have to be solvedby infrastructure providers and application devel-opers. To this end an analysis of gaps and overlapswas undertaken by ETSI TC GRID. The method-ology adopted was to identify broadly applicablethemes for gap analysis, develop a number of casestudies as a mechanism to identify gaps, bringtogether gaps, overlaps and issues based on thesethemes and, on more general architectural con-
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 385
siderations, make proposals for the resolution ofgaps, overlaps and issues.
Gaps and overlaps are likely to be encounteredin several different situations:
– The presence of complex applications involv-ing the composition of services horizontally—a combination of grid services—andvertically—grid services making use ofmultiple networks, one of which could beNGN.
– The relationship between a grid and the un-derlying network.
– Diversity allowed within an individualstandard which could lead to incompatibleimplementations.
– The use of dynamic working, which exposesproblems with standards which are designedwith a static situation in mind.
– Transition to a new version of a specifica-tion. When considering the whole landscape ofmany standards, effective transition becomesa complex problem.
– Lack of implementations.
4.5 Classification of Gaps
In our study, the gaps and overlaps were classifiedinto four broad themes: security, Service LevelAgreement (SLA) and QoS, charging, and servicediscovery. The identified gaps mentioned in thenext paragraphs can be addressed in the shortterm for specific applications and testing frame-works through policy-based constraints, whileothers will require longer term standards.
4.5.1 Security
Security includes authentication, authorization,protection and trust. The problems of authenti-cation of NGN User Equipment (UE) are similarto the ones of user, host and service identities ingrids. Both areas (NGN and grid) lack standardsto guide development. Significant standard gapsexist around the issue of authorization in the griddomain. The standards related to the operation ofa security infrastructure are limited. In addition,a lack of standards regarding the use of groups,roles and attributes as part of a dynamic VirtualOrganization (VO) exists.
4.5.2 SLA and QoS
For certain critical types of distributed infrastruc-ture, there is a need for effective and timelyalternative action when the terms of the SLAare violated in order to maintain a temporarilyadequate level of service. The structure of SLAservice description terms is defined, but the namesand semantics of them are defined outside theSLA standards. These descriptions have been con-sidered for computational resources but not asyet for the relationship with networks (for in-stance, with NGN). Multi-provider applicationswill present problems for SLA establishment andmonitoring.
4.5.3 Charging
Charging includes the activity of collecting us-age data from resources. Existing solutions donot allow situations where service providers arediscovered and selected dynamically. Providing asingle bill in a multiple provider application re-quires further information to be delivered. Thereis an overlap between the structure of grid usagerecords and NGN Charging Detail Records, whichwill prove to be a problem when NGN becomesone of the supporting technologies for grids.
4.5.4 Service Discovery
Existing solutions for service discovery such asUniversal Description, Discovery and Integration(UDDI) have proved to be inadequate becauseof its static nature. A standard is required forgrid service registry that can support VO-styleauthentication, a high level of dynamism and theinclusion of service state. There is significant over-lap of the capabilities provided by various grid-domain directory services and service discoverymechanisms. Thus, there is significant scope toanalyze the requirements of these different sys-tems and work towards a common grid directoryservice standard. Existing solutions for service dis-covery do not work well for device identification,which are needed for situations such as sensornetworks.
386 T. Rings et al.
4.6 High-Level Issues Contributing to Gaps
Several gaps are not due to issues around a par-ticular technology area but come from humanprocesses, composition of services or architecturallayers, and the life-cycle of complex systems.
One such deficiency occurs where implemen-tations have not yet caught up with the OGFand OASIS standards. Production grids, whichare now extensive, adopted grid software whichpredated the move to Web Services and becauseof the initial success were slow to move on. Thisappears to be changing, because Production GridInfrastructure Working Group (PGI-WG) has re-cently been formed within OGF in order to solvespecific problems that the production grids aremeeting when they adopt current OGF standards.
Other gaps result from considering the relation-ship between a grid and the underlying network.For instance OGF specifies information whichmay be used for charging. Even though, this isalso covered by IETF Internet standards as well asNGN standards from ETSI. There is a need for thestandardization process to enable these differentmechanisms to work at all levels.
The design of complex applications involves thecomposition of services. Any area of cross-cuttingconcerns is thereby affected by these composi-tions. The strongest example of this is the securityinfrastructure, which needs to be consistent andcomprehensive in the presence of a composedapplication. Security policies need to be sharedand merged in a predictable way. This is an areawhich is not currently covered by grid standards.SLAs are also affected where composed servicesneed to be negotiated effectively building on theexisting SLAs of constituent services. Similarly,charging needs to take the composition of servicesinto account. In general, there is little standardscoverage of charging models for grid services.
Within each individual grid standard, there isoften room for variation, either intentionally toallow flexibility, or unintentionally. This can in-hibit interoperability between implementations, ifdifferent subsets of the variations are chosen. Thispotential for incompatibility needs to be correctedeither by restricting variation in standards or byincorporating protocols for service characteristicenquiry and negotiation.
Complexity due to dynamic operational en-vironments introduces gaps. Behavior duringtransition from one environment to another isgenerally not discussed: for example in mobileservices where the network characteristics suchas bandwidth or QoS may change during a sin-gle session. Although existing Grid specificationsenvisage some variation of user requirements andworkloads, they generally do not accommodatevariations in an active session.
Many grid protocol and data standards have notconsidered the standard life-cycle and environ-ments where multiple standards are in use concur-rently. Accommodating version negotiation andcompatibility will introduce problems. For exam-ple, this is known to occur where Web Service(WS)-Agreement [2] references a different ver-sion of WS-Addressing from the one used bymost current implementations. Explicit versioningneeds to be introduced. This will become criticalas complex applications running across severalgrids come into use.
5 Testing for Interoperability
Conformance and interoperability testing involveschecking that implementations follow their spec-ifications and that they provide the intendedfunctionality. In the following we use the termstandard instead of specification, because we con-sider such a specification to be standardized andpublished by an organization like OGF, W3C orETSI. In this section, we describe the details ofconformance and interoperability testing, discussrelated work on grid testing and describe theETSI process for conformance and interoperabil-ity test development. Finally, we present an exam-ple that shows how the ETSI process can be usedto define interoperability tests for grid systems.The example is based on the OGF OGSA-BESstandard [23].
5.1 Conformance vs. Interoperability Testing
At ETSI, implementations of standards can beformally tested using conformance testing, inter-operability testing, or interoperability testing withconformance checking [13]. The three approaches
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 387
are illustrated in Fig. 7. Each approach has bene-fits and limitations.
Conformance testing is functional black-boxtesting of one Implementation Under Test (IUT)where the IUT shows its conformity to a standard.The IUT is normally embedded within a SystemUnder Test (SUT). The SUT is a testing environ-ment that contains the IUT and possibly emulatesparts of the system the IUT has to interact withto provide its service to its user. However, evenpassing a conformance test does not automaticallyprove that the IUT is interoperable with othersystems implementing the same standard. Thereason for this is that standards are often not pre-cise enough; they contain implementation optionsand requirement specifications leave space forinterpretation.
Interoperability testing demonstrates that twoor more Equipments Under Test (EUTs) togetherprovide the end-to-end functionality described orimplied by a standard. In this setting, an EUTis considered to be a complete system that mayconsist of several soft- and hardware components.The EUTs inter-operate via an abstract Means ofCommunication (MoC) which is not subject of theinteroperability test. Therefore, the SUT for in-teroperability testing only includes the EUTs andnot the MoC. However, there exists the hidden as-
Driver
SUTSUT
SUT
Test IUT
iiConformance Testing
EUTEUT
Means ofCommunication
(MoC)
TestDriver
TestDriver
Interoperability Testing
Monitor
EUTEUTTest
DriverTest
Driver
Interoperability Testingwith Conformance Checking
SUT
Fig. 7 Three approaches to testing
sumption that the communication services neces-sary for the interoperation of the involved EUTshave been tested for conformance before theinteroperability test takes place. Unfortunately,practice has shown that a lot of interoperabilityproblems are related to conformance problems ofthese communication interfaces.
For this reason, ETSI advocates interoperabil-ity testing with conformance checking, a hybridof the two approaches described above, as inter-operability testing approach. This third approachextends end-to-end interoperability testing withthe monitoring of the communication among theEUTs. The monitor is used to check the confor-mance of the EUTs with the relevant protocolspecifications within the SUT during the interop-erability test.
The ETSI experience with applying this hybridapproach in Plugtests™ has been that in a num-ber of cases end-to-end interoperability has beenobserved even though EUTs did not communicateaccording to underlying standards. Although thisapproach is not a replacement for conformancetesting, it gives an insight into the conformance toa standard of EUTs involved in the interoperabil-ity test.
5.2 Related Work on Grid Testing
An approach of testing grid application workflowsbased on the grid middleware Globus Toolkit 4is outlined in [54]. This work focuses on confor-mance testing adopting the international ISO/IECmulti-part standard 9646 OSI Conformance Test-ing Methodology and Framework [37] for testspecification and implementation using the Test-ing and Test Control Notation (TTCN-3) [20, 66].A case study demonstrates that the test conceptsof TTCN-3 and the remote communication mech-anisms provided by TTCN-3 run-time environ-ments facilitate very well the distributed testing ingrid environments.
The eInfrastructure for Testing, Integration andConfiguration of Software (ETICS) project [9]provides a build and test system by means ofreliable grid software and industry-standard bestpractices. ETICS is used for the build and inte-gration process of gLite by EGEE. Examples forETICS-based implementations of EGEE are the
388 T. Rings et al.
IPv6 compliance analysis of gLite code and thedistributed IPv6 experimental testbed for testingthe IPv6 version of the Berkely Database Infor-mation Index (BDII). In addition, EGEE appliedthe ETICS system to build some of its high-levelservices, such as GridWay. Furthermore, the on-going ETICS 2 project endeavors to support thewidespread adoption of grid technologies.
OGF has done some work on test specificationsfor ByteIO [43] and GridRPC [44]. These testspecifications are informal test descriptions thatmainly follow a conformance oriented, unit test-ing approach rather than end-to-end functionalitytesting from an ETSI point of view.
5.3 The ETSI Process for Test Development
The development of test specifications at ETSI[12, 56] is a process that goes through multiplesteps as illustrated in Fig. 8. These steps can beunderstood as different levels of abstraction thatbridge the large gap between a base standard orprofile thereof and a final conformance or inter-operability test specification.
Base Standard or Profile specification
ETSI Test Development Process
Identification and cataloguing of requirements1.
Implementation Conformance (or Functional) 2
Statement (ICS/IFS) specification2.
Test Purposes (TP) definition and Test Suite Structure (TSS) description
3.
Test Description (TD) specification4.
T t C (TC) d l t5 Test Case (TC) development5.
Validation of Test Cases
Final conformance or interoperability test specification
Fig. 8 ETSI process for test development
In step 1, requirements are identified from rel-evant base specifications or profiles thereof. Arequirement is a specific behavior of the IUT, i.e.,a series of stimuli to and expected outputs fromthe IUT, that can be assessed by means of a test.Requirements may be published in a requirementscatalogue. Then, in step 2, the ImplementationConformance (or Functional) Statement (ICS/IFS)is specified. This step is essentially a high levelcheck list of features and capabilities supportedby the IUT. The ICS/IFS can be used to quicklyidentify if two implementations of the same stan-dard have the potential to inter-operate. In thenext step (step 3), Test Purposes (TPs) are spec-ified for the identified requirements and a logicalgrouping of the TPs, the Test Suite Structure (TSS)is defined. If a requirement can be assessed using agiven form of testing then a test purpose specifiesverdict criteria for a test. After that, in step 4,for each TP an informal Test Description (TD) isdeveloped. In step 5, either TP- or TD-based TestCases (TCs) are specified.
The final step includes the validation of the TCsand is normally not done by ETSI. The validationensures that the TCs are correctly specified. It maybe done by executing the TCs at an interoper-ability event or by running TCs by means of con-formance test tool against a number of differentimplementations of a given standard. Problemsdetected during the validation should be reportedto ETSI and may lead to changes in the ETSI TCspecifications. The validated TCs form the finalinteroperability or conformance test specification.
5.4 Example: Grid Interoperability TestSpecification for OGSA-BES CreateActivity
In this section, the ETSI test specification devel-opment process is exemplified by using an ex-cerpt of the requirements identified in the OGFOGSA-BES standard [23]. OGSA-BES is a goodcandidate for interoperability testing, because in-teroperation between OGSA-BES implementa-tions is defined in the standard and OGSA-BESis not only implemented by the grid systems pre-sented in Fig. 6, but also by other grid-, cluster-,and cloud-environments such as Microsoft HPCServer [42], GridSam [39], and BES++ [4, 55].
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 389
5.4.1 OGSA-BES—A Short Introduction
OGSA-BES is an OGF standard that specifiesa Web Service for initiation, monitor, and con-trol of computational activity requests from a Ba-sic Execution Service (BES) client to a server.Activities in an OGSA-BES context are describedwith JSDL [3] and can be, for example, UNIXor Windows processes, Web Services, or parallelprograms within a defined environment. A BESserver executes accepted activities on appropriatecomputational resources. These resources can bea single computer, a cluster managed by a re-source manager, a Web Service hosting environ-ment, or another BES server.
5.4.2 Test Configuration
Prior to starting test development, an appropriatetest configuration for the interoperability test withconformance checking has to be defined. For this,we need to relate the service oriented view of thegrid infrastructure (Fig. 1) to a view of physicalelements. This is done in the test configurationshown in Fig. 9 which allows testing interoperabil-ity between OGSA-BES-client and OGSA-BES-server implementations.
In this figure, we assume that one EUT includesa grid middleware like gLite, Globus Toolkit 4,or UNICORE that implements user focused ser-
TeststTe
Driver
SupplierClient
SUT
OfferManagement
ManagementClient
Interface
Grid
Middl
OperationalApplicationManagement
Middleware
(EUT)ResourceExecution Resource
ManagementExecution
Management
OGSA-BESClient
Monitor
OGS S
C t ti l
OGSA-BES
Server
Computational
Resource (EUT)
Cluster
Management
Fig. 9 Test configuration reflecting physical entities as wellas services involved in creating a BES activity
vices, core grid services, and an OGSA-BES-clientservice. The second EUT is a computational re-source like a single computer or cluster managedby an OGSA-BES-server implementation. Duringthe interoperability test, a monitor componentchecks the conformance of the client-server com-munication to the standard referenced in [23].
5.4.3 Requirement Extraction
The first step in the development of ETSI testspecifications is to analyze and extract require-ments from a base standard or a profile thereof.Figure 10 shows the specification of the Create-Activity operation as an excerpt from OGSA-BES [23]. It is used for requesting the creation ofnew activities. For the CreateActivity operation,inputs, output, and also the handling of faults arespecified. The CreateActivity operation expectsa JSDL input file that includes a job descriptionelement and describes a single activity. If the ac-tivity is created successfully, the operation returnsthe activity identifier. In addition, the specificationdefines several faults that may occur. For example,the consumer requesting the creation may not beauthorized to create activities, the BES servicemay currently not accept new activities, a featuredescribed in the JSDL may not be supported bythe BES implementation, or an element in therequest message may not be recognized.
Input• ActivityDocumentType ActivityDocument
JDSL file – An XML document including the element jsdl:JobDescription describing a single activity that is to be created.
Outputp• CreateActivityResponseType Response
ActivityIdentifier (EPR) – Identifies the requested activity.c y de e ( de es e eques ed ac y
FaultsFaults• NotAuthorizedFault – Indicates that while the front-end (i.e. BES web
service) was able to validate the incoming user credentials, the back-endservice) was able to validate the incoming user credentials, the back endwould not permit the operation given the credentials supplied.
• NotAcceptingNewActivities – A fault that indicates that the BES is not p gcurrently accepting new activities.
• UnsupportedFeatureFault – A fault indicating either:pp gA well-formed, supported JSDL document input element containing a sub-element that is not implemented by this BES implementation.yA non-JSDL input element that is not implemented by this BES implementation
• InvalidRequestMessageFault – An element in the request message is not recognized.
Fig. 10 CreateActivity specification (Excerpt fromOGSA-BES)
390 T. Rings et al.
Determining the granularity of requirements tocapture is not always an easy task. The Create-Activity operation description contains arguablymore than a single requirement. It covers the han-dling of normal behavior as well as the handling ofexceptional or invalid behavior. However, insteadof isolating these behaviors during requirementextraction, we retain them in a single, compoundrequirement and isolate them in the next step, thetest purpose specification.
5.4.4 Test Purpose Specification
The next step in the ETSI test developmentprocess is the specification of TPs. For this, ETSIhas developed TPLan [56], a special notation fordescribing TPs. An example of a TPLan descrip-tion is shown in Fig. 11. TPLan is based on naturallanguage and can be used to enforce structuredand consistent writing of TPs.
A TP associated with an interoperability testwith conformance checking has to cover eitherone of two aspects: (1) identification of the end-to-end functionality to be tested, or (2) the confor-mance requirements that can be assessed duringthe end-to-end test.
Figure 11 presents a TP for the second aspect,i.e., for a conformance test which assesses thecorrect implementation of a valid BES CreateAc-tivity operation invocation. Additional test pur-poses have also been specified for testing the errorhandling as described in Fig. 10.
TP ID: TP_OGSA_BES_0005Summary: “A successful creation of an activity on a computational
resource”Clause Ref: OGSA GFD-R.108 6.2.1IUT role: OGSA BES Server-- pre-conditionswith { computational resource being available andwith { computational resource being available and
new activities are accepted andconsumer authorized }
ensure that {-- stimuluswhen { the IUT receives an ActivityDocument{ y
containing a valid JSDL document including a Job Definition element-- responsethen { the IUT sends a Responsethen { the IUT sends a Response
containing an ActivityIdentifier (EPR) }}
Fig. 11 Test purpose for a successful BES activity creation
Interoperability Test DescriptionIdentifier: TD_OGSA_BES_001
Summary: Ensure that an authorized consumer can create an activity on acomputational resource
References: OGSA GFD R 108 6 2 1References: OGSA GFD-R.108 6.2.1Configuration: Middleware and computational resourcePreconditions: Consumer is authorized to create activity on computational resource
Provider has registered computational resource with middlewareProvider has registered computational resource with middleware
Test Sequence: Step Description
1 Consumer submits a computational activity using API providedby middlewarey
2 Verify that consumer is notified by middleware that activity is started
Checks: Id Conformance Criteria InterfaceTP_OGSA_BES_0005:when computational resource receives an ActivityDocument
a valid JSDL document including a Job Definition1 a valid JSDL document including a Job Definitionelement
then it sends a Response
BES
containing an ActivityIdentifier (EPR)
Fig. 12 Test description for a successful BES activitycreation
5.4.5 Specification of Test Descriptions
After defining conformance TPs, we have to selectend-to-end functionalities that include the TPsand to specify a complete test description for eachfunctionality. An example for such a test descrip-tion is shown in Fig. 12.
The test sequence is written in terms of externalactors and their ability to interact and observe theservices provided by the entire grid infrastructure,i.e., end-to-end behavior. Based on its success, wederive a test verdict reflecting the interoperabilityof all EUTs in a test.
The test description also includes a list of allrelevant conformance TPs that can be assessed bymonitoring the EUT-communication during theend-to-end test. The compliance of test executiontraces to all of these TPs forms another test ver-dict, the so-called communication verdict. Sinceend-to-end functionality usually encompasses theexchange of multiple messages, each interoper-ability test usually covers a number of differentconformance TPs at the same time. In our exam-ple (Fig. 12), we have limited the assessment toonly one conformance TP.
5.5 ETSI Plugtests™
Test descriptions like the one shown in Fig. 12are often validated at interoperability events like,for example, the ETSI Plugtests™ [11]. Currently,ETSI organizes around 15 Plugtests™ per year
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 391
also in corporation with other organizations andfora. Plugtests™ are open for attendance to every-one. They are used to assess or demonstrate thematurity of a given technology as well as to vali-date standards, e.g., for IMS core networks, High-Definition Multimedia Interface (HDMI), IPv6,Radio-Frequency IDentification (RFID), IPTV,power line transmissions, intelligent transportsystems, etc.
ETSI has also been organizing grid Plugtests™for the past five years [10]. Recently, its technicalformat has been changed from a grid program-ming contest on a fixed, worldwide grid infrastruc-ture into the assessment of a common interface forapplication deployment on a variety of differentgrid and cloud infrastructures based on ETSI GridComponent Model (GCM) standards [16, 17].Results and findings of this Plugtests™ are fedback to the ETSI TC GRID and will be used forthe improvement of existing and the creation ofnew standards in this domain.
6 Summary and Outlook
Telecom operators are expecting that grid enabledservices can improve their internal network oper-ation as well as enrich the services they offer totheir customers. For this, interoperability betweengrid technology and telecom networks has to beachieved. ETSI and its TC GRID have a key roleto play in establishing priorities, standards, andtesting mechanisms.
Several possible scenarios for converging gridand cloud technology with NGN, discussing theadvantages and disadvantages of each have beenconsidered in this article. A review of key stan-dards and standards development organizationshighlights the successes, as well as the short-comings indicated by many custom-made gridinfrastructures. Cloud computing has recentlybecome a popular area, but presently lacksstandards or perspectives for interoperability,although there are signs this is slowly changing.ETSI intends to continue standardizing softwareprotocols and interfaces relevant to NGN andadopting grid and cloud computing technologyinto the global telecommunications network. Theannual Plugtests™ have potential to grow into
a much broader evaluation of commercial gridtechnology and standards.
Interoperability between systems can only beachieved when there are clear standards for in-terfaces and an environment that supports multi-ple implementations of architectural components.The lack of a widely agreed-upon grid archi-tecture, encompassing software, hardware, andservices, impedes the development of a consistentset of standards.
The telecom industry will gain valuable expe-rience with third party services and sub-systemsoffering advanced functionality with the roll-outof NGN. We expect that this roll-out will lead toincreased efforts to develop interoperating grid,cloud, and telecom systems.
Acknowledgements The authors would like to thankall reviewers of this paper for their helpful contribu-tions as well as the ETSI TC GRID for their guidanceand support. We would also like to thank the EuropeanCommission for the funding provided under the contractSA/ETSI/ENTR/000/2006-10 which has made this articlepossible.
References
1. Amazon Web Services, LLC: (Online; http://aws.amazon.com/ fetched on 13-04-09)
2. Andrieux, A., Czajkowski, K., Dan, A., Keahey, K.,Ludwig, H., Nakata, T., Pruyne, J., Rofrano, J., Tuecke,S., Xu, M.: Web Services Agreement Specification(WS-Agreement), GFD-R-P.107. Open Grid Forum(2007)
3. Anjomshoaa, A., Brisard, F., Drescher, M., Fellows, D.,Ly, A., McGough, S., Pulsipher, D., Savva, A.: Job Sub-mission Description Language (JSDL) Specification,Version 1.0, GFD-R.136. Open Grid Forum (2008)
4. BES++ Project Homepage: (Online; http://bespp.sourceforge.net/ fetched on 13-04-09)
5. Briscombe, N., Palmer, D., Ntuba, M., Bertram, S.,Boniface, M.: Enabling integrated emergency manage-ment: reaping the Akogrimo benefits. Tech. rep., ITInnovation Centre, School of Electronics and Com-puter Science, University of Southampton. (Online;http://eprints.ecs.soton.ac.uk/14197/1/Akogrimo_whitePaper_DisasterCrisisMgmt_v1-1.pdf fetched on14-04-09) (2006)
6. China National Grid: (Online; http://www.cngrid.orgfetched on 13-04-09)
7. Crimi, J.C.: Next Generation Network (NGN) Ser-vices. Telcordia Technologies, White Paper (2003)
392 T. Rings et al.
8. Distributed European Infrastructure for Supercomput-ing Applications: (Online; http://www.deisa.eu/ fetchedon 13-04-09)
9. eInfrastructure for Testing, Integration and Config-uration of Software (ETICS): (Online; http://www.eu-etics.org fetched on 13-04-09)
10. ETSI: History of Events. (Online; http://www.etsi.org/WebSite/OurServices/Plugtests/History.aspx fetchedon 28-07-09)
11. ETSI: Plugtests™ interop events. (Online; http://www.etsi.org/plugtests fetched on 13-04-09)
12. ETSI: ETSI ES 202 568: Methods for Testing andSpecification (MTS); Internet Protocol Testing (IPT);Testing: Methodology and Framework. EuropeanTelecommunications Standards Institute (ETSI),Sophia-Antipolis, France (2004)
13. ETSI: ETSI ES 202 237: Methods for Testingand Specification (MTS); Internet Protocol Testing(IPT); Generic approach to interoperability testing.European Telecommunications Standards Institute(ETSI), Sophia-Antipolis, France (2007)
14. ETSI: ETSI ES 282 001: Telecommunications andInternet converged Services and Protocols forAdvanced Networking (TISPAN); NGN FunctionalArchitecture. European Telecommunications Stan-dards Institute (ETSI), Sophia-Antipolis, France(2008)
15. ETSI: ETSI TR 102 659-1 V1.1.1: GRID; Study ofICT Grid interoperability gaps; Part 1: Inventoryof ICT Stakeholders. European TelecommunicationsStandards Institute (ETSI), Sophia-Antipolis, France(2008)
16. ETSI: ETSI TS 102 827 V1.1.1: Grid ComponentModel (GCM); GCM Interoperability Deployment.European Telecommunications Standards Institute(ETSI), Sophia-Antipolis, France (2008)
17. ETSI: ETSI TS 102 828 V1.1.1: Grid Compo-nent Model (GCM); GCM Applications Description.European Telecommunications Standards Institute(ETSI), Sophia-Antipolis, France (2008)
18. ETSI: ETSI TR 102 767: Grid services and tele-com networks; Architectural option. Tech. rep.,European Telecommunications Standards Institute(ETSI), Sophia-Antipolis, France (2009)
19. ETSI eHEALTH Technical Body: (Online; http://http://portal.etsi.org/portal_common/home.asp?tbkey1=eHEALTH fetched on 13-04-09)
20. ETSI TC MTS: ETSI ES 201 873 V3.2.1: The Test-ing and Test Control Notation version 3; Parts 1–8.European Telecommunications Standards Institute(ETSI), Sophia-Antipolis, France, also published asITU-T Recommendation series Z.140 (2007)
21. EURESCOM: TelCo Grid - Business Opportunitiesfor Telecom Operators in the Grid market. (Online;http://www.eurescom.de/public/projects/P1300-series/P1349 fetched on 30-06-09) (not publicly available)(2004)
22. Foster, I.: Globus toolkit version 4: software forservice-oriented systems. In: Jin, H., Reed, D.A., Jiang,W. (eds.) NPC. Lecture Notes in Computer Science,vol. 3779, pp. 2–13. Springer, New York (2005)
23. Foster, I., Grimshaw, A., Lane, P., Lee, W., Morgan,M., Newhouse, S., Pickles, S., Pulsipher, D., Smith, C.,Theimer, M.: OGSA basic execution service version1.0, GFD-R.108. Open Grid Forum (2008)
24. Foster, I., Kesselman, C., Nick, J., Tuecke, S.:The physiology of the grid: an open grid servicesarchitecture for distributed systems integration. http://www.globus.org/alliance/publications/papers/ogsa.pdf(2002)
25. Foster, I., Kesselman, C., Tuecke, S.: The anatomy ofthe grid: enabling scalable virtual organizations. Int. J.High Perform. Comput. Appl. 15(3), 200 (2001)
26. Foster, I., Kishimoto, H., Savva, A., Berry, D., Djaoui,A., Grimshaw, A., Horn, B., Maciel, F., Siebenlist, F.,Subramaniam, R., Treadwell, J., Reich, J.V.: The OpenGrid Services Architecture, Version 1.5, GFD-I.080(2006)
27. Fox, J., Patkar, V., Thomson, R.: Decision supportfor healthcare: the PROforma evidence base. Inform.Prim. Care 14, 49–54 (2006)
28. France Telecom R&D: Grid computing: computer re-sources on demand. Tech. rep., France Telecom R&D.(Online; http://www.orange.com/en_EN/innovation/latest_news/hot_topics/tous_les_dossiers/att00009564/ddm_200503uk.pdf fetched on 20-08-09) (2005)
29. Garfinkel, S.L.: An Evaluation of Amazon’s Grid Com-puting Services: EC2, S3 and SQS. Tech. rep., Centerfor Research on Computation and Society, School forEngineering and Applied Sciences, Harvard Univer-sity, Cambridge, MA (2007)
30. German Grid Initiative (D-Grid): (Online; http://www.d-grid.de fetched on 13-04-09)
31. gLite: (Online; http://glite.web.cern.ch/glite/ fetchedon 13-04-09)
32. Globus Toolkit: (Online; http://www.globus.org/toolkit/ fetched on 13-04-09)
33. Grid Interoperation Now Community Group: (Online;http://forge.gridforum.org/sf/projects/gin fetched on13-04-09)
34. Grid Systems S.A.: (Online; http://www.gridsystems.com/ fetched on 13-04-09)
35. International Telecommunication Union-Telecommunication Standardization Sector (ITU-T):(Online; http://www.itu.int/ITU-T/ fetched on13-04-09)
36. Internet Engineering Task Force: (Online;http://www.ietf.org/ fetched on 13-04-09)
37. ISO/IEC: Information technology—open systemsinterconnection—conformance testing methodologyand framework. International ISO/IEC multipartstandard No. 9646 (1994-1997)
38. Laure, E., Fisher, S.M., Frohner, A., Grandi, C.,Kunszt, P., Krenek, A., Mulmo, O., Pacini, F., Prelz,F., White, J., Barroso, M., Buncic, P., Hemmer, F.,Meglio, A.D., Edlund, A.: Programming the Gridwith gLite. In: Jin, H., Reed, D.A., Jiang, W. (eds.)Computational Methods in Science and Technology,vol. 12(1), pp. 33–45. Scientific Publishers OWN(2006)
39. London e-Science Centre: GridSAM - grid jobsubmission and monitoring web service. (Online;
Grid and Cloud Computing: Opportunities for Integration with the Next Generation Network 393
http://gridsam.sourceforge.net/2.1.3/index.html fetchedon 13-04-09)
40. Loos, C.: E-health with mobile grids: The Akogrimoheart monitoring and emergency scenario. AkogrimoWhite Paper, (Online; http://www.akogrimo.org/download/White_Papers_and_Publications/Akogrimo_eHealth_white_paper_short_20060207.pdf fetched on14-04-09) (2006)
41. Marzolla, M., Andreetto, P., Venturi, V., Ferraro, A.,Memon, A.S., Memon, M.S., Tweddell, B., Riedel,M., Mallmann, D., Streit, A., van den Berghe, S.,Li, V., Snelling, D.F., Stamou, K., Shah, Z.A.,Hedman, F.: Open standards-based interoperability ofjob submission and management interfaces across thegrid middleware platforms gLite and UNICORE. In:E-SCIENCE ’07: Proceedings of the Third IEEE Inter-national Conference on e-Science and Grid Comput-ing, pp. 592–601. IEEE Computer Society, Piscataway(2007)
42. Microsoft: Windows HPC Server 2008. (Online; http://www.microsoft.com/hpc/en/us/developer-resources.aspx fetched on 13-04-09)
43. Morgan, M.: ByteIO OGSA WSRF Basic ProfileRendering 1.0, GFD-R-P.088. Open Grid Forum(2006)
44. Nakada, H., Matsuoka, S., Seymour, K., Dongarra,J., Lee, C., Casanova, H.: GridRPC: a Remote Pro-cedure Call API for Grid Computing. AdvancedProgramming Models Research Group, GWD-I (Infor-mational) (2002)
45. Networked European Software and Services Initiative:Business Grids Vision and Strategic Research Agendav3.0. Online http://www.nessi-europe.com/ (2008)
46. Next Generation Networks: (Online; http://www.etsi.org/website /Technologies /NextGenerationNetworks.aspx fetched on 13-04-09)
47. NextGRID: (Online; http://www.nextgrid.org/ fetchedon 13-04-09)
48. OMII-Europe: (Online; http://omii-europe.com/fetched on 13-04-09)
49. OMII-UK: (Online; http://www.omii.ac.uk/ fetched on13-04-09)
50. Open Grid Forum: (Online; http://www.ogf.org/fetched on 13-04-09)
51. Open Science Grid: (Online; http://www.opensciencegrid.org/ fetched on 13-04-09)
52. Organization for the Advancement of Structured In-formation Standards (OASIS): (Online; http://www.oasis-open.org fetched on 13-04-09)
53. Riedel., M., Laure, E., Soddemann, T., Field, L., Casey,J., Litmaath, M., Baud, J.Ph., Koblitz, B.: Interoper-
ation of world-wide production e-science infrastruc-tures. Concurrency and Computation: Practice andExperience (2008)
54. Rings, T., Neukirchen, H., Grabowski, J.: Testing Gridapplication workflows using TTCN-3. In: InternationalConference on Software Testing Verification and Val-idation (ICST), pp. 210–219. IEEE Computer Society,Piscataway (2008)
55. Ruiz-Alvarez, A., Smith, C., Humphrey, M.: BES++:HPC profile open source C implementation. In: 9thIEEE/ACM International Conference on Grid Com-puting, pp. 41–48 (2008)
56. Schulz, S., Wiles, A., Randall, S.: TPLan-a notation forexpressing test purposes. In: TestCom/FATES. Lec-ture Notes in Computer Science, vol. 4581, pp. 292–304.Springer, New York (2007)
57. Streit, A., Erwin, D., Lippert, T., Mallmann, D.,Menday, R., Rambadt, M., Riedel, M., Romberg, M.,Schuller, B., Wieder, P.: UNICORE - From ProjectResults to Production Grids. CoRR (2005)
58. TeraGrid: (Online; http://www.teragrid.org/ fetched on13-04-09)
59. The Globus Alliance: (Online; http://www.globus.org/fetched on 13-04-09)
60. The Virtual Data Toolkit: (Online; http://vdt.cs.wisc.edu/ fetched on 13-04-09)
61. UK Cabinet Office: Civil contingencies act 2004:Emergency preparedness. (Online; http://www.cabinetoffice .gov.uk/ukresilience/preparedness .aspxfetched on 13-04-09) (2004)
62. UNICORE: (Online; http://www.unicore.eu/ fetchedon 13-04-09)
63. UNICORE Forum e.V.: (Online; http://www.unicore.eu/forum/ fetched on 13-04-09)
64. VEGA GOS: (Online; http://vega.ict.ac.cn/gos/en/index_en.htm fetched on 13-04-09)
65. Wang, Y., Scardaci, D., Yan, B., Huang, Y.: Intercon-nect EGEE and CNGRID e-Infrastructures throughinteroperability between gLite and GOS middlewares.In: eScience, pp. 553–560. IEEE Computer Society,Piscataway (2007)
66. Willcock, C., Deiß, T., Tobies, S., Keil, S., Engler, F.,Schulz, S.: An Introduction to TTCN-3. Wiley, NewYork (2005)
67. World Wide Web Consortium (W3C): (Online;http://www.w3.org/ fetched on 13-04-09)
68. Zha, L., Li, W., Yu, H., Xie, X., Xiao, N., Xu, Z.:System software for China national Grid. In: Jin, H.,Reed, D.A., Jiang, W. (eds.) NPC, Lecture Notes inComputer Science, vol. 3779, pp. 14–21. Springer, NewYork (2005)