Hi all,
The last couple of weeks I have been hammering out a proposal for the
configuration redesign / rearchitecture. I believe it is in a state to
where it is ready for the GSIP process. So... here it is:
http://docs.codehaus.org/display/GEOS/GSIP+8+-+New+Configuration+System
I hope to bring it up as a discussion item in todays IRC meeting, and to
start the ball rolling on the evaluation process.
-Justin
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
This all makes sense, at a technical level, but I still think we are missing something important, that might buy us a truly easy to use (deploy) system sometime in the future.
Everything is pointing towards major jurisdictions sharing common data models (Feature Types), and the motivation for establishing a server will be to implement these...
and little players will follow suit, delivering a mixture of common types (roads, stuff monitoring, environment indicators)
and if you think about this just a little you will see two patterns that will emerge in config land...
1) deploying a service to meet the technical and metadata standards of the environments the service is deployed into...
eg, State of Maine transport services may need to conform to "service profiles" for State of Maine enterprise architecture, MaineTransport agency enterprise architecture, US transport common standards, but may of course also include a few locally defined traffic analyses, proposals for new roads, etc.
ISO 19106 and the Web Services Interoperability forum (wsi.org) have formally defined the requirements of such "service profiles"
So, conceptually, you should look at importing most of the service metadata from one or more externally defined service profiles. (FYI I have started, with a state agency driving the work, a Sourceforge project for a toolkit to turn multiple inheritance into a single, flat conformance class, to support conformance testing, documentation generation and, of , course configuration. )
I dont expect this to be incorporated overnight, or even in advance of the registries that will publish such service profiles, but I'd like to see the configuration system take into account external sources of configuration, with the UI being used to confirm, and augment configuration where the external config doesnt specify required values
2) ease of use - loading instead of creating configs
Config objects should be able to be shared, and loadable from external sources.
this could also provide for the ability to import from foreign formats (including incompatible older configurations!)
I'd imaging architecting in some sort of adaptor class for differing config sources, and an import workflow that loaded multiple config objects, then gave the user the oppotunity to load a new object (eventually searching in an external catalog) or create one.
I know I've said all this before, but its worth saying again. NB TOPP has a grant to make geoserver serve USGS framework data sets - this is a good example of the deployment use case we should analyse.
Rob A
Justin Deoliveira wrote:
Hi all,
The last couple of weeks I have been hammering out a proposal for the
configuration redesign / rearchitecture. I believe it is in a state to
where it is ready for the GSIP process. So... here it is:http://docs.codehaus.org/display/GEOS/GSIP+8+-+New+Configuration+System
I hope to bring it up as a discussion item in todays IRC meeting, and to
start the ball rolling on the evaluation process.-Justin
Hi Rob,
I probably am not getting the point of what you are saying but I will tr y to apply.
Rob Atkinson wrote:
This all makes sense, at a technical level, but I still think we are missing something important, that might buy us a truly easy to use (deploy) system sometime in the future.
Everything is pointing towards major jurisdictions sharing common data models (Feature Types), and the motivation for establishing a server will be to implement these...
and little players will follow suit, delivering a mixture of common types (roads, stuff monitoring, environment indicators)
and if you think about this just a little you will see two patterns that will emerge in config land...
1) deploying a service to meet the technical and metadata standards of the environments the service is deployed into...
eg, State of Maine transport services may need to conform to "service profiles" for State of Maine enterprise architecture, MaineTransport agency enterprise architecture, US transport common standards, but may of course also include a few locally defined traffic analyses, proposals for new roads, etc.
ISO 19106 and the Web Services Interoperability forum (wsi.org) have formally defined the requirements of such "service profiles"
So, conceptually, you should look at importing most of the service metadata from one or more externally defined service profiles. (FYI I have started, with a state agency driving the work, a Sourceforge project for a toolkit to turn multiple inheritance into a single, flat conformance class, to support conformance testing, documentation generation and, of , course configuration. )
I dont expect this to be incorporated overnight, or even in advance of the registries that will publish such service profiles, but I'd like to see the configuration system take into account external sources of configuration, with the UI being used to confirm, and augment configuration where the external config doesnt specify required values
So... are you saying that the catalog / config model in the proposal does not model this requirement appropriately? If so how can you provide feedback on how to acheive this.
As for taking configuration from an external source, I whole heartedly agree. The view of all these things from our services are just interfaces which should be able to be backed onto any source. The actual source is just an implementation detail. Also there should be some sort of rpc api to allow others to play with the catalog / config externally.
2) ease of use - loading instead of creating configs
Config objects should be able to be shared, and loadable from external sources.this could also provide for the ability to import from foreign formats (including incompatible older configurations!)
I'd imaging architecting in some sort of adaptor class for differing config sources, and an import workflow that loaded multiple config objects, then gave the user the oppotunity to load a new object (eventually searching in an external catalog) or create one.
Hmmm..., not sure we need to go that far. I think a simple utility that will take a "legacy geoserver configuration/data directory" and harvest it into the new catalog / configuration. As as it happens there is one already created :). Its part of the prototype created for the proposal.
I know I've said all this before, but its worth saying again. NB TOPP has a grant to make geoserver serve USGS framework data sets - this is a good example of the deployment use case we should analyse.
Definitely.
Rob A
Justin Deoliveira wrote:
Hi all,
The last couple of weeks I have been hammering out a proposal for the
configuration redesign / rearchitecture. I believe it is in a state to
where it is ready for the GSIP process. So... here it is:http://docs.codehaus.org/display/GEOS/GSIP+8+-+New+Configuration+System
I hope to bring it up as a discussion item in todays IRC meeting, and to
start the ball rolling on the evaluation process.-Justin
!DSPAM:4007,464a405f143115219720167!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
> NB TOPP
has a grant to make geoserver serve USGS framework data sets - this is a good example of the deployment use case we should analyse.
Unfortunately that grant has nothing to do with GeoServer - it's all about the uDig client side. We may get a bit of time to try to test with GeoServer, but it's definitely outside the scope of our grant, unfortunately. I wish we had a grant to serve the datasets.
Chris
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
Justin Deoliveira wrote:
Hi Rob,
I probably am not getting the point of what you are saying but I will tr y to apply.
So, conceptually, you should look at importing most of the service metadata from one or more externally defined service profiles. (FYI I have started, with a state agency driving the work, a Sourceforge project for a toolkit to turn multiple inheritance into a single, flat conformance class, to support conformance testing, documentation generation and, of , course configuration. )
I dont expect this to be incorporated overnight, or even in advance of the registries that will publish such service profiles, but I'd like to see the configuration system take into account external sources of configuration, with the UI being used to confirm, and augment configuration where the external config doesnt specify required values
So... are you saying that the catalog / config model in the proposal does not model this requirement appropriately? If so how can you provide feedback on how to acheive this.
Looking (third time now) over the proposal I see the information model,
but not the process model - i.e. where the UI workflow is defined with
respect to resolve elements of the content model. I.e. how flexible the
process is depending on how much of the configuration is loaded from
external sources or existing configuration. Flexibility in the design of
the workflow, depending on how much and what type config is pre-defined
is what I'm looking for, and too stupid to divine 
RA
As for taking configuration from an external source, I whole heartedly agree. The view of all these things from our services are just interfaces which should be able to be backed onto any source. The actual source is just an implementation detail. Also there should be some sort of rpc api to allow others to play with the catalog / config externally.
Nice work Justin; I am going to be going over this with a fine tooth comb tomorrow 
Cheers,
Jody
Hi all,
The last couple of weeks I have been hammering out a proposal for the
configuration redesign / rearchitecture. I believe it is in a state to
where it is ready for the GSIP process. So... here it is:http://docs.codehaus.org/display/GEOS/GSIP+8+-+New+Configuration+System
I hope to bring it up as a discussion item in todays IRC meeting, and to
start the ball rolling on the evaluation process.-Justin
I am going to translate a bit here - seems to be what I do best.
Rob: Justin is interested in getting a handle on all the "info" objects in our design currently, removing the duplication and allowing for the kind of extensions geoserver has already been asked to support. This config proposal could really be called a "config" layer, and represents a clean separation of the WMS, WFS, W*S services from their configuration. The combination of this seperation and the new dispatcher ends up acting similar to the FROGs project - GeoServer brings together just what is needed to answer each request.
WMS
+--------+
| config |
+--------+
There are a couple of consequences to this - the "GetCapabilities" request must be handled just from configuration information (now direct data access).
The other change here is the move to a "live" system where the configuration can be edited as geoserver is running.
+--------+
ui | config +
The config system also acts as the gate keeper by which real data access can occur
+--------+
| config | data
And finally the config system can be backed onto a number of different persistence mechanisms.
+--------+
| config |
+--------+
storage
The trick being that the "storage" is really *live*.
Jody
Translation for Justin this time ....
The answer(s) Rob is looking for is to a slightly different one then what the configuration system is about. In the previous email I showed a user interface / configuration interaction (because that is one of the major constraints). Rob is talking more on the order of an an ingestion engine ... but rather then ingesting lots of "data" - he is interested in ingesting the FeatureTypes, Application Schemas and so on ....
The concept he mentions of a "Service Profile" probably needs a blog article (hey Rob you can write articles for the geoserver blog - or osgeo news letter).
Here is my understanding of it - in brief.
1) The OGC defines what a WFS is - consider that the WFS profile
2) The OGC defines what a WFS-T is - consider that a WFS-T profile
The difference between the two is in what the capabilities document looks like - for WFS-T a couple more operations need to be present. If they are the service is conformant with the WFS-T profile. Conform tends to sound like strong language if you are "forcing" someone to implement it. Rob tends to soften the language by using the word "governance" instead.
The OGC gives out a little flash when an implementation is WFS compliant. You can see the stamps on the web page.
You could also arrange something similar for WMS.
1) OGC defines WMS - but some of the operations are optional - like GetInfo
2) Rob has a tool that will check a WMS and see if GetInfo is supported
The "flash" Rob's tool gives out is a list of "Service Profiles" a service implements.
So geosever can currently collect a bunch of "flash".
But as always there is something more ....
... the capabilities document also specifies what *data* is available.
And as long as your tool is just checking the capabilities document you could define "Service Profiles" based on what data is available as well.
Here is the translation ... given a service profile can we configure GeoServer to "pass" it? For simple things (like turning GetInfo on or off) we probable could. For the interesting things - like making sure the USGS Roads dataset is available - currently not.
Rob the ui / config interface is open to your own community modules - having a module that tries to set up things according to a service profile would be a great sanity check on the api. The specific ray of hope you need is that a FeatureTypeInfo is a first class object; you should be able to define (and their xml schema) even if you cannot hook them up to data right away. I have also been thinking of the KML generation using templates and wondered if GetInfo could be handled in the same way? And possibly the per feature XML snippet ... may be an easier way to conform to an XML schema then your current "mapping"?
Jody
Rob Atkinson wrote:
This all makes sense, at a technical level, but I still think we are missing something important, that might buy us a truly easy to use (deploy) system sometime in the future.
Everything is pointing towards major jurisdictions sharing common data models (Feature Types), and the motivation for establishing a server will be to implement these...
and little players will follow suit, delivering a mixture of common types (roads, stuff monitoring, environment indicators)
and if you think about this just a little you will see two patterns that will emerge in config land...
1) deploying a service to meet the technical and metadata standards of the environments the service is deployed into...
eg, State of Maine transport services may need to conform to "service profiles" for State of Maine enterprise architecture, MaineTransport agency enterprise architecture, US transport common standards, but may of course also include a few locally defined traffic analyses, proposals for new roads, etc.
ISO 19106 and the Web Services Interoperability forum (wsi.org) have formally defined the requirements of such "service profiles"
So, conceptually, you should look at importing most of the service metadata from one or more externally defined service profiles. (FYI I have started, with a state agency driving the work, a Sourceforge project for a toolkit to turn multiple inheritance into a single, flat conformance class, to support conformance testing, documentation generation and, of , course configuration. )
I dont expect this to be incorporated overnight, or even in advance of the registries that will publish such service profiles, but I'd like to see the configuration system take into account external sources of configuration, with the UI being used to confirm, and augment configuration where the external config doesnt specify required values
2) ease of use - loading instead of creating configs
Config objects should be able to be shared, and loadable from external sources.this could also provide for the ability to import from foreign formats (including incompatible older configurations!)
I'd imaging architecting in some sort of adaptor class for differing config sources, and an import workflow that loaded multiple config objects, then gave the user the oppotunity to load a new object (eventually searching in an external catalog) or create one.
I know I've said all this before, but its worth saying again. NB TOPP has a grant to make geoserver serve USGS framework data sets - this is a good example of the deployment use case we should analyse.
Rob A
Justin Deoliveira wrote:
Hi all,
The last couple of weeks I have been hammering out a proposal for the
configuration redesign / rearchitecture. I believe it is in a state to
where it is ready for the GSIP process. So... here it is:http://docs.codehaus.org/display/GEOS/GSIP+8+-+New+Configuration+System
I hope to bring it up as a discussion item in todays IRC meeting, and to
start the ball rolling on the evaluation process.-Justin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
------------------------------------------------------------------------_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Welcome back, Jodymeister!
These emails are enormously helpful. And on the money.
+1 for any progress long these lines.
For an example of a service profile, pre-conformance test (machine readable encodeing of a profile) I recommend you look at the WFS-G gazetteer profile - it binds a service type, set of capabilities and data types together.
I'll post some stuff up as soon as I get over the major hurdles with the community schema build... I have a whitepaper nearly complete.
Rob
Jody Garnett wrote:
Translation for Justin this time ....
The answer(s) Rob is looking for is to a slightly different one then what the configuration system is about. In the previous email I showed a user interface / configuration interaction (because that is one of the major constraints). Rob is talking more on the order of an an ingestion engine ... but rather then ingesting lots of "data" - he is interested in ingesting the FeatureTypes, Application Schemas and so on ....
The concept he mentions of a "Service Profile" probably needs a blog article (hey Rob you can write articles for the geoserver blog - or osgeo news letter).
Here is my understanding of it - in brief.
1) The OGC defines what a WFS is - consider that the WFS profile
2) The OGC defines what a WFS-T is - consider that a WFS-T profileThe difference between the two is in what the capabilities document looks like - for WFS-T a couple more operations need to be present. If they are the service is conformant with the WFS-T profile. Conform tends to sound like strong language if you are "forcing" someone to implement it. Rob tends to soften the language by using the word "governance" instead.
The OGC gives out a little flash when an implementation is WFS compliant. You can see the stamps on the web page.
You could also arrange something similar for WMS.
1) OGC defines WMS - but some of the operations are optional - like GetInfo
2) Rob has a tool that will check a WMS and see if GetInfo is supportedThe "flash" Rob's tool gives out is a list of "Service Profiles" a service implements.
So geosever can currently collect a bunch of "flash".But as always there is something more ....
... the capabilities document also specifies what *data* is available.And as long as your tool is just checking the capabilities document you could define "Service Profiles" based on what data is available as well.
Here is the translation ... given a service profile can we configure GeoServer to "pass" it? For simple things (like turning GetInfo on or off) we probable could. For the interesting things - like making sure the USGS Roads dataset is available - currently not.
Rob the ui / config interface is open to your own community modules - having a module that tries to set up things according to a service profile would be a great sanity check on the api. The specific ray of hope you need is that a FeatureTypeInfo is a first class object; you should be able to define (and their xml schema) even if you cannot hook them up to data right away. I have also been thinking of the KML generation using templates and wondered if GetInfo could be handled in the same way? And possibly the per feature XML snippet ... may be an easier way to conform to an XML schema then your current "mapping"?
Jody
Rob Atkinson wrote:
This all makes sense, at a technical level, but I still think we are missing something important, that might buy us a truly easy to use (deploy) system sometime in the future.
Everything is pointing towards major jurisdictions sharing common data models (Feature Types), and the motivation for establishing a server will be to implement these...
and little players will follow suit, delivering a mixture of common types (roads, stuff monitoring, environment indicators)
and if you think about this just a little you will see two patterns that will emerge in config land...
1) deploying a service to meet the technical and metadata standards of the environments the service is deployed into...
eg, State of Maine transport services may need to conform to "service profiles" for State of Maine enterprise architecture, MaineTransport agency enterprise architecture, US transport common standards, but may of course also include a few locally defined traffic analyses, proposals for new roads, etc.
ISO 19106 and the Web Services Interoperability forum (wsi.org) have formally defined the requirements of such "service profiles"
So, conceptually, you should look at importing most of the service metadata from one or more externally defined service profiles. (FYI I have started, with a state agency driving the work, a Sourceforge project for a toolkit to turn multiple inheritance into a single, flat conformance class, to support conformance testing, documentation generation and, of , course configuration. )
I dont expect this to be incorporated overnight, or even in advance of the registries that will publish such service profiles, but I'd like to see the configuration system take into account external sources of configuration, with the UI being used to confirm, and augment configuration where the external config doesnt specify required values
2) ease of use - loading instead of creating configs
Config objects should be able to be shared, and loadable from external sources.this could also provide for the ability to import from foreign formats (including incompatible older configurations!)
I'd imaging architecting in some sort of adaptor class for differing config sources, and an import workflow that loaded multiple config objects, then gave the user the oppotunity to load a new object (eventually searching in an external catalog) or create one.
I know I've said all this before, but its worth saying again. NB TOPP has a grant to make geoserver serve USGS framework data sets - this is a good example of the deployment use case we should analyse.
Rob A
Justin Deoliveira wrote:
Hi all,
The last couple of weeks I have been hammering out a proposal for the
configuration redesign / rearchitecture. I believe it is in a state to
where it is ready for the GSIP process. So... here it is:http://docs.codehaus.org/display/GEOS/GSIP+8+-+New+Configuration+System
I hope to bring it up as a discussion item in todays IRC meeting, and to
start the ball rolling on the evaluation process.-Justin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
------------------------------------------------------------------------_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel