Hi all,
Looking more at Spring I wrote a little article describing what migrating an existing subsystem of GeoServer (Request/Response) to use Spring would look like.
http://docs.codehaus.org/display/GEOSDEV/Springing+GeoServer
-Justin
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
Hi all,
Looking more at Spring I wrote a little article describing what migrating an existing subsystem of GeoServer (Request/Response) to use Spring would look like.
http://docs.codehaus.org/display/GEOSDEV/Springing+GeoServer
Thanks for the great article, and useful example. I have added some headings so it obvious when you are stepping off into new territory rather then simply reviewing how geoserver works now.
The extension at the operation level (like putStyles) is great and needed.
There is some more consequences to think about, I remember having this conversation as part of the OWS-4 breakout but let me review...
- More then one version of a service needs to be supported WMS 1.0 and WMS 1.3
- Each version is made up a specific group of operations (getCapabilities, getMap, putStyles etc...)
- Operations are different between versions - the WMS 1.0 getMap operation is much different then WMS 1.3 getMap
So when you actually put this together for real you may need some additional information to match the request up to the specific implementation they need, you should also be able to dynamical build the capabilities document based on the opperations available registered against that version of the service.
Ah fun stuff, it will be good to see this set up and working.
Jody
Justin Deoliveira ha scritto:
Hi all,
Looking more at Spring I wrote a little article describing what migrating an existing subsystem of GeoServer (Request/Response) to use Spring would look like.
http://docs.codehaus.org/display/GEOSDEV/Springing+GeoServer
That's basically what I had in mind, but I see a little problem: are
you sure every request will have the SERVICE and REQUEST parameters?
I thought the SERVICE called would be the prefix used in:
http://…/geoserver/wms?service=WMS&request=PutStyles
basically contains the indication of WMS twice, and there is no space for
versioning. What if we used the first part after "geoserver" to determine
the service, something like the following:
http://…/geoserver/wms-1.0?service=xxx&request=yyy
-> service wms and version 1.0
Plus, let's say I'd like to expose something that has nothing to do with
opengis, or maybe I want to publish the opengis services thru a Burlap/Hessian/SOAP
approach, and thus I don't have a get/post request with the parameters as above.
I can't do that with the proposed approach, right?
I believe the REQUEST parsing should be left to a plugin class, which in turns, if
it likes, can parse the post/get request and delegate to other plugins for actual
request handling.
What do you think?
Best regards
Andrea Aime
Hi Andrea,
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
Looking more at Spring I wrote a little article describing what migrating an existing subsystem of GeoServer (Request/Response) to use Spring would look like.
http://docs.codehaus.org/display/GEOSDEV/Springing+GeoServer
That's basically what I had in mind, but I see a little problem: are
you sure every request will have the SERVICE and REQUEST parameters?
GeoServer as it stands today requires the SERVICE paramter to function or it will choke. That being said you are right in that there is redundancy in terms of wms being in the context path and in the query string parameter.
The latter being how to map to the particular request to the specific WFS dispatcher. With the new "extension-point" based dispatch system this wont be required.
I thought the SERVICE called would be the prefix used in:
http://…/geoserver/wms?service=WMS&request=PutStyles
basically contains the indication of WMS twice, and there is no space for
versioning. What if we used the first part after "geoserver" to determine
the service, something like the following:http://…/geoserver/wms-1.0?service=xxx&request=yyy
-> service wms and version 1.0
I am pretty sure the spec says that "VERSION" is a required query string parameter as well.
Plus, let's say I'd like to expose something that has nothing to do with
opengis, or maybe I want to publish the opengis services thru a Burlap/Hessian/SOAP
approach, and thus I don't have a get/post request with the parameters as above.
I can't do that with the proposed approach, right?
I believe the REQUEST parsing should be left to a plugin class, which in turns, if
it likes, can parse the post/get request and delegate to other plugins for actual
request handling.
I think this is a good idea, and I would definitley be into doing this, however I think its out of scope in the short term. The work required is just going to be too drastic of a change and I am not sure we have a business driver for it yet.
Also I know the FROGS people have some of this figured out so I dont want to spend time reinventing the wheel in GeoServer if we dont have to. That being said we need to find someone with time on their hands to look at their framework.
Great feedback Andrea, thanks!!
What do you think?
Best regards
Andrea Aime
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
Looking more at Spring I wrote a little article describing what migrating an existing subsystem of GeoServer (Request/Response) to use Spring would look like.
http://docs.codehaus.org/display/GEOSDEV/Springing+GeoServer
That's basically what I had in mind, but I see a little problem: are
you sure every request will have the SERVICE and REQUEST parameters?
I thought the SERVICE called would be the prefix used in:http://…/geoserver/wms?service=WMS&request=PutStyles
basically contains the indication of WMS twice, and there is no space for
versioning. What if we used the first part after "geoserver" to determine
the service, something like the following:http://…/geoserver/wms-1.0?service=xxx&request=yyy
Um this is all defined by a specification, richard gould wrote the client and can tell you how it actually works.
as far as I know SERVICE REQUEST and VERSION are all required....
Richard what can you tell us?
-> service wms and version 1.0
Plus, let's say I'd like to expose something that has nothing to do with
opengis, or maybe I want to publish the opengis services thru a Burlap/Hessian/SOAP
approach, and thus I don't have a get/post request with the parameters as above.
Um WMS and so on have SOAP bindings defined, but your point is valid.
What needs to be done is look into the FROG project (who cholmes contacted and they are willing to play)
and compare notes on a way forward.
But for an OWS service many of these questions are simply answered. perhaps we would need a different entry point for another standard
such as SOAP/Hessian/Burlap?
I can't do that with the proposed approach, right?
I believe the REQUEST parsing should be left to a plugin class, which in turns, if
it likes, can parse the post/get request and delegate to other plugins for actual
request handling.
I see what you say, I just wanted to ensure Justin tought about the "service" idea as a "grouping" of Requests and allowed us to
both reuse requests and define different handlers based on version.
Jody
That's basically what I had in mind, but I see a little problem: are
you sure every request will have the SERVICE and REQUEST parameters?
I thought the SERVICE called would be the prefix used in:http://…/geoserver/wms?service=WMS&request=PutStyles
Hi Andrea, I was just documenting this in my thesis report. The OWS
Common Specification says that (p.36), for all OGC services, the
parameters "service", "request" and "version" are mandatory in every
operation request, except for GetCapabilities. For GetCapabilities, only
"service" and "request" are mandatory, but the optional "AcceptVersions"
parameter _should_ be supported by all clients and servers to support
version negotiation. The optionality of that parameter was for reasons
of backward compatibility it seems...
Cheers!
Jonas