Web-Services als Basis für evolvierbare Softwaresysteme; Web-services as basis for evolvable...

1 Einleitung

In den letzten funf Jahren hat das Internetin das tagliche Leben der meisten Men-schen Einzug gehalten. Das aktuelle Kino-programm, der Bahnfahrplan und dieNachrichten um nur einige wenige Bei-spiele zu nennen sind heute in Sekun-denschnelle zugreifbar. Bucher, Aktienund andere einfach definierte Wirtschafts-guter, insbesondere auch digital kommuni-zierbare Informationen, werden mit mehroder weniger groen Transaktionskosten-vorteilen fur Endverbraucher im Internetgehandelt. Die Geschwindigkeit undStruktur des Internets erlauben auch neueArten der wirtschaftlichen Interaktion wiezum Beispiel weltweite Auktionen oderdas sogenannte Co-Shopping fur die breiteMasse.

Auf der Infrastruktur des Internets wurdendiese Anwendungen im Wesentlichen alsthin-client, fat-server-Anwendungenrealisiert, deren Nutzung beim Endver-braucher minimalen Aufwand verursacht(Aufruf einer URL uber einen zumeist aufdem Rechner vorinstallierten Browser).Die durch Risikokapital finanzierte Eu-phorie der letzten Jahre vor der weltweitenKrise hatte dazu gefuhrt, dass alle mogli-chen und unmoglichen Auspragungen die-ses Modells ausprobiert wurden. Neben ei-ner groen Anzahl von Investitionsruinenkristallisierten sich einige wenige, Erfolgversprechende Konzepte heraus, die heuteTeil der Geschaftsstrategie vieler alter undeiniger uberlebender neuer Unternehmensind.

Nun stellt sich die Frage nach der nachstenStufe in der Entwicklung Internet-basierterAnwendungen. Fur die major playersIBM, SUN und Microsoft lautet die Ant-wort auf diese Frage ohne Zweifel: Web-Services.

Die Grundidee der Web-Services ist ein-fach (fur eine detaillierte technische Be-schreibung sei auf die Seiten des W3CKonsortiums unter www.w3c.org verwie-sen): Der Server stellt seine Dienste nichtmehr (nur) in Form von fur Menschenkonzeptionierten HTML-Frontends zurVerfugung, sondern uber standardisierteSchnittstellen, die direkt von anderenComputern gelesen und bedient werdenkonnen. Im Gegensatz zur HTML-Dar-stellung werden die zwischen den Syste-men auszutauschenden Informationen nurgema ihrer logischen Struktur als standar-disierte XML-Dokumente dargestellt (siehe[W3C00]). Der Standard fur diese Kopp-lung heit SOAP und wird in [W3C01a]beschrieben. Die Abbildung der auszutau-schenden Information in XML-Dokumen-ten zusammen mit der Verwendung vonStandardprotokollen zum Datentransport(HTTP) erlaubt die einfache und damit zu-verlassige und kostengunstige Integrationvon verteilten Softwaresystemen.

Ein einfaches Beispiel ist die Integrationvon Informationssystemen bei Kundenund Zulieferern: Angenommen, ein Pro-duktionssystem beim Kunden bemerkt denBedarf eines Bauteils. Stellt der Zuliefererlediglich ein HTML-Frontend zu seinemBestellsystem zur Verfugung, so muss dasProduktionssystem einem Mitarbeiter desKunden den Bedarf mitteilen, der dann die

WIRTSCHAFTSINFORMATIK 44 (2002) 5, S. 435445

Der Autor

Oliver Stiemerling

Dr. Oliver Stiemerling,ecambria systems GmbH,Hospeltstrae 35a,50825 Koln,E-Mail: [email protected]

Web-Services als Basisfur evolvierbare Softwaresysteme

WI Schwerpunktaufsatz

Bestellung manuell in das Bestellsystemdes Zulieferers eingibt. Stellt der Zuliefererhingegen einen Web-Service zur Ver-fugung, so kann das Produktionssystemdes Kunden den Bedarf des Bauteils direktan das Bestellsystem des Zulieferers uber-mitteln. Bild 1 stellt diese beiden Arten derSystemintegration dar.

Die Vorteile der Web-Service-Losung sindoffensichtlich (wobei diese Vorteile auchdurch andere Technologien im Bereich derProzessautomatisierung erzielt werdenkonnen):

& Fehlervermeidung durch Wegfall dermanuellen bertragung der Daten.

& Beschleunigung des gesamten Prozesses.& Vereinfachung der Schnittstelle auf die

essenzielle fachliche Logik.

Eine Realisierung dieser Vorteile kann zuProduktivitatssteigerung und Kosten-ersparnis fuhren, was als kommerziellesHauptargument fur die erwartete Akzep-tanz dieser neuen Technologie in der In-dustrie vorgebracht wird.

2 Evolvierbarkeitvon Softwaresystemen

Dieser Beitrag hat zum Ziel, anhand vonErfahrungen mit einem produktiven Sys-tem einen weiteren Vorteil einer Web-Ser-

vice-Architektur zu belegen, der erst nachder Integration eines Gesamtsystems zumTragen kommt:

& Evolvierbarkeit des Softwaresystems,d. h. seine Anpassbarkeit an veranderteAnforderungen

Auf den ersten Blick erscheint dieser Punkteine eher technische Natur zu haben. Diepraktische Projekterfahrung zeigt jedoch,dass Evolvierbarkeit letztendlich auch furden kommerziellen Erfolg des Software-systems entscheidend ist: Ein Unterneh-men und seine Interaktionen mit Kundenund Partnern sind einer starken Dynamikausgesetzt. Folglich andern sich die Anfor-derungen an die geschaftlichen IT-Systemeund Schnittstellen standig. Diese mussenan die neuen Anforderungen angepasstwerden, d. h. mit den Bedurfnissen desUnternehmens evolvieren, ansonsten ver-lieren sie ihre unterstutzende Funktionund damit ihren kommerziellen Wert.

Die Eigenschaft Evolvierbarkeit ist im Ge-gensatz zu quantifizierbaren Vorteilen wieBeschleunigung oder Fehlervermeidungeher qualitativer Natur und damit nurschwer bewertbar. Ob ein System einfachan Veranderungen in seinem Umfeld an-passbar ist, lasst sich nur vorhersagen,wenn die zukunftigen Anforderungen ge-nau bekannt sind. [Parn72] hat gezeigt,dass zwei Architekturvarianten des glei-chen Softwaresystems vollkommen unter-

schiedliche Aufwande bei der Anpassungan eine veranderte Anforderung verursach-ten. [BoSt00] argumentieren, dass der Ent-wurf einer angemessenen Architektur, d. h.einer passenden Dekomposition eines Soft-waresystems in funktionale Komponenten,immer einen kreativen, nicht-formalisier-baren Kern enthalt. Liegen keine konkre-ten zukunftigen Anforderungen vor, somuss sich der Architekt auf die Abstrak-tion seiner Erfahrung aus vergangenenProjekten und seine Intuition verlassen.Beides ist kein Garant fur ein mit wenigAufwand an neue Anforderungen anpass-bares Softwaresystem.

Sind zukunftige Veranderungen und Evo-lutionspfade des Systems jedoch abzusehen,so tritt die Frage nach einer angemessen fle-xiblen Architektur in den Vordergrund.Als Grundlage fur die Architektur werdenTechnologien benotigt, die es erlauben, einSystem so zu implementieren, dass es wenn die Zeit gekommen ist mit gerin-gem Aufwand an die (bekannten) zukunfti-gen Anforderungen angepasst werdenkann.

