Technische Open Source Komponenten implementieren die Referenzarchitektur Quasar

Transkript

1 Technische Open Source Komponenten implementieren die Referenzarchitektur Quasar Dr. (Ph.D.) Bernhard Humm sd&m Research Herrnstraße Offenbach am Main Abstract: Quasar ist eine Referenzarchitektur für betriebliche Informationssysteme, welche langjährige Projekterfahrung bei sd&m kondensiert. In Quasar werden technische Dienste mittels Schnittstellen spezifiziert. Diese Schnittstellen wurden bei sd&m in Form von technischen Komponenten, genannt Quasar-Komponenten, implementiert. Quasar-Komponenten verwenden Open Source Klassenbibliotheken und sind selbst Open Source. Quasar-Architektur, -Komponenten und die Expertise ihrer Nutzung bilden ein Lösungspaket, welches bereits in vielen umfangreichen Projekten bei sd&m erfolgreich eingesetzt wurde. 1 Einleitung Einer der wesentlichen Erfolgsfaktoren für die sichere und effiziente Entwicklung qualitativ hochwertiger Software-Lösungen ist eine gute Software-Architektur. Das Architekturwissen für betriebliche Informationssysteme wurde bei sd&m zur Referenzarchitektur Quasar (Quality Software Architecture, [DS00], [Sid03], [Sid04]) verdichtet. Die wesentlichen Quasar-Konzepte sind die Komponentenbildung und die Trennung von Fachlichkeit und Technik. Technische Dienste der Architektur, z.b. Persistence, Authorization und Client, können durch Komponenten implementiert werden. Die Erfahrung aus zahlreichen Projekten hat gezeigt, dass der Einsatz technischer Komponenten die Sicherheit und Effizienz der Entwicklung und die Qualität des Ergebnisses deutlich verbessern kann. Voraussetzung dabei ist die Passung der Komponenten zur Architektur, die Qualität der Komponenten und die Expertise der Nutzung. Aus diesem Grund hat sd&m im Rahmen einer strategischen Initiative Komponenten für technische Dienste der Quasar-Architektur entwickelt und setzt diese konsequent ein. Ein wesentlicher Aspekt ist die Bereitstellung der Komponenten als Open Source [OpenQuasar] unter einer Common Public Licence (CPL). Dies gibt den Kunden einen klaren rechtlichen Rahmen und damit Sicherheit und bietet so auch sd&m einen Wettbewerbsvorteil.

2 In den folgenden Abschnitten zeigen wir, wie sich die Quasar-Architektur und die Komponenten gegenseitig ergänzen und so einen wertvollen Lösungsbaustein bilden. 2 Quasar: Eine Referenzarchitektur für betriebliche Informationssysteme 2.1 Übersicht Unter einem technischen Dienst verstehen wir die Spezifikation (Syntax, Semantik und Protokoll der Nutzung) einer Menge von Schnittstellen, die gemeinsam eine sinnvolle Einheit bilden. Ein technischer Dienst kann als Komponente implementiert werden. In diesem Abschnitt geben wir einen Überblick über die wesentlichen technischen Dienste der Quasar-Architektur und beschreiben beispielhaft die Schnittstellen eines konkreten Dienstes, nämlich Persistence. Die folgende Abbildung 1 gibt eine Übersicht über die technischen Dienste in Form eines UML Component Diagrams. cd Quasar Architecture Client Management «A Component» Dialog Application Component Management «A Component» Application Component Authorization Alternatives Transaction Persistence Abbildung 1: Technische Dienste der Quasar-Architektur

