IMPLEMENTING GEOSPATIAL WEB SERVICES USING SERVICE ORIENTED ARCHITECTURE AND NOSQL SOLUTIONS

Transcription

1 IMPLEMENTING GEOSPATIAL WEB SERVICES USING SERVICE ORIENTED ARCHITECTURE AND NOSQL SOLUTIONS Pouria Amirian, Anahid Basiri and Adam Winstanley Department of Computer Science, National University of Ireland, Maynooth ABSTRACT Today a huge amount of geospatial data is being created, collected and used more than ever before. The ever increasing observations and measurements of geosensor networks, satellite imageries, point clouds from laser scanning, geospatial data of Location Based Services (LBS) and location-based social networks has become a serious challenge for data management and analysis systems. Traditionally, Relational Database Management Systems (RDBMS) were used to manage and to some extent analyse the geospatial data. Nowadays these systems can be used in many scenarios but there are some situations when using these systems may not provide the required efficiency and effectiveness. In these situations, NoSQL solutions can provide the efficiency necessary for applications using geospatial data. At the other hand, In order to provide full access to geospatial data, they have to be published as standard-based resources over the Web. In other words, custodians of geospatial data have to publish standard-based services to serve geospatial resources in interoperable and platform-independent manner. In this regard, geospatial services must be designed and developed using Service Orientation Architecture (SOA) to provide full interoperability for diverse kinds of end users. But in this context, nature of geospatial data prevents full potential of using SOA in GIS world. This paper proposes an approach to overcome the mentioned issue using SOA and NoSQL solutions. KEYWORDS NoSQL, Service Oriented Architecture, Geospatial Web Services 1 INTRODUCTION Nowadays geospatial data have become central to the practice of decision makers in private sectors as well as most governmental organizations. The everincreasing access to geospatial data on the Web enhanced system performance through cost/time reduction. Moreover, such access helps decisionmakers to manage their assets better, enables faster responses for time-sensitive decisions, and improves the communication process across diverse agencies. If geospatial data are accessed and shared across diverse partners, different organizations can save time and money by avoiding data reproduction. Also Information exchanges can solve problems relating to inconsistencies and quality differences in the geospatial data from various sources. In this regard, geospatial data should be shared and accessed using standard services which are openly published over the Web. In this context, there are generally two approaches for publishing geospatial data over Web in standard manner. The first approach is to use the specifications published and managed by Open Geospatial Consortium (OGC). The mentioned specifications consist of defined set of request/responses to access geospatial resources (such as metadata associated with geospatial data, image of geospatial data or geospatial data in Geography Markup Language - GML- format). The second approach is to use web services technologies and use the standard messaging and standard interface definition mechanisms. The mentioned standard messaging and standard interface mechanisms are inherent to web services technologies and there is no need to predefine set of request/response in order to exposing geospatial resource over the web. Note that these two approaches are just standard approaches for exposing geospatial resources over the web. There are also other approaches that utilize proprietary and platform-dependant solutions for exposing geospatial resources. This paper focuses on standard approaches. 161

