[Geoserver-devel] The rabit hole

GeoServer GeoServer Developer
1

This is an ignorable email :slight_smile: Just collecting my thoughs, and setting GeoServer / uDig up for a bit of fun. Most of the fun is in GeoServer...

What is needed here is a classic 3 tier architecture, uDig by iteself forms classic 2 tier architecture (admittedly it is supposed be non classic publish/find/bind ).

You could argue that GeoServer actually represents a middle tier, it does perform higher level opperations ontop of a database, or shapefiles ... no argument there.

Problem is it is GeoSrever is stateless ... and three tiered applications are generally not, in particular I need to go stateful.

Now we already have the concept of Transaction to make geotools stateful, and that is what I will need to do. Modify WMS and WFS to notice J2EE session information in a Transaction.State. In uDig life is easy.

Where the fun comes is in making GeoServer stateful:
1. Aware of J2EE sessions (eek! vendor specific extention?)
2. Getting session down to the DataStore level
3. Using session along with shared connection pools, connections and probably DataStores with another
web application (I can put them in the same WAR if needed).

Admittedly the normal Web Server concept of user would be sufficient isolation (I don't need Back/Forward isolation like in a JSP application) this is a thick client coming to call. Both GeoServer and another J2EE application could use this to share enough state for both to see the same picture from the databases (Hrm: say Oracle long transaction support ).

We are not too far off (surprise), connection pools is often requested (and is something GeoServer should do to play nice in a proper J2EE install). The Data interface is published into the application context where it can be hunted down by other applications.

Alternatively the other application can publish up a different object into the Data slot (one that pays attention to credentials) and the rest of GeoServer can work unaware. This would be the same solution that would allow different users to "see" different GetCapabilities, indeed this could be based on path as well (an often cited need is to sever different content to different users, or let different paths see different content - as path based access control can be offloaded to Tomcat/Apache...).

Smart - wonder if justin though of this?

So what I need (in addition to an diagram of Justin's New Design) is basically for the OpenSDI mailing list to rock out. Since they have not, I am going to lay stuff out - this week. The end goals are the same and OpenSDI can catchup when someone tells them.

Thanks for the J2EE research Justin, I will post my breakdown of the current GeoServer architecture shortly.

Jody

2

Hi Jody, looks like you are having some fun getting back into the J2EE space.

Jody Garnett wrote:

This is an ignorable email :slight_smile: Just collecting my thoughs, and setting GeoServer / uDig up for a bit of fun. Most of the fun is in GeoServer...

What is needed here is a classic 3 tier architecture, uDig by iteself forms classic 2 tier architecture (admittedly it is supposed be non classic publish/find/bind ).

You could argue that GeoServer actually represents a middle tier, it does perform higher level opperations ontop of a database, or shapefiles ... no argument there.

Agreed.

Problem is it is GeoSrever is stateless ... and three tiered applications are generally not, in particular I need to go stateful.

Now we already have the concept of Transaction to make geotools stateful, and that is what I will need to do. Modify WMS and WFS to notice J2EE session information in a Transaction.State. In uDig life is easy.

Where the fun comes is in making GeoServer stateful:
1. Aware of J2EE sessions (eek! vendor specific extention?)
2. Getting session down to the DataStore level
3. Using session along with shared connection pools, connections and probably DataStores with another
web application (I can put them in the same WAR if needed).

Yeah, GeoServer isn't really stateful in the J2EE way, we have kind rolled our own thing here. Understandably though, being in the spatial world the requirements of the transaction system are a bit more complicated then what is typically handled by EJB and the such.

Admittedly the normal Web Server concept of user would be sufficient isolation (I don't need Back/Forward isolation like in a JSP application) this is a thick client coming to call. Both GeoServer and another J2EE application could use this to share enough state for both to see the same picture from the databases (Hrm: say Oracle long transaction support ).

We are not too far off (surprise), connection pools is often requested (and is something GeoServer should do to play nice in a proper J2EE install). The Data interface is published into the application context where it can be hunted down by other applications.

Yup, the point of making geoserver and geotools "container friendly". As the motto goes, dont call us, we will call you. :slight_smile:

Alternatively the other application can publish up a different object into the Data slot (one that pays attention to credentials) and the rest of GeoServer can work unaware. This would be the same solution that would allow different users to "see" different GetCapabilities, indeed this could be based on path as well (an often cited need is to sever different content to different users, or let different paths see different content - as path based access control can be offloaded to Tomcat/Apache...).

Smart - wonder if justin though of this?

Not sure I agree here, or at least there needs to be a bit more. The more I think about how to do the credential thing well, it needs to be done at the data level. Something that ties directly into datastores so that authentication mechanisms used by them (like permissions / access control in a database) can be picked up.

This coupled with what you describe, handling access control on the request would be good. Like you say, offloading to the container / webserver to do some of the work.

So what I need (in addition to an diagram of Justin's New Design) is basically for the OpenSDI mailing list to rock out. Since they have not, I am going to lay stuff out - this week. The end goals are the same and

Thanks for the J2EE research Justin, I will post my breakdown of the current GeoServer architecture shortly.

It was farily short lived, and i would have liked to do more of it, but there is so much stuff to take in.

Thanks for the architecture write up jody, something that will make a sweet addition to the docs.

Jody

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org