3 Technische Dienste werden als UML Components (Stereotyp <<T Service>>) dargestellt. Die wesentlichen technischen Dienste betrieblicher Informationssysteme sind Persistence, Transaction, Authorization, Application Component Management und Client Management. Konkrete Anwendungskomponenten (Stereotyp <<A Component>>) nutzen die technischen Dienste. Dies ist durch Dependency-Pfeile dargestellt. 2.2 Persistence Interfaces Technische Dienste bestehen aus einer Menge von Schnittstellen, welche die Kernfunktionalität des Dienstes spezifizieren. Die folgende Abbildung 2 gibt eine Übersicht über die Interfaces des technischen Dienstes Persistence im Zusammenspiel mit Transaction. cd Persistence Interfaces «A Component» Application Component Transaction Pool Query Transaction ResourceHandling Persistence Abbildung 2: Interfaces Persistence Eine Anwendungskomponente ruft die Interfaces Transaction, Pool und Query (Call Interfaces). Der technische Dienst Persistence muss das ResourceHandling Interface des Dienstes Transaction implementieren (Callback Interface). Abbildung 3 zeigt beispielhaft die Spezifikation der Syntax der Schnittstellen Pool und Query in Java Notation. interface Pool { public Object make(class instancetype) public void delete(object pooledobject) public Query definequery(object querydefinition) }

4 interface Query { } public Object execute(object[] arguments) Abbildung 3: Interfaces Pool und Query make erlaubt die Anlage von Objekten im Pool; delete bewirkt deren Löschung. Mittels definequery können Abfragen auf den Pool spezifiziert und mittels Query.execute ausgeführt werden. Die Semantik der Schnittstelle lässt sich mit (semi) formalen Notationen, besonders Vor- und Nachbedingungen spezifizieren. Das Protokoll der Schnittstelle, besonders das Zusammenspiel mit dem Dienst Transaction, ist über Szenarien darstellbar. 2.3 Weitere technische Dienste Auf diese Weise sind die folgenden technischen Dienste spezifiziert: Transaction: Bereitstellung der Transaktionssemantik (Atomicity, Consistency, Isolation, Durability) für einen oder mehrere Pools Authorization: Definition und Prüfung von Zugriffsrechten Application Component Management: Strukturierung von Anwendungskomponenten und Bereitstellung querschnittlicher Funktionalität wie Konfiguration und Fehlerbehandlung Client Management: Bereitstellung einer Rahmenarchitektur und Bibliothek für die Implementierung grafischer Benutzeroberflächen 2.4 Weitere Referenzarchitekturen Neben Quasar gibt es noch weitere Referenzarchitekturen für Informationssysteme. Prominente Beispiele sind: CORBA (Common Object Request Broker Architecture) [CORBA]: Herstellerunabhängige OMG Spezifikation von Architektur und Infrastruktur zur verteilten Verarbeitung von Anwendungen J2EE: (Java 2 Platform, Enterprise Edition) [J2EE]: Sun Standard zur Entwicklung komponentenbasierter, mehrschichtiger Geschäftsanwendungen

5 .NET [.NET]: Zusammenfassung von Software-Technologien von Microsoft für die verteilte Verarbeitung zwischen Systemen und Geräten Quasar ist nicht als Konkurrenz zu den genannten, weit verbreiteten und teilweise schon lange veröffentlichten (de facto) Standards zu verstehen. Quasar hat einen anderen Fokus. Auf der einen Seite beziehen sich die genannten Referenzarchitekturen jeweils auf bestimmte Technologien; dabei nimmt die Technologiebindung von CORBA über J2EE zu.net zu. In J2EE beispielsweise werden konkrete Ablaufumgebungen (Container) spezifiziert, die von Produktherstellern direkt implementiert werden können. Quasar dagegen ist ganz bewusst technologieunabhängig und hat die Trennung von Anwendung und Technik als ein tragendes Prinzip. Von daher ist die Quasar-Architektur abstrakter als die genannten Referenzarchitekturen. Auf der anderen Seite gibt Quasar konkrete Hilfestellungen bei der Konstruktion betrieblicher Informationssysteme, also der Komposition von fachlichen und technischen Komponenten zu einer Anwendung. Dies ist nicht der Fokus der oben genannten Referenzarchitekturen. Beispielsweise ist mit der Existenz von Session und Entity Beans (J2EE) noch keine Aussage zur Nutzung der Technologien für betriebliche Informationssysteme gesagt. Die Quasar-Referenzarchitektur gibt hier konkrete Empfehlungen zu einer technikneutralen Implementierung der Anwendungskomponenten und zu einem lokalisierten Einsatz von J2EE-Konzepten, speziell Session Beans nur an der Schnittstelle zu Clients und Entity Beans nur an der Schnittstelle zur Datenbank. Von daher ist Quasar konkreter als die genannten Referenzarchitekturen. 3 Quasar-Komponenten: Implementierungen der Quasar-Interfaces 3.1 Übersicht Das Wissen um technische Dienste der Quasar-Architektur ist schon wertvoll beim Design betrieblicher Informationssysteme. Eine zusätzliche Effizienzsteigerung in der Implementierung bringen, wenn richtig eingesetzt, einsatzfertige technische Komponenten, die die Interfaces der technischen Dienste implementieren. Aus diesem Grunde hat sd&m im Rahmen einer strategischen Initiative einen Baukasten von Open Source Komponenten, genannt Quasar-Komponenten, entwickelt und zusammengestellt und eine Organisation für den effizienten Projekteinsatz aufgebaut. Abbildung 4 gibt einen Überblick über den aktuellen Baukasten von technischen Komponenten.

