1 / 26

Plattformunabhängige Serverdienste am Beispiel von webCOB

Plattformunabhängige Serverdienste am Beispiel von webCOB. 6. Tagung der DFN-Nutzergruppe Hochschulverwaltung Verwaltung@eUniversity Thomas Walter 15.5.2003. Verwaltung in der eUniversity. Zentrale Verwaltung Professionelle Mitarbeiter hoher Grad an Spezialisierung

cisco
Télécharger la présentation

Plattformunabhängige Serverdienste am Beispiel von webCOB

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Plattformunabhängige Serverdienste am Beispiel von webCOB 6. Tagung der DFN-Nutzergruppe Hochschulverwaltung Verwaltung@eUniversity Thomas Walter 15.5.2003

  2. Verwaltung in der eUniversity • Zentrale Verwaltung • Professionelle Mitarbeiter • hoher Grad an Spezialisierung • homogene Ausstattung & guter Support • typische DV-Verfahren: • HIS GX-Systeme • Zentrales DBMS (typischerweise Informix) • Dezentrale Verwaltung • sehr heterogene Struktur sowohl an technischer Ausstattung als auch an Fachwissen • häufig andere Ansprüche an DV-Verfahren

  3. Dezentrales Web-Verfahren „light“ heterogene Clients (Windows, Unix, Mac) keine Installationen auf Clients Verschlüsselung notwendig Serverbasiertes Verfahren: nur Server greift auf DBMS zu meist lesende Zugriffe Vergleich Technik • Professionelles zentrales System (GX-Verfahren) • nur Windows-OS mit installierter Client-SW • läuft im Intrantet der ZV:keine Verschlüsselung • Datenbankanbindung Connect oder ODBC • ein zentrales DBMS für alle Zugriffe, lesend und schreibend • typisches Client-Server

  4. Dezentrales Web-Verfahren „light“ nur wenige Funktionalitäten werden häufig benötigt keine Schulungen SW muss intuitiv bedienbar sein Support nur schwer erreichbar: Dezentrales Management Dienstleistung der ZV Vergleich Usability • Professionelles zentrales System (GX-Verfahren) • Vollzugriff auf alle Möglichkeiten, die das System bietet • hohes Fachwissen des bedienenden Personals • geschultes Personal • regelmäßige Benutzung • vertraut mit Fachtermini • Support erreichbar

  5. QIS Modul COB („webCOB“) Add-On für COB COB-DB bleibt völlig unverändert KoSt-Verantwortlicher kann einfach über seinen Browser SSL-Verschlüsselt KoSt-Berichte erzeugen und abfragen Verbesserter und vereinfachter Datenfluss Beispiel: Kontrolling-Modul COB der HIS • COB-GX • C++ - Client • zentrale Informix-Datenbank • optimale Software für den Controller in ZV • Informationsfluss von ZV zu den KoSt-Verantwortlichen über KoSt-Berichte

  6. Der Einsatz von webCOB • Welcher Aufwand fällt an, um webCOB zu betreiben? • Betrieb eines Webservers, typischerweise mit SSL-Verschlüsselung • Betrieb des „Servlet-Servers“ Tomcat • webCOB selbst ist dann nur eine webapp von Tomcat • Schulung der HIS (webCOB-ADM) zeigt innerhalb von einem Tag die vollständige Installation auf einem Unix-System (Solaris oder Linux)

  7. Vorteile der Anwendung des „Add-On“ • die für die Kosten Verantwortlichen bekommen direkt Informationen aus dem Controlling • Kostentransparenz hin zu den letztlich für die Kosten Verantwortlichen • Entlastung der Zentralen Verwaltung, da die Berichte direkt tagesaktuell dezentral erstellt werden • Dienstleistung der ZV

  8. Zur Technik der Serveranwendung (I) • zentraler Unterschiede zwischen GX-Client und Servlet-Entwicklung: • Programmiersprache • Client ist typische C++-Entwicklung für Windows-Betriebssystem • Server-Anwendung ist Java-Servlet • Java, weil BS-unabhängig und (inzwischen) sehr stark bei Server-Entwicklungen • Servlet, weil für Anwendungen dieser Komplexität die optimale Technik

  9. Zur Technik der Serveranwendung (II) • Performance-Situation • während jeder Client eine eigene CPU verwenden kann, teilen sich im Web alle Clients die CPU des Webservers • von daher muss die Softwarearchitektur modifiziert werden • Beispiel: Auswertung von Baumstrukturen • typischer Client: rekursiver Algorithmus • Servlet: Implementierung von n-ären Bäumen, die nicht rekursiv, sondern iterativ verwendet werden • wichtig: Performance-Tests • Beispiel: Erzeugung zahlreicher Anfragen an Server durch PERL-Script mit LWP

  10. Zur Technik der Serveranwendung (III) • Datenbankanbindung • GX-Client verwendet eine Verbindung zum DBMS Informix • Webclient hat nur (SSL-)Verbindung zum Webserver • Servletcontainer verwendet einen Pool an Verbindungen zum DBMS, um immer eine Verbindung auf Vorrat zu haben

  11. Zur Technik der Serveranwendung (IV) • Benutzerverwaltung: • für „sehr dezentrale“ Anwendungen ist das bewährte Konzept aus den GX-Systemen nicht ideal • Konzept: die dezentralen Einrichtungen verwalten sich selbst, also legen selbst fest, wer auf ihre KoSt zugreifen darf • Benutzerverwaltung über Web • Ablegen der Daten in separater Datenbank

  12. Grobarchitektur, Variante I Web-Client Apache SSL Tomcat COB-GX Client I-Connect ConnectionPool(JDBC) COB-Datenbank (Informix)

  13. Grobarchitektur, Variante II Web-Client Tomcat SSL COB-GX Client I-Connect ConnectionPool(JDBC) COB-Datenbank (Informix) Berichts-DB (Informix, PostgeSQL)

  14. Realisierung und Stand • QIS Modul COB • gemeinsames Projekt der HIS und FH Kaiserslautern • Umfangreiche Testphase(n), auch Usability • Haupttester: Universität Leipzig • nur lizenzgebührenfreie Software(Ausnahme: Informix) • Release 1.0.0 ist seit 1.10.2002 in der Auslieferung über die HIS als Teil des COB-Bundles • Schulungen in Hannover und Stuttgart • aktuell: Release 1.0.2

  15. Features • integrierte Benutzerverwaltung in separater Datenbank • Konfiguration ausschließlich über XML • integrierte pdf-Generierung • integriertes Logging • Layout ist einfach aufgrund verwendeter Templates anpassbar (wird auch in Schulung behandelt)

  16. Verwendete Technik • Grundprinzip: möglichst weitgehende Nutzung vorhandener, bewährter SW-Pakete • Grundarchitektur: Jakarta-Projekt mit Tomcat • Verwendung des Velocity-Frameworks zur HTML-Generierung aus Templates • FOP (Formatting Objects Processor) für die pdf-Generierung • Log4j für Logging • JDOM für die Verarbeitung von XML • JNDI und Tomcat 4.1 für ConnectionPool • HSQLDB für die Benutzerdatenbank

  17. Erweiterung Haushalts-Information • Anregung der Universität Leipzig(Ursula Lennig et. al.): • „Internet-Blick“ auf die internen HISMBS-Daten(dort internes MBS-Unix)für Hochschulinstitute etc. • Wunsch: MBS-Auswertunsglisten 110 und 220 • Realisierung: Adaption des Frameworks von webCOB • aktuelles Projekt unter Beteiligung der KOS, U Leipzig, FH Kaiserslautern und HIS • Einbezug der HH-Information aus HIS QIS Modul FSV

  18. webbasiertes HH-Informationssystem • Kontenstandslisten • Liste 110 • Kontenstände der Haushaltskonten/Projektkonten • Einzelbuchungen in einem Buchungszeitraum • zusätzlich aggregierte Ausgabe der Kostenarten oder Ausgabearten (KoA für KoTr) pro Haushaltsjahr • Liste 220 • Übersichtsliste

  19. Aktuelle Entwicklung (I) • Integration der einzelnen serverbasierten Webmodule unter gemeinsamen Einstiegspunkt • der Einstiegspunkt („Portälchen“) übernimmt die Authentifizierung • je nach Authentifizierung Freigabe der jeweiligen Module

  20. Aktuelle Entwicklung (II) „Giebel“ Authentifizierung Zuordnung der Module ModulCOB ModulLSF ModulFSV Modul...

  21. Demonstration • Live-Präsentation webCOB Version 1.0.1

  22. ...vielen Dank für Ihre Aufmerksamkeit...

More Related