Systemarchitektur und Servicespezifikation

Transkript

1 Grid-basierte Plattform für die Virtuelle Organisation im Bauwesen Gefördert durch Förderkennzeichen: 01IG07001 BauVOGrid-Bericht A-2.2 Systemarchitektur und Servicespezifikation Verantwortlicher Partner: Verfasser: TU Dresden Alexander Gehre & Peter Katranuschkov, TUD Autoren: Alexander Gehre, Peter Katranuschkov, Ksenia Rybenko, Raimar J. Scherer, Faisal R. Shaukat, Steffen Unger, Andreas Hoheisel, Stefan Klose, Johannes Hoen, Peter Hornung, Zdzislaw Pozniak, Wolfgang Müller-Reinecke Datum : 20. August 2008 Version: 1.0 Verteiler: Projektpartner X Projektträger X D-Grid X Öffentlichkeit X Copyright: BauVOGrid-Konsortium Projektlaufzeit: 06/ /2010

2 BMBF-Projekt BauVOGrid BauVOGrid Bericht A-2.2 Systemarchitektur und Servicespezifikation BauVOGrid Konsortium 2008

3 Konsortium Institut für Bauinformatik der Technischen Universität Dresden Dresden Fraunhofer-Institut für Rechnerarchitektur und Softwaretechnik (FIRST) Berlin Institut für Wirtschaftsinformatik (IWi) im Deutschen Forschungszentrum für Künstliche Intelligenz (DFKI) Saarbrücken Seib InformationsTechnologie Consult GmbH (SEIB ITC) Würzburg Bilfinger Berger AG Mannheim BAM Deutschland AG Standort Dresden Dresden IDS Scheer AG Saarbrücken RIB Information Technologies AG Stuttgart TransMIT Gesellschaft für Technologietransfer mbh Gießen TUD FIRST IWI SEIB BB BAM IDS RIB TMIT Koordinator Institut für Bauinformatik der Technischen Universität Dresden Postanschrift: Kontakt: Institut für Bauinformatik TU Dresden Dresden Prof. Dr.-Ing. Raimar J. Scherer Telefon: +49/351/ Fax: +49/351/ Web:

4 Vorwort Vorwort Modernes Software Engineering sieht vor, ein komplexes System wie die verteilte Grid-Plattform des BauVOGrid-Projektes top-down, komponentenbasiert zu entwickeln. Dafür bedarf es, als ersten Schritt nach der Anforderungsphase die Architektur der Plattform mit allen wesentlichen Komponenten zu konzipieren. Diesem Ziel ist der vorliegende Bericht gewidmet. Er bildet, zusammen mit den technischen und nutzerspezifischen Anforderungen, dargestellt in den Berichten A-1.1 und A-2.1, die Grundlage für die Implementierung der anvisierten BauVOGrid-Services und Service-Clients sowie für ihre Integration mit den vorgesehenen vorhandenen Anwendersystemen. Der Bericht ist in die folgenden neun Kapiteln unterteilt: Kapitel 1 stellt kurz die anvisierte BauVOGrid-Plattform dar und erörtert die prinzipiellen Überlegungen, die zu der erarbeiteten Architektur geführt haben, sowie die domänen- und grid-spezifischen Constraints, die es zu berücksichtigen galt; Kapitel 2 liefert einen Überblick über die Gesamtarchitektur in ihrer allgemein konzipierten Form und in der spezifischen Ausprägung für die konkret geplante Pilotimplementierung; Kapitel 3 präsentiert in Kurzform die zugrunde liegenden Ontologiemodelle, die eine entscheidende Rolle zur Gewährleistung der semantischen Interoperabilität und Integrität der Plattform-Komponenten spielen und somit ein fester Bestandteil der Architektur bilden; weiterhin wird hier das wichtige Konzept der Business Process Objects eingeführt; Kapitel 4 bis 8 sind der Beschreibung der Komponenten auf den einzelnen Architekturebenen gewidmet, wobei das Kapitel 8 auch einen ersten Einblick in die Endnutzersicht gewährt; Kapitel 9 präsentiert schließlich eine Zusammenfassung der erreichten Ergebnisse. Im Anhang ist das ausgearbeitete Template für die interne, harmonisierte Servicespezifikation beigefügt. Die technischen Details der einzelnen Services stehen zu diesem Zeitpunkt (Anfang der Implementierungsphase) aus technisch-, wettbewerbs- und juristisch-relevanten Gründen nur den Konsortialpartnern zur Verfügung. Die breite Autorenschaft spiegelt schließlich die Mitwirkung fast aller Projektpartner bei der Erarbeitung der vorgestellten Architektur wider. Federführend für die Erstellung des Berichts selbst waren die zwei Verfasser. Versionshistorie Version Beschreibung Autor(en) Datum 0.1 Berichtsstruktur und prinzipielle Inhalte TUD Vollversion an Partner TUD Vollständige Version mit Zuarbeiten Alle Freigegebene Endversion TUD Seite 4 von 36

5 Systemarchitektur und Servicespezifikation Inhaltsverzeichnis 1. Einleitung 6 2. Gesamtarchitektur 7 3. Systemontologie Basiskomponenten / Genutzte D-Grid-Infrastruktur BauVOGrid Middleware Plattform-Management VO-Management Ressourcen-Management Workflow-Management Anwenderdienste Zentrales Mängelmanagement Medienmanagement Business Process Objects Management (BPO-Management) Mobile Dienste Zugangsdienste BauVOGrid-Portal Grid-RPC Web-Service-Gateway Geschäftsanwendungen MMS BH: EPLASS MMS GU: bebit MME MMS NU: RIB Mobile Medienmanagement Client: K-IMM Lokales Workflow-Management Interoperabilität Zusammenfassung 34 Referenzen 35 Anhang 36 Seite 5 von 36