6 cd Quasar Components Quasar Views «A Component» Dialog Quasar Process Quasar ApplicationComponents «A Component» Application Component Quasar Authorization Alternatives Quasar LocalTransaction Quasar Persistence Abbildung 4: Übersicht Quasar-Komponenten QuasarPersistence ist eine hochoptimierte Implementierung des technischen Dienstes Persistence. Quasar LocalTransaction ist eine einfache Implementierung des JTA- Interfaces [J2EE] für nicht verteilte Transaktionen. Die QuasarPersistence kann mit dieser einfachen JTA-Implementierung, aber auch mit anderen Implementierungen, z.b. eines Application Servers, integriert werden. QuasarAuthorization ist eine mächtige Implementierung des Authorization Dienstes. QuasarApplicationComponents und QuasarProcess sind derzeit in der Entwicklung und implementieren den technischen Dienst Application Component Management. QuasarViews ist eine erste Implementierung des technischen Dienstes Client Management. Eine Erweiterung ist derzeit Gegenstand intensiver Forschung bei sd&m Research. QuasarPersistence ist unter [OpenQuasar] als Open Source veröffentlicht und weitere Quasar Komponenten werden folgen.

7 Analog zu den Referenzarchitekturen sind die Quasar Komponenten keine Konkurrenz zu gängigen Produkten, weder zu kommerziellen noch zu Open Source. Auf der einen Seite komplettieren sie das Produktangebot auf dem Markt, wo noch keine Lösungen etabliert sind. Beispiele sind QuasarViews und QuasarAuthorization. Zum Anderen lassen sie sich in Produkte integrieren, z. B. QuasarPersistence in kommerzielle Application Server. Allen Komponenten ist gemein, dass sie die Quasar Architektur implementieren. So implementiert z. B. die Komponente ApplicationComponents die Standard-Architektur des Anwendungskerns [Sied03]. Die Komponenten Persistence, Views und Authorization sind in der Praxis erprobt und sd&m hat seit 2000 eine hohe Expertise der Nutzung aufgebaut. Beispielsweise wird die QuasarPersistence in 17 Projekten eingesetzt, davon 16 bei sd&m mit einem Gesamtaufwand von mehreren Hundert Bearbeiterjahren. Bereits acht Systeme sind produktiv und weitere stehen kurz vor der Einführung. 3.2 Komponentenauswahl Die Auswahl der Komponenten des Baukastens erfolgt bei sd&m in Form einer strategischen Zwei-Jahres-Planung, die jährlich fortgeschrieben wird. Die folgenden Kriterien gelten für die Aufnahme: Der Baukasten enthält Komponenten genau für die technischen Dienste der Quasar Architektur, da diese zentral für alle betrieblichen Informationssysteme sind Alle Komponenten sind oder werden als Open Source veröffentlicht. Dies gibt den Kunden eine rechtliche Sicherheit des Einsatzes und erhöht die Attraktivität aufgrund der Herstellerunabhängigkeit und fehlender Lizenzkosten Die Komponenten müssen eine ausreichende Qualität für den Einsatz in großen und kritischen Projekten haben Für alle Komponenten muss eine hohe Expertise der Nutzung (Außensicht) vorliegen beziehungsweise aufgebaut werden Für alle Komponenten muss Expertise für die Anpassung (Innensicht) vorliegen, damit die Komponente bei Bedarf projektspezifisch angepasst werden kann Abbildung 5 zeigt den aktuellen Stand der Planung.

