Exposé zur Diplomarbeit

Exposé zur Diplomarbeit von Michael Otto <3otto@informatik.uni-hamburg.de> und Norbert Schuler <3schuler@informatik.uni-hamburg.de>

1. Motivation Der Arbeitsbereich Softwaretechnik am Fachbereich Informatik der Uni Hamburg treibt zur Zeit mit großem Aufwand die Entwicklung des arbeitsbereichseigenen Java-Rahmenwerks JWAM voran. Um die Konstruktion von Software mit JWAM zu erproben, wurde die Helpdesk Taskforce 1 mit dem Ziel gegründet, eine Applikation in einem größeren Rahmen und mit realem Bezug zu entwickeln: ein Helpdesk-System, bei dem Benutzer Support-Anfragen an eine Gruppe qualifizierter Fachleute stellen. Das System soll die Handhabung von Anfragen und deren Lösung in Rückfrage mit dem Benutzer erlauben (vgl. [Zühlke 99]). Bereits zu Anfang entschied die Taskforce, sehr flexiblen Zugang zum Helpdesk-System von unterschiedlichen Arbeitsplatztypen aus mit unterschiedlichen Oberflächen zu erlauben: Die Bedienung sollte sowohl über den Desktop, wie auch über einen Web-Browser (HTML-Oberfläche, [W3C 98]) und auch einen E-Mail-Client möglich sein. Nachdem wir einige Entwürfe für das Helpdesk-System nach dem Werkzeug & Material-Ansatz [Züllighoven 98] gemacht hatten, stellten sich die ursprünglich für einen Desktop-Arbeitsplatz konstruierten Entwürfe als für einen Web-Browser-Arbeitsplatz völlig unpassend heraus. Schon die Trennung eines Werkzeugs in Interaktionskomponente (IAK) und Funktionskomponente (FK), wie sie in WAM verwendet wird, kann bei der Konstruktion für einen Web-Browser- Arbeitsplatz nicht aufrechterhalten werden. An der Stelle des Schnitts zwischen Client und Server im Werkzeug funktioniert die Kopplung zwischen beiden Teilen wegen des Übertragungsprotokolls HTTP [RFC 2616] nur in einer Richtung das führt dazu, daß beim Web-Browser-Arbeitsplatz beispielsweise die FK niemals die IAK benachrichtigen könnte; im HTTP sind nur Anforderungen von Client zu Server vorgesehen 2. Hinzu kommt noch, daß reines HTML 3 als Oberfläche keinerlei Intelligenz besitzt und solche umgekehrten Anforderungen gar nicht verarbeiten könnte. Noch problematischer sieht es mit einer Bedienung des Helpdesk-Systems durch E-Mails aus. Die Oberfläche von E-Mails [RFC 822] kann nichts handhabbar machen, das der Metapher Werkzeug gerecht wird. Die einzige Interaktivität von E-Mails liegt darin, was und ob man etwas verschickt oder geschickt bekommt. Der Mailinglisten-Server Majordomo [], wie er im Arbeitsbereich SWT verwendet ist, ist ein gutes Beispiel für Mail als Benutzerschnittstelle. Diese Einschränkungen bedeuten jedoch nicht, daß die Konstruktion solcher Anwendungen, beispielsweise eines Helpdesk-Systems, mit HTML- oder Mail-Oberfläche unmöglich wäre die Existenz zahlreicher solcher Systeme beweist das Gegenteil. Es liegen jedoch bisher kaum Erfahrungen bei der Realisierung solcher Benutzerschnittstellen mit WAM vor. Wir möchten in unserer Arbeit Lösungen für die beschriebene Problemstellung suchen. Dabei konzentrieren wir uns auf die Frage, wie unterschiedliche Oberflächen und Arbeitsplatztypen so unterstützt werden können, daß nicht für jeden Arbeitsplatztyp die gesamte Applikation neu 1 bestehend aus Holger Bohlmann, Martin Lippert, Marco Zühlke, Christian Beis und den Autoren dieser Arbeit 2 Das sogenannte Server Push lassen wir unbeachtet. Es ist erstens ungeeignet, weil es zwar den umgekehrten Weg erlaubt, dann aber nur diesen, und zweitens ist es nicht standardisiert. 3 ohne Erweiterungen wie JavaScript oder JScript, die nicht allgemein standardisiert sind 2

