\begin{article}
\title{Geoprocessing in the Clouds}
\author{Bastian Baranski, Bastian Schaeffer, Richard Redweik}

\maketitle

\section{Abstract}

Cloud Computing is one of the latest hypes in the mainstream IT world. Spatial Data Infrastructures (SDIs) with its classical publish-find-bind paradigm have not been affected yet by this emerging trend. This paper reviews this novel technology and tries to identify the paradigm behind it. In particular, the scalability aspect for a cloud enabled 52$^{\circ}$North Open Source Web Processing Service is challenged and proven in the exemplary Google Cloud. On this basis, future direction for SDIs and the Cloud Computing paradigm are identified.

\section{Introduction}

Cloud Computing is one of the latest trends in the mainstream IT world \cite{Gartner2009}. The term Cloud Computing uses a cloud metaphor to represent the internet or other large networking infrastructures. From a provider perspective, the key aspect of the cloud is the ability to dynamically scale and provide computational power, storage, and other applications, even complete infrastructures in a cost efficient and secure way over the internet. From a client perspective, the key aspect of a cloud is the ability to access the cloud facilities on-demand without managing the underlying infrastructure and dealing with the related investments and maintenance costs.

However, existing Spatial Data Infrastructures (SDI) are mostly focused on data retrieval and data visualization \cite{Kiehle2007}. Migrating the data processing part from classical desktop application to a distributed environment could be regarded as the next step. The step after migrating to a distributed environment
would be the adoption of Cloud Computing principles.
 While the processing part in SDIs has already been tackled \cite{Schaeffer2009} \cite{Friis2007} \cite{Weiser2007}, Cloud Computing has not been regarded in the context of SDIs yet. This was the starting for this paper to explore the capabilities of Cloud Computing with a special focus on the processing part in SDIs.

