GeoServer : GeoServer 2.0 Technology
This page last changed on Nov 03, 2005 by jdeolive.
This page summarizes some of the research that has been going on with regard to the Geoserver 2.0 project. Its mosly a summary of various candidate technologies.
The following is a summary of the criteria being used to evaluate new technologies to base the next round of geoserver on.
Most modern frameworks employ a plug-in architecture. This is necessary for the following reasons:
A plug-in framework is good, but an easy-to-use plug-in framework is better. Easy-to-use is a loose term so lets try to be a little bit more specific:
Unless an API is well documented, which includes examples/articles of how to use it, no one will use it. Furthermore, the more documentation that exists is the less we have to write.
Its tedious to when writing a component of some sort to have to hack xml configuration files directly. Having tools to eleviate these sorts of tasks can increase developer productivity and at the same time keep them from going insane.
One of the reasons that eclipse is so successful is that they have an IDE that directly supports their component model.
Many frameworks impose some sort of programming model on the developer. As an example, Eclipse makes use of extension points, and extensions (if these terms mean nothign to you don't worry). What this model does is lay down the ground rules that components should follow when interacting with the framework, and with other components. As the complexity of a system grows, these kind of rules become vital to managing components.
People are often constrained by the technologies they "have" to use. For instance, most people have the need to be able to run GeoServer on their specific J2EE application server. For this reason the GeoServer technology must be able to integrate with existing technologies, most notibly J2EE.
For this reason the GeoServer framework must be suitably light-weight.
There are a mountain of frameworks for doing various things out there. However most of these frameworks are not successful in that they do not withstand the test of time. The last thing we want is to stick our developers with a dying technology. So we need to be careful to choose a technology that will be around in 5 years.
In doing so, we will be able to use an existing and well established developer community in order to nurture and grow our own. The growth of the underlying technology will untimatley dictate the growth of GeoServer 2.0.
It will help to have an example application to work with as we examine the different technologies. Since one of the geoserver 2.0 goals is to allow people to quickly develop new services, let us focus there.
The example will be a simple web application which handles GetCapabilities requests for an arbitraty service. The application must be structured in a way which allows new types of services to be plugged in.
Lets start with a simple interface.
And a couple of implementations:
The above classes make up the domain model for the example application.
Now that we have our criteria somewhat nailed down and an example to work with, lets start looking at the candidate technologies.
The primary goal of the Geronimo project is to build a fully certified J2EE implementation bringing together many other projects which implement various parts of J2EE. Examples include Jetty, Derby, OpenEJB, and more...
At the core of the project is the Geronimo Kernel and the GBeans architecture. The geronimo kernel is essentially and IoC container. Components that live inside the container are called Gbeans. Lets introduce with an example. The following denotes a plain old java interface Foo, and two implementations of Foo: FooImpl1,FooImpl2.
Nothing earth shattering here. Ok, so what the following code does is fire up the kernel, and load our components into it
Ok so lets look at this code a bit closer.
The first thing it does is creates an instance of the kernel (our container) and fires it up. No real magic here.
The next thing that happens is that a GBeanInfoBuilder is created. The role of this class is to build up the metadata for our object, in this case an instance of FooImpl1. Put another way, it is used to build up the things that our component wishes to expose to other components (interfaces, attributes, operations, etc...).
Next, an instance of GBeanData is created. This is essentially the bean itself. It contains all the metadata from above, plus an unique identifier, which is an instance of ObjectName. This is a construct from the JMX (Java Management Extensions) specification. Among other things, its role is to identify the bean.
Next, the beans are loaded into the kernel. This only loads the beans, it does not create the underlying components (instances of FooImpl1, and FooImpl2).
And lastly, the beans are started. Starting a bean actually creates the underlying component and starts its life-cycle.
Ok so what, that was a lot of work, what is the big deal? Well there are a few things to note about the Geronimo kernel architecture:
Next let us investigate how some client code would be able to use our components. Consider the following code:
Some more things to note:
The GBean architecture employs a nice plug-in architecture. The indirection provided by the kernel keeps components nicley isolated from each other while at the same time providing easy access. Being used as the core of a full-blown J2EE server pretty much proves it to be robust. And being integrated with various other projects hints at its flexibilty.
The Geronimo kernel itself is farily low-level. The provided example is about as simple as it gets and amounted to close to a few dozen lines of code. It is clear that higher-level constructs are needed to make things easier to use. These constructs may already exist, however the project is still very young and hasn't had a 1.0 release yet. Documentation is sparse.
I dont think much here needs to be said, the geronimo project itself is one big integration of a handful of projects such as OpenEJB, Jetty, Derby, etc... The kernel is sufficiently lightweight enough to embedd in other applications.
The project is still young however enough of the major players have shown interest to ensure that the project will make it to the 1.0 release and beyond. How successful it will be after that, well only time will tell.
J2EE may be used as the base framework for GeoServer 2.0.
To be done...
To be done...
The recently released 4.0.3 version of JBossAS is built around the new JBoss Microcontainer that should make it possibile to use the same configuration and plugins, both with standalone apps and inside a J2EE container.
There're no doubt about this point for JBoss...
|Document generated by Confluence on May 14, 2014 23:00|