Composite Applications...serviceorientierte Anwendungsentwicklung (SODA) 105 3.3 Berücksichtigung...

Composite Applications erfolgreich entwickeln

Christoph Mathas

Christoph MathasComposite Applications erfolgreich entwickelnISBN: 978-3-86802-227-8

© 2010 entwickler.pressEin Imprint der Software & Support Media GmbH

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Ihr Kontakt zum Verlag und Lektorat:Software & Support Media GmbHentwickler.press Geleitsstr. 1460599 Frankfurt am MainTel.: +49 (0)69 630089 0Fax: +49 (0)69 930089 [email protected]://www.entwickler-press.de

Projektleitung: Sebastian BurkartKorrektorat: Rüdiger GlaumSatz: Pobporn FischerBelichtung, Druck & Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn

Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Foto-kopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder anderen Ver-fahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht über-nommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

I5Composite Applications erfolgreich entwickeln

Inhaltsverzeichnis

Vorwort 11

1 Einleitung 13

1.1 Für wen ist dieses Buch gedacht? 15

1.2 Weshalb dieses Buch? 16

1.3 Kapitelstruktur 17

1.4 Anmerkungen 19

1.5 Literaturverweise 19

2 Grundlagen 21

2.1 Treiber der Technologieentwicklung 21

2.1.1 Composite Applications – ein kurzer Blick zurück 24

2.2 Architekturbeschreibung nach IEEE 1471-2000 27

2.2.1 Schichtenkonzept (Layering) 31

2.2.2 Technologiearchitektur und -infrastruktur 36

2.3 Frameworks 37

2.3.1 Frameworks für das Design (Design Patterns und Designstandards) 37

2.3.2 Frameworks für die Entwicklung (Implementierungs frameworks, Applikationsframeworks) 39

2.3.3 Container 40

2.4 Domänen (Fachdomänen) 41

2.4.1 Domain Engineering und generative Programmierung 44

2.5 Anforderungen an Softwaresysteme: Requirement Engineering 47

2.5.1 Nichtfunktionale Systemeigenschaften (technisch) 51

2.5.2 Änderbarkeit (Modifiability) 55

2.6 Allgemeine Leitsätze des Software Engineerings 56

2.7 Industriestandards und Standardisierungsgremien 58


Inhaltsverzeichnis

6

3 Composite Applications – Einordnung und Charakterisierung 65

3.1 Composite Applications basieren auf Frameworks 65

3.1.1 Übergreifende Designframeworks der Composite Applications 69

3.1.2 Composite Applications als „Trichtertechnologie“ 75

3.1.3 Composite Applications und BPM 76

3.1.4 Entwicklungsframeworks bzw. Entwicklungsumgebungen 77

3.1.5 Applikationsframeworks 80

3.2 Systemtechnische Einordnung der Composite Applications 83

3.2.1 Häufige Begrifflichkeiten und ihre technische Einordnung 85

3.2.2 Composite Applications aus dem Blickwinkel der Software- und Systemintegration 88

3.2.3 Ausschöpfen von Automatisierungspotenzialen 93

3.2.4 Laufzeit- und Ausführungsumgebungen (Runtimes, Execution Environments) 97

3.2.5 Services oder Komponenten? 101

3.2.6 Domänengetriebene Entwicklung (DDD) und serviceorientierte Anwendungsentwicklung (SODA) 105

3.3 Berücksichtigung von Kontextinformationen 107

3.3.1 Erweiterung des Begriffs der losen Kopplung 112

3.3.2 Datenzugriff, kanonisches Datenmodell 115

3.3.3 Applikationslebenszyklus (Application Lifecycle), Verwaltung mittels zentraler Ablagen (Repositories) 116

3.4 Einhaltung wichtiger systemtechnischer Grundprinzipien 121

3.5 Mögliche Einsatzszenarien 124

3.5.1 Enterprise-Scale Composite Applications 127

3.6 Vorgehensmodelle und Entwicklungsmethodik 131

3.6.1 Entwicklungsprozessrahmen für Composite Applications 133

3.6.2 Projektmanagement und agile Entwicklungsmethodik: Scrum 135

3.6.3 Agile Entwicklungsmethodik: Extreme Programmierung (Extreme Programming, XP) 136

3.6.4 Agile Entwicklungsmethodik: Testgetriebene Entwicklung (Test-driven Development, TDD) 137

3.6.5 Rollenmodell für die Entwicklung von Composite Applications (Beispiel) 139

3.7 Was ist (wirklich) neu an Composite Applications? 145

3.7.1 Modellierung strukturierter Ausführungslogik/(Geschäfts-) Prozesse 147

7Composite Applications erfolgreich entwickeln

Inhaltsverzeichnis

3.7.2 Harmonisierung von Frameworks und Programmiermodellen 149


4 Horizontale Software- und Systemintegration 153

4.1 Zur Motivation 153

4.2 Systemverteilung 154

4.2.1 Lose Kopplung und horizontale Systemintegration 157

4.2.2 Asynchrone Kommunikation 160

4.3 Systemarchitektur der Composite Applications 162

4.4 Kommunikations- und Vermittlungstechnik 165

4.4.1 QoS-Merkmale 167

4.4.2 Enterprise Service Bus (ESB) 168

4.4.3 Endpunkte (URI, IRI, URL), Protokoll-Binding 169

4.5 Serviceorientierte Architektur (SOA) 170

4.5.1 BPM und SOA 172

4.5.2 Servicekategorisierung 173

4.5.3 Servicecontainer 174

4.6 Virtualisierung 175

4.6.1 Formen der Virtualisierung 176

4.7 Cloud Computing 179

4.7.1 Multi-Mandantenfähigkeit (Multitenancy) 182

4.7.2 Software as a Service (SaaS) 183


5 Prozessintegration 187

5.1 Motivation 187

5.2 Prozessabstraktion und -modellierung 189

5.2.1 Ausführbare Workflowbeschreibungen (WS-BPEL, XPDL), Zustandsautomaten 192

5.2.2 BPMN (2.0) 195

5.2.3 Workflows (Prozessserialisierungen) 197

5.2.4 Workflowlebenszyklus 197

5.2.5 WfMS-Referenzmodell der WfMC 199

5.2.6 Workflow-Engines 201

5.3 Regeln und Regelmaschinen (Rules Engines) 203

Inhaltsverzeichnis

8

5.4 Event-driven Architecture (EDA) 207

5.4.1 Abgrenzung zur traditionellen Prozesssteuerung 207

5.4.2 Complex Event Processing (CEP) 208

5.4.3 Auswirkungen auf die Systemarchitektur 208

5.5 Dynamische Workflows/Choreografie 209


6 Anwenderinteraktion (GUI) 215

6.1 Zur Motivation 215

6.2 GUI und lose Kopplung 217

6.2.1 Pageflows und Workflows 220

6.2.2 Webformulare (Web Forms), (X)HTML, XForms 221

6.3 Rich Internet Applications (RIAs) 223

6.4 Portale 224

6.4.1 Portlets (JSR 168, JSR 268) 226

6.4.2 Remote Portlets (WSRP 2.0) 227

6.5 Mashups 228

6.5.1 Einbindung fremder Informationsquellen (Komponenten/Services, Fremdsysteme) 230


7 Vertikale Software- und Systemintegration 233

7.1 Sicherheit (Security) 233

7.1.1 Sicherheitsanforderungen 233

7.1.2 Funktionale Umsetzung der Sicherheitsanforderungen 234

7.1.3 Sicherheitsmechanismen für Composite Applications 237

7.1.4 Pragmatische Sicherheitsauslegung 240

7.1.5 Sichere Authentifizierung am Beispiel von WS-Trust 243

7.2 Konfigurationsmanagement (KM) 246

7.2.1 ALM, CLM, Versionierungskonzept 247

7.2.2 Paketierung, Deployment 248

7.3 Qualitätsmanagement (QM) 252

7.4 Release-Management 253

7.5 Systemmonitoring (BAM) 255

7.6 Fehlerdiagnose und Laufzeitverhalten 257

7.6.1 Verfahren zur Qualitätssicherung und -steigerung während der Entwicklung 257


Inhaltsverzeichnis

7.6.2 Logging und Tracing 259