geschrieben werden muß. Es muß nach einer Möglichkeit gesucht werden, den jeweiligen technischen und fachlichen Anforderungen der Arbeitsplatztypen gerecht zu werden und gleichzeitig, eine gemeinsame Systembasis zu verwenden. Als Lösung scheinen uns Fachliche Services geeignet. Die Idee der Konstruktion von Software mit Fachlichen Services ist, das bei konventionellen WAM-Entwürfen in den verschiedenen Werkzeugen verstreut implementierte fachliche Wissen über den Umgang mit den Materialien der Anwendung an zentraler Stelle zusammenzufassen und den Arbeitsplatzsystemen als Dienst anzubieten. Die unterschiedlichen, durchaus nicht zwingend nach der Werkzeug-Metapher konstruierten Applikationen setzen auf diesem fachlichen Dienst auf und stellen die Schnittstelle zum Benutzer her. Durch diese Konstruktion kann sich der Entwickler auf den Entwurf der tatsächlich technisch unterschiedlichen Teile der Anwendung beschränken, während die Systembasis gleich bleibt. Fachliche Services sollen der Gegenstand unserer Diplomarbeit sein. 2. Fachliche Services Ein Fachlicher Service faßt das Wissen eines Anwendungsbereichs zusammen, kapselt es und stellt es den mit ihm arbeitenden Komponenten als Dienstleistung unter verschiedenen Aspekten zur Verfügung. Dabei bleibt die Schnittstelle des Service statisch, seine Inhalte können jedoch den sich ändernden Anforderungen angepaßt werden. Der Fachliche Service arbeitet auf Materialien der Anwendung und verwaltet diese selbst oder läßt sie von einem dritten Fachlichen Service verwalten. Ein Fachlicher Service enthält keine kurzlebige Applikationslogik und keine vorgeschriebenen fachlichen Abläufe. Sollten bestimmte Arbeitsplatztypen Abläufe nötig machen, weil ihre Anbindung an die Fachlichen Services automatenartig konstruiert werden müssen (z.b. Web-Zugang), so sind die Abläufe in einer Zwischenschicht außerhalb der Fachlichen Services unterzubringen (siehe Bild 1). Fachliche Services arbeiten auf Materialien der Anwendung, kapseln diese jedoch nicht völlig vor den sie benutzenden Komponenten. Diese kennen die benötigten Materialien und können damit umgehen, ohne jedoch (zu viel) fachliches Wissen umzusetzen. Fachliche Services können hierarchisch angeordnet werden und ihre Dienstleistungen gegenseitig nutzen. In Analogie zu den Aspekten, unter denen Materialien betrachtet werden können, können bestimmte Dienste Fachlicher Services ebenfalls über Aspekte gebündelt werden. Diese recht abstrakt anmutenden Eigenschaften Fachlicher Services sollen nun anhand eines Beispiels erläutert werden. Fachliche Services orientieren sich als Entwurfsmetapher an Dienstleistungen im Alltag. Wir wollen hier kurz die Analogie am Beispiel einer Autowerkstatt als Dienstleister aufzeigen. Wie der Kunde einer Autowerkstatt nichts von Autoreparaturen versteht, so weiß der Klient des Fachlichen Service nicht, wie genau dieser seine Aufgaben erledigt. So wie die Autowerkstatt 3

