The global package is where all the application information for the running of GeoServer lives. There are two sub-packages, dto and xml. DTO stands for Data Tranfer Object, and it is used to add a layer of separation between the configuration and the application layers. The DTO objects are used to communicate from the web admin tool and from the xml readers to the running GeoServer application. This allows the global package to not depend on a persistence method or the dynamic configuration system. The DTO objects can also be persisted, and sent over the wire, as would be done if GeoServer moved to a JXM management system. The xml package contains the configuration readers and writers, to persist the current application state.
One topic in the global package worth examining a bit is the question of data access, as that's primarily what GeoServer does, provides different ways of accessing data over the web. The first thing to understand is that GeoTools handles all the dirty details of the actual backend data types. GeoServer just communicates through the DataStore interfaces. The GeoServer code base has absolutely no knowledge of PostGIS, of Oracle, of Shapefiles, ect. These are all plug-in DataStores, provided in jars in the lib/ directory. All GeoServer knows is the connection parameters that you provide, and it asks the DataStores it has knowledge of any of them can handle the params. These DataStores are then stored in the Data class, which is where responses look up which data their requests want. Each DataStoreInfo class contains the connection parameters to connect to its appropriate back end data type. And each DataStore contains one or more FeatureTypes. A FeatureType is akin to the DescribeFeatureType XML response in WFS - it knows the meta information about a number of Features. All Features with the same FeatureType have the same structure - the same attributes and type of Geometry. In a database each FeatureType represents a single table - in a file format such as Shapefile a DataStore could be the directory and the FeatureType a single file. Some files could also include a number of FeatureTypes. We use FeatureType, which is the WFS way of referring to them, but one could just as easily call it a 'Layer', as the WMS does.
Each FeatureType has a FeatureTypeInfo class, which mediates between GeoServer and GeoTools. GeoServer allows users to limit their FeatureTypes, and this is done in the FeatureTypeInfo class, using the GeoServerFeatureStore. A FeatureStore is a GeoTools object that offers streaming access to a particular FeatureType in a DataStore. The FeatureStore takes queries and returns FeatureResults, which can then be turned into GML or rendered into images.
The FeatureStore can also return the FeatureType, which can be turned into a DescribeFeatureType response, using a FeatureTypeTransformer. A subclass of FeatureStore, called FeatureLocking, provides Locking functionality, to complete the possible WFS requests of GetFeatureWithLock and LockFeature (GetCapabilities is done completely in GeoServer, it just makes use of the FeatureTypeInfo class, which contains the meta information specific to a WFS).
The UML Class Diagram shows how GeoServer handles the configuration files and how it populates the data configuration objects. It shows even the relations and dependancies between global objects and DTOs.
The memo in the upper left corner shows how the configuration plug-ins are integrated with the STRUTS engine, but the user/developer can always recall the configuration loader/updater.