8 Technischer Dienst Komponenten 2004 Komponenten 2005 Client Management Forschung, QuasarViews QuasarClient neu Application Component Management Entwicklung (Quasar- Process, Quasar- ApplicationComponents) QuasarProcess, Quasar- ApplicationComponents Authorization QuasarAuthorization QuasarAuthorization Persistence QuasarPersistence QuasarPersistence, evt. -> Hibernate Bemerkenswert sind die folgenden Aspekte. Abbildung 5: Strategische Planung Komponenten Die unterschiedlichen Reifegrade der Komponenten spiegeln sich in der Planung wider. Zum Beispiel wird QuasarAuthorization gewartet, während QuasarApplicationComponents entwickelt wird. Expliziter Forschungsbedarf (Client Management) wird eingeplant. Der Baukasten wird regelmäßig mit dem Open Source Markt abgeglichen. Sobald die oben genannten Kriterien erfüllt sind (Qualität, Expertise der Nutzung und Anpassung), können Quasar-Komponenten durch andere Open Source Komponenten ersetzt werden, z.b. QuasarPersistence möglicherweise in 2005 durch Hibernate [Hibernate]. 3.3 Komponentenentwicklung Die Entwicklung der Quasar Komponenten erfolgte in konkreten Kundenprojekten, wobei mit den Kunden ein Vertrag über die Veröffentlichung als Open Source geschlossen wurde. Die Weiterentwicklung erfolgt in einem Entwicklungsteam bei sd&m Research. Für die Software-Entwicklung werden Open Source Werkzeuge wie CVS, Bugzilla und Ant eingesetzt. In den Komponenten verwenden wir Open Source Klassenbibliotheken wie JUnit, log4j, Xalan, Xerces und Wings.

9 3.4 Komponenten-Support Da die Expertise der Nutzung einer der wesentlichen Erfolgsfaktoren für den Einsatz von technischen Komponenten ist, wurde neben dem Entwicklungsteam ein separates Support Team etabliert. Es hat die folgenden Aufgaben Unterstützung von Akquisitions- und Projektteams bei Architekturentscheidungen, besonders zum Einsatz von technischen Komponenten Unterstützung von Projektteams bei der Installation, Konfiguration und Nutzung technischer Komponenten First-Level Support (Hotline) für Probleme beim Einsatz von Komponenten 3.5 QuasarPersistence: Eine Implementierung des Interface Pool Dieser Abschnitt soll das Zusammenspiel von Quasar-Architektur und Quasar- Komponenten anhand der Außensicht der QuasarPersistence verdeutlichen. Für weitere Information zu QuasarPersistence und das darauf abgestimmte Modellierungswerkzeug Modellers Workbench siehe [Ern04] und [OpenQuasar]. QuasarPersistence implementiert die Interfaces Pool und Query. Abbildung 6 zeigt zentrale Methoden der wichtigsten Java Interfaces. package com.sdm.quasar.persistence; public interface Pool extends NamedObject { } public abstract Persistent make( Class instancetype, Object[] primarykey, LockMode lockmode) throws PersistenceException; public abstract void delete( Persistent persistent, int timeout) throws PersistenceException; public abstract void lock( Persistent persistent, LockMode lockmode, int timeout) throws PersistenceException; public abstract void store(persistent persistent) throws PersistenceException;

