This page last changed on May 10, 2006 by cholmes.

Overview

The main goal of this effort is to rearchitect GeoServer to be as modular as possible. This is inspired by the current best open source projects, like firefox and eclipse - a super solid core model, with additional functionality written by the community of developers and plugged in by others as needed. We already do a decent job of modularization, with DataStores being completely pluggable, the web admin tool being highly decoupled, and a number of other design decisions. But what we really need to modularize is services - WFS, WMS, z39.50. This will turn GeoServer into a sort of web GIS framework - it will provide a web admin tool and access to common GeoTools classes for developers to write web application plug ins. This is an essential step, so that GeoServer does not become bloated with functionality that most people do not want, but so it still can include it if people want to. We have already had several offers of new services that we have turned down in the interest in keeping the central code clean. A modularized GeoServer will allow us to have the best of both worlds. A core GeoServer will likely consist of the WFS, WMS and web administration tool. Then people could download plug-ins for a variety of other services, that would all utilize the same central configuration.

Pluggable Services to offer.

There are many pieces that would be nice to have integrated, right now we have thought of WCS, z39.50 catalog server, OGC catalog server, a metadata editor, a web W*S client, a style editor, sensor web enablement, gazetteer, a geocoder, and a route finder. One project that has a number of these pieces in Java, which would be very interesting to seek collaboration with, is the GeoNetwork Open Source , by the FAO and WFP . They have a WMS client, a metadata editor, and a z39.50 catalog server, all implemented in Java. If we could collaborate on the base framework and then have GeoServer and GeoNetwork just be different distributions of the modules then both projects, and especially the users of each, would benefit incredibly. They could just pick and choose the Spatial Data Infrastructure pieces that they need, based on the role their organization is looking to server in the SDI. We have been recently talking with the geonetwork guys, and it looks like both of us are excited by potential collaboration, combining our resources and communities to make some great software. Making services modular also opens the door to other interesting protocols, such as Alexandria Digital Library gazetteer, or ArcIMS/ArcXML. Expanding on the idea for a common open source data format, it might be interesting to have a MapServer module, that would read from the central configuration files, users would install a compiled MapServer onto their computer. You would get the ease of GeoServer configuration, with the speed of MapServer.

Details

To get into more details of what that framework would actually look like, for a start Axios Engineering has been talking a lot about making it a true J2EE application. This would be great, since it would then easily scale, so that different parts could be spread across different computers. This would open up a new class of potential collaborators. In doing this we would not sacrifice any of the ease of use or installation, as we will still provide one click installers and embedded servlet containers. It would just open the door for power users.

The core framework would offer access to all the J2EE and GeoTools libraries, and most importantly would provide central configuration for all modules. So when you create a new WMS layer, and fill out the capabilities metadata, it would then automatically pre-populate the WFS metadata, as well as start the fields it knows on the metadata editor and catalog server. This would also give a central place for permissions, so you could define certain users as metadata editors, and others with transaction permissions on the WFS. A central administration tool would serve each of the pieces. It would be great if we could come up with a pluggable web admin interface, such that if a service were present then its options would automatically show up.

Another interesting idea would be to provide alternate configuration interfaces, such as through uDIG, similar to how IBM Eclipse and WebSphere work. You would do all your configurations in an embedded GeoServer in uDIG, and then upload your files to the production server.

Conclusions

The key behind this design would be ease of use, modularization so as to be extremely accessible to new developers, and scalability, in that order. We would like to gather a broad group of organizations and individuals to make this happen, as it more work than any one organization could do, so please get in touch if you can help out. TOPP can provide letters of support and in kind work contributions if you are a small company going after contracted funding.

A bunch of us are currently discussing possibilities at: http://lists.eogeo.org/mailman/listinfo/opensdi And there is some wiki space at OpenSDI

Document generated by Confluence on May 14, 2014 23:00