2 The first approach is standard and well supported in Geospatial Information (GI) community. The second approach belongs to the broader and more dynamic Information Technology (IT) community. As it mentioned before the second approach utilizes web services technologies that consists of several technologies such as XML, XSD, WSDL, SOAP as core technologies (or first generation technologies) and many other technologies such as WS-Security, WS-Addressing, BPEL and etc as second generation technologies of web services (or WS-* technologies). These technologies can be used over the web (HTTP) or any other internet protocol providing the necessary quality of service parameter for the system. At the other hand the first approach (using OGC services) limited to web. This is a serious issue in publishing geospatial resources to the users. Although some OGC specification can be defined using core web service technologies, but using core web service technologies for some OGC services cannot be defined in standard manner. As an example Web Map Service (WMS) specification is the most implemented OGC service. It creates image of geospatial data (map in OGC terminology) as response to GetMap request over the HTTP. Since supported data types of web services defined by XSD and there is no native support for binary data in XSD, creating wrapper web service for WMS results in non-standard web service. In addition to the mentioned issue there is another complex and in some situations ill-defined issue for publishing geospatial resources in standard manner. The huge volume of geospatial data is the reason for this issue. Traditionally Relational Database Management Systems (RDBMS) were used to manage and to some extent process the geospatial data. Nowadays these systems can be used in many scenarios but there are some situations when using these systems may not provide the required efficiency and effectiveness. One of these situations is when there is a need to publish a standard geospatial resource that deals with big geospatial data. At the moment a few terabytes of data can be considered as big data. Also in some situations (such as disaster management) when there is a need to use various geospatial data from different sources for fast decision making, the performance of the system (in terms of response time) is very important. In these situations, NoSQL solutions can provide the efficiency necessary for applications using geospatial data. The paper first assesses geospatial services through a so called OGC services framework. Then Service Oriented Architecture and Web services technologies described. Then NoSQL solutions explained briefly and finally the proposed solution will be expressed. 2 GEOSPATIAL SERVICES Nowadays, geospatial services have been considered as the promising technology to overcome the non-interoperability problem associated with current geospatial processing systems [10]. The OGC has defined a comprehensive framework of geospatial services which is known as OGC Web services framework (OWS). The OWS allows distributed spatial processing systems to interact with the HTTP protocol, and provides a framework of interoperability for the many web-based services, such as accessing spatial data services, spatial processing services, and data locating services. The OWS framework consists of interface implementation specification and encodings which are openly available to be implemented by developers [1]. The interface implementation specifications are software technology neutral details about various operations of each geospatial service. The encodings provide the standard glue among different parts of geospatial services. Each service of this framework can be implemented using various software technologies and systems. The most fundamental services and encodings of the OWS framework are Web Map Service (WMS), Web Feature Service (WFS) and Geography Markup Language (GML). GML is an XML-based markup language that is used to encode information about real world objects. In GML these real world objects are called features and they have geometry and non-geometry properties. GML has three main roles with respect to geospatial information. First as an encoding for the transport of geospatial information from one system to another; second as a modelling language for describing geospatial information types; and third as storage format for geospatial information. Typically in any management related tasks (like environmental management, natural resource and so on) one needs to examine and explore data from several sources, use simulation models, develop scenarios, assess impacts, and provide support for decision makers [13]. In this case, use of XMLbased languages for data exchange is an 162

3 improvement on non XML data formats because the XML format is partially self-documenting and provides common methods for parsing files, obtaining their structure and transforming them to alternative formats. GML (as an XML-based language) is well suited for encoding the geospatial information sent to and from geospatial services. GML is used in both the request and response messages of the WFS, which is a standard service for accessing geospatial feature data. As a modelling language, GML provides a rich variety of objects for describing geospatial information, including geospatial features, coordinate reference systems, topology, time, units of measure and generalized values [1]. In addition, using GML spatial and non-spatial relationships among real world objects can be modelled efficiently. As storage format GML is a plain textual file format which can be managed using any database management system. WFS is the main geospatial Web service for publishing and requesting vector geospatial data in GML format. When a client sends a request to an OGC WFS, the service sends a response message that provides geospatial feature data in GML. Three classes of Web Feature Services are defined in the WFS implementation specification: Basic WFS, XLink WFS and Transaction WFS [13]. A Basic WFS service implements three operations: GetCapabilities, DescribeFeatureType and GetFeature. A client can request an XML-encoded capabilities document (containing the names of feature types that can be accessed via WFS service, the spatial reference system(s), the spatial extent of the data and information about the operations that are supported) by sending the GetCapabilities request to the WFS service. The purpose of the DescribeFeatureType operation is to retrieve an XML Schema document with a description of the data structure (or schema) of the feature types served by that WFS service. The GetFeature operation allows for the retrieval of feature instances (with all or part of their attributes) as GML. An XLink WFS supports all the operations of basic WFS and in addition it would implement the GetGmlObject operation for local and/or remote XLinks. A Transaction WFS supports all the operations of basic WFS and in addition it implements the transaction operation. A transaction request is composed of operations that modify features; that is create, update, and delete operations on geospatial features. The WMS enables maps in graphical form to be delivered in response to queries from HTTP clients (any desktop or Web application which is connected to World Wide Web) [4]. In the context of WMS a map is a raster graphic picture of the data rather than the actual data itself. Clients request maps from a WMS instance in terms of named layers and provide parameters such as the size of the returned image as well as the spatial reference system to be used in drawing the map. In this way, a client application can make requests to different WMS instances and the results can be overlaid to form a rich layering of map information based on the transparency capability of WMS instances. The WMS specification standardizes two mandatory operations by which maps are requested by clients: GetCapabilities and GetMap. The purpose of the GetCapabilities operation is to obtain service metadata, which is a machine readable (and also human-readable) description of the server's information content and acceptable request parameter values. The GetMap operation returns a map whose geospatial and dimensional parameters are well defined in the GetMap request. The GetMap request allows the WMS client to specify distinct layers, the spatial reference system, the geographic area, and other parameters describing the returned map format. 3 SERVICE ORIENTED ARCHITECTURE AND WEB SERVICES TECHNOLOGIES Service orientation is the core concept in SOA. Service orientation is a trend in software engineering that promotes the construction of applications based on entities called services [5]. SOA as a conceptual architecture is adopted today by many businesses as an efficient means for integrating enterprise applications built of Web services [3]. Services in an SOA are modules of business or technical functionality with exposed interfaces to the functionality [11]. SOA is frequently characterized as a style that supports loose coupling, business alignment and Web-based services, which permits extensibility and interoperability independent of the underlying technology [11]. It provide a set of guidelines, principles and techniques in which business processes, information and enterprise assets can be effectively (re)organized and (re)deployed to 163