6 Einleitung 1. Einleitung Ziel des BauVOGrid-Projektes ist es, die Struktur, Funktionsweise und Operabilität virtueller Unternehmen im Bauwesen durch eine wieder verwendbare Bau-Grid-Infrastruktur entscheidend zu verbessern. Um dies zu erreichen, wird ein D-Grid-basierter Lösungsansatz erarbeitet, der es ermöglichen soll: Zuständigkeits- und Autorisierungsstrukturen beherrschbar auf Rollenbasis abzubilden, globale VO-Prozesse sowie lokale unternehmensspezifische Prozesse schnell zu konfigurieren und entsprechend der Zuständigkeitsstruktur zu instantiieren und zu managen, Informationen aus unterschiedlichen Quellen (Dokumente, Zeichnungen, Produktdaten, Katalogdaten, Organisationsdaten etc.) integriert und schnell, flexibel und sicher sowohl im Büro als auch mobil auf der Baustelle zur Verfügung zu stellen, Ad-hoc-Änderungen von Prozessabläufen (z. B. ausgelöst durch Havarien oder Bauherrenentscheidungen) durch semi-automatische Simulation zu ermöglichen und so die Entscheidungsfindung zu beschleunigen und zu verbessern, die mobile Erfassung von Prozessen und Prozess- sowie Produktzuständen auf der Baustelle zu unterstützen und somit eine weiter verbesserte Grundlage für schnelle und effiziente Entscheidungsfindung unter Teilnahme der vor Ort beteiligten und verantwortlichen Personen herbeizuführen. Die erarbeitete Lösung demonstriert das BauVOGrid-Projekt anhand eines Pilot-Demonstrators für den Einsatzzweck des mobilen Mängelmanagements. Dafür sind mehrere auf unterschiedlichen Systemen basierende bestehende Anwendersysteme für das Mängelmanagement kohärent in die Plattform zu integrieren. Auf Basis dieser generellen Anforderungen sowie den in Gehre et al. (2008) zusammengefassten Technischen Anforderungen wurde die in diesem Bericht präsentierte Architektur unter Zusammenarbeit aller am BauVOGrid-Projekt beteiligten Partner erarbeitet. Neben der Adaption der Grid-Technologie für die Erfordernisse Virtueller Organisationen des Bauwesens liegt dabei der Hauptbeitrag des Projektes in der Erarbeitung der Architektur-Strategie für die Einbettung vorhandener Ingenieuranwendungen in diese neue Form sicherer service-orientierter Umgebungen. Aufgrund des Unikatcharakters der erarbeiteten Architektur ist nicht auszuschließen, dass sich im weiteren Projektverlauf kleine Änderungen bzw. Erweiterungen bezüglich des vorgelegten Architekturentwurfs ergeben. Sollte dies der Fall sein, wird dies im Abschlußbericht reflektiert werden. Die Grid-Technologie entwickelt sich nach wie vor mit einer hohen Geschwindigkeit weiter. Es ist daher möglich, dass schon zur Projektlaufzeit von BauVOGrid neue Module, speziell im Rahmen des Globus Toolkit, vorgestellt werden, deren Einsatz Auswirkungen auf die erarbeite Architektur hätte. Solche Neuentwicklungen werden vom Konsortium verfolgt und nach Möglichkeit bei der weiteren Arbeit berücksichtigt. Ziel des Projektes ist jedoch nicht die unbedingte Adaption der aktuell neuesten verfügbaren Grid-Technologie, sondern der praxistaugliche Einsatz des Grid-Konzepts. Das Konsortium behält sich daher vor, auf den Einsatz neuer Module und Technologien zu verzichten, wenn eine Adaption ein Risiko für den Zeitplan und/oder die Konsistenz der angestrebten Lösung darstellen könnte. Seite 6 von 36

7 Systemarchitektur und Servicespezifikation 2. Gesamtarchitektur Als Projekt der 2. D-Grid-Phase liegt der Fokus von BauVOGrid auf der Etablierung von endanwendernahen Middleware-Diensten unter Nutzung der in der 1. D-Grid-Phase aufgebauten Grid- Infrastrukturdienste. Diese bilden die technische Basis der BauVOGrid-Systemarchitektur, die in Abbildung 1 schematisch dargestellt ist. In BauVOGrid kommt dabei das Globus Toolkit (Sotomayor & Childers 2005) als Basissoftware zum Einsatz. Die Komponenten der BauVOGrid-Infrastruktur selbst sind auf die vier Ebenen Middleware-Dienste, Anwender-Dienste, Zugangsdienste, und Geschäftsanwendungen verteilt. Die Infrastruktur nutzt die D-Grid-Infrastruktur und bietet erweiterten Zugang sowohl für stationäre als auch für mobile Grid-/Web-Clients. Die dadurch gewonnene Flexibilität ist von entscheidender Bedeutung für die Akzeptanz der BauVOGrid-Plattform in virtuellen Unternehmen der Baupraxis, die i. d. R. durch eine hoch heterogene IT-Infrastruktur gekennzeichnet sind. Die vier BauVOGrid-Ebenen werden nachfolgend kurz vorgestellt und im Rahmen der folgenden Kapitel detaillierter erläutert, wobei auch auf die beiden Ebenen D-Grid-Infrastruktur und Clients eingegangen wird. Abbildung 1: BauVOGrid Systemarchitektur. (MMS = Mängelmanagementsystem, BPO = Business Process Object, RPC = Remote Procedure Calls) Seite 7 von 36

8 Gesamtarchitektur Auf der Grundlage der D-Grid-Infrastrukturdienste etabliert BauVOGrid Middleware-Dienste, die dem generellen Management der Plattform, gehosteter Virtueller Organisationen, ihrer Ressourcen und Prozesse dienen. Hierfür kommen erstmals auch semantische Technologien zum Einsatz, die es erlauben, modellbasierte Informationen modulübergreifend zu vernetzen. So können z. B. semantische Informationen aus dem Plattform-, VO- und Ressourcenmanagement für ein effizientes integriertes Workflowmanagement genutzt werden. Aufbauend auf den generischen BauVOGrid-Middleware-Diensten werden Anwender-Dienste zur Verfügung gestellt, die domänenspezifischen Anforderungen der Endanwender gewidmet sind. Im Rahmen der Pilotimplementierung des Projektes werden auf dieser Ebene Dienste für ein zentrales, firmenübergreifendes Mängelmanagementsystem, für die Integration und Nutzung von Business Process Objects in dem gesamten Geschäftsprozess, für das geschäftsprozessbegleitende Mediendatenmanagement und für die kohärente Integration mobiler Endgeräte erstellt. Diese Dienste stehen im direkten Kontakt mit den Endanwender-Applikationen, während sie selbst die Module der darunter liegenden Ebene (Middleware Dienste) nutzen. Die BauVOGrid-Plattform stellt weiterhin Zugangsdienste für den Zugriff auf den Plattform- Komponenten mittels Portal, Grid-Interfaces und Standard-Web-Services zur Verfügung. Im Gegensatz zu typischen Grid-Projekten für Forschungs-Communities, die (fast) ausschließlich auf durch Grid-Technologie gesicherte Kommunikation setzen, ist ein reiner Grid-Ansatz im Falle des BauVOGrid-Projektes nicht praxisgerecht. Aus der Anforderung an die Integration gewachsener Anwendersysteme, die von den beteiligten Firmen über lange Zeit entwickelt wurden und erfolgreich im Einsatz sind, ergibt sich die wichtige Forderung nach einer Lösung für die Einbettung nicht-gridfähiger Software (siehe BauVOGrid-Bericht A-2.1 Technische Anforderungsanalyse ). In BauVOGrid wird davon ausgegangen, dass als Mindestanforderung an die Geschäftsanwendungen der Endanwender ein Zugriff mittels Standard-Web-Services gilt. D. h. proprietäre Anwendersysteme müssen mindestens um SOAP-basierte Client-Interfaces erweitert werden, soweit sie diese noch nicht integrieren. Da diese Technologie als etabliert und zuverlässig gilt und für praktisch alle Programmiersprachen und Entwicklungsplattformen Web-Service- Integrationslösungen verfügbar sind, kann davon ausgegangen werden, dass auch spätere Nutzer der BauVOGrid-Plattform beim Zugriff auf die Plattformdienste nicht vor größere Herausforderungen gestellt werden. Für BauVOGrid bedeutet dieser heterogene Ansatz allerdings, dass mehrere Zugriffstechnologien kohärent integriert werden müssen. Während der Zugang mittels Portal oder gridfähiger Clients jedoch der Plattform die nötigen Informationen über den aktuellen Nutzer gewährleistet, ist dies beim Zugriff mittels Web-Services standardmäßig nicht der Fall. Die Bereitstellung eines Web-Service-Gateways zieht daher zusätzlichen Aufwand für die Abbildung von Nutzer-Rollen und -Rechten innerhalb der Plattform nach sich. Über jeweils eine der drei Zugangsarten werden Geschäftanwendungen eingebunden. Client- Anwendungen für die Nutzer der Plattform stehen für das Plattformmanagement selbst sowie als Ingenieursysteme, d. h. domänenspezifische Applikationen zur Verfügung. Für das Plattformmanagement wird eine gridbasierte Kommunikation vorausgesetzt, während Ingenieursysteme auch die im vorigen Abschnitt beschriebenen Web-Service-Interfaces nutzen können. Im Rahmen des BauVOGrid-Pilotprojekts sind drei lokale Mängelmanagementsysteme, stellvertretend für die beteiligten Rollen in einer VO (Bauherr, Generalunternehmer, Nachunternehmer), als Client- Anwendungen vorgesehen. Sie kommunizieren per Standard-Web-Services mit der Plattform, d. h. hauptsächlich mit dem Zentralen Mängelmanagementsystem. Die Integrationslösung für Ingenieursysteme, die mittels Standard-Web-Services eingebunden werden, ist in Abbildung 2 für die anvisierte Pilotimplementierung dargestellt. Die Client- Anwendungen in der dargestellten spezifischen Architektur des BauVOGrid-Pilotprojekts integrieren selbst Grid-Funktionalität, greifen jedoch über einen Gateway auf die Web-Servicebasierten Ingenieursysteme zu. Die Gateways implementieren dabei nicht nur die Zugriffsmethoden der Ingenieursysteme, sondern übersetzen auch Teile des rollenbasierten Zugriffsmodells in Seite 8 von 36