Mitarbeiter und eventuell andere Unternehmen mittelbar und unmittelbar zur Reparatur eines Autos heranzieht, kann auch ein Fachlicher Service andere Services zur Erbringung seiner Leistung in Anspruch nehmen. Bestimmte Materialien, wie z.b. Ersatzteile oder spezielle Werkzeuge benutzt die Autowerkstatt ohne explizites Wissen des Kunden. Genauso kann ein Fachlicher Service benutzte Materialien und andere Hilfsmittel vor seinem Klienten verbergen. Eine Autowerkstatt wird von einem Ersatzteillieferanten oder einem Autohersteller anders angesprochen als von einem Kunden, trotzdem ist es noch der gleiche Dienstleister. Dies entspricht den unterschiedlichen Aspekten, unter denen Fachliche Services in Anspruch genommen werden können. Über die Zeit hinweg muß sich die Reparaturarbeit der Autowerkstatt den sich ändernden Fahrzeugbaureihen und Herstellungstechniken anpassen, der Zugang zum Kunden ändert sich hingegen nur viel langsamer, die gebotenen Dienstleistungen bleiben im wesentlichen die gleichen, oder es kommen neue hinzu. Dies entspricht der statischen Schnittstelle und sich dynamisch ändernden Inhalten Fachlicher Services. Andere Eigenschaften von Dienstleistungen im Alltag lassen sich jedoch schwieriger auf Fachliche Services übertragen: Zum einen wird man kaum eine Vielzahl konkurrierender, praktisch gleich orientierter Fachlicher Services von einer Arbeitsumgebung aus ansprechbar antreffen 4. Umgekehrt wird man bei der Inanspruchnahme der Dienstleistung einer Autowerkstatt vermutlich doch fachliche Abläufe finden, beispielsweise dadurch, daß man einen Reparaturauftrag ausfüllen muß, bevor der Mechaniker mit der Reparatur beginnt. Solches Gebaren würde man aber wohl als schlechten Service bezeichnen wollen, und in diesem Sinne kann es ja auch übertragen verstanden werden. Das Ziel beim Entwurf von Software, die sich Dienstleistungen in Form Fachlicher Services bedient, ist es, mit dem laufzeitarchitekturneutralen, einheitlichen Grundgerüst der Fachlichen Services alle oder möglichst viele Arbeitsplatztypen und Oberflächen unabhängig voneinander zu unterstützen. Bild 1 zeigt beispielhaft eine Software-Architektur, die sich Fachlicher Services bedient; die Extreme verschiedener Arbeitsplatztypen werden von (Thin-Client-)Desktop, Webtop und E-Mail- System verkörpert. Der für alle Arbeitsplatztypen gleiche Grundstock aus Fachlichen Services wird über eine laufzeitarchitekturabhängige Zwischenschicht angesprochen: Beim Desktop übernehmen dies die Funktionskomponenten 5 der den Fachlichen Service benutzenden Werkzeuge, bei den anderen Arbeitsplatztypen regeln Elemente wie Servlets [Sun 99a] die Kommunikation zwischen Oberfläche und Fachlichem Service. 4 Wir lassen hier einmal die kommerziell orientierten Dienste des Internet außer Betracht. Diese würden wir aber (noch) nicht als Fachliche Services nach dem Verständnis dieser Arbeit ansehen. 5 Hierbei wird es sich vermutlich um im Umfang stark reduzierte FKs handeln, da fachliches Wissen in die Fachlichen Services verlagert wurde. 4

Thin-Client- Desktop Desktop IAK/ Repräsentation Webtop (Webbrowser, HTML) Mailclient, E-Mails Repräsentation FK-Fragment Client ULC-Protokoll/RMI RMI/CORBA (IIOP) HTTP SMTP/POP3/IMAP Server laufzeitarchitekturabhängige Zwischenschicht IAK FK-Fragment Servlet (FK-Fragment) fachliche Abläufe Mail- Verarbeitung fachliche Abläufe laufzeitarchitekturneutrale Schicht FS-Aspekt FS-Aspekt FS-Aspekt Fachlicher Service 1 FS-Aspekt FS-Aspekt FS-Aspekt Fachlicher Service 2 Aspekt Aspekt Aspekt Aspekt Material A Material B Bild 1: Laufzeitarchitekturneutrale Softwarekonstuktion für verschiedene Arbeitsplatztypen mit Fachlichen Services Die Konstruktion der Helpdesk-Applikation nach diesem Ansatz erlaubt es nun, eine einheitliche Grundarchitektur mit Fachlichen Services wie z.b. einem Anfragedienst zu entwerfen, auf der dann verschieden ausgeprägte Architekturen aufsetzen können, ohne daß diese das gesamte fachliche Wissen über Anfragen neu implementieren müssen. 3. Entwurf Fachlicher Services Für den Entwurf Fachlicher Services bieten sich grundsätzlich zwei Möglichkeiten: Die Entwickler entwerfen ihre Software wie gewohnt mit Werkzeugen, die in IAKs und FKs getrennt sind. Durch Abstraktion des fachlichen Anwendungswissens aus den FKs bzw. Weglassen der Applikationslogik ergeben sich eventuell Dienste, die dann von Fachlichen Services übernommen werden. Andersherum könnten die Entwickler auch versuchen, 5