Die spater in diesem Beitrag vorgestellteFallstudie handelt von einem Portalsys-tem, das zuerst rein auf der Basis objekt-orientierter Technologie (in der Program-miersprache JAVA) implementiert wurde.Als das Projekt immer mehr Personenund externe Firmen umfasste, wurden aufder Basis von Web-Service-Technologieneinfache Schnittstellen zwischen wichtigenSystemkomponenten geschaffen. DieserTechnologie-Shift sicherte die weitereEvolvierbarkeit des Systems mit den rapidewachsenden und sich andernden Anforde-rungen des Konzerns. Bevor die Fallstudievorgestellt wird, werden im Folgenden diebeiden grundlegenden Technologien ob-jektorientierte Programmiersprachen undKomponententechnologie kurz im Hin-blick auf die Evolvierbarkeit der mit ihrerHilfe implementierten Systemen vergli-chen. Zudem wird die zentrale Aussagedieses Beitrags formuliert, die dann durchdie Fallstudie unterstutzt wird.

2.1 Evolvierbarkeitvon objektorientiertenSoftwaresystemen

Objektorientierte Sprachen unterstutzendie Evolvierbarkeit von Softwaresystemen,indem sie Konzepte bereitstellen, mit de-


Internet

HTML / HTTPHTML / HTTP

Manuelle bertragung

Internet SOAP (XML / HTTP)

Ohne Web-Services

Mit Web-Services

Produktionssystemdes Kunden

Bestellsystem desZulieferers

Bestellsystem desZulieferers

Produktionssystemdes Kunden

Bild 1 Einsatz von Web-Services

436 Oliver Stiemerling

nen ein hohes Ma an Sharing (gemein-same Nutzung von Code) zwischen der al-ten und einer neuen Version der Softwareerreicht werden kann. Der Entwicklermuss lediglich Code fur die neuen bzw. ge-anderten Funktionalitaten erstellen. Exis-tierende Funktionalitat kann sein Codeeinfach von einer alten Klasse erben oderdurch Aufruf einer Methode einer altenKlasse nutzen (im Sinne von Forwardingoder sogar Delegation, siehe [Knie00]).Objektorientierte Technologien eignen sichgut dazu, Evolvierbarkeit bei kleinerenSoftwaresystemen, die von Einzelpersonenoder in kleinen Teams entwickelt werden,zu erreichen. Bei groeren Systemen undProjekten zeigt sich jedoch, dass aufgrundder groen Anzahl von Klassen, Ablei-tungsstrukturen und Aufrufmodalitatender Aufwand fur Anpassungen stark an-steigt. Die Komplexitat des Gesamtsystemskann die Grenzen der kognitiven Fahigkei-ten des Menschen erreichen (siehe[Nard93]). So hat ein neu mit dem Systemkonfrontierter Programmierer auchwenn die Architektur nderungen tech-nisch einfach zulassen wurde zur effi-zienten Nutzung der alten Funktionalitateinen hohen Einarbeitungs- bzw. Lernauf-wand. Zudem neigen Entwickler dazu, inAnlehnung an weit verbreitete APIs wiedie Windows-API oder die diversen Java-APIs ihre eigenen Systeme in Form vonmoglichst generischen Frameworks zu im-plementieren. Die dazu notwendige Abs-traktion von konkreten Anforderungenmacht die Schnittstellen solcher Systemeoft wesentlich komplexer, als sie fur die inabsehbarer Zukunft real anfallenden An-forderungen sein mussten.

Ein weiteres Problem bei manchen (nichtallen) objektorientierten Sprachen ist, dassAnwendungen, die auf der Basis eines Fra-meworks entwickelt wurden, bei jeder n-derung des Frameworks neu ubersetzt undausgeliefert werden mussen auch wenndie Framework-nderungen nicht einmaldie von der Anwendung verwendetenSchnittstellen betreffen.

2.2 Evolvierbarkeitvon komponentenorientiertenSoftwaresystemen

Komponentenorientierte Systeme gewin-nen ihre Evolvierbarkeit aus der zentralenEigenschaft von Komponenten, nur uberklar definierte Schnittstellen von anderen

Teilen des Systems abhangig zu sein (fureinen ausfuhrlichen berblick uber Kom-ponententechnologien siehe [Szyp97]). So-lange die Schnittstellen unverandert blei-ben, kann eine Komponente erheblichenAnpassungen unterworfen werden, ohnedass die anderen Komponenten des Sys-tems betroffen sind. Anpassungen konnenauch durch Rekomposition oder Erweite-rung des Systems um neue Komponentenerreicht werden. [Stie00] diskutiert die viel-faltigen Moglichkeiten der komponenten-basierten Anpassbarkeit und beschreibt eineKomponentenplattform, die Veranderun-gen der Komposition eines Systems zurLaufzeit erlaubt. Bild 2 stellt drei Arten derEvolvierbarkeit eines aus Komponentenbestehenden Softwaresystems dar.

Ausgehend von einem beispielhaft aus dreiKomponenten zusammengesetzten System(Ausgangsbasis, oben links) besteht dieMoglichkeit, die im System vorhandenenKomponenten anders zu verbinden (Re-konfiguration), Komponenten durch neueVersionen zu ersetzen (Substitution)oder das Gesamtsystem um neue Kom-ponenten zu erganzen (Erweiterung).Die spater in diesem Beitrag diskutierteFallstudie zieht Vorteile aus allen drei Ar-ten der Evolvierbarkeit.

Die Darstellung in Bild 2 abstrahiert vondrei wesentlichen Details der Komponen-tentechnologie:

& den verfugbaren Interaktionsmechanis-men,

& der Implementierung der Kompositionim laufenden System und

& der Betrachtung der Ausfuhrungsplatt-form.

Diese Faktoren spielen jedoch fur die Ei-genschaften des implementierten Systemseine groe Rolle, weshalb im Folgendenkurz auf ihre Bedeutung eingegangen wird.

2.2.1 Faktor 1: VerfugbareInteraktionsmechanismen

Um im Verbund zu funktionieren, mussenKomponenten offensichtlich interagieren und zwar in einer Art und Weise, die durchauere Anforderungen vorgegeben ist.Durch diese Anforderungen kann be-stimmt sein, welche Komponenteninstanzeine Interaktion beginnt, ob eine Antwortder anderen Komponenteninstanz erwartetwird und wie bzw. ob sich der Kontroll-fluss des ausfuhrenden Prozessors zwi-schen den Komponenteninstanzen bewegt.

Je nach Komponentenmodell werden un-terschiedliche Interaktionsmechanismenzur Verfugung gestellt. Beispielsweise er-laubt das JAVABEANS-Komponentenmodell(siehe [Java97]) eine Interaktion uber soge-nannte Events. Events werden von einerKomponente (der Event-Quelle) ausgelostund erlauben die bertragung von Kon-


Kernpunkte fur das Management

Am Beispiel des Portalsystems eines Grokonzerns wird gezeigt, wie eineWeb-Service-Ar-chitektur es einem komplexen Softwaresystem erlaubt, flexibel mit den dynamischen Anfor-derungen eines Unternehmens zu evolvieren.

& Evolvierbarkeit ist eine fur den langfristigen Erfolg eines industriellen Softwaresystems ent-scheidende Eigenschaft. Wird diese Eigenschaft bei der Entwicklung des Systems nichtberucksichtigt, verursachen spatere Anpassungen hohe Aufwande oder sind sogar un-moglich.

& Web-Services reduzieren aufgrund der erreichbaren klaren Trennung von Systemkom-ponenten auf konzeptioneller, technischer und organisatorischer Ebene die spateren Auf-wande bei der Anpassung eines Systems an neue Anforderungen, bzw. machen diesenderungen uberhaupt erst implementierbar.

& Der Einsatz von Web-Services als Basis fur evolvierbare Software sollte aufgrund von Per-formanzverminderung und Entwicklungsaufwanden auf Systemkomponenten beschranktwerden, fur die zukunftige Veranderungen absehbar sind.

Stichworte: XML, Web-Service, Evolvierbarkeit, Anpassbarkeit, Software, Architektur, Kom-ponenten, Dekomposition