4 support and enable strategic plans and productivity levels that are required by competitive business environments [8]. In SOA, the central elements are services. In many respects, a service is the natural evolution of the component, just as the component was the natural evolution of the object. Services are autonomous, platform-independent computational elements that can be described, published, discovered, orchestrated and programmed using standard protocols for the purpose of building networks of collaborating applications distributed within and across organizational boundaries [5]. The actual implementation of SOA using open, standard and widely used protocols and technologies is called Web services [5]. Web Services are the basic components of serviceoriented solutions. The World Wide Web Consortium (W3C) defines Web Services as a software system designed to support machine-tomachine interaction over the Internet. Each Web service has an interface described in a machine-processable format. Other systems and services interact with the Web service in a manner described by its description using messages. Messages are conveyed typically using HTTP with an XML serialization, in conjunction with other Web-related standards, but any other communication protocol can be used as well [3]. Web services are based on open standards, so they provide interoperability in decentralized and distributed environments like Web. These technologies can be developed by using any software platform, operating system, programming language and object model. Web services are implemented using a collection of standards and technologies. SOAP and WSDL 1 form the core technologies for implementing Web services [5]. SOAP is a lightweight, XML-based protocol for exchanging information in decentralized and distributed environments. SOAP is used for messaging among various SOA s components in a Web services platform. SOAP is platform independent and also it can be used with virtually any Network Transport protocols such as FTP 2, HTTP and HTTPS3. WSDL is XML-based specification for describing the capabilities of a service in a standard and 1 Web Service Description Language 2 File Transfer Protocol 3 Secure HTTP extensible manner. Technically, WSDL defines the software interface of Web service in platform independent approach. 4 PROVIDING SERVICE LAYER ON TOP OF GEOSPATIAL SERVICES In order to provide full potential of share and accessibility for geospatial data, a standard based service layer must be designed and deployed on top of geospatial services. In other words since geospatial services and their corresponding Web services are not directly compatible, additional layer (service layer) should be added to provide compatibility between two kinds of services. The main reason for the additional service layer is the lack of standard and native support for binary data in web services technologies. Web Services uses SOAP messages to communicate with each other. OGC services use the specific request and response formats. All OGC services request data using URLencoded parameters in HTTP request or in XML messages. Both methods can be changed to SOAP messages using a simple wrapper solution. The difficulty arises in creating response messages when raw binary data must be retrieved from an OGC service (like an image of geospatial data from WMS). Since Web services use XML as the primary encoding of communication they are restricted to the predefined set of data types which are specified in XSD standard. In general, there is no support for binary data in XSD data types. There are various solutions for the mentioned issue. Amirian, et al. [1] proposed four different approaches to overcoming this issue: translator web service, physical address web service, wrapper web service and common backend. All these approaches and their advantages and disadvantages are explained in [1]. Through these four approaches one of them (common backend) is more flexible, extensible and more inline with service orientation. For this reason this research tries to enhance the common backend approach and utilize the mentioned approach for high-performance publishing of huge volume geospatial resources. As it mentioned in [1], the common backend approach is based on shared set of component to access and process geospatial data. On top of the shared backend components system can provide two types of service: OGC service and web service. web service is able to handle binary geospatial data using various solutions. For example binary data 164