Dienstleistungen um ein bestimmtes Material der Anwendung herum zu gruppieren. Wie genau dieser Arbeitsprozeß vonstatten geht, und ob er auch für z.b. Webtop und E-Mail-System sinnvoll ist, die ja gar nicht nach der Werkzeug-Metapher konstruiert werden können, bleibt zu untersuchen. Bei der zweiten Möglichkeit müssen die Entwickler Fachliche Services schon im Entwurfsprozeß berücksichtigen. Konzepte des Anwendungsbereichs mit Dienstleistungscharakter müssen herausgearbeitet, untersucht und dann in Fachliche Services umgesetzt werden. Hierbei bleibt zu untersuchen, ob dieser Weg überhaupt gangbar und sinnvoll ist. 4. Vorgehen In der Diplomarbeit wollen wir das Konzept der Fachlichen Services erarbeiten und vertiefen. Dazu soll die beispielhafte Implementation eines Helpdesk-Systems auf Basis Fachlicher Services die Grundlage bilden. Als Oberfläche wollen wir eine HTML-basierte Webtop-Lösung mit Java-Komponenten auf der Serverseite erstellen. Wir schätzen hier die Chancen, daß man den Kern Fachlicher Services herausarbeiten kann, als besonders gut ein, weil man bei dieser Lösung auf eine strikte Trennung zwischen Applikationslogik/Oberfläche und fachlichem Wissen fast zwingend angewiesen ist, während bei einer Desktop-Lösung viele Teile ohne technische Schwierigkeiten sowohl auf der einen als auch auf der anderen Seite implementiert werden könnten. Konkret wollen wir untersuchen, wie man Fachliche Services sinnvoll konstruiert, wie die übrigen Elemente der geschilderten Architektur aussehen, wie Fachliche Services untereinander und mit den sie benutzenden Komponenten kommunizieren, wie man Fachliche Services sinnvoll verteilt und wie sie sich von Automaten, Archiven und Materialverwaltern abgrenzen. Es bleibt zu untersuchen, ob der Dienstleistungscharakter Fachlicher Services nur für den Entwickler sichtbar ist, oder ob Fachliche Services ein auch für den Benutzer der Software greifbares Konzept werden; denkbar sind beide Varianten. Wir wollen versuchen, von den erzielten konkreten Ergebnissen auf allgemeine Eigenschaften, Umgangsformen und Konstruktionsarten Fachlicher Services zu schließen. Hierzu sollen alternative Entwürfe getestet und verglichen werden. Weiterhin wollen wir prüfen, ob und wie sich die Idee Fachlicher Services in das Framework JWAM integrieren läßt und welche Teile hieraus sinnvoll verwendet werden können. Darüber hinaus sollen auch die Konsequenzen für den Entwicklungsprozeß nach WAM analysiert werden. Die technische Realisierung Fachlicher Services könnte als Enterprise JavaBeans geschehen. Diese Spezifikation von Sun Microsystems beschreibt ein Komponentenmodell für Java, das wir momentan für die geeignete Plattform für diese Aufgabe halten. Sun selbst nennt die Abtrennung der fachlichen Anwendungslogik ( business logic ) von der technischen Infrastruktur als wichtigste Motivation für den Einsatz von Enterprise Java Beans [Sun 99b]. 6