Web-Services als Basis fur evolvierbare Softwaresysteme 437

trollfluss und Information in eine odermehrere andere Komponenten (die Event-Senken). Eine Antwort auf ein Event wirdnicht erwartet. Eine solche Event-gesteuer-te Interaktion eignet sich insbesondere furinteraktive Anwendungen, die primar aufEreignisse (wie z. B. das Betatigen einerSchaltflache) an der Benutzeroberflachereagieren.

Andere Interaktionsmechanismen sind Me-thodenaufrufe (wie in objektorientiertenProgrammiersprachen) oder Blackboards(zwei Komponenten lesen und schreiben ineinen gemeinsamen Speicherbereich). KeinKomponentenmodell stellt alle Inter-aktionsmechanismen zur Verfugung. In[Stie00] wird jedoch gezeigt, dass man ei-nen Interaktionsmechanismus oft durch ei-ne Kombination von anderen Mechanis-men implementieren kann. Beispielsweisekann ein Methodenaufruf durch das Hin-und Herschicken von zwei Events simu-liert werden. Auf der anderen Seite werdendie Events im JAVABEANS-Komponenten-modell durch vereinfachte Methodenaufru-fe ohne Ruckgabewert implementiert.

Trotzdem sind die zur Verfugung stehen-den Interaktionsmechanismen ein zentralerFaktor, der bei der Auswahl eines Kom-ponentenmodells fur ein evolvierbares

Softwaresystem in Betracht gezogen wer-den sollte. Insbesondere ist im Hinblickauf die Interoperabilitat von organisations-ubergreifend entwickelten Systemen aufdie Moglichkeit der klaren Beschreibungder Interaktionsschnittstellen zu achten.

2.2.2 Faktor 2: Implementierungder Kompositionim laufenden System

Ein weiterer relevanter Punkt ist die Imple-mentierung der Verbindung der Kom-ponenten. Man betrachtet im Kontext eineslaufenden Systems nicht mehr Komponen-ten, sondern Komponenteninstanzen. EineKomponente (z. B. eine Schaltflache) kannzur Laufzeit durchaus mehrfach auftreten,sodass die Unterscheidung zwischen even-tuell unterschiedlich parametrisierten In-stanzen einer Komponente wichtig ist. Bei-spielsweise kann eine Schaltflache einmalmit OK und einmal mit Abbrechenbeschriftet und jeweils mit der entspre-chenden Funktionalitat verbunden sein.

Sind die Verbindungen von Komponentenhart codiert, so muss fur jede Veranderungder Komposition wie in Bild 2 dar-gestellt das System neu ubersetzt und ge-startet werden. Werden die Verbindungender Komponenten jedoch zur Laufzeit des

Systems aus einer Konfigurationsdatei ge-laden, so besteht die Moglichkeit, das Sys-tem anzupassen, ohne den Betrieb unter-brechen zu mussen.

Fur die Evolvierbarkeit komponentenba-sierter Anwendungen ist die Art der Dar-stellung der Komposition folglich ein wei-terer entscheidender Faktor.

2.2.3 Faktor 3: Plattformabhangigkeitoder -unabhangigkeitder Komponente

Insbesondere in firmenubergreifendenProjekten aber auch in Grounternehmenhat man es oft mit heterogenen System-landschaften zu tun. Dadurch kann bei derImplementierung eines Systems die Ver-wendbarkeit von Komponenten auf ver-schiedenen Plattformen (d. h. Betriebs-und Hardwaresystemen) entscheidendeBedeutung haben.

Die Programmiersprache Java erlaubt mitihrem Bytecode-Konzept den Einsatz voneinmal ubersetzten Komponenten auf jederPlattform, die die sogenannte Java VirtualMachine (JVM) zur Verfugung stellt. DieJVM fuhrt den Bytecode auf der jeweiligenPlattform aus und abstrahiert so von loka-len Besonderheiten. Eine in Java entwickel-te Komponente kann folglich auf verschie-denen Plattformen ohne eine erneutebersetzung eingesetzt werden. Die meis-ten anderen Komponentenmodelle z. B.CORBA von der OMG (siehe [OMG95])oder COM von Microsoft (siehe [Micr02]) basieren auf plattformabhangig ubersetz-ten Komponenten, die nicht ohne eineNeuubersetzung auf anderen Plattformeninstalliert werden konnen.

Muss man davon ausgehen, dass ein Sys-tem uber Plattformgrenzen hinweg evol-viert, so ist die Bedeutung der Plattform-unabhangigkeit offensichtlich.

2.3 Web-Services als Basis furevolvierbare Softwaresysteme

Web-Services sind mit dem Ziel der Inter-operabilitat entwickelt worden. Damit er-scheinen sie pradestiniert dafur, als Grund-lage fur komponentenbasierte, evolvierbareSysteme zu dienen. Im Bezug auf die obengenannten Aspekte bietet das Web-Ser-vices-Konzept in jedem Punkt eine Reihevon Implementierungsvarianten an.


S2

S3

S1

Rekonfiguration

S2S1

Substitution

S2S1

S4

Erweiterung

S3

S2S1

Ausgangsbasis

S3

Legende

S2 Komponente

Service-Angebot

Service-Verbraucher

Verbindung zur Laufzeit

S3

Bild 2 Drei Arten der Evolvierbarkeit eines komponentenbasierten Softwaresystems


Web-Services konnen mit unterschiedli-chen Interaktionsmechanismen implemen-tiert werden. Die am weitesten verbreiteteDefinitionssprache WSDL (Web-ServiceDefinition Language, siehe [W3C01b]) er-laubt die Beschreibung von Methodenauf-rufen und einer Event-artigen Interaktion,die keine Antwort auf eine verschickteNachricht erfordert. Die Schnittstellen derKomponenten sind in Bild 2 bereits in An-lehnung an die Benutzung der Web-Ser-vice-Konzepte in der Fallstudie dargestellt:Es gibt Service-Anbieter und Service-Ver-braucher. Ein Service-Angebot eines Web-Services ist dabei eine Sammlung von Me-thoden. Im Bezug auf die oben geforderteMoglichkeit zur klaren Definition der In-teraktionsschnittstellen bietet WSDL einesogar maschinenlesbare Darstellung.

Im laufenden System werden Web-Service-Instanzen als URLs angesprochen. DieseURLs konnen in den aufrufenden Kom-ponenten hart codiert sein, was jedoch we-nig sinnvoll erscheint. Die Kompositionvon Web-Services kann wesentlich flexiblerin Konfigurationsfiles beschrieben werden.Fur die Beschreibung einzelner Schnittstel-len und URLs ist die Web-Service Defini-tion Language (WSDL, siehe oben) geeig-net. Fur die Beschreibung der eigentlichenKomposition gibt es noch keine standar-disierte Sprache, lediglich akademischeVorschlage (z. B. DARWIN beschrieben in[MDEK95] oder CAT beschrieben in[Stie00]). Weniger komplexe Kompositio-nen konnen wie in der spater beschriebe-nen Fallstudie einfach durch Eintrage indie Konfigurationsfiles der aufrufendenKomponenteninstanzen realisiert werden.

Die Adressierung von Web-Service-Schnittstellen uber URLs hat zur Folge,dass lediglich Komponenten einer grobenGranularitat auf diese Weise implementiertwerden konnen. Es erscheint wenig sinn-voll, feine Komponentenstrukturen (z. B.die einzelnen Dialogelemente einer lokalen,interaktiven Benutzerschnittstelle) auf derBasis von Web-Service-Schnittstellen zuimplementieren. Die Starken des Web-Ser-vice-Ansatzes liegen eher im Bereich vongrobgranularen, verteilten Strukturen.

Bezuglich einer plattformabhangigen oder-unabhangigen Implementierung derKomponenten macht das Web-Service-Konzept keinerlei Vorgaben. Es ist einezentrale Eigenschaft des Konzepts, dassWeb-Services und die sie aufrufende Soft-ware in beliebigen Programmiersprachen

