400 likes | 405 Views
WISE Distributed System. SADL K.U. Leuven Geo Solutions NV. Koen Mertens Jan De Belder Rombout Verwimp. Overall agenda. Part 1: WISE ds theory Part 2: Get it real! + demo Part 3: Results + discussion Part 4: Potential use WISE-ESTAT case + demo. Agenda Part 2.
E N D
WISEDistributedSystem SADL K.U. Leuven Geo Solutions NV Koen Mertens Jan De Belder Rombout Verwimp
Overall agenda • Part 1: WISE ds theory • Part 2: Get it real! + demo • Part 3: Results + discussion • Part 4: Potential use WISE-ESTAT case + demo
Agenda Part 2 • WISE ds goals & architecture • WISE ds technical framework
Wise ds pilot goals 1 • Evaluate the overall data flow • Evaluate performance issues/requirement • Evaluate INSPIRE specifications for WISE • Evaluate the use of mixed WISE QA/QC engine for object and file based reporting
WISE ds pilot goals 2 • Evaluate metadata elements required on the data but more specific to follow up the data streams • Evaluate service communication with member states • To give advice on the management/coordination required by this sort of systems.
Out of scope Out of scope • All data except WFD Art 8 data • WISE data flow manager • Links with REPORTNET • No dissemination towards applications • (except 1H02 link to Eurostat pilot) • Operational production ready systems • Performance benchmarking at EEA site • Multilingual applications (only English will be used) • Full configurable applications -> goal is to illustrate the flow!
WISE DS pilot solution • Based on : • Microsoft BizTalk (business processing management software – XML messaging) • Microsoft SQL server technology • C#.NET (web services) technology • ARCGIS server + desktop technology (9.3) • Postgresql/postgis • Apache Tomcat + deegree WFS • FTP
Metadata management DB • SQL Server 2005 • LUT tables: lookup values from xsd • Other tables: metadata information about contacts, reported files, file status, errors,… • Link to object geodatabase: lnkFileObject: links objectids from geodatabase to fileIDs in management database
Feature database • ESRI ArcGIS ArcSDE geodatabase • Complex relationships due to xml structure • Links: ParentTableName_Id is foreign key in childTables • Physical primary keys = oid or objectid while the logical primary key = ParentTableName_Id • No physical relationships using relationship classes at ArcSDE level • Only 2 feature classes: Ground- and surfacewatermonitoringStation, the rest are tables
only 3 types of objects/xml Reportedobjects in geodatabase only 2 feature classes complex relationships: different ways of being child
Logical flow • Incoming reported file passes following stages: • File Harvesting: get & archive the file • Metadata writing • File validation • Schema validation (xml schema test) • Spatial validation (spatial coordinates test) • Content validation (xml content test) • File approval or rejection • Storage of spatial & attribute information in spatial relational DB • Dashboard consultation
Use cases • UC 1: File posting: Member states report the WISE information through an FTP server or through the setup of a WFS service • UC 2: File harvesting: BizTalk picks up the information from the FTP or WFS. • UC 3: Controller action: The information is processed by the .NET controller web service • UC 4: QA/QC: Quality control of the content of the reported data
Use cases • UC 5: GIS data handling: All GIS related operations are performed by the GIS web service, e.g. object storage in the wise object geodatabase • UC 6: Metadata handling: Metadata about the reported data is maintained in the management database • UC 7: Dashboard usage: The dashboard facilitates information exchange from the management database
Demo • FTP • WFS • Dashboard
Decision steps in development • Generic & Extensible Framework of services • Data flow governed by BizTalk (XML intermediate files) • Custom code available as web methods • Instead of “black box” of code • Priorities in development • Technical issues over organisational issues • Time frame too limited for extensive user testing • Primary goal was to demonstrate the feasibility of the automated dataflow • Technological choices • FTP: easily implementable at MS side • WFS: advanced implementations required • WFS – complex features: currently only 1 solution • DEEGREE-WFS
Findings • FTP • No complex IT requirements on the MS side • Limited reuse of ART 8 data for dissemination • WFS • For serving complex features: only 1 solution: DEEGREE WFS • More complex IT architecture required at MS side • Tomcat + Postgres/postgis + Deegree • Datamodel according to ART 8 schema • WFS = service : reuse of ART 8 data for dissemination