5 can be encoded using Base64 or BinHex encodings. Using Base64 or BinHex, binary data can be encoded to ASCII characters and then included in any XML document like SOAP messages. In this case, the web service encodes retrieved data from common backend components and returns SOAP response to the client. The client must then decode the base64 or BinHex data before using it. There are also some other approaches for attaching binary data to SOAP message. A more efficient approach is to use DIME (Direct Internet Message Encapsulation) to send large binary data. DIME is a message-based encapsulation protocol which leverages SOAP headers in a streamlined message encapsulation process. DIME enables a Web service to efficiently send and receive attachments with SOAP messages. These attachments might be binary files, other SOAP messages, XML fragments, or even other DIME messages [9]. When using Base64 or BinHex encodings, the processing on client and Web service gets complicated and time-consuming when attachments are very large. It is proved that base64 encoded data increase the size of binary data by a factor of 1.33, and that BinHex encoded data expands by a factor of 2. DIME protocol describes a mechanism for sending one or more attachments external to the SOAP message. By keeping the attachments and the SOAP message separate, processing load can be decreased dramatically. Also, given the nature of parsing a SOAP message, the entire message needs to be read into memory before any internally included data decoded and used which for large binary means using plenty of memory on client and Web service sides. Using DIME, on the other hand, an XML parser can read the SOAP header to locate SOAP message or specific attachments without loading the whole message, thus providing a better performance and scalability. The better solution for transmitting binary data using SOAP messages is utilizing Xml-binary Optimized Packaging (XOP) with SOAP Message Transmission Optimization Mechanism (MTOM) [5]. The purpose for using MTOM is to optimize the transmission of a SOAP message by selectively encoding portions of the message, whilst still presenting an XML Infoset to the SOAP application [5]. In other words, using MTOM is utilized to optimize the transmission of large binary message contents while keep it in accordance with other Web services technologies. MTOM is able to transmit binary data as raw bytes, saving the encoding/decoding time and resulting in smaller messages. MTOM provides a better approach in comparison with DIME. When using DIME, data is external to the SOAP message and is not a part of the message Infoset. As a result, layered technologies for processing and describing SOAP need to provide one set of solutions for the XML component of their SOAP message and another set of solutions for the external data which is referenced in the message. This not only complicates all the entities working with such messages, but also brings interoperability issues because no standard model governs how SOAP intermediaries process the referenced data. In addition, if there is a need for using second generation of web services technologies like WS- Security, there will be some incompatibility issues since existing technologies such as XML signature and encryption were not really designed with such referenced data in mind. With MTOM, any specific Web service requirements, such as the use of Security and Reliable-messaging can be utilized. In contrast to DIME, since becoming W3C standards in 2005, XOP and MTOM have been quickly and widely adopted in next-generation SOAP engines [11] and [3]. As a result, the best choice for packaging response from enhanced web service that handle binary geospatial data is to utilize MTOM to transmit binary data in SOAP messages. So the issue with all these solutions is how to specify the encoding approach for client in order to make it able to decode the binary geospatial data in standard manner? This paper propose to use the standard elements of soap to make it self sufficient. In other words, the SOAP message itself, tells the encoding of the binary data through header element (<soap:header>). The optional SOAP header element contains application-specific information (like security, policy, etc) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element. Following figure illustrates the use of header element containing image data (response to WMS) in base64 encoding. 165