7.6.3 Process Monitoring, Process Mining 261

7.7 Technische Analysemittel 263

7.7.1 (Remote) Debugging 264

7.7.2 Runtime Profiling 265

7.7.3 Frameworkbezogenes Logging, DB-bezogene Analyse 265

7.8 (IT-) Governance 267

7.8.1 Policies 269

7.8.2 Literaturverweise 270

8 Technologiebeispiel SCA & SDO 273

8.1 Service Component Architecture (SCA) 274

8.1.1 SCA-Spezifikationen 275

8.1.2 SCA Assembly Model 277

8.1.3 Implementierungsbeispiel 280

8.2 Service Data Objects (SDO) 285

8.2.1 Implementierungsbeispiel 289


9 Zusammenfassung und Ausblick 295

9.1 Was bringt die Zukunft? 296

Stichwortverzeichnis 299

V11Composite Applications erfolgreich entwickeln

Vorwort

Integrationsthemen sind in der praktischen Software- und Systementwicklung omniprä-sent. Die Vorteile untereinander vernetzter Rechner wurden spätestens Ende der 1970er Jahre von SUN Microsystems erkannt, nachdem es zuvor in den USA mit ARPANET die ersten Gehversuche auf diesem Gebiet gegeben hatte. SUN brachte Workstations heraus, die untereinander kommunizieren konnten, und bewarb sie mit dem Werbespruch „The network is the computer“. Eine echte Alternative zu den monolithischen Großrechnern stand zur Verfügung.

Dieses Motto nahm SUN zum Ende der 1990er Jahre, im frühen Java-Zeitalter, in einer Werbekampagne wieder auf. Die Betonung lag jetzt auf der Betriebssystem-Unabhängig-keit bzw. Portabilität der Java Virtual Machine (JVM), die wiederum zur verteilten Kompo-nentenkommunikation, z.B. mittels EJBs, eingesetzt werden kann.

Einige Innovations- und Produktzyklen später – nach Web Services, SOA oder ESB – ist die Anwendung der Komponenten- und Servicetechnologien im Projektalltag selbstver-ständlich geworden. Integrationsaufgaben lassen sich heute einfacher bewältigen als noch vor einigen Jahren.

Derzeit rücken die verschiedenen Formen der Virtualisierung in der Anwendungsent-wicklung verstärkt ins Blickfeld. So verspricht das Cloud Computing, die Rechenleis-tung von Rechenzentren mit solchen lokalen, innerhalb eines Unternehmens betriebenen Servern zu kombinieren. Dabei macht man sich zu Nutze, dass leistungsfähige Hard-ware-Ressourcen mittlerweile zulassen, schlichtweg „alles“ zu virtualisieren, darunter Middleware-Bausteine, Laufzeitcontainer, prozessorientierte Anwendungssysteme oder Serverbetriebssysteme.

Unter diesen Voraussetzungen stellen Composite Applications den zeitgemäßen Ansatz zur Entwicklung mittlerer und großer IT-Anwendungssysteme dar. Ihre Bedeutung wird im Enterprise-Bereich voraussichtlich weiter zunehmen. Jedenfalls richten die Branchen-größen – z.B. IBM, SAP, Microsoft und Oracle – ihre Integrations- und Middleware-Pro-dukte deutlich sichtbar darauf aus.

Composite Applications helfen den Unternehmen, heterogene IT-Strukturen in den Griff zu bekommen und einen stabilen Systembetrieb zu gewährleisten. Geeignete Verfahrens-weisen und Vorgehensmodelle flankieren die konkreten Techniken und Werkzeuge ihrer Entwicklung.

Composite Applications profitieren von den Potenzialen eines effektiven Managements in allen Phasen ihres Lebenszyklus. Typische Entwicklungsthemen, z.B. Qualitätssiche-rung, Deployment oder Sicherheit, spielen eine gewichtige Rolle. Die modellgetriebene Softwareentwicklung erweist sich als besonders geeignet, um in ihrem Umfeld formal

Vorwort

12

erfasste Geschäftsprozesse idealerweise „auf Knopfdruck“ zur Ausführung zu bringen bzw. ihre IT-technische Implementierung zu großen Teilen vorzubereiten.

Dieses Buch verfolgt das Ziel, die vielfältigen Einflüsse, die sich im Umfeld der Composite Applications ergeben, in übersichtlicher und leicht verständlicher Form zusammenzustel-len und zu beschreiben. Dem Projekterfahrenen mag das eine oder andere durchaus be-kannt vorkommen, doch geht es auch und gerade um das Aufzeigen des Zusammenspiels der Einflussgrößen. Ein gemeinsames Verständnis der Software- und Systemarchitektur der Composite Applications unter allen Beteiligten schafft die besten Voraussetzungen für eine erfolgreiche Projektdurchführung.

An dieser Stelle möchte ich mich bei allen, die mich beim Schreiben in vielfältiger Form unterstützt haben, herzlich bedanken: zuvorderst bei meiner Familie und bei Sebastian Burkart von entwickler.press für die Projektleitung und die freundliche Unterstützung.

Ich wünsche nun viel Freude bei der Lektüre!

München, im April 2010 Christoph Mathas


1 Einleitung

In der Fachdiskussion um neue und moderne Ansätze in der Software- und Systement-wicklung fällt der Begriff der Composite Applications, also der zusammengesetzten An-wendungen, seit einiger Zeit häufiger. Mit der Verfügbarkeit neuer und leistungsfähiger Design- und Entwicklungsframeworks, häufig – wenn auch nicht zwingend – basierend auf den Paradigmen der serviceorientierten Architektur (SOA), erlangen sie in der Praxis eine zunehmende Bedeutung. Auch die großen Hersteller, z.B. IBM, Microsoft, SAP und Oracle, haben diesen Trend erkannt und fördern ihn.

Ihr Anwendungsbereich ist nicht nur auf denjenigen der Enterprise Applications im Um-feld von Wirtschaft und Verwaltung beschränkt, auch wenn sie der wesentliche Auslöser der Technologieentwicklung waren. Die Beispiele wie die Service Component Architecture (SCA) oder der Distributed-OSGi-Plattform tragen ihre Konzepte auch in die vornehmlich technisch geprägte Anwendungsentwicklung weiter. Hier sei das Stichwort der Micro-Container genannt.

Da die Composite Applications auf einem technisch besonders leistungsfähigen und stu-fenweise erweiterbaren Designframework basieren, für das darüber hinaus leistungsfä-hige Programmiermodelle und Implementierungsmittel verfügbar sind, eignen sie sich für Projekte beliebiger Größenordnungen. Dieses ist mit dem Begriff der Skalierbarkeit gemeint, die aus technischer Sicht in eine horizontale und vertikale Systempartitionie-rung mündet, was die Transparenz, Steuerbarkeit und Kommunizierbarkeit der Entwick-lungsergebnisse fördert.

Wie in der IT angesichts neuer Technologieströmungen häufig der Fall,gehen die Vorstel-lungen über die inhaltlichen Schwerpunkte über die reine Begrifflichkeit hinaus rasch auseinander. Der Grund hierfür dürfte das breite Spektrum der von den Composite Ap-plications abgedeckten Technologien sein: Sie reichen von der interaktiven Webapplika-tion, die sich durch eine einfache Integrierbarkeit von Oberflächenkomponenten in ein modulares Portalframework auszeichnet, bis zur technisch eleganten und einfach um-zusetzenden Serverapplikation, inklusive einer abgesetzten Prozesssteuerung von Ge-schäftslogik durch ein Workflow-Management-System (WfMS).

Angesichts dieser Vielfalt einen gemeinsamen Nenner zu definieren, ist durchaus eine Herausforderung. Diesen herauszuarbeiten und in Bezug zu den wesentlichen Entwick-lungsströmungen zu setzen, ist das Ziel dieses Buchs. Es unterscheidet sich von anderen dadurch, dass es sich nicht auf ein herstellerspezifisches Framework, z.B. die IBM Lotus Suite, konzentriert, sondern einen durchgängig produktneutralen Blickwinkel einnimmt. Beantwortet werden Fragen wie:

1 – Einleitung

14

In welchen Projekten lohnt sich der Einsatz der Composite Applications? •Wo liegen die Gemeinsamkeiten angesichts verschiedener für sie verwendbarer Platt- •formen und Technologien?

