Mit Condat-Effekt. Mobile Business we make IT berlinbrandenburg Umweltdatenbanken 2006 Software zur Verwaltung der Abwasseranlagen-Eigenkontrolle zum Gewässerschutz.

Präsentation zum Thema: "Mit Condat-Effekt. Mobile Business we make IT berlinbrandenburg Umweltdatenbanken 2006 Software zur Verwaltung der Abwasseranlagen-Eigenkontrolle zum Gewässerschutz."—  Präsentation transkript:

1 mit Condat-Effekt. Mobile Business we make IT berlinbrandenburg Umweltdatenbanken 2006 Software zur Verwaltung der Abwasseranlagen-Eigenkontrolle zum Gewässerschutz 16. Mai 2006 in Höxter Tilman Fischer, Condat AG tf@condat.de

2 Condat AG, Berlin 20062 Inhalt  Überblick HAA-Software  Gesetzliche Regelungen / Anforderungen an EKVO  EKVO-Standard-Workflow  Auswahl Anwendungsarchitektur  Technologievorschlag Eclipse Rich Client Plattform (RCP)  Einordnung EclipseRCP / Integrationsfähigkeit  Hardware- und Software-Anforderungen  Zukunftstauglichkeit EclipseRCP  Alternativen

3 Condat AG, Berlin 20063 Kläranlagen in Hessen Betreiber  700 Kläranlagen  2000 Kanalnetze  5000 Kleinkläranlagen

4 Condat AG, Berlin 20064 HAA-Software Oberfläche

5 Condat AG, Berlin 20065 Historie - DV-Konzept 9 DBs

6 Condat AG, Berlin 20066 HAA-Software heute  Erstellt mit  4GL-Sprache/Entwicklungsumgebung Centura (V.3.0)  Visual Basic VB V.6  VBA in Word  auf Oracle-DB  früher: 9 verteilte Oracle 8i, jetzt eine zentrale Oracle 9i-DB  80 Tabellen (eine gemeinsame Tabelle für alle Listen)  ca. 200 Masken  37 Reports/Anschreiben/Bescheide/… Dokument-Schnittstellen  Word Serienbrief und Autotext-Dokumentvorlagen, u.a. für Tabellen

7 Condat AG, Berlin 20067 HAA-Software Funktionsgruppen

8 Condat AG, Berlin 20068 HAA-Software Funktionsgruppen  Unterstützung aller Verwaltungsabläufe für den Bereich kommunales Abwasser, u.a.  Genehmigungs- und Erlaubniserstellung  Schematisierter Aufbau der Kläranlagen  Staatliche Überwachung, Messwertverwaltung  Gebühren- und Kennziffernberechnung  Umsetzung der Eigenkontrollverordnung  Wiedervorlage, Anbindung von MS-Word  Zentrale Auswertungen, usw…  http://www.hlug.de/medien/wasser/abwasser/haa.htm http://www.hlug.de/medien/wasser/abwasser/haa.htm

9 Condat AG, Berlin 20069 HAA-Fließbild

10 Condat AG, Berlin 200610 EKVO - gesetzliche Regelungen  Richtlinie des Rates vom 21. Mai 1991 über die Behandlung von kommunalem Abwasser (91/271/EWG)  Regelungen des Bundes, insbesondere im Wasserhaushaltsgesetz (WHG, u.a. § 18b Bau und Betrieb von Abwasseranlagen)  Hessischen Wassergesetz (HWG, u.a. § 46 Betrieb, Eigenkontrolle und Überwachung von Abwasseranlagen)  Verordnung über die Eigenkontrolle von Abwasseranlagen (EKVO) vom 21. Januar 2000 (GVBl. I S. 59) zuletzt geändert durch Verordnung vom 11. November 2003 (GVBl. I S. 301)  Anforderungen an Kleinkläranlagen durch Aufnahme in Anhang 1 der AbwVO und neuer Regelungen. (Neufassung der DIN 4261 Teil1 und EN 12566)

11 Condat AG, Berlin 200611 Zielsetzungen  EKVO 2006 unterstützen - neue Daten, mehr Berichtspflichtige  Anteil der elektronische Datenübermittlung maximieren - Kosten- und Aufwandsreduktion  Datenqualität maximieren - Aufwand für Qualitätsprüfung und Rückfragen/Mahnungen minimieren  E-Government Masterplan berücksichtigen - Lösung muss passfähig sein  Startpunkt für HAA auf neuer technologischer Basis - Zukunftsfähigkeit sichern