6 Figure 1. Structure of SOAP response for enhanced web service As it is shown in the above figure the po:enc element specifies the encoding of the content of the body of SOAP message. The soap:mustunderstand attribute is used to indicate that understanding of this element (po:enc element) is necessary for client of this service in order to process the response. If the consumer of enhanced web service does not recognize the po:enc element it will fail when processing the Header. Using this approach publishing binary geospatial data using web service technologies in a standard manner would be possible. As it mentioned previously, in order to handle huge volume of geospatial data, NoSQL databases provide efficient approach. 5 WHY USE A NOSQL DATABASE FOR MANAGEMENT OF GEOSPATIAL DATA? It has been more than thirty years since relational DBMSs became the major solution for storing all kinds of data in many types of applications. They manage data using relational algebra and relational calculus as their theoretical foundation. They use tables, relationships, keys and Structured Query Language (SQL) to perform all sorts of functions with data. They usually are the best solutions when the schema of data is fixed and predefined. In other words, RDBMSs are ideal solutions to managing structured data. RDBMS can be effectively used in many common GIS workflows. Since they support transaction and locking features, they provide robust backend for enterprise GIS systems. Usually geospatial data have a fixed schema and in most cases they are not used in isolation. That is a join of two or more datasets and connecting data through spatial operations is needed in most GIS workflows. For this reason managing fixed schema geospatial data and using them in GIS workflows can usually be done effectively through RDBMS systems. How ever, today unstructured and semi-structured data are becoming mainstream. Observation and meas urements from diverse kinds of sensors, geos patial data of Location Based Services (LBS) and social networks are three examples of semistruc tured and unstructured data in the geospatial worl d. In addition, there are also some methods that gener ate massive geospatial data, for example remote sensing (RS) and laser scanning. In some situations when high availability and scalability is needed, RDBMSs provide very expensive solutions for managing such data even if it has a fixed schema. For example, in an Automatic Vehicle Location (AVL) application, an RDBMS cannot easily handle the possibly massive read and write operations. In these situations NoSQL databases can provide a highly accessible and scalable way of managing semi-structured or unstructured geospatial data. In addition, some problems arise with RDBMS systems when scalability is needed by adding more servers and technologies to bind them together. With more loads on the RDBMS system, vertical partitioning, denormalization and removal of the relational constraints comes into play. In summary, to achieve high scalability in RDBMS systems the normalized relational model of data storage has to be compromised and deviated from relational model. 6 WHAT IS A NOSQL DATABASE? The NoSQL DBMSs are a broad class of DBMSs identified by non-adherence to the RDBMS model. In general, the most significant difference is the lack of SQL. There are different types of NoSQL databases, each with distinct set of characteristics but they all can deal with large amounts of (semistructured and unstructured) data and are able to support a large set of read and write operations. For this reason NoSQL and relational models are not in contrast with each other rather they complement each other. The most widely accepted taxonomy of NoSQL databases are: key-value, document, tabular or columnar and graph [12]. The key-value database is the simplest type of NoSQL databases. As the name implies, this type of database stores schema-less data using keys. The key is usually a string and the stored values can be 166