Worauf ist bei der Projektdurchführung besonders zu achten? •Welche Auswahlkriterien führen zu einer richtigen und passenden Toolumgebung in •einem neuen Entwicklungsprojekt?

In diesem Buch geht es darum, die entscheidenden Aspekte der modernen Software- und Systementwicklung diesen Punkten genauer auszuleuchten und verständlich darzustel-len. Die Bandbreite der ins Spiel kommenden technischen Themen ist wie angesprochen vielfältig.

Wie schön war in seiner Einfachheit das klassische Modell der n-Schichten (n-Tier, üb-licherweise n=3) der Java-Welt: Informationssysteme des „Enterprise Information Tier“ konzentrieren den Zugriff auf die verschiedenen heterogenen Datenquellen, entweder Fremdsysteme oder Datenbanken. Die darüber liegende Schicht der Geschäftslogik dient der sinnvollen Verarbeitung der solchermaßen bereitgestellten Daten. Die Präsentation der Verarbeitungsergebnisse erfolgt mittels einer grafischen Benutzerschnittstelle (Graphical User Interface, GUI). Die Berücksichtigung objektorientierter Patterns, wie etwa dasjenige des Model View Controllers (MVC), unterstützt den Anwendungsentwickler dabei durch eine klare und eindeutige Form der Systemstrukturierung. Das Java-EE- (Java Enterprise Edition)-Framework liefert auch gleich den technischen Unterbau mit dazu. Auf der an-deren Seite stand Microsoft mit seinen Component-Object-Model (COM/DCOM)-Modell, und hinter diesen beiden Gegenspielern standen unversöhnliche konkurrierende Anhän-gerscharen an Entwicklern, die nichts miteinander zu tun haben wollten.

In modernen Entwicklungsumgebungen und -frameworks verwischen hingegen zuneh-mend Technologiegrenzen und herstellerspezifische Architekturparadigmen: Universelle Protokolle und Standards, zumindest der ernsthafte Versuch der kommerziellen, großen Infrastrukturanbieter in Richtung von offenen, vornehmlich serviceorientierten Software- und Systemarchitekturen, machen es erforderlich, sich bereits vor Beginn und während der Entwicklungsarbeit mit wesentlichen nichtfunktionalen Systemeigenschaften struk-turell zu befassen. Dabei können die Paradigmen der Composite Applications effektiv helfen und unterstützen.

Deren Grundprinzipien haben heute bereits Einzug in nahezu alle modernen Entwick-lungsframeworks der Branchengrößen – IBM WebSphere, Oracle Fusion (Sun), BizTalk/Moss von Microsoft, Tibco BPM oder SAP PI – gehalten. Daneben gibt es auch kleinere Spezi-alanbieter wie Cordys, die auf diesem Gebiet durchaus leistungsfähige Speziallösungen anbieten.

Der im täglichen, kräftezehrenden Projektgeschäft stehende Architekt und Entwickler, stets an einem modernen und zukunftsträchtigen Entwurf seiner Software interessiert, wird dadurch mehr oder weniger zwangsläufig an die grundlegenden Paradigmen der Composite Applications herangeführt. Das gilt auch für diejenigen, die sich für diese neu-en Entwicklungen nicht ausdrücklich interessieren, bedingt durch den Wandel in den Programmiermodellen und einer immer besseren Toolunterstützung.


Für wen ist dieses Buch gedacht?

1.1 Für wen ist dieses Buch gedacht?Tief greifende Umbrüche sind hinsichtlich der IT-Architekturen, Infrastruktur- und Im-plementierungstechnologien für die nahe und mittelfristige Zukunft eher nicht zu erwar-ten: Vielmehr werden die vorhandenen Technologien wohl immer besser unter einer weit reichenden automatischen Unterstützung der Implementierungstätigkeiten miteinander konsolidiert. Leichtgewichtige Frameworks und rasche Entwicklungszyklen gestatten ei-ne hohe Produktivität, gerade hinsichtlich der agilen Softwareentwicklung und hybrider Hosting-Modelle (z.B. serviceorientierte Architekturen als Grundlage von Software-as-a-Service), die künftig stetig an Bedeutung gewinnen dürften.

Die verschiedenen Softwaretechnologien zur Anwendungsentwicklung wachsen so zu-sammen. Es wird immer schwieriger, zwischen Tätigkeiten der reinen Systemintegration und allgemeinen Implementierungsarbeiten zu unterscheiden. Die Fähigkeit, den Über-blick über die verfügbaren Technologien zu wahren, stellt eine wichtige Voraussetzung für ihr Verständnis und ihre Anwendung dar. Das gilt etwa für die Kenntnis der Bezüge zwischen den verschiedenen eingesetzten Einzeltechnologien (etwa GUI, Laufzeitcontai-ner, Prozess- und Datenintegration) sowie die Entwicklungs- und Einführungsphasen ei-nes neu zu entwickelnden Softwaresystems. Wo liegen ihre Gemeinsamkeiten, und nach welchen Kriterien können die eingesetzten Frameworks voneinander unterschieden wer-den?

In der hier gegebenen Darstellung geht es in diesem Sinne darum, die Leistungsstärken der Composite Applications herauszuarbeiten und aufzuzeigen, in welchen Anwen-dungsszenarien ihre Vorteile zur Geltung kommen. Durch Berücksichtigung der zeitge-mäßen modularen, häufig serviceorientierten Architekturansätze ist eine leistungsstarke Unterstützung für alle Phasen des Lebenszyklus einer neu zu entwickelnden und einzu-führenden IT-Applikation gewährleistet.

Unter Beachtung dieses grundsätzlichen Sachverhalts richtet sich die produktneutrale und herstellerunabhängige Darstellung in diesem Buch an den folgenden Leserkreis:

Softwareentwickler • können ihr Verständnis der verschiedenen Komponenten und Verfahrensweisen zur Entwicklung von Composite Applications vertiefen und ihre aktuellen Tätigkeiten so möglicherweise besser und präziser in den übergreifenden Entwicklungszusammenhang einordnen.

Softwarearchitekten • schärfen ihren Blick für die praktischen Herausforderungen der Umsetzung, über den gesamten Bogen der verschiedenen Entwurfstechniken und Softwaretechnologien. Die Composite Applications bilden hier sozusagen die Königs-klasse, da in ihren Einsatzszenarien die unterschiedlichsten Systemanforderungen zu definieren und zu berücksichtigen und mögliche inhaltliche und technische Kollisio-nen aufzulösen sind. Diese Arbeit ist nur mit dem entsprechenden Erfahrungsschatz zu leisten. Für Softwarearchitekten im Umfeld der Software- und Systemintegration ist die Relevanz dieser Konvergenz im integrationszentrischen Entwicklungsumfeld besonders hoch.

In zeitgemäßen IT-Projekten existiert eine enge Rückkopplung zwischen Technik und •Projektsteuerung. Das ist ein besonderes Merkmal des agilen Vorgehensmodells, das

1 – Einleitung

16

zumindest in Teilen in jedem zeitgemäßen IT-Projekt Beachtung finden sollte. Dieses Buch gestattet auch die Erarbeitung (oder besser: das „Erlesen“) der entsprechenden Hintergrundinformationen für Softwareentwicklungsprojekte mit einem gewissen Schwerpunkt auf der Software- und Systemintegration. So können auch Projektleiter von der Lektüre profitieren.

Nach dem Lesen sollten Sie, gleich welche Rolle Sie in den jeweiligen Entwicklungspro-jekten einnehmen, in die Lage versetzt sein, die Potenziale, den Einsatzbereich und Nut-zen der Composite Applications besser als zuvor zu bewerten und ihren Einfluss in Ihrem aktuellen oder zukünftigen Projektumfeld zielgenauer einzuschätzen. Einen besonderen Nutzen ziehen Sie naturgemäß aus der Beschreibung, wenn Ihre eigene Tätigkeit im Um-feld der Software- und Systementwicklung bzw. der Systemintegration selbst liegt.