12 Condat AG, Berlin 200612 Standard-Workflow

13 Condat AG, Berlin 200613 EKVO-Anforderungen - Betreiber EKVO bei den Anlagenbetreibern:  Geringer Installationsaufwand für ca. 7000 Betreiber  Hohe Plattformunabhängigkeit (unbekannte Betreiber-HW/SW)  Komfortable Datenerfassung und Kontext-Hilfe  Import-Schnittstelle, z.B. für Daten aus Betriebstagebüchern  Berichts-Übersicht und lokale Auswertung  Offline nutzbar (Datentransfer per Datenträger)  Online nutzbar (Datentransfer per Email)  Druckfunktion  Übernahme neuer Versionen und Stammdaten vom HLUG

14 Condat AG, Berlin 200614 Intranet-Nutzer / Dienststellen

15 Condat AG, Berlin 200615 EKVO-Anforderungen - Dienststellen EKVO in den Behörden:  Ansicht lokal vorliegender Datensatzdateien  Adressänderung / Ersterfassung von gemeldeten Kläranlagen  Stammdaten-Verteilung zu den Betreibern  Import von Datensätzen nach Prüfung / Freigabeprozess  Anschreiben und Mahnungen (Bericht fehlt / unvollständig)  Wiedervorlage  Online-Hilfe / Prozessbeschreibung  Ansicht und Auswertung freigegebener Datensätze

16 Condat AG, Berlin 200616 Fragestellungen/Datenauswertung  Auswertungen für Kommunen, hessischen Landtag, statistisches Landesamt, UBA, Bund und EU  Lageberichte und spezielle Anfragen  Zustand der Kanäle (Länge / untersucht / Sanierungsbedarf)  Einhaltung von Grenzwerten (z.B. N, Pges)  Verwendung / Beseitigung von Reststoffen  Belastung von Flüssen / Reinigungsgrad / 2. oder auch 3.- Behandlung  Struktur der Entsorgung / Anschlussgrad  Anlagentypen / Reinigungsstufen (Art und Anzahl)  Wasserrahmenrichtlinie (Untersuchungen von Mischwasserentlastungen, Abwasser/Flusswasser-Verhältnis)

17 Condat AG, Berlin 200617 Erfahrungen HAA & EKVO  Datenmanagements bei der kommunalen Abwasserbehandlung  Scheller Zugriff auf alle Daten, z.B. Fristen bei der Wiedervorlagen  Information Außenstehender, z.B. nach dem Umweltinformationsgesetz  Verfahrenstechniken leicht erkennbar und zu bewerten  Existierende Erfahrungen mit EKVO  Steigert das Umweltbewusstsein der Betreiber  Einspareffekte beim Betreiber durch schnellere Reaktionsmöglichkeit  Katastererfassung wird aktualisiert, Betreiber bekommt eine bessere Zustandsübersicht seiner Anlagen (Kanäle und Kläranlagen)  Absicherung des Betreibers gegen Grenzwertüberschreitungen mit der Folge strafrechtlicher Konsequenzen (Nachweis der ordentlichen Arbeit)

18 Condat AG, Berlin 200618 Anwendungsarchitekturen im Überblick  Terminal-Server-Architektur  gesamte Rechenleistung Server-seitig  Client-seitig nur einfache Daten-Ein/Ausgabe  Client/Server-Architekturen („Fat Clients“)  Transfer der Rechenleistung auf den Client  Komplexe Benutzerschnittstelle, Server-seitig nur Datenhaltung  Web-basierte Architekturen („Thin“ oder „Web Clients“)  Transfer der Rechenleistung zurück auf den Server  Client-seitig eingeschränkte Benutzerschnittstelle  Rich-Client-Architekturen  Transfer eines Großteils der Rechenleistung auf den Client  Komplexe Benutzerschnittstelle  Nutzung von Vorteilen der Web-Client-Architekturen, an denen es den Fat Clients mangelte

19 Condat AG, Berlin 200619 Anwendungslogik GUI Datenhaltung Fat Client Aufgabenverteilung Anwendungslogik GUI Datenhaltung Rich Client Anwendungslogik GUI Datenhaltung Web Client Anwendungslogik

