Difference between revisions of "FOSS4G 2009 Integration Showcase"
(16 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
− | = | + | '''<font color="red">The Integration Showcase is now managed by the OGC as the [http://external.opengis.org/twiki_public/bin/view/ClimateChallenge2009/WebHome Climate Challange Integration Plugfest 2009].</font>''' |
− | The | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | The rest of this page is kept for historical archiving. It will likely be removed soon. | |
− | + | = Goals = | |
− | + | The primary goals of the showcase are: | |
− | + | * Provide a working and complete (likely overly complete) spatial data infrastructure to conference participants. | |
− | * | + | * Demonstrate the reliability and stability of FOSS4G projects by providing a working case-study. |
− | |||
− | |||
− | * | ||
− | |||
− | |||
− | = | + | == Provide SDI == |
− | |||
− | |||
− | |||
− | + | The hope in providing a working spatial data infrastructure, complete with data, is that presenters, workshop and lab coordinators and exhibitors can all connect to various components of the SDI. This will help them, exhibitors in particular, by demonstrating their products capability to interact with FOSS4G infrastructure. Presenters, workshop coordinator and lab coordinators will have a greater range of data and services to leverage. | |
− | |||
− | ==== | + | == Demonstration of FOSS4G == |
− | |||
− | + | This is more of a touchy-feely goal, but also more important. By showing a complete SDI functioning in a demanding environment, we will gain credibility amongst the nay-sayers that continue to view open source as a bunch of kids sitting in their parents basements coding up crap. This is less and less the case, and at a FOSS4G conference we'll be preaching to the choir to a large extent, but if they can go back to work and point their own GIS systems at the services to show their collegues and managers. Here is where the real value of an integration showcase comes from. | |
− | + | = Requirements = | |
− | |||
− | * | + | This is a tricky point. We have several considerations: |
− | ** | + | * Stability |
− | ** | + | * Accessibility |
+ | * Predictability | ||
+ | * Performance | ||
+ | * Ubiquity | ||
− | == | + | == Stability == |
− | + | We're asking participants in the conference to use our infrastructure. We need to make sure it's available for them when they try to present. | |
− | '' | + | == Accessibility == |
+ | All participants, whether delegates, exhibitors or attendees, must be able to connect to the infrastructure. Additionally, various components of the infrastructure must be able to connect to each other. More than anything else, this means we need some solid documentation on what is available and how to use it. There is also a security issue here. Some workshops and demos will undoubtably want write access to something, but the data we're serving is intended to be authoritative, real data, and as such it's completely inappropriate to allow edits. This particular issue can be dealt with as needed, but will likely involve creating some sandbox datasets. | ||
− | + | == Predictability == | |
− | + | People will need to know what is going to be served by the infrastructure and how. In order to have enough confidence in the infrastructure to build a workshop around it, the infrastructure needs to be established and documented ages before the conference. Ideally services will be setup and data loaded several months before hand, even if it's only a sample of expected data, on a low-performance demonstrator system. | |
− | + | == Performance == | |
− | + | During the conference, the infrastructure must be able to provide the performance required by those that are dependent on it. Having half a dozen workshops hitting services can be expected, as well as multiple vendors, labs and presentations doing the same. If the infrastructure is to be opened as I hope it will be, there is the need for a parallel, invitation only infrastructure to guarantee performance for those most dependent on it, the workshops, labs and presentations. | |
− | |||
+ | == Ubiquity == | ||
+ | The integration showcase must be prepared to accept EVERY FOSS4G project that is interested in getting involved. The project itself will need to provide the expertise to integrate the product, configuring, styling and securing as needed, but we need to be able to make room for it. While the integration showcase must also accept any and all proprietary products into the fold, the SDI itself should remain FOSS only. This is, after all, intended to show the strength, stability and interoperability of FOSS4G. | ||
− | + | = Steps Forward = | |
− | |||
− | == | + | == Develop Scenarios == |
− | + | One noted shortcoming of the 2007 integration showcase was a couple scenarios that would exercise the infrastructure. Possibly we could pull together a couple of case studies and build them on top of the or embed them in the showcase. Alternately, or additionally, if we put together a script that would take people through a workflow that accomplishes something real. Thoughts? | |
− | + | * Data Replication<br />There are a number of mechanisms to replicate or aggregate data, and it's a topic in growing demand. | |
− | + | * Emergency Services<br />Everybody loves a good ES scenario. Makes us feel like we're saving the world. Does anyone have a toxic plume handy? | |
− | * | + | * ... |
− | |||
− | * | ||
+ | == Data == | ||
+ | The showcase will be considerably less interesting with no data. We need people to commit to providing the data, as well as appropriate metadata, under an open license to be loaded and distributed in the showcase. | ||
− | == | + | == Services == |
− | + | We need people, preferably the project communities themselves, to stand up services. By providing multiple data stores (RDBMS, file system, ...) and multiple services (WMS, WFS, CSW, ...) we will hopefully provide enough mechanisms to connect into the showcase to handle everyone. | |
− | + | == Applications == | |
+ | While the server side of the showcase is critical, it doesn't look as pretty as the client side. We need to get some pre-configured applications, some web applications, scripting examples and data processing tools available to show what can be done with this stuff. This may not be hosted on the SDI itself, but run on delegates machines and handed out as install kits or live cds as appropriate. | ||
− | + | [[Category:FOSS4G2009]] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 19:21, 27 November 2008
The Integration Showcase is now managed by the OGC as the Climate Challange Integration Plugfest 2009.
The rest of this page is kept for historical archiving. It will likely be removed soon.
Goals
The primary goals of the showcase are:
- Provide a working and complete (likely overly complete) spatial data infrastructure to conference participants.
- Demonstrate the reliability and stability of FOSS4G projects by providing a working case-study.
Provide SDI
The hope in providing a working spatial data infrastructure, complete with data, is that presenters, workshop and lab coordinators and exhibitors can all connect to various components of the SDI. This will help them, exhibitors in particular, by demonstrating their products capability to interact with FOSS4G infrastructure. Presenters, workshop coordinator and lab coordinators will have a greater range of data and services to leverage.
Demonstration of FOSS4G
This is more of a touchy-feely goal, but also more important. By showing a complete SDI functioning in a demanding environment, we will gain credibility amongst the nay-sayers that continue to view open source as a bunch of kids sitting in their parents basements coding up crap. This is less and less the case, and at a FOSS4G conference we'll be preaching to the choir to a large extent, but if they can go back to work and point their own GIS systems at the services to show their collegues and managers. Here is where the real value of an integration showcase comes from.
Requirements
This is a tricky point. We have several considerations:
- Stability
- Accessibility
- Predictability
- Performance
- Ubiquity
Stability
We're asking participants in the conference to use our infrastructure. We need to make sure it's available for them when they try to present.
Accessibility
All participants, whether delegates, exhibitors or attendees, must be able to connect to the infrastructure. Additionally, various components of the infrastructure must be able to connect to each other. More than anything else, this means we need some solid documentation on what is available and how to use it. There is also a security issue here. Some workshops and demos will undoubtably want write access to something, but the data we're serving is intended to be authoritative, real data, and as such it's completely inappropriate to allow edits. This particular issue can be dealt with as needed, but will likely involve creating some sandbox datasets.
Predictability
People will need to know what is going to be served by the infrastructure and how. In order to have enough confidence in the infrastructure to build a workshop around it, the infrastructure needs to be established and documented ages before the conference. Ideally services will be setup and data loaded several months before hand, even if it's only a sample of expected data, on a low-performance demonstrator system.
Performance
During the conference, the infrastructure must be able to provide the performance required by those that are dependent on it. Having half a dozen workshops hitting services can be expected, as well as multiple vendors, labs and presentations doing the same. If the infrastructure is to be opened as I hope it will be, there is the need for a parallel, invitation only infrastructure to guarantee performance for those most dependent on it, the workshops, labs and presentations.
Ubiquity
The integration showcase must be prepared to accept EVERY FOSS4G project that is interested in getting involved. The project itself will need to provide the expertise to integrate the product, configuring, styling and securing as needed, but we need to be able to make room for it. While the integration showcase must also accept any and all proprietary products into the fold, the SDI itself should remain FOSS only. This is, after all, intended to show the strength, stability and interoperability of FOSS4G.
Steps Forward
Develop Scenarios
One noted shortcoming of the 2007 integration showcase was a couple scenarios that would exercise the infrastructure. Possibly we could pull together a couple of case studies and build them on top of the or embed them in the showcase. Alternately, or additionally, if we put together a script that would take people through a workflow that accomplishes something real. Thoughts?
- Data Replication
There are a number of mechanisms to replicate or aggregate data, and it's a topic in growing demand. - Emergency Services
Everybody loves a good ES scenario. Makes us feel like we're saving the world. Does anyone have a toxic plume handy? - ...
Data
The showcase will be considerably less interesting with no data. We need people to commit to providing the data, as well as appropriate metadata, under an open license to be loaded and distributed in the showcase.
Services
We need people, preferably the project communities themselves, to stand up services. By providing multiple data stores (RDBMS, file system, ...) and multiple services (WMS, WFS, CSW, ...) we will hopefully provide enough mechanisms to connect into the showcase to handle everyone.
Applications
While the server side of the showcase is critical, it doesn't look as pretty as the client side. We need to get some pre-configured applications, some web applications, scripting examples and data processing tools available to show what can be done with this stuff. This may not be hosted on the SDI itself, but run on delegates machines and handed out as install kits or live cds as appropriate.