1.2 Weshalb dieses Buch?Auch wenn sie nicht immer ausdrücklich so bezeichnet werden, gewinnen die den Com-posite Applications zu Grunde liegenden Konzepte in der praktischen Software- und Sys-tementwicklung stetig an Bedeutung. So wird mit Java/JEE 6 die Technologie der Web Beans (JSR 299) eingeführt, die die bislang vorherrschende künstliche Unterscheidung der Technologien zur losen Kopplung von Oberflächen- bzw. Infrastrukturkomponenten weit gehend aufheben. Aufgrund seiner grundlegenden Bedeutung für die Kommunika-tionsparadigmen nach den Vorgaben der Composite Applications wurde dieser Standard folgerichtig im Herbst des Jahres 2009 in „Contexts and Dependency Injection for the JEE platform“ umbenannt [SunCDI]. Hier finden sich wesentliche Ideen der Composite Ap-plications in einem konkreten Programmiermodell wieder. Ähnliches gilt für die Techno-logien der Micro-Container, etwa der Spring DM (Dynamic Modules) Server, die künftig in der Entwicklungspraxis eine größere Rolle spielen dürften.

Die serviceorientierte Architektur (SOA) hat die Zeit der großen Schlagzeilen mittlerweile hinter sich gelassen – und muss sich in verschiedenen Fachbeiträgen beizeiten gar den Vorwurf gefallen lassen, im Projektalltag impraktikabel zu sein.

Wer in der professionellen Softwareentwicklung unterwegs ist, kann sich dieser Ansicht jedoch nicht wirklich anschließen: Ihre charakteristischen Merkmale werden heute durch-gängig in den verfügbaren Applikationsframeworks berücksichtigt. Der große Nutzen der SOA ergibt sich daraus, dass mit ihr die Konzepte der modularen Softwareentwick-lung, die seit langem schon in der Systemintegration eine Rolle gespielt haben, deutlicher als zuvor herausgestrichen werden konnten, was ihre Konsolidierung vorangetrieben hat. Flankiert wird dieses durch kostenintensive Infrastrukturinvestitionen der Branchen-größen – hier seien nur die Schlagworte des Cloud Computing, Software-as-a-Service (SaaS) zitiert. Mit ihnen sind konkrete Programmier- und Betriebskonzepte verbunden, die Aus-wirkungen auf IT-Entwicklungsprojekte haben, ob man das nun befürwortet oder nicht.

Im Gesamtbild ist der Grundton erkennbar, dank einheitlicher Standards und Entwurfs-techniken Gesamtanwendungen zukünftig zu „assemblieren“, also einzelne Prozesskom-ponenten mit eigenen oder Marktkomponenten mit einem Minimalaufwand zu einem


Kapitelstruktur

Ganzen zusammenzufügen. Bei aller angebrachten Skepsis bedeutet das einen weiteren fundamentalen Schritt in Richtung zu einer industriellen softwaretechnischen Infrastruk-tur der IT.

Um demgemäß zu einem geschlossenen Bild der modernen, integrationszentrischen An-wendungsentwicklung zu kommen, sind moderne Softwarearchitekturkonzepte einer-seits in Bezug zu Methoden der agilen Softwareentwicklung zu setzen. Daneben stehen andererseits auch die Herausforderungen der modellgetriebenen Softwareentwicklung, die sehr stark von einem vertikal strukturierten (Top-Down-)Ansatz geprägt ist.

Die Composite Applications bieten hier Mittel und Möglichkeiten, die Vorteile dieser beiden Ansätze miteinander zu vereinen und die Effizienz der durchzuführenden Ent-wicklungsprojekte zu steigern. Der Komponentenbegriff erfährt auf allen Ebenen der Softwarearchitektur eine Renaissance, mehr noch: Durch entsprechende Erweiterungen werden die Komponenten in ein geschlossenes (vertikal integriertes) Anwendungssze-nario einbezogen, das hochwertige Benutzeroberflächen, Data-Center-Technologien mit vielgestaltigen Hosting-Modellen oder Vorgehensmodelle zur Anwendungsentwicklung abdeckt.

Das Buch verfolgt das Ziel, die verschiedenen technischen Aspekte der Composite Appli-cations, insbesondere in Bezug auf Fragen der System- und Prozessintegration, und der Anwenderinteraktion herauszuarbeiten und einen Überblick über die heute hierfür prak-tisch einsetzbaren Frameworks bzw. Technologien zu geben. Da damit ein hohes Automa-tisierungspotenzial verbunden ist, wird dieses früher oder später zu ihrer industriellen Anwendung und Nutzung führen. Unter diesem Gesichtspunkt soll die konzeptionelle Einordnung erleichtert und so auf die praktischen Herausforderungen, die sich in diesem Umfeld verstärkt stellen werden, vorbereitet werden.

1.3 KapitelstrukturEine Übersicht über den Aufbau dieses Buchs zeigt Abbildung 1.1. Das Buch ist für die zusammenhängende Lektüre gedacht, und fokussiert sich nach einem allgemeinen Über-blick auf die wichtigsten Spezialthemen, die sich aufgrund der breiten technischen Basis der Composite Applications ergeben:

Allgemeine Grundlagen • (Kapitel 2)Das Einstiegskapitel beschreibt die verschiedenen technischen und organisatorischen Einflüsse, die in der modernen Anwendungsentwicklung allgemein zu berücksichti-gen sind. Sie bieten die Randbedingungen für eine qualitativ hochstehende Entwick-lung verteilter Systeme, die einen zeitgemäßen Anforderungskatalog erfüllen sollen.

Composite Applications – Einordnung und Charakterisierung • (Kapitel 3)Dieses Kapitel fokussiert sich auf die Besonderheiten der Composite Applications und zeigt die Beziehungen zu den mannigfaltigen Strömungen der angewandten Infor-matik (modellgetriebene Entwicklung, Aspekte der losen Kopplung und der Anwen-dungsentwicklung) mit ihren verschiedenen Herausforderungen auf technischem und organisatorischem Gebiet.

1 – Einleitung

18

Horizontale Software- und Systemintegration • (Kapitel 4)Die (netzwerk-) technische Vernetzung der Komponentenarchitektur der Composite Applications trägt zu einem Großteil ihrer Flexibilität in ihrer Anwendung bei. Hier sind insbesondere die durch die serviceorientierte Architektur einer breiten Anwen-dergruppe nahegebrachten technischen Grundprinzipien zu berücksichtigen.

Übersicht über die Kapitelstruktur Abbildung 1.1:

Prozessintegration • (Kapitel 5)Ohne alle Details der Prozesssteuerung bis ins Einzelne auszuleuchten, beschäftigt sich dieses Kapitel mit den wichtigsten ihrer Konzepte, die für verteilte Anwendungen gül-tig sind. Neben den typischerweise in den Vordergrund gerückten Prozessmaschinen (Process Engines) für sequenzielle Verarbeitungsschritte bieten sich auch verschiedene andere Realisierungsformen an. Sie können bis hin zur „traditionellen“ Steuerung des Programmflusses in eigenständigen Komponenten, z.B. in den altbekannten Stateless Session Beans (SLSBs) der Java (JEE)-Welt, reichen.

Anwenderinteraktion • (Kapitel 6)Während die horizontale Software- und Systemintegration immer stärker standardi-siert wird, bietet sich hinsichtlich der grafischen Anwenderschnittstelle eine Vielzahl von Realisierungsformen und -möglichkeiten. Dieses Kapitel präsentiert eine knappe Übersicht und gibt Entscheidungshilfen für eigene Projekte.


Anmerkungen

Vertikale Software- und Systemintegration • (Kapitel 7)Ein wesentlicher Mehrwert der Composite Applications ergibt sich durch die Berück-sichtigung vertikaler Integrationsaufgaben, also solcher, die sich über die verschiede-nen Ebenen der Softwarearchitektur ziehen und deren Komponenten untereinander in Beziehung stehen. Mit welchem Instrumentarium für Composite Applications auf die wichtigsten Anforderungen dieses Umfelds, z.B. bezüglich der Informationssicherheit oder Qualitätssicherung, reagiert werden kann, ist Gegenstand dieses Kapitels.