In general, there are two options for realizing Cloud Computing in SDIs. First, adopting Cloud Computing principles and standards to SDIs. Second, migrating SDI elements amongst other services on top of a Cloud Computing infrastructure. Following the first option, the geodomain would once again create their own separate standards and markets and therefore establishing new barriers for utilizing SDIs. From our perspective the second option would be more effective and would allow the Geoinformation (GI) domain to be open to the mainstream IT world and thereby broaden the limited GI market. By leveraging these core propositions, we believe that the paradigm behind the Cloud Computing buzzword is promising for geospatial applications in order to enable new and promising business models for building up, operating and utilizing SDIs. In order to get hands-on experience, the 52$^{\circ}$North WPS implementation \footnote{\url{http://www.52north.org/wps}} was migrated as a proof-of-concept study into the Google Cloud (namely the Google App Engine platform).

The remainder of this paper is structured as follows. First, a review of the basic concepts and related technologies is provided. This is followed by a description of the technical concept of the WPS migration into the Google Cloud. In the next section, our technical concept is evaluated in terms of scalability as one of the key aspects of Cloud Computing. Finally, the paper ends with a conclusion about the described framework and a discussion about interesting topics for a further research agenda.

\section{Background}

This section provides a review of related work in the context of Cloud Computing and SDI concepts.

\subsection{Cloud Computing}

Cloud Computing is one of the latest trends in the mainstream IT world \cite{Gartner2008} \cite{Gartner2009} and several companies such as Amazon, Google, Microsoft and Salesforce have already build up significant effort in this direction. The term Cloud Computing uses a cloud metaphor to represent the internet or other large networking infrastructures and the paradigm behind the buzzword hints at a future in which the storage of data and computations are no longer performed on local computers, but on distributed facilities operated by third-party storage and computational utilities \cite{Foster2008}. The term Cloud Computing overlaps with some concepts of Distributed Computing and Grid Computing \cite{Hartig2008}. Grid Computing and Cloud Computing are both scalable infrastructures and provide sufficient computational resources like storage or computational power. But the target audience of Grid Computing is typically the scientific community running large-scale simulations and resource- and time-consuming applications (for example a global climate change model or the aerodynamic design of engine components), whereas with Cloud Computing small and medium-sized companies can scale their web-based applications in an instant fashion without having to invest in infrastructure for storing or processing large amounts of data \cite{Myerson2008}. Furthermore, national and international Grid infrastructures (for example the Worldwide LHC Computing Grid \footnote{\url{http://lcg.web.cern.ch/LCG/}}) are typically governmentally funded and driven by international joint research projects (for the example the Large Hadron Collider, LHC project at CERN \footnote{\url{http://lhc.web.cern.ch/lhc/}}), whereas cloud infrastructures are operated by large enterprises under economic aspects.

\subsubsection{Characteristics}

The key characteristics of the cloud are the ability of datacenter providers to scale and provision computational resources, storage, and other applications even complete infrastructures dynamically in a cost efficient and secure way over the internet. Besides the consumer is given the ability to use these resources without having to manage the underlying complexity of the technology. These characteristics open up new perspectives for tackling different problems and lead to the following set of core value propositions.

\paragraph{Efficiency}
Cloud Computing enables IT organizations to increase hardware utilization rates enormously and to scale up to massive capacities in an instant without heavily investing in infrastructure in advance. Datacenter providers are now able to utilize their infrastructure more efficiently by dynamically distributing their applications and processes to free available resources.

\paragraph{Outtasking}
By outtasking software and data to scalable facilities operated by third parties, users and customers don't have to operate their own datacenters anymore. Therefore, enterprises of all types - from Web 2.0 startups to global enterprises - can decrease their infrastructure costs enormously. They can take advantage of transforming their fixed IT costs into variable costs as a business advantage by focusing on their core business (rather spending time on developing mature software and innovative business models than managing their physical hardware and purchasing costly licenses for rarely used software).

\paragraph{Scalability}
The allocation of cloud resources (for example high capacity storage or computing power) is done in real-time and most cloud infrastructures scale the deployed applications automatically on demand (for example in case of high request rates). This gives cloud users and cloud application providers the option for handling peak load very efficiently without operating their own datacenter and without managing their own infrastructure. For example, load-balancing or the development of high availability solutions for their software does not need to be regarded because it is provided by the cloud implicitly. By deploying their software and data in the cloud, they are automatically able to scale up their business capacities (for example from a few to hundreds of servers) in an instant and on demand fashion.

\paragraph{On-demand}
Allocating cloud resources on a real-time and on-demand basis helps enterprises to scale up their business capacities in an instant and efficient way. The absence of long-term contracts in combination with pay-per-use revenue models allows the low-cost start-up of new ideas for business models. The total cost of ownership (including hardware, software licenses, energy, fail-safety and technical engineers) of self-hosted datacenters minimizes start-up costs and helps enterprises to put new promising business models into the market.

Additional features of Cloud Computing infrastructures are the application of Service Level Agreements (SLA) defining service quality guarantees and contractual penalty clauses if the providers fail to meet the guaranteed service quality goals. Such contracts are important for cost-performance ratio transparency and therefore an essential skill for all kinds of IT and in this sense also IT based geospatial business models.

In essence, Cloud Computing is not a completely new concept. It moreover collects a family of well known and established methods and technologies (for example SaaS as a model for software packaging and deployment and Virtualization as an efficient hosting platform \cite{Sun2009}) under the umbrella of the term Cloud Computing. Besides, it describes a paradigm of outsourcing applications and specific tasks to a scalable infrastructure and therefore consequently enabling new business models with less up-front investments. Keeping in mind that these technologies and general concepts existed in the IT industry for years, the emergence of high network bandwidth and mature virtualization technologies has now enabled this paradigm for a broader audience and leads to new application development models.

There are still a number of open issues for Cloud Computing. One deals with the general barriers of adopting Cloud Computing and is examined for example in the so-called ``Open Cloud Manifesto''. Beside data backup and recovery responsibilities the outsourcing of confidential and economically relevant data from data owners facilities to third party infrastructures is problematic in context of trust. Using public clouds as a deployment platform for applications and services in a risk management scenario is already a security issue in situations when the underlying cloud suffers an outage. But the problems regarding outsourcing of data and reliability of infrastructures are not specific only for cloud infrastructures. They must be addressed for all kinds of distributed architectures.

\subsubsection{Projects and Initiatives}

A lot of enterprise corporations are trying to get into the Cloud Computing business by offering services to access their huge and over years grown infrastructures to the public. Microsoft with the Azure Services Platform \footnote{\url{http://www.microsoft.com/azure/default.mspx}} and its upcoming operating system Windows Azure \footnote{\url{http://www.microsoft.com/azure/windowsazurefordevelopers/default.aspx}} for operating cloud infrastructures, IBM introduced their ``Blue Cloud'' platform \footnote{\url{http://www.ibm.com/ibm/cloud/}} and SUN for example offers Cloud Computing solutions as well \footnote{\url{http://www.sun.com/solutions/cloudcomputing/index.jsp}}. In this chapter we describe the two cloud solutions from Amazon and Google more detailed, showing clearly that cloud providers could realize the different layers and characteristics of a cloud infrastructure at a different level of detail.

The Amazon Web Services (AWS) product is a collection of services that are offering Infrastructure as a Service (IaaS), Datastorage as a Service (dSaaS) and some aspects of Platform as a Service (PaaS). The Amazon Elastic Compute Cloud (Amazon EC2) provides a web service interface to manage virtual machines (IaaS) that are used to host customer specific applications and can be scaled on-demand to handle peak load. The Amazon Simple Storage Service (Amazon S3) provides a web services interface that can be used to store and retrieve large amounts of data (dSaaS). The Amazon Elastic MapReduce is a web service that offers computational power to process efficiently vast amounts of data. It utilizes the Hadoop \footnote{\url{http://hadoop.apache.org/core/}} framework and dynamically distributes data and processing tasks across an automatically scaled cluster of computation nodes.

In contrast of AWS, the Google App Engine is an adequate example for pure PaaS. The Google App Engine provides a sandbox for running Java- and Python-based web applications. The web applications are deployed on the Google infrastructure and so they can take advantage of the same scalable and load balancing technologies that Google applications are built on. On the one hand, the key advantage of Google App Engine over AWS is that Google App Engine offers an easy way of deploying web applications in the cloud. In particular, the overhead of dealing with virtual machines and entire (virtual) server systems could be neglected. The Google App Engine offers also a data storage service (dSaaS) and different bindings to existing Google applications for authentication and accounting. Besides, the free default quota for testing purposes (for example data transfer and CPU time) lowers also the barrier for a first trial experiment. On the other hand, applications deployed in the Google App Engine are restricted to a specific (Java- or Python-based) application framework that runs in a restricted sandbox. This sandbox forbids the creation of threads and the web service request duration is limited to 30 seconds. Furthermore, the Google App Engine platform does not support the MapReduce programming model \cite{Dean2008} or related methods for distributed processing and generating efficiently large data sets. Therefore, the Google App Engine platform is currently not suitable for performing large-scale and time-consuming geospatial processes.

Beside these and other commercial cloud providers, different projects and initiatives drive the general development of Cloud Computing technologies and especially the development of open standards for interoperability in clouds. The Open Cloud Consortium (OCC) \footnote{\url{http://www.opencloudconsortium.org/}} for example is an initiative dedicated to Cloud interoperability and initiated the Open Cloud testbed \footnote{\url{http://www.opencloudconsortium.org/}}. The Open Cirrus Project \footnote{\url{https://opencirrus.org/}} is cloud computing research testbed between research and industry partners. In the Eucalyptus \footnote{\url{http://www.eucalyptus.com/}} initiative, an open source based implementation of the Amazon API is under development.

\subsection{Web Processing Service}

The Open Geospatial Consortium (OGC) Web Processing Service interface specification \cite{OGC2007} describes a standardized method to publish and execute web-based processes for any type of geoprocesses. According to the WPS interface specification, a process is defined as any calculation operating on spatially referenced data. In detail, the WPS interface specification describes three operations, which are all handled in a stateless manner: GetCapabilities, DescribeProcess and Execute. GetCapabilities is common to any type of OGC Web Service and returns service metadata. In case of WPS it also returns a brief description of the processes offered by the specific service instance. To get more information about the hosted processes, the WPS provides process metadata through the DescribeProcess operation. This operation describes all parameters, which are required to run the process. Based on this information the client can perform the Execute operation upon the designated process. As every OGC Web Service, the WPS communicates through HTTP-GET and HTTP-POST based on an OGC-specific XML-message encoding. Besides this basic communication pattern, the WPS interface provides functionality for scalable processing such as asynchronous processing (implemented using the pull model), storing of process results and processing of data references encoded as URLs. The application of URL references as input for specific processes is a promising feature, as it limits the volume of data sent between client and service and allows the service to apply specific caching strategies. The service retrieves the data once and reuses it multiple times, by using the reference as an identifier for data.

\section{Concept}

On a technical level, the classical 52$^{\circ}$North WPS is implemented as a Java Servlet. Due to platform independence gained by Java programming language and the Google App Engine Java support, the WPS components could be easily compiled with a standard Java compiler on a local machine and the resulting package could be deployed on the Google App Engine platform which runs with its own java virtual machine.

As our first test case, we implemented a simple buffer process, which takes two inputs. First, geographic features to be buffered encoded as GML (for example provided by an OGC Web Feature Service, WFS) and second, a distance for the buffer calculation. As a result, geographic features representing the buffers around the input geographic features are computed. The resulting dataset could be fetched either encoded as GML (as exercised with uDig \footnote{\url{http://udig.refractions.net/}}) or KML (as exercised with Google Earth \footnote{\url{http://earth.google.de/}}). According to the number of requests, the deployed application is able to scale up by means of the Google cloud mechanisms. Furthermore, native Google cloud services such as authentication could be used directly in the cloud from the deployed application.

In general, the deployed WPS provides geoprocesses to customer, which is the classical SaaS aspect. This is built on the PaaS aspect, which fosters the automatic scalability.

By deploying the WPS in the Google Cloud, the enduser still is able to find and bind a single URL representing the WPS, even though multiple instance exist on the sever side to maintain a scalable service. Therefore the classical publish-find-bind SDI paradigm \cite{Masser2005} is not modified by using cloud technologies. However, the use of standardized interfaces such as a WPS ensures interoperability from the client perspective, cloud interoperability from a provider perspective is not given, since every cloud infrastructures has its own APIs and requirements.

\section{Scalability Evaluation}

Scalability is one of the key aspects of Cloud Computing. Therefore, we tested our approach and the Google cloud in this direction. We used a stress test to simulate a high demand of simultaneous requests and expected a constant response time by the WPS deployed in the cloud in contrast to a linear rising response time by a non-cloud setting.

\subsection{Methodology}

The WPS was stress tested with the simple buffer algorithm, deployed on the Google App Engine as well as on a local and non cloud enabled Tomcat installation. The geometric data for that process were also delivered via a web service (deployed at the Google App Engine platform in the first case and deployed on the local and non cloud enabled machine in the second case). A cumulative approach was used, starting with 1 and up to 200 requests that were sent simultaneously to the deployed services. The elapsed time from sending the request to receiving the response on its own, as well as for the cumulative sum of the requests/response times was measured. In order to compare the local setting with the remote cloud setting, the results are normalized by only regarding the response time relatively to the maximum/minimum interval of all requests to the specific machine.

\begin{figure*}[t]
   \centering
   \includegraphics[width=\textwidth]{foss4g09/baranski/geoprocessing.jpg}
   \caption{Comparison of normalized response time of remote (blue) and local (red) deployed WPS over number of simultaneously requests.}
   \label{fig:figure2}
\end{figure*}

\subsection{Results}

Figure \ref{fig:figure2}  shows the normalized response time of the online as well as of the local deployed WPS over the number of simultaneously sent requests. The response time of the remote WPS (blue) stays nearly constant up to 200 simultaneous requests whereas the local WPS response time (red) grows linearly.

\subsection{Evaluation}

The performance evaluation shows to some degree that Google App Engine's scale at high request rates, as the response time for many simultaneous requests stays nearly constant in contrast to the non-cloud deployment.

The slight increase of the response time of the WPS deployed at the Google App Engine platform could be explained by some bottlenecks concerning the data allocation from an external server, laborious internal processing steps in the performance testing tool and high traffic at the local machine and in the local sub-network when running the performance testing tool. A slight overhead for replicating new service instances on the server side could also be assumed.

\section{Conclusion and Outlook}

This paper presented and tested an approach of bringing the OGC Web Processing Service to the cloud. On a conceptual level, we showed that Cloud Computing is not a completely new concept and applied to SDI, the classical publish-find-bind pattern does not have to be modified. Therefore, we see a paradigm shift from technological to economical aspects in contrast to a complete paradigm change. On a technical level, our tests showed that by using the Google Cloud, response times could be held almost constant in contrast to a non-cloud approach. However, our tests also showed, that for the cloud approach, bottlenecks outside the cloud have to be taken into account and could eliminate the positive cloud effects if not carefully evaluated. Nevertheless, the tests showed that Cloud Computing keeps its promises and should be regarded further in sophisticated setups.

Thus, we plan in the next evolution phase to extend the described scenario, which mainly incorporates SaaS aspects, towards a more complex scenario, which takes near real-time air quality sensor data, stored already in the cloud (IaaS or dSaaS) and provided through standardized OGC interfaces (for example OGC Sensor Observation Service, SOS), and interpolate these data in the cloud (for example via WPS). Thereby, we aim at keeping the response time constant using efficient (despite possible high request rates). Besides, another goal for the next iteration phase will be the integration of existing Google App Engine services (for example Mail for alerting and Google Accounts for authentication) and efficient methods for distributed processing as well as storing large dataset (for example MapReduce and the Hadoop platform) into the framework.

Nevertheless, the presented approach is to our knowledge the first OGC compliant cloud service ever and could pave the way for a paradigm shift in SDIs. On the basis of our past experience we still believe that Cloud Computing is promising for building up, operating and utilizing SDI in an effortless way and promising for geospatial applications to enable new business models with less up-front investments. Furthermore, Cloud Computing could be potentially the missing element to popularize SDIs to a broader non-expert community (for example in an effortless way by means of Web 2.0 applications, such as mashups, open collaboration, social networking and mobile e-commerce). In particular, we could think of using OGC interfaces as the standardized way for obtaining geospatial resources (data/processing) similar to added-value services already provided in clouds such as Google Mail. However, by using OGC interfaces, cloud interoperability even from a provider perspective in regard to geospatial resources could be gained.

To further advance the adoption and combination of Cloud Computing and SDI, the 52$^{\circ}$North Geoprocessing Community members will continue their basic research by addressing the following questions and topics:

\begin{itemize}
\item How can Cloud Computing lower the barriers for building, operating and utilizing SDIs?
\item How can Cloud Computing promote innovative and promising geospatial e-commerce models?
\item How can Cloud Computing popularize geospatial applications to a broader and collaborating community?
\item How can SDI elements be mapped to the Cloud Computing paradigm?
\item Development and implementation of a fully Cloud Computing enabled SDIs by extending our approach with other Cloud Computing aspects.
\item Security aspects such as Authentication, Authorization, Accounting and Delegation.
\end{itemize}

% ------ your information --------

\address{Bastian Baranski\\
  Research Associate, Institute for Geoinformatics at University of Muenster, Germany\\
  \email{baranski AT uni-muenster.de}\\
  \url{http://ifgi.uni-muenster.de/}
}

\address{Bastian Schaeffer\\
  Research Associate, Institute for Geoinformatics at University of Muenster, Germany\\
  \email{schaeffer AT uni-muenster.de}\\
  \url{http://ifgi.uni-muenster.de/}
}

\address{Richard Redweik\\
  Bachelor Student, Institute for Geoinformatics at University of Muenster, Germany\\
  \email{richard.redweik AT uni-muenster.de}\\
  \url{http://ifgi.uni-muenster.de/}
}

\vspace{2cm}

% ------bibliography ---------

% \begin{bibliographie}
\bibliographystyle{plain}
\bibliography{geoprocessing}
% \end{bibliographie}

\end{article}
