GeoServer学习手记（六）：Servlet及HTTP派发过程之三

GeoServer学习手记（六）：Servlet及HTTP派发过程之三

转载 粟卫民http://www.gisdev.cn/ http://blog.csdn.net/suen/ 日期：2009-10-31

接上篇《GeoServer学习手记（五）：Servlet及HTTP派发过程之二》（http://blog.csdn.net/suen/archive/2009/11/02/4759398.aspx）。

Response
The Response is the processing of what is sent back to the user after their request. The format of this rsponse, for a getFeature request, is GML.

Here is an overview of the process in picture format:
 

Where it Starts

At the very beginning, in WfsDispatcher, an HttpServeletResponse is passed into doGet() and doPost()

public void doPost(HttpServletRequest request, HttpServletResponse response)        throws ServletException, IOException public void doGet(HttpServletRequest request, HttpServletResponse response)        throws ServletException, IOExceptionLets refer back to this diagram:
 

This response object is passed into the Feature servelet, so it can be populated once it has a hold of a FeatureReader.

Output Strategy Object

The output strategy object tells Geoserver how to proceede when returning the data. What does this mean? Here are some examples that are specified in the web.xml file to help explain it:

    serviceStratagy        SPEED  Why is it called Strategy? A Strategy is a design pattern that is defined in the Gang of Four Design Patterns book (ISBN 0201633612). What it essentially does, is allow the user to plug in their own method of performing a specific task. So what Geoserver does is read the web.xml file, see what strategy you want to use (‘speed’ in our example), and plug it into the output response process.

You can define your own output strategy object by looking in org.vfny.geoserver.servlets.AbstractService. It must implement org.vfny.geoserver.servlets.AbstractService.ServiceStrategy

Here is a tutorial on setting up your own output strategy.

Feature Streaming

Its very important to note that the Geoserver/Geotools design allows for Feature Streaming, meaning that Geoserver only ever has around one feature in memory at a time. This is very important for large queries (or you’d run out of memory) as well as simutaneously doing multiple queries.

When a DataStore accepts a Query, it doesnt actually return Features, instead it returns a FeatureReader which can be used to read the Feature that the Query selects one-at-a-time. The delegate (ie. GML2 producer in our example) reads a single feature, converts it to GML2 and send the results off to the output Strategy object.

GML Encoding

After the output strategy has been determined, the Feature sends the output to a FeatureResponse object. This feature response object will then pass on the information to the GML2FeatureResponseDelegate object.

The GML encoding object will take care of the rest of the output for you that will be streamed through the output strategy.

The End

Notes
How Datastores process Query & Filter

Some DataStores (like the Database backed ones) can do most of the Filter processing in the database using the database’s indexes. Other datastores can do “quick” processing of certain components of the Filter. For example, the “normal shapefile” datastore can quickly do bounding-box tests for features. The “index shapefile” datastore (thats a shapefile with a .qix spatial index file) can do spatial searching quickly.

Basically, the Filter object is sent to the datastore which looks at the Filter and beaks it into components:

portions that the datastore can index (ie. quickly approximate a solution)
portions that the datastore can efficiently calculate (ie. quickly calculate a solution)
portions that the datastore cannot efficiently calculate (these will be handled by Geotools Java code)
All this is handled transparently by the datastore so the programmer just has to send a Query object off to the DataStore and not have to worry about how it processes it. The features returned by the FeatureReader will only be ones that pass the Filter conditions.

Lets looks at a PostGIS example for a Query’s Filter that looks like this:

(the_geom INTERSECTS ) AND (population > 1000000)

This will be translated into the SQL query:

SELECT … FROM WHERE

     the_geom &&  — this is the spatial index operation
 AND intersects(the_geom,  )      — this is the full OGC spatial operation
 AND population > 1000000;
The same query to the “normal shapefile” datastore will be processed differently. The shapefile datastore can perform bounding-box vs bounding-box operations quickly because the shapefile has the bounding of each geometry stored.
The read processing is done in two states: (a) shapefile optimized and (b) Java-code handled.
foreach row in the shapefile
     If the row’s bounding box overlaps the
       THEN send this row to the next stage
       OTHERWISE this feature does not pass the Filter condition
Java code will then take the “approximate” solution that the datastore can quickly compute and fully evaluate the Filter.
The same query to the “indexed shapefile” datastore can be processed even more effiently. Instead of having to read large portions of the shapefile to test EVERY row to see if the bounding box intersects the search bounding box, it can just read a portion of the spatial index. Java code will then take this “approximate” solution that the datastore can very quickly compute and fully evaluate the Filter.
1.6版之后的HTTP派发过程
（未完待续）
 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/suen/archive/2009/11/02/4759410.aspx

转载自：https://blog.csdn.net/xinruogis/article/details/5340420