Technologiebeispiel SCA • & SDO (Kapitel 8)Mit einem gewissen Fokus auf der horizontalen Systemintegration ist die Service Com-ponent Architecture (SCA) ein Beispiel für ein Framework, das wichtige Grundkonzep-te der Composite Applications aufnimmt und in ein „standardisiertes“ Programmier-modell überführt (soweit in der IT von Standards geredet werden kann). Im Bereich der Java-basierten Middleware-Plattformen insbesondere der Branchengrößen – IBM, Oracle und Tibco – wird SCA zukünftig eine wichtige Rolle spielen. SDO stellt dagegen ein Persistenzmodell bereit, das als flexibler Ressourcenadapter in verteilten Systemen eingesetzt werden kann und sich mit der SCA gut ergänzt. Mittlerweile existieren für die Eclipse-IDE entsprechende Editoren, die den Entwurf geeigneter Softwaresyste-me gestatten und ihre Produktivierung erleichtern. Dieses Kapitel soll anhand eines kleinen Beispiels den praktischen Einstieg in diese Thematik erleichtern und unter-stützen.

Abgerundet wird die Darstellung durch eine Zusammenfassung und einen Ausblick auf die zukünftige Entwicklung (Kapitel 9). Die Darstellung aus den Kapiteln 4 bis 7 eig-net sich auch für die ausschnittsweise Lektüre, die bei Bedarf inhaltlich vertieft werden kann.

1.4 AnmerkungenMan mag es bedauern oder auch nicht, dass gerade in der IT-Fachsprache – und nicht nur dort – dem Englischen ein beherrschender Einfluss zukommt. In der Praxis ist die Ver-wendung von Bezeichnungen wie Registry, Component, Directory etc. selbstverständlich. Zugunsten der Praxisnähe wird dieser Sprachgebrauch in der hier gegebenen Darstellung deshalb auch beibehalten.

An dieser Stelle noch eine kleine Anmerkung zu Tools und Linksammlung: Diese waren zum Zeitpunkt der Erstellung dieses Buchs aktuell – und doch werden sie über kurz oder lang sehr wahrscheinlich veralten.

1.5 Literaturverweise[SunCDI] Sun: JSR 299 – Contexts and Dependency Injection for the Java, EE platform,

URL: http://jcp.org/en/jsr/detail?id=299

http://jcp.org/en/jsr/detail?id=299


2 Grundlagen

Dieses Kapitel beschäftigt sich mit den wesentlichen architektonischen Grundlagen, die für die weitere Betrachtung der Composite Applications von Bedeutung sind. Die wich-tigsten Themen werden dabei in einer kompakten Darstellung beleuchtet. Sie sollte im Be-darfsfall durch weiteres Quellenstudium ergänzt werden. Ergänzende Literaturverweise geben hier mögliche Ansatzpunkte.

Das Kapitel beantwortet folgende Fragen:

In welchen Bezug stehen Composite Applications • zu bestehenden Softwaretechnolo-gien?

Welches Architekturverständnis liegt der weiteren Lektüre zu Grunde? •Welche Rolle spielen Frameworks, und an welcher Stelle bringen sie einen Mehrwert •im Projekt?

Welche funktionalen und nichtfunktionalen Systemanforderungen sind zu beachten, •und welche Antworten lassen sich mit Composite Applications darauf geben?

2.1 Treiber der TechnologieentwicklungAlbert Einstein wird das Bonmot zugeschrieben, hätte man die Forschung ausschließlich in die Hände der Ingenieure gelegt, existierten heute wohl perfekt funktionierende Petro-leumlampen, doch kaum eine Beleuchtung auf der Grundlage der Elektrizität. Stammt es tatsächlich von dem großen Wissenschaftler, so bestand seine Intention sicherlich darin, auf die besondere Bedeutung der Grundlagenforschung und Innovation hinzuweisen. Pointiert bringt diese Aussage auf den Punkt, dass jede Innovation in zweierlei Hinsicht zu überprüfen ist: Gestaltet sie bereits vorhandene Ideen durch punktuelle Verbesserun-gen weiter aus, oder handelt es sich um tatsächliche Neuerungen, etwa als Ergebnis einer fundamental neuen Betrachtungsweise?

Die aktuellen Trends in der angewandten Informatik – sowohl in der Wirtschaftsinforma-tik als auch in der technischen Informatik – sind daran gemessen eine ingenieurwissen-schaftliche Disziplin. Im Wesentlichen geht es darum, die bis in die frühen 2000er Jahre entwickelten Technologiekonzepte (etwa der Objekt- und Komponentenorientierung oder der serviceorientierten Architektur) auf zunehmend mächtigeren Hardwareplattfor-men und leistungsfähigen Kommunikationsinfrastrukturen in einen höherwertigen tech-nischen und organisatorischen Ordnungs- und Anwendungsrahmen einzubringen (siehe Kapitel 2.3). Dieser hat etwa die Software- und Systemarchitektur zum Inhalt, die techni-

2 – Grundlagen

22

sche IT-Infrastruktur (Hardware-/Netzwerktechnik) oder auch Software- und Organisa-tionsframeworks, aus denen sich die zu implementierende Geschäftslogik ableitet.

Der aus Ordnung und Rahmen zusammengesetzte Begriff des Ordnungsrahmens leitet sich vom lateinischen Begriff „ordo“ ab und steht übersetzt für Ordnung, Rang, Reihe oder Stand. Die Aufgabe des Ordnungsrahmens besteht darin, durch klare Strukturvor-gaben die Elemente eines Systems in eine Reihe, eine Rangordnung oder eine allgemei-ne Ordnung zu bringen. Durch Adaption aus englischsprachiger Literatur wird auch im Deutschen häufig synonym von „Framework“ gesprochen.

Frameworks sind heute in der Praxis der IT-Systementwicklung wichtiger als jemals zu-vor: sowohl auf der organisatorischen als auch auf der technischen Ebene. Dabei beziehen sie sich auf verschiedene Wirkungsfelder in mannigfaltiger Abstufung, und sie ergänzen sich, wobei ihre Grenzen untereinander fließend sind. Die Anwendung von Frameworks setzt ein gutes Verständnis ihres Sinns und Zwecks, ihrer technologischen und anwen-dungstechnischen Grundlagen voraus.

Bis in die frühen 1990er Jahre hinein, als solche mächtigen, abgestuften Frameworks in der Anwendungsentwicklung in der Breite noch nicht verfügbar waren, bestand die Auf-gabe der Anwendungsentwickler (vulgo: Programmierer) darin, mit den Hilfsmitteln der strukturierten oder objektorientierten Programmierung mehr oder weniger maschinen-nah Programmcode zu erstellen und auf einer technischen Zielplattform mit Abhängig-keiten zu Betriebssystem, Prozessortyp, Speicherausstattung etc. zu kompilieren.

Dieses mag einerseits hohe Anforderungen an den Erfindungsreichtum der Entwickler stellen, andererseits ergeben sich stets umfassende Gestaltungsspielräume in der Neu-erstellung oder Weiterentwicklung von Anwendungssystemen, die häufig proprietäre Kommunikationsprotokolle, Speicherverwaltungen, Threading- oder Transaktionskon-zepte mit sich bringen. Was für den einen, d.h. die beauftragenden Firmen, ein Unsicher-heitsfaktor sein mag, kommt den Anliegen der Entwickler möglicherweise entgegen (wie dem einen oder anderen von Ihnen bekannt sein dürfte): Letztere neigen dazu, kreative, individuelle Programmierstile zu pflegen, die durchaus zu ausgezeichneten und hochef-fizienten Lösungen führen, die in operationeller Hinsicht als vorbildlich zu bezeichnen sind. Doch die allgemeine Entwicklungseffizienz mag darunter leiden, da sich bei sol-chen individuellen Lösungen leicht Defizite z.B. hinsichtlich Wartungsfragen, weiterer Entwicklungsplanung, Integration oder Dokumentation eines Softwaresystems ergeben können.

Seit einigen Jahren geht der Trend nun dahin, geeignete Frameworks mit zusätzlichen technischen Ebenen (Indirektion) und Konfiguration einzusetzen, die über der reinen Kodierungsebene liegen. Sie beziehen immer stärker auch Gesichtspunkte der Laufzeit-architektur mit ein. Mit ihrer dementsprechend zunehmenden Komplexität wächst na-turgemäß die Gefahr herstellerspezifischer, proprietärer Lösungen. Diese in aller Regel unerwünschte und nur schwer zu korrigierende Festlegung auf eine konkrete Technolo-gieplattform ist unter dem Schlagwort des „Vendor Lock-Ins“ bekannt.

