Hi,
last winter I’ve tried to introduce the concept of filtering WPS processes so that
admin/developers can control what processes show up in the capabilities documents
and can eventually be described and run:
http://osgeo-org.1560.n6.nabble.com/WPS-process-filtering-and-callbacks-td3820081.html
The discussion stalled on the idea of having a simple generic filter vs storing the process
metadata in the catalog, the window of opportunity was short and I eventually missed it,
so nothing was developed.
I’m back with another (very small) window of opportunity, starting tomorrow and lasting
a week, where I could push to develop the filtering concept I’ve described before
(I got to know about this opportunity only yesterday, apologies for the hurry… ).
Thinking about it, I believe the two concepts would be orthogonal anyways, that is,
the process filter per se is a generic concept that could be used for configuration,
security and system integration, and it could be used to add support for process filtering
configuration regardless of how it’s developed.
The process filter interface would be as simple as:
public interface ProcessFilter {
/**
- Filters out unwated processes
*/
public boolean allowProcess(Name processName);
/**
- Gives the filter an opportunity to wrap the process to exert control on its inputs
*/
public Process create(Name name);
}
and the ProcessFilter instances would be registered in the application context (which would
allow for injection of other bits in the filter, such as configuration related beans).
Making them work is funnier, in that most of the code is actually calling
Processors.createProcessFactory(processName), where Processors is a GeoTools class.
For the filtering to work we have probably two opportunities:
- change the GeoTools Processors API so that it can take the filters somehow (getters/setters, parameters of a new create method?)
- have GeoServer use its own factory class that wraps Processors
Given the short time I would go for the latter, the wrapper would orchestrate processors
and the filters so that the returned ProcessFactory only knows about the processes
we can expose given the current filters.
It also seems to me that filtering processes should not be the job of the library, but one
of the application built on top of it.
In case someone can push the filtering down in GeoTools calling directly ProcessFactory
again would be a matter of a simple code change in a single place, and a refactor to
inline the calls of the GeoServer factory wrapper.
I’m also still keen to allow some configuration, but given the short time window and the
other stuff in my backlog I guess I’ll only be able to add a process whitelist/blacklist in
WPSInfo, and a GUI with checkboxes to choose what gets exposed, and what is not.
In case this is not considered suitable, maybe I could only develop the filtering machinery
without any actual code using it?
Or maybe someone with a desired for more out of the box functionality could tag
team with me and help adding the extras (whatever those might be)?
Cheers
Andrea
–
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
