D5.2 Plan4all Networking Architecture

978 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
978
On SlideShare
0
From Embeds
0
Number of Embeds
42
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

D5.2 Plan4all Networking Architecture

  1. 1. D5.2 Plan4all Networking Architecture 1/77 ECP-2008-GEO-318007 Plan4all Plan4all Networking Architecture Deliverable number D-5.2 Dissemination level Public Delivery date 30 October 2010 Status Final Authors Flavio Camerata, Giuseppe De Marco, Giuseppina Pellegrino (DipSU) Runar Bergheim (AVINET) Main contributors Pēteris Brūns (TDF), Jachym Cepicky (HSRS), Stelian Dimitrov (EPF), Petr Horák (HF), Jan Jezek (UWB), Katharina Mitterer-Reinisch (ISOCARP), Julia Neuschmid (CEIT ALANOVA), Norma Zanetti (Hyperborea) eContentplus This project is funded under the eContentplus programme1, a multiannual Community programme to make digital content in Europe more accessible, usable and exploitable. 1 OJ L 79, 24.3.2005, p. 1.
  2. 2. D5.2 Plan4all Networking Architecture 2/77 Table of Contents 1. Purpose................................................................................................................................ 4 2. System overview................................................................................................................. 5 2.1. Mission of system........................................................................................................ 5 2.2. System stakeholders .................................................................................................... 5 2.3. System architecture...................................................................................................... 5 3. Methodology....................................................................................................................... 7 3.1. Methodology adopted for Plan4all .............................................................................. 7 3.2. Existing input to the definition of the architecture...................................................... 8 3.3. Requirement analysis................................................................................................... 8 3.4. Review of relevant standards....................................................................................... 9 4. Architectural description................................................................................................... 15 4.1. Application of RM-ODP approach to Plan4All: Plan4all-RM.................................. 15 5. Enterprise Viewpoint ........................................................................................................ 19 5.1. Concerns.................................................................................................................... 19 5.2. Stakeholders (actors) ................................................................................................. 19 5.3. Use cases/Activities................................................................................................... 21 5.4. Use cases.................................................................................................................... 23 5.5. Core elements ............................................................................................................ 35 6. Information Viewpoint...................................................................................................... 38 6.1. Information life-cycle................................................................................................ 38 6.2. Information flow model............................................................................................. 40 6.3. Information data model ............................................................................................. 41 6.4. Principal information types ....................................................................................... 43 6.5. Important findings for the implementation of the architecture.................................. 45 6.6. Formal Information Viewpoint language .................................................................. 45 7. Computational Viewpoint................................................................................................. 46 7.1. Concerns.................................................................................................................... 46 7.2. Access Control Services (ACOS).............................................................................. 46 7.3. Application services .................................................................................................. 47 7.4. Portrayal services....................................................................................................... 48 7.5. Metadata services ...................................................................................................... 48 7.6. Data services.............................................................................................................. 49 7.7. Processing services.................................................................................................... 49 7.8. Harmonisation services.............................................................................................. 50 7.9. Registry services........................................................................................................ 50 7.10. Relations among components ................................................................................ 52 8. Engineering Viewpoint ..................................................................................................... 53 8.1. Concerns.................................................................................................................... 53 8.2. Plan4All Technical Architecture ............................................................................... 53 8.3. Access Control Services (ACOS) – Technical Overview ......................................... 54 9. Technology Viewpoint...................................................................................................... 60 9.1. Concerns.................................................................................................................... 60 10. Implementation recommendations ................................................................................ 61 10.1. Examples of Open Source tools for implementing the Plan4all Networking Architecture.......................................................................................................................... 61 10.2. Examples of commercial tools for implementing the Plan4all networking architecture........................................................................................................................... 70 11. References ..................................................................................................................... 76
  3. 3. D5.2 Plan4all Networking Architecture 3/77 11.1. Standards, specifications and articles .................................................................... 76 11.2. Websites................................................................................................................. 76
  4. 4. D5.2 Plan4all Networking Architecture 4/77 1. Purpose The objective of Task 5.2 is to define the architecture (platform neutral) and the basic set of networking services in compliance with the INSPIRE Directive, for the sharing of spatial planning data between public sector and all user groups involved in the planning process and results (NGOs, citizens, private sector, education and science, and all those who play an important role in spatial planning tasks). Plan4all will define the interfaces by which the different parties will exchange the spatial planning data. This document intends to formalise and describe the Plan4all networking and data sharing architecture, and suggest its possible components. The starting point and requirements can be found in the Plan4all deliverable D5.1 and in the results of the previous Work Packages.
  5. 5. D5.2 Plan4all Networking Architecture 5/77 2. System overview 2.1. Mission of system The mission is to demonstrate the INSPIRE compliant (platform neutral) networking service architecture implementation for the sharing of spatial planning data among the public sector organisations and all the interested user groups, providing the following services: - discovery; - access to data and visualisation; - machine-to-machine communication; - work flow following the “publish-find-bind” design pattern; - processing services; - Geo-RM services. 2.2. System stakeholders - Government sector (e.g. municipalities, provinces, states, federal states); - private sector (e.g. investors, consultancy companies, contractors and development companies); - NGOs and the Third Sector (e.g. no-profit organisations, aid organisations, environmental organisations); - research and education sector (e.g. universities, research institutes, scientists, students); - citizens (e.g. people who are accessing systems without affiliation to associations, NGOs or similar). 2.3. System architecture From an architectural point of view, the system must have the following characteristics: - service oriented; - loosely coupled integration; - persistent identifiers; - trusted infrastructures. The system design is based on the principles of the Service Oriented Architecture (SOA) and is INSPIRE compliant. The INSPIRE requirements give to the overall system architecture a loosely coupled integration based on OGC standard usage, which allows to use any OGC- compliant software component and easy replace it with another if necessary. In order to achieve interoperability, the main software interface among each particular component has to be based on ISO standards and OGC specifications, following the INSPIRE Directive. These specifications are: - OGC CSW; - OGC WMS; - OGC WFS; - OGC WPS. And other relevant standards are: - ISO 19115; - ISO 19110; - Dublin Core metadata.
  6. 6. D5.2 Plan4all Networking Architecture 6/77 The communication interfaces are based on well known approaches used generally in SOA (Service Oriented Architecture). These communication protocols are widely used in OGC standards and mainly are: - key-value-pairs sent via HTTP/GET request; - key-value-pairs or XML sent via HTTP/POST request; - SOAP sent via HTTP/POST request; - REST communication via HTTP/GET/POST.
  7. 7. D5.2 Plan4all Networking Architecture 7/77 3. Methodology 3.1. Methodology adopted for Plan4all The approach adopted is based on the standard Reference Model of Open Distributed Processing (RM-ODP) (described in ISO/IEC 10746-1), which is the architecture reference model used also within ISO/TC 211 “Geographic Information – Reference model” [ISO 19101:2002], and on Open Geospatial Consortium Reference Model (ORM). The RM-ODP allows to define an overall conceptual framework for building distributed systems in an incremental and coordinated manner. The ORM is based on RM-ODP and provides an overall conceptual framework for building geo-processing services. Furthermore, the RM-ODP framework will have to be integrated with the Model Driven Architecture (MDA) approach, which allows to define the system through an abstract schema, independent from implementation tools and techniques. 3.1.1 RM-ODP Overview RM-ODP is a widely used international standard for designing open, distributed processing systems. RM-ODP provides a short, clear and explicit specification of concepts and constructs that define semantics, independently from the representation, methodologies, tools and processes used for the development of open distributed applications. RM-ODP identifies five viewpoints, or perspectives, which address different aspects of a system: - Enterprise Viewpoint; - Information Viewpoint; - Computational Viewpoint; - Engineering Viewpoint; - Technology Viewpoint. Viewpoint Name Definition of RM-ODP Viewpoint Enterprise Focuses on the purpose, scope and policies for that system. Information Focuses on the semantics of information and information processing. Computational Captures component and interface details without regard to distribution. Engineering Focuses on the mechanisms and functions required to support distributed interaction among objects in the system. Technology Focuses on the choice of technology. Description of the RM-ODP Viewpoints.
  8. 8. D5.2 Plan4all Networking Architecture 8/77 Relationships among the five RM-ODP viewpoints. 3.1.2 ORM Overview The OGC Reference Model (ORM) describes the OGC Standards Baseline focusing on relationships between the baseline documents. The OGC Standards Baseline (SB) consists of the approved OpenGIS Abstract and Implementation Standards (Interface, Encoding, Profile, Application Schema) and Best Practice documents. Purpose of the ORM: - provide an overview of OGC Standards Baseline; - provide insight into the current state of the work of the OGC; - serve as a basis for coordination and understanding of the documents in the OGC SB; - provide a useful resource for defining architectures for specific applications (Source: http://www.opengeospatial.org/standards/orm). 3.2. Existing input to the definition of the architecture - INSPIRE; - OGC; - Plan4all WP2; - Plan4all WPs 3 and 4; - Plan4all T5.1. 3.3. Requirement analysis As a preliminary work (May 2010), each involved partner has been invited to identify the use cases. The results are reported in Annex I. Moreover, during the project meeting held in Rome on 14th and 15th October 2010, all partners participated in a group discussion and answered a set of questions related to the Task. The results of these discussions are reported in Annex II. They are interesting not only for the purpose of this specific Task, but can be useful also for the following WPs.
  9. 9. D5.2 Plan4all Networking Architecture 9/77 3.4. Review of relevant standards 3.4.1 Web Map Services WMS is the standard protocol for the dynamic request of spatially referenced map images over the internet using vector or raster data from geographic data resources. The WMS specification was developed and first published by the OGC (Open Geospatial Consortium) in 1999. Today’s up-to-date WMS interface is version 1.3.0. WMS requests are always called through URI parameters. The WMS operations are: - service-level metadata (GetCapabilities request); - map with well-defined geographic and dimensional parameters (GetMap request); - optional: information about particular features shown on a map (GetFeatureInfo request); - optional: information about layers (DescribeLayer request); - optional: legend creation (GetLegendGraphic request). A WMS capable of serving the GetCapabilities and GetMap requests is referred to as “basic WMS”, a WMS also serving GetFeatureInfo requests is called “queryable WMS”. The WMS standard is mainly designed for producing maps, not to access attribute data beyond objects on the map. The WMS standard itself refers to these given standards: - EPSG Geodesy Parameters for the definition of the geographic map projection; - MIME for the correct encoding of the mapserver’s return document; - URI (Uniform Resource Identifier) syntax for the correct spelling of the map requests; - HTTP 1.1 (Hypertext Transfer Protocol) for data transmission over the Internet (it is mandatory that WMS requests can be transferred using the GET method, POST method is only optional and therefore hardly used in this context); - ISO 8601:2000 for the correct representation of dates and times; - ISO 19111, Geographic information – Spatial referencing by coordinates; - ISO 19115:2003, Geographic information – Metadata; - XML (Extensible Markup Language) for the non-graphical output of a mapserver. Data can be retrieved from a mapserver in single layers. These layers can be combined with each other. Using transparent output images (GIF or PNG) these layers can be overlaid in a way that the layers underneath the top images can also be viewed. Data can be requested from one or more different mapservers at a time, and data can also be passed through more than one mapserver to produce output referred to as “cascading WMS”, which means that one mapserver calls data from another mapserver and includes these data in its own output. The section of the Earth being mapped is defined through the “bounding box” consisting of the coordinates of a rectangle (format: min(x), min(y), max(x), max(y)) in the given coordinate reference system (CRS). The output of a mapserver – i. e. the answer to a WMS request – is always a computer readable file which is transferred from the server to the client. The MIME type string defines whether this file shall be treated as image (usually type “image/png”) or text (type “text/xml”). The table below explains some common WMS request parameters (shown for the example of a GetMap request).
  10. 10. D5.2 Plan4all Networking Architecture 10/77 Common parameters of a GetMap request (Source: OGC WMS 1.3 Interface Recommendation Paper). The request is always composed as HTTP URI string like http://myserver.com/mywmsname?SERVICE=WMS&REQUEST=GetMap&[ANOTHE RPARAMETER]=[anotherValue]. Usually the request parameters are written in uppercase characters to enhance human legibility of the request string, but also lowercase is possible. The request parameters are not case-sensitive, however, the parameter values are. Each WMS has a pre-defined style which tells the mapserver how to create an image from the geodata used in the GetMap request. Some mapservers also allow the use of Styled Layer Descriptors (SLD) so that different or user-defined map styles can be applied to map images. These SLD information is stored in XML format and can either be located on the mapserver side or sent to the mapserver as a URI parameter of the GetMap request. 3.4.2 Web Feature Services (WFS) The OGC WFS Standard (WFS) allows the interchange of geographical features across the web using platform-independent calls. While WMS only transfer images which are created from the original data, WFS deliver the data itself. It is oriented for vector data exchange on the Internet. WFS operations are used to retrieve or query features based on spatial and non- spatial constraints and to create/delete/update feature instances. The current WFS standard is version 1.1.0. These requirements must be fulfilled for WFS (source: OGC WFS standard definition): - the interfaces must be defined in XML; - GML (Geographic Markup Language) must be used to express features within the interface; - at a minimum a WFS must be able to present features using GML;
  11. 11. D5.2 Plan4all Networking Architecture 11/77 - the predicate or filter language will be defined in XML and be derived from CQL (Common Query Language) as defined in the OpenGIS Catalogue Interface Implementation Specification; - the data store used to store geographic features should be opaque to client applications and their only view of the data should be through the WFS interface; - a subset of XPath expressions for referencing properties must be used. Both geometric and attribute information are transferred with GML. Also the OGC Web Gazetteer Service profile is derived from this service. An extended capability of the service enables transactional operations like insert/update/delete features on remote servers. WFS uses also Filter Encoding for querying. WFS requests are: GetCapabilities A web feature service must be able to describe its capabilities. Specifically, it must indicate which feature types it can service and what operations are supported on each feature type. DescribeFeatureType A web feature service must be able, upon request, to describe the structure of any feature type it can service. GetFeature A web feature service must be able to service a request to retrieve feature instances. In addition, the client should be able to specify which feature properties to fetch and should be able to constrain the query spatially and non-spatially. GetGmlObject A web feature service may be able to service a request to retrieve element instances by traversing XLinks that refer to their XML IDs. In addition, the client should be able to specify whether nested XLinks embedded in returned element data should also be retrieved. Transaction A web feature service may be able to service transaction requests. A transaction request is composed of operations that modify features; that is create, update, and delete operations on geographic features. LockFeature A web feature service may be able to process a lock request on one or more instances of a feature type for the duration of a transaction. This ensures that serialisable transactions are supported. Types of WFS requests. Based on the operation descriptions above, three classes of web feature services can be defined: - basic WFS: implements the GetCapabilities, DescribeFeatureType and GetFeature operations. It is a read-only WFS; - XLink WFS: an XLink WFS would support all the operations of a basic web feature service and in addition it would implement the GetGmlObject operation for local and/or remote XLinks, and offer the option for the GetGmlObject operation to be performed during GetFeature operations; - transaction WFS: a transaction web feature service would support all the operations of a basic web feature service and in addition it would implement the Transaction operation. The WFS Transaction (WFS-T) operation is used to describe data transformation operations that are to be applied to web accessible feature instances. A web feature service may process a Transaction operation directly or possibly translate it into the language of a target datastore to which it is connected and then have the datastore execute the transaction. When the transaction has been completed, a web feature service will generate an XML response
  12. 12. D5.2 Plan4all Networking Architecture 12/77 document indicating the completion status of the transaction. The Transaction operation is optional and a WFS implementation does not need to support it to conform to this specification. If the Transaction operation is supported, then this fact must be advertised in GetCapabilities results. The rules on how to compose the WFS request are the same as with WMS. While HTTP GET requests use keyword-value pairs similar to WMS, HTTP POST operations require the use of XML. Transaction operations can only be done with the POST method. Very often SOAP (Simple Object Access Protocol) is used for communication between mapserver and client. 3.4.3 Web Coverage Services (WCS) WCS can be seen as somewhere in between WMS and WFS. WFS deliver vector data; WCS is WFS’s counterpart for raster data (images and grids). Coverages are usually transferred in GeoTIFF, HDF-EOS, NITF or CF-NetCDF formats. The actual format is defined through a MIME type string. WCS data may contain: - series of points, such as locations of samples; - regular grids of pixels or points (also photos or pictures); - segmented curves, often used for road paths; - Thiessen polygons; - Triangulated Irregular Networks (TIN). WCS provides three operations which are all mandatory: - GetCapabilities: returns an XML document which describes the service and the coverages that clients may request; - DescribeCoverage: the client can request a full description of one or more coverages served by a particular mapserver. The server returns an XML document describing the coverages; - GetCoverage: returns a coverage (i. e. values or properties of a set of geographic locations) encoded in a well-known coverage format. The requests are usually composed from key-value pairs and transferred via the HTTP GET method. Support of the HTTP POST method is only optional for WCS. 3.4.4 Web Catalogue Service (CSW) Catalogue services are the key technology for locating, managing and maintaining distributed geo-resources (i. e. geospatial data, applications and services). They support the ability to publish and search collections of descriptive information (metadata) for data, services, and related information objects. Metadata in catalogues represent resource characteristics that can be queried and returned through catalogue services for resource evaluation and, in many cases, invocation or retrieval of the referenced resource. Catalogue services support the use of one of several identified query languages to find and return results using well-known content models (metadata schemas) and encodings. With catalogue services, client applications are able to search for geo-resources through standardised interfaces and operations and, ideally, they are based on a well-known information model, which includes spatial references and further descriptive (thematic) information that enables client applications to search for geo-resources in very efficient ways. CSW relies on these standards: - ANSI/NISO Z39.50-2003, Information Retrieval (Z39.50): Application Service Definition and Protocol Specification; - IETF RFC 2045 and IANA (MIME types); - IETF RFC 2141 (URN Syntax); - IETF RFC 2396 (URI Syntax); - IETF RFC 2616 (HTTP);
  13. 13. D5.2 Plan4all Networking Architecture 13/77 - CORBA/IIOP, Common Object Request Broker Architecture, Version 2.X; - ISO/IEC TR 10000-1:1998. Information Technology – Framework and taxonomy of International Standardised Profiles – Part 1: General principles and documentation framework; - ISO/IEC 10746-2:1996. Information Technology – Open Distributed Processing – Reference Model: Foundations. Common text with ITU-T Recommendation X.902. - ISO 4217:2001, Codes for the representation of currencies and funds; - ISO 8601:2000(E), Data elements and interchange formats - Information interchange - Representation of dates and times; - ISO 11180, Postal addressing; - ISO/IEC 14977:1996, Information technology – Syntactic metalanguage – BNF; - ISO 19106:2003, Geographic Information – Profiles; - ISO 19115:2003, Geographic Information – Metadata; - ISO/DIS 19119, Geographic Information – Services; - ISO/TS 19139, Geographic Information – Metadata – Implementation Specification; - OASIS/ebXML Registry Services Specification v3.0; - and various OGC and W3C standards and/or recommendations. Metadata structures, relationships, and definitions – known as conceptual schemas – exist for multiple information communities. For the purposes of interchange of information within an information community, a metadata schema may be defined that provides a common vocabulary which supports search, retrieval, display, and association between the description and the object being described. Although this specification does not require the use of a specific schema, the adoption of a given schema within an information-sharing community ensures the ability to communicate and discover information. The metadata standard ISO 19115:2003 includes a proposal for core metadata elements in common use. ISO Draft Technical Specification 19139 defines a formal encoding and structure of ISO metadata for exchange. Where a catalogue service advertises such application schemas, catalogues that handle geographic dataset descriptions should conform to published metadata standards and encodings, e. g. ISO 19115:2003, and support XML encoding per ISO 19139 or profiles thereof. Service metadata elements should be consistent with ISO 19119. CSW use their own query language which has a syntax similar to the SQL WHERE clause. The expressiveness of the query does not require extensions to various current query systems used in geospatial catalogue queries other than the implementation of some geo-operators. The CSW query language is extensible. OGC_Common supports both tight and loose queries. A tight query is defined where if a catalogue does not support an attribute or column specified in the query, no entity or row can match the query and the null set is returned. In a loose query, if an attribute is undefined, it is assumed to match. CSW supports these types of operations according to the latest standard CSW 2.0.2: - discovery (mandatory): implemented through the requests GetCapabilities, DescribeRecord, GetRecords und GetRecordById. The selection is made by the search engines of the geodata infrastructure providers to give the client information about geoapplications, geotools or geodata ; - transaction (optional): with a transaction metadata documents can be inserted, updated or deleted. Transaction operations are done with web-based metadata editors which are usually available to closed or restricted user groups; - harvesting (optional): the operation harvestResource retrieves metadata from an external CSW and stores it in the own CSW. In a GDI this is done by a coordination office or data clearinghouse: the upper level CSWs harvest metadata from local or regional catalogues and, therefore, can offer a centralised search. A disadvantage of harvesting is the risk of redundancies through recursion.
  14. 14. D5.2 Plan4all Networking Architecture 14/77 3.4.5 Tools which can help to take local data and put them into the web effectively “AVeiN!” or “AMeiN!” are Open Source software products that help the user to export a view from ESRI ArcView or ArcMap into a UMN Mapserver map file. The application name stands for “ArcView einfach ins Netz”/”ArcMap einfach ins Netz” which is German and means “From ArcView easily into the web”/”From ArcMap easily into the web”. The software is installed as extension to ArcView or ArcGIS and guides the user through a few steps like a wizard so that a mapfile (including symbol and legend files) can be generated very quickly. The output of AVeiN/AMeiN and the geodata (shapefiles) has just to be copied into UMN Mapserver’s target directory on the web server and the data can be instantly accessed as WMS. AMeiN offers the following functions: - transfer of ArcMap symbols, fonts, font symbols, colours, hatches, …; - settings for legend, scale bar, querymap and overview map (WYSIWYG editor); - definition of data source and direct data source connection; - access to about 90 % of UMN’s functions. Unfortunately, the development of AVeiN and AMeiN was stopped some years ago, so it is not sure whether these extensions will be compatible with future versions of ArcGIS or UMN. Together with shapefiles or geodatabase information, also attribute data are stored on the web server. These attribute data can be accessed either with the WMS GetFeatureInfo request or with WFS. To propagate document-based or non-spatial information along with geodata, the easiest way seems to link such documents to the id of a geo-object in the database or shapefile. With an URI given in the attribute table, the user can access an external database where all files can be stored which are linked to certain geo-objects or groups of geo-objects. Sources: - http://www.opengeospatial.org/standards/wms - http://www.opengeospatial.org/standards/wfs - http://www.opengeospatial.org/standards/wcs - http://en.wikipedia.org/wiki/Web_Map_Service - http://en.wikipedia.org/wiki/Web_Feature_Service - http://en.wikipedia.org/wiki/Web_Coverage_Service - http://www.terrestris.de/2010/04/29/amein-handbuch-online
  15. 15. D5.2 Plan4all Networking Architecture 15/77 4. Architectural description 4.1. Application of RM-ODP approach to Plan4All: Plan4all-RM Plan4all adopted the RM-ODP approach, in particular referring to OGC Reference Model (ORM) to define its own architectural model, in order to comply to OGC standards and specifications and to ISO/TC211 standard series, according to T.5.1 requirements about services design. Adopted within many current best practices, the RM-ODP approach has been chosen because it eases the design and implementation of the Plan4all Networking Architecture, which is a complex system, in order to give a clear idea on the interrelation among the different parts of the Networking Architecture. This approach will provide an overall conceptual model to develop the Networking Architecture in an incremental manner, enabling partners’ data and services interoperability achievement (Plan4all scope) and, on the other hand, granting an easy adaptation of the Networking Architecture to future requirements (further services, new technical specifications, etc). In this work, UML will be used as the main notation language to describe all the aspects of the Networking Architecture from the different “viewpoints”, and a service-oriented approach will be adopted according to INSPIRE and Plan4all requirements defined in T5.1. This work will be focused on the Enterprise, Information, Computational and Engineering Viewpoints and the relationships among them. The Technology Viewpoint will be analysed in the following WPs, using the specifications defined in this WP. The following diagram shows the relationships between the five RM-ODP viewpoints within the Plan4all Networking Architecture.
  16. 16. D5.2 Plan4all Networking Architecture 16/77 Relationships between the five RM-ODP viewpoints within the Plan4all Networking Architecture. The following diagram gives an overview on how some reference standards and specifications play a role in the Plan4all reference model.
  17. 17. D5.2 Plan4all Networking Architecture 17/77 Overview on how some reference standards and specifications play a role in the Plan4all reference model. The following table summarises the five RM-ODP Viewpoints addressing different aspects of the Plan4all Networking Architecture, and the UML mapping containing the profiles used to describe them. Viewpoint Rationale UML technology mapping Enterprise Description of P4a system from the viewpoint of its users’ purpose, related to the reference context and policies. The Enterprise Viewpoint is defined by a set of use cases and a class diagram. Information Definition of the conceptual schema of the information managed into P4a, related to the Conceptual Data Models and Metadata profile designed by Work Packages 3 and 4. The focus is on the information semantics and processing. The ISO/OGC General Feature Model is adopted as information meta-model. The Information Viewpoint is defined by a set of information objects (classes) represented by class diagrams. Computational Definition of the reference architecture (SOA) and subdivision of the system into services interacting through interfaces, independently from The Computational Viewpoint is represented by UML component and activity diagrams.
  18. 18. D5.2 Plan4all Networking Architecture 18/77 their “physical” distribution. Engineering Definition of the engineering schema and the interaction between system components and services. The Engineering Viewpoint is represented by a “block diagram” and activity diagrams. Technology Technological specifications for the system implementation (network nodes, communication, software, etc). physical deployment. Mapping in WSDL in compliance with OGC specifications, W3C Web Services, UDDI etc. The five RM-ODP Viewpoints
  19. 19. D5.2 Plan4all Networking Architecture 19/77 5. Enterprise Viewpoint 5.1. Concerns The enterprise viewpoint deals with the purposes, scope and policies of the system. The concepts of this viewpoint are independent of both distribution and implementation details. The design of the Plan4all Networking Architecture from the Enterprise Viewpoint consists in three steps: - definition of the “stakeholders” (actors) and of the “roles”; - identification of the “activities” (use cases) for each stakeholder; - identification of the “core elements”, described through class diagrams. 5.2. Stakeholders (actors) A stakeholder is an individual or a group with an interest in the success of a system in delivering its intended results and maintaining the viability of its products. Stakeholders either affect the Plan4all system or are affected by it. The following diagram shows the stakeholders of the system, as defined by WP2. Stakeholders of the system.
  20. 20. D5.2 Plan4all Networking Architecture 20/77 The following table briefly describes the stakeholders involved with their respective activities into the Plan4all Networking Architecture. Stakeholder Description Activities End User (application, human) Stakeholder who uses Portal without registration on the Portal.  Uses services without registration;  searches through metadata;  analyses metadata view and downloads free data;  joins free services. Expert User Stakeholder registered on the Portal, who connects to data/services according to his rights, but he does not publish his own data.  Searches through metadata;  analyses metadata;  views and downloads data and joins services according to his rights;  creates and publishes composition from external sources – defines policies for this publication. Content Provider Stakeholder registered on the Portal, who provides his own data or services; he accesses data/services according to his rights.  Searches through metadata.  analyses metadata;  update metadata;  views data, downloads data and joins services according to his rights;  creates and publishes composition from external sources – defines policies for this publication;  provides data on the web;  produces metadata;  assures quality of data and metadata;  defines policies and license agreements. Policy maker Stakeholder not directly registered on the Portal, but having a secondary influence on access to the data/service (politician, not registered data owner, ...) Influences data access policies. Administrator System administrator with full access to the Portal. Technically manages the System. Stakeholders’ activities. WP2 defined several groups of users and captured requirements from them. The next table shows these user groups in relation to the actors of the proposed system.
  21. 21. D5.2 Plan4all Networking Architecture 21/77 User group/stakeholder Content provider Expert user End user Policy maker Spatial planning authorities Other civil service authorities Owners of transport and technical infrastructure Planning engineers, city planners Firms NGO Investors, real estate owners Real estate agents Research institutes, students Public User groups in relation to the actor of the proposed system. 5.3. Use cases/Activities A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system. The purpose of the Plan4all Networking Architecture may be defined in terms of the use of the system made by the stakeholders. Every activity can be represented through a UML “Use Case”, the performer of the activity is defined “Actor”. A top-level diagram shows the primary use cases in the following figure.
  22. 22. D5.2 Plan4all Networking Architecture 22/77 Primary use cases. List of use cases: - user administration and security: o stakeholder registration; o user deregistration; o user login; o setting user roles; - search and discovery: o search metadata; o browse metadata; o join a new catalogue;
  23. 23. D5.2 Plan4all Networking Architecture 23/77 - data management: o import data; o compose data/service; o publish data/service; o view data; o download data; - metadata management: o produce metadata; o import metadata; o edit/update metadata and service. - policies: o DRM specification; o access to data with DRM; - monitoring and control service: o monitor registration process; o monitor requests for access with DRM; o web analytics tool. 5.4. Use cases 5.4.1 Administration and Security Use case UC 1-01 – Stakeholder registration Task Stakeholder can use the Plan4all portal with or without registration. If he wants to access to extended functionality or restricted data, he needs to register himself: - anyone can register as a portal User for extended functionality; - anyone can register as Content Provider (to publish his own data); - Users may associate themselves with one or more content providers; - User’s roles within a Content Provider context will be restricted. Actors User, Administrator, Content Provider. Preconditions Normal Flow 1. User opens the default portal site. 2. User selects “Registration” from the main page. 3. Portal displays a registration form. The page includes help links. The form includes: o user name, password, name, company, contact information (address, email, phone, etc.), optional list of roles and list of content providers that could be associated. 4. User fills in requested data. 5. Portal validates User information (see Alternate Flow 1). 6. Portal sends a confirmation of registration to the new User. The message is also sent to the Portal Administrator (see Alternate Flow 2).
  24. 24. D5.2 Plan4all Networking Architecture 24/77 7. Portal sends a message to Content Providers specified by User, indicating the new User, his role and request for access to the Content Provider’s data (See Alternate Flow 2). 8. Portal presents a welcome page for a new User. The page includes links to Getting Started, User Documentation and Personalisation pages. Alternate Flow 1. Required information is missing or invalid. o Portal presents indication of invalid application and points out mistakes, with details on invalid or missing fields. o Portal logs invalid submission. o Use case continues with Step 3, with fields populated with previous information. 2. Notification cannot be sent to the User. o Portal sends an e-mail message to the Portal administrator notifying problem with Provider's e-mail. o Use case terminates. o Portal Administrator notifies the User directly by email and investigates communication failure. Postconditions, Results 1. Normal Flow. o User is registered on the Portal. o Appropriate Content Providers are notified about the new User and his role and are asked to confirm user’s access to their data. o Message is sent to User, welcoming him to Portal. 2. Alternate Flow 1. o Message is displayed, indicating a failed registration with details on invalid fields. o Portal has logged the registration failure. o Use Case continues with Step 3, the registration form is populated with user content. 3. Alternate Flow 2. o A communication failure event has been created. o Portal Administrator detects the communication failure. o Portal Administrator communicates directly with Content Provider, informing of Service approval. o Portal Administrator evaluates the communication failure. o Use case terminates. Notes Standard registration is done by the system. The access to Content Provider’s data is possible after the request is approved by him. Status of the request will be indicated on the Users’ personal page. Use case UC 1-02 – User Deregistration Task Registered User wants to cancel his registration in the Portal. Actors User, Administrator, Content Provider.
  25. 25. D5.2 Plan4all Networking Architecture 25/77 Preconditions User has got a valid registration on the Portal. Normal Flow 1. User logs in the portal. 2. User goes to the User’s Personal Page. 3. User selects “Cancel Registration”. 4. Portal presents Warning message. 5. User confirm deregistration (see Alternate Flow 1). 6. Portal presents “Your registration has been cancelled”. 7. Portal logouts the User. 8. Portal provides a log of the user’s last active settings. 9. Portal cancel User’s registration. 10. Portal sends deregistration notice to User, Administrator and relevant Content Provider (see Alternate Flow 2). Alternate Flow 1. User doesn’t confirm deregistration. o Portal presents the notice “Deregistration has been canceled”. o Portal goes to User’s Personal Page. o Use case is finished. 2. Deregistered User plays the role of Content Provider. o System sends deregistration notice also to every User who has indication (on Personal Page) of using Content Providers data/services. o System indicates on Personal Page of every User, that the data/service is not available any longer. Postconditions Notes Use case UC 1-03 – Login Task In order to access to extended portal functionality or to restricted data/services, the Stakeholder needs to be logged in the Portal. Actors User. Preconditions User has got valid registration on the Portal. Normal Flow 1. User opens the default portal site. 2. User types username/password in the login box. 3. User clicks “Login” button. 4. Portal runs Authentication routine - verifying the Stakeholder (see Alternate Flow 1). 5. Portal runs Authorisation routine (permission to access to extended functionality or restricted data/services). 6. Portal logs the User in the portal. 7. Portal presents the Main Page according to User’s settings. Alternate Flow 1. Authentication is failed. o Portal displays the message “Wrong Username or Password”. o Portal goes to the default portal site (step 1 of the Normal Flow). Postconditions
  26. 26. D5.2 Plan4all Networking Architecture 26/77 Notes Use case UC 1-04 – Setting User Roles Task When the Stakeholder is registered, he can play the role of Expert User (access to extended functionality or restricted data/services) or Content Provider (the same as Expert User and the possibility to publish own data). Actors User, Administrator Preconditions Stakeholder has got valid registration with the Portal and is logged in. Normal Flow 1. User goes to his Personal Page. 2. User selects the “Role Settings” table and chooses the Role. 3. User confirms his choice. 4. The Portal sets the new role. 5. The Portal displays message “Your new role has been set”. 6. Portal sends message to the administrator. Alternate Flow Postconditions Notes 5.4.2 Search, Discovery and Display Use case UC 2-01 – Search Metadata Task User searches for data/service using metadata catalogue implemented into the Portal. Actors User. Preconditions Portal includes Data and Metadata Repository. Portal includes a solution supporting CSW 2.02. Normal Flow 1. User selects a search functionality. 2. User types a simple keyword (see Alternate Flow 1). 3. Metadata Catalogue Server searches in the internal Data and Metadata Repository. 4. Metadata Catalogue Server sends a request for metadata to the External CSW. 5. Catalogue client displays a result of searching. Alternate Flow 1. Advanced Parameter Searching. o User selects the Advanced Parameter Searching button. o System displays the Advanced Parameter Searching window with the extended list of parameters, geographical extent input; relevant Thesaurus should be included. o User specifies searching conditions. o Use case continues in the Step 3 in the Normal Flow.
  27. 27. D5.2 Plan4all Networking Architecture 27/77 Postconditions The result set includes: - Total number of results. - Basic information about each result (e.g. thumbnail, title, abstract, organisation, etc.). - Expand results to display additional information (e.g. full metadata record) from the Catalogue. - A function to display data/service preview. - A function to add selected data/service into User’s Map Client. Notes Metadata are regularly harvested. Use case UC 2-02 – Browse Metadata Task User searches for data (use case 2-01) and gets a result set. The record set may contain a great number of metadata records. He needs to work with the result and find the appropriate record. Actors User. Preconditions A set of results of metadata records from searching is available on the metadata client. The metadata is sorted by a source catalogue. Normal Flow 1. User browses the list of metadata. The metadata is signed as metadata for data or services. 2. User clicks on the metadata preview to get a full metadata record. The record is shown in a new window; it is better to use a split window for the list and the detail (See Alternate Flow 1). 3. User clicks on the Button to get preview of the data/service. The data/service is displayed in Map Client of the Portal. 4. User goes back to the list or to the detail of the metadata record. 5. User looks at the detail of other records. 6. If needed, User can join a new catalogue for searching. Then he repeats searching (see UC 2-02). Alternate Flow 1. Grouping by parameters. o User can group a list of results by pre-defined parameters (owner, year, ...). User selects “Group by parameters”. o Portal displays list of results by groups. o Use case continues by Step 2 of the Normal Flow. Postconditions User gets information about appropriate data/service. User is able to view or join data/service into his project/application. Notes Use case UC 2-03 – Join a new catalogue (CSW) for searching Task User searches for data (use cases 2-01, 2-02) and gets a result set. But the results are not satisfactory, so User needs to extend searching with
  28. 28. D5.2 Plan4all Networking Architecture 28/77 other catalogue. Actors User. Preconditions Metadata searched by default catalogue are not satisfactory. Joined catalogue is relevant to CSW 2.0.2. Normal Flow 1. To add a new catalogue, User clicks on the button “Add CSW”. 2. User selects one of the pre-defined catalogues (see Alternate Flow 1). 3. User clicks on “Add” button. Alternate Flow 1. Add Custom CSW. o User types name (title) of the CSW. o User types URL of CSW. o If needed, User selects SOAP using. o User click on “Add” button. Postconditions New CSW is added to the list. When User makes new search for metadata, the new CSW is running together with the default one. Notes 5.4.3 Data Management Use case UC 3-01 – Import Data Task Content Provider intends to publish his data on the web. The first step is to get data from a local storage into the Portal Repository. Actors Content Provider. Preconditions Content Provider has set his competence by the Portal’s Authorisation Service. Normal Flow 1. Content Provider goes to the Data Management module of the Portal. 2. Content Provider runs the “Upload Data” function. 3. Content Provider selects data on his computer to upload it on the Portal. 4. Content Provider chooses the upload into File Repository or import into Database. 5. Content Provider sets the rights for access to data. 6. Content Provider specifies Licence Condition for the data utilisation. 7. Content Provider fills in an appropriate metadata record. Alternate Flow Postconditions User’s data is stored in the Internal Portal Repository and is searchable through metadata catalogue. Notes Use case UC 3-02 – Compose Data/Service
  29. 29. D5.2 Plan4all Networking Architecture 29/77 Task User wants to create a new map project which integrates internal and external data sources. This new map project will be published and then will be available for other users. Actors Content Provider, User. Preconditions Content Provider has set his competence by the Portal’s Authorisation Service. Data for publication is stored in the Internal Portal Repository. External data sources are known or discoverable through CSW 2.0.2. Normal Flow 1. Content Provider goes to the Data Management module of the Portal. 2. Content Provider runs “Create Composition” function. 3. Content Provider specifies basic settings of the map project (name, keywords, referential system, extent, ...). 4. Content Provider selects data sources – Internal Data Repository (files or database) or External Web Services (WMS, WFS) or sources accessible through the implemented CSW. 5. From the selected data source, Content Provider selects appropriate data/services and adds the map project (see Alternative Flow 1). 6. Content Provider sets parameters of the content – symbols, colours, visibility, layers order, ... (see Alternative Flow 1). 7. Content Provider sets/updates metadata of the map project. 8. Content Provider saves the final map project. Alternate Flow 1. To check the work, Content Provider can display the in- process map project in the Map Client. Postconditions The new map project is stored and published as a Map View, or a standardised web service (WMS, WFS) is established and searchable through metadata catalogue. Notes Use case UC 3-03 – Publish Data/Service Task Data Provider wants to publish his data as web services. Actors Data Provider. Preconditions The competence of the Content Provider is set by the Portal’s Authorisation Service. Data for publication is stored in the Internal Portal Repository. Normal Flow 1. Content Provider goes to the Data Management module of the Portal. 2. Content Provider runs “Publication” function. 3. Content Provider selects data for publication. 4. Content Provider sets type of publication (Map View, WMS, WFS, ...). 5. Content Provider sets the rights for access to data. 6. Content Provider specifies Licence Condition for the service utilisation.
  30. 30. D5.2 Plan4all Networking Architecture 30/77 7. Portal displays metadata records (going from dataset) and offers metadata update. 8. Content provider edits metadata record (the data should not be published without appropriate metadata). 9. Content Provider confirms the service establishment. Postconditions New service is established and searchable through metadata catalogue. Notes Publication of Map View means generating a private or public URL address showing window with map client and User’s data (in this case one layer). Use case UC 3-04 – View Dataset Task User needs to look at the spatial planning data, find detail information about objects, compare them with the referential data. Actors User. Preconditions Map client supporting Open Web Services implemented onto Portal. Data set available for the map client in the Portal internal repository or via standardised Open Web Services (WMS, WFS). Map Client window integrates a box for catalogue searching. Normal Flow 1. User opens Map Client on the Portal. He can open Map Client with the specific map project (e.g. municipal plan of city) or he can use a default project. 2. User can join new dataset from internal Portal Repository. If needed, data is transformed using transformation service. 3. User can join a new Web Service (see Alternate Flow 1). If needed, data is transformed using transformation service. 4. User uses available Map Client functionality (zoom, info, ...) to get relevant information. Alternate Flow 1. Join Service from the catalogue. o User can look for new data/service through implemented CSW. o User types keyword into catalogue searching box. o Next steps – see use cases 2-01 and 2-03. o Continue with step 4 of the Normal Flow. Postconditions User gets a map or a map composition with relevant information in the Map Client. Notes Use case UC 3-05 – Download Dataset Task User needs data on his computer (to use them in desktop application, to update them, ...). He downloads data from the Internal Portal Repository or from an external data source. Actors User. Preconditions The competence of the Content Provider is set by the Portal’s
  31. 31. D5.2 Plan4all Networking Architecture 31/77 Authorisation Service. Data for publication is stored in the Internal Portal Repository. Normal Flow 1. Content Provider goes to the Data Management module of the Portal. 2. Content Provider runs “Download” function. 3. Content Provider searches for data through the CSW (see Alternate Flow 1, 2). 4. Content Provider selects datasets for download. 5. Content Provider sets parameters for download (see Alternate Flow 3). 6. Content Provider downloads the data. Alternate Flow 1. Download from Internal Portal Repository. o Content Provider accesses file repository or database according to his authorisation. o Content Provider selects data to download. o Content Provider sets download parameters. o Content Provider downloads the data. 2. Dataset defined by WFS query. 3. Transformation service. o If transformation process for data is needed (based on the set parameters), the Portal provides transformation of data into the requested format. Postconditions Downloaded data are stored in PC in the requested format. Transformation service is applied if needed. Notes 5.4.4 Metadata Management Use case UC 4-01 – Produce Metadata Task Content Provider, Expert User authorised for data/service publication should provide also metadata. When the data/service is prepared for publication, metadata record is created and stored together with new data/service. Actors Content Provider, Expert User. Preconditions The competence of the Content Provider or Expert User is set by the Portal’s Authorization Service. Metadata creator is integrated into the Portal or the Metadata record has to be in the appropriate profile. Normal Flow 1. Content Provider or Expert User logs in the Portal. 2. Content Provider or Expert User publishes a new service or data. 3. Before confirmation, the user chooses the metadata record creation or updating. 4. Portal runs metadata editor (integrated or external). 5. Content Provider or Expert User updates metadata record. 6. Content Provider or Expert User confirms data/service storing. 7. Portal stores data/service and appropriate metadata record.
  32. 32. D5.2 Plan4all Networking Architecture 32/77 Alternate Flow Postconditions Metadata is available for searching by CSW2.0.2. Notes Use case UC 4-02 – Import Metadata Task Content Provider doesn’t need to create metadata on the Portal, but he may import existing metadata records created in external editors. Actors Content Provider. Preconditions The competence of the Content Provider is set by the Portal’s Authorisation Service. Data is imported onto the portal together with metadata. Metadata needs to be in the appropriate structure (profile). Normal Flow 1. Content Provider logs in the Portal. 2. Content Provider imports data on the server (see Alternate Flow 1). 3. Portal offers also an import of metadata, if it exists. 4. Content Provider selects appropriate metadata xml and uploads it on the server together with data. 5. Portal stores imported data and appropriate metadata record. Alternate Flow 1. Import metadata without data. In some cases, metadata could be imported individually and joined to data on the server. It is for example when metadata is created ex post or in external metadata editors without portal connection. o Content Provider selects data on the Portal which will join metadata too. o Continue with step 3 Normal Flow. Postconditions Metadata is available for searching by CSW 2.0.2. Notes Use case UC 4-03 – Edit/Update Metadata Task Content Provider, Expert User needs to update or edit metadata stored on the Portal. Actors Content Provider, Expert User. Preconditions The competence of the Content Provider or Expert User is set by the Portal’s Authorisation Service. Metadata is stored on the portal in the appropriate profile. Metadata editor is integrated into the Portal. Normal Flow 1. Content Provider or Expert User logs in the Portal. 2. Content Provider, Expert User searches for metadata record that he wants to edit in metadata catalogue. 3. Portal displays metadata record. 4. Content Provider or Expert User runs metadata editor. 5. Content Provider or Expert User updates/edits metadata
  33. 33. D5.2 Plan4all Networking Architecture 33/77 record. 6. Content Provider or Expert User confirms changes. 7. Portal stores updated record. Alternate Flow Postconditions Notes 5.4.5 Data Right Management (DRM) Use case UC 5-01 – Specification of DRM for Data/Services Task Content Provider wants to set DRM for his Data/Service. Actors Content Provider. Preconditions In relevant cases, this use case is included into Data Management (see use cases UC 3-01 Data Import and UC 3-03 Publish Data/Service). Content Provider has his own text of the License Agreement on Data/Service. Normal Flow ... UC 3-01, UC 3-03: Content Provider sets the access rights to data. 1. Content Provider selects the choice “Set DRM for Data/Service”. 2. The Portal offers predefined types of DRM. 3. Content Provider selects the relevant DRM type. 4. The Portal offers uploading of the License Agreement text (in pdf). 5. Content Provider uploads the relevant pdf. UC 3-01, UC 3-03 continue... Postconditions Notes The Portal doesn’t solve any business contract between Content Providers and Users, only accesses to the data based on the License Agreement. Use case UC 5-02 – Access to the Data/Services with DRM Task User needs to access the data with DRM. Actors User, Content Provider. Preconditions To access the data with DRM, User needs to have a valid registration to the Portal. Normal Flow 1. User looks for data using catalogue and finds data with DRM. 2. The Portal warns that the data is with DRM. 3. User wants to use data with DRM and sends request for an access. 4. The Portal notices to relevant Content Provider that the data is requested. The message contains User’s identification and details. 5. Content provider approves the request (see Alternate Flow 1).
  34. 34. D5.2 Plan4all Networking Architecture 34/77 6. The Portal notices the approval to the User and offers acceptation of a License Agreement. 7. User accepts the License Agreement (see Alternate Flow 2). 8. The Portal extend User’s Authorisation. 9. User can work with data with DRM. Alternate Flow 1. Content Provider refuses the request. o System notices the refusing to the User. o System blocks User’s access to the data. o Use case finishes. 2. User doesn’t accept the License Agreement. o The Portal warns the User that data will not be accessible. o The Portal blocks User’s access to the data. o The Portal sends notification to the Content Provider. o Use case finishes. Postconditions - All requests and decisions are stored in a log. - Content Provider can list his data and given accesses. - Content Provider can cancel his approval. Notes 5.4.6 Monitoring and Control Services Use case UC 6-01 – Monitoring of the Registration Process Task Administrator needs a summary of the registration requests. Actors Administrator. Preconditions Normal Flow 1. Administrator goes to his profile. 2. Administrator selects the “Monitoring of registration requests”. 3. The Portal displays list of the registration requests in the table, that covers: o Date. o Registration is successful/unsuccessful. o User name (content link to the user’s profile). o Role. o User’s IP. 4. Administrator can display user’s profile by clicking on the “Name”. 5. Administrator can search the table. Postconditions Notes Use case UC 6-02 – Monitoring of the Requests for an access to the data/service with DRM
  35. 35. D5.2 Plan4all Networking Architecture 35/77 Task Administrator or Content Provider needs a list of the requests for access to the data with defined DRM. Actors Administrator, Content Provider. Preconditions Administrator has the access to all requests. Content Provider can display only the requests concerning his own Data/Services. Normal Flow 1. Administrator or Content Provider goes to his profile. 2. Administrator or Content Provider selects “Monitoring of DRM data access”. 3. The Portal displays list of all requests (depending on Administrator’s or Content Provider’s rights) for the access to the Data/Service with defined DRM. The table covers: o Date. o User Name (contents link to the User’s profile). o User’s IP. o Requested Data/Service. o Relevant Content Provider (contents link to the Data Provider profile). o Request confirmed/refused. o Licence (link to the text of the relevant licence). 4. Administrator or Content Provider can display text of the licence and the profile of the User or Content Provider. Postconditions Notes Use case UC 6-3 – Web Analytics Tool Task Administrator needs web analytics regarding website traffic. Actors Administrator. Preconditions Normal Flow 1. Administrator goes to his profile. 2. Administrator selects “Web Traffic Analysis”. 3. The Portal Analytical component displays the data groups: o Number of users connected to the web in different periods. o Sources of the connection. o Visited pages/services. 4. Administrator can export or print the Web traffic analytical report. Postconditions Notes 5.5. Core elements Within the Plan4all system, the core elements are: - policies; - services; - harmonisation;
  36. 36. D5.2 Plan4all Networking Architecture 36/77 - metadata; - Content Provider and Data. Particularly important is the element “policies”, which includes the mechanisms necessary to guarantee security to the services. A proper technical infrastructure has been defined to support the whole system and will be described in detail in section 8.3. The following diagram represents the different kinds of policies. Different kinds of policies. The Authentication allows verification of the unique identity of the user that ensure the access to the services. The Authorisation provides the user with the privileges necessary to access specific functionalities. Digital Rights Management (DRM) deal with the management of rights and licenses. For the implementation of these mechanisms, OASIS and W3C specifications have been adopted, especially geoDRM specifications for the definition of DRM policies. Each actor may interact with one or more elements in a different way depending on their roles. The following figure shows the high-level object model.
  37. 37. D5.2 Plan4all Networking Architecture 37/77 High-level object model. The Plan4all system consists in metadata, policies and services. Through these services, the stakeholders can have access to the Content Providers’ data. The data provided by the different Content Providers interact with the system through the Harmonisation Tools and the services implemented by Plan4all.
  38. 38. D5.2 Plan4all Networking Architecture 38/77 6. Information Viewpoint The Information Viewpoint describes the way that the Plan4all Networking Architecture stores, manipulates, manages, and distributes information. The major issues which are analysed and assessed are: - information structure and content with a clear focus on the metadata and data models developed through Work Packages 3 and 4; - information flow among the different actors and components in the architecture; - the ownership of the data and the responsibilities associated with its creation and maintenance; - references and mappings between different metadata and data sets; - management of transactions and recovery of information; - issues related to data quality including completeness, validity, consistency, timeliness and accuracy; - considerations related to data volumes; - archiving and data retention issues and; - adherence to regulations and policies. By assessing these aspects of the Information Viewpoint, a number of findings have been described which are of impact to the design of the Plan4all Networking Service architecture. 6.1. Information life-cycle The information life-cycle of spatial planning data (maps) and documents as envisaged within the framework of Plan4all consists of the following steps: Step Description Creation Data (maps) and documents are born through the creative planning process whereby areas, lines and point features are assigned functions according to national/regional spatial planning regulations. The input to this phase is typically any thematic information plus preceding or higher-level spatial plans for the same area. It is also relevant to identify “neighbouring” plans on the same level created by the same or parallel administrations. Refinement Throughout the planning process, data (maps) and documents are exposed to additional stakeholders to those who are directly involved in the creative process for feedback. Following this feedback, initial data (maps) and documents are modified and new versions are presented for further comments and inputs. Approval Following the completion of the creative planning process and any legally mandated public hearing processes, the spatial planning data and documents are printed and raised to the appropriate political body for approval. In most EU Member State legislations, with the exception of the Netherlands, the legally adopted spatial plan is the hard-copy version – not the digital data. The plan is therefore a composite of base map data, thematic data and planned land-use polygons. This leads to a split management regime from this point onwards. The reason for this is partly dated legislations and governmental practices and partly legal precedent in terms of property disputes resulting from
  39. 39. D5.2 Plan4all Networking Architecture 39/77 detailed planning in high-value urban areas where the line-thickness of a land-use polygon boundary has a great economic significance in terms of e.g. compensation for expropriation. This does however put some limitations on how the digital data may be re-used. Use Having been approved, the spatial planning data (maps) and documents enter into the “production” phase where they are used as underlying decision and guidance documents for controlling large and small-scale physical development. The traditional stakeholders of this type of use are public administrations with sector or overall responsibilities for approving and issuing no- objection-certificates for public, private and individual development and construction projects. Publishing The traditional publishing of spatial planning data (maps) and documents was in the form of printed copies available for review and consultation from the local planning office. A more recent addition to the life-cycle of spatial planning data and one that is critical to the vision of Plan4all is the publishing of spatial planning data as data and services over the public Internet indiscriminate of the intended purpose of any re-using party. This involves making data available through open protocols like WMS (view services) and WFS (download services) and providing a suitable cartography and metadata to support third parties in understanding the quality and nature of the data. While the named protocols above enable re-use of spatial planning data, an essential step of the publishing is to expose the materials in such a manner as to make it discoverable for potential users. This is typically achieved through the implementation of interoperable catalogue services (e.g. CS-W). Re-use The re-use domain for spatial planning data is largely “uncharted territory” in that there is an infinite number of use-cases which may exist among re- users. Envisaged use-cases include geospatial analysis for location of new businesses and development areas as well as real-estate advisory services. The recent developments of the Web 2.0 and Semantic Web communities and their mash-ups based on light-weight web services and Linked Open Data have shown that it is impossible to pre-empt or even predict potential uses of data. The ruling philosophy is therefore to make as much “raw data” as possible available with as little effort as possible. Periodical revision Planning data typically has a validity period which is defined by the national or regional legal spatial planning framework. Upon expiry of this validity period the plan shall be replaced by a revision, taking into account new or additional spatial development trends and requirements. Information life-cycle of spatial planning data. For the purpose of Plan4all, the Publishing and Re-use steps of the information life-cycle are of great importance and the analysis of the Information Viewpoint therefore dwells specifically on this topic. The Publishing step is a new and somewhat alien concept to the spatial planning process in that it involves technical rather than planning skills. Due to spatial plans largely being treated
  40. 40. D5.2 Plan4all Networking Architecture 40/77 as complete maps rather than individual land-use polygon datasets, the disciplines involved in publishing a spatial planning map and its associated documents are equally complex as in running a full-fledged spatial data infrastructure (SDI). “Zooming” in on the publishing step, we will see that it consists of the following elements: - preparation of data in accordance with the Plan4all/INSPIRE data models; - preparation of metadata in accordance with the Plan4all/INSPIRE metadata models; - installation of Internet infrastructure and server hardware; - installation of web and application server software for discover, view and download services; - configuration of cartography for view services; - configuration of security; - monitoring, running and maintenance of data, software and hardware infrastructure. These tasks are comprehensive and technology intensive and require additional skills to those commonly found in local planning authorities. This puts a constraint on the Plan4all networking service architecture that it must be implementable with minimal capital investment and work effort. 6.2. Information flow model The flow of information between the different processes and actors in the Plan4all networking service architecture has great significance for the specification. In order to understand the flow it is important to understand which parts of the communication is publishing based and which are based on user interaction through open services interfaces. The above diagram shows the information flow between planners and re-users of planning data in the Plan4all networking service architecture. The originating point for planning data is the local planning authority, symbolised by the planner. He or she creates the planning data (maps) and documents throughout the creative planning process using CAD or GIS tools – providing basic data as output. From the planner, data can find two ways to the overall INSPIRE/Plan4all infrastructure: a) directly from a local administration acting as both data and service provider or; b) through
  41. 41. D5.2 Plan4all Networking Architecture 41/77 third-party service providers acting as “web hotels” for planning data (maps) on behalf of planning authorities or administrations which for one reason or the other are unable or unwilling to run their own infrastructure. The service provider is responsible for exposing OWS interfaces to the Internet, to be consumed by the INSPIRE and the Plan4all Geo-portals and pan-European registry, as well as by end-users making individual requests to Discover, View or Download services. The sequence of events is that the re-user queries the INSPIRE/Plan4all Geo-portal for data sets of a specific type for a specific area. The query returns metadata on a number of resources which may then be accessed directly from the service provider over OWS request protocols like WMS (view services), WFS (download services) and CS-W (discover services). 6.3. Information data model Understanding the relationships among the individual types of information involved in the Plan4all architecture is essential to be able to satisfy service provider and end-user requirements.
  42. 42. D5.2 Plan4all Networking Architecture 42/77 The above data model shows the relationships among the individual information components of the Plan4all Networking Architecture.
  43. 43. D5.2 Plan4all Networking Architecture 43/77 At the heart of the information model lies the spatial plan. A spatial plan is an abstract information entity which consists of three parts: - one or more spatial planning documents; - zero or more spatial planning data sets; - zero or more map compositions. For this reason, a spatial plan may not be treated as one individual file or entity – but as a group of heterogeneous resources with strong dependencies. The data model and nature of the spatial plans will vary significantly between different planning legislations – and to secure interoperability, a harmonised view or transformation of the data model must be provided as a distinctive data set. The spatial plan and the harmonised data set are both associated with metadata which are published through a discovery interface which is called a catalogue service. This service will provide discovery and web service interfaces for performing searches and look-up in metadata. The metadata will cover four different aspects: - metadata for the abstract spatial plan including an URI reference to an online accessible version of the planning documents; - structured metadata for the harmonised spatial planning datasets; - geo-rights management metadata to handle restrictions and legal obligations associated with the spatial data; - spatial services metadata to provide the ability to connect to actual OWS web services based on query result data from the catalogue service. The underlying data will be exposed through a set of INSPIRE services as described below: - original datasets, harmonised datasets and metadata will be exposed through spatial planning services like discover, view and download; - harmonised datasets may be created through online transformation of original datasets through transformation services using the Plan4all data model as input. In the absence of a functional INSPIRE Geo-portal with a pan-European registry-layer, the Plan4all geo-portal temporarily serves this purpose and provides both a metadata profile and an exchange data model for spatial planning related data. 6.4. Principal information types In this section the most important information types in the architecture are defined and discussed in greater detail. 6.4.1 Spatial plan Spatial planning refers to the methods used by the public sector to influence the distribution of people and activities in spaces of various scales. Spatial planning includes all levels of land use planning including urban planning, regional planning and environmental planning, etc. While from a GIS perspective, spatial plans are often thought of as maps and data – these are usually mere visualisations which support a comprehensive textual description of the spatial development policies for an administrative area. This means that spatial plans may not be shared successfully if one only considers spatial data service protocols. Access to underlying documents is equally or more important to interpret and contextualise the information contained in the spatial data sets.
  44. 44. D5.2 Plan4all Networking Architecture 44/77 6.4.2 Metadata Metadata is loosely defined as data about data. Metadata is a concept that applies mainly to electronically archived or presented data and is used to describe the a) definition, b) structure and c) administration of data files with all contents in context to ease the use of the captured and archived data for further use. For example, a web page may include metadata specifying what language it’s written in, what tools were used to create it, where to go for more on the subject etc. When taking information out of its original scope and making it available out of context, a lot of metadata which are considered implicit (and therefore redundant) by the local administration or planning authority is very important. There are hundreds of common coordinate systems in active use across Europe using all sorts of datum points, ranging from the corner of the town-hall to UTM. When creating data in a local application this information is given – but when the data are received by a third-party this becomes crucial metadata in order to successfully understand and use the data. For maps created using CAD tools, there may occasionally not even be real-world coordinates for the maps – and they must be manually registered to geographical space. 6.4.3 Spatial data Spatial data are data which define a location. Spatial data are usually expressed in the form of graphic primitives that are usually either points, lines, polygons or pixels and associated one- or multi-dimensional attributes. Spatial data can originate from multiple sources. In the planning world, detailed plans are very often made in CAD systems – reflecting the fact that the legal documents often are the printed ones – not the digital data. For this reason CAD tools are very good for making quick and accurate drawings which correspond to the drawing and cartographic visualisation rules of planning legislations. The Plan4all architecture considers spatial planning data as GIS datasets – that is, geometrical primitives representing logical planning features, carrying rich information attributes. In order to bridge the gap between the two information paradigms, it is necessary to introduce services which are able to translate back and forth between the two software environments. The two-way translation is important because it is not possible to envisage that a data sharing infrastructure will impact the way in which data are created and used at all planning authorities across Europe – but will have to adapt flexibly to the existing conditions. 6.4.4 Document data An original or official paper relied upon as the basis, proof, or support of anything else, including any writing, book, or other instrument conveying information pertinent to such proof or support. While the spatial data standards have sophisticated protocols for look-up and use via OWS protocols, document data are completely free-form and therefore allow for more limited capabilities in terms of information integration and cross-searches. However, in order to understand a spatial planning map or dataset it is essential to have access to the document providing the description and detail of the different land-use purposes which are assigned to polygons, lines and points. It is therefore necessary to identify a standard way of publishing the spatial planning documents in such a way that they are strongly linked with the spatial data. While foreign language is an issue in attribute data and code lists, it is a more severe issue when it comes to planning documents written in national languages. This is of course an impediment to successful interpretation of spatial planning documents – but may to a certain degree be mitigated by automated translation tools which will not produce semantically correct output but which may prove evidence towards the meaning of the original text and
  45. 45. D5.2 Plan4all Networking Architecture 45/77 give sufficient background for knowledgeable users to determine if they want to translate the passage or not. 6.5. Important findings for the implementation of the architecture The following are the most important findings from the analysis of the Plan4all networking service architecture from the Information Viewpoint: - the architecture must serve documents in addition to spatial data types; - the architecture must be able to consume and deliver data to and from GIS and CAD software environments; - there must be a strong link between metadata and data in order to secure effective re- use of data discovered through the INSPIRE Geo-portal metadata catalogue; - there must be a facility in place to provide transformation from local coordinate reference systems to well-known, standard coordinate reference systems; - the implementation of the infrastructure must be applicable in an environment where the stakeholders’ principal skills lie in thematic disciplines like planning and who have limited knowledge of the disciplines required to run an SDI. 6.6. Formal Information Viewpoint language In the ISO/IEC 19793-2008, an international standard defining UML profiles for use when modelling system architectures in conformance with RM-ODP, the Information Viewpoint language is defined as follows: “...The individual components of a distributed system should share a common understanding of the information they communicate when they interact, or the system will not behave as expected. These items of information are handled, in one way or another, by information objects in the system. To ensure that the interpretation of these items is consistent, the information language defines concepts for the specification of the meaning of information stored within, and manipulated by, an ODP system, independently of the way the information processing functions themselves are to be implemented. Information held by the ODP system about entities in the real world, including the ODP system itself is modelled in an information specification in terms of information objects, and their relationships and behaviour. Basic information elements are modelled by atomic information objects. More complex information is modelled as composite information objects each modelling relationships over a set of constituent information objects. The information specification comprises a set of related schemata, namely, the invariant, static and dynamic schemata: - an invariant schema models relationships between information objects that must always be true, for all valid behaviours of the system; - a static schema models assertions that must be true at a single point in time. A common use of static schemata is to specify the initial state of an information object; - a dynamic schema specifies how the information can evolve as the system operates. ...”. RM-ODP in its native form is a methodology which is good to define in detail technical system architectures for and by technical experts. Due to the nature of the stakeholders in the Plan4all architecture, a simplified approach has been chosen in modelling the different viewpoints. The purpose of this is to enhance the understanding of the model for non-GIS- professional, non-technical stakeholders who play key roles in the information flow.
  46. 46. D5.2 Plan4all Networking Architecture 46/77 7. Computational Viewpoint 7.1. Concerns The computational viewpoint enables distribution through functional decomposition of the system into objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition. This viewpoint focuses on the components of the system, not considering distribution aspects, which are managed within the Engineering and Technology viewpoints. The proposed architecture is Service Oriented, based on publish-find-bind paradigm. The primary components identified for P4All are described below. 7.2. Access Control Services (ACOS) As the Geoportal consists in various applications with different purposes, a single point of user login and application permissions discovery are required. For this goal, the system is required to provide an application that is capable of using various required data backends due to deployment specifics. Also, it needs to provide communication frontend for various “clients”, where client means everything from desktop application to mobile service. The Access Control Service in composed by: - Access Interface: o SOAP – whole functionalities of ACOS Core are available throw SOAP WebService interface. This is very important for use by many different devices (server, desktop, mobile) and platform (Windows, .NET, Java, …); o OAuth – allows users to share their private resources stored on geoportal (in any application of geoportal) with another site/application without having to hand out their credentials; o OpenID – each user registered on ACOS (Geoportal) has automatically an OpenID identificator which allows users to login to external applications with it. - Core: o Authentication Core – contains functions for communication with authentication connectors for specific authentication method (LDAP, SAML, …); o Authorization Core – contains functions for communication with authorisation connectors; o Administration Core – contains functions for manage objects inside ACOS (users, user groups, permissions, parameters). - Connectors: o a separate connector exists for each authentication and authorisation method. - Management console: o web application for managing objects inside ACOS (users, user groups, permissions, parameters). 7.2.1 Interfaces The component proposes itself to the system through the only interface control.
  47. 47. D5.2 Plan4all Networking Architecture 47/77 7.3. Application services It is a fundamental component including all the processes necessary to the users in order to employ the functionalities supplied by the system. The application services allow to: - search metadata: o through the horizontal service, invoke the search metadata service of “metadata services”; o receive the “package” of results to display from the “portrayal services”, “through” the horizontal service, and display it to the user in terms of list of metadata records that match search criteria. - “receive” a metadata record (the user can be human or another system): o invoke the get metadata service of “metadata services” through the horizontal service, to request a specific record; o receive the metadata record to be displayed to the user from “portrayal services”, through the horizontal service, and return it to the user. - “manage” (produce, import, upload, edit/update) metadata, through the horizontal service, using the metadata services; - view or download a dataset: o view:  through the horizontal service, invoke data services;  allow the user to interact with data (pan, zoom, overlay) calling “view” services of data services;  return to the user the data (map, overlays, …) to be displayed from the “portrayal services”; o download:  through the horizontal service, invoke “download” data services;  return to the user the features data received from the “portrayal services”. - send the request to appropriate services transformation to transform data: o through the horizontal service, invoke the service SRS transform of “processing services”; o through the horizontal service, invoke the format transformation service of “processing services”; o return to the user the data received from the “portrayal services”. - perform a transformation of unharmonised data (the user can be human or another system): o through the horizontal service, invoke the “harmonization service”:  the user input – such as source and target schema and mapping metadata – is passed to the harmonisation service. - register or invoke services in the service registry: o “register” – the service provider will use this service to “publish” a service onto the service registry: through the horizontal service, invoke the publish service of the “registry services” component; o “search” – the user or a generic service consumer will use this service to search/discover a service into the registry: through the horizontal service, invoke the find service of the “registry services” component; o “locate” – the user or a generic service consumer will use this service to obtain service metadata for a service registered into the repository: through the horizontal service, invoke the bind service of the “registry services” component.
  48. 48. D5.2 Plan4all Networking Architecture 48/77 7.3.1 Interfaces The component does not expose interfaces. 7.4. Portrayal services The task of this component is to visualise the results from the component Application services. This component is essentially a renderer. The portrayal services perform the rendering of “generic data” (catalogue entry, map image,…) into an output format that will be delivered to the user through the “horizontal service” and then through the application services. The generic “rendering” to the application service can be specialised to allow: - rendering of the output from search/discovery service (e.g. list of metadata item found from a search): o build the link to the catalogue item, allowing the user to direct access it. - rendering of a metadata item: o build, if available in the metadata record, the link to the resource, allowing the user to direct access it. - rendering of the output from view service (e.g. image with overlays); - rendering of the output from download service (e.g. a shapefile or a GML); - rendering of the output from transform service. 7.4.1 Interfaces The rendering is accessed through the interface portrayal delivery. 7.5. Metadata services This component provides the access to Plan4All metadata to users or to other system components. It implements search/discovery services, thus exposes catalogue services. Search/discovery: the goal of discovery is to support discovery, evaluation and use of spatial data and services through their metadata properties (source: D3.5 – INSPIRE Architecture v2.0). Thus, metadata services perform: - search/discovery (CSW): o search the metadata catalogue for record that matches the user’s search criteria; o extract the results list and pass it to the “portrayal service” through the horizontal service; - extract a single record from the metadata catalogue and pass it to the “portrayal service” through the horizontal service; - allow the content provider to produce, upload and import metadata; - allow the content provider to edit/update metadata. 7.5.1 Operations - get discovery service metadata (get capabilities); - discover metadata: o get metadata records (through search); - get metadata record (by resource unique ID identification).
  49. 49. D5.2 Plan4all Networking Architecture 49/77 7.5.2 Interfaces The component operations are accessed through the interface capture metadata. 7.6. Data services This component implements view and download services, thus exposes map/feature services. View: view services allow display, navigate, zoom in and out, pan or overlay viewable spatial data sets and display legend information and any relevant content of metadata. Download: download services allow extracting copies of spatial data sets, or parts of such sets, to be downloaded and, where practicable, accessed directly (source: D3.5 – INSPIRE Network Services Architecture v2.0). Thus, this component exposes using services to: - produce the layer in raster format (view – WMS) and pass it, “through” the horizontal service, to the “portrayal service”: o produce the “view” (PNG, GIF, …) of a whole data set or a part of in a coordinate system supported optionally through the transformation service exposed by “processing services”); - produce the data in vector format (download – WFS – GML, shapefile) and pass it, “through” the horizontal service, to the “portrayal service”: o allow the download of a whole data set or a part of it; o allow direct access to a whole data set or a part of it; o allow direct access to a feature and to its attributes (structured attributes are managed at the data model level/information viewpoint, e.g. structured attributes inherit the spatial attribute from the feature). This component can use the harmonisation service. Moreover, this component uses the GeoRM services to apply access limitations. 7.6.1 Operations - View services operations (WMS, WFS): o get service metadata (get capabilities); o get map; o get feature information. - Download services operations o get download service metadata (get capabilities); o get spatial objects (get feature); o describe spatial object type (describe feature type); o query spatial objects. 7.6.2 Interfaces The component operations are accessed through the interface capture data. Also, the component uses the following interfaces from other components: - harmonisation services :: mapping data; - horizontal services :: control. 7.7. Processing services This component implements transform services (D3.5 – INSPIRE Network Services Architecture v2.0), thus exposes map/feature transform services. It exposes services to:
  50. 50. D5.2 Plan4all Networking Architecture 50/77 - transform a data set from the native coordinate system to the required coordinate system (SRS transform – e.g. from Gauss Boaga to WGS84); - transform the format of a data set (e.g. from shapefile to GML). 7.7.1 Operations - get transformation service metadata (get capabilities); - transform (transform coordinates). 7.7.2 Interfaces The component operations are accessed through the interface data delivery. Also, the component uses the following interfaces from other components: - data services :: capture data; - horizontal services :: control. 7.8. Harmonisation services This component is invoked by the component Data Services in order to carry out the mapping between the application schemas of Plan4all and the application schemas of the data provided by the partners. The main goal of this component is to perform transformation of data starting from: - input schema (can be a WFS also); - target schema; - schema mapping (metadata/transformation rules). This service can be exploited on two scenarios: - on-the-fly transformation; - upload unharmonised data. The main sub-components should be: - transformation engine (the transformer), which exposes the service to perform the physical transformation; the result is then passed, through the horizontal service, to the “portrayal service”; - the transformation designer, to build the mapping between schemas. This component is used, through horizontal services, by the application services and data services in response to a user agent request. 7.8.1 Operations - transform data. 7.8.2 Interfaces The component operations are accessed through the interface data mapping. Also, the component uses the following interfaces from other components: - horizontal services :: control. 7.9. Registry services This component implements invoke services. Invoke: for spatial data services available on the Internet, the “Invoke Spatial Data Service” service will enable a user or client application to run them without requiring the availability of
  51. 51. D5.2 Plan4all Networking Architecture 51/77 a GIS. This requires that a client application can discover the service, bind to it and invoke it (source: D3.5 – INSPIRE Network Services Architecture v2.0). In this scenario, the registry services component acts as a “service repository” in a basic SOA “publish/find/bind” pattern for distributed system. This component implements the “publish-find-bind” pattern: - publish: register a service in the registry, along with service metadata suitable for further use from a consumer; - find: query the service registry to allow discovery (search) and locate a service to be invoked; the search is performed onto services metadata stored in the repository; - bind: returns the “service metadata” for services stored in the registry to allow the bind and invoke from a service consumer, allowing the service consumer to bind to the service provider. The following diagram shows the “publish-find-bind” pattern. Provider Service Repository (Registry) Consumer (Client) publish find bind SOA publish/find/bind pattern. Basically, this pattern can be described as follows: - the service provider publishes a service into the registry, providing also the service description (capabilities) through service metadata; - the registry (the services repository) allows the search of services and retrieval of their descriptions, by which locate a service; - the service consumer finds services via the registry and binds to the provider using service metadata. 7.9.1 Operations - register service through its metadata; - search service (query service metadata repository); - get service metadata (get capabilities). 7.9.2 Interfaces The component operations are accessed through the following interfaces: - register; - publish; - search. Also, the component uses the following interfaces from other components: - horizontal services :: control.
  52. 52. D5.2 Plan4all Networking Architecture 52/77 7.10. Relations among components The relations among the components may be schematised as follows. General schema.

×