This page last changed on Sep 30, 2005 by jdeolive.

This space is intended to be used as a whiteboard for the design and architecture of the next round of Geoserver: Geoserver 2.0, also known as Geoserver Enterprise Edition.


Over the last few months, much discussion has gone one about what a open-source spatial data infrastructure should like like. Check out Geoserver 2.0 Roadmap for some of the details. The following summarize the major goals of the project:

  • A framework in which geo-spatial web applications and services can be built upon
  • A modular plug-in based architecure which facilitates rapid and easy application development
  • A rich API which enables developers to perform high-level tasks with little effort


In order to define the architecture, dome definitions are in order.

Term Defintion
Component An autonomous software module which performs a particular set of tasks
Service A series of components which work together to provide functionality to the outside world
Extension Point An interface advertised by a component which is intended to be implemented by other components in order to acheive a task
Extension An implementation of an extension point


Building a web service or application is a lot of work. A framework aimed at making this activity easy must factor out the common tasks that any type of service may wish to perform. The following are categories of such tasks.

  • Catalog
  • Query
  • Transaction
  • Security


A central repository for data. Tasks include:

  • archiving
  • population


A mechanism for looking up data based on specific parameters. Tasks include:

  • data access
  • filtering


Facilities for modifying data. Tasks include:

  • data mofication
  • state based transactions (rollback,commit,etc...)


  • verification of user credentials
  • user access control
Document generated by Confluence on May 14, 2014 23:00