Matthew Laurenson (HortResearch) and Seishi Ninomiya (NARC)

1. The agmodel project:Live linking between natural resource modelsand weather databases, online map services,and digital elevation models. Matthew Laurenson (HortResearch) and Seishi Ninomiya (NARC)

2. Background • Project began in 1999 in Dept of Information Science and Technology at National Agricultural Research Centre in Tsukuba, Japan • Supported by Japan Science and Technology Agency, initially through a two year STA Fellowship • In 2000 recognized as one of the “Top 10” research projects for the year with the Japanese Ministry of Agriculture and Forestry • Work on framework continues under the JST project…

3. Project Goal • Promote model “portability” e.g. • Develop a natural resource model in Thailand with Thai data, then run the model in New Zealand with New Zealand data • Challenges • Database heterogeneity (same kind of data, different logical structure and format) • User interface localization • Initial focus on weather data (because used in many agricultural decisions.

4. Outputs • MetBroker – weather data from 18 databases • ChizuBroker – maps from multiple online sources • DEMBroker – digital elevation models for the World and Japan • ResourceServer – multilingual labels in many languages • CountryServer – country and administrative region boundaries • Suite of client applications

5. MetBroker and ResourceServer Retrieves data from any of 12,000 MetBroker-linked stations Station’s period of operation Weather elements and resolutions available from station

6. Coverage from NOAA WMO weather database

7. ResourceServer

8. CountryServer (and MetBroker)

9. ChizuBroker, DEMBroker and CountryServer

10. Using Multiple Brokers DEMBroker Elevation data MetBroker ChizuBroker Meteorological data Background maps Spatial Risk Applet Country Server Nationalboundaries Resource Server Application text

11. Frost probability based on interpolated temperature

12. Possible measures of success • Continued existence • Awards • References • Improved weather data availability (measured by usage) • Model for development of other systems (eg SoilBroker) • Uptake by developers outside of NARC/HortResearch

13. Important Accessibility Milestones for MetBroker 1 • Version 1.0 available (two databases, RMI access only) potential adopters can test, see real performance, and use MetBroker • MetBroker documented and open-sourced developers can rely on future access to MetBroker • Tanaka links his models to MetBroker other Java developers can create broker-linked applications • Otuka develops servlet access users can test without installing Java Plug-in • HTTP wrappers developed users behind firewalls can access

14. Important Accessibility Milestones for MetBroker 2 • SOAP access developed non-Java developers can create broker applications • Apirak replaces PSEPro with free OODB, retaining applications, database drivers, and configuration files. anyone can run their own copy of MetBroker other implementations of MetBroker core are possible • Meng links NOAA World data set relevant data for many more users • Yamakawa makes MetBrokerEJB – simplifying deployment of MetBroker and related Web services and allowing use of any underlying relational database for metadata

15. Ideas • Make something useful and encourage use and casual experimentation • Publish early and often • Don't exclude developers through choice of technology • Design of system interfaces is critical – Interfaces (between client application and broker, and between broker and databases) are perhaps most valuable part of MetBroker

16. Things we should have done • Installation of Java Plug-in was barrier to casual experimentation Should have made better Web application (HTML) instead of applets • Need to license commercial OODB was barrier to experimentation Should have used free relational database for metadata instead of commercial OODB

17. Positive Points of MetBroker • Pragmatic approach – doesn’t require much effort of database owners • Careful separation between: • Client application API • Internal Implementation • Database driver API Client applications don’t need to know about/download most server classes Database drivers are easy to write (1 week) and are dynamically linked at runtime • Multilingual labels and metadata

18. Future for MetBroker – technical side • Use emerging Grid computing standards • Revise architecture

19. MetadataRequest MetadataRequest MetadataResponse MetadataResponse Existing structure for MetBroker - Metadata MetBroker Internal Implementation ClientApplication Database Driver Interface for Client Applications Interface forDatabase Drivers

20. DataRequest DataRequest DataResponse DataResponse Existing structure for MetBroker – weather data MetBroker Internal Implementation Database Driver ClientApplication Interface for Client Applications Interface forDatabase Drivers

21. MetaDataRequest MetaDataRequest MetaDataResponse Register MetaDataResponse Data Request Data Response New structure for MetBroker based on Web services Metadata Registry DatabaseWrapper ClientApplication Database . Broker (not shown) acts as wrapper for smaller databases without their own wrappers

22. Agmodel Project – administrative side • Ensure a well-supported standard version is available(with up-to-date source code) • Establish governance structure • Establish maintenance/support structure