auf beliebigen Plattformen implementiertsein konnen.

Diese Betrachtung von Web-Services alsKomponententechnologie fuhrt zur For-mulierung der zentralen Hypothese desBeitrags:

Web-Services eignen sich als Basis fur evol-vierbare Softwaresysteme

Diese Aussage wird im Folgenden empi-risch durch die Analyse der mehr als ein-jahrigen Erfahrungen mit der Evolution ei-nes produktiven Grosystems unterstutzt.Anschlieend werden die beim Einsatz vonWeb-Services entstehenden Aufwande dis-kutiert und einige Hinweise zum sinnvol-len Einsatz von Web-Service-Architektu-ren gegeben.

3 Fallstudie: Die Evolutioneines Portalsystems

Unternehmen streben naturgema danach,ihre Interaktionen mit Kunden und Part-nern so effizient und effektiv wie moglichzu gestalten. Das Internet bietet die Mog-lichkeit, schnell und gunstig auch mit geo-grafisch weit entfernten Personen Infor-mationen auszutauschen und Geschafts-vorfalle abzuwickeln. Das Angebot anGeschaftsprozessen (hier als Fachanwen-dungen bezeichnet) fur bestimmte Grup-pen von Kunden und Partner ist haufig inso genannten Portalen gebundelt, sodassdie Mitglieder der jeweiligen Zielgruppenur einen einzigen Zugang (single login)fur alle ihre Anliegen benotigen. Wie inBild 1 in der Einleitung dargestellt, kann essich bei den Schnittstellen fur die Zielgrup-pen sowohl um Schnittstellen fur Men-schen (HTML/Browser-basiert) als auchfur Maschinen (Web-Services) handeln.Meldet sich ein Mensch am Portal an, siehter oft eine Auswahlseite, die Verweise aufalle ihm zur Verfugung stehenden Fach-anwendungen enthalt.

Fur groe Unternehmen ist es haufig sinn-voll, eine Reihe von Portalen fur spezielleKunden- und Partnergruppen zu unterhal-ten. Dabei kann die Anzahl der in einemPortal angebotenen Fachanwendungen be-trachtlich sein, sodass das gesamte Portal-system mit allen Portalen und Fachanwen-dungen sowohl in der Entwicklung alsauch im Betrieb viele interne Abteilungenund externe Zulieferer umfassen und be-treffen kann.

Hinzu kommt eine betrachtliche Dynamikund auerer Anpassungsdruck: Neue Kun-den- und Partnergruppen mussen durchspezielle Portale unterstutzt werden, Fach-anwendungen sollen gleichzeitig in ver-schiedenen Portalen angeboten werden,neue Geschaftsprozesse sollen im Portalzur Verfugung gestellt werden und existie-rende Fachanwendungen oder Portalemussen an veranderte Bedingungen undAblaufe angepasst werden. Tabelle 1 gibteinen berblick uber die konkret auftre-tenden Dynamiken im Umfeld eines Por-talsystems und die resultierenden tech-nischen Konsequenzen.

Der im Folgenden dargestellte reale Fallder Evolution eines Portalsystems ist fureine Bewertung der Vorteile einer Web-Ser-vice-Architektur besonders interessant undrelevant, da im Verlauf des produktivenEinsatzes ein Technologie-Shift von einerrein objektorientierten Implementierunghin zu einem komponentenorientierten,Web-Service-basierten System durchge-fuhrt wurde. Beide technologischen Vari-anten waren allen in Tabelle 1 aufgefuhrtenDynamiken ausgesetzt, so dass eine diffe-renzierte qualitative Analyse durchgefuhrtwerden kann. Teilweise sind sogar vorsich-tige quantitative Vergleiche zu den Auf-wanden fur gewisse Anpassungen moglich.

Zuerst wird als Ausgangspunkt das ur-sprungliche, rein objektorientierte Systemvorgestellt und in Bezug auf seine Evol-vierbarkeit unter den angegeben Dynami-ken charakterisiert. Dann wird der Tech-nologie-Shift in Form der Erweiterung umeine zentrale Web-Service-Schnittstelle imPortal beschrieben und ebenfalls bezuglichseiner Evolvierbarkeit bewertet. Im ab-schlieenden Vergleich werden beide Tech-nologien gegenubergestellt, wobei die Vor-teile der Web-Service-Architektur imHinblick auf die Evolvierbarkeit des Ge-samtsystems deutlich werden.

3.1 Ausgangspunkt:ein Portalsystem basierendauf OO-Technologien

Zum Zeitpunkt der Entscheidung, ein Por-talsystem fur das betrachtete Unternehmenzu entwickeln, waren objektorientierteTechnologien der aktuelle Stand der Tech-nik. Als Implementierungssprache wurdeJAVA gewahlt, wobei fur Standardfunktio-nalitaten die objektorientierten Frame-



works (OO-Frameworks) eines kommer-ziellen Application-Servers benutzt wur-den. Diese Frameworks stellten unter ande-rem auch die Persistenzmechanismen inForm eines objekt-relationalen Mappingszur Verfugung. UnternehmensspezifischeAnteile wurden ebenfalls als OO-Frame-works in JAVA implementiert. Benutzer-schnittstellen wurden in reinem HTMLrealisiert.

Auf der Basis dieser OO-Frameworks (desPortalsystems) wurden Portale fur spezi-fische Zielgruppen entwickelt. Die Kern-

funktionalitat eines Portals war selbst alseine HTML-basierte Anwendung imple-mentiert, mit der sich ein Benutzer anmel-den und seinen Zugang pflegen konnte.Die Fachanwendungen waren ebenfallsHTML-Anwendungen, die auf den glei-chen OO-Frameworks wie das Portal ba-sierten (Beispiele fur Fachanwendungenaus dem hier betrachteten Projekt sind An-wendungen zur nderungen von Kunden-stammdaten, Vertragsanderungen undelektronische Rechnungsubermittlung). Ei-ne Fachanwendung musste immer zusam-men mit den OO-Frameworks ubersetzt

und installiert werden. Auf der Basis desobjekt-relationalen Mappings kommuni-zierten die einzelnen Fachanwendungenmit der zentralen Portalanwendung indi-rekt uber die eine gemeinsame Datenbank.So konnte eine Fachanwendung beispiels-weise mit einem Aufruf einer Methode imOO-Framework indirekt uber die Daten-bank verifizieren, ob ein Benutzer, der ausdem Internet auf die Fachanwendungenzugriff, sich vorher bereits am Portal ange-meldet hatte (Das wurde anhand der ber-prufung einer Session-ID festgestellt).Bild 3 gibt einen berblick uber die rele-vanten Strukturen des rein objektorientier-ten Portalsystems, wobei von den Persis-tenzmechanismen abstrahiert wird.

Fur den Zweck dieses Beitrags ist es nuninteressant zu sehen, wie das Portalsystemin dieser Technologie die durch die in Ta-belle 1 beschriebenen Dynamiken notwen-digen Anpassungen unterstutzte. Dabeiwird eine einfache qualitative Bewertungvorgenommen: ; bedeutet, dass die An-passung angemessen unterstutzt wurde,,*, dass die Anpassung nur mit hohemAufwand durchgefuhrt werden konnte,und , dass die Anpassung nicht odernicht mit vertretbarem Aufwand durch-gefuhrt werden konnte. Diese Bewertungfut auf der subjektiven Einschatzung desAutors aus Gesprachen mit anderen Pro-jektbeteiligten und wird daher in Tabelle 2weiter begrundet.

Die in Tabelle 2 dargestellte Bewertung un-terstutzt deutlich die vorher uber die Evol-vierbarkeit von objektorientierten Syste-men getroffenen Aussagen. Da gerade dieletzten drei Anforderungen mit dem gro-en Erfolg des Portalsystems immer mehrin den Vordergrund traten, musste die Ar-chitektur des Systems mit dem Ziel derEvolvierbarkeit umgestellt werden. Eswurde eine Reihe von Verbesserungen imRahmen von OO-Technologien diskutiert,beispielsweise