7 any valid type such as a primitive programming data type (string, integer etc) or a BLOB (Binary Large Object) without any predefined schema. It provides a simple API to access stored data [6]. In most cases, this type of NoSQL database solution provides very little functionality beyond key-value storage. There is no support for relationships [14]. In terms of concurrency, they usually provide eventual consistency but don t provide optimistic concurrency especially in highly scalable environments. Queries are just limited to accessing values using keys but since there is one request to access the value, the queries are executed quickly. Transactions are limited to a single key. The database contains no semantic model. In other words, the client is in charge of interpreting and understanding values. Key-value databases can be utilized to store geospatial data but their complexity hinders spatial searches especially for polylines and polygons. For this reason, it needs to be spatially indexed for fast data retrieval which, in most cases, gives lower performance than a relational database. Many researchers and developers recommend using indexing techniques such as grids or tiles, quadkeys, space filling curves and similar approaches. In summary, key-value data stores are ideal for inserting, deleting and searching huge amount of data items using their unique identifiers (keys). If spatial searches are needed however they are not good solutions. A document database in its simplest form is a keyvalue database in which the database understands its values [7]. In other words, values inside the database are based on predefined formats such as XML, JSON or BSON (Binary JSON). This feature of document databases provides many advantages over key-value databases. Instead of putting too much logic in the application tier, many operations can be done by the database itself. Queries in this type of NoSQL databases are quite flexible and some document databases even have their own query languages. Similar to key-value databases, there is no need to adhere to a predefined schema to insert data. There is only limited support for relationships and joins as each document is stand alone. However, more concurrency options, such as optimistic concurrency and eventual consistency are available [2]. Transaction integrity is supported for one document or document fragment. The document databases can be used for managing geospatial data more effectively than key-value databases. Since geospatial data inside the document database can be retrieved using flexible queries, they can be used for storing and managing geospatial data in multiple use cases. In fact many document databases support geospatial data natively or through extensions. Some applications of LBS such as proximity queries can be efficiently implemented using these document databases. As mentioned before, relationships and joins are not supported the way they are supported in relational databases. Often in common GIS workflows relationships and joins have to be used. Special kinds of document database can partially handle relationships. Native XML databases can be configured to enforce adherence to set of predefined XML schemas. In addition to all the advantages of document databases, native XML databases are able to utilize many XML technologies to provide further functionality. For example, they can use XQuery and XPath to perform various queries and create flexible result sets, they can make use of XPointer to reference other documents thus modelling a relationship and they can use XSD and RelaxNG to enforce schema validation. Geography Markup Language (GML), as a standard mechanism for storing, modelling and exchanging geospatial data, is an XML-based grammar and so Native XML databases are an ideal choice for managing geospatial data in GML format. The tabular or columnar (or column family) database stores data in columns. This is in contrast to the row-oriented format in relational databases [12]. The column is the smallest unit of data and it is a triplet that contains a key, value and timestamp [7]. Columnar databases store all values beside the name of the columns and stores null values simply by ignoring the column. Usually, related columns compose a column-family. All the data in a single column family will be stored on the same physical set of files [14]. This feature provides higher performance for search, data retrieval and replication operations. A super column is a column that contains other columns but it cannot contain other super columns [7]. Most columnar databases use a distributed file-system to store data to disk and so provide a horizontally scalable system. In fact columnar databases are designed to run on a large number of machines. Queries in this type of NoSQL databases are limited to keys and in most cases they don t provide a way to query by column or value. By limiting queries to just keys, columnar 167

8 databases ensure that procedure to find the machine containing actual data is quite fast. There is no join capability and, as in other types of NoSQL databases, there is limited support for transactions. Columnar databases are ideal for storing huge amounts of data when high availability is needed. Similar to document databases, there are many columnar databases which support the management and simple analysis of geospatial data. Any GIS related application which needs heavy data insertion and fast data retrieval with simple queries can efficiently make use of columnar databases. As an example, an Automatic Vehicle Location (AVL) application which needs to track the location of many vehicles simultaneously can store the incoming data from vehicles in a columnar database and respond to queries efficiently. As the name implies graph databases are based on graph theory and employ nodes, properties and edges as their building blocks. In the graph databases various nodes might have different properties. The graph databases are well suited for data which can be modelled as networks such as road networks, social networks, biological networks and semantic webs. Their main feature is the fact that each node contains a direct pointer to its adjacent node and no index lookups are necessary for traversing data. As a result they can manage huge amount of data as long as the data do not require expensive join operations. Some of graph databases support transactions in the way that relational databases support them. In other words the graph database allows the update of a section of the graph in an isolated environment, hiding changes from other processes until the transaction is committed. Geospatial data can be modelled as graphs. Since graph databases support topology natively, topological relationship between geospatial data can be easily managed by this type of NoSQL databases. In most GIS workflows, topological relationships play a major role. In addition, since graph databases are ideal for managing data with evolving schema, they can be effectively used in Volunteered Geographic Information (VGI) and crowd sourcing applications. Also, graph databases are the best choice for managing huge linear networks (such as roads) and for routing and navigation applications. 7 PROPOSED ARCHITECTURE FOR IMPLEMENTING GEOSPATIAL WEB SERVICES Figure 2, shows the architectural view of proposed solution for implementing geospatial Web services using SOA and NoSQL database. This architecture consists of four layers: user layer, services layer, business logic layer and data layer. The data layer consists of geospatial data that are stored in a NoSQL database. In this research MarkLogic NoSQL database was utilized to store and manage geospatial data in XML format. The MarkLogic database uses XML documents as its data model, and stores the documents within a transactional repository. In other words, it can be considered as native XML database. The business logic layer consists of several components for parsing requests, accessing geospatial data and drawing maps. When client send a request to a service such as WMS to get a map of certain area, request will be parsed using parser component then required geospatial data retrieved using data access component and then map will be built using drawing component. Finally the parser component again is utilized to creating an appropriate response. If the request is in the form of OGC specification, the map will be simply sent to the client over HTTP. If the request is in the form of SOAP request, the created map will be encoded to an appropriate encoding (such as base64 or MTOM) and then the encoded data will be put inside the body of the SOAP response. In the later case, the header of the SOAP response specifies the encoding. As it shown in the figure 2, the service layer includes OGC Services and enhanced web services. The OGC services provide access to geospatial resources using OGC specification. As it mentioned earlier the enhanced web services provide more flexibility to accessing geospatial resources. Because it is possible to make use of any WS-* (second generation web services technologies) specifications in this solution, it is possible to enrich the communication between client and service and provide security, addressing and orchestration. This way the SOAP response containing geospatial data become more intelligent and it would be possible to implement complex geospatial workflows. The user layer consists of software which is used by users to connect to service layer. It can be desktop, server, developer or mobile software. 168