Die Grundsätze der Composite Applications greifen insbesondere jedoch nicht nur an dieser Stelle ein. Ihre Paradigmen eröffnen einen Weg zu gesteigerter Offenheit, Interope-rabilität, Performance und Erweiterbarkeit einmal erstellter Anwendungssysteme, ohne


Treiber der Technologieentwicklung

auf die Stärken der umfangreichen Entwicklungsframeworks zu verzichten. Die Wahl der richtigen Applikationsframeworks macht im Idealfall transparent, auf welcher Tech-nologiebasis die Ablauflogik beruht, mehr noch: Auch die sich immer wieder ergebenden Fragen nach Auslegung bzw. Skalierung der Ablaufumgebungen oder des Laufzeitma-nagements können aus der Applikationslogik herausgezogen bzw. herausgehalten und in modulare, separat konfigurierbare und verwaltete Einheiten ausgelagert werden.

Den Querverbindungen zwischen diesen Einheiten kommt insbesondere bezüglich ihrer technischen Ausgestaltung und administrativen Verwaltung eine stetig wachsende Be-deutung zu. Dabei sind verschiedene technische Fragen zu betrachten, etwa:

Wie lässt sich auf der Entwicklungsseite die Anwenderinteraktion mit der technischen •Prozesssteuerung in Einklang bringen?

Wie können Erweiterungen an den Applikationen vorgenommen werden, ohne bereits •erbrachte Entwicklungsleistung zu verlieren?

Wie können Fremdsysteme wie z.B. Datenbanken mit sensiblen Kundendaten effektiv •in die eigene Applikationslogik eingebunden werden?

Wie wird das System-Deployment durchgeführt? •Bei der Beantwortung derartiger Fragen gerät man in der modernen Systementwicklung zwangsläufig in das Spannungsfeld der mittlerweile weitläufig bekannten serviceorien-tierten Architektur (SOA) sowie des Geschäftsprozessmanagements (Business Process Management, BPM). Diese beiden Ansätze definieren Grundprinzipien einer modernen, einem Anwendungssystem zu Grunde liegenden Systemarchitektur, vor allem in Bezug auf Aufgaben der Systemintegration sowie einer effektiven, möglichst modellgetriebenen Implementierung der Geschäftslogik.

Composite Applications bringen diese beiden wichtigen Grundströmungen moderner Systemarchitekturen nicht nur konsistent miteinander in Deckung, sondern halten darü-ber hinaus auch die notwendigen Technologien vor, um komplexe Backend-Systeme zu integrieren und entsprechende Interaktionen in standardisierter Weise in Geschäftspro-zesse einzubeziehen. Die solchermaßen erstellten Anwendungen können dabei sowohl in „geschlossenen“, d.h. für konkrete Anwendungsfälle innerhalb einer Firma bzw. einer speziellen Anwendungsdomäne gedachten, oder in „offenen“, d.h. für externe Zugriffe geeigneten, Einsatzszenarien zum Einsatz kommen.

Diese Betrachtung macht plausibel, dass die Entwicklungsprinzipien der Composite Ap-plications keinen plötzlichen Kulturwechsel bedeuten, sondern die Grundideen in die bereits vorhandenen Frameworks und Protokolle übernommen werden und sie sich so in natürlicher Weise in Richtung umfassender Frameworks für Composite Applications weiterentwickeln. Das Rad muss schließlich nicht immer neu erfunden werden.

Die folgenden Unterkapitel gehen kurz auf die Grundlagen ein, die für die zeitgemäße Entwicklung von Anwendungssystemen im Allgemeinen und damit auch für Composite Applications von Bedeutung sind. In den Folgekapiteln werden schließlich die wesentli-chen Gesichtspunkte tiefergehend charakterisiert.

2 – Grundlagen

24

Composite Applications – ein kurzer Blick zurück2.1.1 Composite Applications bilden einen Sammelbegriff für allgemeine Entwurfsprinzipien moderner Softwarearchitekturen und passen damit prinzipiell auf nahezu „jedes“ An-wendungsszenario, das auf einer verteilten Softwareumgebung beruht. Dabei bestehen Querbeziehungen zu fast jeder neueren Entwicklungsströmung in der Softwaretechnolo-gie. Dieser Abschnitt soll hierüber einen kurzen historischen Abriss geben mit den für sie relevanten Errungenschaften aus der Software- und Anwendungsentwicklung.

Die Historie der heutigen angewandten Informatik, die sich mit der Entwicklung leis-tungsfähiger Anwendungssysteme in IT-Szenarien in Unternehmen und Verwaltungen auseinandersetzt (Wirtschaftsinformatik), aber zunehmend auch mit rein technischen Anwendungsdomänen (technische Informatik), ist letztlich nichts anderes als eine suk-zessive Einführung verschiedener Ebenen von technischen Abstraktionen bzw. Modellen mit drei Schwerpunktsetzungen [BeckerMathasWinkelmann]:

Die Ebene der • logischen Systemmodellierung umfasst die wesentlichen strukturellen Ei-genschaften eines Softwaresystems, insbesondere hinsichtlich seines inneren Aufbaus sowie seiner inneren und äußeren Wechselwirkungen. Dazu zählt auch die Identifika-tion der technischen Basisentitäten, etwa durch eine Objekt- oder Datenmodellierung. An dieser Stelle gehen die verschiedensten Architekturperspektiven (Facharchitektur, funktionale Zerlegung und Schichtung, Laufzeit, Integration, s.u.) ein.

Die Ebene der • Funktionsmodellierung bezieht sich auf die Realisierung der eigentlichen, geschäftskritischen Kernfunktionalität bzw. bereitet deren Implementierung zumin-dest vor. Hier kommen die verschiedenen verfügbaren Programmierparadigmen bzw. -stile (imperativ, deklarativ, objekt- oder komponentenorientiert, …) zur Wirkung.

Die Ebene der • technischen Systemmodellierung liefert ein Abbild einer realen oder vir-tuellen Ablaufumgebung, d.h. konkret einer Server- oder Ausführungsplattform. Auf dieser Grundlage erfolgt die Entwicklung und Umsetzung des eigentlichen Laufzeit-systems.

Leistungsfähige Grundkonzepte der technischen Systemmodellierung bilden die Basis ei-nes jeden Anwendungssystems und damit auch der Composite Applications. Sie werden in der theoretischen Informatik genauer untersucht.

Bahnbrechend war hier das Gedankenmodell der Turingmaschine, die der britische Ma-thematiker Alan Turing in den 1930er Jahren entwickelte und die als imaginärer Prototyp der modernen Computer überhaupt gilt [Hofmann]. Turings Entwurf lieferte nicht nur ein mathematisches Modell, sondern die grundlegenden Annahmen können darüber hinaus auch als Grundlage der konkreten technischen Umsetzung dienen: die Turingmaschine kann durch eine entsprechende Formalbeschreibung „programmiert“ werden. Turing be-trachtete hierzu ein unendlich langes Speicherband (heute als Ein-Band-Turingmaschine bezeichnet), auf dem sich ein Schreib- bzw. Lesekopf bewegt, der primitive Basisoperatio-nen ausführen kann („Zeichen lesen“, „Zeichen schreiben“, „Kopf bewegen“). Er bewies, dass sich mithilfe einer solchen Maschine jedes vorstellbare Problem, für das eine Darstel-lung als Algorithmus existiert, lösen lässt. In der Praxis ist der verfügbare Speicher einer Turingmaschine natürlich begrenzt. Die Einheit von Programmiersprache und Computer, die bei Unterstellung eines unendlichen Speichers alle Operationen ausführen könnte wie


Treiber der Technologieentwicklung

die klassische imaginäre Turingmaschine, wird als Turing-vollständig bezeichnet. Turing-vollständige Systeme können alle vom Menschen berechenbaren Funktionen tatsächlich auch berechnen und einander emulieren; mit einem Wort, sie sind universell program-mierbar.