9 Systemarchitektur und Servicespezifikation die lokalen Methoden der Mängelmanagementsysteme. Dies umfasst neben den Nutzerdaten und jeweiligen Rollen der Akteure auch die Abbildung anderer notwendiger Stammdaten, in denen die lokalen Systeme vom VO-Modell der Plattform abweichen. Die Einbindung der Web- Services in die sichere Grid-Infrastruktur erfolgt mittels der YAGSI -Infrastruktur (Yet Another Grid Security Infrastructure). Die Integration der Web-Service-basierten Ingenieursysteme wird durch definierte semantische Modelle unterstützt, die es erlauben, mittels ausdrucksstarker Nachrichten zu kommunizieren, d. h. integrierte Informationen mit den Ingenieursystemen auszutauschen, die auf verschiedenen Plattform- und Anwendungsontologien basieren (z. B. Nachrichten, die auf VO-, Ressourcenund Mängelontologie gleichzeitig beruhen). Abbildung 2: Integration nicht-gridbasierter Ingenieur-Systeme im Demo-Szenario. (MMS = Mängelmanagementsystem, BH = Bauherr, GU = Generalunternehmer, NU = Nachunternehmer) Über die semantischen Modelle können lokale Modelle in den Ingenieursystemen teilweise mit abgebildet bzw. referenziert werden. Dies erleichtert das Mapping zwischen lokalen und Plattform-Systemen. Das im Rahmen von BauVOGrid entworfene System basiert auf Infrastrukturseite vollständig auf frei zugänglicher Grid-Software und -Standards. Die service-basierte Architektur wurde offen gestaltet und erleichtert so Erweiterungen im weiteren Projektverlauf sowie nach Abschluss des Projektes in einer nachfolgenden Phase kommerzieller Nutzung. Darüber hinaus ist die Architektur nicht nur auf das gewählte Pilotprojekt ausgelegt. Andere Einsatzgebiete sind mit wenig Aufwand mit den genutzten und neu entwickelten Infrastrukturkomponenten realisierbar. Seite 9 von 36

10 Systemontologie 3. Systemontologie Um die Interoperabilität und die Integrität der Komponenten der im vorhergehenden Kapitel dargestellten Architektur im Sinne der ausgetauschten und der gemeinsam genutzten Informationen zu sichern, ist es notwendig, ein plattformübergreifendes Modell zu definieren, dass von allen Komponenten gleichermaßen verstanden wird. Aus Erkenntnissen früherer Projekte, z. B. die EU Projekte K-Wf Grid und InteliGrid oder das BMBF Projekt icss, sowie Vorarbeiten innerhalb von BauVOGrid wurde hierfür die Semantic Web Technologie als das geeignete Mittel zur Erfüllung dieser Aufgabe gewählt. Die Methoden der konzeptionellen Modellierung, umgesetzt mit Hilfe der Semantic Web Technologie, ermöglichen eine einheitliche formale Beschreibung des Gesamtsystems mit allen Diensten, Daten und (Domänen-)Modellen und somit deren Auffindung, Integration und Anwendung. Die Semantic Web Technologie ergänzt insofern die Grid- Technologie und ermöglicht den ingenieurgerechten Zugriff auf die im Grid verteilten Ressourcen sowie den prozess-zentrierten Nutzungsansatz. Zentrale Aspekte der Anwendung des Semantic-Web-Ansatzes im BauVOGrid sind (1) die Definition des Umfangs, der Bestandteile und der Inhalte der Systemontologie, und (2) das Erarbeiten eines kohärenten Modells für die Laufzeitnutzung der BauVOGrid-Ontologien. Dabei ist es wichtig, dass das SOA-Konzept auch bei der Ontologieentwicklung angewendet wird, d. h. dass die Gesamtontologie nicht monolithisch, sondern vielmehr aus erweiterbaren (und ersetzbaren) Komponenten besteht und dass das Prinzip des Minimal Ontological Commitments bei dem Ontologiedesign eine leitende Rolle spielt. Abbildung 3 zeigt schematisch das entwickelte Ontologiekonzept, das im EU-Projekt InteliGrid einer ersten Verifikation unterzogen wurde (Dolenc et al. 2007). nutzt Organisationsontologie beschreibt repräsentiert Nutzer-/Rolle- Autorisierung Autorisierungsservice Verteilte Laufzeit- Plattform ref OWL RBAC Client- Anwendungen Prozessontologie nutzt Serviceontologie beschreibt Services repräsentiert BauVOGrid Services Web Services Web Services OWL ref OWL-S WSDL Ausgeführt auf nutzt Ressourcenontologie beschreibt Ressourcen repräsentiert OWL Ontologiespezifikationen Mehrfache Optionen Verteilte Grid- Umgebung Abbildung 3: Die prinzipielle BauVOGrid-Systemontologie in Zusammenhang mit der Systemarchitektur. Wie in Kapitel 2 schon dargestellt, erfolgt der Zugriff auf den Plattform-Services über die Client- Ebene (oben in Abbildung 2, rechts in Abbildung 3). Die weißen Kästen auf der linken Seite der Abbildung 3 zeigen schematisch die prinzipiellen Relationen zwischen den einzelnen (Teil-) Ontologien auf. Jedes dieser Kästen steht stellvertretend für weitere domänenspezifische Ontolo- Seite 10 von 36