& die Verschmalerung der Schnittstellezwischen Fachanwendung und OO-Framework, um den Einarbeitungsauf-wand und die Abhangigkeiten zu verrin-gern.

& die Ersetzung der Datenbank als runti-me-Schnittstelle durch geeignetere Me-chanismen wie JAVA-RMI (siehe [Java98]),bzw. sogar CORBA (siehe [OMG95]), umTechnologie-unabhangiger zu werden.

Mit diesen Schnittstellen hatten jedoch un-ter hohem Aufwand nur Teilerfolge erzielt


PortalsystemOO-Frameworks

Portal F1 F2 F3 ... benutztFx

Fachanwendungdes Portal

Legende:

Portalsystem ohne Web-Services

Bild 3 Ein Portalsystem basierend auf OO-Technologie

Tabelle 1 Funf Umfelddynamiken und ihre technischen Konsequenzen fur ein Portalsystem

Dynamik des Umfelds Technische Konsequenzen fur das Portalsystem

1.) Eine neue Zielgruppe soll durch eineigenes Portal unterstutzt werden.

Eine neue Portalversion, die die Besonder-heiten der neuen Zielgruppe berucksichtigt,muss vom Portalsystem abgeleitet werden.Beispielsweise muss der Prozess derBeantragung von Zugangen spezifischgestaltet werden.

2.) Existierende Geschaftsprozessewerden angepasst.

Eine Fachanwendung muss angepasst werden.Es entsteht eine neue Version der betreffendenFachanwendung.

3.) Einer bereits durch ein Portalunterstutzten Zielgruppe soll ein neuerGeschaftsprozess zur Verfugunggestellt werden.

Eine neue Fachanwendung muss entwickelt undin das Portal integriert werden.Erschwerend kann hinzukommen:a) Die Fachanwendung soll in einer anderen

Technologie entwickelt werden.b) Die Fachanwendung soll Unternehmens-

extern betrieben werden.

4.) Ein bereits fur eine Zielgruppeangebotener Geschaftsprozess sollauch einer anderen Zielgruppeangeboten werden.

Eine existierende Fachanwendung muss in einweiteres Portal eingebunden werden.

5.) Die Anforderungen einer Zielgruppean ein bestimmtes Portal andern sich,beispielsweise aufgrund vonrechtlichen nderungen.

Das Portal muss angepasst werden. Beispiels-weise ist eine andere Form der Authentifizierungvon Zugangsantragen notwendig.


werden konnen und zudem waren neueAbhangigkeiten und Komplexitaten ent-standen. Da die Eigenschaften der Schnitt-stellen der neuen Architektur (schmal,Technologie-ubergreifend, zur Laufzeit ge-bunden) recht klar auf Web-Service-Tech-nologien hinwiesen, wurde die Entschei-dung getroffen, den Schritt zu wagen unddie neue Architektur auf dieser noch rechtneuen Basis zu entwickeln.

3.2 Umstellung des Portalsystemsauf eine Web-Service-Architektur

Ein Grundsatz beim Design einer Soft-ware-Architektur mit dem Ziel der Evol-

vierbarkeit ist das sogenannte Orthogona-litatsprinzip:

Trenne Dinge, die sich unabhangig von-einander verandern!

Die funf Umfelddynamiken und ihre Be-wertung in Tabelle 2 forderten offensicht-lich eine klare Trennung zwischen demPortal mit seinen Frameworks und denFachanwendungen. Eine Analyse der Ab-hangigkeiten zwischen diesen Komponen-ten zeigte, dass man die Funktion des Por-tals aus der Sicht einer Fachanwendung imWesentlichen auf die Authentifizierung ei-nes Benutzers uber die Session-ID aus sei-ner Anmeldung am Portal reduzierenkonnte. Die Fachanwendung steht bei ih-rem Aufruf durch einen Benutzer vor demProblem, die Gultigkeit einer vom Browser

erhaltenen Session-ID bewerten zu mus-sen. Da die Gultigkeit dieser Session-IDnur dem Portal bekannt ist, muss die Fach-anwendung die Session-ID zwangslaufigdort authentifizieren. Konzeptionell ge-schieht dies in der neuen Architektur ubereinen Methodenaufruf der Fachanwendungbeim Portal:

authenticate(SessionID)

In Realitat bietet die hier vereinfacht dar-gestellte Schnittstelle noch mehr Funktio-nalitaten fur die Fachanwendungen. Furden Zweck dieses Beitrags kann jedoch da-von abstrahiert werden. Die Schnittstellewurde mit einem Web-Service auf der Basisdes Standardprotokolls SOAP uber HTTP(siehe [W3C01a]) realisiert, sodass ein Auf-ruf der obigen Methode sich als bidirektio-


Tabelle 2 Bewertung der Evolvierbarkeit des Portalsystems in OO-Technologie

Technische Konsequenzen fur dasPortalsystem

Umsetzung der veranderten Anforderungen in OO-Technologie

1.) Eine neue Portalversion, die dieBesonderheiten der neuen Zielgruppeberucksichtigt, muss vom Portalsystemabgeleitet werden. Beispielsweise mussder Prozess der Beantragung vonZugangen spezifisch gestaltet werden.

Diese Anforderung konnte die OO-Technologie angemessen unterstutzen. Ein neues Portalkonnte mit weitgehender Wiederbenutzung von Code erstellt werden. Die Entwickler hattennicht den Eindruck, das Rad neu zu erfinden.

Es zeigte sich lediglich, dass Anpassungen nicht nur in der Portalanwendung, sondern immerauch in den OO-Frameworks vorgenommen werden mussten. Diese nderungen in denFrameworks mussten bei der Entwicklung fur die Fachanwendungen des neuen Portalsberucksichtigt werden.

2.) Eine Fachanwendung muss angepasstwerden. Es entsteht eine neue Version derbetreffenden Fachanwendung.

Hier gilt das gleiche wie bei Anpassung 1. Eine Fachanwendung konnte aufgrund derOO-Sprachkonstrukte einfach angepasst und ausgeliefert werden.

3.) Eine neue Fachanwendung mussentwickelt und in das Portal integriertwerden.

* Hier zeigte sich, dass die Entwicklung einer Fachanwendung fur einen mit den unternehmens-spezifischen OO-Frameworks vertrauten Entwickler nicht ubermaig aufwandig war.

Es wurden jedoch auch Fachanwendungen von externen Firmen entwickelt. Die Entwicklerdieser Firmen hatten einen erheblichen Aufwand (geschatzt ca. 20 Personentage) bei derEinarbeitung und Einbindung, da die OO-Frameworks recht generisch gehalten waren undinsbesondere die Schnittstellen, Design Patterns und Datenstrukturen komplex waren.

3.a) zusatzlich muss die neue Fach-anwendung in einer anderen Technologieentwickelt werden.

Unter diesen Umstanden war eine Einbindung der Fachanwendung in das Portal unmoglich,da Fachanwendungen zwingend auf die nur in einer Technologie verfugbaren OO-Frame-works aufbauen mussten. Anwendungen, die z. B. in PL/SQL, PHP, Python etc. geschriebenwaren, konnten nicht mit single login in das Portal eingebunden werden.

3.b) zusatzlich wird die neue Fach-anwendung von einer anderen Firma/in einem anderen Standort betrieben.

Da es fur externe Firmen und netztechnisch unsicher angebundene Standorte des Konzernsverboten war, direkt auf Produktionsdatenbanken zuzugreifen, konnten Fachanwendungennicht von anderen Firmen betrieben werden. Dieser Datenbankzugriff war jedoch, wie obenbeschrieben, fur eine Kopplung notwendig.