20 Condat AG, Berlin 200620 Fat Client Bewertung der Kerneigenschaften Rich ClientWeb Client +Umfangreiche Funktionalität +Hoher GUI-Komfort -Initialinstallation -Schlechtes Update- Verhalten +Offline u. online lauffähig -Performance stark vom Client abhängig +Umfangreiche Funktionalität +Hoher GUI-Komfort -Initialinstallation +Gutes Update- Verhalten +Offline u. online lauffähig ±Performance teils vom Client abhängig -Eingeschränkte Funktionalität -Geringer GUI-Komfort +Keine Initialinstallation +Gutes Update- Verhalten -Nicht offline nutzbar +Performance stark vom Server abhängig

21 Condat AG, Berlin 200621 Was wofür?  Spezialisierte Anwendungen für Experten (z.B. Fachverfahren oder Workflow-Systeme)  Eher für eine überschaubare Anzahl von Nutzern (bis zu wenige Hundert)  Anwendungen mit hoher Verfügbarkeit und solche, die auch offline bedienbar sein müssen  Anwendungen mit hohem Anteil von Dokumentengenerierung und ggf. Office Integration  Anwendungen in Umgebungen mit geringer Netzbandbreite  Einfache Anwendungen (z.B. Informationsrecherche oder einfache Formularlösungen)  Eher für große Nutzermengen (auch mehrere Tausend)  Anwendungen, „die auch mal ein paar Stunden ausfallen können“ (Ausnahme: Geschäftsmodelle wie ebay oder Amazon)  Anwendungen, die weniger produzierenden Charakter haben  Anwendungen, bei denen das Antwortzeitverhalten nachrangig ist Rich ClientWeb Client

22 Condat AG, Berlin 200622 Strategische Entscheidung  Rich Client auf Java-Basis  keine Browser-basierte Anwendung  Integration / Nutzung von Web-Lösungen möglich - wenn sinnvoll, wie z.B. bei Integration mit existierenden / fremden Verfahren

23 Condat AG, Berlin 200623 Basis-Architekturen Oracle- DB Repository Remote-DB Business Logic GUI Rich Client DB-Server Offline Client Sync-issues Thin Client Application-Server

24 Condat AG, Berlin 200624 EKVO Architektur & Technologie Anforderungen  Offen für alle Prozesse  Integrationsfähigkeit  E-Government-konforme Kommunikation, Standards  Flüssiges Arbeiten mit Bedienkomfort  Eingabeunterstützung  Plattformunabhängigkeit  Minimale Administration Lösungen mit dem Rich Client  Komplexeste Vorgänge sind abbildbar, auch Offline  Geschaffen für Plugins, auch mit Integration lokaler Anwendungen  Als Java-Bibliotheken verfügbar, meist Open Source  Reaktionsfähigkeit und Masken- komfort auf dem Client  Jede Hilfe programmierbar  Java und Eclipse  Installation durch Kopie, Online- und Offline-Updates

25 Condat AG, Berlin 2006 Referenz Architektur RichClient+EKVO-Instanz Client Schicht Java Web Start EclipseRCP Web Server Application Server Präsentationsschicht Geschäftsfunktionalitätsschicht Java Connector Architecture Java Native Interface JDBC / ODBC RMI / Corba SOAP Integrations- schicht Datenhaltungs- schicht HLUG-Dienste Oracle Import- Dateien... Fließbilder Crystal Reports Star Office API HAA-Admin Workflow Geschäftslogik Datenobjekte HTML (z.B. Dokumentation) Web Services ReportsHAAMonitoring & Notification Online Hilfe Java Web Start

26 Condat AG, Berlin 200626 Technologische Basis  Eclipse Rich Client Plattform (RCP)  EclipseRCP ist ein minimaler Anwendungsrahmen  sozusagen ein leeres Fenster, leeres Menü, eine leere Schnellstartleiste, leere Hilfe und diverse weitere Mechanismen  universelle Komponenten-Plattform für Rich Clients  plattformunabhängig durch Java  seit 2001 Open Source, verwaltet von der Eclipse Foundation  Nachfolger von IBM Visual Age (40 Mio US$ Entwicklungskosten) Vergleich: Browser mit Plug-ins Eclipse RCP: alles ist ein Plug-In

