12th AGILE International Conference on Geographic Information Science 2009 page 1 of 10 Leibniz Universität Hannover, Germany

Description
12th AGILE International Conference on Geographic Information Science 2009 page 1 of 10 INSPIRE-able Services Aneta J. Florczyk, Francisco J. López-Pellicer, J. Valiño, R. Béjar, and P. R. Muro-Medrano

Please download to get full document.

View again

of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information
Category:

How To, Education & Training

Publish on:

Views: 10 | Pages: 10

Extension: PDF | Download: 0

Share
Transcript
12th AGILE International Conference on Geographic Information Science 2009 page 1 of 10 INSPIRE-able Services Aneta J. Florczyk, Francisco J. López-Pellicer, J. Valiño, R. Béjar, and P. R. Muro-Medrano Department of Computer Science and Systems Engineering University of Zaragoza Maria de Luna 1, 50018, Zaragoza, Spain {florczyk, fjlopez, juanv, rbejar, ABSTRACT The INSPIRE services network architecture establishes rules for the architectural model of the European Spatial Data Infrastructure. Each Member State of the European Union should create new services or adapt existing ones according to the Implementing Rules derived from the INSPIRE directive. A INSPIRE Drafting Team is responsible for the definition of the INSPIRE Implementing Rules which include technical specifications that define a common contract for the operation interfaces, data description and representation. The INSPIRE directive advises to use the existing standards. The OGC standard family is being considered by the drafting team. The Word Wide Web Consortium (W3C) suggestion to use the SOAP messaging protocol for Web Services is also being taken into consideration. This paper proposes the application of well-known design patterns for the adaptation of INSPIRE-unconformable Services (non INSPIRE compatible Services). However, there are several challenges. It does not exist a methodology that facilitates building wrapper services. What is more, the services provided by Member States and offered at state level are not restricted by the INSPIRE Implementing Rules. Nevertheless, the application of the INSPIRE Implementing Rules at levels below the European one (e.g. at Member State level), should decrease significantly the complexity of the development of an application based on the INSPIRE infrastructure. Similarly, applying patterns to any existing service, including commercial ones, would allow transforming this service into an INSPIRE-able Service that would facilitate the creation of any INSPIRE-based application. Key words: INSPIRE, service pattern, SOA, OGC, SOAP INTRODUCTION The European Union directive named INSPIRE [INSPIRE Directive 2007/2/EC, 2007] establishes an Infrastructure for Spatial Information in the European Community (INSPIRE). The INSPIRE Network Service Architecture Draft [Network Services Drafting Team, 2008] introduces a two-level architecture compound of (1) the Member State (MS) and (2) the European Union level. Each Member State has to provide the basic services through the Member State access point. These INSPIRE Services have to conform with the INSPIRE Network Service Definitions included in the Implementing Rules defined by the INSPIRE Drafting Team. The INSPIRE Services will be used by the INSPIRE geo-portal and any application or user accessing them directly at European Union level. However, there are not any requirements about those services provided by the public authorities at the Member State level. To avoid the necessity to create new services by the Member States to fulfil the INSPIRE requirements, the INSPIRE Network Service Architecture Draft has proposed the use of a facade component to allow already existing non INSPIRE compatible Services to participate in the EU level architecture. Figure 1 illustrates the use of a facade component as an additional layer between non-inspire compatible Services of Member State level and EU level users. 12th AGILE International Conference on Geographic Information Science 2009 page 2 of 10 Figure 1: Service Network Service Definitions as a mediator between Member States INSPIRE and non-inspire Services and EU level users. The INSPIRE Architecture follows the Service Bus pattern which supports a Message-Oriented Architecture. This architecture permits the integration of heterogeneous systems, and the interoperability of legacy and new systems. This approach interconnects applications independently of their underlying technology. Nevertheless, the Network Services Architecture Document [Network Services Drafting Team, 2008] has recommended the usage of one binding technology: INSPIRE services should utilize one standard technology binding for all service types. In order to streamline integration and implementation as well as getting a maximum benefit from the offered services, a mix of technologies is to be avoided. According to the World Wide Web Consortium (W3C) recommendations to use SOAP as a messaging protocol for Web Services: the default communication-protocol and binding technology for INSPIRE services should be SOAP (document/literal) [Network Services Drafting Team, 2008]. This, and other complementary aspect to SOAP, such as WSDL or UDDI, have been studied by a JRC survey about SOAP HTTP binding status[villa, 2008], and then developed in the technical report on the INSPIRE Network Services SOAP Framework [Villa et alt., 2008]. As the authors state, this first version of a SOAP framework is only the first step towards its potential endorsement by the INSPIRE stakeholders. Although the Network Services Drafting Team does not propose any technical specification at this moment, the recently published technical reports suggest the probable choice of the SOAP framework as the solution. The Network Services Drafting Team is also responsible for the Implementing Rules (IRs) definition. The IRs identify the OGC standards as the preferred in most cases for implementing new services or adapting existing ones (see Table 1). However, other standards may be used as long as they conform to the Implementing Rules. Although existing OGC specifications are not compliant with SOAP protocol [Villa, 2008], OGC teams are working on the use of WSDL/SOAP [Schäffer, 2008, Sonnet, 2003, Sonnet, 2004]. OGC assessment envisions that the usage of SOAP bindings, instead of relying only on HTTP, will allow a smooth and complete integration in development environments, and a full integration with Web Services environments (WSDL, UDDI, etc). Moreover, the definition of a common SOAP header allows INSPIRE Services to support requirements from horizontal services (e-commerce, georm). 12th AGILE International Conference on Geographic Information Science 2009 page 3 of 10 Service Type View Service Discovery Service Downloads Service Transformation Service Invoke Spatial Data Service OGC Standard recommendation OGC:WMS OGC:CSW OGC:WFS, OGC:WCS OGC:WCTS OGC:WPS Table 1: INSPIRE Implementing Rules recommendations. The applications based on the INSPIRE architecture may need to use services from MS level that are INSPIRE-unconformable. In this paper, the term INSPIRE-unconformable Service means a service that is provided by a public authority, which does not satisfy the IRs due to the usage of a different interface or because it is a legacy system. Integration of such services into the IRs-based applications will require the development of an ad-hoc adapter. Also, ad-hoc adapters will be required in case of non-inspire Services, for example commercial services (as illustrated by Figure 2). Several well-known design patterns may facilitate building up a mediator layer between the INSPIRE Service Bus and the non-inspire and INSPIRE-unconformable Services. This approach could bring a significant decrease in the integration costs. Figure 2: Relation among INSPIRE-unconformable and non-inspire services. In this paper the adapted INSPIRE-unconformable Service will be named the INSPIREconformable Service. The mediator service required for the adaptation will be named the INSPIREconformable mediator. In the case of a non-inspire Service, the resulting service will be referred to as the INSPIRE-able Service and its mediator service the INSPIRE-able mediator (see Figure 3). 12th AGILE International Conference on Geographic Information Science 2009 page 4 of 10 Figure 3: The INSPIRE-conformable, the INSPIRE-able and the INSPIRE Services. The rest of this paper is organized as follows. After the introduction, the second section presents the state of the art in the architecture for distributed systems development on the World Wide Web. The third section briefly describes the increase in the availability of Spatial Web Services which has occurred during the last years. Next, the design patterns proposed to adapt services are presented, and the method of service adaptation is explained with a practical case of the GoogleGeocoder Service. Finally, some conclusions are drawn and future work is outlined. STATE OF THE ART The INSPIRE Network Service Architecture Draft [Network Services Drafting Team, 2008] proposes a distributed network-based architecture for interoperable applications dealing with spatial information, realized on the Web technology platform. Currently, there exist two principal architectural patterns that provide support for distributed network-based systems: Resource Oriented Architecture (ROA) and Service Oriented Architecture (SOA). Both of them define the interaction mechanisms and interfaces to access the components of a distributed system through the network. ROA is focused on distributed resources and SOA is focused on distributed services. Identifying a pure SOA-based application is quite difficult because the majority of services accessible via Web which identify themselves as SOA-based, are classified by some authors into (1) Big Web Services [Pautasso, 2008], based on the SOA paradigm, and (2) RESTful Web Services [Fielding, 2000, Richardson, 2007], based on the ROA paradigm, sometimes loosely. Resource Oriented Architecture (ROA) The Resource Oriented Architecture (ROA) emerged first as the Representational State Transfer (REST) architectural style, presented in [Fielding, 2000]. This is an idealized model of interactions within the World Wide Web, which considers the Web as a world-size distributed hypermedia system. The fundamental elements of this approach are the concept of resource, and the stateless interactions grounded on the transfer of resources representation [Fielding, 2002]. 12th AGILE International Conference on Geographic Information Science 2009 page 5 of 10 Service Oriented Architecture (SOA) An alternative for the development of distributed systems is the Service Oriented Architecture (SOA). SOA is the core element of the Service-Oriented Computing (SOC) [Erl, 2007]. SOC is a computing paradigm [Papazoglou, 2006] that represents a new generation of distributed systems and promises development cost reduction, even in heterogeneous environments. The broad use of terms service-oriented architecture and SOA in media and vendor marketing literature has resulted in misunderstanding SOA as synonymous of service-oriented computing platform. According to the platform-independent definition of Thomas Erl, SOA is a term that represents a model in which automation logic is decomposed into smaller, distinct units of logic [Erl, 2005]. These units of logic are encapsulated in the form of reusable services whose functionality is provided via interfaces [ISO/TC 211, 2003]. These services reflect the service-oriented design paradigm where each new application is based on the composition of services. Thus, SOA is designed to support the implementation of services and service composition, and provides mechanisms for service publishing, discovering and invocation over the network (see Figure 4). The main principles of SOA are loosecoupling, protocol independence and the use of standards. Figure 4: SOA principal interactions. Web as the Global SOA Web principles such as distribution, openness, interoperability or user-orientation contribute in settling the Web Services platform as the most popular technology platform that implements the SOA paradigm nowadays. The Web Services platform is characterized by its diversity. There are numerous standards and specifications supported by different vendors and communities. Two basic integration styles exist within the Web Services platform. They are the message-based and RPC-based styles. The message-based style might be divided into two generations depending on the standards and specifications used: First-Generation Web Services Platform and Second-Generation Web Services Platform [Erl, 2007]. The first one is based on WSDL, SOAP, UDDI and the WS-I Basic Profile. The second generation platform involves WS-* and intends to fulfil the necessity to define quality-ofservice levels by setting up standards for message-level security, cross-service transactions, and reliable messaging. This division does include only the SOAP-based Web Services, the so-called Big Web Services [Pautasso, 2008]. It is important to stress here the importance and popularity of the services loosely based on REST principles, the so-called lo-rest [Pautasso, 2008] (or weak-rest [Lucchi, 2008]) services, which follow the RPC-style. This type of services is the most common within the Web 2.0 programming style that supports the so-called mashups [Domingue, 2008]. Recently, RESTful services [Richardson, 2007] have become popular as an approach to integrate applications within the Web Services platform. This approach is based on the Resource Oriented Architecture. They are suggested as best suited for basic, ad-hoc integration scenarios compared to the Big Web Services, which are more appropriate for enterprise computing. 12th AGILE International Conference on Geographic Information Science 2009 page 6 of 10 SPATIAL WEB SERVICES AND INSPIRE The INSPIRE-based applications will take advantage of the existing Web Services to develop different functionalities. Nowadays, in the context of the spatial data services, there are many initiatives that arise from open communities and enterprise suppliers (see Figure 5). The open communities are characterized by the large amount of participants that take part in the service creation, and/or the spatial data production, which gives ground to a new phenomena known as neogeography [Satyaprakash, 2008]. As a result, the open communities provide many free but adhoc services characterized by simple data models and not always appropriate for the complexity of their task. As an alternative, the commercial suppliers are distinguished by their access to economic resources, which implies the availability of human resources as well. This muscle is shown in the number of commercial services and dedicated solutions available on the market. Other stakeholder is the geospatial community. In response to the need of open standards for spatial data, the consortium of companies, government agencies and universities that is the Open Geospatial Consortium (OGC), establishes service specifications for spatial applications. Another stakeholder that participates in the Spatial Web Service platform is the Semantic Web community. They provide Geospatial-aware Semantic Web solutions as DBpedia [Becker, 2008]. Figure 5: SOA Web in context of spatial data. The variety of Web Service invocation styles, interfaces, etc., is the cause of a integration scenario that is characterized by the heterogeneity of the technological approaches. Thus, the technological integration of different services may be rather complex and may require multiple adhoc adapters. The approach of using ad-hoc adapters is not the best solution for an INSPIREconformed wrapper service. Publishing a set of generic, preconfigured or run-time adaptable mediators in the INSPIRE bus registry, following well-known patterns seems a more suitable approximation. PATTERNS FOR SERVICE INTEGRATION The Member States have to provide the INSPIRE Services via a MS access point. The Network Services Drafting Team defines the Implementing Rules to be conformed with by the INSPIRE Services. Additionally, the recently published technical reports consider the SOAP framework. Taking into account the variety of technological solutions used by Member States to provide their services, and the heterogeneity of Web Services, both commercial and free, the existing services may be adapted by creating a mediator service rather than creating a new one involving possibly greater costs. The mediator service could be seen as an additional cost. However, depending on each case (for example, if the existing service is provided by a third party), the service owner might find this approach profitable. 12th AGILE International Conference on Geographic Information Science 2009 page 7 of 10 Depending on users needs to implement these mediator services one of the following design patterns might be used: adapter or façade. The adapter pattern allows the user to access to functionality of an object via known interfaces and/or adopting message channel [Gamma, 1994, Hohpe, 2003,]. In the majority of cases, the mediator service will implement this pattern to encapsulate the invocation of the original service according to INSPIRE SOAP binding requirements. In addition, it may hide the logic of multiple requests or error handling. The façade pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. [Gamma, 1994]. In terms of services, this approach addresses subsystems which combine several services and allows for concealing their logic. Method In this paper we propose a method for service integration into the INSPIRE Service Bus by applying the adapter design pattern to the creation of a mediator service. The implementation of a mediator service requires the identification of the source service (the adaptee service) and the functionality which should be reflected by the target service. The first step of the proposed method is the selection of an INSPIRE-unconformable or non-inspire service to be adapted to the INSPIRE Service Bus (see Figure 6). The INSPIRE Services and their data should be described using metadata according to the Implementing Rules for Metadata. In accordance with those requirements, it has been defined a simple metadata template. This template should be filled with the available documentation of the chosen service. Although this might sound rather straight, in practice is not so simple. Popular Web Services (e.g. Google, Yahoo families) lack in standardized documentation. Commonly, they only provide human-readable documents, an API, or sample code that the service provider publishes for developers to use. Less frequently a WSDL description is provided. If there is not a WSDL file, our method requires creating one during the documentation analysis. The created Adaptee WSDL File and the fulfilled service metadata template that produces the Adaptee Service Metadata are the result of the documentation analysis. Metadata element Description INSPIRE MD correspondence (see A of [Drafting Team, 2009]) Language Language of the metadata Metadata language ServiceName A short name of service Resource title HumanDescrition Brief human-readable Description Resource abstract Provider Provider identification Responsible party UseRestrictions AccessRestrictions Restrictions about usage (e.g. Data reuse not allowed) Restriction about accessing (e.g. Licence needed or Key-based) Condition applying to access and use Limitations on public access Table 2: Simple metadata model for description of non-inspire or INSPIRE-unconformable services. 12th AGILE International Conference on Geographic Information Science 2009 page 8 of 10 Figure 6: Methodology description. The task of the target service selection might be performed independently of the documentation analysis. The services standardized by OGC are recommend by the INSPIRE IRs. In the most general case, the characteristics of the adaptee service, along with the desired functionality, will indicate which OGC service should be implemented. In this paper, we focus only on one of the OGC service type: the WPS. The WPS mediator is appropriate for the services that offer some geospatial functionality, as route calculation or geocoding. As the WPS is standardized, we have defined a set of template files that are used late
Related Search
Similar documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x