10 package com.sdm.quasar.persistence.query; public interface QueryManager { } public abstract PreparedQuery preparequery( Pool pool, LockMode lockmode, int timeout, String oql) throws PersistenceException; public interface PreparedQuery { } public abstract QueryResult execute( Object[] arguments) throws PersistenceException; Abbildung 6: Außensicht QuasarPersistence An dem Beispiel können die folgenden Aussagen zum Zusammenspiel zwischen technischen Diensten der Quasar-Architektur und der konkreten Komponente deutlich gemacht werden. Die Komponente implementiert konzeptionell die Interfaces des technischen Dienstes. Das bedeutet, dass Methoden in Komponenten-Interfaces existieren, deren Semantik der von Methoden der Dienst-Interfaces entsprechen. Die Syntax kann aber durchaus unterschiedlich sein. Beispiel Pool.defineQuery und QueryManager.prepareQuery Die Komponente erweitert üblicherweise die minimalen Schnittstellen der technischen Komponenten um Funktionalität, die es erlaubt, spezifische Anwendungssituationen abzudecken bzw. zu optimieren. Beispiel: Pool.store zum setzen von Modifikationskennzeichen (Dirty Bits) und Pool.lock zum expliziten Locking. Komponenten erweitern üblicherweise die minimalen funktionalen Schnittstellen um Komfort-Methoden (Convenience), welche die Aufrufe für Anwendungsprogrammierer vereinfachen (in Abbildung 6 ausgelassen). Die Komponenten-Interfaces konkretisieren Parameter, die aus Gründen der Allgemeingültigkeit in der Schnittstelle des technischen Dienstes offen bleiben. Beispiel: Die Query Definition, in der Dienstschnittstelle als Object typisiert, wird in der Persistence Schnittstelle als OQL-String (Object Query Language) spezifiziert. Dahinter steht eine umfangreiche Spezifikation der Query Syntax [oql].

11 4 Fazit Eine gute Software-Architektur ist einer der wesentlichen Erfolgskriterien für Software- Projekte. Quasar ist eine Referenzarchitektur für betriebliche Informationssysteme, die Architekturwissen aus Individualsoftwareprojekten bei sd&m mit insgesamt vielen tausend Bearbeiterjahren verdichtet. Quasar ist veröffentlicht und somit von der gesamten Informatik-Gemeinschaft nutzbar. Die technischen Dienste der Quasar-Architektur wurden im Rahmen einer strategischen Initiative durch Komponenten implementiert und können, wenn richtig eingesetzt, die Effizienz der Implementierungsphase deutlich erhöhen. Ein wesentlicher Bestandteil der Strategie ist der Einsatz von Open Source: Open Source Komponenten geben den Kunden rechtliche Sicherheit und sind attraktiv aufgrund der Herstellerunabhängigkeit und entfallender Lizenzkosten. Die Quasar-Komponenten stellen einen wesentlichen Open Source Beitrag dar. Umgekehrt werden bei der Entwicklung Open Source Werkzeuge und Klassenbibliotheken verwendet ein Geben und Nehmen. Sind die Randbedingungen gegeben, so können einzelne Quasar-Komponenten durch andere Open Source Komponenten ersetzt werden. Den Rahmen dafür gibt die Quasar- Architektur, der somit auch eine wichtige Rolle als Programm für Open Source Entwicklungen spielt. Ein wesentlicher Erfolgsfaktor für den Einsatz von technischen Open Source Komponenten ist die Expertise der Nutzung (Außensicht) und, wenn nötig, zur Anpassung (Innensicht). Umfangreiche Projekterfahrungen haben gezeigt, dass der Komponenteneinsatz unter diesen Rahmenbedingungen ein Erfolg ist. Literaturverzeichnis [CORBA] OMG Homepage für CORBA: [DS00] Denert, Ernst: Siedersleben, Johannes: Wie baut man Informationssysteme? Überlegungen zur Standardarchitektur. Informatik Spektrum Nr. 4/2000, S [Ern04] Ernst, Andreas: Quasi-stellares Objekt; Objektbasierte Datenbankzugriffsschicht Quasar Persistence, Javamagazin 3/04, S , [Hibernate] Relational Persistence For Idiomatic Java: [J2EE] Sun Homepage für Java 2 Enterprise Edition: java.sun.com/j2ee [.NET] Microsoft Homepage für.net: [openquasar] Homepage für Quasar-Komponenten: [oql] Object Query Language der Object Data Management Group: [Sied04] Siedersleben, Johannes: Moderne Software-Architektur umsichtig planen, robust bauen mit Quasar. Zu erscheinen im dpunkt Verlag [Sied03] Siedersleben, Johannes (Hrsg.): Quasar: Die sd&m Standardarchitektur. Teile 1 und 2, 2. Auflage. sd&m Research, 2003.