Als Oberflächen- und Funktionalitätsprototyp für die angestrebte Lösung soll die bereits von uns erstellte CGI-Version dienen. 5. Einordnung des Begriffs Service Der Begriff Service oder Dienst in der Informatik-Literatur ist vornehmlich technisch geprägt. Der Standard Open Systems Interconnection (OSI) definiert einen Dienst als Leistung, die eine abstrakte Schicht einer darüberliegenden Schicht liefert (vgl. [Kerner 93]). Im Open Distributed Processing (ODP) ist ein Dienst eine Funktion, die von einem Objekt angeboten wird (vgl. [Popien 95]). Die Middleware CORBA [Mow & Mal 97] stellt dem Anwendungsentwickler grundlegende sogenannte CORBAservices beispielsweise für Persistenz und Transaktionsunterstützung von Objekten und darauf aufbauende fachlicher orientierte CORBAdomains und Application Services zur Verfügung. Ein Service ist in diesem Umfeld eine feste Schnittstelle für technische und fachliche Dienstleistungen. Die Motivation für die Verwendung von Services wird technisch begründet. Zum einen fehle verteilten Anwendungen der gemeinsame Adreßraum, zum anderen seien Services wegen ihres bausteinartigen und passiven Charakters und durch die völlige Trennung vom Klienten besser wiederverwendbar [Mow & Mal 97]. Die genannten abstrakten Definitionen des Begriffs Service passen auf sehr viele Ausprägungen der Datenkommunikation zwischen zwei Partnern; wenn ein Objekt eine Methode an einem anderen ruft, ist dies als Dienst des aufgerufenen Objekts im Sinne obiger Definition zu betrachten (vgl. Vertragsmodell in [Züllighoven 98]). Fachliche Services sollen begrifflich enger gefaßt werden. Wie oben am Beispiel demonstriert, sollen Fachliche Services aus (fachlichen) Dienstleistungen im Alltag hergeleitet und an diesen orientiert werden, auch wenn die ursprüngliche Motivation für den Einsatz Fachlicher Services wie anfangs geschildert eine technische war. Die Hierarchie Fachlicher Services sehen wir beweglicher als im angedeuteten OSI-Modell, in dem eine Schicht die Dienstleistungen tiefer unten liegender Schichten nur interpretiert über die direkt folgenden Schicht in Anspruch nehmen kann. Fachlich entspräche das beispielsweise dem Dienst eines Zeitungsgrossisten, den der Zeitungskäufer nur über den Einzelhändler in Anspruch nehmen kann. Solche Zwischenschichten bei Dienstleistungen im Alltag sind meist zweckmäßig und oft traditionell verankert. Jedoch sollen nicht alle Mechanismen alltäglicher Dienstleistungen auf Fachliche Services übertragen werden. Fachliche Services sollen grundsätzlich jedem Teilnehmer offenstehen, der diese nutzen möchte. Wir glauben, daß dies eine flexiblere Anwendungsarchitektur ermöglicht. 7

6. Literatur [Kerner 93] Helmut Kerner. Rechnernetze nach OSI. Addison-Wesley, Bonn Paris Reading, Mass, 1993. [Mow & Mal 97] [Popien 95] Thomas J. Mowbray, Raphael C. Malveau. CORBA Design Patterns. John Wiley & Sons, Inc., New York, 1997. Claudia Popien. Dienstvermittlung in verteilten Systemen: Dienstalgebra, Dienstmanagement und Dienstanfrageanalyse. B.G. Teubner Verlagsgesellschaft, Leipzig 1995. [RFC 822] Request For Comments 822, http://sunsite.cnlab-switch.ch/ftp/doc/ standard/rfc/8xx/822, August 1982. [RFC 2616] Request For Comments 2616, http://sunsite.cnlab-switch.ch/ftp/doc/ standard/rfc/26xx/2616, Juni 1999. [Sun 99a] Sun Microsystems. Java Servlet Specification Version 2.2 Public Draft. http://java.sun.com/products/servlet/, Juni 1999. [Sun 99b] Sun Microsystems. Enterprise Java Beans Specification 1.1 Public Draft 3. http://java.sun.com/products/ejb/, Juli 1999. [W3C 98] World Wide Web Consortium. HTML 4.0 Specification. http://www.w3.org/tr/rec-html40/, April 1998. [Zühlke 99] Marco Zühlke. Ein Helpdesk-System mit JWAM. Arbeitsbereich Softwaretechnik, Fachbereich Informatik, Universität Hamburg, voraussichtlich 1999. [Züllighoven 98] Heinz Züllighoven. Das objektorientierte Konstruktionshandbuch. Nach dem Werkzeug & Material-Ansatz. Dpunkt-Verlag, Heidelberg, 1998. 8