27 Condat AG, Berlin 200627 Einordnung EclipseRCP IT- Komponentensysteme („IT-Ökosysteme“)  Java ist ein Komponentensystem aus Bibliotheken  EclipseRCP ist ein Werkzeug-basiertes Komponentensystem  Selbst Java-basiert; kann damit alle Java-Bibliotheken nutzen, z.B. - JAAS (Java Authentication and Authorization Service) - XML, XML Schema und XSLT  Fertige Werkzeuge werden durch Konfiguration eingeklinkt, u.a. - Werkzeuge zur Administration und Verwaltung (z.B. für Outlook) - Editoren (HTML, XML, …), nützliche Helfer (z.B. Telefonbuch)  Mit WTS und unabhängig vom WTS verwendbar

28 Condat AG, Berlin 200628 Eclipse Ecosystem http://wiki.eclipse.org/index.php/Image:FAQ_PartI.jpg

29 Condat AG, Berlin 200629 Technologie-Prototyp  EclipseRCP (Platform, GUI)  Eclipse Forms  Eclipse Help  JFace DataBinding  Eclipse BIRT (Reporting)  EMF  Ecore  UML  XML-Persistenz durch EMF  Service Data Objects SDO für die Offline-Synchronisation  Elver (Mapping-Konfiguration)  Hibernate (O/R-Mapping)  Oracle 9i-Datenbank  Eclipse Visual Editor  DITA modulare Dokumente  ArgoUML/argo2ecore  Eclipse TPTP Test and Performance Tools Platform  Eclipse Update Manager Java Web Start

30 Condat AG, Berlin 200630 Software-Anforderungen EKVO-Runtime und HAA-EKVO-Komponente  Download-Volumen  Java Runtime Environment 1.5 (JRE): 16 MB (offline Installation)  Eclipse Rich Client Plattform: 6 MB  Zusätzliche Komponenten und Implementierung: 20-30 MB  Installationsaufwand  Mit JRE: „ein“ Mausklick  Ohne JRE: JRE Installation + „ein“ Mausklick

31 Condat AG, Berlin 200631 Hardware-Anforderungen EKVO-Runtime und HAA-EKVO-Komponente  Hardware  entsprechend Betriebssystemanforderungen / aktuelles Officepaket  z.B. für Windows 128 MB Arbeitsspeicher, 300 MHz Prozessor  EKVO-Anwendung 40 MB Festplatte + JRE 100 MB Festplatte  Ressourcenbedarf zur Laufzeit  EKVO-Demonstrator mit Java-VM: 38 MB  Mit allen Komponenten: 60-100 MB (*)  Nur die neue EKVO-Runtime 40-80 MB

32 Condat AG, Berlin 200632 Integrationsfähigkeit EclipseRCP EclipseRCP  Plugin-Konzept nach OSGi-Standard  Open Services Gateway Initiative, gegründet 1999, 44 Firmen  Alle von Java unterstützten Standards einsetzbar  Plug-ins für  Business Process Management (BPM, BPEL)  Enterprise Application Integration (EAI)  Workflow-Management (WFMS)

33 Condat AG, Berlin 200633 Zukunftstauglichkeit EclipseRCP Liste aller prominenten J2EE-Applikations-Server  BEA WebLogic  kauft Eclipse-Firma M7, tritt 2/2005 der Eclipse Foundation bei, portiert WebLogic Workshop 8.1 nach Eclipse  Apache Geronimo  JBoss  IBM WebSphere  SAP NetWeaver  SAP NetWeaver Developer Studio basiert auf Eclipse  Sun Java System Application Server  basiert auf Suns NetBeans Plattform Alle Werkzeuge als Eclipse Plug-ins

34 Condat AG, Berlin 200634 Alternativen Alternativen zur EclipseRCP  Microsoft.NET  Sun NetBeans Plattform (Swing/AWT)  IBM WebSphere  Web Client

35 Condat AG, Berlin 200635 Eclipse SWT Standard

36 Condat AG, Berlin 200636 Eclipse Forms Standard

37 Condat AG, Berlin 200637 Vielen Dank für Ihre Aufmerksamkeit. Condat-Effekt. Mobile Business mit