Dieser Ansatz war deshalb so revolutionär neu, weil er den Sprung aus der theoretischen Betrachtungsweise der Algorithmen in Richtung einer technischen Ingenieurdisziplin ge-stattet, auf der die heutige maschinelle Informationsverarbeitung beruht. Im Sinne des erwähnten Einsteinschen Ausspruchs stellt dieses eine echte Basisinnovation dar, aus der innerhalb einer recht kurzen Zeit eine Milliardenindustrie erwachsen sollte.

Die Composite Applications sind darüber hinaus durch eine Konvergenz der Hardware-, Netzwerktechnik sowie weiterer konzeptioneller Fortschritte in der Anwendungsent-wicklung gekennzeichnet. So sind etwa tragfähige Virtualisierungskonzepte ohne ent-sprechende Rechenleistung, Speicherausstattung und Netzkommunikation nicht vor-stellbar, z.B. durch neue Prozessoren und Speichertechnologie. In Bezug auf die digitale Übertragungstechnik spielt schließlich die Informationstheorie eine große Rolle, die Clau-de E. Shannon im Jahr 1948 begründete [Shannon].

Derartige grundlegende Innovationen begründen einen Großteil des theoretischen Fun-daments, auf dem die heutigen Anwendungssysteme basieren. Erst darauf aufbauend konnte die moderne Softwaretechnologie ihre rasante Entwicklung nehmen. So konnten schließlich Ansätze zur systematischen und toolgestützten Spezifikation der Systemfunk-tionalität und Grundstruktur der Softwaresysteme ins Auge gefasst werden, um Proble-me der angesprochenen logischen Modellierung bzw. Funktionsmodellierung effizient zu lösen.