4.) Eine existierende Fachanwendung mussin ein weiteres Portal eingebundenwerden.

Diese Anforderung konnte nicht umgesetzt werden, da wie unter Punkt 1 beschrieben dieOO-Frameworks fur jedes Portal angepasst werden mussten. Eine Fachanwendung konnteimmer nur in genau ein Portal eingebunden werden, da sie wie oben dargestellt immernur genau mit einer Version der OO-Frameworks ubersetzt werden konnte.

5.) Das Portal muss angepasst werden.Beispielsweise ist eine andere Form derAuthentifizierung von Zugangsantragennotwendig.

Da Anpassungen des Portals wie unter Punkt 1 beschrieben immer auch die grundlegendenFrameworks betrafen, mussten die Fachanwendungen zumindest neu ubersetzt und installiertwerden. Bei einem Portal mit wenigen ( 3) Fachanwendungen, die in der gleichen Firmaentwickelt werden, war dies noch vertretbar. Im vorliegenden Abteilungs- und firmenuber-greifenden Entwicklungsszenario war dies jedoch nicht mehr tragbar.


naler Austausch von XML-Dokumentenuber das HTTP-Protokoll darstellt. Derover the wire-Request erscheint dabeiwie in Bild 4 (vereinfacht) dargestellt.

Eine positive Antwort mit dem entspre-chenden Antwort-Header des HTTP-Pro-tokolls ist in Bild 5 dargestellt.

Fur den Zweck dieses Beitrag muss nichtnaher auf die technischen Details odermogliche alternative XML-Schemata(z. B. im Kontext von ebXML, siehewww.ebXML.org) eingegangen werden(fur eine genaue Beschreibung von SOAPsei auf [W3C01a] verwiesen). Hier liegt der

Fokus auf den Auswirkungen, die die Ein-fuhrung dieser Schnittstelle auf der archi-tektonischen Ebene hatte. Bild 6 zeigt dieneue Web-Service-Architektur des Portal-systems.

Die URL der Schnittstelle des Portalservice(beispielsweise http://www.portal.com/Webservice) erhalten die Fachanwen-dungsinstanzen uber einen Eintrag in ihrenKonfigurationsdateien zur Laufzeit.

Analog zum objektorientierten Portalsys-tem wird in Tabelle 3 bewertet, wie sich dieWeb-Service-Architektur unter dem Ein-fluss der funf Umfelddynamiken verhalt.

Die in Tabelle 3 aufgefuhrte Bewertung derWeb-Service-Architektur hinsichtlich Evol-vierbarkeit zeigt deutlich, dass die neue Ar-chitektur im Vergleich zur reinen OO-Lo-sung (Tabelle 2) entscheidende qualitativeFlexibilitatsvorteile erzielt. Die Vorteile re-sultieren aus den drei Arten der komponen-tenbasierten Anpassbarkeit (siehe Bild 2):

& Das Portalsystem kann einfach durchneue Komponenten erweitert werden(Integration neuer Fachanwendungen siehe Punkt 3 in Tabelle 3);

& Existierende Komponenten konnendurch neue Versionen substituiert wer-den (z. B. kann ein Portal modifiziertwerden, ohne die Fachanwendungen zuberuhren siehe Punkt 5);

& Das Gesamtsystem kann zur Erfullungweiterer Aufgaben rekonfiguriert wer-den (Einhangen von Fachanwendungenin andere Portale siehe Punkt 4).

Die quantitativ bewertete Verminderungdes Aufwands zur Einbindung auf einZehntel ist hier aufgrund der kleinen sta-tistischen Basis mit Vorsicht zu interpre-tieren. Diese Zahl sollte lediglich als In-diz fur die in groen Projekten durchWeb-Services zu erreichenden Aufwands-reduzierungen gesehen werden. Das zen-trale Ergebnis der Fallstudienanalyse istdie empirische Untermauerung der Hy-pothese: Web-Service-Architekturen eig-nen sich als Basis fur evolvierbare Soft-waresysteme.

Das Portalsystem ist heute zentraler Be-standteil der Aktivitaten des betreffendenUnternehmens. Es zeichnet sich insbeson-dere dadurch aus, dass es den rapidewachsenden und sich verandernden An-forderungen, die sich aus der starkenMarktorientierung des Unternehmens er-geben, schnell und mit geringen Anpas-sungsaufwanden gerecht wird.

Dieses Beispiel fur den erfolgreichen Ein-satz einer Web-Service-Architektur sollden Leser jedoch nicht dazu bewegen, jedeSchnittstelle eines Softwaresystems alsWeb-Service zu gestalten. Die Anwendungdieser Technologie verursacht zusatzlicheAufwande in Entwicklung und Betriebund birgt einige Risiken bezuglich Perfor-manz in sich. Folglich ist eine Web-Ser-vice-Architektur mit Bedacht und unterBerucksichtigung einer Reihe von tech-nischen und organisatorischen Faktoren zuentwerfen. Die folgende Diskussion gehtkritisch auf diese Faktoren ein und gibt ei-nige konkrete Handlungshinweise.


Host: abc.xyz.com:80Content-Type: text/xml; charset=utf-8Content-Length: 307SOAPAction: ""

123456789

POST /PortalWeb-Service HTTP/1.0

Bild 4 Anfrage zur Authentifizierung

HTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: 117

OK

Bild 5 Antwort zur Authentifizierung

Portalsystem mit Web-Services

Portalsystem

OO-Frameworks

Portal

Portal

Web-Service

F1 F2 F3benutzt

FxFachanwendung

des Portal

Legende:

Service-Angebot

Service-Verbraucher


Portalsystem mit Web-Services

Portalsystem

OO-Frameworks

Portal

Portal

Web-Service

F1 F2 F3benutzt

FxFachanwendung

des Portal

Legende:

Service-Angebot

Service-Verbraucher


Bild 6 Ein Portalsystem mit einer Web-Service-Architektur


4 Entwurf und Entwicklungvon Web-Service-Architekturen

Der Aufruf einer Web-Service-Schnittstelleuber das HTTP-Protokoll wie in der obenbeschriebenen Fallstudie verursacht offen-sichtlich mehr Aufwand als der Aufruf ei-ner Methode innerhalb eines einzigen Spei-cherraums. Er involviert zusatzlich zurAusfuhrung der eigentlichen Methoden-funktionalitat noch Netzwerkkommunika-tion, Erzeugen und Parsen von XML-Do-kumenten, das Verpacken der XML-Do-kumente im HTTP-Protokoll undeventuell zusatzlich noch Loadbalancing(falls der Web-Service in mehreren Instan-zen in Betrieb ist). Die Umsetzung dieserSchnittstelle verursacht folglich zusatz-lichen Aufwand in allen Bereichen desSoftwareentwicklungsprozesses.

4.1 Konzeptionund Dokumentation

Die Konzeption einer Web-Service-Archi-tektur ist der Schritt, der primar uber dieerzielbare Flexibilitat entscheidet. Wird dasGesamtssystem an den falschen Stellen inWeb-Service-Komponenten unterteilt, wer-den Anpassungen spater zu aufwandig unddas System kann nach einiger Zeit seineAufgaben nicht mehr erfullen.

Bei der Zerlegung eines Systems in Kom-ponenten spielen nicht nur technische Er-wagungen eine Rolle. Es kann auch ent-scheidend sein, organisatorische oderfachliche Aspekte zu berucksichtigen. Indi-zien fur die Identifizierung von Web-Ser-vice-Komponentenkandidaten im Gesamt-system mit dem Ziel der Evolvierbarkeitgeben die folgenden Fragen:

& Werden Teile des Systems von unter-schiedlichen Arbeitsgruppen, Abteilun-gen oder sogar Fremdfirmen implemen-tiert?

& Unterliegen Teile des Systems unter-schiedlichen fachlichen Dynamiken,bzw. kommen Anforderungen an dasSystem aus unterschiedlichen Bereicheneines Unternehmens?

& Werden Teile des Systems aus histori-schen oder Know-how-Grunden in un-terschiedlichen Technologien implemen-tiert, bzw. sollen in Zukunft Systemteilebasierend auf unterschiedlichen Tech-nologien integriert werden?

& Ist geplant, Teile des Systems an ver-schiedenen Stellen in verschiedenen In-stanzen einzusetzen?

Konnen Systemteile identifiziert werden,fur die einige dieser Fragen auf der Basisvon sicheren bzw. sehr wahrscheinlichen


Tabelle 3 Bewertung der Evolvierbarkeit des Portalsystems in Web-Service-Technologie

Technische Konsequenzen fur dasPortalsystem

Umsetzung der veranderten Anforderungen in Web-Service-Technologie

1.) Eine neue Portalversion, die dieBesonderheiten der neuen Zielgruppeberucksichtigt, muss vom Portalsystemabgeleitet werden. Beispielsweise mussder Prozess der Beantragung vonZugangen spezifisch gestaltet werden.