9 9 REFERENCES Figure 2. Proposed Architecture of the geospatial web services 8 CONCLUSIONS In this paper an approach for implementing geospatial web service using SOA and NoSQL databases was explained. As it mentioned in the paper in order to provide access to geospatial resources in efficient and standard manner there are generally two issues: huge volume of geospatial data and limited capabilities of OGC services to provide self sufficient messages containing geospatial data. The proposed solution provides geospatial resources through interoperable services which can be consumed using various kinds of message exchange patterns for different kinds of clients. Although OGC services and Web services technologies are not directly compatible, in this research by adding a service layer a data type handling issue were resolved. It is worth mentioning that, as a result of utilizing the proposed approach, services in this solution can be used as efficient composition member in geospatial workflows (in GI community) and orchestration or choreography (in IT community). In addition using NoSQL databases provide ability to manage huge amount of geospatial data in efficient manner. 1. P. Amirian, A. A. Alesheikh, A. Basiri. Standardbased, interoperable services for accessing urban services data, Computer Environment and Urban Systems, 34 (4), , (2010). 2. F. Chang, J. Dean, S. Ghemawat, W. Hsieh, R. Gruber. Bigtable: A distributed storage system for structured data. Seventh symposium on operating system design and implementation, (2006). 3. R. Daigneau. Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services, Addison-Wesley (2011). 4. J. dela Beaujardiere. OpenGIS Web Map Server Implementation Specification version 1.3, (2006). 5. T. Erl. SOA Principles of Service Design, Prentice Hall PTR (2008). 6. M. Fowler, P. Sadalage. NoSQL distilled: a brief guide to the emerging world of polyglot persistence, Addison-Wesley publication, (2012). 7. R. Hecht, S. Jablonski. NoSQL Evaluation A Use Case Oriented Survey, International Conference on Cloud and Service Computing, , (2011). 8. J. Lawler, B. Hawel. Service Oriented Architecture: SOA strategy, Methodology and Technology, Taylor & Francis Group (2008). 9. E. Murakami, A. M. Saraiva, L. J. Ribeiro, C. E. Cugnasca, A. R. Hirakawa, P. L. Correa. An infrastructure for the development of distributed serviceoriented information systems for precision agriculture, Journal of Computers and Electronics in Agriculture Volume 58, May 2007, (2007). 10. J. Sample, K. Shaw, S. Tu, M. Abdelguerfi. Geospatial Services and Applications for the Internet, Springer Science+Business Media, LLC, 233 Spring Street, New York, NY 10013, USA (2008). 11. G. Schmutz, P. Welkenbach, D. Liebhart. Service Oriented Architecture: An Integration Blueprint, Packt Publishing (2010). 12. S. Tiwari. Professional NoSQL, Wrox publication, (2011). 13. P. A. Vretanos. OpenGIS Web Feature Service 2.0 Interface Standard, OGC r1 and ISO/DIS (2010). 14. P. Xiang, R. Hou, Z. Zhou. Cache and consistency in NoSQL. 3rd IEEE international conference on computer science and information technology, , (2010). ACKNOWLEDGEMENTS Research presented in this paper was funded by a Strategic Research Cluster grant (07/SRC/I1168) by Science Foundation Ireland under the National Development Plan. The authors gratefully acknowledge this support. 169