Die Programmiersprachen und -konzepte bilden den zentralen Ankerpunkt der Funkti-onsmodellierung, deren historische Entwicklung Abbildung 2.1 darstellt. In ihren ersten Versionen ermöglichten sie eine symbolische Kodierung programmiertechnischer Aus-führungslogik (Assembler). Die Einführung der prozeduralen Sprachen zu Beginn der 1960er Jahre verbesserte die Entwurfsmöglichkeiten hinsichtlich des Programmflusses durch die Zerlegung der Ausführungslogik in Funktionen und Prozeduren (Beispiele: Pascal, C). In den 1980er Jahren wurden schließlich die objektorientierten Programmierspra-chen entwickelt, die ihre Stärke durch die Eigenschaft der „Abbildung“ der menschlichen Vorstellungswelt auf softwaretechnische Entitäten vereinfachen (Modellierung anhand von Attributen und Verhalten von Klassen). Sie stellen bis heute die Basiswerkzeuge vie-ler Anwendungsentwickler dar und bilden auch die Basis leistungsstarker Applikations-frameworks (Beispiele: C++, C#, Java).

Die Softwareentwicklung in objektorientierten Programmiersprachen wird in der Regel durch objektorientierte Analyse (OOA) und objektorientiertes Design (OOD) flankiert. Diese auch heute noch beliebte und weithin verbreitete Entwurfsmethodik glättet in natürlicher Weise den Strukturbruch, der mit den bis in die 1970er Jahre eingesetzten Modellierungsverfahren – im Wesentlichen der strukturierten Analyse (SA) und des strukturierten Designs (SD) – zwischen Analyseergebnissen, Systementwurf und System-implementierung bestand. In OOA/OOD fließen Zustands-, Funktions-, Daten- und Er-eignismodellierung in natürlicher Weise zusammen.

2 – Grundlagen

26

Die Abstraktion von den hardwaretechnischen Laufzeitumgebungen auf der Ebene der technischen Systemmodellierung berührt naturgemäß neben den rein theoretischen Her-ausforderungen auch die wirtschaftlichen Interessen der Softwareproduzenten.

Diese Entwicklungsrichtung wurde mithilfe der Komponententechnologie um das Jahr 1995 ge-fördert, deren Anwendung ein vorgegebenes Framework, das in einer Laufzeitumgebung festgelegte Bezugspunkte einführt und einen festen Bestandteil des so genannten „Laufzeit-containers“ ausmacht. Die Komponenten, also die einzelnen Logikbausteine, aus denen sich eine Applikation zusammensetzt, hängen sich in dieses Framework über fest spezifizierte Schnittstellen ein (etwa Suns JEE-Framework, Microsofts COM/DCOM). Der Vorteil dieses Verfahrens besteht darin, dass es sich in allen Systemumgebungen, die die entsprechenden Schnittstellenspezifikationen unterstützen, verwenden lässt und die entfernte Kommunika-tion zwischen verschiedenen Komponenten weit gehend durch Anwendung von Standard-protokollen umgesetzt werden kann. Damit gibt diese Technologie bereits die Marschroute in Richtung einer virtuellen Ablaufumgebung vor: Die Laufzeitcontainer können ihrerseits auf virtuellen Maschinen (z.B. für die Programmiersprachen Java, C#) laufen und auch auf virtuellen Servern betrieben werden (siehe Kapitel 4.6).

Die modellgetriebene Softwareentwicklung (Model-driven Software Development, MDSD) fügt den bereits genannten Abstraktionsebenen eine weitere Ebene hinzu, indem sie auf einer übergreifenden Modellebene die funktionalen, logischen und technischen Modellie-rungsebenen miteinander verknüpft und in einen gemeinsamen Rahmen stellt.

Auf dieser Grundlage entworfene Modelle bieten potenziell eine hohe Effektivität bei der Entwicklung von Anwendungssystemen, doch ist damit Systemimplementierung nur dann sinnvoll möglich, wenn Modelle und die Entwicklungswerkzeuge optimal auf eine IT-Zielinfrastruktur abgestimmt sind, um eine durchgängige Entwicklung auch auf der technischen Abstraktionsebene zu erreichen. Erst dann lassen sich Modelle tatsächlich in Richtung einer direkten Ausführbarkeit bewegen (Domain Engineering).

Composite Applications in ihrer historischen EinordnungAbbildung 2.1:


Architekturbeschreibung nach IEEE 1471-2000

Der arbeitsteilige Modellierungsprozess, in den fachliche ebenso wie technische Anfor-derungen eingehen, stellt hohe analytische Anforderungen an die Architekten eines Soft-waresystems.

Ohne einen passgenauen Prozess- und Ordnungsrahmen ist es oftmals schwierig, unter den kurzen Änderungszyklen der einzelnen Softwarekomponenten, wie sie in der Pra-xis häufig vorkommen, zu einer koordinierten Weiterentwicklung des Gesamtsystems zu kommen.

Die neueren Entwicklungen ergänzen daher die beschriebenen Ansätze der Komponen-tentechnologie, um auch für diese Problematik eine Abhilfe zu schaffen: Durch die Einfüh-rung von allgemeinen, d.h. verbreitet verwendeten Standards, die auf unterschiedlichen Technologieplattformen implementiert werden, lässt sich eine technologieunabhängige und plattformübergreifende Abstraktionsebene konstruieren (z.B. Web Services auf Basis des SOAP-Standards). Diese Entwicklung findet ihren weithin bekannten Ausdruck in den Applikationsframeworks für die serviceorientierte Architektur (SOA), die sich beson-ders gut als Basisarchitektur eignet, um Prozessmodelle auf heterogenen IT-Infrastruktu-ren zu implementieren und effizient zu betreiben.

Composite Applications fügen sich in diese Entwicklungslinie in natürlicher Weise ein, in-dem sie die Entwicklungen aus dem Gebiet der verteilten Systeme (SOA), des Geschäfts-prozessmanagements (BPM) und der modernen Verfahren des Software Engineerings aufnehmen und zusammenführen. Insbesondere geben sie eine tragfähige Antwort auf die systemtechnischen Fragen, die sich aus den modernen modellgetriebenen Entwick-lungsansätzen heraus ergeben.

Composite Applications vereinen die leistungsfähigsten derzeit verfüg-KOmPAKT: baren Konzepte auf Seiten der Hardware- und der Softwaretechnologie unter Einbe-ziehung der Netzwerktechnologie für die Belange der Systemverteilung in natürlicher Weise. Dabei berücksichtigen sie insbesondere die modernen Ansätze der tech-nischen und logischen Systemmodellierung sowie der Funktionsmodellierung. Sie legen die Grundzüge und -prinzipien einer System- und Softwarearchitektur fest, mit denen die Ideen und Konzepte einer modellgetriebenen Softwareentwicklung (Model Driven Software Development, MDSD) auf hochgradig skalierbare, erweiterbare und offene (d.h. integrierbare) IT-Applikationen abgebildet werden können.

2.2 Architekturbeschreibung nach IEEE 1471-2000Für eine technische Detailbetrachtung der Composite Applications ist ein gemeinsamer Architekturbegriff eine Voraussetzung. Was ist überhaupt ein IT-System? Bereits hinter diesem Begriff steht offenbar eine technische Modellabstraktion, die verschiedene Fragen beantworten muss, darunter:

Bezieht sie sich auf die Gesamtheit aller technischen Funktionsbausteine inklusive aller •Sub- und Teilsysteme?

2 – Grundlagen

28

Oder ist jede minimale Funktionseinheit, aus denen sich das Gesamtsystem am Ende •zusammensetzt, bereits eine geeignete Bezugsgröße?

Welcher Teilaspekt steht im Mittelpunkt der Betrachtung (z.B. die Integrations-, die •Fach- oder die Systemarchitektur)?

Für den Systembegriff im Allgemeinen, und damit auch für IT-Systeme und insbesondere für Composite Applications werden daher verlässliche Ordnungskriterien benötigt. Das führt uns wiederum in den Wirkungsbereich der bereits angesprochenen Frameworks. Bezüglich Modelle übernehmen hier Metamodelle deren Funktion. Sie legen die einzel-nen Begrifflichkeiten (Syntax), aus denen sich eine Modellbeschreibung zusammensetzt, ebenso fest wie deren Beziehungen untereinander (Semantik).

Metamodelle dienen als Rezeptur einer technisch abstrahierten Beschreibungsart und -methode. Der IEEE-Standard 1471-2000 (auch ISO/IEC 42010) bietet ein solches Metamo-dell bezüglich Architekturen von Softwaresystemen (in der IEEE-Terminologie „software-intensive Systeme“, Abbildung 2.2). Da dieser Standard der weiteren Betrachtung der Composite Applications zu Grunde liegt, sei an dieser Stelle kurz auf ihn eingegangen. Er fasst die folgenden Kernbegriffe in einem gemeinsamen Bild zusammen:

Den zentralen Ausgangspunkt bildet der Begriff des • Systems. Ein solches entspricht ganz allgemein einer Sammlung von Einzelbausteinen oder Komponenten, die in einer sinnvollen Weise zusammengefasst sind, zwischen denen Beziehungen bestehen und die im Sinne einer spezifischen Systemfunktionalität gezielt zusammenwirken.

Die Anordnung und das Zusammenspiel der Einzelbausteine werden mittels der •System archi tek tur festgelegt. Darin handelt es sich ebenfalls um einen konzeptionellen Oberbegriff.

Die Detaillierung der Systemarchitektur geschieht schließlich mithilfe einer • Beschrei-bung (Description). Diese stellt eine beliebige und auch umfassende Sammlung von Produkten und Ergebnissen dar, die sich generell für Dokumentationszwecke eignen. Dabei muss es sich gar nicht um formale Beschreibungen handeln, sondern es ist alles zugelassen und erlaubt, was auf Basis einer Dokumentation Klarheit in den Systemauf-bau bringt (siehe Kapitel 2.5).

Diese Systembeschreibung ist in • Sichten (Views) organisiert. Sie stellen den Blickwinkel dar, den die an einem System beteiligten menschlichen Akteure (Stakeholder) einneh-men. Unterscheidungsmerkmale und inhaltliche Schwerpunkte ergeben sich aus ihren jeweiligen Standpunkten bzw. Perspektiven (Viewpoints), die ihr eigenes Anliegen (Con-cern) verfolgen und daraus die Modelle der Beschreibung definieren.

Der Standard führt auch den Begriff des • Modells verbindlich ein: Jede der Einzelsichten wird mittels eines oder mehrerer Modelle beschrieben, die ihrerseits wiederum als Be-standteil des Gesamtsystems betrachtet werden.

Es können nun verschiedene Perspektiven auf ein Softwaresystem eingenommen werden. In Analogie zu den bereits erwähnten drei Abstraktionshauptebenen in der Software- und Systementwicklung sind in der Praxis die folgenden ausschlaggebend:


Architekturbeschreibung nach IEEE 1471-2000

Die Elemente des IEEE-1471-Architekturstandards Abbildung 2.2:

2 – Grundlagen

30

Die • Facharchitektur, die alle funktionalen Systemspezifikationen umfasst. Bezüglich der Composite Applications spielen hier formale Prozessdefinitionen, die beschreiben, wie ihre Einzelbausteine zusammenwirken, eine herausgehobene Rolle. Aber auch jede an-dere Art der Fachspezifikation ist hier zugelassen und geht in die Facharchitektur eines Arbeitsgebiets ein (z.B. auch handschriftliche Notizen, Sketches).

Die • Software- bzw. Anwendungsarchitektur, die den strukturellen, logischen Zusammenhang bzw. Aufbau des betrachteten Systems in seinen Einzelbausteinen beschreibt. Bezüglich der verteilten Systeme, und damit auch der Composite Applications, wird hier häufig die Sicht der Komponentenarchitektur eingenommen. Sie zeigt die logische Zerlegung der An-wendungsarchitektur in unterschiedliche, möglichst autarke Softwarebausteine, eben die Komponenten (oder auch Services), auf, die miteinander kommunizieren. Dabei werden nicht nur strukturelle Zusammenhänge, die zum Zeitpunkt des Systementwurfs interes-sant sind, erfasst, sondern auch solche, die zur Ausführungszeit eine Rolle spielen (Lauf-zeitarchitektursicht, z.B. Interaktions- und Sequenzdiagramme).

Die • Systemarchitektur, die die Software- bzw. Anwendungsarchitektur auf die tatsächlichen systemtechnischen Gegebenheiten bzw. physikalischen Systemkomponenten abbildet. Auch hierzu existieren verschiedene Sichten bzw. Standpunkte. Für Composite Applica-tions im Umfeld der Wirtschaftsinformatik besonders relevant sind diejenigen der Integra-tions- und „Enterprise-Technology“-Architektur (auch kurz als ET-Architektur bezeichnet):

Die Integrationsarchitektur führt alle systemtechnischen Anteile zusammen, die der •Integration der verschiedenen Bausteine eines verteilten Systems (um die es sich bei den Composite Applications handelt) dienen und diese untereinander in Beziehung setzen. Besondere Berücksichtigung finden hier z.B. Middleware-, Adapter- oder Bridging-Technologien.

Kennzeichnend für die Einführung integrationszentrischer Systeme • ist die Tatsache, dass sie oft in ein unternehmensweit bestehendes Integrationsszenario einzubinden sind. Es bestehen also in der Regel bereits entsprechende Auskunftssysteme (Enter-prise Information Systems) sowie eine systemtechnische Infrastruktur (z.B. Server-landschaft, netzwerktechnische Voraussetzungen). Erstere werden auch als Legacy-Systeme – im Sinne von Bestandssystemen und nicht von Altlasten – bezeichnet. Daneben existieren Vorgaben aus der IT-Strategie, die die Entwicklung von Compo-site Applications beeinflussen bzw. einschränken können. Alle diese Gesichtspunkte finden Eingang in die Enterprise-Technology-Architektur.

Tabelle 2.1 zeigt ergänzend hierzu eine kurze Übersicht.

Da bei der Erstellung von Softwaresystemen nicht nur die traditionelle HInWEIS: Software- und Systemarchitektur betrachtet wird, bei der sich zahlreiche Freiheitsgra-de z.B. hinsichtlich der Integrationsarchitektur ergeben, werden heute wie beschrie-ben zahlreiche andere Architektursichten mehr systematisch eingenommen und im Vorfeld analysiert. An die Stelle der Systemarchitektur tritt nun besser der Begriff der „Technologiearchitektur“, der alle denkbaren Architekturperspektiven und -sichten zusammenfasst.

Composite Applications...serviceorientierte Anwendungsentwicklung (SODA) 105 3.3 Berücksichtigung...

Documents

Transcript of Composite Applications...serviceorientierte Anwendungsentwicklung (SODA) 105 3.3 Berücksichtigung...