Diese veranderte Anforderung kann immer noch einfach durch Anwendung derOO-Sprachkonstrukte umgesetzt werden.

Wie vorher mussen Anpassungen nicht nur in der Portalanwendung, sondern immer auch inden OO-Frameworks vorgenommen werden. Im Unterschied zur reinen OO-Technologiemussen diese nderungen in den Frameworks jedoch in diesem Fall nicht bei der Entwicklungfur die Fachanwendungen des neuen Portals berucksichtigt werden. Die Fachanwendungensind immer noch mit der gleichen Schnittstelle konfrontiert.

2.) Eine Fachanwendung muss angepasstwerden. Es entsteht eine neue Version derbetreffenden Fachanwendung.

Durch die Entkopplung von Fachanwendungen und Portalsystem ist die Evolution vonFachanwendungen unabhangig zu sehen. Wie im folgenden Punkt 3 beschrieben, konnenFachanwendungen in beliebiger Technologie implementiert sein, sodass ihre Evolvierbarkeitlediglich von der Eignung dieser Technologien abhangt.

3.) Eine neue Fachanwendung mussentwickelt und in das Portal integriertwerden.

Der Gesamtaufwand zur Einbindung (Einarbeitung in die Web-Service-Schnittstelle undUmsetzung) einer fremdentwickelten Fachanwendung wurde von den Entwicklern aufca. 2 Personentage geschatzt. Dies entspricht eine Verminderung des Aufwands im Vergleichzur reinen OO-Technologie um den Faktor 10.

3.a) zusatzlich muss die neue Fach-anwendung in einer anderen Technologieentwickelt werden.

Gerade an diesem Punkt spielt der Web-Service-Ansatz seine volle Starke aus. Durch diestandardisierte Schnittstelle ist die Einbindung eine Fachanwendung in einer anderenTechnologie kein Problem mehr.

3.b) zusatzlich wird die neue Fach-anwendung von einer anderen Firma/in einem anderen Standort betrieben.

Da der Zugriff auf eine Web-Service-Schnittstelle uber das HTTP-Protokoll erfolgt, konnenauch externe Anwendungen einfach eingebunden werden. Dabei muss allerdings unteranderem HTTP durch HTTPS (mit SSL-Verschlusselung) ersetzt werden, um eine sicherebertragung zu gewahrleisten. (Eine detailliertere Betrachtung der Sicherheitsmechanismengeht uber den Fokus dieses Beitrags hinaus.)

4.) Eine existierende Fachanwendung mussin ein weiteres Portal eingebundenwerden.

Da alle Portale im Portalsystem den gleichen Web-Service zur Verfugung stellen (wenn auchauf der Basis von recht unterschiedlichen Versionen der OO-Frameworks), kann eineFachanwendung ohne groen Aufwand in zwei Portalen auftauchen.

5.) Das Portal muss angepasst werden.Beispielsweise ist eine andere Form derAuthentifizierung von Zugangsantragennotwendig.

Das Portal kann beliebig geandert werden, ohne dass die Fachanwendungen mitangepasstwerden mussen. Da es sich bei Web-Services um Laufzeitschnittstellen handelt, konnen Teiledes Gesamtsystems sogar zur Laufzeit ausgewechselt werden.


zukunftigen Anforderungen positiv beant-wortet werden, besitzt man die Grundlagefur eine Dekompositionsentscheidung.

Sind die Web-Service-Komponenten desSystems identifiziert, besteht der nachsteSchritt in der Gestaltung der Schnittstellen-Signatur, d. h. der Festlegung von Metho-den, Parametern und Ruckgabewerten.Hier muss das Ziel sein, eine moglichst ein-fache Schnittstelle zu definieren. Jede zu-satzliche Abstraktion oder auf spekulativerBasis eingefugte Verallgemeinerung ver-kompliziert die Schnittstelle und treibt soden Aufwand fur die folgenden Schritte indie Hohe. Die Schnittstelle sollte so gestal-tet werden, dass sie die sicher absehbarenzukunftigen Anforderungen auf die ein-fachst mogliche Weise abdeckt.

Die Schnittstellen-Signatur wird alsWSDL-Datei (siehe [W3C01b]) dokumen-tiert. Fur die Beschreibung der Service-Se-mantik gibt es keinen etablierten Standard.Es ist jedoch zumeist kein Problem, eineklar definierte Schnittstelle auch in ihrerFunktionalitat in einem Dokument zu be-schreiben. Zusatzlich sollten die nichtfunk-tionalen Anforderungen an die Schnitt-stelle, insbesondere die Performanz,dokumentiert werden.

4.2 Entwicklung und Betrieb

Es existiert eine Reihe von Werkzeugenund Frameworks, die die Implementierungund den Betrieb von Web-Service-Schnitt-stellen erleichtern. Beispiele sind:

& WSTK (Web Service Toolkit, siehe auchwww.alphaworks.ibm.com/tech/Webservicestoolkit) von IBM.

& WSDP (Web Services Developer Pack,siehe auch www.javasoft.com) von SUN

& .NET (siehe auch www.microsoft.com/net) von MICROSOFT

& APACHE SOAP (siehe auchxml.apache.org/soap) von der APACHEFOUNDATION

Diese Werkzeuge und Frameworks erlau-ben dem Entwickler, sich auf die reineFunktionalitat des Web-Services zu kon-zentrieren. Die gesamte bersetzung inXML und die Implementierung der Netz-werkkommunikation erfolgt automatisiert.Sogar die WSDL-Datei zur Dokumenta-tion der Schnittstelle kann auf der Basisexistierender Funktionalitat automatischerzeugt werden. Die Auswahl einer Ent-wicklungsplattform hangt vom Know-how

der verfugbaren Entwickler und insbeson-dere auch von den Moglichkeiten des Be-treibers ab. Kann dieser z. B. keine JavaServlets betreiben, wurde eine Entwicklungvon Web-Services mit APACHE SOAP ei-nen enormen Neuaufwand im Betrieb be-deuten, da die Apache-Engine Web-Ser-vices als Servlets publiziert.

Ein moglicher Nachteil einer automatischgenerierten Schnittstelle ist die Perfor-manz. Insbesondere zum Erzeugen undParsen von XML-Dokumenten werden ge-nerische Bibliotheken benutzt, die zwarmit jedem korrekten XML-Dokument zu-rechtkommen, dafur aber teilweise rechtlange brauchen.

Wenn Performanz ein kritischer Faktor furden Systemerfolg ist, kann ein eigenesXML-Handling ein guter Weg sein, dasSystem zu optimieren. Zur Unterstutzungdieses Weges gibt es schon Ansatze, dieEntwicklung einer eigenen, spezialisiertenXML-Verarbeitung zu automatisieren. DieJAVA Architecture for XML Binding(JAXB) erzeugt auf der Basis von XML-Schemata bzw. DTD-BeschreibungenXML-Parser, die aufgrund ihrer Speziali-sierung einem generischen Parser bei derGeschwindigkeit uberlegen sind.

