400 likes | 416 Views
Explore the goals, technical framework, and pilot solution evaluation of the WISE Distributed System. Discover the logical architecture, components, and business processes. Follow the flow of BizTalk and web services interaction. Dive into use cases and demo for a comprehensive understanding.
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