11 Systemarchitektur und Servicespezifikation gien, die ergänzende Konzepte der Zieldomäne(n) abbilden können. Wie dies für den BauVOGrid- Pilotdemonstrator realisiert wird, ist in Abbildung 4 skizziert und in (Scherer et al. 2008) näher erläutert. Serviceontologie generisch domänenspezifisch Prozessontologie importiert importiert Mängelmanagement BPOs importiert Organisations- Ressourcenontologiontologie importiert Mängelontologie Konzepte Mängelmgmt. BPO Instanzen referenziert Laufzeit Mängeldaten Instanzen Abbildung 4: Prinzipielles Vorgehen für die Nutzung der domänenspezifischen Ontologien in dem BauVOGrid-Pilotdemonstrator Alle Ontologien werden in der OWL Sprache ( web ontology language ) spezifiziert (Dean & Schreiber 2004), das ihre einheitliche Anwendung in den BauVOGrid-Services, z. B. über SPARQL-Anfragen (Prud'hommeaux & Seaborne 2007), ermöglichen wird. Die Kästen in der mittleren Spalte der Abbildung 3 zeigen die prinzipiell erforderlichen Mappings der Ontologiekonzepte auf der Ebene der Middleware-Dienste, die nicht notwendigerweise die BauVOGrid-Ontologien verstehen werden. Es ist leicht zu erkennen, dass die Prozessontologie eine übergeordnete Rolle in dem Gesamtkonzept spielt. Sie bewerkstelligt, in Anlehnung an das ARIS-Konzept (Scheer 2000), eine integrierende Sicht auf das Gesamtsystem und ermöglicht die direkte Modellierung von Geschäftsprozessen. Darüber hinaus kann die Prozessontologie als Basis für das dynamische Prozessmanagement genutzt werden. Eine weitere wichtige Rolle ist der Organisationsontologie zugeteilt. Sie definiert Konzepte, wie z. B. Akteure, Rollen, Projekt- und Organisationsstrukturen, Teams und Personen, sowie die entsprechenden Autorisierungsprofile und Zugriffsrechte auf Ressourcen und Services. Somit wird die Trennung zwischen personenbasierter Authentifizierung über die Grid-Middleware und rollenbasierte Autorisierung entsprechend der konkreten VO-Semantik sichergestellt. Die Ressourcenontologie ist der Repräsentation aller Datenressourcen (Dateien, Dokumente, Modelldaten, Mediendaten) gewidmet, wobei sie nicht die eigentlichen Daten, sondern vielmehr die entsprechenden Metainformationen für deren Auffindung und Abfrage speichert. So werden z. B. Mängel- und Stammdaten bei den jeweiligen VO-Partnern lokal gehalten und über die Ressourcenontologie verlinkt. Dies ermöglicht das gezielte, zugriffgesicherte Aufrufen von Daten über entsprechende Basis- oder Anwenderdienste. Die Serviceontologie definiert schließlich die Metadaten über die Services und ihre eventuelle Orchestrierung zu Workflow-Bausteinen. Dies ermöglicht, ähnlich der Ressourcenontologie, die formale Bindung von Services zu Geschäftsprozessen sowie deren konsistente, rollenbasierte Nutzung. Seite 11 von 36

12 Systemontologie Die integrierenden Konzepte dieser vier unabhängigen Ontologien werden in der Prozessontologie definiert. Dies sind die Konzepte Business Process Object (BPO) und Business Process Pattern (BPP). Die Idee der BPO erweitert das bekannte Konzept des Business Objects (UIS 2006). Ein Business Object wird typischerweise durch ein Datenschema (Modell), Instantiierungsregeln und Methoden zur Verarbeitung der Daten definiert und stellt somit eine Verallgemeinerung von Software- Objekten dar. BPOs erweitern dieses Konzept, indem sie den Prozess, in welchem das Business Object verarbeitet wird, zusammen mit dem verantwortlichen Akteur, der den Prozess durchführen soll, die Akteure, die benachrichtigt werden sollen, die Daten, die in dem Prozess verarbeitet werden, und die Services, die für die Durchführung des Prozesses benutzt werden, in einheitlicher Form definieren (Katranuschkov et al. 2007). Abbildung 5 zeigt schematisch das Basis-BPO-Konzept der Prozessontologie mit der Verankerung der anderen Ontologien. Dadurch wird eine integrierte Sicht im Sinne des Semantic Web ermöglicht, ohne ein komplexes globales Modell erschaffen zu müssen. Attribute Deliverable Attribute Attribute Deliverable ❶ Element der Prozessontologie Message Before Event Process Resource After Event Message ❹ Element der Organisationsontologie Org. entity (actor) Info. Resource Service Resource ❷ ❸ Element der Ressourcenontologie Element der Serviceontologie Konnektor Business Process Object Abbildung 5: Schematische Darstellung des Basis-BPO Konzepts und der Verankerung der Organisations-, Ressourcen- und Serviceontologien in dem BPO (in unterschiedlichen Farben dargestellt) Das gezeigte Basis-BPO kann weiterhin über logischen Konnektoren vom Typ UNCONDITIONAL, AND, OR und XOR, ähnlich dem EPK-Modell zu Prozessketten erweitert werden. Dadurch können komplexere BPOs sowie BPPs definiert werden, die als parametrisierbare Prozessbibliothekbausteine die dynamische Prozessmodellierung sowie das ad-hoc Workflowmanagement unterstützen können. Das prinzipielle Verfahren zur BPO- und BPP-Nutzung ist in (Scherer et al 2008) vorgestellt. Weitere Details werden in dem Bericht A-3.1 Ontologiespezifikation (Dez. 2008) sowie in dem BauVOGrid Abschlußbericht (Mai 2010) präsentiert. Seite 12 von 36

13 Systemarchitektur und Servicespezifikation 4. Basiskomponenten / Genutzte D-Grid-Infrastruktur BauVOGrid nutzt als Grid-Infrastruktur das Globus Toolkit (Sotomayor & Childers 2005). Dieses besteht aus Modulen der Hauptkategorien Sicherheit, Datenmanagement, Ausführungsmanagement, Informationsdienste und Laufzeitumgebung. Nicht alle dieser Module sind für die Realisierung der BauVOGrid-Architektur notwendig. Die aktiv genutzten Module wurden in Abbildung 6 mit einer roten Umrandung markiert. Diese sind: OGSA-DAI, Index, C und Java WS Core, Delegation, Authentication/Autorisation (letzteres dem entsprechenden semantischen VO-Service nachgestellt s. Kap. 2, 7), Reliable File Transfer, GridFTP und, für C-basierten Implementierungen das C Common Libraries Modul. Abbildung 6: Genutzte Komponenten des Globus Toolkit. Seite 13 von 36

14 Basiskomponenten / Genutzte D-Grid-Infrastruktur Von besonderer Bedeutung für BauVOGrid ist der Zugriff auf verteilte Daten. Das GridFTP- Protokoll ist dafür gut geeignet und wird daher für den Dateiaustausch hauptsächlich zum Einsatz kommen. Es bietet einen sicheren, robusten und leistungsfähigen Transfer-Mechanismus, eine Reihe von Tools für das Erstellen und Manipulieren großer Datensätze sowie Fähigkeiten für das Management von Repliken. Das GridFTP-Protokoll selbst basiert auf dem bekannten und weit verbreiteten FTP-Protokoll. Weiterhin wird das OGSA-DAI Framework für den standardisierten Zugriff auf (Datenbank-) Daten und ihre Integration in übergeordnete Abläufe eingesetzt. Es ermöglicht auch einen generalisierten Zugriff auf Informationsressourcen (Textdateien, Datenbanken, XML-Dateien, usw.). BauVOGrid nutzt weitestgehend die im D-Grid bereitgestellten Infrastruktur-Ressourcen, d. h. Sicherheitsinfrastruktur sowie Speicher- und Processing-Kapazitäten. Für spezifische Services ist jedoch auch die Etablierung begrenzter neuer Ressourcen vorgesehen. Sie dienen speziell Testzwecken und Aufgaben im Rahmen des Demoprojektes. So existieren z. B. seitens der Endanwender Sicherheitsbedenken bezüglich der Speicherung sensibler Daten auf allgemeinen D-Grid-Servern. Dem wird durch lokale Speicherkapazitäten im BauVOGrid begegnet, die zwar weniger leistungsfähig sind, dafür aber unter der Kontrolle des Projektes und seiner Partner stehen. Abbildung 7: Semantisches rollenbasiertes Autorisierungsmodell von BauVOGrid. Das Grid-Rechtemanagement wird durch BauVOGrid mittels eines semantischen rollenbasierten Modells, teilweise in Abbildung 7 dargestellt, erweitert. Das Management der Nutzer- und Rollendaten wird durch den VO-Management-Service und einen entsprechenden Client mit GUI realisiert. Ein Entwurf für diese GUI ist in Abbildung 8 dargestellt. Abbildung 8: GUI-Entwurf für das Rechtemanagement, basierend auf semantischen Modellen. Seite 14 von 36

15 Systemarchitektur und Servicespezifikation Die Umsetzung des semantischen Datenmodells in reale Autorisierungsstrukturen wird über eine Anbindung an das zum Einsatz kommende VOMS (Alfieri et al. 2004) gemäß Abbildung 9 erzielt. Durch diesen Ansatz stehen die umfangreichen und ausdrucksstarken ontologiebasierten Nutzer- und Rollendaten allen Einsatzzwecken des BauVOGrid kohärent zur Verfügung (z. B. dem prozesszentrierten Mängelmanagement) und werden gleichzeitig auf das technische Management der Autorisierungen abgebildet. VO Management Service Abbildung 9: Verbindung des semantischen rollenbasierten BauVOGrid-Rechtemanagements mit dem VOMS. Seite 15 von 36

16 BauVOGrid Middleware 5. BauVOGrid Middleware Die BauVOGrid Middleware-Dienste dienen dem Plattformmanagement sowie der Verwaltung gehosteter Virtueller Organisationen, ihrer Ressourcen und Prozesse. Hierfür kommen die semantischen Technologien zum Einsatz, die es erlauben, modellbasierte Informationen modulübergreifend zu vernetzen Plattform-Management Der Dienst für das Management der BauVOGrid-Plattform dient der Verwaltung organisatorischer Aspekte der gridbbasierten Umgebung, d. h. er zentralisiert semantische Informationen über die in BauVOGrid aktiven Entitäten. Dieser sog. Gridspace umfasst die technologische Basisinfrastruktur (z. B. aus dem D-Grid), soweit sie von BauVOGrid genutzt wird, sowie die im BauVOGrid registrierten Dienstleister, Anwender und registrierten Virtuelle Organisationen. Durch ein einheitliches semantisches Modell für die Beschreibung der Infrastruktur und der Akteure können leicht neue Virtuelle Organisationen konzeptionell angelegt, konfiguriert und verwaltet werden. Wichtig ist, dass die semantischen Modelle direkt in die Autorisierungs- Infrastruktur abgebildet werden. Dadurch werden Konfigurationen in weiteren Grid- Sicherheitssystemen deutlich reduziert. Eine standardisierte auf semantischen Modellen basierende Servicebeschreibung nach dem OWL-S Modell (Martin et al. 2005) verbessert weiterhin die generische Erweiterbarkeit der Plattform sowie die flexible Konfiguration neuer Virtueller Organisationen. Der Dienst für das Plattform-Management ist als Web-Service mit Grid-Sicherheit ausgelegt. Das Datenmodell wird mittels Semantic Web Ontologien (in OWL) definiert. Als Datenaustauschformat kommt RDF zum Einsatz. Neben spezifischen Abfragemethoden können generische Abfragen mittels der SPARQL-Abfragesprache formuliert werden. Für ein anwenderfreundliches Management der Plattform-Daten ist eine GUI-basierter Client als Teil des BauVOGrid-Portals vorgesehen VO-Management Der Dienst für das VO-Management ähnelt dem des Plattformmanagement, hat als Kontext jedoch konkrete VOs, d. h. für jede auf der Plattform gehostete VO gibt es einen virtuellen sog. VO Space, der Informationen über alle Entitäten einer spezifischen VO bündelt. Dazu gehören neben Daten über die an der VO beteiligten Personen und Organisationen auch detaillierte Informationen über im Projekt definierte Rollen und die Zuordnung der Akteure zu diesem Rollen. Über das Konzept der Permissions können wiederum den Rollen feingranulare Rechtestrukturen auf Ressourcen (Dateien und Dienste) zugeordnet werden. Das Anlegen neuer bzw. die Auflösung bestehender VOs ist nicht Teil des VO-Managements sondern fällt in den Aufgabenbereich des Plattformmanagement. Erst wenn mittels dieses Dienstes eine neue VO aufgesetzt und initial konfiguriert wurde, kann sie mittels des Dienstes für das VO-Management verwaltet werden. Ähnlich dem Plattform-Management-Dienst ist der Dienst für das VO-Management als Web- Service mit Grid-Sicherheit ausgelegt. Das Datenmodell wird mittels Semantic Web Ontologien (in OWL) definiert. Als Datenaustauschformat kommt RDF zum Einsatz. Neben spezifischen Seite 16 von 36

17 Systemarchitektur und Servicespezifikation Abfragemethoden können generische Abfragen mittels der SPARQL-Abfragesprache formuliert werden. Der Zugriff auf das VO-Management geschieht über einen GUI-Client, der Teil des BauVOGrid- Portal sein wird Ressourcen-Management Mit dem Dienst für das Ressourcen-Management werden Metadaten über alle im BauVOGrid genutzte Ressourcen verwaltet. Dies sind hauptsächlich Dateien, Produktmodelle, Mediendaten, IT-Dienste, sowie komplexe Ressourcen (bestehend aus mehreren Ressourcen, die in einem gemeinsamen Kontext stehen). Grundlage des Dienstes ist eine spezielle Ressourcen-Ontologie, die auf verschiedenen Metadatenstandards basiert, und ihren Fokus auf strukturierte und unstrukturierte Daten legt. Für spezifische Anforderungen verschiedener VOs ist eine Erweiterung der Ressourcen-Ontologie und damit des Funktionsumfangs des Ressourcen-Management-Dienstes leicht möglich. Dies unterstreicht den generischen Plattform-Ansatz des BauVOGrid-Projektes. Spezifische Metadaten, die im Medienmanagement-Dienst verwaltet werden, werden im Ressourcen-Management-Dienst referenziert, d. h. alle Ressourcen-Informationen sind zentral über den Dienst des Ressourcen-Management erreichbar bzw. ermittelbar. Der Dienst für das Ressourcen-Management ist auch als Web-Service mit Grid-Sicherheit ausgelegt. Das Datenmodell wird mittels Semantic Web Ontologien (in OWL) definiert. Als Datenaustauschformat kommt RDF zum Einsatz. Neben spezifischen Abfragemethoden können generische Abfragen mittels der SPARQL-Abfragesprache formuliert werden Workflow-Management Der Grid Workflow Execution Service (GWES) koordiniert die Erstellung und Ausführung von Grid Workflows. Er implementiert das hochdynamische Workflow Konzept, das auf der Grid Workflow Description Language (GWorkflowDL) basiert. Die Prozessmodellierungssprache des Grid Workflow Management Systems basiert auf Petrinetzen, welche eine formale Analyse, Verifizierung und Optimierung der Workflows ermöglichen. Der Dienst für das Workflow-Management stellt Schnittstellen zum Web-Portal für die Nutzerinteraktion und zur Low-Level Grid-Middleware für den Start der Anwendungen zur Verfügung und erlaubt die interaktive Überwachung von deren Ausführung. In der derzeitigen GWES-Version kann im online-status ein GWUI auf den GWES zugreifen und entsprechende Aktivitäten auslösen. Die Portierung dieses GWUI auf mobile Endgeräte ist ebenfalls vorgesehen. Zusätzlich ist eine Version des GWES-Dienstes für mobile Endgerät geplant, die Teilworkflows auf dem mobilen Endgerät selbst anstoßen kann (auch im offline-staus) und im online-status mit dem Grid interagiert. Seite 17 von 36

18 Anwenderdienste 6. Anwenderdienste Zeil der Anwenderdienste ist es, domänenspezifische Anwendungen effizient zu unterstützen indem sie: (1) einen gezielten, rollen- und prozess-basierten, ingenieurgerechten Zugriff auf die Grid-Ressourcen gewährleisten, (2) existierende Endanwendersysteme miteinander verbinden, und (3) firmenübergreifende Funktionen, die für die Zusammenarbeit in einer VO von besonderen Bedeutung sind, anbieten. In der BauVOGrid-Pilotimplementierung werden 5 solche Komponenten realisiert, die im Folgenden dargestellt werden Zentrales Mängelmanagement Bedingt durch den spezifischen wirtschaftlichen und rechtlichen Anforderungen des Bauprozesses werden Mängel i. d. R. separat von jedem beteiligten Partner in einer VO behandelt. Dadurch entstehen typischerweise Wartezeiten, Wiederholungszyklen oder Missverständnisse, die die Effizienz des Gesamtprozesses massiv beeinträchtigen. Die Situation wird durch die Nutzung lokaler Mängelmanagementsoftware nur wenig verbessert, da die eingesetzten Systeme nicht interoperabel sind und/oder keinen differenzierten Zugriff auf die gespeicherten Daten ermöglichen, so dass sie als Folge externe Anfragen meistens zurückweisen. Ziel des zentralen Mängelmanagementdienstes (ZMMS) ist es hierzu Abhilfe zu leisten. Zum einen werden alle firmenübergreifenden sowie firmeninternen mobilen Funktionen aus dem EPK Mängelmanagement unterstützt (Katranuschkov & Lehner 2008), wobei das Augenmerk auf das korrekte auflösen der Nutzerrechte und das darauf folgende Delegieren der Abarbeitung an der entsprechenden Anwendung (MMS BH, MMS GU oder MMS NU) liegt. Zum anderen wird durch die Harmonisierung der Mängeldaten eine zentrale Abspeicherung aller Mängel für den schnellen Zugriff sowie für Archivierungszwecke ermöglicht. Es werden jedoch nur die reinen firmenneutralen Mängeldaten in dem ZMMS registriert. Für sensible Stammdaten, wie Firmenadressen, Kundendaten, Personaldaten, diversen Aktennotizen etc. wird ein Verfahren, basierend auf das RDF-Konzept entwickelt (Manola & Miller 2004), das es ermöglicht die Stammdaten zu verlinken, weiterzuleiten und berechtigten Personen zur Verfügung zu stellen, ohne dabei die tatsächlichen Daten selbst zu kennen und zu speichern. Zum korrekten aufschlüsseln der Nutzerberechtigung wird bei jeder Funktion die Organisationsontologie referenziert. Ein weiterer, wesentlicher Aspekt des ZMMS ist es, dass dadurch die direkte Kommunikation und somit die M:N Schnittstellen-Mappings zwischen der Anwendersysteme grundsätzlich abgeschafft werden, wie auch in Abbildung 2 gezeigt. Dies erleichtert nicht nur die Dateninteroperabilität, es ermöglicht vielmehr die durchgängige Nutzung der D-Grid-Sicherheitskonzepte auch wenn die Endanwendungen nur teilgridifiziert oder über reine Web Services mit den restlichen Plattform-Komponenten kommunizieren. Dadurch entsteht ein entscheidender Vorteil gegenüber den herkömmlichen Projekt-Portal- oder Client-Server-basierten Lösungen Medienmanagement Das Medienmanagement ermöglicht den zentralisierten Zugriff auf Mediendaten (Photos, Video-, Audiodaten), die für die effiziente Behandlung von Mängeln aber auch für diverse weitere Zwecke gesammelt und benutzt werden sollen. Es ist dabei möglich, dass Mediendaten sowohl direkt, bei der Feststellung und Meldung eines Mangels aufgenommen werden, als auch indirekt, aus anderem Anlass, entstanden sein können und später mit den Mängeldaten verknüpft werden sollen (z. B. Bilder / Videosequenzen einer Überwachungskamera). Wichtige Anforderungen sind u. a. das schnelle Sortieren und Auffinden der relevanten Mediendaten sowie die differenzierte, rechtlich gesicherte Zuordnung zu Nutzergruppen und Personen. Seite 18 von 36

19 Systemarchitektur und Servicespezifikation Die Funktionen des Medienmanagements können in 4 Gruppen unterteilt werden: (1) allgemeine Funktionen, (2) Ortsbasierte Such- und Zuordnungsfunktionen, (3) Zeitbasierte Such- und Zuordnungsfunktionen und (4) Gruppierungsfunktionen. Als Backend für den Medienmanagementdienst soll eine erweiterte web-service-fähige Version des K-IMM Systems (Mitschick & Fritzsche 2007) benutzt werden. Für mängelrelevante Abfragen wird der ZMMS referenziert. Zu den allgemeinen Funktionen gehören das Up- und Downloaden lokal aufgenommener Mediendaten, die Verschlagwortung der Mediendaten auf Basis einer Medienontologie und die Prüfung der Metadatenkonsistenz. Die ortsbasierte Funktionalität umfasst die Zuordnung der Mediendaten (1) zu einer konkreten Baustelle bzw. einem konkreten Bauabschnitt mittels Vergleich der aufgenommenen GPS Koordinaten mit der (vereinfacht) gespeicherten Baustellengeometrie, (2) zu konkreten Baumodellobjekten (Geschoss, Raum, Bauelement) sowie (3) zu konkreten Mängeln über eindeutigen Mängel- IDs, die vom zentralen Mängelmanagementsystem vergeben oder mittels fotografiertem Barcode direkt eingelesen und beiden Systemen zur Verfügung gestellt werden. Das Ergebnis der entsprechenden Such- und Abfragefunktionen können 0, 1 oder mehrere Mediendatenobjekte sein, die mit den Anfrageparametern und mit direkten oder von den Anfrageparametern abgeleiteten Suchkriterien übereinstimmen. Da das System ontologiebasiert aufgebaut ist, können solche Abfragen sehr flexibel, z. B. unter Verwendung der SPARQL-Sprache formuliert werden. Die zeitbasierte Funktionalität ist der ortsbasierten technisch sehr ähnlich, nutzt jedoch als Eingabe einen zeitlichen Bezug. Hierzu gehören die Zuordnung der Mediendaten zu einer vorgegebener Zeitspanne und das zeitabhängige Mappen der Daten zu Prozessphasen. Die Gruppierungfunktionen haben schließlich die essentielle Aufgabe, einen rollen-basierten firmenübergreifenden Team-Zugang zu den Mediendaten zu gewährleisten. Sie sollen ermöglichen bestimmte Mediendaten Nutzergruppen und Personen zuzuordnen und eindeutig identifizieren zu können. Hierzu ist es notwendig, dass der Medienmanagementservice das Rollenmodell des Mängelmanagements über das VO-Management referenziert und richtig interpretiert. Die Granularität der aufgelisteten Funktionen und ihre einheitliche semantische Basis ermöglichen weiterhin ihre Kombination in nutzerspezifischen Convenience Services, die im Rahmen der Pilotprojektimplementierung konkretisiert und realisiert werden Business Process Objects Management (BPO-Management) Ziel des BPO-Management-Dienstes ist es, den Workflow-Management-Dienst durch gezielte BPO-Abfragen zu ergänzen, um darauf basierend höherwertige Nutzerdienste entwickeln zu können. Die vorgesehene Funktionalität ist eng mit der Prozessontologie verbunden (s. Kapitel 3). Die Methoden werden als passive Anfragen implementiert, die Informationen aus der Ontologie liefern und bei der Suche, Informationsprüfung und Instanziierung von BPOs Abhilfe leisten sollen. Die geplanten Funktionen umfassen: (1) das Ermitteln der für einen bestimmten Prozess verantwortlichen Person/Team/Rolle, (2) das Auffinden eines passenden BPOs/BPPs nach vorgegebenen Kontextinformationen und/oder Schlüsselbegriffen, (3) das Instanziieren eines BPO mit den vorgegebenen Laufzeitparametern, (4) das Auffinden der zu einem BPO passenden Ressourcen, Anwendungen oder Services, (5) das Auflisten bestimmter BPO (Meta-) Daten, (6) das Aufzeigen der Abhängigkeiten zwischen vorgegebenen BPOs, um potentielle Konflikte zu vermeiden, (7) das Auflisten aller Funktionen, die für ihre Durchführung eine bestimmte Ressource benötigen (Unterstützung der räumlichen Ressourcen-Kollokation), (8) die Konsistenzprüfung eines instanziierten BPOs, um somit sicherzustellen, dass keine Deadlocks oder Data Loops in dem entsprechenden Workflow entstehen werden, und (9) das Mapping eines BPO zum von GWES benutzten GWorkflowDL (s. Kapitel 5.4). Seite 19 von 36

20 Anwenderdienste Voraussetzung für die korrekte Ausführung dieser Funktionen zur Laufzeit ist die vorherige Spezifikation einer Bibliothek parametrisierbarer BPPs. Hierzu werden im Rahmen der Pilotimplementierung die erarbeiteten EPK-Modelle für das Mängelmanagement und das Medienmanagment als Referenzmodelle betrachtet und in BPPs modularisiert. Maßgeblich für diese Modularisierung sind diverse Kriterien wie ausführende Rolle, die örtliche und zeitliche Lokation der Prozesse, bestimmte BPO-Interface-Regeln etc. Dies wird in dem nachfolgenden Bericht A-3.1 näher diskutiert. Der BPO-Management-Dienst nutzt intensiv in fast allen seiner Funktionen die unterliegenden BauVOGrid-Middleware-Dienste, insbesondere der VO-Management- und der Ressourcen- Management-Dienst Mobile Dienste Während die meisten BauVOGrid-Dienste sowohl von stationären als auch von mobilen Clients eventuell mit eingeschränkter Funktionalität benutzt werden sollen, sind zwei Dienste von ganz spezifischer Bedeutung für die mobile Nutzung. Der erste betrifft die Datensynchronisation nach temporärem Offline-Betrieb. Im Unterschied zu seiner relativ komplexen Realisierung kann der entsprechende Funktionsumfang geradlinig definiert werden, er umfasst die Synchronisation (1) aller Nutzerdaten, (2) der Daten in einem vorgegebenen oder vom Nutzer spezifizierten Zeitfenster, oder (3) der Daten entsprechend einem bestimmten Datenfilter, wobei für das letzte die Basisontologiefunktionen zur Hilfe herangezogen werden können. Der zweite Dienst betrifft die lokale Ortung, um Kontextdaten automatisch weitergeben und nutzen zu können. Mit Hilfe der Ortungskomponente wird die Benutzerposition festgestellt. Dabei ist zwischen einer globalen und einer lokalen Position zu unterscheiden. Globale Positionsdaten können per GPS und lokale Positionsdaten per W-LAN oder RFID-Tagging erhoben werden. Die gemessene Position ist eine wichtige Zusatzinformation bei der Datenerhebung während Baustellenbegehungen (wie z. B. im Mängelmanagement). Diese Position kann mit Hilfe von zuvor erstellten Tabellen oder einem vorhandene Bauwerkmodell auf Beschreibungen der Position abgebildet werden. So kann beispielsweise eine globale Position in den Namen einer spezifischen Baustelle oder eine lokale Position in eine Raum-/Etagenbeschreibung umgewandelt werden. Funktionen der lokalen Ortung sind: (1) die Bestimmung der Benutzerposition entweder global (GPS) oder mittels Signalstärketriangulierung, (2) das Mapping der ermittelten Position zu einer bestimmten Ressource / Baukomponente (Gebäude, Etage, Raum etc), (3) das Matching der aktuell ermittelten Position mit einem vorher gespeicherten (Mangel-)Objekt, und (4) die Kalibrierung der Signalquellen. Für alle diese Funktionen müssen gewisse technische Einschränkungen berücksichtigt werden. So funktionieren globale Ortungsverfahren (GPS) i. d. R. nur außerhalb Gebäuden. Zur Ortung innerhalb von Gebäuden muss eine lokale Infrastruktur (z. B. W-LAN) aufgebaut werden. Soll diese Infrastruktur auch für die Datenübertragung und nicht ausschließlich für die Ortung genutzt werden, müssen Interferenzen vermieden werden, die die Datenübertragung stören können. Des Weiteren muss zur Erstellung der Mapping-Tabellen eine Einmessung der Signalquellen erfolgen. Ändert sich das Signalquellenmuster beispielsweise durch den Einbau einer neuen Wand muss die Einmessung erneut erfolgen. Die Access Points müssen eine eindeutige und sichtbare SSID besitzen. Weiterhin ist zu berücksichtigen, dass sowohl globale als auch lokale Ortungsverfahren gewisse Ungenauigkeiten aufweisen. Zur Verbesserung der Werte kann auf Differenzsignale (z.b. differential GPS) zurückgegriffen werden. Dies soll im Laufe der Implementierung der Dienste genauer untersucht werden. Seite 20 von 36

21 Systemarchitektur und Servicespezifikation 7. Zugangsdienste BauVOGrid bietet drei Zugangsarten für die Nutzung der Plattform: über ein Projektportal, über Grid-Services, und unter Einschränkungen mittels Standard Web-Services. Die wichtigste Rolle spielt dabei das Projektportal, das eine Reihe von Clients für den Zugriff auf Plattformdienste integriert. Für eine Grid-basierte Plattform bietet der Zugriff über Grid-Service- Schnittstellen (Web-Services mit Grid-Sicherheitsfunktionalität) den effizientesten und sichersten direkten Zugang zur den Anwenderdiensten. Der (eingeschränkte) Zugang mittels Standard-Web- Services ist der gegenwärtigen Situation der Softwaretechnik im Bauwesen geschuldet und bietet ein Gateway in die Grid-Umgebung für nicht Grid-fähige Bestandssoftware BauVOGrid-Portal Das BauVOGrid-Portal ergänzt den bestehenden EPLASS-Server der Firma SEIB ITC. Es bildet die Eingangstür zum BauVOGrid und stellt somit einen zentraler Baustein der BauVOGrid- Architektur dar. Das Portal basiert auf dem Domino 8 Server von IBM. Die Technischen Anforderungen, die sich aus der Nutzung der EPLASS-Software ergeben, sind in dem Bericht A-2.1 Technische Anforderungsanalyse (Gehre et al. 2008) dargelegt. Durch den Einsatz von Lotus 8 bietet sich bei der Nutzung der EPLASS-Software durch BauVOGrid ein an die Eclipse Entwicklungsumgebung angelegtes Plug-In Konzept. Die Integration bzw. Kommunikation erfolgt dabei über die Web-Services-Technologie. Als Programmiersprache kann Lotus Script oder Java zum Einsatz kommen. Eine Ankopplung von Komponenten über das.net-framework ist ebenfalls möglich. Bei Zugriff auf die Plattformdienste mittels des Portals kann ein Single-Sign-On in BauVOGrid realisiert werden. Durch die Integration des Portals mit den semantischen Diensten basierend auf der Organisationsontologie und dem VOMS wird eine kohärente Lösung für eine rollenbasierte Autorisierung beim Zugriff auf durch das Portal integrierte Dienste erreicht. Innerhalb des Portals werden über Composite Applications verschiedene Module des BauVOGrids in einer Übersichtsseite zusammengefasst. Es stehen auch Teile der EPLASS Produktpalette (Mängelmanagement und DMS) zur Verfügung. Ein Screenshot der DMS-Funktionalität des Portals ist beispielhaft in Abbildung 10 dargestellt. Eine weitere wichtige Funktion des Portals ist die Integration verschiedener Clients für das Management der BauVOGrid-Plattform selbst. Diese sind insbesondere die GUI-Clients für das semantische Management des Gridspace und der VO-Spaces. Sie basieren auf der Java-Plattform und werden als Plug-In in das Portal eingebunden. Der Zugriff wird ebenfalls über das semantische Rollenmodell beschränkt. Weiterhin wird der Client zum Workflow-Management als Komponente des Portals eingebunden. Im Rahmen des BauVOGrid-Demonstrators soll das Portal auch einen Client für den Zugriff auf das zentrale Mängelmanagementsystem hosten. Seite 21 von 36

22 Zugangsdienste Abbildung 10: Dokumentenmanagement mit dem EPLASS-Portal Grid-RPC Dieser Standard-Zugang zu Grid-Diensten bietet einen verschlüsselten und über Nutzer- Zertifikate gesicherten Zugriff auf Dienste des BauVOGrid. Er stellt somit die Vorzugslösung für Anwendungen dar, die nicht in das Portal integriert sind und von extern auf Anwenderdienste zugreifen. BauVOGrid nutzt die Standard Grid-Service-Funktionalität, basierend auf dem Globus Toolkit. Die integrierte rollenbasierte Sicherheit wird über die von den Grid-Diensten durchgeführten Autorisierungs-Anfragen an das zentrale Rechtemanagement realisiert (VOMS und semantisches Rechtemodell) Web-Service-Gateway Wie in Kapitel 2 ausgeführt, ergibt sich in BauVOGrid die Anforderung der Nutzung von Standard-Web-Services als Bestandteil des BauVOGrid. Die Gewährleistung der Integrität des Systems wird durch den Einsatz der Yet Antother Grid Security Infrastructure YAGSI (Hoheisel et al. 2007), deren genereller Ansatz in Abbildung 11 angedeutet ist, erreicht. Seite 22 von 36

23 Systemarchitektur und Servicespezifikation Abbildung 11: Der YAGSI-Ansatz für die Einbindung von Standard-Web-Services in die Grid-Infrastruktur. (UKS = User Key Store) YAGSI setzt einen sog. User Key Store Service (UKS) und Service-Wrapper für die Standard-Web-Services ein und arbeitet mit Security Tokens, die neben dem Nutzer-Zertifikat noch zusätzliche Informationen wie z.b. eine ID und die Service URI des UKS enthalten. Für Details zum Ansatz sei auf Hoheisel et al. (2007) verwiesen. Mittels dieses Workarounds können vorhandene Web-Service-basierte Systeme in BauVOGrid eingebunden werden. Als Ziel kann jedoch eine mittelfristige Umstellung aller am BauVOGrid beteiligter Dienste auf Grid-Services mit vollständiger Sicherheitsfunktionalität formuliert werden. Seite 23 von 36

24 Geschäftsanwendungen 8. Geschäftsanwendungen Die Geschäftsanwendungen runden die BauVOGrid-Plattform ab und ermöglichen damit den gezielten praktischen Einsatz. Im Umfang der Pilotimplementierung im Bereich des Mängelmanagements kommen hierzu die folgenden zum Teil bestehenden Anwendungen in Frage, die für BauVOGrid adaptiert und je nach Einzelfall zu einem bestimmten Grad gridifiziert werden sollen: Das Mängelmanagementsystem EPLASS des Projektpartners SEIB ITC, das als MMS des Bauherren (BH) in den Szenarien eingesetzt werden soll; Das Mängelmanagementsystem bebit MME der Tochterfirma bebit des Projektpartners Bilfinger Berger als MMS der Generalunternehmers (GU); Das Mängelmanagementsystem RIB mobile des Projektpartners RIB Information Technologies stellvertretend für das MMS der einzelnen Nachunternehmer (NU) in einer Bau-VO; Das Medienmanagementsystem K-IMM entwickelt an der TU Dresden; Ein lokales Workflow-Management-System, derzeit in Entwicklung beim Projektpartner Fraunhofer FIRST. Weitere Ingenieurdienste werden im Verlauf der F&E-Arbeit aus Sicht der Praxis untersucht und bei bestehendem Bedarf und Ressourcenverfügbarkeit in BauVOGrid integriert MMS BH: EPLASS Zentrales Merkmal des Mängelmanagementsystems EPLASS ist die einfache und schnelle Eingabe der auf der Baustelle festgestellten Mängel. Dies geschieht mit Hilfe der in Abbildung 12 dargestellten Eingabemaske. Abbildung 12: Eingabemaske des MMS EPLASS Seite 24 von 36

25 Systemarchitektur und Servicespezifikation Das System vergibt automatisch eine eindeutige Mangelnummer und legt die Mängel in einer strukturierten Gliederung ab, die frei konfigurierbar und änderbar ist. Der Anwender kann über vorbelegte Listenfelder, Ankreuzfelder und durch freie Texteingabe die folgenden relevanten Daten eingeben: Kurzbeschreibung des Mangels Zuordnung des Mangels an einen Nachunternehmer Festlegung der Priorität Festlegung des derzeitigen Bearbeitungsstandes Festlegung eines Zieldatums zur Beseitigung des Mangels (KW und Datum) Zuordnung eines/mehrerer interner Bearbeiter Zusätzlich können dem Mangel in einem Freitextfeld beliebige Anhänge z. B. Fotos des Mangels, Schriftstücke von der Baustelle usw. zugeordnet werden. Die einzelnen Mängel werden automatisch über mehrere Ansichten kategorisiert abgelegt und können je nach Aufgabenstellung schnell wieder gefunden werden. Abbildung 13 zeigt eine Ansicht, die alle Mängel nach Priorität und Baustelle sortiert. Zudem wird angezeigt, für welches Protokoll (z. B. als Word-Dokument abgelegt) der jeweilige Mangel benutzt wurde. Damit wird ein Überblick geschaffen, welche Mängel in offiziellen Schreiben bereits verwendet wurden. Abbildung 13: Beispiel für die Möglichkeiten zum Sortieren der Mängel in EPLASS (hier: Sortieren nach Priorität) Vorgabewerte für das Projekt können individuell über ein Projektstammblatt eingestellt und jederzeit geändert werden (s. Abbildung 14). Über die integrierte vorlagengestützte Protokollfunktion können mit wenigen Mausklicks Protokolle, Mängel, Behinderungs- und Schadensanzeigen erstellt werden. Bestehende Vorlagen können mit geringem Aufwand in das System integriert werden. Abbildung 15 zeigt die zugehörige Officemaske und eine Beispielmangelanzeige mit automatischer Datenübernahme von den in Abbildung 13 markierten Mängeln. Abbildung 16 zeigt eine Beispielmangelanzeige mit automatischer Datenübernahme von den in Abbildung 13 markierten Mängeln. Seite 25 von 36

26 Geschäftsanwendungen Abbildung 14: Projektvorgaben im EPLASS (Anpassung an die BauVOGrid-Plattform erfolgt über die Systemontologie) Abbildung 15: Definition einer Vorlagemaske im EPLASS Abbildung 16: Beispiel für die automatisierte Mangelanzeige mit EPLASS Seite 26 von 36