GeoServer Web Based Configuration Design DRAFT. GeoConnections Victoria, BC, Canada

Transcription

1 GeoServer Web Based Configuration Design DRAFT Submitted To: Program Manager GeoConnections Victoria, BC, Canada Submitted By: David Zwiers Jody Garnett Richard Gould Refractions Research Inc. Suite Douglas Street Victoria, BC, V8W-2E7 Phone: (250) Fax: (250)

2 TABLE OF CONTENTS GEOSERVER WEB BASED CONFIGURATION DESIGN...1 TABLE OF CONTENTS...2 TABLE OF FIGURES...3 INTRODUCTION CURRENT GEOSERVER CONFIGURATION CURRENT CONFIGURATION WORKFLOW PROPOSED GEOSERVER CONFIGURATION DESIGN MEMORY MODEL SERVICE CONFIGURATION CATALOG CONFIGURATION GEOSERVER WEB CONFIGURATION USER INTERFACE MODEL-VIEW-CONTROLLER MODIFIED MODEL-VIEW-CONTROLLER GEOSERVER WEB CONFIGURATION DESIGN USER INTERFACE DESIGN GEOSERVER WEB CONFIGURATION WORKFLOW SAMPLE GEOSERVER CONFIGURATION WEB PAGES WFSCONFIG WMSCONFIG CATALOGCONFIG

3 TABLE OF FIGURES Figure 1 Overview Diagram...6 Figure 2 Model-View-Controller Design Pattern Figure 3 Modified Model-View-Controller Design Pattern Figure 4 Interface Flow Diagram Figure 5 User Interface Template Figure 6 Interface Page Layout Figure 7 WFSConfig Page 1: Description Figure 8 WFSConfig Page 2: Contents Figure 9 WMSConfig Page 1: Description Figure 10 WMSConfig Page 2: Contents Figure 11 CatalogConfig Page 1: DataStores Figure 12 Catalog Configuration Namespaces Figure 13Catalog Configuration Styles Figure 14 Catalog Configuration Feature Types

4 INTRODUCTION This document represents our proposal for extending the GeoServer application with a Web Based Configuration. Currently GeoServer makes use of a series of XML files to store configuration information. Server configuration is performed when the server is offline through the manual editing of these files. We intend to improve this on two fronts: the interface and the server state. This extension to Geoserver will provide a Web Based user interface to the configuration. In addition we will provide dynamic configuration of the GeoServer application. Dynamic configuration will avoid unnecessary server restarts and allowing configuration to be tested prior to saving

5 1 CURRENT GEOSERVER CONFIGURATION GeoServer has recently changed its configuration as part of a Web Map Server integration effort. As such the current design is of recent vintage and sparsely documented. 1.1 Current Configuration Workflow Load a series of configuration XML files into: ServerConfig WMSConfig: Web Map Server information WFSConfig: Web Feature Server information (used in the GetCapabilites) CatalogConfig: FeatureType and Namespace information The existing system has the data stored in multiple classes all found in the org.vfny.geoserver.config package. Each class has three main purposes: to store data required by the application to provide data to the application to populate configuration data from XML files The configuration data is imported into the system exactly once at startup. The data is then served to the application in various forms. In most cases, it is not possible to modify application configuration dynamically as GeoServer is running. The exception occurs in the CatalogConfig class, where references to XMLSchema files are passed to the DescribeFeatureType response

6 2 PROPOSED GEOSERVER CONFIGURATION DESIGN To address the limitation of the existing GeoServer Configuration System we intend to: Separate out the Configuration Model from the GeoServer application Separate out Loading Configuration from the Configuration Model Allow saving of the Configuration Model Although this work will initially make use of the existing GeoServer configuration XML files we may need to store additional information or make use of alternate storage formats. An example would be storing additional FeatureType Schema information as the metadata in the database. Here we intend to provide a basic system overview of the portion of Geoserver being affected. The portion shown in Figure 1 represents what is currently the configuration module in package org.vfny.geoserver.config. The Application module represents the remainder of the Geoserver, where the interface into the Application remains the same as that defined for the configuration module. WFS WMS Catalog GeoTools2 init config GeoServer Configuration Memory Model Load Save Struts ActionForm Web Browser Forms Shape Database XML cookie Figure 1 Overview Diagram - 6 -

7 2.1 Memory Model The memory model will allow us to complete a separation of concerns between the data being stored, the importing of the data, and the use of the data. Since the GUI will be updating this information on the fly we have adopted the Model View Controller (MVC) pattern. This will allow the GUI and the Application to view the data at the same time. The controller portion of the model is to be completed by; the Init portion at the system start-up, and; the modifications made by the GUI. The Memory model classes will consist of a set of data classes. These classes will be Beans, and will provide full access to all the data. This is important to allow the GUI to implement dynamic configurations. This is one of the important changes from the existing design. We will be implementing a layer of indirection between the Application and the Memory model, as shown in Figure 1, which will restrict access to the memory model from the application to current levels. We will be collecting the Init functionality from the current constructors and collapsing this into a cohesive module. This will not affect the current data access permissions, as they currently do not exist. The WFS, WMS, and Catalog Modules are intended as an interface to the Application. We envision these modules to contain more than some simple access routines. At the very least the Catalog module will create the data sources in the same way as they are created in the DataStoreConfig class. We intend to extract similar duplicate functionality from the Application to place it in the appropriate module. The code below has been included to share a sample memory model. In this model the Catalog, Global, WMS and WFS classes as these classes represent the base of the model

