This page last changed on May 01, 2007 by cholmes.

Overview

Creating a dispatch system that can dynamically dispatch to an open web service.

Proposed By

Justin Deoliveira

Proposal Type

Module Change
Module Additions

Assigned to release

The current target will be GeoServer 1.6.

State

Completed

Links

JIRA task:

Email discussion:

Other wiki discussions:

Voting History

Andrea +1
Rob +1
Alessio +1
Chris +1

Dependencies

GSIP 6 - Track GeoTools Trunk

Motivations

There are issues with the current GeoServer service model. Adding a new service involves:

  1. Changing the dispatcher
  2. Extending a ( now somewhat complicated ) interface ( AbstractService )

Ideally adding a new service to GeoServer can be done via a plugin, without any modifications to core code. Furthermore, the ideal that services are nothing more then plain old java objects which don't extend any particular interfaces lowers the bar making it less work to write a new service.

In support of this is a new dispatch system which is capable of reflectively dispatching operations to services. Also providing other functionality such as version negotiation for services which implement multiple versions of a particular service.

Such a system has been developed as part of the Open Web Services 4 project. It has been well tested and is the base of which wfs 1.1 support has been built on. This proposal amounts to porting modules from the ows4 branch to GeoServer trunk.

Implementation

Implementation will fall into two major steps:

Porting Dispatcher

This will involve porting the new dispatch system from the ows4 branch. Along with the dispatch system itself are a few new modules it depends on. Most importantly the ows service model.

Adapting Existing Services

Once the dispatch system is in place, existing services will need to be adapted to it. To minimize the impact on existing code adapters which completely wrap the old service implementation will be developed.

Participants

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