4.3 Test von Web-Services

Der Test einer Web-Service-Schnittstellefolgt geradlinig der Konzeption und Do-kumentation. Fur jede verlangte Eigen-schaft mussen Tests aufgesetzt werden. Diefolgenden Fragen geben die grobe Rich-tung vor:

& Ist die Implementierung konform zurspezifizierten Signatur (wie in derWSDL-Datei dokumentiert)?

& Ist die Implementierung konform zurspezifizierten Semantik?

& Werden die Performanzanforderungenauch unter Last erfullt?

Im Gegensatz zu HTML-Schnittstellen, diedirekt von Menschen getestet werden kon-nen, erfordert der Test vonWeb-Services ei-nen gewissen Programmieraufwand. Mit-hilfe der oben beschriebenen Werkzeugekonnen jedoch anhand der WSDL-Doku-mentation schnell Clients erzeugt werden.

Obwohl Web-Services gerade mit dem Ge-danken der Interoperabilitat entwickeltwurden, sind leider dennoch Tests erfor-derlich, falls man mit einem generierten

Client des einen Lagers (z. B. ApacheSOAP) auf einen generierten Web-Serviceeines anderen Lagers (z. B. MICROSOFT.NET) zugreifen will.

5 Bewertung und Ausblick

Die in diesem Beitrag dargestellte Fallstu-die unterstutzt die Behauptung, dass Web-Service-Architekturen ein geeignetes Kon-zept sind, um groe, firmenubergreifendentwickelte Softwaresysteme im Hinblickauf antizipierbare zukunftige Anforderun-gen evolvierbar zu gestalten. Aufgrund deshoheren Aufwands in Entwicklung undBetrieb sollten Web-Services jedoch mitBedacht eingesetzt werden.

Wahrend dieser Beitrag auf einer einzigen,wenn auch umfangreichen Fallstudie be-ruht, so zeigt die qualitative Analyse derArchitektur unter dem Einfluss der funfunterschiedlichen Umfelddynamiken je-doch eindeutig die Effektivitat der Web-Service-Architektur im Hinblick auf Evol-vierbarkeit. Dabei verdeutlichte dieBetrachtung von Web-Services als Kom-ponententechnologie die fundamentalenGrunde fur diese Effektivitat vor dem Hin-tergrund des Konzepts der komponenten-basierten Anpassbarkeit von Softwaresys-temen. Man kann davon ausgehen, dass diequalitativen Aussagen dieses Beitragsdurchaus auf andere Softwaresystemeubertragbar sind.

Der fast zwingend nachste Schritt in derBetrachtung des Werts von Web-Servicesfur die Evolvierbarkeit von Softwaresyste-men ist die Erarbeitung von quantitativenAussagen. Interessant erscheint die Kos-ten/Nutzen-Relation der Entwicklung vonevolvierbaren Systemen. Ein quantitativesModell sollte dabei nicht nur die Investi-tion in Evolvierbarkeit mit den zukunfti-gen Kostenersparnissen durch geringereAnpassungsaufwande in Relation setzten,sondern insbesondere auch den Wert derTatsache in Betracht ziehen, dass ein Sys-tem uberhaupt evolvierbar bzw. schnellerevolvierbar ist als das System des Wett-bewerbers.

Danksagung

Dank gebuhrt allen Projektbeteiligten furdie vielen fruchtbaren Diskussionen und



den anonymen Gutachtern fur die sehr de-taillierten und konstruktiven Anmerkun-gen.

Literatur

[BoSt00] Bohning, Christian; Stiemerling, Oliver:Designing and Implementing a Component-Based Electronic Meeting System. In: Slagter,R. J.; ter Hofte, G. H.; Stiemerling, O. (Hrsg.):Proceedings of CBG2000, the CSCW2000Work-shop on Component-Based Groupware. Phila-delphia, USA. Telematica Instituut, The Nether-lands. December 2000.

[Java97] JavaSoft: JavaBeans 1.0 API Specification.1.00 ed. Mountain View, California: SUNMicro-systems 1997.

[Java98] JavaSoft: Java RMI 1.0 API Specification.1.00 ed. Mountain View, California: SUNMicro-systems 1998.

[Knie00] Kniesel, Gunther: Dynamic Object-BasedInheritance with Subtyping. Ph.D. Thesis, Uni-versity of Bonn, July 2000.

[MDEK95] Magee, J.; Dulay, N.; Eisenbach, S.;Kramer, J.: Specifying Distributed Software Ar-chitectures. In: Proceedings of 5th EuropeanSoftware Engineering Conference, Barcelona,LNCS 989 (Springer-Verlag), 1995, pp. 137153.

[Micr01]Microsoft: About COM.http://www.microsoft.com/com,Abruf am 2002-03-20.

[Nard93] Nardi, Bonni. A.: A Small Matter of Pro-gramming Perspectives on End User Program-ming. Cambridge, Massachusetts: The MITPress 1993.

[OMG95] OMG: The Common Object RequestBroker: Architecture and Specification. 2.0 ed:Object Management Group, 1995.

[Parn72] Parnas, D. L.:On the Criteria To Be Usedin Decomposing Systems into Modules. In:Communications of the ACM 15 (1972) 12,S. 10531058.

[Stie00] Stiemerling, Oliver: Component-BasedTailorability. Ph.D. Thesis, Universitat Bonn,Bonn 2000. (http://www.ecambria-systems.com/publications/dissertation.pdf).

[Szyp97] Szyperski, C.: Component Software Be-yond Object-Oriented Programming. Reading,Massachusetts: Addison-Wesley 1998.

[W3C00]W3C (World Wide Web Consortium): Re-commendation: Extensible Markup Language(XML) 1.0 (Second Edition). http://www.w3.org/TR/2000/REC-xml-20001006, 2000-10-06.

[W3C01a] W3C (World Wide Web Consortium):Working Draft: SOAP 1.2 Part 1: MessagingFramework. http://www.w3.org/TR/2001/WD-soap12-part1-20011217, 2001-10-02.

[W3C01b] W3C (World Wide Web Consortium):Note: Web Services Description Language(WSDL) 1.1. http://www.w3.org/TR/2001/NOTE-wsdl-20010315, 2001-03-15.


Abstract

Web-services as basis for evolvable software systems

Web-service-technologies are often regarded as the dominant way of software developmentin the future, especially for inter-company scenarios. While the current discussion in thisarea focuses mainly on the integration of software, this paper takes the next step and looksat the evolvability of the system resulting from the integration. A systems adaptability in theface of changing requirements is usually the decisive success factor in industrial environ-ments.This paper analyses experiences with a large, web-service-based application already in in-dustrial use. As principal result we show that such a web-service-architecture indeed has thepotential to support the evolvability of a complex software system. The clear separation ofsystem components achieved by web-services not only on a conceptual, but also on atechnological and organizational level is especially beneficial for large, long-term soft-ware projects that span company boundaries.The decision for a web-service-architecture requires additional efforts in the design, devel-opment and deployment of the software. With these additional efforts in mind, the conclud-ing discussion offers some guidelines for web-service-projects, especially concerning thesensible (and economical) decomposition of the system into components connected by web-services.This contribution draws on experiences from a portal project for a large German company.The project employed around 50 persons including all sub- and partner-projects. For rea-sons of confidentiality the name of the company and project details are omitted, albeit with-out hurting the main points of the paper.

Keywords: XML, web-service, evolvability, adaptability, tailorability, software, architecture,components, decomposition


Web-Services als Basis für evolvierbare Softwaresysteme; Web-services as basis for evolvable...

Documents

Transcript of Web-Services als Basis für evolvierbare Softwaresysteme; Web-services as basis for evolvable...