8 2.2 Service Configuration Web Map Server Model public class WMSModel { private static final String WMS_VERSION = "1.1.1"; /** WMS spec specifies this fixed service name */ private static final String FIXED_SERVICE_NAME = "OGC:WMS"; private static final String[] EXCEPTION_FORMATS = { "application/vnd.ogc.se_xml", "application/vnd.ogc.se_inimage", "application/vnd.ogc.se_blank" ; private Date updatetime = new Date(); private Service service; Web Feature Server Model public class WFSModel extends Service { public static final String WFS_FOLDER = "wfs/1.0.0/"; public static final String WFS_BASIC_LOC = WFS_FOLDER + "WFS-basic.xsd"; public static final String WFS_CAP_LOC = WFS_FOLDER + "WFS-capabilities.xsd"; private String describeurl; private Service service; Service Model public class ServiceModel { private boolean enabled = true; private String servicetype; private String onlineresource; private URL url; private String name; private String title; private String _abstract; private List keywords; private String fees; private String accessconstraints = "NONE"; private String maintainer; - 8 -

9 2.2.4 Global Model public class GlobalModel { private static final Logger LOGGER = Logger.getLogger("org.vfny.geoserver.config"); private Level logginglevel = Logger.getLogger("org.vfny.geoserver").getLevel(); private int maxfeatures = 20000; private boolean verbose = true; private int numdecimals = 8; private Charset charset; private String baseurl; private String schemabaseurl; private static final String CONFIG_DIR = "WEB-INF/"; private static final String DATA_DIR = "data/"; private Contact contact = null; Contact Model public class ContactModel { private String contactperson; private String contactorganization; private String contactposition; private String addresstype; private String address; private String addresscity; private String addressstate; private String addresspostalcode; private String addresscountry; private String contactvoice; private String contactfacsimile; private String contact ; - 9 -

10 2.3 Catalog Configuration Catalog Model public class CatalogModel { private Map datastores; private Map namespaces; private Map features; private Map styles; private NamespaceSupport defaultnamespace; DataStore Model public class DataStoreModel { private String id; private NamespaceSupport namespace; private boolean enabled; private String title; private String _abstract; private Map connectionparams; Feature Type Model public class FeatureTypeModel { private DataStore datastore; private Envelope latlongbbox; private int SRS; private FeatureSchema schema; private Map styles; private String name; private String title; private String _abstract; private List keywords; FeatureTypeSchemaModel public class FeatureTypeSchemaModel { private String name; private String pathtoschemafile; private String schemabase; private List schemaelement; public class FeatureSchemaElement { private String name; private boolean nillable; private int minoccurs; private int maxoccurs; private String type; private Map restrictions;

11 3 GEOSERVER WEB CONFIGURATION USER INTERFACE This section contains information about the GeoServer Web Configuration User Interface. The intended workflow and user interface design is presented. The proposed new GUI will allow a user to create the GeoServer XML configuration files using a friendly web-based interface. The GeoServer Web Configuration User Interface will provide a configuration for WFS, WMS and Catalog systems. The GeoServer development team has provided guidance in the selection of the STRUTS application framework. We will explore the design of the STRUTS framework and the implications for the GeoServer Web Configuration User Interface. 3.1 Model-View-Controller Model-View-Controller is a traditional design pattern used in Object-Oriented design since the early days of Smalltalk. User Actions Controller State Change View Selection State Query View Change notifcation Model Figure 2 Model-View-Controller Design Pattern Model-View-Control has several advantages: Separation of concerns between the Model, View, and Controller Uses notify/subscribe protocol and the Observer pattern between Model and View Allows multiple Dynamic Presentations Consolidate Control For web based development strict MVC cannot be used due to limitations of the HTTP protocol. The notify/subscribe notification cannot be used and server applications cannot push change notification to the web client

12 3.2 Modified Model-View-Controller The STRUTS Application Framework makes use of a modified Model-View- Controller design. View Controller Model Presentation Layer Control Layer Application Logic Figure 3 Modified Model-View-Controller Design Pattern To address the limitations of the MVC design STRUTS, and indeed many web applications, make use of a flattened Model-View-Control design. In which all model-view communication is funneled through the controller

13 4 GEOSERVER WEB CONFIGURATION DESIGN Each configuration area of the interface will be processed through the ActionForm. The ActionForm class acts as the Controller in STRUTS based applications. The configuration information will be stored in memory using a series of Java Beans representing our Configuration Model. WFS Interface WFS JavaBean WMS Interface Action Form WMS JavaBean Catalog Interface Figure 4 Interface Flow Diagram Catalog JavaBeans

14 4.1 User Interface Design STRUTS makes use of a framework called Tiles, which allows for the separation of web page layout from content. As a starting place we will be making use of the following layout. Web Browser - GeoServer url: Logo Current Location Login Logout Help Tab1 Tab2 Status Try Out Save Load Form Actions Features of this layout: Figure 5 User Interface Template configuration section is sub-divided into relevant pages accessible through tabs at the top of the screen GeoServer status information updates are contained in the top of the left Global Operations are displayed at the left-middle Available actions are displayed in the bottom-middle The current form is also displayed

15 4.2 GeoServer Web Configuration Workflow The basic layout of the configuration interface is presented in figure 6. loginpage loggedinmenu ValidationConfig Description SystemConfig WFSConfig Contents Related Pages DataStores WMSConfig CatalogConfig Namespaces Description Styles Contents FeatureTypes Related Pages Related Pages Figure 6 Interface Page Layout Once the user is logged in, they have the option of accessing the WFS configuration, the WMS configuration or the Catalog configuration

16 5 SAMPLE GEOSERVER CONFIGURATION WEB PAGES 5.1 WFSConfig The WFS configuration is divided into two pages, Description (Figure 7) and Content (Figure 8). Web Browser - GeoServer url: Web Feature Server Configuration Current changes have not been saved. Description Contents Login Logout Help Name: FreeFS Title: The Open Planning Project Basemap Server To Geoserver Save XML Load XML Access Constraints: Fees: Maintainer: Key Words: NONE NONE The Open Planning Project WMS, TEST, NY, NEW YORK Abstract: This is a test server. It contains some basemap data from New York City. Submit Reset Figure 7 WFSConfig Page 1: Description Web Browser - GeoServer url: Web Feature Server Configuration Current changes have not been saved. Description Contents Service Type WFS Login Logout Help Enabled Online Resource URL To Geoserver Save XML Load XML DescribeURL Feature List Feature 1 Feature 2 Feature 3 Namespace foo foo foo Create Feature Edit Feature Submit Reset Figure 8 WFSConfig Page 2: Contents

17 5.2 WMSConfig The WMS configuration is almost identical to the WFS configuration. The Contents page features an updatetime field instead of a describeurl field. Web Browser - GeoServer url: Web Map Server Configuration Current changes have not been saved. Description Contents Login Logout Help Name: FreeWMS Title: The Open Planning Project Basemap Server To Geoserver Save XML Load XML Access Constraints: Fees: Maintainer: Key Words: NONE NONE The Open Planning Project WMS, TEST, NY, NEW YORK Abstract: This is a test server. It contains some basemap data from New York City. Submit Reset Figure 9 WMSConfig Page 1: Description Web Browser - GeoServer url: Web Map Server Configuration Current changes have not been saved. Description Contents Service Type WMS Login Logout Help Enabled Online Resource URL To Geoserver Save XML Load XML UpdateTime Feature List Feature 1 Feature 2 Feature 3 Namespace foo foo foo Create Feature Edit Feature Submit Reset Figure 10 WMSConfig Page 2: Contents

18 5.3 CatalogConfig At the top of each Catalog configuration page, there is a drop down box that can be used to select the object currently being edited. Web Browser - GeoServer url: Catalog Configuration Current changes have not been saved. To create a feature, you must enter at least one datastore, namespace and style. DataStores Namespaces Styles Current DataStore: bizkaia.sde Datastore ID: bizkaia.sde Enabled: Features Login Logout Help To Geoserver Save XML Load XML New Datastore Delete this DataStore Namespace: Description: cgf British Columbia sample road shapefiles Connection Parameters: "dbtype"="arcsde" "server"="localhost "port"="5151" instance"="sde" "user"="sde "password" ="carto" Submit Reset Figure 11 CatalogConfig Page 1: DataStores Web Browser - GeoServer url: Catalog Configuration Current changes have not been saved. To create a feature, you must enter at least one datastore, namespace and style. DataStores Namespaces Styles Features Current Namespace: topp URI: Login Logout Help To Geoserver Save XML Load XML Default: Prefix: topp Submit Reset New Namespace Delete this Namespace Figure 12 Catalog Configuration Namespaces

19 Web Browser - GeoServer url: Catalog Configuration Current changes have not been saved. To create a feature, you must enter at least one datastore, namespace and style. DataStores Namespaces Styles Current Style: thick outline ID: thick outline Default: Features Login Logout Help To Geoserver Filename: styles/polyshp.sld Save XML Load XML Submit Reset New Style Delete this Style Figure 13Catalog Configuration Styles Web Browser - GeoServer url: Catalog Configuration Current changes have not been saved. DataStores Namespaces Styles Current FeatureType bc_roads Features Login Logout Help To Geoserver Save XML Load XML New FeatureType Delete This FeatureType Name: SRS: Title: latlonboundingbox Attributes Key Words: Abstract: Name: the_geom: LENGTH: bc_roads test bc roads , , Calculate from DataStore WMS, TEST, NY, NEW YORK This is a test server. It contains some basemap data from New York City. bc_roads_type type="gml:multilinestringpropertytype" nill... nillable="true" minoccurs="0" maxoccurs="1"... BTRN_BC_ID: type="xs:int nillable="true" minoccurs="0".. Submit Reset Figure 14 Catalog Configuration Feature Types