Foderative Unternehmensprozesse: Technologien, Standards Und Perspektiven Fur Vernetzte Systeme

Wagner/Schwarzenbacher Föderative Unternehmensprozesse

Föderative Unternehmensprozesse Technologien, Standards und Perspektiven für vernetzte Systeme

von Johann Wagner und Kurt Schwarzenbacher

Publicis Corporate Publishing

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

Autor und Verlag haben alle Texte in diesem Buch mit großer Sorgfalt erarbeitet. Dennoch können Fehler nicht ausgeschlossen werden. Eine Haftung des Verlags oder des Autors, gleich aus welchem Rechtsgrund, ist ausgeschlossen. Die in diesem Buch wiedergegebenen Bezeichnungen können Warenzeichen sein, deren Benutzung durch Dritte für deren Zwecke die Rechte der Inhaber verletzen kann. http://www.publicis-erlangen.de/books

ISBN 3-89578-231-9 Herausgeber: Siemens Aktiengesellschaft, Berlin und München Verlag: Publicis Corporate Publishing, Erlangen © 2004 by Publicis KommunikationsAgentur GmbH, GWA, Erlangen Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen, Bearbeitungen sonstiger Art sowie für die Einspeicherung und Verarbeitung in elektronischen Systemen. Dies gilt auch für die Entnahme von einzelnen Abbildungen und bei auszugsweiser Verwendung von Texten. Printed in Germany

Danksagung

Wir bedanken uns sehr herzlich bei unseren Kollegen innerhalb von Siemens Business Services, welche uns als Diskussionspartner zur Verfügung standen und welche die Patenschaft für einzelne Kapitel des Buches übernommen haben. Unser besonderer Dank gilt so den Herren Achim Luhn, Christian Vester, Igor Fodor, Lothar Bamberger, Oliver Kraus, Peter Poschenrieder und Volker Stiehl. Wir danken unseren Führungskräften, den Herren Johann Breidler und Helmut Tillinger, die uns zum Schreiben ermuntert haben. Auf Seiten der Hersteller IBM, Microsoft, SAP, IDS Scheer, BEA, Oracle, Siebel und Brainloop haben die folgenden Personen unsere Aussagen zu den 27 zitierten Produkten überprüft: Frau Karin Mair und die Herren Bernd Vellguth, Carsten Czarski, Christian Holsing, Christoph Sprenger, Colin Harnwell, Detlev Jeschka, Detlev Straeten, Frank Prengel, Günther Stürner, John Doe, Klaus Dalke, Karl-Heinz Fesenbeckh, Karsten Hohage, Kemal Koeksal, Matthias Haendly, Markus Seyfried, Richard Turner, Roland Peisl, Tilo Böttcher und Torsten Sydow. Unsere Erkenntnisse beruhen aber auch auf einer freimütigen Auseinandersetzung mit David Chappel von Chappel Associates, Eric Newcomer von IONA, Eric Swift, Norm Juda und Richard Turner von Microsoft, Professor Frank Leymann von IBM Böblingen und der Universität Stuttgart, Howard Smith von CSC, Ismael Ghalimi von Intalio, Professor Mario Jeckle vom DaimlerChrysler Forschungslabor und der FH Furthwangen und Herbert Sattler von Fujitsu Siemens Computers. Wir danken ausdrücklich unseren Frauen Hildegard Wagner und Eva Maria Schwarzenbacher für ihre Rücksichtnahme und für die ihnen zugunsten der Erstellung des Manuskripts mit uns entgangene Zeit.

5

Vorwort

Die zunehmende Fokussierung von Unternehmen auf Kernkompetenzen und das Outsourcing ganzer Abteilungen erfordert standardisierte Interaktion zwischen Anwendungen über technische und organisatorische Grenzen hinweg. Unternehmen wollen einerseits weitgehend selbständig agieren und sich differenzieren, andererseits müssen sie nahtlos in die übergreifenden Wertschöpfungsnetzwerke eingebunden sein. Sie folgen damit einem föderativen Prinzip. Dieses Buch gibt IT-Managern, Beratern, Projektmanagern, Systemarchitekten und Studenten einen umfassenden Überblick über die technischen Perspektiven bei der Automatisierung globaler betriebswirtschaftlicher Prozesse. Es bietet einen Einstieg in die Kernkonzepte der neuen Technologien und Standards zur Modellierung, Implementierung und der Überwachung unternehmensübergreifender Prozessabläufe. Dieses Buch ist keines in der Reihe immer neuer Heilsbotschaften, welche die Entwicklung der IT seit langem begleiten. Es soll vielmehr helfen, die immer neu entstehenden Hypes mit kühlem Verstand zu hinterfragen. Dieses Buch verspricht auch nicht die Rettung aus dem Sumpf, in dem das IT-Management heute fest zu sitzen scheint. Es könnte jedoch dazu motivieren, sich aus diesem selbst zu befreien. Dieses Buch soll den Lesern helfen nüchtern und unbeirrt in die nächste Epoche der IT hinein zu gehen. Dabei wird die Diskussion nicht bei theoretischen Erwägungen belassen, sondern das Thema Föderative Unternehmensprozesse wird mit den aktuellen Produktangeboten ausgewählter Hersteller in Beziehung gesetzt. Für deren Unterstützung sei hier nochmals herzlich gedankt. Die zitierten Produkte sind als Beispiele für die Umsetzung der in diesem Buch behandelten Technologien zu verstehen. Denn bei der Mächtigkeit von Basisprodukten, Middleware und Frameworks macht es heute kaum Sinn, über Architekturen zu schreiben, ohne dabei die Produkte zu nennen, welche diese unterfüttern, und ja selbst die Architekturen vorgeben. Standards werden die Kooperation von Unternehmen auf technischer Ebene erheblich erleichtern. Die Anwendungen werden künftig als Web Services realisiert und sie werden intern von einem leicht adaptierbaren Workflow gesteuert. Ein solcher Workflow als eine global wirkende Choreographie verknüpft den Web Service mit allen in einem Netzwerk vorhandenen und benötigten weiteren Web Services. Web Services werden bereits jetzt in einem Netzwerk als Teile künftiger Lösungen bereitgehalten. Diese IT-Services gehen konform mit dem generellen Trend zur organisatorischen Modularisierung von Unternehmen, dem In- und Outsourcing von Services generell. Diese Affinität von Technologie und Organisation, ist die Grundlage einer neuen, erfolgsversprechenden Ära: der Ära föderativer Unternehmen.

München und Salzburg im Mai 2004

6

Johann Wagner und Kurt Schwarzenbacher

Inhaltsverzeichnis

1 1.1 1.2 1.3 1.4 1.5

Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Föderalismus als unternehmerisches Gestaltungsprinzip . . . . . . . . . . . . . . . . . Warum wird die Technologie von Web Services und Prozessen jetzt standardisiert? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wie kann man Software rasch an sich ändernde Bedingungen anpassen? . . . . Warum ändert sich die Programmierung und was ist gut daran? . . . . . . . . . . . Warum braucht es föderative Systeme? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 10

2 2.1 2.2

Grundlagen und Anforderungen föderativer Unternehmensprozesse . . . 19 Grundlegende Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Anforderungen föderativer Unternehmensprozesse an die IT . . . . . . . . . . . . . 22

3 3.1 3.2 3.3 3.4

Die Service-Blaupause eines Unternehmens . . . . . . . . . . . . . . . . . . . . . . . . Das ideale Unternehmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Netzwerke werden zum Eingangstor zu Unternehmen . . . . . . . . . . . . . . . . . . Die Blaupause eines Unternehmens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Systemarchitektur eines Unternehmens . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 28 29 31

4 4.1 4.2 4.3 4.4 4.5 4.5.1 4.5.2 4.6

Service-orientierte Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strukturierung durch Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strukturierung von Lösungen durch Abstraktionsschichten . . . . . . . . . . . . . . . Strukturierung durch Business-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Strukturierung durch Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Service-orientierte Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zusammensetzung von Anwendungen aus Services . . . . . . . . . . . . . . . . . . . . Dynamische Architekturen – Late Binding von Services . . . . . . . . . . . . . . . . Lose gekoppelte Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 32 34 36 39 40 44 46 48

5 5.1 5.2 5.3 5.4 5.5

Workflow-gesteuerte Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evolution der Software-Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steuerung betriebswirtschaftlicher Anwendungen durch Workflows . . . . . . . Theoretische Grundlagen der Workflow-Technologie . . . . . . . . . . . . . . . . . . . Workflow-Management-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Choreographie – der Use-Case von Workflows . . . . . . . . . . . . . . . . . . . . . . . .

51 51 52 57 57 58

6 6.1

Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Die Idee der Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

12 13 16 17

7

Inhaltsverzeichnis

6.2 6.3 6.3.1 6.3.2 6.3.3 6.4 6.4.1 6.4.2 6.5 6.6 6.6.1 6.6.2

Interoperation statt System-Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Service Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Messaging & Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard für Prozess-getriebene Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der BPEL Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Eigenschaften von BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Server zur Unterstützung von Prozessen . . . . . . . . . . . . . . . . . . . . Web-Service-Framework-Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Microsoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63 65 65 66 68 70 70 72 74 75 75 76

7 7.1 7.2 7.3 7.3.1 7.3.2 7.4 7.5 7.6

Grid Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Idee der Grid Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grid Server, Grids und OGSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Standard Interfaces für Grid Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die WSDL-Technologie für Grid Service Interfaces . . . . . . . . . . . . . . . . . . . . Grid Service Interfaces in OGSI 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Implementierung von Grid Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Grid Computing für Business-Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Bedeutung von Grid Services für die klassische IT und das ASP . . . . . . .

81 81 82 82 83 83 85 86 88

8 8.1 8.2 8.2.1 8.2.2 8.2.3 8.2.4

Föderierte Datenhaltungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Idee der Integration heterogener Informationen . . . . . . . . . . . . . . . . . . . . Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IBM DB2 Information Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Microsoft ADO.NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Oracle XML DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SAP TREX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89 89 92 92 93 95 97

9 9.1 9.1.1 9.1.2 9.1.3 9.2 9.2.1 9.2.2 9.3

Design, Monitoring und Werkzeuge föderativer Prozesse . . . . . . . . . . . . . 98 Anforderungsanalyse und Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Design der Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Integration, Test und Inbetriebnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Management- und Modellierwerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Business-Process-Management-Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Modellierungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Business Activity Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10 10.1 10.2

Informationsportale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Nutzen von Portalen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Single Sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8

Inhaltsverzeichnis

10.3 10.3.1 10.4 10.5 10.6 10.6.1 10.6.2 10.6.3 10.6.4 10.6.5 10.6.6

Personalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Das Portal zur Interaktion mit Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration von Anwendungen und Services über Portale . . . . . . . . . . . . . . . Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nutzen einer Multichannel Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multichannel-Integrationsplattform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multichannel Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Location Based Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sicherer Zugang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multidevice Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multidevice Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

125 126 127 127 128 129 129 130 130 130 131

11 11.1 11.2 11.3

Kommunikationsportale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Management gemeinsamer Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Groupware-Produkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

132 132 132 135

12 12.1 12.2 12.3

Kontrolle und Vertrauen in föderativen Netzwerken . . . . . . . . . . . . . . . . Vertrauen und Verträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Organisation kooperativer Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Neue Rollen für Kunden, Mitarbeiter und Führungskräfte . . . . . . . . . . . . . .

139 140 143 144

13 13.1 13.2

Rückblick und Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Rückblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

14

Abkürzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

15

Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

16 16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 16.9

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nachrichten-orientierte Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prozess/Workflow-Spezifikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . J2EE-Plattform für Workflows und Web Services . . . . . . . . . . . . . . . . . . . . . Domain-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security-Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Content-Zugriffs-Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Content-Präsentations-Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collaboration Platform Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

174 174 174 175 177 178 178 179 180 180

Hersteller- und Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

9

1 Einführung

• • • • • • •

Ist Föderalismus ein unternehmerisches Gestaltungsprinzip? Was ist eine föderative Organisation? Warum wird die Technologie von Web Services und Prozessen jetzt standardisiert? Welcher Nutzen ergibt sich aus der Standardisierung? Wie kann man Software rasch an sich ändernde Bedingungen anpassen? Warum ändert sich die Programmierung und was ist gut daran? Warum braucht es föderative Systeme?

1.1 Föderalismus als unternehmerisches Gestaltungsprinzip Das gemeinsame Kennzeichen aller föderativen Ideen ist der Grundsatz, die Eigenständigkeit eines jeden Mitglieds zu bewahren und es zugleich zu Leistungen nach eigenem Vermögen für das Gemeinwohl zu verpflichten. Als unternehmerisches Gestaltungsprinzip begünstigt der Föderalismus einen überschaubaren und differenzierten Aufbau von Unternehmensnetzwerken und Prozessen. Föderalismus schützt dabei als Form- und Strukturelement die kleinere Einheit vor der übergeordneten größeren, ohne dieser die zur Bewältigung ihrer Aufgaben benötigten Unterstützung vorzuenthalten, und bietet dieser erheblichem Gestaltungsspielraum in ihren Aufgaben. Föderativ ist also das Struktur- und Organisationsprinzip, in dem sich grundsätzlich selbständige, autonome Einheiten zu einem übergeordneten Ganzen zusammenschließen, um eine erforderliche Einheitlichkeit mit einer für den Erfolg der Organisation unabdingbaren Vielfältigkeit zu verbinden. Unternehmen haben dann Erfolg, wenn sie genügend – nicht unbedingt optimal – an die Rahmenbedingungen ihrer ökonomischen Umwelt angepasst sind. Einheitlichkeit ist eine hinreichende Voraussetzung für effiziente Kommunikation, vertrauensvollen Austausch von Information, für die Orientierung an gemeinsamen Zielen, für die Entwicklung und Herstellung von Produkten, die sich reibungslos ineinander fügen. Die Vielfalt ihrer Teile ist die notwendige Voraussetzung für die Erhaltung der Anpassungsfähigkeit der Organisation an die fortwährenden Änderungen und Forderungen ihrer ökonomischen Umgebung. Das sich föderativ verhaltende Unternehmen und die Föderation selbst ziehen dann Vorteile aus Ihrem Verbund, wenn sich der Gesamtnutzen erhöht und die Gesamtkosten sinken. Die Zukunft gehört den autonomen, föderativ verbundenen Unternehmen, die sich in ihrer Geschäftstätigkeit auf ihre Kernkompetenz konzentrieren und eingebunden sind in überbetriebliche, föderative Organisationen und Prozesse, die Bestandteile globaler Wertschöpfungsnetze sind. • Große Sportartikelhersteller betreiben keine eigenen Produktionsstätten mehr. Sie reduzieren ihre Aktivität auf Marketing und Design. Fehlende Leistungen und Ressourcen werden durch verbundene Unternehmen ergänzt.

10

1.1 Föderalismus als unternehmerisches Gestaltungsprinzip

• Im Wesentlichen werden alle Notebooks für die verschiedenen bekannten Großunternehmen von einem einzelnen unabhängigen Werk in Südostasien hergestellt. Der Computerhersteller Dell betreibt seit vielen Jahren Unternehmensnetzwerke zur effizienteren Erfüllung des Geschäftszweckes (Dell, 1999). Föderativ nennen wir ein Gestaltungsprinzip für Kooperationen und vernetzte Prozesse zwischen autonomen Unternehmen auf der Basis von Verträgen, dem Austausch von Information und dem Fluss von Waren und Dienstleistungen. Der Rückzug und die Spezialisierung der Unternehmen auf ihre Kernkompetenzen schafft Raum für das Auslagern von Leistungen. Die betrieblichen Bereiche Materialwirtschaft, Fertigung, Rechnungs- und Personalwesen eines typischen Unternehmens sind Kandidaten für eine Auslagerung (Outsourcing). Selbst Forschung und Entwicklung sowie das Marketing können als Dienstleistung eingekauft werden. Auch die Auslagerung des IT-Bereichs wird praktiziert. Das Outsourcing der Organisationsabteilung selbst würde jedoch den Sinn eines Unternehmens in Frage stellen. »Make or buy« radikal zu Ende gedacht, reduziert die notwendigen Leistungen eines Unternehmens auf die Festlegung der Strategie des Unternehmens und die laufende Anpassung seiner Unternehmensprozesse. Föderative Organisationen sind geprägt durch das zentrale, gemeinsame Interesse zur Bildung eines gemeinsamen Wertschöpfungsnetzes, das den einzelnen Mitgliedern weitgehende Unabhängigkeit einräumt. Föderative Organisationen stehen erfahrungsgemäß unter der Führung eines marktnahen Unternehmens. Alle verbundenen Unternehmen bewegen sich in einem Raum gemeinsamer Standards, Richtlinien und technischer und ethischer Normen. Die Eigenständigkeit eines jeden Unternehmens muss bewahrt bleiben. Gleichzeitig müssen bei der Bewältigung der Aufgaben die Beteiligten aber nicht nur zusammenwirken, sondern sich auch gegenseitig kontrollieren und wechselseitig fördern oder beschränken. Die Gestaltung von föderativen Prozessen, die für den Zusammenhalt, die Zusammenarbeit, den Informationsaustausch und die Steuerung sind, hat weit reichende Konsequenzen für Strategie, Organisation und Branchenstrukturen. Das Besondere an föderativen Organisationen im Vergleich zu traditionellen Unternehmen ist: • Föderative Organisationen haben die Fähigkeit zur Orchestrierung (Zusammenstellung und Steuerung) von Prozessen (Löwe, 2003). Ist die zu verkaufende Ware oder Dienstleistung festgelegt, geht es darum, die aktiven Teile des Unternehmensprozesses, die Ressourcen und Lieferanten zu bestimmen. Es ist wie bei einem Orchester: Ist das aufzuführende Stück bekannt, geht es darum, das Orchester festzulegen. Manchmal werden Oboen gebraucht, dann wieder ein Schlagzeug und schließlich noch Bratschen. Es muss aber nicht jedes immer verfügbar sein. Die daraus entstehenden, komplexen Wertschöpfungsnetze werfen Fragen hinsichtlich Führungs- und Anreizsystemen, Wissensmanagement und Management von Standards auf. • In föderativen Organisationen tritt die Bedeutung des Besitzes eigener Ressourcen hinter die Fähigkeit zur Orchestrierung eigener und fremder Ressourcen zurück. • Föderative Organisationen suchen weltweit Partner. • Föderative Organisationen besitzen klare Strukturen und publizieren ihre Prozesse. Da Unternehmensprozesse in kleine Portionen zerlegt werden, gilt das Erfordernis der kla-

11

1 Einführung

ren Beschreibung der eigenen Geschäftstätigkeit, der eigenen Kompetenz und Erfahrung. Nur auf dieser Basis kann jedes Unternehmen schnell in weitere Prozessketten eingebunden werden. • Föderative Organisationen setzen in ihrem wirtschaftlichen Prozess auf die Werte Vertrauen, Kompetenz, Erfahrung, Fairness und Partnerschaft.

1.2 Warum wird die Technologie von Web Services und Prozessen jetzt standardisiert? Traditionell wickeln Unternehmen ihre Vorgänge weitgehend innerhalb ihrer Unternehmensgrenzen ab. Ein Geschäftsprozess beginnt und endet innerhalb des Unternehmens. Interaktionen mit der Außenwelt werden über Briefe, Telefon, Fax, E-Mail oder »Electronic Data Interchange« (EDI) ausgeführt. Nach wie vor ist an den Grenzen des Unternehmens der Mensch der entscheidende Vermittler von Informationen. Neben der zeitlichen Verzögerung erzeugt jede menschliche Intervention auch Kosten. Um an einem globalen Wertschöpfungsnetzwerk weiter teilnehmen zu können, werden – ja müssen – die Unternehmen an den Außengrenzen Maschine-zu-Maschine-Schnittstellen implementieren. Die eigenen Waren und Dienstleistungen müssen in standardisierter Form in Verzeichnisdiensten beworben werden, damit das Unternehmen weltweit elektronisch lokalisierbar ist. Wir betrachten in diesem Buch insbesondere Anwendungen, die Geschäftsprozesse über die Grenzen eines Unternehmens hinweg unterstützen, die Dienste aus verschiedenen Abteilungen eines Unternehmens oder mehrerer Unternehmen integrieren (Gaedke et al. 1999). Hierzu zählen Dienste (Services) verschiedener Anwendungen (z. B. Produktionsplanungssysteme, Bestellabwicklung, Lagerverwaltung) oder Datenbanken. Die Zusammenfassung dieser Dienste kann immer zu einem neuen Dienst führen. Das Internet wandelt sich zusehends von einem dezentralen Informationsmedium in eine Plattform für komplexe, verteilte Anwendungen. Für seine ursprüngliche Aufgabe, die Veröffentlichung von Informationen, war das Internet gut geeignet. Die inzwischen im Internet realisierten Dienste sind jedoch umfangreiche Anwendungen, besonders auch im kommerziellen Bereich. Diese Web Services sind modulare, gekapselte IT-Funktionen, die ihrerseits andere Web Services nutzen können, um genutzt durch neue Lösungen komplexe Aufgaben im Interoder Intranet auszuführen zu können. Web Services sind nichts anderes als Anwendungen, oftmals bestehende Legacy-Systeme, welche über standardisierte Interfaces von einem Client mittels einer Nachricht im SOAP-Format über HTTP, also über ein Netzwerk, angesprochen werden können. Zentrale Motivation für die Entwicklung von Web Services ist der Bedarf nach reibungslosen Informationsflüssen über technische und organisatorische Grenzen hinweg und dabei indirekt die Wiederverwendung von Anwendungen in einem Netzwerk. Die Services sollen über Netzwerkgrenzen hinweg nutzbar sein. Dem stehen heute heterogene IT-Systeme oft ohne standardisierte Schnittstellen entgegen, die meist nur mit beträchtlichem Aufwand untereinander Daten austauschen können. Die Verbreitung der Internet-Infrastruktur stellt einen ersten Schritt in die gewünschte Richtung dar. Allerdings liegt bisher der Fokus auf

12

1.3 Wie kann man Software rasch an sich ändernde Bedingungen anpassen?

der Mensch-zu-Maschine-Kommunikation über Webbrowser. Die direkte Kommunikation zwischen Maschinen ist bisher meist nur durch proprietäre und damit in der Übertragbarkeit auf andere Systeme aufwändige und unflexible Ansätze möglich. Web Services treten nun an, Standards für die Maschine-zu-Maschine-Kommunikation zu etablieren, die das Verbinden von IT-Systemen ähnlich einfach gestalten soll wie das Erstellen von Webseiten. Der breite Einsatz von Web Services hat also das Potential viele verschiedene Anwendungen (Services) auf unterschiedlichen Plattformen über IT-Netzwerke schnell und effizient zu integrieren und bei Bedarf anzupassen.

1.3 Wie kann man Software rasch an sich ändernde Bedingungen anpassen? Die Geschichte der Softwareentwicklung ist geprägt vom Bedürfnis Anwendungen rasch, kostengünstig und fehlerarm an geänderte Anforderungen anzupassen. Die Anwendungen müssen datenunabhängig sein. Die frühen Software-Anwendungen waren monolithische Codestücke mit geringer interner Strukturierung. Das erste Strukturierungsprinzip neben der Modularisierung war die Aufteilung der Anwendung in Eingabe, Verarbeitung und Ausgabe. Es gab auf der einen Seite die Infrastrukturanteile (Anmeldung, Steuerung der Abfolge, Bildschirmmasken, Datenhaltung) auf der anderen die Geschäftslogik (Algorithmen, Datenmanipulation, Plausibilitätsprüfungen, usw.). Alle Teile wurden in einem Stück Software realisiert. Jede noch so geringe Änderung des Datenschemas erforderte, dass alle Anwendungen, welche diese Daten nutzten, angepasst werden mussten. Die Einführung von Datenbankmanagementsystemen (DBMS) schaffte dafür eine Erleichterung. DBMS unterstützen nun die Definition und den gleichzeitigen Zugriff auf dieselben Daten durch mehrere Anwendungen. Änderungen am Datenschema und an den physikalischen Zugriffswegen können damit weitgehend ohne Auswirkung auf bestehende Programme durchgeführt werden. Anwendungen müssen klar strukturiert sein. Ziel einer guten Software-Architektur ist eine Trennung von Funktionen für die Benutzeroberfläche, von denen der Geschäftslogik und denen zur Speicherung von Daten. Das Model-View-Controller(MVC)-Konzept wird seit den achtziger Jahren des letzten Jahrhunderts für die Erstellung von flexiblen, grafischen Dialogfunktionen, ursprünglich bei Smalltalk, verwendet. Ziel des MVC-Konzepts ist die Zerlegung von interaktiven Anwendungen in Teilsysteme mit abgegrenzter Funktionalität und einem hohen Grad an Wiederverwendung. Das Model repräsentiert die Datenspeicherung und Wiedergewinnung. Die View übernimmt die Aufgabe Präsentation der Daten und der Controller steuert einerseits Model und View und übernimmt die Verarbeitung der Daten. Die drei Komponenten werden dabei separat behandelt und implementiert (Bild 1.1). Dies macht nicht nur die Erstellung von Anwendungen mit unterschiedlicher Darstellung (Tabelle, Detailansicht, Diagramm) auf ein und dieselben Daten, sondern auch die Lokalisierung von Fehlern leichter. Das MVC-Konzept gewährleistet, dass Änderungen im Modell zu den entsprechenden Änderungen in den Views führen. Dabei bleibt die Steuerung der Funktionen im Programm verborgen und ist nur für den Entwickler nachvollziehbar und manipulierbar.

13

1 Einführung

Bild 1.1: Evolution der Lösungsarchitektur. Die Architektur betriebswirtschaftlicher Lösungen hat in den letzten 20 Jahren eine Segmentierung erfahren durch die Einführung relationaler Datenbanken (SQL) und durch Verwendung dünner Clients (Browser für HTML oder WML). Damit wurden Model (DB), View (GUI) und Controller (Verarbeitung) entkoppelt.

Die Anwendungen müssen unabhängig vom Endgerät sein, von dem aus sie genutzt werden. Durch die Nutzung der Internetstandards und die Einführung des Browsers als universelle Benutzerschnittstelle ist Software nun weitgehend unabhängig vom Endgerät. Wenn die Anwendung zukünftig mit der Hilfe von Multidevice Frameworks auf die Unterstützung unterschiedlicher Endgeräte ausgelegt wird, funktioniert sie auch auf Mobiltelefonen, Selbstbedienungsterminals, Kühlschränken und sonstigen unterstützten Endgeräten. Die Anwendungen müssen unabhängig(er) werden vom Geschäftsprozess, den sie unterstützen. Die Steuerung der Reihenfolge, der Funktionen, Algorithmen und der Anwenderinteraktionen ist bis heute vorwiegend in der Anwendung selbst hinterlegt und mit ihr verwoben. Ob beim objektorientierten Ansatz im Controller oder bei prozeduralen Programmiersprachen in einem oder mehreren Modulen, eine Änderung in der Reihenfolge der Aktivierung von Funktionen oder der Zuordnung von Aufgaben zu Bearbeitern erfordert immer einen Eingriff in die Programmierung der Anwendung. Diese Änderungen können infolgedessen meistens nicht schnell, präzise und sicher genug durchgeführt werden. Betriebswirtschaftliche Abläufe bestehen aus einer Kette von Funktionsaufrufen und Verzweigungen an Entscheidungspunkten gemäß der im Vorfeld erzielten Ergebnisse der Funktionen. Technisch gesehen ist das ein Workflow. Was liegt nun näher als diese Ablaufsteuerung explizit zu machen, Geschäftsfunktionen zu kapseln und von der Steuerung gänzlich abzugrenzen?

14

1.3 Wie kann man Software rasch an sich ändernde Bedingungen anpassen?

Nachdem im letzten Jahrzehnt die Diskussion über den Nutzen von Workflows eher akademisch und vom Marketing getrieben war, scheint sich dieser Umstand nun zu wandeln (Brahm und Pargmann, 2003). Workflow-Management-Systeme werden entwickelt und erfolgreich eingesetzt, um die Definition und die Abarbeitung von Geschäftsprozessen zu unterstützen. Die Zielvorstellung ist, dass die Definition, die Steuerung, die Zuweisung von Aufgaben an die Bearbeiter, der Datenfluss und die Reihenfolge der Geschäftsfunktionen unabhängig von der Implementierung der Funktionen werden. Ausschließlich durch Definition sollen Änderungen am Workflow erfolgen, ohne Auswirkung auf die Funktionen. Die Anwendung wird zu einer Workflow-basierten Anwendung, die aus einem Modell des zugrunde liegenden Geschäftsprozesses und einer Menge von der Steuerung unabhängiger Funktionen besteht (Leymann und Roller, 1997). Die Möglichkeit betriebswirtschaftliche Prozesse mittels der Technologie von Workflows an sich fortwährend ändernde Rahmenbedingungen anzupassen, ohne gleichzeitig Änderungen an den Anwendungen vornehmen zu müssen, ist von der gleichen Bedeutung für IT wie die Einführung relationaler Datenbanken vor einigen Jahrzehnten. Daraus entsteht vierfacher Nutzen (Leymann und Roller, 1997): • • • •

Flexibilität, wenn sich der zugrunde liegende Geschäftsprozess ändert. Integration, auch für sonst unvereinbare Anwendungen auf getrennten Systemen. Wiederverwendung von Prozessbeschreibungen. Skalierbarkeit sowohl bei der Entwicklung als auch bei der Ausführung der Prozesse.

Die so entwickelten Prozesse bleiben nicht auf ein Unternehmen beschränkt. Die Technologie der Web Services, deren Ausführung über Prozesse gesteuert wird, ist unternehmensübergreifend angelegt (Bild 1.2). Die Technologie entspringt aus der Vision von vollständig automatisierten Produktionsabläufen quer über alle weltweit kooperierenden Unternehmen hinweg. Dieser Traum von Automatisierung enthält ein Netzwerk weltweit wirksamer, aufeinander abgestimmter Prozessschritte und den permanenten Austausch geschäftskritischer Daten zwischen allen Geschäftspartnern in Echtzeit (Ranadivé, 1999). Die Anwendungen müssen lose koppelbar, selbst beschreibend, gekapselt, in anderen Anwendungen wiederverwendbar und global standardisiert in Netzwerken nutzbar werden. Lose Kopplung bedeutet, dass zwischen den Komponenten keine Abhängigkeit besteht. Lediglich Nachrichten werden über ein Kommunikationsnetz ausgetauscht. Im Fall einer engen Kopplung nutzen die Komponenten gemeinsame Ressourcen und setzen Bedingungen hinsichtlich Betriebssystem, Datenbank, Protokoll oder Programmiersprache voraus. In den 80er Jahren war es eine Herausforderung, selbst Anwendungen auf dem gleichen Rechner miteinander kommunizieren zu lassen. Später entstanden mit DCOM, CORBA und J2EE Architekturen für Komponenten, die auf standardisierte Art und Weise von allen Anwendungen innerhalb der Architektur genutzt werden konnten. Aufgrund der Komplexität dieser Komponenten insbesondere im Bereich der Sicherheit und des Transaktionsmanagements sind die Installation und Konfiguration oft schwierig und fehleranfällig. Da die Architekturen (DCOM, CORBA, J2EE) zueinander grundsätzlich inkompatibel sind, setzen sie voraus, dass alle Knoten der verteilten Anwendung das gleiche Objektmodell – sprich DCOM, CORBA (IIOP) oder RMI – verwenden. Dies kann aber bei global verwendbaren, unternehmensübergreifenden Anwendungen nicht vorausgesetzt werden. Wei-

15

1 Einführung

Bild 1.2: Steuerung der Geschäftslogik unter Nutzung von Web Services. Im Bereich der Verarbeitung (Controller) führt eine Trennung der Geschäftslogik von dem sie steuernden Workflow zu einer weiteren Teilung der Lösungsarchitektur. Lösungsinterne, aber auch externe Geschäftsfunktionen werden von einem Workflow orchestriert. Externe Geschäftsfunktionen, welche über ein Netzwerk angesprochen werden, heißen Web Services. Workflows sind Abstraktionen, welche rasch an neue Bedürfnisse angepasst werden können.

terhin verlangen diese Protokolle, dass beide Endpunkte der Kommunikation direkt miteinander verbunden sind. Web Services bauen dagegen auf loser Kopplung. • Die Kommunikation mit Web Services basiert auf Nachrichtenaustausch. • Web Services stellen Metadaten zur Verfügung um die Struktur der ausgetauschten Nachrichten zu beschreiben. • Web Services sind unabhängige, in sich abgeschlossene, gekapselte Anwendungen, die eine genau definierte Aufgabe erfüllen. • Web Services können sowohl von menschlichen Benutzern, von Web-Anwendungen und anderen Web Services genutzt werden. • Die Standards WSDL, SOAP und UDDI bilden das Fundament der Web-Service-Architektur.

1.4 Warum ändert sich die Programmierung und was ist gut daran? Das Two Level Programing Paradigm: Bei diesem Programmiermodell besteht eine Anwendung aus Funktionen oder Komponenten und aus einem Workflow, der Beschreibung des Ablaufes. Leymann (2003) unterscheidet zwischen Programmieren im Kleinen und im Großen. • Programmieren im Kleinen bedeutet Entwicklung von Web Services oder Legacy-Systemen mit Web-Service-Schnittstellen versehen.

16

1.5 Warum braucht es föderative Systeme?

• Programmieren im Großen heißt, die automatisierbaren Teile des Geschäftsprozesses in eine formale Prozessbeschreibung umsetzen. Die Prozessbeschreibung wird in eine maschinenlesbare Sprache übersetzt, läuft dann auf einem Workflow-Management-System ab und ruft je nach Fortschritt des Prozesses die benötigten Geschäftsfunktionen (Web Services) auf. Veränderungen in der Ablaufreihenfolge des Prozesses können nun ohne Änderung der Anwendung, vielleicht sogar vom Prozessverantwortlichen selbst, ohne Entwicklerbeteiligung, durchgeführt werden könnten. Die Trennung der Steuerungslogik von den funktionalen Komponenten erhöht die Chance für eine Wiederverwendung der Komponenten. Durch die Prozessmodellierung besteht darüber hinaus die Möglichkeit, Prozessbeschreibungen von Anfang an durch Simulation zu überprüfen oder in der Form von prototypischen Lösungen die Anforderungsanalyse zu beschleunigen. Dieses neue Paradigma in der Entwicklung von Geschäftsanwendungen wird Auswirkung auf die Entwicklung von Geschäftsanwendungen haben. Dies betrifft unmittelbar das Lösungsangebot der etablierten Anbieter wie SAP oder Siebel hinsichtlich Zerteilung der Anwendungen in verschiedene Web Services und der expliziten Beschreibung von Prozessen. Was früher als Ablaufsteuerung implizit, mit verhältnismäßig geringen Möglichkeiten des Customizing aus einer Hand geliefert wurde, wird nun durch die Standardisierung und explizite Spezifikation in BPEL (Business Process Execution Language) als Prozessbeschreibung zu einem handelbaren Gut.

1.5 Warum braucht es föderative Systeme? • Kosten senken. Viele Unternehmen ziehen sich auf ihre Kernkompetenzen zurück. Geschäftsprozesse oder Teile von Geschäftsprozessen, die nicht rentabel im eigenen Haus ausgeführt werden können, werden ausgegliedert und von anderen Anbietern, Spezialisten auf diesem Gebiet, zugekauft. Um die bestehende Struktur der Prozesse im Unternehmen nicht jedes Mal radikal ändern zu müssen, müssen Funktionen und Systeme lose gekoppelt werden. Lose gekoppelte Systeme arbeiten in relativer Autonomie und kommunizieren nach dem föderativen Prinzip asynchron über Nachrichten. Die Anpassung an neue Bedingungen kann flexibel, rasch und sicher ablaufen. Die Beschleunigung und Vereinfachung von Prozessen senkt Kosten. • Flexibilität erhöhen. Kundenwünsche und Zwang zur Kostensenkung führen immer wieder dazu, dass ein interner Prozess der Leistungserbringung verändert und optimiert wird. Diese Änderungen dürfen keine Auswirkungen auf bereits etablierte verteilte Geschäftsprozesse haben. Das Verhalten des Prozesses nach außen muss gleich bleiben. • Loyalität der Kunden erhöhen. Jedes Unternehmen hat das Ziel, zu seinen Kunden eine emotionale und dauerhafte Beziehung aufzubauen, zumal sich Unternehmen in einem Käufermarkt bewegen. Es ist entscheidend für wirtschaftlichen Erfolg, die internen Abläufe des Unternehmens mit den Verhaltensweisen von Kunden zu synchronisieren. Ortsungebunden, zeitunabhängig und über ein beliebiges Medium und Gerät kann der Kunde Informationen aufnehmen und abrufen. Der Kunde trifft zu unterschiedlichen Zeitpunkten und in unterschiedlichen 17

1 Einführung

Umgebungen auf die Leistungen des Anbieters; er will sich dabei persönlich angesprochen fühlen und die gleichen, bekannten Vorgänge und Bedingungen wieder finden. • Lose koppeln. Alle Verfahren der Rationalisierung in zentralistischen Organisationen vermehren immer auch die Komplexität. Sie erweitern Abstimmungsprozesse und Kontrollprozesse, die es eigentlich zu verringern gilt. Wer enger anbindet, erhöht zwar die Schlagkraft und Reaktionszeit der Organisation, aber er erhöht auch die Wahrscheinlichkeit, dass Wirkungen aus der Umgebung oder der gebundenen Einheit direkt auf die Organisation durchschlagen. Föderativ gebundene Einheiten suchen eigenständig nach Lösungen und versetzen nicht sogleich das übergeordnete System in Unruhe. Der Trend der Unternehmen sich zunehmend von der Last allzu enger Verbindungen mit eigenen Abteilungen und Partnerunternehmen zu befreien geht einher mit dem Reifen von Technologiestandards, die dieses Bestreben auf Seite der Informationstechnologie unterstützen. Dieses Buch erklärt die Technologien. Es beschreibt die Merkmale Service-orientierter Architektur von IT-Systemen und von Web Services, gibt Antwort auf die Frage nach Web Service Security, der zukünftigen Rolle von Grid Services, föderierter Datenhaltungen, Informations- und Kommunikationsportalen und es geht ein auf die Spielregeln von Vertrauen und Kontrolle zur Stabilisierung von Organisationsformen.

18

2 Grundlagen und Anforderungen föderativer Unternehmensprozesse

Große Unternehmen und Organisationen sind über verschiedene Standorte verteilt, sie betreiben Geschäftsstellen und Filialen. Andere Unternehmen dagegen konzentrieren ihre Kernkompetenzen und gestalten in loser Partnerschaft föderative Organisationen. Bisher lokal ablaufende Geschäftsprozesse werden zu einem föderativen Unternehmensprozess integriert, der organisatorische und geographische Grenzen überschreitet. Dies hat Auswirkungen auf die Gestaltung jedes Unternehmens.

2.1 Grundlegende Konzepte Geschäftsprozesse • Ein Prozess ist die Erzeugung, Veränderung, kurz Überführung eines Objektes (z. B. eines Produktes oder einer Dienstleistung) durch Aktivitäten von Menschen oder Maschinen in Raum und Zeit mit einem vorgegebenen Ziel. • Ein Geschäftsprozess ist die Folge logisch zusammenhängender Aktivitäten zur Erstellung einer Leistung oder Veränderung eines Objektes. Das Ziel des betriebswirtschaftlichen Geschäftsprozesses ist Wertsteigerung und Wertschöpfung. Durch Geschäftsprozesse werden in Unternehmen schlicht auch Produkte erstellt. • Der Geschäftsvorfall ist eine konkrete Instanz dessen und bezieht sich auf ein oder mehrere Geschäftsobjekte (z. B. ein Vertragsdokument). Ein Geschäftsvorfall wird durch ein Ereignis (z. B. eine Bestellung) gestartet. Die im Geschäftsprozess festgelegten Aktivitäten werden anschließend bearbeitet. Geschäftsvorfälle sind z. B. der konkrete Kauf von Waren oder Dienstleistungen zwischen Geschäftspartnern. Der Geschäftsprozess besteht also aus einer Kette von Aktivitäten mit einem bestimmten Anfangs- und Endpunkt. In den Fluss der Aktivitäten sind manchmal, aber nicht notwendigerweise, Menschen eingebunden, die dabei Rollen einnehmen. Der Geschäftsprozess beinhaltet stark und schwach strukturierte Anteile. Das heißt, es gibt innerhalb von Geschäftsprozessen stark reglementierte Anteile, die eine zwingende Abfolge von Aktivitäten verlangen, aber auch Bereiche, die sich durch flexibles, spontanes Vorgehen auszeichnen, je nach der Art der zu erbringenden Leistung. Letzteres ist bei allen kreativen Formen der Leistungserstellung der Fall, wenn es z. B. darum geht ein Produkt zu erfinden, etwa eine neuartiges Triebwerk für ein Flugzeug oder eine Softwarelösung. Dabei wird das Zusammenspiel der Kräfte mehr durch gemeinsam angestrebte Ziele als durch vorgegebene Einzelschritte gesteuert.

19

2 Grundlagen und Anforderungen föderativer Unternehmensprozesse

Unternehmensprozessmodell • Die Gesamtheit der Geschäftsprozesse eines Unternehmens ergibt das Unternehmensprozessmodell. Das Unternehmensprozessmodell ist eine Repräsentation aller Prozesse, Aktivitäten, der dabei notwendigen zentralen Informationen, der Ressourcen, wie der IT-Infrastruktur und der Mitarbeiter, der Ziele und der Beschränkungen eines Unternehmens. Das Geschäftsprozessmodell umfasst die Kunden des Unternehmens, die Kernprozesse und die Unterstützungsprozesse des Unternehmens. Kunden sind die Abnehmer der Leistungen des Unternehmens. Kernprozesse sind solche, die für den Kunden Wertschöpfung erbringen. Der Kunde ist deswegen auch bereit für die durch den Kernprozess erstellten Leistungen zu bezahlen. Unterstützungsprozesse schließlich sichern das Überleben des Unternehmens und unterstützen die Kernprozesse, sind aber zur Differenzierung am Markt weniger entscheidend. Unternehmensmodelle sind wie eine Blaupause. Sie betrachten das gesamte Unternehmen und nicht nur die von der IT unterstützten Prozesse. Viele Geschäftsprozesse werden durch die IT unterstützt, manche von ihnen werden überhaupt erst durch die IT möglich. Geschäftsprozessanalyse • Ziel der Geschäftsprozessanalyse ist die Dokumentation, Reorganisation und Anpassung von Prozessen, Planung des Ressourceneinsatzes und insbesondere die Entwicklung von möglichst automatisch ausführbaren Workflows auf der Basis von Workflow-Management-Systemen. Das Ergebnis der Analyse ist ein Modell, ein Abbild des aktuellen Geschäftsprozesses. Am Beginn der Geschäftsprozessanalyse steht die Erfassung der Aktivitäten des Geschäftsprozesses. Eine Aktivität beschreibt einen durchgeführten Bearbeitungsschritt eines Geschäftsprozesses. Jede menschliche Aktivität wird von einem Benutzer in einer bestimmten Rolle durchgeführt. Automatische Aktivitäten nutzen Anwendungen wie etwa SAP R/3. Eine Rolle ist eine abstrakte Beschreibung einer Person, die die Berechtigung hat, eine Aktivität durchzuführen. Bei der Bearbeitung einer Aktivität sind Hilfsmittel erforderlich. Software wird genutzt, es werden Daten erzeugt, manipuliert oder gelesen. Tabellen und Handbücher werden zur Bearbeitung der Aktivität eingesetzt. Elemente des Prozesses sind die Datenobjekte, physisch oder elektronisch, in denen Informationen zum Geschäftsfall gehalten werden. Ebenso gehören auch, z. B. in der Produktion, die Güter selbst und Daten über diese Güter zum Prozess. Aktivitäten können also automatisch, IT-gestützt im Dialog mit einem Mitarbeiter oder auch vollständig manuell erledigt werden. Im Geschäftsprozess fließt Information von einer Aktivität zur nächsten. Der Fluss der Information erfolgt unter Nutzung von Medien. Medien sind Formen des Informationstransports zwischen Aktivitäten und zwischen Rollen (z. B. Fax, Telefon, E-Mail, Brief, EDI oder Nachrichten in einem XML-Format). Aktivitäten können hintereinander oder parallel durchgeführt werden. Sie können wiederholt in Schleifen abgearbeitet werden oder sie können den Prozess bis zum Erreichen eines Termins oder Ereignisses anhalten.

20

2.1 Grundlegende Konzepte

Das Modell der Geschäftsprozesse enthält also die Aktivitäten, die Bearbeitungsfolge der Aktivitäten, die Definition von Ereignissen, die die Durchführung der Aktivitäten beeinflussen, die Definition der Datenobjekte, die zur Abwicklung der Aktivität benötigt werden, die Identifikation von Rollen, die zur Bearbeitung von Aktivitäten benötigt werden und last but not least Qualitäts- und Performancekriterien. Business-Process-Management-Systeme Business-Process-Management-Systeme (BPMS) sind die Weiterentwicklung von Enterprise-Application-Integration(EAI)-Systemen. BPMS verbinden die Möglichkeit der Workflow-Management-Systeme, komplexe Geschäftsprozesse zu modellieren, zu visualisieren und auszuführen, mit den Integrationstechnologiefähigkeiten von EAI-Systemen. Smith und Fingar (2003) nennen es das CAD für die IT im Bereich der Betriebswirtschaft. Zur Modellierung von abgeschlossenen Geschäftsprozessen innerhalb von Unternehmen stehen Methoden und Werkzeuge zur Verfügung. Diese Modellierungsmethoden sind jedoch nur begrenzt auf unternehmensübergreifende Prozesse übertragbar. Gründe dafür sind die über mehrere Unternehmen verteilten Informationen über den Zustand des Prozesses, die eingeschränkte Kontrolle aus der Sicht des einzelnen Unternehmens über den Gesamtprozess und schließlich die große Komplexität des Prozesses als Ganzes. Obwohl ein unternehmensübergreifender Prozess meist aus wenigen lokalen Prozessen zusammengesetzt ist, erreicht in zentraler Sichtweise das Gesamtmodell aus Prozessen, Aktivitäten und Ereignissen eine nicht zu bewältigende Komplexität. Erfolgversprechender ist der Ansatz unternehmensübergreifenden Strukturen mit einer föderativen Strategie zu begegnen: Lokale Geschäftsprozesse werden in lokaler Autonomie und unter lokalen Gesichtspunkten entwickelt. Das globale Zusammenspiel wird immer auf das Notwendige beschränkt und in einer globalen Spezifikation festgelegt. Aus der Perspektive des einzelnen Unternehmens, das lediglich die Schnittstellen zu anderen Unternehmen beachten muss, nicht jedoch alle dahinter liegenden Prozesse im Einzelnen, stellt sich dann die Situation nicht mehr ganz so komplex dar. Insbesondere vermeidet das Konzept die vorherige Integration von Unternehmen auf der Ebene der Datenhaltungen, welcher meist wenig Erfolg beschieden ist. Ausführbare Prozesse – Workflows • Der Workflow beschreibt die automatisierbaren Teile der Geschäftsprozesse, die durch ein Workflow-Management-System und durch IT-Anwendungen unterstützt werden. Ein solches Modell enthält eine Beschreibung der Arbeitsabläufe (die Steuerung) und der Aktivitäten (Funktionen). Der Workflow wird vom Workflow-Management-System als Muster zur Ausführung einer konkreten Instanz eines Workflow genutzt. Diese Instanz wird durch ein Ereignis erzeugt und dann gestartet. Die Workflow Engine ist die IT-Plattform, auf der die ausführbaren Prozesse (Workflows), die in einer bestimmten Sprache beschrieben sind, ablaufen und über welche die im Workflow definierten Aktivitäten gestartet werden. Die Workflow Engine ist eine Komponente eines Workflow-Management-Systems, welche neben den Funktionen der Steuerung auch die der Überwachung von Prozessen übernimmt. Workflow-Management-Systeme sind Middleware-Produkte, die das Zusammenwirken von Personen, Rollen und Anwendungen unterstützen, indem sie Aktivitäten auf Maschi21

2 Grundlagen und Anforderungen föderativer Unternehmensprozesse

nen oder Mitarbeiter verteilen, die Bearbeitung koordinieren, die Ausführung kontrollieren und entsprechend des Workflow-Modells den Ablauf der einzelnen Aktivitäten steuern, geeignete Werkzeuge bereitstellen und benötigte Daten in der Form von Nachrichten transportieren. Eine solche Architektur zielt auf Wiederverwendung und leichte Modifizierbarkeit ab: Das System wird als eine Reihe von Transformationen von aufeinander folgenden Eingabeströmen gesehen. Daten gelangen ins System, wandern Komponente für Komponente durch das System, werden dabei manipuliert und am Ende auf einem Ausgabestrom oder einem anderen Medium bereitgestellt. Die funktionellen Komponenten sind weitgehend voneinander unabhängig agierende Programme und diese arbeiten nacheinander. Eine Komponente beendet ihre Aufgabe, und erst dann beginnt die nächste in der Abarbeitungsreihenfolge. Dieser Stil stammt aus dem klassischen Datenverarbeitungsbereich und ist seit vielen Jahren unter dem Begriff Vorgangssteuerung bekannt. Generelles Ziel ist somit die Wiederverwendung der eher statischen funktionellen Komponenten und die Möglichkeit der einfachen Änderung dynamischer Anteile in der Gestalt von separierten Programmteilen, den Workflows. Workflow-Typen Workflow-Anwendungen können in Form von Typen unterschieden werden: • Productive Workflow: Ein sich häufig wiederholender, strukturierter aber individueller Vorgang, die Kernkompetenz fördernd. Die Koordination der Aktivitäten kann automatisiert werden. Wertschöpfung erbringt das Unternehmen primär durch Productive Workflows (z. B. Auftragsabwicklung) (vgl. Leymann und Roller, 2000). • Collaborative Workflow: Komplexer, aber nur gering strukturierter Vorgang unter Einsatz unterschiedlicher Werkzeuge mit starkem Beitrag zur Wertschöpfung (z. B. Entwicklung von Software oder einer Turbine, Erstellung technischer Dokumentation). • Administrative Workflow: Ein sich häufig wiederholender und strukturierter Vorgang. Die Koordination der Aktivitäten kann automatisiert werden. Der Beitrag zur Wertschöpfung ist gering (z. B. Reiseabrechnung, Bestellung von Arbeitsmitteln). • Ad-hoc-Workflow: Vorgang ohne festgelegten Informationsfluss zwischen Bearbeitern. Die Koordination von Aktivitäten ist nicht automatisiert, sondern von Menschen gesteuert (z. B. Informationsweiterleitung per E-Mail).

2.2 Anforderungen föderativer Unternehmensprozesse an die IT • Föderative Unternehmensprozesse sind Geschäftsprozesse, die über unterschiedliche, autonome Organisationen verteilt sind. Sie wirken End-to-End aufeinander, d.h. von einem Punkt in einem Wertschöpfungsnetz auf einen beliebigen anderen und dessen Prozess. Föderative Unternehmensprozesse führen zu Beschleunigung der Entwicklung, Produktion und Markteinführung von Waren und Dienstleistungen, zur Senkung von Kosten durch Konzentration der Partner auf ihre Kernkompetenzen und zu erhöhter Flexibilität in der Gestaltung und Anpassung der unternehmensinternen Prozesse. Durch diese Eigenschaften ergeben sich einerseits Anforderungen an die eingesetzte Informationstechnologie. Das Zusammenwirken von Unternehmen unterliegt andererseits ver-

22

2.2 Anforderungen föderativer Unternehmensprozesse an die IT

traglichen Regelungen, welche zunächst vereinbart werden und sich dann unmittelbar auf die Art der Zusammenarbeit in korrespondierenden Prozessen auswirken. Die Abmachung, gemeinsame Betreuung und Optimierung der Vorgehensweisen zwischen Partnern führt zu umfangreichen und vielfältigen Kommunikationsprozessen. Unternehmen befinden sich in einem ständigen Informationsaustausch. Manchmal werden dazu übergreifend agierende Teams gegründet, welche eine bestimmte Aufgabe, etwa die Suche nach einem besseren Prozess, lösen sollen. Sollen die Prozesse von Unternehmen aufeinander abgestimmt werden, etwa um Kosten für die Lagerhaltung einzusparen, so ist die Vereinbarung der Prozesse selbst der Gegenstand von Verhandlungen. Dazu ist eine gemeinsame, möglichst standardisierte Sprache zur Beschreibung der Prozesse notwendig. Und das entsprechende Modell kann als Teil von Verträgen fungieren. Die Gestaltung föderativer Unternehmensprozesse verlangt nicht nur nach einer allgemein akzeptierten Modellierungssprache mit eindeutiger Semantik, sie verlangt auch nach Weiterverwendung des Ergebnisses der Modellierung in Entwicklungs- und Produktivsystemen. Für die Beschreibung automatisierbarer Prozesse bieten sich überwiegend grafische Darstellungsformen an. Die Werkzeuge zur Modellierung sind verfügbar. Die Business Process Execution Language (BPEL) zur Notation der ausführbaren Workflows ist standardisiert. Die damit erstellten Prozessmodelle können unmittelbar mit Unterstützung durch ein Workflow-Management-System ausgeführt werden, wenn die Geschäftsfunktionen (und Services) bereits implementiert sind. Ein wesentliches Merkmal von unternehmerischem Handeln ist die freie Gestaltung des Vorgehens und damit die Autonomie über die eigenen Prozesse und Daten. Das heißt im vorliegenden Kontext vor allem die Freiheit zu haben, die internen Prozesse jederzeit zu verbessern und an neue Gegebenheiten anzupassen, ohne aus dem Verbund der föderativen Organisation zu fallen. Unternehmensübergreifende Prozesse entstehen aus der Komposition unternehmensspezifischer Geschäftsprozesse. Daher muss der lokale Geschäftsprozess geeignete externe Schnittstellen bereitstellen um mit anderen lokalen Geschäftsprozessen anderer Organisationen zu kommunizieren. Wenn ein Unternehmen das Prozessmodell seiner Prozesse in BPEL veröffentlicht, legt es damit fest, in welcher Reihenfolge es Nachrichten mit Partnern austauschen möchte. Es teilt mit, welche Aktivitäten und Services es anbietet und selbst zu verwenden beabsichtigt, um ein Geschäftsziel zu erreichen (Leymann, 2003). Die öffentliche Sicht des Prozesses ist von der internen zu unterscheiden. Die interne Sicht umfasst alle Details, die zur unternehmensinternen Ausführung des Prozesses notwendig sind, und entspricht häufig dem Workflow. Insbesondere enthält eine interne Prozessdarstellung alle für die Ausführung notwendigen Variablen, also den Zustand einer Prozessinstanz. Ein intelligenter Kernprozess ist ein entscheidender Wettbewerbsvorteil und damit immer ein Betriebsgeheimnis. Die Offenlegung gegenüber der Konkurrenz ist nicht akzeptabel. Deswegen müssen und können auch einzelne Teile eines Prozessablaufs gegenüber der Sicht von außen, der eines Geschäftspartners, verborgen gehalten werden.

23

2 Grundlagen und Anforderungen föderativer Unternehmensprozesse

Integration föderativer Unternehmen durch die Web-Service-Technologie Die Idee der Web Services basiert auf der Wiederverwendung von existierender Software in einem Netzwerk über eine Verbesserung der Integrationstechnologie. Dabei besteht ein Web Service aus einer relativ autonomen Anwendungskomponente für eine abgegrenzte Funktion, die über ein Netzwerk angesprochen werden kann. Web Services selbst sind in der Lage wieder mit anderen Web Services zu kommunizieren. Insbesondere haben Web Services ihr eigenes Datenmanagement. So lassen sich komplexe Anwendungen aus verschiedenen Services zusammenbauen. Web Services sind ein Mittel der Integration und der Wiederverwendung zugleich. Betriebswirtschaftliche Funktionen, Anwendungen, Prozesse oder Komponenten liegen in unserer Vision künftig in Gestalt von Web Services vor. Ihre Schnittstellen sind über einen einheitlichen Standard (WSDL) beschrieben und können über ein einheitliches Nachrichtenformat (SOAP) aktiviert werden. Ein Web Service kann intern als ein Workflow implementiert sein, welcher von außen über die WSDL-Schnittstelle bzw. SOAP angestoßen wird. Wir sind sicher, dass föderative Unternehmensprozesse technologisch durch den Einsatz von Workflow-Management-Systemen und Web Services gestaltet werden können. Die Darstellung und Beurteilung der Technologie von Services erfolgt im Kapitel 4, die der Workflow-Technologie in Kapitel 5 und die von Web Services im Kapitel 6. Umgang mit großen Datenmengen Ein wesentlicher Aspekt betriebswirtschaftlicher Systeme ist die Verwaltung von umfangreichen Datenbeständen. In den Datenbanken steckt das Vermögen von Unternehmen. Ein Zugriff von außen muss aus Gründen der Verfügbarkeit und der Informationssicherheit tunlichst unterbunden werden. Konflikte bei Transaktionen von Komponenten auf stark vernetzten Datenbanken sollen vermieden werden. Mit der besonderen Problematik der in betriebswirtschaftlichen Anwendungen üblichen gemeinsamen Nutzung gemeinsamer Daten befassen sich Kapitel 4 und Kapitel 9. Sicherheit Sicherheit spielt bei Geschäftsanwendungen die zentrale Rolle. Wie man Sicherheit bei Web-Service-Anwendungen realisiert, hängt vom Zugang ab. Dienste, die nur im Intranet zugänglich sind, werden durch die unternehmenseigene Firewall vor Zugriffen von außen geschützt. Bei Verwendung des Internets als Transportinfrastruktur können Nachrichten jedoch potentiell von anderen gelesen, verändert oder fälschlicherweise erzeugt werden. Insgesamt ergeben sich die folgenden Sicherheitsanforderungen an die Kommunikation mit einer Service-Komponente (Jeckle und Zenger, 2002): • Vertraulichkeit: Eine Nachricht soll ausschließlich für den adressierten Empfänger lesbar sein. • Berechtigung: Ein Dienstnutzer muss auch zu dessen Nutzung berechtigt sein. Insbesondere soll es für einen Eindringling nicht möglich sein, eine andere Identität vorzutäuschen. • Konsistenz: Eine versandte Nachricht muss ohne Modifikationen beim Empfänger eintreffen.

24

2.2 Anforderungen föderativer Unternehmensprozesse an die IT

• Glaubwürdigkeit: Eine Nachricht muss nachprüfbar durch den vermeintlichen Sender erstellt worden sein. • Verbindlichkeit: Der Sender soll im Nachhinein die Urheberschaft einer durch ihn erstellten Nachricht nicht leugnen können. Long Transactions und asynchrone Aufrufe Alle Geschäftsprozesse zwischen Partnern sind Long Transactions (deutsch: Lange Transaktionen). Die angesprochenen Partner antworten selten sofort, sondern innerhalb einer bestimmten Frist, manchmal nach Tagen oder überhaupt nicht. Durch dieses Grundkonzept einer betriebswirtschaftlichen Architektur wird verhindert, dass sich die Partner gegenseitig blockieren. Das bedeutet auch, das auf der Seite dessen, der einen Dienst anfordert (Consumer), alle Informationen (der Kontext) beim Eintreffen der Antwort wieder bereitstehen müssen. Die Verarbeitung beim Empfänger läuft asynchron zu der des Senders der Nachricht. Dabei bedarf es erheblicher Koordinationsleistung aller beteiligten Parteien über das Gesamtergebnis der Transaktion zu informieren und jede einzelne Aktivität abzuschließen oder zurückzusetzen. Eine gewisse Konsistenz der Abläufe wird durch die Vorgabe zeitlicher Bedingungen erreicht. Werden Zeitlimits überschritten, werden spezielle Workflows aktiviert um eine Nachfrage zu starten oder den Abbruch eines Vorganges den Partnern mitzuteilen. Ein Vorteil asynchroner Verarbeitung ist, dass die Geschäftspartner nicht zu jeder Zeit verfügbar sein müssen. Die erneuten Versuche, Nachrichten zu übermitteln, startet das System vollautomatisch. Informationsintegration in Portalen In föderativen Organisationen bieten Portale die Möglichkeit Inhalt, Anwendungen und den Workflow innerhalb des Unternehmens und unternehmensübergreifend auf der Oberfläche eines Browsers für Mitarbeiter, Partner und Kunden zu integrieren. Die Nutzer brauchen sich über ein Single Sign-on (SSO) nur einmal am Portal-Server anmelden. So erhalten sie zu allen benötigten Informationen von einer einzigen Website aus Zugang, quasi wie beim Durchschreiten des Portals eines Gebäudes. Unabhängig davon, ob ein so genutzter Service im eigenen Unternehmen läuft oder über das Internet/Intranet angefordert wird, die Information ist in einem einzigen Portalfenster zusammen mit allen anderen Informationen für den Anwender nutzbar. Ein besonderer Aspekt der Nutzung von Portalen ist die Überwachung von unternehmensübergreifenden Prozessen – einem Reporting in Echtzeit – dem Business Activity Monitoring. Business Activity Monitoring wird in Kapitel 9 diskutiert. Die Integration der Kommunikation über Portale wird in Kapitel 11 erörtert. Service-Level Agreements Ein Service-Level Agreement (SLA) ist eine Rahmenvereinbarung für die Auslagerung von Aufgaben an einen Dienstleister, die im Wesentlichen Inhalt und Umfang der Dienstleistung beschreibt. SLA verpflichten den Dienstleister zur Leistungserbringung und Bereit-

25

2 Grundlagen und Anforderungen föderativer Unternehmensprozesse

stellung in festgelegtem Umfang und Qualität. SLAs können einfache IT-Dienstleistungen abdecken oder auch gesamte Prozesse (Business Process Outsourcing). Wesentliche Vereinbarungen eines SLA betreffen: • Die vereinbarte Verfügbarkeit, ausgedrückt als Verhältnis von tatsächlicher zu geforderter Verfügbarkeit des Systems, der Anwendung oder des Service in einem Zeitraum. Verfügbarkeit ist bei Web Services essentiell. • Die vereinbarte Antwortzeit, die Zeit zwischen einer Aktion des Anwenders und der Reaktion des Systems inklusive aller Bearbeitungszeiten. • Die vereinbarte Reaktionszeit, die Zeitspanne zwischen dem Eingang einer Fehlermeldung beim Auftragnehmer und einer Reaktion in definiertem Umfang. Sollte die Leistungserfüllung, gemessen am SLA, mangelhaft sein, so wird nach einem definierten Eskalationsmechanismus bis hin zu Sanktionen vorgegangen (siehe Kapitel 11).

26

3 Die Service-Blaupause eines Unternehmens

• • • • •

Wie sieht das ideale Unternehmen aus? Was ist ein E-Service? Warum kann es das ideale Unternehmen nicht geben? Welche E-Services gibt es schon? Wie bietet ein Unternehmen seine Services an?

3.1 Das ideale Unternehmen Ideale haben einen besonderen Reiz: Sie beflügeln die Phantasie, gleichwohl zeigen sie das Wesentliche. Angenehm ist, wenn die Vorstellungen wenigstens stückweise Realität werden können. Der Traum vom idealen Unternehmen umfasst eine einheitliche Plattform für alle Anwendungen und zugleich ein alles übergreifendes Datenmodell für alle Partner in einem Netzwerk von Kunden, von Zulieferern und den Mitarbeitern des Unternehmens (Bild 3.1). Beflügelt von der Vorstellung von Web Services als elektronisch konsumierbare Leistungen in einem Netzwerk ist die Sicht auf alle Leistungen eines Unternehmens in der Form von Services erwachsen. Der Begriff der E-Services schließt alle Stufen der Herstellung und des Transports von Produkten und Dienstleistungen ein. Dieser voll auf den Kunden ausgerichtete Ansatz wird als neues Paradigma für die Organisation von Unternehmen diskutiert, welche ihr Geschäft elektronisch vernetzt betreiben (Rust und Kannan, 2002). Die Bereitstellung von Waren tritt dabei in den Hintergrund. In einer derartigen Vorstellung geschieht der Zugriff auf einen E-Service immer über das Internet, sei es durch Konsumenten selbst oder durch einen Automaten (Client, Agent), der den Konsumenten vertritt. Auf der Geschäftsebene kann ein E-Service der digitale Einkauf oder der elektronisch unterstützte Service nach dem Einkauf sein. In den letzteren Bereich fallen alle Services, welche über Contact Center angeboten werden, und diese wiederum nutzen alle denkbaren Medien bei der Interaktion mit Kunden. Über das Internet werden Kunden immer stärker in den Service- und Produktionsprozess einbezogen. Dabei lernt das Unternehmen unmittelbar vom Kunden und der Kunde lernt sich selbst zu helfen. Beides spart Kosten. E-Services sind ein umfassendes, auf Kunden ausgerichtetes Konzept und schließen die internen Bereiche eines Unternehmens als Kunden mit ein. Dieses neue Paradigma wird von zwei Seiten propagiert: • Von Seiten der Technologen im Hinblick auf die Standardisierung von Web Services und Workflows sowie

27

3 Die Service-Blaupause eines Unternehmens

Bild 3.1: Das ideale Unternehmen. Die utopische Vorstellung des idealen Unternehmens basiert auf einer einzigen Datenbank mit allen Informationen, welche vom Unternehmen, seinen Partnern und seinen Kunden benötigt werden, auf einem Vorrat von Services und Portlets, welche über Netzwerk zu neuen Lösungen oder Portalen aggregiert werden können und auf unternehmensübergreifender Orchestrierung von Services durch Workflows.

• von Seiten des Produkt- und Service-Marketings als natürliche Erweiterung des E-Commerce. Großunternehmen sind durch viele einzelne Maßnahmen gewachsen, insbesondere auch, was ihre IT-Landschaft betrifft. Hier gibt es nicht nur viele Lösungen, von denen jede auf eine spezielle Leistung ausgerichtet ist, es gibt auch zahlreiche Lösungsvarianten in Verbindung mit Standardprodukten ein und desselben Produktherstellers. Betrachtet man die gesamte Wertschöpfungskette als ein virtuelles Unternehmen, so potenziert sich die Vielfalt an eingesetzten Produkten und Herstellern. Hinzu kommen die unterschiedlichen Lösungsansätze und proprietären Schnittstellen, welche einer Integration im Wege stehen. Damit wird das ideale Unternehmen zur Utopie. Im Weiteren geht es darum, die natürliche Heterogenität, sprich die Realität, zu respektieren und sich mit ihr auseinander zu setzen.

3.2 Netzwerke werden zum Eingangstor zu Unternehmen Die Vorstellung von Web Services als elektronisch konsumierbare Leistungen haben die Sicht auf die Leistungen eines Unternehmens verändert. Der Begriff E-Services umfasst nicht nur die Herstellung und Lieferung von Produkten – jegliche Leistung ist ein Service. Der Zugang zum Netz wird zur Schwelle in den Geschäftsbereich eines Unternehmens.

28

3.3 Die Blaupause eines Unternehmens

Software-Hersteller wie Microsoft sehen die Ware Software vornehmlich als einen Service, an dem Kunden teilnehmen können (Subskription). Alles zielt darauf ab, mehr über den Kunden zu lernen und darüber, wie er ein bestimmtes Produkt nutzt. Das Ziel ist Produkte zu verbessern und gleichzeitig eine enge Kundenbindung zu erzeugen. Ein E-Service wird definiert als die Bereitstellung jeder Art von Service eines Unternehmens über elektronische Netzwerke. Mit der Einführung des Konzepts E-Services ändert sich die Vorstellung von einem Produkt, das gekauft und gegebenenfalls bei Fehlerhaftigkeit zurückgegeben wird. Das Konzept der E-Services sieht stattdessen im Vordergrund eine lang anhaltende Kooperation mit dem Kunden. Mit dem Internet als brauchbares alternatives Marketing- und Geschäftsmedium verwandeln sich viele Services in E-Services. Es ist keine einfache Umwandlung. E-Services unterscheiden sich in der Substanz von traditionellen Services. Sie liegen mehr in der Hand des Kunden, enthalten mehr Self-Services (Rust und Kannan 2002). Viele Beispiele für E-Services sind uns bereits aus dem Alltag bekannt: • Der Kauf von Automobilen ist beispielsweise komplett über das Internet möglich und das bestellte Auto wird vor die Tür geliefert. Die Übertragung des Eigentums, die Garantieleistung, die Versicherung und Finanzierung werden vollständig über das Internet abgewickelt. Die Web-Site des Herstellers enthält genaue Informationen über das Fahrzeug in der Form von digitalen Bildern und Videos und ersetzt damit die Ausstellungsräume. Verkaufsverhandlungen werden durch einfachere Self-Services ersetzt, Preisvergleiche führen Agenten durch. Testfahrten und die Reparatur bleiben natürlich traditionell. • Der physikalische Anrufbeantworter in einem Telefon kann schon seit Jahren leicht durch einen Voice-Box-Service eines Telefonnetzanbieters ersetzt werden. Diese VoiceServices sind dabei auch für das Marketing nutzbar. • Es gibt Bücher, welche individuell für einen Leser zusammengestellt werden. Die Hersteller von Musikträgern überlegen, ob sie Musik auch auf der Basis von Subskriptionen vertreiben sollen, wie Fachzeitschriften oder Magazine. • Der Verkauf von Software wird zunehmend ersetzt durch die Verteilung über elektronische Netze auf Subskriptionsbasis. Microsoft ist dabei, sein Businessmodell völlig neu zu gestalten und alle Upgrades ihrer Software durch turnusmäßige Gebühren entgelten zu lassen.

3.3 Die Blaupause eines Unternehmens Heute werden Geschäftsbeziehungen nicht mehr in gleicher Weise als dauerhaft angesehen wie bisher. Daher wächst die Chance neue Geschäftsbeziehungen einzugehen mit der Art, wie Sie Ihre Leistung im Markt präsentieren. Quasi als Ergebnis des Re-Engineering ihrer Prozesse publizieren Sie mögliche Leistungen als Blaupause des Unternehmens. Hinter den Blöcken (z. B. Create Purchase Order) einer derartigen Blaupause verbergen sich die Unternehmensfunktionen in der Form miteinander vernetzter Teilprozesse, welche bei der Erbringung der angebotenen Leistungen durchlaufen werden (Bild 3.2). Die Blaupause ist wie das Aushängeschild eines Unternehmens. Sie ist der Zugang zu den veröffentlichten Prozessabläufen und zeigt einem Kunden, nach welchem Schema der Part29

3 Die Service-Blaupause eines Unternehmens

Bild 3.2: Blaupause eines Service-Angebots (nach Microsoft). Nach den Vorstellungen von Microsoft werden Unternehmen künftig ihre Dienste in Form einer Blaupause anbieten. Hinter diesen Dienstleistungsangeboten verbergen sich technische Services und miteinander vernetzte Prozesse. Diese werden vom Unternehmen erbracht und können von den externen Geschäftspartnern genutzt werden.

ner die Leistung erbringt und wie der Kunde vorzugehen hat, um eine bestimmte Leistung zu nutzen. Sie beeinflusst das Denken der Partner über das dargestellte Unternehmen. Sie ist das generelle und spezifische Angebot des Unternehmens. Sie zeigt, wem die definierten Prozesse und Sub-Prozesse gehören, also wer für den Betrieb der elektronisch genutzten Services verantwortlich ist. Alle großen Funktionsbereiche können weiter untergliedert werden, bis eine ganze Palette von Unternehmensleistungen entsteht. Ein Unternehmen, welches sich in der Organisation an seinen Prozessen ausrichtet, d.h. die Verantwortung für Prozesse als Fokus für Zusammenarbeit sieht, wird auch seine künftige IT-Architektur entsprechend gestalten. Die Merkmale dieser neuen prozessorientierten Architektur für Services sind: • Alle Anwendungen sind zuforderst Prozessabläufe. • Alle Prozesse sind leicht anpassbar. • Alle Prozesse werden von Anfang an inkrementell entwickelt. Als technische Prinzipien der Entwicklung gelten: • Das Prinzip der expliziten Steuerung (Orchestrierung) von kleinen Funktionskomponenten (Services). • Das Prinzip der losen Kopplung mit den Anwendungen der Partnerunternehmen. Dies gilt im Hinblick auf den Wunsch nach Autonomie und der dabei gewonnenen Robustheit innerhalb eines Netzwerkes der Wertschöpfung. • Das Prinzip der Integration eigener und fremder Anwendungen (Services) allein über den Austausch von Nachrichten. • Das Prinzip der Modularisierung von Funktionen (Services) in hoher Granularität, um ein hohes Maß an Wiederverwendbarkeit zu erreichen.

30

3.4 Die Systemarchitektur eines Unternehmens

3.4 Die Systemarchitektur eines Unternehmens Die Konzentration von Unternehmen auf viel beschworene Kernkompetenzen ist weltweit im Gange. Ein Beispiel ist die Herstellung von Flatscreens, die fast nur noch von einem einzigen Unternehmen weltweit produziert werden. Dieser Trend setzt sich dann fort, wenn das Vertrauen unter den Unternehmen weiter zunimmt und das Zusammenspiel ihrer Prozesse von einer höheren Warte aus gesteuert wird. Es entstehen föderative Unternehmen. Um dieses föderative Verhalten zu ermöglichen, muss auch die technische Infrastruktur der Unternehmen darauf ausgerichtet werden. Nur dann kann der Nutzen aus den neuen Netzen der Wertschöpfung gezogen werden. Wahrscheinlich wird dieses neue Beziehungsgeflecht zur Norm und nicht mehr nur die Ausnahme sein. Folgt man diesem neuen Trend zum Outsourcing von Services im Bereich der Verwaltung oder gar der Idee der »Dritten Revolution der Wertschöpfung« (Fink, Köhler und Scholtissek, 2004), so ist eine veränderte Systemarchitektur die Grundlage dazu. Das Integrationspotential einer solchen IT-Infrastruktur liegt auf verschiedenen Ebenen: • Integration von Informationen Dabei handelt es sich um Informationen sowohl innerhalb als auch außerhalb einer Unternehmung. Wegen des Scheiterns von zentralen Ansätzen bei Datenbanken geht es hier um den periodischen Abgleich der unter den Partnern verteilten und von ihnen verantworteten Daten. • Web Services und Portlets Web Services und Portlets sind Anwendungen, welche durch ihre einheitliche Technologie leicht zu neuen Geschäftslösungen aggregiert werden können. Portlets sind spezielle Anwendungen für den Aufbau von individuell auf die Bedürfnisse zugeschnittenen Portalen. Alle so geschaffenen Bausteine in ein Netzwerk dienen der Wiederverwendung, nicht zuletzt der konkreten Leistungen (Produktion und Service) von Unternehmen. • End-to-End-Prozesse Prozesse dienen der Verknüpfung (Orchestrierung) der Services innerhalb und außerhalb einer Unternehmung. Sie sind das Instrument, mit dem ein Unternehmen festlegt, wie es seine Leistung erbringt, wie es im Unternehmen und mit seinen Partnern und Kunden zusammenarbeitet. • E-Service-Strategie Dies ist die Summe aller Leistungen, welche ein Unternehmen seinen Kunden über elektronische Medien anbietet. Die dazu angefertigte Blaupause ist gleichzeitig eine Niederschrift des Unternehmenszweckes unter einem funktionalen Blickwinkel. Die elektronischen Services des künftigen Unternehmens sind von außen gesehen Web Services. Diese werden on Demand zur Verfügung stehen und sie selbst werden irgendwo in einem weltweiten Grid ausgeführt werden. Die Vorstellung von dezidierten Servern für dezidierte Lösungen verblasst.

31

4 Service-orientierte Architekturen

• • • • • • • • • • • •

Wie werden Anwendungen und Systeme heute strukturiert? Was ist Abstraktion bei Software und welche Vorteile hat sie? Was ist Middleware und was ist ein Server? In welchen Anwendungsbereichen nützt objektorientiertes Vorgehen? Welche Probleme entstehen bei der Zuordnung von Daten zu Funktionen? Warum sind Workflows eine Abstraktion? Welche Erwartungen erwachsen aus dem Konzept von Services? Wie ist eine Service-orientierte Anwendung aufgebaut? Warum ist die Trennung von Workflow und Funktionen sinnvoll? Was ist ein Service-Bus? Was ist Late Binding? Welche technischen Vorteile hat asynchrone Kopplung?

4.1 Strukturierung durch Server In den 80er Jahren des vergangenen Jahrhunderts begann der Siegeszug der Client-ServerTechnologie. Sie bedeutete eine Aufteilung von Anwendungen in präsentationsnahe Teile auf Workstations und Verarbeitungsteile auf zentrale Server. Konform dieser technischen Aufteilung der Verantwortlichkeiten verschiedener Rechner war in den 90ern viel von dem organisatorischen Prinzip der Subsidiarität zu hören. Subsidiarität ist die Verlagerung der Zuständigkeiten in der Organisation an die Stellen mit der höchsten Kompetenz und Effektivität. Ein technisches Prinzip wurde somit sinngemäß auf die Organisation übertragen. Vielleicht war es aber auch umgekehrt und die Technik folgte den neuen organisatorischen Vorstellungen. Auch SAP mit R/3 folgte diesem Paradigmenwechsel. Ab Mitte der 90er Jahre gesellte sich eine weitere Gliederung der Architektur in eine für die Geschäftslogik und eine für Datenbanken hinzu. Möglich wurde dies durch eine Steigerung in der Leistung von Netzverbindungen (LAN). Man spricht daher von 3-Tier-Architekturen. Die Trennung der Datenhaltung von der Geschäftslogik ist allerdings auch ohne den Datenverkehr über ein LAN sinnvoll. Mit dem Erfolg von Browsern begann dann eine Rückverlagerung der präsentationsnahen Teile einer Anwendung in den Bereich der Server. Es entstanden 4-Tier-Architekturen. Die Rückverlagerung der Präsentationslogik in einen zentralen Server, der einen Browser versorgt, hatte folgende Ursachen: • Die notwendigen Applets wurden zu groß; dadurch kam es zu einer hohen Netzlast und zu Wartezeiten.

32

4.1 Strukturierung durch Server

Bild 4.1: Zonen von Consumer und Server. Die Gruppierung von Servern in Zonen folgt den Anforderungen nach Sicherheit und Performanz. Die Zonen enthalten die Kernkomponenten für Informations- oder Kommunikationsportale, für integrierte Geschäftslösungen unter Nutzung vorhandener Services über das Netz, für datenbanknahe Lösungen und für den Zugriff auf die Daten selbst. Die ConsumerZone spricht die Lösungen über Endgeräte oder über entfernte Computer automatisch an.

• Die Ablaufumgebung auf den Clients war zu heterogen (Java-Versionen, Browser-Versionen, etc.). Die Aufbereitung der Webseiten geschieht seither durch Skripts wie Java Server Pages (JSP) bzw. Active Server Pages (ASP) auf dem Web Server. Diese Skripting-Technologie war zwar nützlich, hat jedoch auch negative Auswirkungen auf die Klarheit der Lösungsarchitektur. Seit dem Erscheinen von Web Services wird der automatische Client auch Consumer genannt. Neben dem Zugang für Menschen über einen Browser gibt es jetzt auch selbstständige Rechner, welche Services (Anwendungen) einer Suite vollautomatisch nutzen. Eine Gesamtsicht auf die Zonen einer aktuellen Systemarchitektur zeigt Bild 4.1. Jede Zone stellt jeder anderen Zone ihre Services zur Verfügung. Jede Anwendung kann dabei auf einzelne Zonen aufgeteilt werden. Die Services werden für verschiedene Serverplattformen entwickelt, sind interoperabel, jedoch nicht notwendigerweise portabel. Die Segmentierung einer Anwendung und die Verteilung derer Services geschieht unter den Gesichtpunkten • Performanz, • Wiederverwendbarkeit (Schnittstellen),

33

4 Service-orientierte Architekturen

• Ausfallsicherheit von Services (Ausfälle einzelner Services führen nicht zum Ausfall der kompletten Anwendung), • Wartbarkeit und • Spezialisierung von Produktangeboten (Web Server, Portal Server). Die Konzentration von Funktionen auf ganz bestimmte Server erfolgt auch aus Gründen der Sicherheit. Sie erlaubt den Schutz von Zonen durch Firewalls. Dies sind Vorrechner, welche jede Nachricht untersuchen und dem Sender den Übertritt in die Zone erlauben oder zurückweisen. Performanz ist ein weiteres wichtiges Kriterium um Funktionen zusammen auf einen Server zu legen. So werden Daten, welche schnell an einen Benutzer gesendet werden müssen, in der Nähe des Netzwerks gehalten.

4.2 Strukturierung von Lösungen durch Abstraktionsschichten Neben der besprochenen Verteilung von Anwendungen in verschiedene Zonen gibt es seit langem das Prinzip der Schichtung von Anwendungen durch die Abstraktion vom Detail (Parnas, 1972). Höheren Schichten einer Anwendung werden dabei die Services darunter liegender Schichten über vereinbarte Schnittstellen angeboten. Damit ist die Implementierung der Details der Services (früher: Module) bis zu einem gewissen Grad ohne Einfluss auf die sie nutzenden Consumer. Die Anwendungen werden dadurch wartbarer, zumindest solange die vereinbarten Schnittstellen beibehalten werden. Man spricht dabei auch von Verträgen, Contracts, zwischen einem Service und dessen Consumer. Das Prinzip der Modularisierung kann sich über mehrere Ebenen erstrecken. Die so entstehende Schichtung, das Layering, von Systemen wurde beim Design des OS/360 von IBM verwendet. Der oberste und abstrakteste Layer war dabei der für die Anwenderprogramme. Allerdings hat sich um die von Parnas vorgeschlagene Modularisierung eine Art Mystik gebildet und es wird dabei oft übersehen, dass der Programmierer bei der Implementierung eines Client nur in den wenigsten Fällen mit der einfachen Beschreibung der Schnittstelle auskommt. Dies wird bei der Integration von Legacy-Systemen ganz offensichtlich, wenn etwa ein Wrapper erfunden werden soll, welcher die wichtigsten Funktionen des Systems als neue Schnittstellen z. B. als Web Services anbieten soll. Ein Wrapper, auch Adapter genannt, ist ein Zusatz zu einer bereits vorhandenen Anwendung, welcher den Zugriff auf diese vereinfacht und welcher die für eine Integration wichtigen Funktionen bündelt. Ein bekanntes Beispiel für eine Abstraktion mit durchschlagendem Erfolg ist die Einführung von SQL für den Zugriff auf Datenbanken. Damit wurde es möglich, neue Indexe zur Steigerung der Performanz einzuführen, Datensätzen neue Attribute hinzuzufügen oder ganze Datenbankbereiche auf separate Plattenspeicher auszulagern ohne bereits bestehende Anwendungen anzutasten. Die Standardisierung von SQL bedeutete Investitionsschutz und erzeugte einen Schub in der Entwicklung neuer Anwendungen. Eine auffällige Umsetzung des Prinzips der Abstraktion ist der J2EE-Standard, welcher insbesondere die Plattform von Java-Application-Servern definiert. Aber schon bei CORBA war die Abstraktion das Hauptanliegen. Inzwischen haben sich oberhalb der Ebene der Betriebssysteme zahlreiche allgemein verwendbare Funktionen entwickelt, welche allgemein als Middleware bezeichnet werden. Beispiele sind die Funktionsangebote Application Server, Portal Server, Message Broker,

34

4.2 Strukturierung von Lösungen durch Abstraktionsschichten

Bild 4.2: Middleware für End-to-End-Geschäftslösungen. Die Wiederverwendung im Bereich der Softwareentwicklung wird durch Betriebssysteme und leistungsfähige Middleware erreicht. Teilkomponenten von Lösungen nutzen dazu (vertikal) dezidierte Server und kombinieren sie (horizontal) mit Services auf anderen Servern. Eine Geschäftslösung überdeckt grundsätzlich alle Server in einer Suite und besitzt manchmal auch eigene Teile in der Zone der Consumer. Durch die Möglichkeit einzelne Teile (Services) einer Lösung über standardisierte Protokolle (z. B. SOAP) miteinander zu verknüpfen kann eine Server Suite heterogen ausgelegt sein, z. B. gleichzeitig mit .NET-, J2EE- und Mainframe-Servern.

Contact Server oder Content Server. Die durch diese Server bereitgestellten Funktionen werden irreführend ebenfalls als Services, darum besser als Infrastruktur-Services bezeichnet. Middleware kann in zwei Kategorien unterteilt werden: • Ein Teil der angebotenen Middleware ist eine Erweiterung des Betriebssystems (z. B. J2EE). Dazu zählen z. B. Application Server, Object Request Broker oder Portal Server. • Ein anderer Teil hat Framework-Charakter, z. B. die Koppler zwischen OO-Programmierung und relationalen Datenbanken, Content Server oder Konnektoren. Eine grobe Schichtung der einzelnen Zonen zeigt Bild 4.2. Inzwischen ist das Angebot für standardisierte Middleware gewachsen. Es gibt zwei wichtige Arten von Middleware-Plattformen, solche, die nach dem J2EE-Standard und solche, die nach den Vorgaben von .NET implementiert wurden. In Verbindung mit diesen haben sich mächtige Produktangebote von Laufzeitumgebungen, Frameworks und Tools gebildet: WebSphere von IBM, die WebLogic Platform von BEA und .NET von Microsoft. Die Middleware-Angebote führen zu einer erheblichen Erleichterung für neue Lösungen oder domänenspezifische Standardlösungen (Bild 4.3).

35

4 Service-orientierte Architekturen

Bild 4.3: Chancen für individuelle Branchenlösungen. Unternehmen wie SAP mussten in der Vergangenheit notwendige »Middleware« für ihre Lösungen vorwiegend selbst einwickeln. Beispiele: ABAP-Engine, BAPI, IDOC, TREX, BWH, Dynpro. Umfangreiche IT-Plattformen von Herstellern wie IBM, Microsoft, BEA und SAP, welche zudem BPEL unterstützen, ermöglichen neue, individuelle Lösungen mit einer flexiblen Architektur ohne große Vorleistungen. Diese Vorleistung wird künftig zusätzlich über branchenspezifische Middleware erbracht.

4.3 Strukturierung durch Business-Objekte Es ist unstrittig, dass das Paradigma der Objektorientierung (OO) viel Nutzen gestiftet hat. Im Speziellen ist dies im Bereich der Simulation und Entwicklung von grafischen Benutzeroberflächen der Fall. Der Erfolg in anderen Anwendungsgebieten ist zumindest strittig. Insbesondere hat OO im Bereich kommerzieller Systeme nicht den erwarteten Erfolg gezeitigt. Die Kernfrage lautet: »Gibt es in betriebswirtschaftlichen Anwendungen überhaupt so etwas wie eine Abstraktion, welche diese für ein OO-Design geeignet macht?« Heute wird die Eignung des OO-Paradigmas zur Lösung betriebswirtschaftlicher Probleme in der IT eher kritisch gesehen, weil • ein betriebswirtschaftliches System aus einer Ansammlung von Spezialfällen besteht und • manche betriebswirtschaftliche Systeme einen hohen Vernetzungsgrad aufweisen, was zu nicht überschaubaren Objektgeflechten führt. Vordergründig ist es so, dass auch betriebswirtschaftliche Funktionen mit Daten zusammengebracht werden können und dass die so geschaffenen Objekte in ihrem Verhalten nur von den gekapselten Daten abhängen.

36

4.3 Strukturierung durch Business-Objekte

Bild 4.4: Zustandsverhalten von Objektinstanzen bei gemeinsamen Daten. Der klassische Begriff von in Objekten gekapselten Daten kann bei betriebswirtschaftlichen Anwendungen nicht durchgehalten werden. Wegen der engen Beziehung nebenläufiger Prozesse zur selben Datenbank ist das Verhalten einer Objektinstanz unbestimmt. Daher gibt es keine Business-Objekte im klassischen Sinn.

Funktionen verhalten sich entsprechend der ihnen zugeordneten Daten. In betriebswirtschaftlichen Systemen ist dies die gesamte Datenbank, welche durch eine Funktion bei Bedarf genutzt wird und welche zudem von anderen Benutzern gleichzeitig geändert wird. Deswegen ist die vom Paradigma der Objektorientierung geforderte Abgeschlossenheit eines Objekts und das daraus resultierende konsistente Verhalten nicht zu gewährleisten. Diese Abgeschlossenheit ist bestenfalls bei Datenobjekten in der Datenbank selbst gegeben, welche mit einer Objektschale versehen werden. Wird ein Objekt für die Auftragsbearbeitung angesprochen, so reagiert dies nur dann sinnvoll, wenn es von sich aus den Lagerbestand überprüft, um eine Auftragsannahme zu bestätigen oder abzulehnen. Es könnten ja sowohl Waren durch andere Bestellvorgänge entfernt oder neue Waren geliefert worden sein (Bild 4.4). Viele Objekte in betriebswirtschaftlichen Anwendungen sind nicht abgeschlossen. Ihr Verhalten hängt nicht nur von ihren eigenen Daten (Zustand genannt) ab, sondern auch indirekt vom Zustand anderer Objekte und ggf. von der ganzen Datenbank, welche gemeinsam von anderen Objekten genutzt werden. Ihr Verhalten ist nicht vorauszusehen und nicht durch ein Zustandsdiagramm beschreibbar. Sie verhalten sich nicht mehr dem OO-Paradigma entsprechend konsistent. Fielding (2000) unterstützt diese Argumentation. Eine Operation auf einem Objekt kann Operationen auf anderen Objekten zu Folge haben und diese auf weiteren. Das kann vorteilhaft sein, weil es den Zustand dort lässt, wo er wahrscheinlich up-to-date ist, aber es hat den Nachteil, dass es schwierig ist den Überblick über die Aktivitäten in einem System zu behalten.

37

4 Service-orientierte Architekturen

Die Argumentation zeigt, zu welchen Schwierigkeiten der von den OO-Advokaten, wie Booch (1995), propagierte Blick auf eine Anwendung führen kann, und dann kommt die von uns hier vorgebrachte Erschwernis durch gemeinsame Objekte in einer betriebswirtschaftlichen Anwendung hinzu, welche letztlich zu einem nicht mehr vorhersehbaren Verhalten eines Objekts führt. Lindström (1999) diskutiert den Einfluss der Objektorientierung auf die Modellierung von Unternehmen. Er fragt sich, ob die Annahme wirklich zulässig ist, dass die Realität, welche modelliert werden soll, selbst objektorientiert gesehen werden kann, und ob es nicht sogar ein Risiko wäre, die Analyse unter dem Blickwinkel des OO-Paradigmas durchzuführen. Man bekommt vielleicht nicht ein Modell der Realität, wie sie ist, sondern eines wie sie sein sollte? Ernüchtert stellt er fest, dass es immer schwer war, die OO-Methode auf die »normale« Unternehmensmodellierung anzuwenden. Wir haben mit unserer Argumentation über die Objektorientierung im Bereich betriebswirtschaftlicher Datenbanken versucht, auf Ursachen für die angesprochene Problematik hinzuweisen.

Bild 4.5: Unterschiedlich komplexe Wirkungsgefüge im Automobil und im Handel. Der Vergleich der Entwicklung betriebswirtschaftlicher Anwendungen mit dem Bau von Automobilen ist unpassend. Komplexität: Die Komponenten eines Autos sind autonom und funktional gekoppelt, die einer betriebswirtschaftlichen Anwendung hingegen vorwiegend über eine gemeinsame Datenbank. Konzeption: Autos sind Varianten immer des gleichen Konzepts; BWA nutzen zwar zunehmend die gleiche Middleware, die Prozesse selbst sind immer neu. Vielfalt: Ein individuelles Angebot an Dienstleistungen ist ein Grundbedürfnis von Kunden. Bei Autos liegt das entsprechende Bedürfnis im Komfort und der Optik.

38

4.4 Strukturierung durch Workflows

Viele Missverständnisse entstehen, wenn Konzepte aus einem technischen Bereich vorschnell in einen anderen Kontext übertragen und dort als Beispiel genutzt werden. Dies gilt umso mehr, wenn dabei Besonderheiten übersehen werden (vgl. Bild 4.5). Ein Beispiel für solche Vergleiche ist der Vergleich der Rationalisierung der Software-Entwicklung mit der im Autobau (Woods 2003a und 2003b), der einige Schwächen aufweist. Das Grundkonzept des Autos gibt es schon über 100 Jahre. In der Automobilindustrie wird immer das gleiche Produkt mit konstanten grundlegenden Eigenschaften hergestellt. Bei der Rationalisierung werden die Herstellungsabläufe verkürzt und die Komponenten permanent optimiert. Vielleicht war die einzige gravierende Innovation aber die Erfindung des Motors und der Lenkung. Bei Betrachtung von Software muss zwischen allgemein verwendbaren Produkten und Lösungen klar unterschieden werden. Zu den ersteren zählt das, was heute mit Middleware, Frameworks und Tools bezeichnet wird. Zum zweiten zählen Lösungen, welche den individuellen Bedürfnissen aus dem Geschäft eines Unternehmens und denen seiner Kunden entsprechen. Diese Welt der Problemlösungen wird anders als beim Auto ständig neu erfunden und nur Lösungen, die nicht mehr entscheidend für das Geschäft sind, werden zu einer Art Standard und können am Markt erworben werden. Carr (2003) behauptet, dass die IT kaum Einfluss auf die Wettbewerbsfähigkeiten einzelner Unternehmen hätte. Carrs richtige Annahme liegt darin, dass zwar Middleware zunehmend zu einem allgemein verfügbaren Gebrauchsgut wird, wie die als Argument genutzten Vergleiche mit der Dampfmaschine, der Eisenbahn, der Elektrizität und dem Telefon zeigen. Er vergisst aber, dass IT-Lösungen für die Kernkompetenzen eines Unternehmens immer etwas Spezielles sind. Kunden wollen das so. Die IT-Lösungen spiegeln den Ablauf des Geschäfts und es wäre schädlich, wenn ein Unternehmen den Ablauf als Standardprodukt von der Stange beziehen würde. Die Erfindung des Buchdrucks sagt schließlich auch nichts über das Genie und die Leistung eines Schriftstellers aus. Der Buchdruck dient lediglich der Vervielfältigung seines Werkes.

4.4 Strukturierung durch Workflows Was sich häufig ändert, sollte gekapselt werden (Parnas, 1972). Dies vermeidet Auswirkungen auf andere Bereiche einer Anwendung. Heute sollen Workflows dazu beitragen, dass künftige Systeme leichter geändert werden können. Mit ihnen wünscht man sich eine leichte Änderung der Abfolge einzelner Aktivitäten ohne einen Eingriff in die Funktionen selbst. Ein Workflow ist nicht in der gleichen Weise unabhängig von seiner Nutzung wie eine abgeschlossene SQL-Datenhaltung, also keine vollkommene Abstraktion. Änderungen haben durchaus Auswirkungen auf andere Teile (Daten, Zustände, Dokumente). Dennoch wird durch die vorgenommene Trennung eine Aktivität vor Änderungen im steuernden Workflow geschützt. Dies gilt umgekehrt auch für den Workflow, wenn die Funktion geändert wird. Workflows schaffen jedoch Transparenz in Anwendungssystemen und erleichtern so eine Anpassung an neue oder geänderte Geschäftsprozesse. Das Nebeneinander der unterschiedlichen Abstraktionen zeigt Bild 4.6.

39

4 Service-orientierte Architekturen

Bild 4.6: Abstraktion von Workflows und Datenbanken. Die Abstraktion wird bei Datenbanken über das Schema und den Mechanismus der Selektion von SQL erreicht. Die Abstraktion bei Workflows betrifft die verborgene Änderung von Abläufen, die Integration neuer Geschäftsfunktionen. Diese Abstraktion ist in der Regel schwächer, weil öfter auch die Geschäftsfunktionen angepasst werden müssen. Zudem erfolgt parallel zum Informationsfluss in einem Workflow auch ein solcher über eine gemeinsame Datenbank. Dies schränkt den Spielraum bei Änderungen eines Workflow ein.

Einzelne Geschäftsfunktionen werden aus dem Workflow heraus aktiviert und greifen dabei oftmals auf eine gemeinsame Datenbank in einem Unternehmen zu und antworten mit Rückgabewerten. Dann folgt der Aufruf der nächsten Funktion. Das Weitergeben von Information erfolgt dabei nicht nur über die Nachrichten im Workflow selbst, sondern auch über die gemeinsame Datenbank. Dies ist bei der Integration von Legacy-Systemen oftmals ein kritischer Punkt, da die Wirkung dieses globalen Datenbereichs schwer zu durchschauen ist und Rückwirkungen auf das Design eines Workflows hat.

4.5 Die Service-orientierte Architektur Der Begriff der Web Services hat große Aufmerksamkeit ausgelöst. Das darin verkörperte Prinzip der Integration von Anwendungen in einem Netzwerk wurde inzwischen verallgemeinert. Man spricht generell von Services. Gemeint sind autonome Code-Stücke, welche eine mit WSDL (Web Service Definition Language) beschriebenes API besitzen und die über ein beliebiges Protokoll angesprochen werden. Als Web Services werden heute nur solche Services bezeichnet, welche über HTTP mit Messages im SOAP-Format angesprochen werden. 40

4.5 Die Service-orientierte Architektur

Zu den wesentlichen Eigenschaften eines Service in einer Service-orientierten Architektur (Bild 4.7) zählen: • Die Verantwortung für die Leistung eines Service liegt außerhalb des Projekts, welches ihn für eine Lösung nutzt. Die Entwicklungsumgebung dient vornehmlich der Integration geeigneter fremder, autonomer Services. Auch die Entwicklung von Services erfolgt autonom und zunächst unabhängig von den konkreten Anforderungen des Projekts, welches ihn einsetzen will. • Teams nutzen verschiedene Technologien und Frameworks. • Ein in einem Projekt genutzter Service ist bereits zu Beginn irgendwo im Netzwerk verfügbar. Der Verantwortungsbereich für einen solchen Service liegt meist außerhalb des Projekts. Damit setzt der Einsatz seine Erreichbarkeit und seine Verfügbarkeit voraus. • Ein Service ist immer aktivierbar und hat kein Wissen über den ihn nützenden Client. Das wirft eine besondere Problematik bei Änderungen eines Service auf, welche über besondere Maßnahmen geregelt werden muss. • Eine Service-orientierte Architektur (SOA) hat folgende markante Eigenschaften: – Sie überspannt oftmals weite geografische Distanzen. – Sie enthält Bereiche mit unterschiedlichen Sicherheitsmechanismen. – Sie nutzt unterschiedliche Laufzeitsysteme.

Bild 4.7: Das Prinzip einer Service-orientierten Architektur (SOA). Ein Service ist über ein Netzwerk aktivierbar. Dazu ist das Interface eines Service mittels WSDL beschrieben. Ein Service besitzt eine autonome Verwaltung eigener Daten. Es gibt keine gemeinsame Datenbank. Die Kommunikation zwischen Services ist unabhängig von der Infrastruktur, auf denen Service und Consumer ablaufen. Die Implementierung eines Service kann frei gestaltet werden. Ein Service »gehört« im Normalfall nicht dem Nutzer. Daher sind Service-Level Agreements notwendig.

41

4 Service-orientierte Architekturen

• Ein Service in einer SOA verbirgt gegenüber dem Consumer die von ihm verwendeten Daten und die Art der Datenhaltung. • Die Kommunikation von Services basiert auf einer expliziten Übertragung von Nachrichten. Die Kommunikation erfolgt asynchron über Warteschlangen. Dies geschieht aus Gründen der Robustheit und Skalierbarkeit. Services sind lose mit dem Consumer gekoppelt. • Die Implementierung eines Service selbst ist dem Client soweit als möglich verborgen. Wenn es um das Verwalten von Dialogzuständen geht, muss entweder der Client oder der Service selbst den Zustand verwalten. • Die Kommunikation von Services wird nicht durch eine zentrale Instanz gesteuert. Dies hat Auswirkungen auf die Verteilung und Versionierung von Services und Lösungen im Netzwerk. Im Gegensatz dazu werden OO-Anwendungen immer als Einheit installiert, auch hinsichtlich ihrer verteilten Komponenten. Services für Anwendungen in einer SOA werden zeitlich vor den sie nutzenden Komponenten im Netzwerk installiert. • SOA-Anwendungen können in unterschiedlichen Laufzeitumgebungen ablaufen. Bei SOA-Anwendungen kann es zu Teilausfällen kommen, ohne dass dies den anderen Services automatisch bekannt gemacht wird. Um gegen Auswirkungen anzugehen, müssen weitere Technologien herangezogen werden, wie Transaktionen, dauerhafte Warteschlangen, redundante Verteilung von Services oder Failover. • Beim Design von Systemen mit einer SOA-Architektur muss man damit rechnen, dass die bei einem Service ankommenden Nachrichten sowohl fehlerhaft aufgebaut sind, als auch in krimineller Absicht abgeschickt wurden. Daher braucht jeder Service Technologien zum Schutz davor. • Services sind im Gegensatz zu OO-Klassen keine Abstraktion von Datenstrukturen und Funktionen unter einem eindeutigen Namen. Services senden und empfangen Nachrichten, welche einem Typenschema unterworfen sind. Allerdings kann einer Interaktion eine gewisse Reihenfolge (Constraints) abverlangt werden. Der Schwerpunkt liegt auf der Verifizierung und Validierung von Nachrichten. • Weil es unmöglich ist, bei einer Änderung im Nachrichtenschema einen Hinweis an alle zu verteilen, welche jemals einen Service genutzt haben, muss ein SOA-Design viel flexibler sein als ein OO-Design. Alles hat eben seinen Preis. • Die schillerndsten Attribute von Services sind Policy Expressions und Assertions, welche die Anlaufbedingungen von Operationen regeln. So kann ein Service in einem Prädialog bekannt geben, welche Art der Verschlüsselung er nutzt. Die asynchrone Kommunikation von Services bedarf • der Korrelation von gesendeten und empfangenen Nachrichten über Kennzeichen zur Identifikation, d.h. Antworten, die erst nach längerer Zeit eintreffen, müssen dem Prozess und den Kontext-Informationen zugeordnet werden, von denen sie ausgelöst wurden; • einer optimistischen Locking-Strategie bei Datenänderungen; Änderungen werden durchgeführt, wenn zwischenzeitlich keine Änderungen durch andere Prozesse durchgeführt wurden; • der Definition von UNDO-Prozessen (Kompensationen) für gescheiterte lange Transaktionen: Das sind Workflows, welche versuchen, Änderungen rückgängig zu machen; • eines Mechanismus zur Behandlung nicht erreichbarer Services (mobile Geräte, Systemausfälle).

42

4.5 Die Service-orientierte Architektur

Nach diesen Prinzipien entwickelte Anwendungssysteme basieren auf einer Service-orientierten Architektur (SOA). Bei einer Service-orientierten Architektur sind die autonomen Daten der genutzten Services wegen der verteilten Verantwortung zwar immer aktuell, aber der Ablauf ist zunächst weniger zu überblicken. Um diese Transparenz zu verbessern, ist die Technologie der Workflows durchaus geeignet. So gesehen ergänzen sich die an der OO-Technologie orientierten Services und Workflows auf komplementäre Weise. Erstere schaffen die Autonomie und Aktualität der Services in föderierten Systemen und letztere schaffen Transparenz in der Interoperation und den systemweiten Abgleich der verteilten Datenbestände innerhalb dieser Services. Eine Service-orientierte Architektur muss hinsichtlich ihrer Funktionen kein statisches Gebilde sein. Sie kann auch dynamisch, also ad-hoc entstehen, wenn Services zunächst gesucht und anschließend mit einem Service-Client gekoppelt werden. Dabei liegen die zu lösenden Probleme sowohl im Bereich der Terminologie, die ihre Ausdruckskraft ja nicht einbüßen soll, wie oftmals auch im Bereich der Rechtsverbindlichkeit. Im Normalfall sind vor der Nutzung von fremden Services Service-Level Agreements mit den Partnern abzuschließen. Da Services in der Regel separat entwickelt werden und auch unabhängig voneinander ablaufen, können sie ähnliche, aber zum Teil inkonsistente Daten über ein und dasselbe reale Objekt, z. B. einen bestimmten Kunden, enthalten. Es ist dann unvermeidlich, dass sich diese Daten über ein reales Objekt zeitlich parallel in einem unterschiedlichen Zustand befinden (Bild 4.8). Bei einer Integration auf Datenebene ist es mit der unabhängigen Implementierung der neuen Teilsysteme dann problematisch, wenn man versucht, unterschiedliche Technologien zu vermischen. Als großes Problem hat sich z. B. die Integration eines Legacy-Systems mit einer neuen Java-Lösung auf einem Application Server erwiesen. Obwohl bei dem Letzteren alle Daten in einer relationalen Datenbank gespeichert wurden, musste der Zugriff des Legacy-Systems ebenso über die OO-Schale gelenkt werden. Andernfalls wäre die Integrität der Daten verletzt worden. Die Synchronisation der unterschiedlichen Datenbestände über Messages ist häufig der bessere Weg, insbesondere dann, wenn nicht über alle Teillösungen frei verfügt werden kann. Wie im realen Geschäftsablauf üblich, muss festgelegt werden, wann es zweckmäßig oder notwendig ist, die Daten zu synchronisieren, um einen hinreichend konsistenten Zustand im Gesamtsystem herzustellen. Betriebswirtschaftliche Komponenten sind durch Daten vernetzt, welche sie gemeinsam nutzen, in denen sie navigieren und ändern. Um diese Abhängigkeiten zu vermindern, wurde das Konzept der Views erfunden. Komponenten können dabei die gleichen Datensätze nutzen, ohne dass eine Änderung in der Datenstruktur gleich in allen Komponenten nachvollzogen werden muss. Die Daten werden etwa um ein Feld erweitert, welches beim Lesen durch eine alte Komponente vor der Übergabe an sie »abgestreift« wird. Ebenso können neue Datentypen vor der Übergabe in das alte Format transformiert werden und umgekehrt. Diese Art der Entkopplung von Komponenten und Daten leisten normalerweise Datenbanksysteme, manchmal auch Zugriffschalen (Persistenz-Klassen) an der Schnittstelle von Objektorientierten Sprachen zu relationalen Datenbanken.

43

4 Service-orientierte Architekturen

Bild 4.8: Integration von Daten durch den Austausch von Nachrichten. Consumer und Services in einem Netzwerk nutzen Informationen aus demselben Szenario der realen Anwendungen, z. B. Informationen über ein und demselben Kunden. Damit ein effizienter und konsistenter Ablauf gewährleistet werden kann, ist es sinnvoll Daten periodisch zu synchronisieren. Es ist theoretisch ein Streitfall, ob diese Art von Daten wirklich deckungsgleich sind, da sie nur in Beziehung zu den mit ihnen verbundenen unterschiedlichen Funktionen gesehen werden können.

Views können als Mittel für Re-Integration von Datenhaltungen innerhalb enger Grenzen gesehen werden, also für Lösungen, die aus älteren Lösungen abgeleitet werden und deren Informationsstrukturen auseinander gedriftet sind. Insbesondere enthält jede Datenhaltung Zugriffsstrukturen, welche auf die Einzellösung zugeschnitten sind. Diese Strukturen wurden an den speziellen Bedürfnissen ausgerichtet. Das Service-orientierte Paradigma verzichtet aus Gründen der Performanz und der Unabhängigkeit von Entwicklungen grundsätzlich auf die Idee gemeinsamer Datenstrukturen. Dies hat die Notwendigkeit der Datensynchronisation auf der Ebene von Messages und Workflows zur Folge. 4.5.1 Zusammensetzung von Anwendungen aus Services Lösungen werden künftig eine Aggregation von Services sein. Diese Services stehen im Netzwerk eines Unternehmens und darüber hinaus zur Verfügung (Bild 4.9). Einzelne Services sind auf Servern installiert, für die sie implementiert wurden. Innerhalb der Server nutzen sie gemeinsame Middleware und deren Abstraktionsschichten. Serverübergreifend sind die Services über standardisierte Netzwerk-Protokolle aktivierbar (Woods, 2003a, 2003b). Diese Zusammenhänge sind die Basis von SOA. Konform zu den Zonen einer Server-Landschaft für die Präsentation, die Geschäftslogik und die Datenhaltung können auch Anwendungsteile als Services gestaltet und auf entsprechenden Servern installiert werden. Sie werden generell über in WSDL beschriebene Schnittstellen angesprochen. Dies gilt insbesondere, wenn sich ein Service-Consumer oder

44

4.5 Die Service-orientierte Architektur

Bild 4.9: Horizontale und vertikale Wiederverwendung durch Services und Middleware Layers. Vertikale Wiederverwendung entspricht dem Prinzip der Abstraktion von Layers, die horizontale der der Wiederverwendung von Services. Erstere kann man als homogene, letztere als heterogene Wiederverwendung bezeichnen.

Provider außerhalb einer Server-Familie befindet. Bild 4.10 zeigt eine Anwendung, welche einen Service zur Erfassung von Daten über einen Dialog besitzt und welche zur Verarbeitung dieser Daten einen weiteren Service auf einem Application Server nutzt. Dieser wiederum stützt sich auf einen externen Datenbank-Service.

Bild 4.10: Service-orientierte Anwendungsarchitektur (nach Microsoft). Die von Microsoft entwickelte Anwendungsarchitektur gliedert diese in Services für den Dialog mit dem Benutzer, zentrale über ein Netzwerk zugängliche Services und solche für die Datenspeicherung sowie für die Verbindung zu weiteren Services im Netzwerk. Komponenten können mittels Workflows zu komplexen Services aggrigiert werden. Dialogprozesse dienen dem Aufsammeln von Daten, etwa beim Füllen eines Warenkorbes, ehe sie der Verarbeitung zugeleitet werden. 45

4 Service-orientierte Architekturen

Die Gliederung moderner Anwendungen nach diesem Schema erleichtert sowohl die Anpassung einzelner Teile als auch die Wiederverwendung in neuen Lösungen. Über die notwendigen Protokolle entscheiden die Anforderungen an Performance und Sicherheit. In den einzelnen Teilen der Anwendung werden spezielle Laufzeitumgebungen genutzt, etwa für Komponenten oder Workflows. 4.5.2 Dynamische Architekturen – Late Binding von Services Die Technologie der Services ermöglicht eine neuartige Architektur mit Ad-hoc-Charakter. Der Vorstellung entsprechend publiziert ein Provider sein Service-Angebot im Internet. Dies erlaubt einem automatischen Service-Consumer die Prüfung des Angebots • bezogen auf die beabsichtigte Nutzung: Alle Provider mit einem entsprechenden Angebot werden zur weiteren Untersuchung in einer Ergebnisliste, dem Virtual Service Bus, festgehalten. • bezogen auf die gewünschten Ablaufbedingungen: z. B. alle Daten sollen verschlüsselt übertragen werden können. Die Bezahlung soll in Raten erfolgen und die Ware soll in spätestens drei Tagen geliefert werden. Der automatische gesuchte und ausgewählte Service wird temporär an den Client gebunden, die Ware wird nach der Registrierung des Kunden, Bankverbindung und Kreditprüfung ohne menschliches Zutun bestellt. Die Ware wird geliefert und die Raten werden automatisch abgebucht (Bild 4.11). Der Ad-hoc-Nutzung eines Service geht eine Suche voraus und nicht der Aufruf eines bereits bekannten Service über dessen bekanntes API (SOAP). Der automatische Nutzer sagt was er will, die Suche und Anbindung, das Late Binding, des gesuchten Service leistet ein Service Bus. Aus der Sicht des Clients sind alle gefundenen Services zunächst gleichwertig. Die Menge der gefundenen Services wird als virtueller Service bezeichnet. Der Service Bus sucht auf Grund der vom Client gesetzten Bedingungen daraus einen bestimmten Service aus. Dies geschieht vielleicht anhand von technischen Kriterien, wie der aktuellen Systembelastung oder der mittleren Reaktionszeit. Damit geht es bei einer Service-orientierten Architektur um weit mehr als das Protokoll SOAP. Es geht um eine völlig neue, sich dynamisch entwickelnde Anwendungsarchitektur. Objektorientierte Konzepte waren dynamisch im Hinblick auf ihre Daten (Create Object, Object Factory). SOA-Konzepte sind dynamisch im Hinblick auf die Funktionen selbst. Der Service Bus, inzwischen von IBM auch Enterprise Service Bus genannt, virtualisiert die bei ihm angemeldeten Services. Er optimiert einen Request entsprechend der Gesamtsituation im Netzwerk, etwa der Verfügbarkeit und Auslastung bestimmter Server. Das Konzept dynamischer Architekturen im technischen Bereich kann jedoch nicht dem Prinzip von Experiment und Auslese genügen. Die neuen Komponenten einer Architektur müssen zu den bereits vorhandenen passen. Das beginnt mit einer Abstimmung eines fremden API mit einem vorhandenen durch Transformation, geht weiter mit der Abstimmung der Protokolle und endet letztlich mit dem Problem der Semantik. Und dabei geht es nicht nur um Probleme der Taxonomie, d.h. dem menschlichen Verständnis von Begriffen an der Schnittstelle, sondern darum was das neue Programm eigentlich tut. Und das ist das essentielle Problem der Integration. Damit ist klar, dass ein derartiges automatisches Suchen und Binden ohne menschliches Zutun nur im engsten Rahmen funktionieren kann.

46

4.5 Die Service-orientierte Architektur

Bild 4.11: Virtual Service Bus (nach IBM, modifiziert). »Virtual Service Bus« ist eine Metapher für alle Services, welche nach bestimmten Kriterien automatisch gesucht wurden, anschließend einer genaueren Auslese unterworfen werden und nach entsprechender Qualifikation technisch mit dem Consumer verbunden werden, damit dieser einen automatischen Auftrag durchführen kann. Die eher theoretische Konzeption lässt die notwendige Übereinstimmung der Vorgehensweise in einem Service mit dem Consumer und insbesondere die Übereinstimmung in der betriebswirtschaftlichen Taxonomie und Semantik außer Acht. Das dynamische Binden von Services ist für fest umrissene, einfache Domänen mit einheitlicher Taxonomie hilfreich.

Das Semantische Web Das Ziel eines Semantischen Web ist die Bereitstellung von Sprachen, mit denen der Inhalt von Web-Seiten ausgedrückt werden kann, damit diese von Programmen verarbeitet werden können. Als ein generelles Defizit von Web Services wird das Fehlen jeglicher semantischer Information angesehen. Über diese Feststellung darf auch der oftmals vorgebrachte triviale Vergleich mit mathematischen Funktionsbibliotheken nicht hinwegtäuschen. Das Vorbringen von trivialen Beispielen mit wohl definierter Allerwelts-Semantik zum Nachweis des Funktionierens, ja der Allgemeingültigkeit eines technischen Prinzips, ist ein immer wiederkehrendes, ärgerliches Phänomen in der IT. Web Services ermöglichen die syntaktische Interoperabilität, nicht aber ein automatisches Verstehen der ausgetauschten Nachrichten. Dieses Fehlen einer expliziten Semantik verhindert letztlich, dass Web Services in der Weise autonom sind, dass sie ihre Nachrichten und das was sie tun gegenseitig verstehen. Daher will die Forschung zum Semantischen Web die Web-Service-Infrastruktur in der Weise bereichern, dass Web Services • über Geschäftsregeln und Beziehungen explizit Auskunft geben können,

47

4 Service-orientierte Architekturen

• eine Geschäftsfunktion (Buchbestellung, Kreditprüfung, etc.) so präsentieren, dass eine automatische Servicesuche genutzt werden kann, • die notwendige Abfolge der Nachrichten (das Protokoll) publizieren, • die Bedeutung der ausgetauschten Nachrichten so präsentieren, dass diese verstanden werden, • die Vorbedingungen für die Nutzung eines Web Service und die Effekte bei der Nutzung publizieren. Es bedarf daher für ein Semantisches Web der Entwicklung formaler Sprachen und von Terminologien, um über die Beschreibungen von Services, von Nachrichteninhalten, von Geschäftsregeln und insbesondere die Verknüpfungen von Web-Inhalten zu bewerten.

4.6 Lose gekoppelte Services Service-orientierte Architekturen basieren speziell bei der unternehmensübergreifenden Kopplung von Prozessen auf asynchroner Kommunikation. Die asynchrone Kopplung in einer Service-orientierten Architektur ist oftmals die Grundlage folgender Konzepte: • Verteilung (Brokering) und Reaktion auf Events, • intelligente Suche nach benötigenden Services, die ganz bestimmten Anforderungen genügen, • Übertragung von Nachrichten in unterschiedlichen Formaten über unterschiedliche Transportmechanismen sowie • Zwischenpufferung der Nachrichten in Warteschlangen. Das Protokoll für asynchrone Kommunikation basiert auf Mechanismen für zuverlässige Übertragung von Nachrichten, welche bei Störungen die Übertragung der Nachrichten selbständig wiederholen. Zwischengeschaltete Server halten Kopien der Nachrichten. Eine derartige Übertragung ist notwendig, wenn die angesprochenen Server überlastet oder ausgefallen sind und deshalb die Nachrichten nicht übernehmen können. Es kommt dann zwar zu Wartezeiten, nicht aber zu Datenverlust. Der größte Vorteil ist, dass alle Server auf mittleren Durchsatz, nicht aber auf Lastspitzen ausgelegt werden können. Damit wird ein Servernetz insgesamt kostengünstiger (Bild 4.12). Natürlich trifft man auch auf Geschäftbedingungen, bei denen Zeit wirklich Geld bedeutet. Etwa ist die sofortige Zustellung neuer Kurse das A und O des automatischen Börsenhandels. In diesem Fall wären Verzögerungen durch Warteschlangen geschäftsschädigend. Daher fällt auch die Art der Nachrichtenübertragung in den Bereich der Service-Level Agreements und nicht nur die Leistung der Services selbst. Werden Services synchron (in Echtzeit) angesprochen, so ist die Bearbeitung direkt abhängig von der Übertragungszeit und Zuverlässigkeit der genutzten Infrastruktur. Zudem müssen die Endpunkte der Kommunikation verfügbar sein, ansonsten bricht das Protokoll nach kurzer Zeit die Kommunikation ab, auch wenn die Funktionsfähigkeit des Übertragungsnetzwerks weiter gegeben ist. Bei asynchroner Übertragung versucht der Server, den anderen momentan nicht erreichbaren Server stunden-, ja tagelang zu kontaktieren. Die Pufferung von Nachrichten in Warteschlangen wirkt sich auch günstig auf die Skalierbarkeit der Transaktionen der verarbeitenden Anwendung aus. Die Pufferung von Nachrichten erlaubt es dem Systemarchitekten, ein System auf eine durchschnittliche Belastung

48

4.6 Lose gekoppelte Services

Bild 4.12: Robustheit und weniger Serverbedarf durch lose Kopplung (nach Kaye, modifiziert). Wo lose Kopplung von Services über Warteschlangen möglich ist, zeigen sich die folgenden Vorteile. Die Services müssen nicht ständig verfügbar sein, weil die Warteschlangenmechanismen Nachrichten autonom wiederholen. Nachrichten werden gleichmäßig an den Sender weitergegeben. Dies führt zu einer Reduktion des Leistungsbedarfs von Servern auf der Seite des Empfängers. Es gibt Fälle, bei denen dieses Prinzip aus speziellen Gründen nicht genutzt wird, z. B. bei der Verteilung von Aktienwerten über ein Brokernetz. Hier ist eine synchrone Kopplung notwendig.

hin auszulegen. Spitzenlasten werden durch Pufferung abgefangen, wenn auch unter Inkaufnahme temporär längerer Reaktionszeiten. Bei einer genauen Analyse von Auslastungskurven erkennt man immer wieder Lastspitzen, welche deutlich über dem von einem Kunden vorgegebenen Wert liegen. Asynchrone Verarbeitung sollte immer die Regel sein. Die notwendige Middleware, wie MSMQ oder MQSeries, ist seit langem erprobt und auf individuelle Bedürfnisse abstimmbar. Eine Grenze stellt die Geschwindigkeit dar, mit der Anfragen in eine Warteschlange eingefügt werden können. Deswegen ist die asynchrone Kopplung von Systemen normalerweise langsamer als die synchrone. Beim Einsatz von XML als Nachrichtenformat ist der Engpass allerdings weder der Nachrichtenpuffer noch das Netzwerk, sondern überraschenderweise die Interpretation des Formats durch den Parser. Besitzt eine Warteschlange ausreichende Kapazität, so kann ein nachgeschalteter Application Server alle SOAP-Requests auch in Spitzenzeiten abarbeiten. Ein Application Server arbeitet dann konstant mit mittlerer Leistung und ggf. einem Lastabfall in Zeiten geringerer Last. Zur Nutzung der überschüssigen Leistung wird derzeit das Grid Computing entwickelt (siehe Kapitel 7). Im Fall der asynchronen Verarbeitung bestimmt die Bereitschaft des Anwenders, in Zeiten hoher Last auf Antwort zu warten, die Höhe der Investition in die Leistungsfähigkeit des Application Servers. Im Fall der synchronen Verarbeitung ist bei hoher Last durch zu

49

4 Service-orientierte Architekturen

geringe Dimensionierung des Application Servers die Verfügbarkeit des gesamten Systems in Frage gestellt. Somit ist die asynchrone Kommunikation und Verarbeitung auf der Basis von Nachrichten und von Warteschlangen das Mittel der Wahl bei lose gekoppelten, Service-orientierten Architekturen.

50

5 Workflow-gesteuerte Services

• • • • • • • •

Wie hat sich die Software-Technologie entwickelt? Warum kam es zum Wandel von Objekten zu Komponenten und jetzt zu Services? Sind Workflows eine Alternative oder Ergänzung? Wie muss man mit redundanten Datenhaltungen umgehen? Welche Theorien stecken hinter den Workflow-Technologien? Was leistet ein Business-Process-Management-System? Wozu braucht man eine Choreographie? Wie und warum verbirgt man bestimmte Unternehmensprozesse?

5.1 Evolution der Software-Technologien Die gesamte Geschichte der Software-Technologien kreist um das Thema Wiederverwendung. Schon mit dem ersten Modul, dem ersten Unterprogramm, begann der Siegeszug der Abstraktion. Details wurden gegen andere Programmteile abgeschottet und waren veränderbar, in den meisten Fällen ohne Auswirkung auf ihre Umgebung. Sie waren für viele weitere Anwendungen wieder verwendbar. So entstanden Betriebssysteme und die heutige Middleware. Die Geschichte der IT ist eine Geschichte der Abstraktion, der Wiederverwendung und der Integration. Bei einer derartigen historischen Betrachtung ist das in den 80ern gefundene Konzept für den generellen Aufbau eines Dialogprogramms nach dem Model-, View-, und ControllerPrinzip (MVC) hilfreich. Das MVC-Prinzip hat sich insbesondere bei Anwendungen mit starker Interaktion als nützlich erwiesen. • Model repräsentiert die Daten, auf welchen eine Anwendung operiert. Die Evolution der Datenhaltungssysteme führt über Dateien zu den Codasyl-Datenbanksystemen in den 60er Jahren. Ein gewaltiger Einschnitt ergab sich mit der Umsetzung des von Codd vorgeschlagenen relationalen Modells in den 70ern. Objektorientierte Datenbanken in den 90er Jahren haben sich im Bereich betriebswirtschaftlicher Anwendungen nie durchsetzen können. Derzeit dienen föderierte Datenhaltungssysteme einer Zusammenführung des Zugriffs auf Speicher für verschiedenartige Datentypen, unter anderem von XML mit relationalen Datenhaltungen. • View ist die Präsentation der Verarbeitungsergebnisse gegenüber einem Benutzer. Die Evolution der Präsentionstechnik führt über die Mainframe-Terminals in den 70ern zum grafischen Desktop am Beginn der 80er zum Browser in der Mitte der 90er, verbunden mit dem Durchbruch des Internets. Daran anschließend entstanden Frameworks zur gleichzeitigen Unterstützung verschiedener Endgeräte insbesondere von Handhelds. In der Entwicklung sind multimodale Endgeräte, mit denen über ein GUI wie auch über gesprochene Sprache kommuniziert werden kann.

51

5 Workflow-gesteuerte Services

• Controller steuert den Ablauf mit dem Aufruf der Verarbeitungsfunktionen. Die Evolution der Controller-Technologie begann mit Prozedursprachen für Batchprozesse am Anfang der 60er. Dann wurden modale Dialoge (mit Input Prompts) in Verbindung mit Alpha-Terminals und Time Sharing Mainframes verwendet. Seit den 80ern entstand mit dem PC die ereignisgesteuerte Programmierung. Sie ist auch das Paradigma der Programmierung bei der Verwendung von Browsern am GUI. Derzeit stehen Workflows und Workflow-Systeme als Mittel zur Steuerung von Programmkomponenten im Mittelpunkt. Parallel zu diesen Merkmalen für die Konstruktion von Anwendungen verlief die Entwicklung der Technologien für die Wiederverwendung und der Systemarchitekturen. Wiederverwendung von Komponenten: Am Anfang der Wiederverwendung standen die Unterprogrammtechnik und die Bildung von Modulen als separate Übersetzungseinheiten. Mit den Konzepten der OO-Technologie entstand die Technik von Klassen mit Vererbung. Dann entstanden in den 90er Jahren Laufzeitsysteme für wieder verwendbare Komponenten. Jetzt folgen in einem Netzwerk leicht integrierbare Anwendungskomponenten, die Web Services. Ein besonderes Konzept sind dabei ad-hoc integrierbare Services. Wiederverwendbare Architekturen: Die Ära der Mainframe-Architekturen wurde mit der Einführung des PC in den 80er Jahren von den Client-Server-Systemen abgelöst. Daraus entstanden mit unterschiedlicher Middleware ausgestattete Server und die Architektur so genannte Multi-Tier-Systeme. Im Blickpunkt stehen heute die Service-orientierte Architektur und die Architektur von Grids für die Steuerung unterschiedlicher Computing-Ressourcen.

5.2 Steuerung betriebswirtschaftlicher Anwendungen durch Workflows Workflows als Technologie der Steuerung von Anwendungen sind keineswegs neu. In den einzelnen Standardlösungen von SAP ist die Steuerung der internen Verfahrensabläufe der eigentliche Wert. Diese existieren dort seit langer Zeit als explizite Tabellen der Datenbank – ein damals mutiges, aus heutiger Sicht geniales Design. Was am Thema Workflow neu ist, ist die weltweite Tendenz, künftig alle betriebswirtschaftlichen Systeme mit dieser Technologie standardisiert zu entwickeln und zu verknüpfen. Dennoch und gerade wegen der Interdependenzen in der Datenbasis betriebswirtschaftlicher Anwendungen ist die Definition funktioneller Komponenten wünschenswert. Diese ordnen die notwendigen Funktionsmengen nach betriebswirtschaftlichen und technischen Gesichtspunkten. Sie besitzen dann eine sorgsame Beschreibung ihrer Schnittstellen und der Bedingungen, unter denen sie ablaufen können. Diese Beschreibung enthält alle Hinweise, wie die einzelnen Funktionen mit ihrer gemeinsamen Datenbank umgehen. Komponenten können aus einer Kollektion von weiteren Komponenten bestehen, welche zusammen eine betriebswirtschaftliche Funktion realisieren. Aber auch hier ist eine Überschneidung mit anderen Komponenten auf Grund der gemeinsamen Datenbasis meist unvermeidlich. Die Abfolge und das Zusammenwirken von Komponenten oder Services kann über einen Workflow gesteuert werden, der selbst auf einer Workflow Engine abläuft. Dabei entsteht ein Service mit großer Flexibilität (Bild 5.1).

52

5.2 Steuerung betriebswirtschaftlicher Anwendungen durch Workflows

Bild 5.1: Interne Steuerung eines Web Service durch einen Workflow. Ein Workflow ist eine separate Programmkomponente innerhalb eines Service. Er steuert die Abfolge der Aktivitäten. Diese können als weitere Services lokal oder entfernt realisiert sein, als Worklist für einen menschlichen Agenten an einem Portal oder durch die Abfrage eines technischen Sensors. Der Workflow und der gesamte Service sind beim Ablauf immer nur einem bestimmten Consumer zugeordnet. Der Service bzw. dessen Workflow-Instanz verwaltet den Verarbeitungszustand als Grundlage für den Dialog mit dem Consumer und dem internen Informationsfluss.

Betriebswirtschaftliche Funktionen im mittleren Bereich von Bild 5.1 werden bei einem Workflow als nur geringen Veränderungen unterworfen betrachtet. Sie besitzen Schnittstellen für ihren Aufruf und zur Rückgabe von Ergebnissen. Auch diese Schnittstellen werden als wenig veränderlich angenommen. Innerhalb der jeweiligen Funktion läuft die Detailverarbeitung ab. Nun bestehen die meisten betriebswirtschaftlichen Abläufe aus einer Kette von Funktionsaufrufen und Verzweigungen gemäß den im Einzelnen erzielten Ergebnissen. Technisch gesehen ergibt sich ein Workflow. Hält man diese Abgrenzung von Funktion und Ablaufsteuerung konsequent durch und kapselt letztere, so kann man die Ablaufsteuerung ändern, ohne dass die Funktionen berührt werden. Man kann zum Beispiel die Reihenfolge von Funktionsaufrufen ändern, Aufrufe still legen, neue hinzufügen, Parameter transformieren oder Abläufe parallel ausführen ohne jeden Eingriff in die betriebswirtschaftlichen Funktionen. Bei der Anpassung an neue Anforderungen können auch auf der Ebene der Workflows Funktionen, wie z. B. die Umrechnung von Werten, eingeschleust werden. Workflow-Definitionen sind theoretisch gesehen portabel, wenn ihre Verknüpfung mit den Funktionen über eine flexible Technologie wie etwa WSDL realisiert ist. Wenn ein so gestalteter Workflow in einer neuen Umgebung wiederverwendet wird, muss nur festgelegt werden, wie die dort vorliegenden Geschäftsfunktionen mit den Aktivitäten des Workflow

53

5 Workflow-gesteuerte Services

verbunden werden. Die Funktionen müssen die gleichen Schnittstellen und prinzipiell die gleiche Funktionalität besitzen oder sie müssen teilweise dieselben Services ansprechen, welche im Netz einer Service-orientierten Architektur zur Verfügung stehen können. Ein Workflow kann Services nutzen, die wiederum Workflows enthalten. Er kann Teil eines Service sein und selbst von Services über ein Netzwerk genutzt werden. Workflows publizieren ihre Funktion über eine Service-Schale und konsumieren andere Workflows, indem sie mit deren Service-Interfaces, beschrieben in WSDL, interoperieren. Auf diese Weise entsteht eine Hierarchie flexibler Services. Die konsequente Trennung von Workflow und Funktion (bzw. Services) führt insgesamt zu einer erheblichen Steigerung der Transparenz und Wartbarkeit betriebswirtschaftlicher Anwendungen. Die Kommunikationen zwischen einzelnen Workflows bzw. Prozessen erfolgt grundsätzlich bidirektional. Der Empfänger ist dem Sender bekannt und die Reaktion wird mit dem Verursacher in Verbindung gebracht (Message Correlation). Im Gegensatz dazu steht das Message Brokering. Hier steht der Empfänger nicht fest, wie beim Rundfunk der einzelne Zuhörer dem Sender unbekannt ist. Jeder Prozess hat im Zusammenspiel mit anderen Systemkomponenten grundsätzlich eine integrierende Wirkung, wie bei den Komponenten auf einem Application Server (z. B. via IIOP), wie bei Datenbanktabellen (z. B. via ODBC), wie bei Adaptern zu Packaged Solutions (z. B. webMethods) und wie bei Message-Queue-Systemen (z. B. JMS oder MQSeries). Beim Einsatz der Workflow-Technologie in Verbindung mit bestehenden Anwendungen muss immer klar sein, welche Informationen von der existierenden Komponente implizit über eine gemeinsame Datenbank weitergereicht werden und welche über die Nachrichten des neuen Workflows. Diese bei Integrationsprojekten oftmals unüberblickbare, implizite Kommunikation ist Grund für auftretende Probleme, ja sogar für das Scheitern von Projekten. Die Problematik des verdeckten Weiterreichens von Daten über die Datenbank wird verschärft, wenn es bereits Komponenten gibt, welche selbst untergeordnete Workflows vorgeben (Bild 5.2). Auch wenn diese Abläufe bekannt sind und im Quellcode vorliegen, sind der Stabilität einer übergeordneten Workflow-Schicht Grenzen gesetzt. Entschärft wird diese Problematik, wenn diese Subkomponenten zusammen mit den Workflows an die neuen Bedürfnisse angepasst werden können. Die Problematik verschärft sich weiter, wenn es sich um ein generisches System von Komponenten handelt, das durch viele Parametereinstellungen aus einem Funktions- und Ablaufvorrat auf eine konkrete Lösung eingestellt wurde. Unter solchen Umständen ist selbst die Erstellung einer grafischen Repräsentation (Referenzmodell) für das generische Basissystem von erheblichen Schwierigkeiten begleitet. Workflow-Technologie ist ein Mittel der Abstraktion und setzt auf der Ebene der Komponenten konformes Verhalten voraus. Am besten geeignet sind kleine und überschaubare Komponenten bzw. Web Services, deren Reaktion auf Nachrichten genau bekannt sind. Trotzdem sollte man sich nicht entmutigen lassen und beim Einsatz der Workflow-Technologie gleich einige schwarze Schafe unter den Komponenten entfernen und durch weiße ersetzen. Bestimmte Komponenten mit einem unberechenbaren Verhalten müssen frühzeitig erneuert werden. Nur diese Vorgehensweise führt letztlich zu einem übersichtlichen, leicht anpassbaren Service-orientierten Gesamtsystem.

54

5.2 Steuerung betriebswirtschaftlicher Anwendungen durch Workflows

Bild 5.2: Verdeckter Informationsfluss über die gemeinsame Datenbank. Beim Hinzufügen von Workflows zu bereits bestehenden Software-Komponenten (StandardProdukten) entstehen zwei Probleme: Workflow-Aktivitäten kommunizieren nicht ausschließlich über den Austausch von Nachrichten und über ihren Zustandsbereich, sondern indirekt über die von Komponenten gemeinsam genutzte Datenbank. Existierende Komponenten werden intern selbst von Workflows gesteuert und ihr Verhalten wird vorher generiert. Deshalb liegen bei der Anpassung zwei verschiedene Toolwelten vor.

Heute wird oftmals eine Integration auf der Basis von Standardlösungen, z. B. von SAP, Siebel, PeopleSoft oder Oracle gewünscht. Diese als Best Breed bezeichneten Lösungspakete sind weit verbreitet. Aber es ist bei der Kombination dieser Standardlösungen davon auszugehen, dass ein daraus entwickeltes Gesamtsystem sehr unterschiedliche Datenbanken für ähnliche Sachverhalte enthält und dass diese Datenbanken demzufolge laufend miteinander abgeglichen werden müssen. Der Grund für die mehrfache Speicherung von Informationen ist keineswegs Willkür, sondern das Vorhandensein von Überschneidungen im Datenbereich. Eine CRM-Lösung kennt Kunden ebenso wie ein Bestellsystem. Varianten von Produkten des gleichen Lösungsherstellers können unterschiedliche Ausprägungen der Informationen über Kunden haben. Aber es handelt sich immer um den gleichen Kunden. Eigene Datenbestände sind zudem ein wichtiges Merkmal autonomer, föderativer Systeme, und das Zusammenwerfen von Datenbanken würde sowohl einen Machtverlust bei einzelnen Partnern bedeuten, als auch einen Verlust an Robustheit im gesamten Wertschöpfungsnetz. Daneben käme es zu einer nicht zu rechtfertigenden Verflachung der Semantik insgesamt, also zu einem »Kulturverfall«. Es ist schwer zu entscheiden, ob die Informationen zu einem Kunden in dem einen System wirklich denen in dem anderen entsprechen, denn der Vergleich ist ohne die Berücksichtigung der Anwendungen, die auf den jeweiligen Informationen operieren, sinnlos. Dies ist auch der wahre Grund, warum die Integration auf der Ebene der Datenbanken meistens erfolglos ist.

55

5 Workflow-gesteuerte Services

Bild 5.3: Synchronisation von Informationen in einem End-to-End-Prozess (IDS Scheer, modifiziert). Durch die Best-of-Breed-Ideologie in der Vergangenheit wurde das nützliche Kontinuum einer gemeinsamen betriebswirtschaftlichen Datenbank gesprengt. Daher bedarf es Mechanismen zur Synchronisation der verschiedenen Datenhaltungen unterschiedlicher Produkte, und dabei der Abbildung Repräsentation von Werten, der Schlüsselsysteme und der Angleichung der speziellen Semantik. Diese Synchronisation wird durch eigene Plattformen und Prozesse erbracht, welche sich aus Gründen der Wartbarkeit eines generischen zentralen Zwischen-Datenmodells und einer zweistufigen Transformation der Strukturen bedienen.

Neben den Workflows für den Ablauf des Geschäfts muss es daher immer einen Workflow für die Synchronisation der virtuellen Datenbasis geben. Wenn sich etwa die Anschrift eines bestimmten Kunden ändert, so sorgt dieser Synchronisationsprozess dafür, dass dies in allen an der Integration beteiligten Systemen bekannt wird. Synchronisation ist also eine Art expliziter Kommunikation über relevante Datenänderungen nach bestimmten Ereignissen. Somit ist die Notwendigkeit der Synchronisation von Daten der Preis für die Bildung autonomer Services, bzw. von selbständigen Standardlösungen. Diese Synchronisation rekonstruiert quasi permanent die gemeinsame Datenbasis des idealen Unternehmens (Bild 5.3). Die Integration innerhalb einer Wertschöpfungskette führt wegen eines geringeren Pflegeaufwandes auch zur Zusammenlegung der Datenhaltungen der Partner, also zum Verlust der Hoheit über die eigenen Daten bis hin zur Fremdsteuerung des Partnerunternehmens bei bestimmten Geschäftsvorfällen. Ein Hersteller von Produkten prognostiziert den Absatz und steuert damit die Aktivitäten eines Logistikunternehmens.

56

5.4 Workflow-Management-Systeme

5.3 Theoretische Grundlagen der Workflow-Technologie Von Seiten der Wissenschaft wurden verschiedene Muster zur Kontrolle des Ablaufs in einen Prozess festgestellt. Im Einzelnen ergeben sich sechs verschiedene Gruppen: • • • • • •

Basic Control Patterns Advanced Branching and Synchronization Patterns Structural Patterns Patterns Involving Multiple Instances State-based Patterns Cancellation Patterns.

In den Workflow-Systemen, die ja meist auf der Theorie der Petri-Netze beruhen, sind diese Muster vertreten. Außerdem gilt als Theorie für moderne zustandsbehaftete Systeme auch π-Calculus (Millner, 1999). Diese Theorie befasst sich mit mobilen Systemen und auch mit der temporären Nicht-Verfügbarkeit von Komponenten. In allen Workflow-Produkten werden die oben genannten Patterns unterstützt.

5.4 Workflow-Management-Systeme Workflow-Management-Systeme dienen dazu, Workflow-Definitionen auszuführen und zu überwachen. Der Ablauf der Aktivitäten in einem Workflow wird dabei beeinflusst von Systemzuständen (internen Daten und externen Nachrichten und Abfragen), Menschen und technischen Sensoren. Der Zugang zu den beiden letzten ist nicht unmittelbarer Teil der Workflow-Technologie. Die von ihnen ausgehenden Entscheidungskriterien werden implizit über unterschiedliche Anschlussmechanismen gewonnen und den Prozessvariablen zugeordnet. Bild 5.4 zeigt die Vielzahl möglicher Einflusselemente auf Entscheidungen in einem Workflow. Ein Workflow ist die dominante Steuerungslogik, also der Controller in einem Service. Daher bedarf es zur Integration menschlicher Aktivitäten einiger Kunstgriffe. Ein Workflow kann an einen User eine Mail schicken, die dieser unter Nutzung von Formularsoftware beantwortet und zurücksendet. Der Workflow verlässt daraufhin seinen Wartezustand, greift auf das ausgefüllte Dokument in einem Mail-Server zu, identifiziert und bewertet die Antwort. Mit einer anderen Technik trägt der Workflow eine Anfrage in eine Warteschlange für einen Benutzer ein, welche von diesem entweder direkt abgefragt wird, oder auf die ein Skript im Browser des Benutzers periodisch zugreift. Die Verbindung der Technologie der Telefonie mit der von Workflows geschieht indirekt beim Einschalten eines menschlichen Agenten über ein Informations- und Kommunikationsportal (siehe Bild 5.4). Bekommt ein Agent einen Hinweis auf Unregelmäßigkeiten, dann kann er je nach Anwesenheit von Kollegen spontan eine Telefonkonferenz einberufen, klärt Maßnahmen und behebt die Störung, in dem er die notwendige Entscheidung trifft.

57

5 Workflow-gesteuerte Services

Bild 5.4: Sensoren in automatischen und personenbezogenen Workflows. Workflows sind offen für alle übrigen Komponenten einer Architektur: Im Normalfall werden Aktivitäten automatisch durch die angestoßenen Web Services bearbeitet. In Ausnahmefällen können Einträge im Portal eines Agenten erscheinen, der die notwendigen Aktionen mittels der Anwendungen an seinem Arbeitsplatz erledigt oder bei Bedarf die Verbindung mit anderen Agenten aufnimmt, um einen Fall zu besprechen. Entscheidungen können nicht allein durch die Analyse von Nachrichten, Zuständen oder Datenbankinhalten getroffen werden, sondern gegebenenfalls auch durch die Abfrage technischer Sensoren.

5.5 Choreographie – der Use-Case von Workflows Eine Choreographie ist das Protokoll an den Systemgrenzen zwischen den Prozessen verschiedener Partner. Sie dokumentiert das Verhalten des Partnersystems beim Erreichen bestimmter Systemzustände, d.h. die möglichen Anfragen und die unmittelbar oder in Zukunft zu erwartenden Reaktionen (Bild 5.5). Das konforme Verhalten eines Prozesses gegenüber seinen Partnern ist der komplexeste Teil der Technologie. Es ist das Thema der Koordination langer Transaktionen und das Verhalten des Prozesses bei Aktivitäten, welche nicht erfolgreich durchgeführt werden können. Betriebswirtschaftliche Systeme sind grundsätzlich von der Art, dass Störungen schon dadurch passieren, dass Menschen Fehler machen, ein vorausschauendes Handeln nur schwer möglich ist und alles parallel abläuft und trotzdem aufeinander einwirkt. Wie das Rücksetzen der Wirkung von Aktivitäten (UNDO) in einem weiterlaufenden Gesamtsystem

58

5.5 Choreographie – der Use-Case von Workflows

Bild 5.5: Orchestrierung von externen Prozessen (nach IBM, modifiziert). Das wesentliche Prinzip von BPEL-Workflows ist das der externen Orchestrierung von Services gemäß der Vorgaben des BPEL Abstract Process. Der Abstract Prozess dient primär der Entwicklung des Consumer-Teils in Abstimmung mit den möglichen Reaktionen des Service-Providers. In vielen Fällen ist er auch ein Entwurfsmittel für den Service selbst, wenn anschließend die notwendigen Variablen (für den Zustand einer Prozessinstanz) oder sonstige Hilfsmittel wie Entscheidungsregeln hinzugefügt werden. Wie ein Service das abstrakte Protokoll erfüllt, ist grundsätzlich irrelevant. Daher können auch bestehende interne Workflows als abstrakte Prozesse publiziert und verwendet werden.

möglich ist, bedarf der eingehenden Beobachtung des Systems. Ein derartiges System ist in seine Umgebung eingebettet und grundsätzlich nicht gänzlich erfassbar. Durchgehende End-to-End-Prozesse sind eine Fiktion. Alle Unternehmen sind miteinander durch Choreographien verbunden. Diese Choreographien fordern ein standardisiertes Verhalten, auch in Gestalt eines proprietären internen Workflows. Es ist dabei nicht vorausgesetzt, dass die Implementierung eines internen Prozesses auch standardisiert ist. Diese externe Choreographie wird im Entwicklungsprozess in eine beliebige, geeignete Programmiersprache (z. B. Java oder C#/MISL) übersetzt. Datendefinitionen und interne Nachrichtenformate werden dann hinzugefügt. Das entstehende Workflow-Programm wird mittels JIT übersetzt und direkt im Maschinencode ausgeführt. Es ist ganz natürlich, dass ein Unternehmen seinen Partnern nicht alle Einzelheiten über seine Vorgehensweise offen legen will und diese kritischen Entscheidungen für interne Zwecke frei gestalten will. Hierzu werden vertrauliche Prozessschritte gekapselt, ehe ein bestimmter Prozessablauf einem externen Geschäftspartner gegenüber dargestellt wird (Bild 5.6).

59

5 Workflow-gesteuerte Services

Bild 5.6: Für Geschäftspartner verborgene Unternehmensentscheidungen. Es ist selbstverständlich, dass es nicht im Interesse von Unternehmen liegt, nur wegen der Technologie zum Leistungsaustausch mit anderen Unternehmen Informationen über ihre strategischen Entscheidungen nach außen zu tragen. BPEL sieht deswegen vor, bestimmte Entscheidungen zu abstrahieren und ohne die konkrete Logik zu publizieren. Es ist dann von außen nicht mehr zu sehen, warum der Kredit für einen bestimmten Kunden nicht gewährt wurde.

60

6 Web Services

• Was ist ein Web Service? • Was ist Interoperation? • Welche Voraussetzungen gibt es für die Nutzung von unternehmensübergreifenden Web Services? • Was sind lange Transaktionen und Kompensationen? • Was leistet WS-Security? • Was regeln BPEL- und WSDL-Standard? • Wie kann man sich einen zukünftigen Application Server vorstellen? • Wie unterstützen Produkte von IBM, Microsoft und OpenSource Web Services?

6.1 Die Idee der Web Services Hinter den Web Services verbirgt sich die schlichte Idee des Ersatzes eines Web Browsers durch einen automatischen Client. Web Services sind Anwendungen, welche über standardisierte Schnittstellen von einem Client mittels einer Nachricht im SOAP-Format über HTTP angesprochen werden können. Der über eine URI angesprochene SOAP-Server, ein erweiterer Web Server, der externe Aufrufe im SOAP-Format auf die Schnittstellen einer Programmiersprache abbildet, steht wie ein Web Server innerhalb der Firewall eines Unternehmens. Um diesen SOAP-Server anzusprechen, ist meist der Port 80 frei geschaltet, der eine SOAP-Message passieren lässt. Belange der Sicherheit auf dem SOAP-Server haben die auf dem Web Server ablaufenden Anwendungen, also die Web Services, selbst zu regeln. Das Interface eines Web Service wird mit WSDL (Web Service Description Language) beschrieben (Bild 6.1). Hinter der Fassade eines Web Service kann sich ein Programm jeder möglichen Programmiersprache und jedes Programmierstils, ein Workflow oder auch eine Legacy-Applikation, die mit einem WSDL-Wrapper angepasst wurde, verbergen. Ein WSDL-Wrapper ist ein Adapter, welcher die Legacy-Anwendung mit einem API nach dem WSDL-Standard ausstattet. Im Konzept der Service-orientierten Architekur (SOA) und des WSIF (Web Service Invocation Framework von IBM/Apache) können Services nicht nur über das SOAP-Format und HTTP angesprochen werden, sondern über jedes Format und jeden Transportmechanismus. Dies erleichtert die Nutzung von entfernten Services. Die Technologie für Implementierung von Web Services oder Services ist nicht vorgegeben. Zur Implementierung wird Technologie der Plattform genutzt, auf der die Services ablaufen, z. B. in Java auf J2EE oder in C# auf .NET. Die Services sind demnach grundsätzlich nicht portabel, außer innerhalb der jeweiligen Plattform. Sie sind wiederverwend-

61

6 Web Services

Bild 6.1: Divergierende Konzepte für die Implementierung einer Service-orientierten Architektur. Microsoft setzt auf das SOAP-Format. Neben HTTP werden auch weitere Protokolle unterstützt. IBM betrachtet Services als generelles Mittel für die Integration über alle möglichen Protokolle und Formate. Zentrales Element des IBM-Ansatzes ist WSIF (Web Service Invocation Framework). SOAP ist für IBM ein Protokoll von vielen. Jedes Protokoll, auch IIOP/CORBA, wird unterstützt. Das Gemeinsame ist WSDL (Web Service Description Language), eine Definition der Typen von Nachrichtenelementen.

bar dadurch, dass sie in einem Netzwerk von überall her aufgerufen werden können. Das verwendete Protokoll ist von den Plattformen unabhängig. Obwohl lediglich definiert ist, dass ein Web Service remote aufgerufen werden kann, folgen viele Implementierungen dem Konzept des traditionellen Remote Procedure Calls (RPC). Der RPC ist ein Protokoll, welches einem Programm auf einem Server erlaubt, Programmcode auf einem anderen Server ablaufen zu lassen, ohne dass dies explizit programmiert werden muss. Ein RPC wird vom aufrufenden Programm durch eine Nachricht mit Argumenten einer Prozedur an den entfernten Server gestartet. Beim Beenden der Prozedur wird das aufrufende Programm automatisch benachrichtigt. Bei Web Services wird eine Nachricht an einen entfernten Server übertragen. Die Nachricht ist ein XML-Text-Dokument im SOAP-Format, welches der angesprochene, entfernte Service zunächst interpretiert und in der Folge verarbeitet. Eine Antwort an den Sender wird grundsätzlich nicht voraus gesetzt. Schon deshalb liegen Web Services dem Konzept einer asynchronen Verarbeitung von Dokumenten näher als dem für synchrone Verarbeitung genutzten RPC. Bei RPC wartet der Client nach seinem Aufruf auf die Antwort.

62

6.2 Interoperation statt System-Layers

Die Spezifikation von Web Services macht grundsätzlich keine Vorschriften über die Realisierung eines Service. Ob, wann und wie der Service einen Aufrufer wiedererkennt, ist undefiniert. Ob ein Service die Daten aus vorhergehenden Dialogschritten aufbewahrt, gehört ebenso zu den speziellen Eigenschaften eines Services und ist nicht im Rahmen der Spezifikation geregelt. Die Nutzung anderer Technologien wie CORBA, J2EE oder COM+ ist Sache der Implementierung, nicht des Standards. Die Offenheit von Web Services ist eine Chance für deren Einsatz in unterschiedlichen Architekturen.

6.2 Interoperation statt System-Layers Web Services werden über das SOAP-Protokoll aufgerufen. Dieses Protokoll ist unabhängig von den Plattformen, auf denen die Web Services selbst ablaufen. Auf der Systemebene kennen sich Sender und Empfänger nicht. Diese Identifikation ist Teil der SOAP-Nachricht und wird auf der Ebene der Anwendung (des Service) ausgewertet. Die Datentypen in den ausgetauschten Nachrichten sind durch das Typenschema von WSDL festgelegt, welches häufig reichhaltiger ist als die Typen der genutzten Programmiersprachen. Mit dem Konzept der Web Services wird die Idee einer alle Plattformen übergreifenden, uniformen Service-Architektur (z. B. von CORBA), quasi die Idee der Portabilität, zugunsten der Integration von Lösungen in einem Netzwerk aufgegeben (Bild 6.2). Web Services

Bild 6.2: Paradigmenwechsel durch Fokussierung von Web Services auf die Interoperation. Verteilte Verarbeitung und Wiederverwendung wird durch Protokolle und Frameworks unterstützt und nicht mehr durch einen homogenen Layer wie bei CORBA und J2EE. Damit ist das Ziel der Portabilität von Anwendungen aufgegeben.

63

6 Web Services

regeln nur die Kommunikation, nicht aber die Architektur innerhalb der Services selbst. Das berührt auch die Programmierer, welche sich unter Umständen einer Vielzahl proprietärer Frameworks gegenüber sehen. Allerdings können Services auf vollkommen verschiedenen Plattformen ablaufen. Die Hersteller künftiger Lösungen werden es schwer haben, die Unterschiede in den Plattformen zu überbrücken. SAP entschied sich möglicherweise deswegen für die Implementierung einer eigenen Plattform, NetWeaverTM. Auch die Hersteller von Application Servern geraten mit dem Erscheinen der Web-Service-Technologie unter Druck. Während Microsoft .NET radikal unter das Paradigma von Web-Services-based stellt, müssen IBM, BEA oder IONA ihre Plattformen über den Java-Community-Prozess in Richtung von Web-Service-Application-Servern schrittweise erweitern. Im Wesentlichen geht es dabei um Funktionen zur Identifizierung von Meldungen bei asynchroner Kommunikation und um das Mapping von Nachrichten auf Objekte bei synchroner Kommunikation. Diese Thematik wird im Kapitel über BPEL-Prozesse vorgestellt. Die Integration der Web-Service-Technologie in J2EE Application Server erfolgt über eine Erweiterung der Servlet Engine des Web Servers (Bild 6.3). Ein über HTTP eingegangener SOAP-Aufruf ist zunächst ein Textdokument, welches durch einen Parser nach Parametern durchsucht und in den Funktionsaufruf einer Programmiersprache, z. B. in den einer JavaMethode umgewandelt wird. Werden dabei Komponenten angesprochen, welche auf einem J2EE Application Server laufen, so kann bei Bedarf für einen Dialog automatisch eine Zustandsverwaltung eingerichtet werden.

Bild 6.3: Anpassung bestehender Infrastruktur-Technologien an Web Services (nach Newcomer, modifiziert). Application Server müssen an die Technologie der Web Services angepasst werden. SOAPAufrufe können den Aufrufen von Instanzen direkt zugeordnet werden. Damit ergibt sich bei Application Servern der Vorteil eines Zustands-Managements (für Session-Instanzen).

64

6.3 Web Service Standards

6.3 Web Service Standards Die Steuerungsinformationen für die Kommunikation von Web Services werden im Header der SOAP-Nachricht und ggf. auch im Nachrichtenteil untergebracht. Auf diese Steuerungsinformation greifen Frameworks zur Unterstützung von Web Services, aber auch die Web Services selbst zu. Die Einträge im SOAP-Header folgen einer klaren Systematik, aber sie sind in ihrem Inhalt nicht starr vorgegeben. Sie sind erweiterbar (enhanceable) und im Einzelnen zu vereinbaren. Die einzelnen Web-Service-Protokolle sind voneinander unabhängig und je nach Bedarf einsetzbar (pluggable). Diese Offenheit spricht eigentlich gegen einen Standard. Dennoch unterstützt gerade diese Offenheit eine rasche de-facto-Umsetzung. Aktuell werden von IBM, Microsoft, BEA und neuerdings SAP und Siebel Protokolltypen spezifiziert. Diese sind im Bild 6.4 zeitlich eingeordnet. 6.3.1 Messaging & Routing Messaging & Routing dient der verbindlichen Verteilung von Nachrichten. Dies geschieht über ein virtuelles Netzwerk über die beteiligten, unterschiedlichen Transportprotokolle. Garantierte, verbindliche Zustellung ist bei Mail-Systemen und Message Brokern üblich. Eine Nachricht hat hier immer bestimmte Empfänger. Die Nachrichten werden durch meh-

Bild 6.4: Roadmap der Web Services Standards. Die Entwicklung der Spezifikation von Web Services dauert an. Schwierig ist die Verwirklichung von Sicherheit. Bisher wurden noch nie solche unternehmensübergreifenden Konzepte realisiert. Glücklicherweise sind sowohl SAP als auch BEA an der Entwicklung der Spezifikationen beteiligt. SAP als weltweitem Business-Process-Experten kommt eine besondere Verantwortung zu.

65

6 Web Services

rere zwischengelagerte Server (Hubs) übertragen. Dabei werden die Routing-Pfade über Parameter festgelegt. Die eigentliche Routing-Information ist im Header der SOAP-Message hinterlegt. Im Gegensatz zu den bekannten Netzwerk-Routern erfolgt das Routing von Web Services auf der Anwendungsebene. Ein Messaging Framework in der Web-ServicePlattform sorgt für das Senden und Weiterleiten der Nachrichten vom Sender bis zum endgültigen Empfänger (End-to-End). 6.3.2 Transaktionen Eine Transaktion ist eine Folge von Operationen auf einem, möglicherweise verteilten, Datenbestand. Dabei müssen die ACID-Eigenschaften erfüllt sein: • Atomicity Entweder alle Operationen einer Transaktion werden erfolgreich ausgeführt oder gar keine. • Consistency Eine Transaktion überführt den Datenbestand von einem konsistenten Zustand in den nächsten konsistenten Zustand. • Isolation Zeitgleich ablaufende Transaktionen beeinflussen sich gegenseitig nicht und scheinen in serieller Reihenfolge abzulaufen. • Durability Nach dem erfolgreichen Ende einer Transaktion sind die resultierenden Zustandsänderungen dauerhaft gespeichert und gehen durch mögliche nachfolgende Fehler nicht verloren. Eine Transaktion nach dem ACID-Prinzip schreibt Veränderungen auf dem Speicher erst fest, wenn alle Änderungen durchgeführt werden können. Web-Service-Protokolle unterstützen synchrone, kurze Transaktionen und asynchrone, lange Transaktionen (Bild 6.5). Im Bereich unternehmensübergreifender Prozesse werden häufig lange Transaktionen benötigt. Sie werden als Business Activities bezeichnet. Die Aufgabe, dass die Client-Anwendung die Aufrufe mehrerer Web Services in einer Transaktion verbinden möchte, ist nicht trivial zu lösen. Die Transaktionseigenschaften der beteiligten Web Services beschränken die Möglichkeiten. Für die Koordination von verteilten Transaktionen besteht die Lösung grundsätzlich in der Verwendung des Two-PhaseCommit-Protokolls. Die Verwendung des Two-Phase-Commit für Web Services ist wegen der Anforderungen der unternehmensübergreifenden Integration allerdings selten möglich. Für Business-Transaktionen, also Geschäftsvorgänge, die sich über Tage oder Wochen erstrecken, kann Transaktionssicherheit nicht automatisch mit technischen Mitteln gewährleistet werden. Hier bedarf es zusätzlicher Strategien. Lockerung der Isolation – Vorzeitige Sichtbarkeit von Änderungen Die Änderungen werden als vorläufige Änderungen gespeichert. Problematisch sind Änderungen, deren Ergebnisse von anderen Transaktionen zwischenzeitlich gelesen und erneut verändert worden sind. In manchen Fällen kann die Veränderung gespeichert und deren Rücksetzung protokolliert werden. Ein kompensierender Workflow (UNDO) stellt den Ausgangszustand möglichst wieder her.

66

6.3 Web Service Standards

Bild 6.5: Zwei Transaktionstypen im Web Service Standard. Fremde Web Services werden praktisch immer mittels lang laufender Transaktionen, bei BPEL Business Activities genannt, angesprochen. Diese langen Transaktionen sind »rücksichtsvoll« und setzten keine Sperren in Datenbanken im fremden Umfeld. Stattdessen werden Transaktionen im Falle der Erfolglosigkeit durch Workflows so gut wie möglich zurückgesetzt. Oftmals bedarf es dabei auch des Eingriffs von Menschen.

Manche Aktivitäten, die Konsequenzen in der realen Welt haben (z. B. das Versenden von Waren), können nicht immer rückgängig gemacht werden. Solche Fälle benötigen menschliche Intervention (z. B. Anruf durch einen Kundenbetreuer mit der Bitte, die Waren zurückzusenden). Die Lockerung der Isolation (Änderungen werden als vorläufig markiert) kann schnell zur Inkonsistenz der globalen Daten führen (Verlust der Consistency). Deshalb ist die Einführung dieser Strategie bei jeder einzelnen Anwendung kritisch abzuwägen. Lockerung der Atomarität – Differenzierte Abstimmung Um flexibler auf Fehler reagieren zu können, wird die Atomarität gelockert – eine Transaktion wird in mehrere Teile gegliedert. Die Entscheidung, ob die Transaktion erfolgreich abgeschlossen wird oder nicht, erfolgt dann differenziert nach der Logik der Anwendung. Tentative Hold – Abstimmungen vor der eigentlichen Transaktion Vor einer Transaktion mit mehreren Web Services erfolgen Anfragen, ob die gewünschten Ressourcen verfügbar sind. Daraufhin wird an den Ressourcen ein so genannter Hold erworben. Dieser Hold führt in dem Moment zu einer Benachrichtigung, in dem die Ressourcen nicht mehr zur Verfügung stehen. Der Hold sperrt nicht die Ressourcen selbst.

67

6 Web Services

Zeitbeschränkte Zusicherungen auf Prepare-Anfragen Um lange Sperren und eine fremde Kontrolle über das eigene System zu vermeiden, wird eine positive Antwort auf eine Prepare-Anfrage zeitlich begrenzt. Ein Web Service garantiert als teilnehmende Ressource ein erfolgreiches Commit nur für ein begrenztes Zeitintervall. Anschließend behält er sich das Recht vor, die Entscheidung zum Abbruch autonom zu treffen und die Transaktion zurückzusetzen (vgl. Geiß, 2002). Standardisierte XML-Nachrichten zur Transaktionssteuerung Zurzeit existieren zwei Initiativen zur Standardisierung eines Protokolls zur verteilte Transaktionssteuerung, das solche Strategien implementiert: einerseits das Business Transaction Protocol (BTP) unter dem Dach von OASIS und anderseits WS-Coordination und WSTransaction, die von Microsoft, IBM und BEA getragen werden. Derzeit ist noch nicht erkennbar, welches Protokoll sich durchsetzen wird. 6.3.3 Security Grundkonzept Ohne ausreichende Sicherheit erreichen Web Services und elektronische Geschäftsprozesse selten ihr mögliches Potential. Die Notwendigkeit und Problematik ist heute von allen Entwicklungsleitern als vorrangig erkannt. Chappel (2003a) hält die Aufgabe einer Multivendor-Vereinbarung zur Identifizierung und Autorisierung für ein äußerst schwieriges Unterfangen. Er meint, dass dieses Problem bisher noch nie befriedigend gelöst wurde. Bei der Spezifikation der Web-Service-Security-Protokolle werden grundsätzlich bereits bekannte Technologien der Security genutzt. Die WS-Security Spezifikation definiert SOAP Header Extensions, welche Security Tokens übertragen. Die Tokens identifizieren und autorisieren Clients, stellen die Integrität von Nachrichten sicher und garantieren die Vertraulichkeit von Nachrichten. Das Ziel von WSSecurity ist die Herstellung von Sicherheit vom Sender bis zum letztendlichen Empfänger (End-to-End Security) auf der Ebene von Messages. WS-Security beschreibt, wie ein Empfänger die Integrität und Vertraulichkeit überprüfen kann. Die WS-SecurityPolicy Spezifikation beschreibt die Annahmen, von denen ein Web Service Client im Bereich der Security ausgehen kann. WS-Trust legt das Protokoll fest, mit dem Security Tokens von einem Trust Center angefordert werden. WS-SecureConversations regelt die Absprachen über die Kontextinformation bei häufigem Nachrichtenaustausch, damit Security-Information nicht bei jedem Aufruf erneut übertragen werden muss. Eine Einführung in das Thema WS-Security gibt Chappel (2003b). Security Tokens zu Authentifizierung Die WS-Security regelt die Übertragung und den Aufbau von Tokens. Die Spezifikation macht keine Vorgaben für die Authentifizierung des Senders eines Tokens. Alle Tokens sind erlaubt, drei Typen sind explizit definiert: Username & E-Mail-Address/Password, Kerberos Tickets und ein X.509 Zertifikat.

68

6.3 Web Service Standards

Alle Tokens werden im SOAP Header als Teil eines Security-Elements gesendet. Die Art der Tokens und der Authentifizierungsmechanismus müssen vor der Kommunikation vereinbart werden. Somit ist die Kommunikation nur zwischen Anwendungen möglich, deren Security-Frameworks die gleiche »Token-Sprache« und die gleiche Authentifizierung verwenden. Damit Web Services zwischen Partnern zusammenarbeiten können, müssen sich die Partner vorher auf einen bestimmten Security-Mechanismus einigen. Umgekehrt müssen Web Services von Providern so flexibel angelegt werden, dass sie mit vielen verschiedenen und mit neuen Methoden der Authentifizierung zusammenwirken können. Das Zusammenspiel unterschiedlicher Token, wie etwa Digital Signature und X.509 Certificate, mit einem Kerberos Ticket wird in WS-Federation definiert. Digitale Unterschrift des Senders einer Nachricht Die digitale Unterschrift beruht auf der Bildung einer Prüfsumme über den Inhalt eines Dokuments. Diese Prüfsumme wird mit dem geheimen, privaten Teil eines Schlüsselpaars verschlüsselt. Dadurch entsteht die digitale Unterschrift der codierten Prüfsumme. Das verschlüsselte oder unverschlüsselte Dokument wird zusammen mit der digitalen Unterschrift versendet. Vom Empfänger wird die digitale Unterschrift mit dem öffentlich zugänglichen Teil des Schlüsselpaars entschlüsselt. Gleichzeitig wird erneut die Prüfsumme des empfangenen Dokuments gebildet und mit der entschlüsselten Unterschrift verglichen. Dieses Vorgehen stellt über die Prüfsumme sicher, dass die Nachricht nicht verfälscht wurde, und dass die Nachricht auch vom Sender stammt, dessen Public-Key verwendet wurde. Der Public-Key sollte von einem Trust-Center stammen, dem der Empfänger vertraut. Vertraulichkeit durch Verschlüsselung von Nachrichten WS-Security definiert die Art, wie eine Nachricht vor der Übertragung zu verschlüsseln ist. Dies sichert die Integrität einer Nachricht gegen Verfälschung und gegen die Nutzung durch Dritte. Auch hier wird ein bereits bestehender Standard, XML Encryption, eingesetzt. Die Verschlüsselung kann den ganzen oder Teile eines SOAP-Headers, den SOAPBody und jedes Attachment betreffen. SSL (Secure Socket Layer) reicht zur Verschüsselung von SOAP-Nachrichten nicht aus. SSL ist ein Standard-Protokoll zur Verschlüsselung für die Übertragung von einem Server zu einem nächsten Server. Auf diesem wird die Nachricht durch das Protokoll wieder entschlüsselt und im Klartext sichtbar (Security Gap). Damit ist SSL auf der Ebene des Nachrichtentransports nur für jene Web Services geeignet, welche am benachbarten Server ablaufen. Darüberhinaus muss die Verschlüsselung auf der Ebene der Anwendungen selbst geschehen. Spezifikation von Policies zwischen Web Services Mit WS-SecurityPolicy werden die spezifischen Anforderungen eines Web Service an die Security veröffentlicht. Verlautbart wird etwa, welche Tokens oder Algorithmen für die digitale Unterschrift verwendet werden und wie Dokumente verschlüsselt werden. In der Spezifikation noch nicht festgeschrieben ist, wie Policies von einem Partner zu einem anderen übertragen werden können.

69

6 Web Services

Übernahme von Tokens von einem Trust Center WS-Trust definiert, wie Tokens von einem Security Token Service von einem Key Distribution Center oder einer Certification Authority angefordert und übernommen werden. Definition eines Context zwischen Web Services Ist die Interaktion zwischen Systemen häufig, müssen bestimmte Security-Informationen nur einmal ausgetauscht werden. Die Lebensdauer eines Schlüssels für Nachrichten kann vereinbart werden. Die Absprache des Context erfolgt über SOAP Messages. Ist der Context vereinbart, genügt es bei jeder Nachricht diesen Context zu identifizieren. SAML und XrML SAML (Security Assertion Markup Language) ist eine Alternative zu Kerberos Tickets oder X.509 Tickets. Mit SAML können zahlreiche Security-Festlegungen (Entstehung der Nachricht, Zugriff auf Ressourcen) definiert und mit XML Signature verschlüsselt werden. Die entsprechenden Informationen werden im SOAP Header gespeichert. Mit XrML (eXtensible rights Markup Language) werden Rechte über die Nutzung digitaler Inhalte festgelegt, etwa das Recht, einen speziellen Web Service zu nutzen oder ein AudioFile abzuspielen. Auch diese Information wird im SOAP Header gespeichert.

6.4 Standard für Prozess-getriebene Services 6.4.1 Der BPEL Standard BPEL4WS (Business Process Execution Language for Web Services), auch kurz BPEL genannt, dient der Modellierung und unmittelbaren Ausführung von Workflows. Er wird von IBM, Microsoft und BEA, aber inzwischen auch von SAP und Siebel, schrittweise zum Standard entwickelt. BPEL ist die Zusammenführung von XLANG (BizTalk Server) von Microsoft und WSFL von IBM. Die unterschiedlichen auf π-Calculus im einen und Petri-Netzen im anderen Fall beruhenden Sprachkonzepte wurden dabei zu BPEL vereinigt. Dieses Kunststück führt dazu, dass selbst innerhalb eines Programms beide Technologien sogar abwechselnd eingesetzt werden können. BPEL benützt für den Export und Import von Nachrichten WSDL-Interfaces. Das bedeutet, dass Web Services intern über BPEL gesteuert werden können und der BPEL-Workflow selbst wieder Web Services aktivieren kann. Der BPEL-Standard gibt zwei Beschreibungsarten für Prozesse vor: • BPEL: Eine ausführbare Prozessbeschreibung, die von einer BPEL Engine verstanden wird und die einzelne Business-Activities (Web Services) aufruft und steuert. • BPEL Abstract Process: Eine nicht-ausführbare, abstrakte Prozess-Sprache, mit der das für einen Geschäftspartner sichtbare Verhalten eines Web Service beschrieben wird und die den internen Ablauf teilweise verbirgt. Sie unterstützt die Implementierung der Client-Software des Partners. Sie zeigt insbesondere das Verhalten des Prozesses, von dem

70

6.4 Standard für Prozess-getriebene Services

ein Entwickler auszugehen hat. BPEL Abstract Process ist ein Protokoll und enthält keine Variablen für Daten. BPEL erweitert die Technologie von Web Services um langlebige Business-Transactions (Business Activities) und deren Kompensation im Fehlerfall. Die BPEL-Engine ist dabei gleichzusetzen mit dem Monitor für lange Transaktionen. BPEL liefert ein von der Plattform unabhängiges und übergreifendes Intergrationsmodell für organisationsübergreifende Vorhaben. BPEL wird zum Standard für Prozessintegration werden. Damit wird das Integrationspotential von Web Services gesteigert. Zum Zeitpunkt ihrer Ausführung werden die BPEL-Definitionen meist nicht interpretiert, sondern sie werden in den entsprechenden Bytecode des Host-Systems umgewandelt und ggf. über einen JIT-Compiler als Maschinencode zu Ablauf gebracht. Nur Web-Service-interne Workflows greifen auf Daten zu. Aus der externen Sicht auf den Web Service haben diese Daten keine Bedeutung. Alle Daten, welche zur Funktionsfähigkeit eines Cross-Company-Prozesses beitragen, werden in der Form von Messages dargestellt. BPEL benutzt eine Notation, um die für das Protokoll relevanten Daten in den Messages zu identifizieren. Die Beziehung des eigenen Workflows zum Workflow des Partners wird über ein Web Service Framework implizit geregelt. Die BPEL-Workflows sind dabei in kommunizierende Services eingebettet. Workflows rufen andere Workflows über WSDL auf und werden selbst über WSDL aufgerufen. Ein BPEL-Workflow steuert und koordiniert die Interaktionen mit einem Partner-Workflow und kennt dabei dessen Zustandsverhalten, d.h. das Protokoll, nach dem er vorzugehen hat. Dieses Protokoll eines zustandsbehafteten BPEL-Service wird als »Orchestration«, bzw. mit »BPEL Abstract Process« bezeichnet. Die BPEL-Prozesse oder Workflows und die Services, in denen sie existieren, machen keine Annahmen über die Ablaufumgebung des jeweilig anderen. Diese und die Implementierungstechnologie gelten nach dem Prinzip von SOA als abstrahiert. Für die Interaktion werden nur das Protokoll und dessen Nachrichten, der BPEL Abstract Process, also die Sicht auf den Service von außerhalb, publiziert. Werden trotzdem Plattform-abhängige Funktionen genutzt, so können diese in den externen Protokollen (in den SOAP Headers) verborgen werden. Diese Art der Neutralisierung spezifischer Funktionen macht BPEL reizvoll, da es den Entwicklungswerkzeugen eine kostengünstige Realisierung von unternehmensübergreifenden Prozessen erlaubt. Der WSDL Standard und BPEL Anstelle des Begriffs Web Services verwendet BPEL den Begriff WSDL Services, um auf die Unabhängigkeit der genutzten Protokolle und Formate hinzuweisen. Die BPEL-Spezifikation beruht auf WSDL 1.1, XML Schema 1.0 und XPATH 1.0, nicht jedoch zwingend SOAP. SOAP ist für BPEL ein Nachrichtenformat unter vielen. Das Transport-Protokoll ist frei wählbar. Das Datenmodell von BPEL nutzt WSDL Nachrichten und XML-Schema-Type-Definitionen. XPATH unterstützt die Manipulation von Daten.

71

6 Web Services

Im Kern des BPEL-Prozess-Modells steht eine Peer-to-Peer-Interaktion zwischen Services, deren Interfaces in WSDL beschrieben sind. Damit agieren alle Prozesse wie Komponenten und sind wiederverwendbar. 6.4.2 Die Eigenschaften von BPEL Lifecycle Management WSDL ist ein zustandsloses Client-Server-Modell von synchronen und unkorrelierten, asynchronen Interaktionen. Eine Prozess-Definition ist das Muster für eine ProzessInstanz. Aus diesem Muster können viele gleichartige Prozesse (z. B. Bestellvorgänge) erzeugt werden. Die Erzeugung einer neuen Prozess-Instanz, etwa beim Eintreffen einer bestimmten Nachricht, erfolgt implizit. Gleichzeitig wird ein so genannter Correlation-Set erzeugt, in welchem die Zustände einer Interaktion und der Correlation Identifier gespeichert werden. Letzterer dient der Wiedererkennung bei langen Transaktionen. Es besteht bisher keine Möglichkeit einen Prozess von außerhalb zu beenden. Grundsätzlich sind Web Services auf immerwährende Verfügbarkeit ausgerichtet. Message Correlation Einlaufende Messages müssen nicht nur an die richtige Geschäftsfunktion (Port der Aktivität), sondern auch an die richtige Prozess-Instanz ausgeliefert werden. Diese Aufgabe (das Instanz Routing) übernimmt das Web Service Framework des Hosts durch eine Inspektion des Headers der Nachricht oder der Nachricht selbst und der Auswertung eines Identifiers. Die Lage, den Aufbau und die Semantik eines Identifiers in einer Nachricht beschreibt eine Correlation Property. In objektorientierten Systemen übernehmen im Fall synchron gekoppelter Systeme ObjektReferenzen diese Aufgabe (Bild 6.6). Um diese Technologie zu erweitern, werden zwischen einem Client und einem Service Identifier vereinbart und an einer bestimmten Stelle der Nachricht hinterlegt. Die Factory des objektorientierten Systems erzeugt beim Eintreffen der ersten Nachricht ein Objekt, bzw. hier eine BPEL Workflow Session, und kann bei jedem weiteren Eintreffen von Nachrichten die richtigen Prozess-Instanzen erneut ansteuern. Die so von einem Prozess gespeicherten Daten stehen dann bei jedem neuen Dialogschritt zur Verfügung, wie sie beim Aussenden einer Antwort an den Client vorlagen. Die Prozess-Instanz entspricht dann einem Objekt, einer Session. BPEL setzt keine Factory zur Erzeugung von Prozessen voraus. Einige der Nachrichten an einen BPEL-Prozess erzeugen implizit neue Prozess-Instanzen. Die Identifizierung des richtigen Prozesses bei mehreren Dialogschritten erfolgt über Correlation-Felder und Tokens im Header oder Body der Nachrichten. Correlation Tokens sind Identifier und normalerweise mit XML beschrieben und über XPATH abfragbar. Diese Identifier müssen zwischen Client und Server vorher über ein Meta-Protokoll vereinbart sein. An dieser Stelle liegt momentan kein Standard vor. BPEL-Prozesse nutzen Zustandsvariablen. Diese Variablen werden durch den Prozess über Data-Expressions manipuliert. Als Default-Sprache wird XPATH verwendet. Ein Standard ist noch in Entwicklung. Der aktuelle Zustand eines Prozesses bzw. einer Prozess-Instanz ergibt sich aus der Summe aller Messages, die ausgetauscht wurden, und aus allen bisher zwischengespeicherten 72

6.4 Standard für Prozess-getriebene Services

Bild 6.6: Automatische Zuordnung von Kunden zu ihren temporären Daten. Bei Web Services ist kein festes Schema für die Identifikation eines Consumers festgelegt. Diese Identifikation wird irgendwo in der SOAP-Nachricht übertragen. Beim Einsatz eines Application Servers erzeugt eine Session Factory eine Instanzadresse für alle temporären Daten des Consumers im Server. Die erneute Zuordnung eines bestimmten Consumers bei seinen Dialogschritten, wenn er z. B. einen Warenkorb füllt, erfolgt über einen Router.

Daten, die auch beim Aufbau einer Nachricht verwendet wurden. Das heisst, dass alle BPEL-Prozesse zustandsbehaftet sind und damit auch alle Web Services, welche über einen mit BPEL definierten Workflow genutzt werden. Ein solcher Web Service hält also fest, welche Daten durch Dialogschritte eines Web Service Consumer verändert wurden und reagiert entsprechend. Ein wesentliches Element von BPEL sind Ports. Ein Port-Typ definiert zunächst die Menge der bei einem Service vorgesehenen Operationen, die jeweiligen Messages, die er versteht, mit ihren Parametern, und die Schema-Typen dieser Parameter. Ein Port-Typ wird einem bestimmten Service zugeordnet, den eine Aktivität benötigt, um ein Ergebnis zu erzeugen. Ein Port ist die Schnittstelle des Service selbst. Der Port-Typ wird dem konkreten Port des Service über das Binding zugeordnet. Gebunden wird das Protokoll, mit dem der Service aufgerufen werden kann. Einem Port-Typ kann auch eine menschlichen Aktivität (ein menschlicher Service) zugeordnet werden, indem der entsprechende Service einen Eintrag in eine Worklist vornimmt. Ports sind die Brücke von BPEL zur Modellierung von Unternehmen, in der Aufgaben einzelnen Menschen, Rollen, Organisationen oder aber IT-Funktionen zugeordnet werden.

73

6 Web Services

Ein Compensation Handler bei BPEL ist ein Workflow zum Rücksetzen der Auswirkungen von Aktivitäten, wenn ein bestimmtes Ziel nicht erreicht werden kann. Der Compensation Handler benötigt dabei Daten über den aktuellen Zustand des Geschehens und er liefert Daten über den Erfolg der Kompensation. Die Technologie der Kompensation benötigt tief greifende Überlegungen. Ein Compensation Handler von BPEL arbeitet auf einem Schnappschuss der Variablen vor dem Ablauf der Prozess-Instanz, deren Wirkung kompensiert werden soll. Ein Compensation Handler kann nicht die Daten ändern, die der aktuelle Prozess gerade nutzt. Kompensationen leben also in einer Schnappschusswelt. Sie können niemals in einen laufenden Prozess eingreifen und nur auf externe Services und deren Undo-Interfaces einwirken. Weitere Zusätze zu BPEL sollen Kompensation erleichtern.

6.5 Application Server zur Unterstützung von Prozessen Die auf Erweiterbarkeit angelegten Web Services (SOAP Header, WS-Security, BPEL) sprechen gegen die Einheitlichkeit künftiger Middleware, dennoch kann nicht ausgeschlossen werden, dass die Hersteller derzeitiger Application Server die Idee von Komponenten auf das Konzept von Web Services ausdehnen.

Bild 6.7: Application Server mit Unterstützung von Workflows. Die Ablaufumgebung von Workflows in künftigen Application Servern werden spezielle Container sein. Diese sorgen für die Verwaltung der Verarbeitungszustände bei langen Transaktionen, für die Verbindung zu Services und menschlichen Agenten, das Bereitstellen von Timern, den Restart unterbrochener Abläufe beim Eintreffen von Antworten, die notwendigen Security-Mechanismen und die Überprüfung der Korrektheit eingehender Requests durch Nutzung eines aktiven Registry.

74

6.6 Web-Service-Framework-Plattformen

Das Vorgehen von Microsoft ist »rigoros«. Jedes Stück Software, jeder Service ist in .NET automatisch ein Web Service und jedes API ist mit WSDL beschrieben. Daraus kann automatisch ein Proxy generiert und von einem Client genutzt werden. Der .NET-Plattform fehlen allerdings einige Elemente der J2EE-Plattform, wie etwa Stateful Session Components oder Shareable Enterprise Components, welche eine große Bereicherung bei der Implementierung von Web Services darstellen. Erweiterungen für künftige Application Server werden sein (Bild 6.7): • WSDL Interfaces für Transport-Protokolle von Services, nicht nur RMI over IIOP. Übernahme der WSIF-Architektur zur Anbindung unterschiedlicher Protokolle an Komponenten. • Unterstützung aller Sicherheitsmechanismen • Prozess-Container als eine Art Session Beans (Process Beans) mit – Ablaufsteuerung des Workflows und Monitoring, – Management von XML-Nachrichten der Prozess-Instanz, – Kommunikation von Aktivitäten, welche von Menschen ausgeführt werden, – Verwaltung der Daten einer Workflow-Instanz über lange Zeit (Context Store), – Timer Management zur Überprüfung des fristgemäßen Ablaufs angestoßener Aktivitäten, – Management von Warteschlangen und – Restart (Callback) einer angehaltenen Prozess-Instanz.

6.6 Web-Service-Framework-Plattformen 6.6.1 Microsoft Die Neuentwicklung des Windows-Betriebssystems für .NET enthält eine Kommunikations-Infrastruktur zur Entwicklung verteilter Systeme – Connected Systems. Gemäß dem Service-orientierten Ansatz werden damit autonome Programme mittels asynchroner Übertragung von Nachrichten komponiert. Diese Plattform basiert auf einem einheitlichen Programmiermodell und Protokoll-Stack für die gesamte verteilte Kommunikation. Sie ist eine Zusammenführung von .NET Remoting, ASP.NET, Web Services und .NET Enterprise Services. Darüber hinaus führt die Plattform viele verschiedene Transport- und Security-Mechanismen, Netzkonzepte und Transaktionskonzepte zusammen. Die Plattform unterstützt das SOAP-Protokoll und die Web-Services-Protokolle für Security, Reliability und Transaktionen. .NET Enterprise Services, früher COM+, sind für die verteilte Verarbeitung von .NETbasierten Systemen vorgesehen, Web Services dagegen für die Interoperation mit anderen Systemen. Jedoch können Komponenten auf Basis von Enterprise Services als Mittel für die Web-Service-Implementierung genutzt werden. Die wesentlichen Komponenten der neuen Web-Service-Plattform, Codename »Indigo« (Bild 6.8), sind:

75

6 Web Services

Bild 6.8: Architektur für Web Services von Microsoft. Indigo ist die Infrastruktur zur Unterstützung von Web Services innerhalb der Neuentwicklung des Windows-Betriebssystems unter dem Codenamen »Longhorn«. Indigo liefert ein einheitliches Programmiermodell für die gesamte verteilte Verarbeitung. Indigo ist eine Zusammenführung von .NET Remoting, ASP.NET Web Services und .NET Enterprise Services (DCOM).

Service Model Das Service Model hat die Aufgabe, die eingehenden Nachrichten mit dem Programmcode, den Services, zu verbinden. Dabei kann zwischen mehreren Kommunikationsarten gewählt werden, z. B. One-way oder Request/Reply. Zustände von Service-Instanzen können über COM+ oder ein spezielles Kontext-Management realisiert werden. Darüber werden eingehende Nachrichten automatisch den richtigen Service-Instanzen zugeordnet. Eine Instanz kann Nachrichten unterschiedlichen Typs verarbeiten. Belange der Sicherheit und der Zuverlässigkeit werden über Deklarationen (.NET Attribute) im Programmcode beeinflusst. Konnektor Der Konnektor ist ein Framework für sichere und zuverlässige Nachrichtenverbindungen. Das Framework basiert ausschließlich auf SOAP. Der Konnektor erlaubt die Kommunikation unabhängig vom Transportmechanismus, also nicht nur via HTTP. Die gesamte Architektur des Konnektors ist auf hohen Durchsatz und geringe Verzögerungszeiten ausgelegt. 6.6.2 IBM Web Service Gateway Das Web Service Gateway dient in erster Linie der sicheren Kommunikation von Web Services zwischen Unternehmen. Eine weitere Aufgabe des Gateway ist die Transformation 76

6.6 Web-Service-Framework-Plattformen

von Protokollen, etwa von JMS nach HTTP und SOAP. Dazu muss vom Provider eines Web Service eine WSDL-Beschreibung des Service mit den möglichen unterschiedlichen Bindings (Protokolle) mit dem Gateway als Endpunkt definiert werden. Zur Behandlung der Sicherheitsaspekte wird eine Filtertechnologie eingesetzt. Ein Filter interpretiert den Inhalt einer SOAP-Nachricht und startet bestimmte Verarbeitungsfunktionen, etwa für die Authentifizierung des Clients oder zur Entschlüsselung von Nachrichten. Diese Filter-Technologie wird auch bei ausgehenden Nachrichten verwendet. Mit dieser Framework-Technologie können sich Unternehmen eine auf ihre Bedürfnisse ausgerichtete Web-Service-Plattform einrichten. Sie legen dabei fest, welche SicherheitsTechnologie sie verwenden, wie sie die von einem akzeptierten Client gestarteten Prozesse bei dessen erneutem Zugriff identifizieren oder welche weiteren Informationen zur Steuerung des Ablaufs ausgetauscht werden. Web Service Invocation Framework (WSIF) Das Web Service Invocation Framework (Bild 6.9) ist ein von der IBM entwickeltes Framework, das unterschiedliche Zugriffe (via SOAP, RMI/IIOP, JDBC, JMS, usw.) auf Services aus einem J2EE Application Server zulässt. Mit WSIF kann ein Java Bean remote und praktisch über jedes beliebige Protokoll auf Services zugreifen. Diese Services müssen

Bild 6.9: Web Service Invocation Framework (WSIF) von IBM/Apache (nach IBM, modifiziert). Das Web Service Invocation Framework ist ein offenes Framework zur Anbindung von Services an Java Beans über unterschiedliche Transportmechanismen und Nachrichtenformate. Die Bindung kann statisch über Proxies erfolgen oder auch erst zur Laufzeit, nach dem Auffinden eines den Anforderungen entsprechenden Service entprechend dem von IBM vorgeschlagenen Enterprise Service Bus. Eine wichtige Eigenschaft dieser Architektur ist, dass die Adaption von Funktionen ausschließlich ein Teil des Services selbst und nicht des Frameworks ist. Benutzer des Frameworks können unterschiedlichste Protokolle und Formate in das Framework integrieren.

77

6 Web Services

Bild 6.10: WSDL-Interface-Technologie. WSDL dient der Abstraktion des API unterschiedlicher Services und der Kopplung von Services über ein spezielles Protokoll. Damit wird WSDL die künftige Grundlage für jegliche Integration. Ein Service kann dabei mehre WSDL-API, sogennante Fassaden, bereitstellen. Das WSIF von IBM lässt im Gegensatz zum Standard mehr als ein Protokoll pro WSDL-Spezifikation zu.

dazu ein WSDL-Interface besitzen, welches über das WSIF importiert wird. Zugriffe auf Web Services werden durch WSIF von der aufrufenden Instanz abgekapselt, woduch für den Client der Transport Layer transparent und im Gegensatz zu Web Services (SOAP) austauschbar wird. WSIF ist als Framework in den WebSphere Application Server integriert. WSIF ist eng mit WSDL verbunden und kann dadurch jeden Service aufrufen, dessen API mit WSDL beschrieben ist. Der Transportmechanismus und das Nachrichtenformat beim Aufruf eines Remote-Service sind offen. Deshalb können in das WSIF neue Interfaces, so genannte Provider, für neue Transportmechanismen und Formate durch einen Entwickler eingebracht werden. Im WSIF werden die Services entweder über ein statisches Proxy-Interface oder ein Dynamic Invocation Interface (DII) angesprochen (Bild 6.10). Über das DII unterstützt WSIF das so genannte Late-Binding, wodurch Service-Requests auf ad-hoc zugeordnete neue Services und deren Protokolle ohne Code-Änderungen umgeleitet werden können. Der Client kann selbst zur Laufzeit ein von ihm gewünschtes Binding zu den gefundenen Services auswählen. In WDSL besteht ein Service aus drei Teilen: • Port-Typ Dieser definiert die Menge der Operationen auf einem Service, die jeweiligen Messages mit ihren Parametern und die Schema-Typen der Parameter.

78

6.6 Web-Service-Framework-Plattformen

• Binding Ein Binding gibt an, wie der Port-Typ auf das Format (z. B. SOAP) und das Protokoll (z. B. HTTP) eines konkreten Service abgebildet wird, welches dieser versteht. • Port Dieser definiert die Adresse des Service, z. B. bei HTTP die URI eines SOAP Service. Der Port kann ein Adapter oder ein Wrapper für ein Legacy-System sein. Modellierung organisatorischer Anforderungen Hinter einem Port kann auch die Verbindung zu einer speziellen Anwendung stehen, über welche ein Mensch Entscheidungen innerhalb eines Workflows zu treffen hat. Ports entsprechen dann dem Zugriff eines Workflows auf Personen in einer Organisation. Meist sind es Rollen oder Berechtigungen, über die einzelne Personen erst zur Laufzeit und unter konkreten Bedingungen zugeordnet werden. In einer abstrakten Sicht können die Rollen auch durch Unternehmen oder Unternehmenstypen ausgefüllt werden, wie Logistik-, Inkasso-Unternehmen oder Versicherungen, also alle Teilnehmer eines Wertschöpfungsnetzwerks. In WSDL hat jedes Binding nur einen Port-Typ. Zur Realisierung einer Service-orientierten Architektur benötigt man eine Technologie, in der jeder virtuelle Service (Port-Type)

Bild 6.11: Anbindung eines BPEL-Workflow an Services über WSDL und WSIF. Bei einem BPEL-Workflow erfolgt die Anbindung von Services grundsätzlich über WSDL. Die Funktionen müssen entweder ein WSDL-API besitzen oder durch einen Adapter mit einem solchen nachträglich ausgestattet werden. Die Anbindung an eine Funktion bzw. an ein Protokoll kann über WSIF vereinfacht werden. Einem J2EE-basierten Workflow steht jede Protokolltechnologie (EJB, JMS, HTTP/SOAP, Java, IIOP) oder ein beliebiges, frei definiertes Protokoll zur Verfügung. 79

6 Web Services

unterschiedliche Ports (und damit Services mit den unterschiedlichsten Protokollen) binden kann. Die generelle Verfügbarkeit von WSDL in Verbindung mit WSIF unterstützt auch die Technologie der Workflows (BPEL), da auf diese Weise ein flexibler Mechanismus zur Implementierung von Aktivitäten geschaffen wurde (Bild 6.11). Man spricht statt von Web Services von WSDL Services. Die Stärke von WSIF ist die Erweiterbarkeit von WSDL. Trotz der Erweiterungen, etwa für CICS, IMS, Java Beans, EJBs oder JMS, bleibt der Client-Code von der Implementierung im Provider unabhängig. Der Client kann Entscheidungen über den Port eines Service, den er nutzen will, einer Infrastruktur (Services Bus) überlassen, welche die Auswahl nach Charakteristiken wie Quality of Service oder gemäß einer Business Policy trifft. Damit erlaubt WSDL dem gleichen API (Port-Type) des Clients das dynamische Binding zu SOAP, JMS, JCA, IIOP oder zu anderen Protokollen – eine enorme Perspektive für Java Beans in einem künftigen J2EE Application Server. Das Java API für XML-basierte Remote Procedure Calls (JAX-RPC) dient heute dem Aufruf von externen SOAP-basierten Web Services aus der Java-Plattform. Dies bedeutet auch, dass ein Java-Client auch Web Services auf einer Nicht-Java-Plattform ansprechen kann. JAX-RPC führt ein Mapping zwischen Java und WSDL durch. Im Zentrum dieser Technologie des späten Bindens von Services mit unterschiedlichen Protokollen steht das Untersuchen und Auswerten von WSDL-Files, in denen die Beschreibung der Ports eines Service steht. Entsprechend wird die notwendige Implementierung etwa für lokale oder entfernte Java-Objekte, JMS oder .NET erzeugt. Ein Client spricht immer mit einem generischen Java Interface (Java Object, Stub) ohne Wissen über die Implementierung der Kommunikationsverbindung, etwa SOAP via WSDL. WSIF ist ein Komponente des WebSphere Application Server. Standardisierung der WSIF-Technologie Für neue Anwendungen auf einem WebSphere Application Server wird IBM die in ihrer Leistung mit dem WSIF vergleichbaren Spezifikationen JSR 109 und JSR 101 unterstützen (siehe Anhang Standards), wobei JSR 101 das Mapping von WSDL nach Java und umgekehrt definiert. JSR 109 erweitert den JSR 101 um die verschiedenen Möglichkeiten zur Bindung eines Client an einen Service.

80

7 Grid Services

• • • • • • •

Was ist ein Grid? Was verbirgt sich hinter OGSA? Was bedeutet Virtualisierung von Services? Warum werden Grid Service APIs mit WSDL beschrieben? Welche Eigenschaften benötigen Grid Services für den Ablauf in einem Grid? Welchen Nutzen versprechen Grid Services? Gibt es schon Ansätze in aktuellen Produkten?

7.1 Die Idee der Grid Services Der Ursprung der Grid Services liegt im Bereich der Wissenschaft. Dort werden für Berechnungen häufig große Rechenleistungen benötigt. Dazu werden freie Computer temporär zusammengeschlossen. Es gibt dazu eine Reihe hochleistungsfähiger Netze wie das UK Research Grid und das Tera Grid. Auch im Unterhaltungsbereich sind Grids im Entstehen, z. B. Butterfly.net. Im Bereich der Industrie werden Grids bei rechenintensiven Verfahren in den Bereichen Energiegewinnung, Finanzwesen, Produktfertigung und auch Bioinformatik genutzt. Einen aktuellen Überblick über den Stand des Grid Computing findet man bei Berman, Fox und Hey (2003). Was ist ein Grid? Ein Grid ist ein Verbund heterogener Computer-Ressourcen zur Verteilung und zum Ablauf von Grid Services (Anwendungen). Um ein Grid nutzen zu können muss die Architektur einer Anwendung zur Verteilung geeignet sein. Grid Services erlauben es Organisationen Ressourcen und Services in Netzwerken auf heterogenen Plattformen gemeinsam zu nutzen. Die Aufgabe der Infrastruktur, dem Grid, kann mit der eines Betriebssystems verglichen werden. Die Grid Services müssen bestimmte Interfaces bereitstellen und umgekehrt auch solche bedienen. Dazu zählen Interfaces für das Auffinden, das Laden und das Life Cycle Management. Sie müssen auch Events für das übergreifende Management der Services liefern. Die Interfaces werden den Nutzern in der Form von spezifischen Proxies zur Verfügung gestellt. Ein Grid bezeichnet also sowohl eine Ablaufumgebung für Grid Services als auch eine Menge von Grid Services, die darin integriert werden können.

81

7 Grid Services

7.2 Grid Server, Grids und OGSA Die einheitliche Ablaufumgebung, das Grid, wird zu einer Weiterentwicklung der Application Server führen. Die implementierten Grid Services können überall im Grid zur Ausführung gebracht werden, wenn sie zu den Ablaufbedingungen passen. Grids als Netzwerk von Grid Servern sind Systeme, die alle IT-Ressourcen koordinieren, und dabei keiner zentralen Administration unterliegen. Beim Grid-Forum 2002 in Toronto schlossen sich das Projekt Globus und wichtige Hersteller als OpenSource Community zusammen, um das Grid Computing über den bisherigen wissenschaftlichen Bereich hinaus auch im industriellen Bereich einzuführen. Das Grid Forum ist das Gremium für die Open Grid Services Architecture (OGSA) und definiert Spezifikationen und Standards, welche die Vorteile des Grid Computing mit denen der Web Services kombinieren. Globus stellt dazu eine OpenSource/Public Domain Implementierung des Standards bereit. Grid Services sind Anwendungen innerhalb der OGSA. Grid Services ermöglichen zusätzlich zu den Web Services ein Life Cycle Management. Grid Services können auf Anweisung eines Client als Instanzen geladen werden, haben ein Gedächtnis über den Zustand der Interaktion mit dem Client und können angehalten oder zerstört werden.

7.3 Standard Interfaces für Grid Services Virtualisierung In der OGSA ist ein Service eine Einheit in einem Netzwerk, welche eine bestimmte Leistung bereitstellt. Services sind in der OGSA Computer-Ressourcen, Speicher, Programme und Datenbanken. Die Virtualisierung erlaubt die Integration von Services ohne Rücksicht auf die Implementierungsart des einzelnen Service. OGSA legt fest, wie eine Grid-Service-Instanz erzeugt, benannt und beendet wird und wie diese mit anderen kommuniziert. OGSA legt nicht fest, was und wie die Instanz es tut. Jede Instanz verwaltet im Unterschied zu einem Web Service einen internen Zustand. Dieser Zustand unterscheidet die Instanz von allen anderen desselben Grid-Service-Typs. Jede Instanz wird wie bei CORBA über einen global eindeutigen Namen, den Grid Service Handle, angesprochen. Der Scheduler für einen Ablauf liegt auf einem besonders gegen Ausfall gesicherten Server innerhalb des Grids. Er vermittelt die auf dem Grid angebotenen Ressourcen und startet und überwacht den Ablauf. Damit zukünftig J2EE als Netzwerkbetriebssystem funktionieren kann, muss eine Instanz geschaffen werden, welcher bekannt ist, wo Ressourcen frei sind. Es bleibt abzuwarten, wie und wann WSDL, WSIF sowie die Grid Services Interfaces fester Bestandteil von J2EE werden. Hinzukommen müssen jedenfalls • das Mapping von Grid-weiten Namen (Grid Service Handles) auf implementierungsspezifische Einheiten wie C-Pointer, Java Object Referenzen, etc.,

82

7.3 Standard Interfaces für Grid Services

• die Verteilung von Aufrufen und Events auf spezielle Aktionen wie Unterbrechungen und Prozeduraufrufe, • die Unterstützung von diversen Protokollen, • das Life Cycle Management und • die Authentifizierung von Services. 7.3.1 Die WSDL-Technologie für Grid Service Interfaces Damit Grid Services virtualisiert werden können, trennt WSDL das Interface von den Kommunikationsprotokollen. Dadurch können auch bestehende Anwendungen, vor allem solche, welche remote z. B. über HTTP angeschlossen sind, leichter in ein Grid einbezogen werden. Der Client kann bei der Kommunikation ein bestimmtes Protokoll selbstständig wählen. Grid Service Interfaces entsprechen den Port-Types von WSDL. OGSA hat zusätzlich eine Möglichkeit der Versionierung von Services in WSDL eingeführt. Das Grid Service Interface ist unabhängig von der Implementierung des Service selbst. Es kann denselben Grid Service für verschiedene Plattformen geben, ohne dass sich ein Client (Consumer) darauf speziell einrichten muss. Für die Implementierung eines Grid Service in einer Grid-Architektur kann zwischen den folgenden Ansätzen gewählt werden: 1. Eine Referenz-Implementierung wird auf die Bedürfnisse unterschiedlicher Plattformen angepasst. 2. Wenn eine Plattform spezialisiert ist, wird der Service auf diese zugeschnitten implementiert und ist über das Grid zugänglich. 3. Ein Service wird aus kleineren Sub-Services aufgebaut und aggregiert. Der wesentliche Aspekt bei der Virtualisierung des Verhaltens von Ressourcen ist die Anpassung an die Betriebssystemfunktionen eines bestimmten Hosts. Dabei sollen die Eigenschaften der Plattform genutzt werden. Hier erlaubt der Discovery-Mechanismus einem Client herauszufinden, welche Technologie (z. B. Sicherheit) bei der Implementierung des Interface genutzt wurde, um sich anzupassen. Natürlich kann eine Implementierung eines Grid Service auch eine bestehende, nicht-verteilte Legacy-Anwendung auf einem Mainframe sein. 7.3.2 Grid Service Interfaces in OGSI 1.0 Discovery Zwingend für einen Grid Service ist ein Interface zum Suchen von Informationen über den Service. Dazu kann XQuery eingesetzt werden. Die Zugriffsadresse (Handle) eines Service wird ebenso ermittelt, wie die verschiedenen Eigenschaften der aktuellen Instanz, die Anzahl der Anfragen und die momentane Belastung der Services durch andere Nutzer. Die Grundlage der Service Discovery ist ein Grid Service Registry, ähnlich dem UDDI. Dynamic Service Creation Die Erzeugung einer Instanz eines Grid Service erfolgt über ein Factory-Interface. Zurückgeliefert an den verursachenden Client wird ein Grid Service Handle (siehe dort). Dabei

83

7 Grid Services

nutzt die Factory die Mechanismen der Grid Service-Ablaufumgebung des Host-Environments. Life Cycle Management In Host-Environments endet ein Programm, wenn eine Aufgabe erledigt ist. Bei verteilten Systemen können Teilkomponenten ausfallen oder Nachrichten verloren gehen. Das führt dazu, dass eine Komponente eventuell nie explizit beendet würde. Deswegen führt OGSA einen Soft State Approach ein, wobei den Services eine Lebenszeit zugewiesen wird. Diese Frist kann durch einen Client dynamisch verändert werden. Ist die Frist abgelaufen, beendet das Host-Environment den Service und gibt die reservierten Betriebsmittel wieder frei. Notification Mit dem OGSA Notification Framework können sich Clients dazu anmelden (subscribe), dass sie beim Erscheinen bestimmter Nachrichten oder Services informiert werden. Das Interesse an diesen Ereignissen muss der Empfänger durch Keep-alive-Nachrichten signalisieren. Die Verteilung der Events kann abhängig vom Protokoll in verschiedenen Varianten geschehen, etwa mit garantierter Zustellung oder über ein Multicast-Protokoll.

Bild 7.1: Grid Computing Middleware (nach IBM, modifiziert). Als zusätzliche Eigenschaften gegenüber Web Services besitzt die Grid-Infrastruktur das Life Cycle Management von Grid Services. Instanzen werden nicht über URI und Identifier in den Nachrichten angesprochen, sondern wie bei CORBA über universelle Handles. Grid Services müssen bestimmte Anforderungen erfüllen, damit das Laufzeitsystem eine effiziente Steuerung der Ressourcen durchführen kann. Die Eigenschaften des Grid-Laufzeitsystems selbst sind noch wenig standardisiert.

84

7.4 Die Implementierung von Grid Services

Handles Ein Grid Service Handle ist ein Netzwerk-weiter Pointer, der einem Client erlaubt, die Instanz eines Grid Service zu nutzen. Grid Service Handles dienen der eindeutigen Identifikation einer einmal erzeugten Grid-Service-Instanz in einem Grid. Ein Konzept, das auch schon bei CORBA Verwendung fand. Bei Web Services geschieht dies im Gegensatz dazu über zwischen den Partnern frei vereinbarte Mechanismen. Eine Grid Service Reference erlaubt den indirekten Zugriff auf einen Service, da eine Grid Service Instanz zwischenzeitlich den Server gewechselt haben kann. Die Grid Service Reference wirkt wie ein Broker. Über eine Grid Service Reference kann ein Client Anfragen an eine Grid-Service-Instanz schicken, um bestimmte Bedingungen zu erfragen. Die dazu notwendigen Operationen sind in der Beschreibung des Port-Typs des Service enthalten. Die beim Service hinterlegten Daten werden als Service Data bezeichnet. Sie dienen der Abfrage von Informationen über einen Service und von aktuellen Zustandsinformationen zu einer Service-Instanz. Die beschrieben Grid Services Interfaces im Zusammenhang mit anderen Elementen einer Grid Computing Architektur zeigt das Bild 7.1.

7.4 Die Implementierung von Grid Services Die Möglichkeiten einer Architektur von Grid Services reichen von der Implementierung eines Service als Prozess in einem Mainframe-Betriebssystem bis zur Realisierung eines Grid Service als Komponente in einem J2EE Container. OGSI schreibt keine bestimmte Architektur vor.

Bild 7.2: Alternative Implementierungen von Grid Services (nach OGSI 1.0). Grid Services werden auf Plattformen verteilt, die ihren Ablaufbedingungen entsprechen. Unabhängig von den Anforderungen durch das Grid Runtime System können die üblichen Services einer Plattform genutzt werden. Es können Application Server genutzt werden, in deren Containern ein Grid Service abläuft oder der einen externen Grid Service über einen JMS-Adapter einbindet. Aber auch ein Legacy Grid Service kann über ein Grid-Protokoll direkt angesprochen werden. 85

7 Grid Services

Im ersteren Fall muss das gesamte geforderte Verhalten (Aufruf, Life Cycle, Registrierung etc.) im Anwenderprozess enthalten sein, im Falle der Nutzung eines Containers muss dieser das Grid-Verhalten garantieren. Bild 7.2 geht von der Annahme aus, dass der Aufruf eines Grid Service bei einer HTTP Servlet Engine ankommt, welche die Message in ein Format umwandelt, das von der Ablaufumgebung verstanden wird. Die Message wird an einen Container weitergeleitet, welcher die Nachricht (z. B. im SOAP-Format) in einen normalen Programmaufruf umwandelt (Demarshalling). Daneben kann der Container andere im Grid geforderte Funktionen enthalten, wie Life Cycle Management, automatische Autorisierung und Authentifizierung, Logging, Anhalten, Beenden bei Erreichen der Lebenszeit und den Abbruch eines Service.

7.5 Grid Computing für Business-Lösungen Das Konzept des wissenschaftlichen Grid Computing hat in den Bereich der Industrie Einzug gehalten. Bei der Infrastruktur handelt es sich um individuelle Lösungen. Jenseits der beginnenden Standardisierung der Grid Services und vielleicht sogar der Bereitstellung von Grid-Servern soll hier über die Grenzen dieser Technologie gesprochen werden. Das klassische wissenschaftliche Grid Computing unterscheidet sich ganz wesentlich vom klassischen Business Computing. Beim ersteren geht es darum Rechenleistungen für umfangreiche, parallel ausführbare Berechnungen zu bündeln, Berechnungen gleichzeitig durchzuführen und dann Ressourcen wieder frei zu geben. Es geht um temporäres Ausleihen von Rechenleistung. Dagegen liegt das Schwergewicht bei Business-Lösungen auf einem optimierten Zugriff auf fest verbundene Datenbanken. Es ist nicht möglich diese Datenbanken zu virtualisieren und auf die Rechneranlage zu bringen, auf der die Verarbeitung der Geschäftslogik stattfindet. Die meist großen Datenmengen bleiben also ortsfest und müssen über Netzwerke bereitgestellt werden. Auch dem Remote-Zugriff über ein superschnelles Glasfaser-Netzwerk ist letztlich durch die Lichtgeschwindigkeit und die Leitungslänge eine natürliche Grenze gesetzt. Der Grid Standard ist ein Anfang In der aktuellen Spezifikation des Grid Standard sind Konzepte enthalten, welche eine übergreifende Nutzung im Business Computing kritisch erscheinen lassen. Die Grid-Architektur verzichtet bislang auf eine zentrale Steuerung der verteilten Verarbeitung und überlässt das Geschehen dem freien Spiel der Kräfte. Es ist bislang nicht zu sehen, wie bei diesem Konzept eine transaktionelle Integrität garantiert werden kann, oder wie etwa im Netz verlorene Quittungen auf eine Nachricht behandelt werden sollen. Ein System wie SWIFT im Bereich der Banken wäre damit wohl nicht zu realisieren. Die Services werden durch Events eines Client am Leben gehalten, können aber auch bei Bedarf des Servers oder beim Ausbleiben der Keep-alive-Events gestoppt werden. Es ist zu bezweifeln, ob dieses Soft-State-Management den Bedürfnissen von missionskritischen Anwendungen genügt. Daher muss genau geprüft werden, welche Anwendungen in der

86

7.5 Grid Computing für Business-Lösungen

Bild 7.3: Perspektiven der industriellen Nutzung des Grid Computing (nach IDC). »Gridified« Infrastructure bezeichnet das Laufzeitsystem für Grid Services. IDC hat bestimmten Grid Services Chancen in den unterschiedlichen Industriezweigen zugeordnet. Diese Grid Services müssen verteilbar sein. Die Verteilung von klassischen betriebswirtschaftlichen Anwendungen ist wegen der Laufzeiten in einem Netzwerk und der damit erforderlichen Nähe der Datenbank selten möglich – es sei denn das Grid befindet sich in einem Rechenzentrum, bei dem Laufzeiten nicht ins Gewicht fallen.

Industrie als Grid Services realisiert werden können. Eine erste Übersicht dazu gibt eine Darstellung von IDC (Bild 7.3). Fortschritt in der Standardisierung von Services Aus der Sicht von Web Services bringen Grid Services zweifellos einen Fortschritt. Sie bringen Mechanismen, welche sonst erst implementiert werden müssten: • Grid Services zeigen Zustandsverhalten, d.h. ein Client kann damit rechnen, dass er im Normalfall beim nächsten Interaktionsschritt die Daten wieder vorfindet, welche er dort hinterlassen hat. Dadurch wird der Aufwand bei der Programmierung des Client reduziert. • Web Services müssen immer verfügbar sein, also rund um die Uhr. Grid Services hingegen können von einem Client bei Bedarf erzeugt und nach der Nutzung wieder stillgelegt werden. • Web Services werden über eine URL angesprochen. Grid Services, als spezielle Implementierungstechnologie von Web Services, werden über eine Factory erzeugt und liefern dem Client eine eindeutige Referenz (Handle). Damit ist die Identifizierung von Clients auf der Seite des Servers bereits durch die Middleware bereitgestellt. Grid Services sind eine Wiederauflage des Themas der verteilten, Zustands-orientierten Verarbeitung und der Object Request Broker, auch wenn dieser Begriff momentan noch aus strategischen Überlegungen vermieden wird. Perspektiven für Grid Services Die Nützlichkeit jedes neuen Standards kann erst dann beurteilt werden, wenn sich dieser im Einsatz bewährt hat. Dazu ist es noch etwas früh. Die hier vorgebrachten Einwände sind

87

7 Grid Services

durch eine neue Spezifikation oder aber durch die Anpassung der konkreten Systemarchitektur zu entkräften. Im Gegensatz zu CORBA sind bei Grid Services Konzepte vorhanden, welche auf eine Verbesserung in der Nutzung heterogener Systeme zielen. Grid Service Container dienen dazu, Informationen über Grid Services zu liefern, um daraus für einen Ausgleich aller Interessen in einem Grid zu sorgen. CORBA-Lösungen sind homogene Lösungen. Ähnlich wie bei der Reservierung von Übertragungsleitungen oder Bandbreiten bedarf es einer Vorausschau auf freie Rechnerkapazitäten bezogen auf Zeit und Leistung. Es sind völlig neue Preismodelle aber auch Steuermodelle zu entwickeln, denn die Wertschöpfung wird in den Ländern erbracht, in denen die Rechner stehen. In einem Grid, dessen Server prinzipiell allen zu Verfügung stehen sollen, aber Rechte erst im Falle eines Vertrages vergeben werden können, sind die administrativen Mechanismen einzurichten. Jeder Grid Service Consumer Client hat sich dann entsprechend auszuweisen.

7.6 Die Bedeutung von Grid Services für die klassische IT und das ASP Mit dem Auftauchen der Idee gekoppelter Unternehmensprozesse, des IT-Outsourcings und des Outsourcing ganzer Unternehmensprozesse laufen globale Anwendungen nicht mehr nur innerhalb von geschützten Unternehmensgrenzen ab. Vielmehr handelt es sich immer häufiger um eine Ansammlung heterogener IT-Ressourcen, die unterschiedliche Organisationen und Netzwerke überspannen. Der Grid-Computing-Ansatz unterstützt ausdrücklich auch dieses organisatorische Ziel. Er will den dabei entstehenden virtuellen Organisationen eine in jeder Hinsicht sichere Plattform liefern, sowohl für den Ablauf von Grid Services selbst als auch für die Kollaboration der Nutzer. Perspektiven für Application Service Provider Grid Services können trotz der Einwände sehr wohl eine Grundlage des Application Service Providing (ASP) werden. Das Grid, wie es von den OGSA-Standards definiert wird, ist Middleware zur kontrollierten, gemeinsamen Nutzung heterogener Computer-Ressourcen. Dazu enthält die Middleware Metainformationen und Funktionen, die sich zu einer Middleware für heterogene Systeme verbinden. Nichts anderes liegt im Interesse eines Application Service Providers und seiner Kunden. Er stellt Leistung on Demand zur Verfügung und seine Kunden profitieren von einem gut gesteuerten Ausgleich von Ressourcen. Grid Service Provisioning (GSP) bedeutet also zuerst die Bereitstellung einer Plattform, eines Grid und die Anpassung von Anwendungen an die Bedingungen dieses Grids. Durch die hohen Anforderungen an die Performance beim Zugriff auf Datenbanken im kommerziellen Bereich und den verständlichen Wunsch, die Daten nicht ohne Not nach außen zu geben, kann die Bereitstellung schneller Netze durch einen ASP ein Vorteil gegenüber seinen Konkurrenten sein.

88

8 Föderierte Datenhaltungen

• • • •

Warum genügt nicht ein einziges Datenbankmanagementsystem? Kann man Workflows auch bei Datenbanken nutzen? Wie erhält man einen einheitlichen Zugriff auf unterschiedliche Datenbanken? Wie unterstützen IBM und Microsoft die Integration von verschiedenen Datenhaltungen?

8.1 Die Idee der Integration heterogener Informationen Der Nutzen einer einheitlichen Zugriffsschicht Die Entwicklung von Datenbanken und in erster Linie von relationalen Datenbanken bewirkte einen hohen Grad an Unabhängigkeit für die Anwendungen. Neue Anwendungen können ohne Änderungen auf der Datenbank aufsetzen und die Datenbank kann geändert werden, ohne auch die bisherigen Anwendungen verändern zu müssen. Das Grundkonzept von Datenbanken sind Transaktionen, Caching, Indexing, Logging sowie Replikation und Synchronisation. Inzwischen hat das Internet zu einer Zunahme der Informationsmengen und Informationstypen geführt. Es ergibt sich der Wunsch diese über bessere Werkzeuge und eine übergreifende Schnittstelle zugänglich zu machen. Portale etwa müssen gleichzeitig auf Datenbanken, Content Server oder Data Warehouses und unterschiedliche Datentypen zugreifen. Auch die Redaktionen von Zeitschriften operieren mit ihren Syndication-Formaten in dieser heterogenen Datenwelt. In diesen Formaten werden Nachrichten zur Herstellung neuer Ausgaben gegenseitig übermittelt. Für die Suche in heterogenen Datenbeständen gibt es Abfragesprachen wie XQuery. Die Zusammenführung von heterogenen Datenquellen unter einem einheitlichen Zugriff, der Datenbank-Föderation, ist eine leistungsfähige Technologie. Eine Datenbank-Föderation nützt eine Datenbank-Engine zur Erzeugung einer internen, virtuellen Datenbank aus einer Zahl heterogener Datenbanken. Diese Technologie föderierter Datenbanken führt zu einer Erleichterung bei der Entwicklung von Anwendungen, welche mehrere unterschiedliche Datenquellen nutzen. Beispiele für Datenquellen sind relationale Datenbankmanagementsysteme, XML-Stores, Web Services, Google oder Spreadsheets. Dabei stehen lesende Zugriffe im Vordergrund. Die insgesamt anstehenden Forschungsthemen schildern Jhingram (2002) und Roth (2002). Föderierte Datenspeicher Daten werden künftig nicht mehr auf einem einzigen Server liegen. Sie werden über viele Maschinen verteilt sein und auch zu unterschiedlichen Organisationseinheiten gehören. Manchmal liegen sie sogar außerhalb eines Unternehmens selbst und sind über die Techno89

8 Föderierte Datenhaltungen

logie von Web Services zugänglich gemacht. Es ist ja so, dass manchmal eine Zentralisierung von Datenbeständen gar nicht möglich oder gewünscht ist, da rechtliche Ansprüche und kommerzielle Interessen vorliegen. In diesen Fällen bleibt keine andere Wahl, als die Daten dort zu lassen, wo sie sind, und diese föderativ zu verknüpfen, ganz analog zu den Geschäftsfunktionen (Services) eines Geschäftspartners innerhalb einer Service-orientierten Architektur (SOA). So wie die Technologie von Web Services und der Grid Services immer mehr Zuspruch finden, ist es nahe liegend, auch das Datenmanagement in dieses Framework zu integrieren. Natürlich müssen diese Daten-Web-Services die von den Datenbanken gewohnten Eigenschaften wie Zuverlässigkeit und Performanz besitzen. Das Global Grid Forum entwickelt Standards, mittels der relationale und XML-Datenbanken gesucht, genutzt und im Grid repliziert werden können. Workflows in einem Verbund von Datenbanken Es liegt nahe die Speicherung und Wiedergewinnung von einem umfangreichen Bündel zusammengehöriger Daten über einen embedded Workflow des DBMS zu steuern. Dazu gehören dann Funktionen mit automatischem Wiederanlauf bei Störungen, und das entkoppelt von den Anwendungen, welchen die Daten erzeugt haben.

Bild 8.1: Einbettung von Workflows in einen Datenbank-Server (nach IBM, modifiziert). Es gibt Tendenzen, die Integration auch in den Bereich der Datenbank-Server zu verlegen. Werden durch einen Prozess mehrere Datenbanken gleichzeitig angesprochen, so ist die Bearbeitung von verschiedenen Speicher- und Retrieval-Vorgängen im Umfeld der Datenbank ein Zeitgewinn. Komplexere Abläufe können dort über Workflows gesteuert werden. Dabei werden die Regeln wie garantierte Zustellung, gleichzeitige Zustellung an mehrere Einheiten oder die Anfrage von Timern bei Nicht-Verfügbarkeit eines Speichers genauso genutzt wie in einem Integration Server. Antworten werden akkumuliert an den Sender zurückgegeben. Der Vermittler kann ein Datenbank-Server wie DB2 II oder Yukon sein.

90

8.1 Die Idee der Integration heterogener Informationen

Wenn ein solcher Workflow unter der Kontrolle eines Datenbanksystems abläuft, erzeugt er zunächst ein Zwischenergebnis in der Form einer Datenbank-Tabelle, aus der er dann mit der Select- und Where-Anweisung eines SQL-Kommandos die notwendige Auswertung vornimmt. Der Workflow wird dabei, ähnlich einer Stored Procedure, von einem Wrapper angestoßen und über eine Flow-Engine ausgeführt (Bild 8.1). Zugriff über die Schnittstelle eines bestimmten Datenbanksystems Federated Data Access bietet einheitlichen Zugriff auf relationale und XML-Daten. Eine große Zahl von Herstellern bietet Produkte für die Suche in externen Datenbanken, Dateisystemen und sonstigen Dokumentspeichern an. Der Zugriff auf externe Datenquellen erfolgt über mit dem Datenbankprodukt mitgelieferte Wrapper. Die gleichzeitige Abfrage in verschiedenen SQL-Datenbanken ist eine komplexe Angelegenheit. Für diese föderative Suche in multiplen Datenhaltungen gibt es intelligente Query Optimizer. In keinem Fall zerstört ein föderativer Zugriff die Autonomie der einzelnen Datenquellen bzw. von deren Besitzer. Denn die Änderung der verschiedenartigen Datenbestände erfolgt vornehmlich über einen anderen Weg und unter einer anderen Verantwortung. Für den Zugriff auf besondere Datenquellen kann der Programmierer selbst Zugriffsfunktionen erstellen und in ein DBMS für die Datenföderation einschleusen. Solche Funktionen liefern als Zwischenergebnis eine Tabelle, welche dann in die normale Abfragetechnologie des DBMS, im Normalfall mittels SQL, einbezogen werden (Bild 8.2). Die Adapter der Produkte für föderierte Datenhaltungen bilden das Datenmodell von fremden Quellen auf das der zentralen Datenbank ab. Gleichzeitig werden Abfragen in die speziellen Strukturen der fremden Quellen transformiert.

Bild 8.2: DBMS-basierte Föderation von Datenhaltungen (nach IBM, modifiziert) Das Speichern in einer föderierten Datenhaltung kann über die Datenbank erfolgen. Alle Quellen erzeugen dabei im Datenbanksystem Ergebnisse in Tabellenform, welche über SQL manipuliert werden.

91

8 Föderierte Datenhaltungen

XQuery XQuery ist eine Abfragesprache für unterschiedliche Arten von Datenbeständen. Diese Bestände sind entweder direkt mit XML beschrieben oder sie werden durch entsprechende Datenbankfunktionen in XML-Strukturen transformiert und auf dieser Basis abgefragt. Mit XQuery können deswegen sowohl relationale Datenbanken als auch XML-Dokumentbestände genutzt werden. Der Ursprung von XQuery liegt in der Sprache Quilt, welche sich auf XPath, XQL, XMLQL, SQL und OQL stützt. XQuery stützt sich auf Datentypen des XML-Schema. Deshalb werden nur korrekte Abfragen an die Mechanismen der nachgelagerten Datenbanken weiter gegeben. Virtualisierung von Daten für Data Grids Im Grid Computing ist das Management des Zugriffs auf unterschiedliche Daten eine Herausforderung. Solche Daten sind verteilt und liegen in unterschiedlichen Zuständigkeitsbereichen, haben unterschiedliche Formate und oftmals eine unterschiedliche Semantik. Um auf diese Daten einheitlich zugreifen zu können, werden Data Collections gebildet, wobei die Daten selbst nicht im Grid verschoben werden. Die Data Grids stellen VirtualisierungsServices bereit. Das sind Funktionen, welche die oft sehr unterschiedlichen Datenbestände in einem einheitlichen Format anbieten und dabei sogar Unterschiede in Versionen überbrücken. Diese Virtualisierung bewahrt Organisationen vor einer ständigen Anpassung ihrer Anwendungen, also ihrer Grid Services. Probleme mit Versionen entstehen, wenn solche Daten über sehr lange Zeit benötigt werden. Ein typisches Beispiel ist die Aufbewahrung der Zeichnungen eines Flugzeugs. Ein Flugzeug ist Jahrzehnte im Einsatz und demnach müssen die Zeichnungen auch nach zahlreichen Software-Generationen noch erzeugt werden können. Entweder wird dazu die Anwendung angepasst, welche die Zeichnungen erzeugt, der Inhalt an die neue Umgebung angepasst oder alte Versionen dynamisch virtualisiert. Alte und neue Versionen sind dann föderiert.

8.2 Produkte 8.2.1 IBM DB2 Information Integrator DB2 Information Integrator (DB2II) ist der Nachfolger der Produkte DB2 UDB Rational Connect/DB2 Life Science Data Connect und DB2 DataJoiner. Im Gegensatz zu DB2 UDB, welches nur eine Federated Query über DB2- und Informix-Datenbanken bietet, dehnt DB2 II die Federated Search auf eine größere Anzahl von Datenquellen aus, selbst das Google-Portal und E-Mail Server sind darin enthalten. Das Ziel von DB2 II ist der einheitliche lesende Zugriff auf vielfältige Datenquellen in einer über SQL vereinheitlichten Datensicht. Die Daten aus den unterschiedlichen Datenquellen können direkt innerhalb einer SQL-Query miteinander verknüpft werden, ohne dass dafür Anwendungsprogrammierung benötigt wird. Häufig genutzte Datenquellen (aus heterogenen relationalen Datenbanken, z. B. DB2, Oracle, MS SQL Server, Sybase, Informix, Teradata) werden aus Performance-Gründen (in Materialized Query Tables, MQT)

92

8.2 Produkte

lokal zwischen gespeichert. Da die föderierten Datenbanken parallel von ihren eigenen Anwendungssytemen geändert werden, ist in der ersten Version die Erzeugung eines aktuellen Zustandes der MQTs über Replikationsmethoden vorgesehen. Die Replikation für die DB2-Familie geschieht über Logging, die für nicht-DB2 relationale Datenbanken erfolgt über Trigger. Eine direkte Änderung der Datenquellen (Insert) über die föderierte Schnittstelle ist bislang nur bei einer einzigen der verbundenen Datenquellen möglich. Auf der Roadmap der Entwicklung steht jedoch der gleichzeitige Update in mehreren Datenbanken, transaktionsgesichert über eine Two-Phase-Commit und außerdem XQuery. DB2 Information Integrator for Content ist als eine weitere Produktvariante des DB2 II für die Nutzung durch Content-Management-Anwendungen und im Umfeld von Portalen gedacht. Mit diesem Produkt werden Mittel für die Recherche bereitgestellt, wie die Extraktion von Namen und technischen Begriffen, die Erkennung der Sprache des Dokuments, die Bildung von Kategorien und Gruppen. Es ermöglicht den Zugriff auf unstrukturierte Informationen wie digitale Texte, XML und HTML Files, Images, Audio und Video Files, und auf strukturierte Informationen über Konnektoren zu relationalen Datenbanken, auf Datenbanken von Lotus Domino und auf Dokumente in einem Workflow. Die Workflow-Komponente gestattet die Definition von Entscheidungspunkten für Interaktionen mit einem Nutzer, für die Abfrage von Ablaufvariablen, für das Routing von Informationen mit parallelen Abläufen und von Subprozessen für iterative Tasks und von Punkten für die Synchronisation paralleler Workflows. 8.2.2 Microsoft ADO.NET ADO.NET ist ein Client-seitiger Cache, ein DataSet, der aus unterschiedlichen Datenquellen automatisch erzeugt wird. Dieser Cache ist einem Client-Prozess exklusiv zugeordnet und bei der Verarbeitung von den Datenquellen z. B. dem DBMS getrennt. Durch diese Entkopplung wird eine höhere Skalierbarkeit der Architektur erreicht. Bei Veränderung der Daten im Cache werden diese erst nach einem expliziten Kommando in den beteiligten Speichern persistent gemacht. Für die Konsistenz und Integrität des DataSet hat der Programmierer mit eigenen Mitteln zu sorgen. Das Framework unterstützt optimistisches Locking. ADO.NET ist für den Fall zugeschnitten, dass eine Geschäftsfunktion Daten aus Datenhaltungen unterschiedlichen Typs und unterschiedlicher Speicherprodukte benötigt, um diese z. B. an einen Browser im Internet auszugeben und in den Ergebnissen von Suchfragen vorwärts oder rückwärts zu blättern. ADO.NET liefert zahlreiche Adapter, Data Provider, welche die Daten in den Cache von ADO.NET einlesen (Bild 8.3). ADO.NET ist somit ein föderierter Cache. Neben zahlreichen relationalen Datenbanken werden auch XML-Dokumente in den Cache eingelesen (Bild 8.4). DataSets sind alle Ergebnisse (Tabellen) von einer oder mehreren Abfragen in den externen Datenbanken durch ADO.NET. Die Tabellen eines DataSets können über Fremdschlüssel verknüpft werden. Eine komfortable Funktion ist die der Serialisierung von DataSets. DataSets können dabei als Block an andere Server weitergereicht werden. Schemainformation für den ADO Cache. Jedem DataSet ist ein Schema zugeordnet, in dem die Datentypen in den Spalten jeder Tabelle beschrieben sind. Dieses Schema wird von Visual Studio .NET aus dem Schema einer Datenbank erzeugt. Gleichzeitig kann eine Zugriffschicht auf die Objekte (Tabellenzeilen) im Cache erzeugt werden.

93

8 Föderierte Datenhaltungen

Bild 8.3: Data Provider von ADO.NET (nach Microsoft) ADO.NET ist ein föderierter Client-Cache, welcher über unterschiedliche Datenbanken gefüllt wird. Nach dem Füllen wird der Cache von den Datenquellen abgekoppelt. Die Sicherung der Konsistenz der Daten in den Datenbanken mit denen in der aktuellen Verarbeitung obliegt allein dem Programmierer. Das Speichern von neuen Datensätzen in der Datenbank bedarf wegen der unterschiedlichen Schlüsselsysteme einiger Sorgfalt. ADO.NET ist im Gegensatz zur Technologie des SQL-Servers auf die performante Verarbeitung von spezifischen Daten aus unterschiedlichen Quellen ausgerichtet.

Bild 8.4: DataSet Cache von ADO.NET (nach Microsoft, modifiziert) Die Ergebnisse von Selects auf die Quelldatenbanken bilden Tabellen im ADO.NET Cache. Diese Tabellen können durch einfache Operationen miteinander verknüpft werden. Auf den Tabellen liegen wie in normalen Datenbanken Cursoren, mittels derer das Clientprogramm navigieren kann.

94

8.2 Produkte

Transaktionen in Verbindung mit den Datenbanken. Wenn die Daten aus einer Datenbank in den ADO Cache eingelesen sind, wird die Verbindung zu dieser Datenbank geschlossen. Alle folgenden Operationen eines Client auf die Daten im Cache sind völlig entkoppelt von denen der externen Datenquellen. Der In-Memory Cache von ADO.NET speichert vor der Änderung einer Tabelle die Originalversion, wie sie auf der externen Datenbank beim Einlesen bestand. Sollen die geänderten Daten in die Datenbank zurückgeschrieben werden, so werden die sichergestellten Originalversionen im Cache durch den spezifischen Data Provider mit dem aktuellen Zustand der entsprechenden Tabellen in der externen Datenbank inhaltlich verglichen. Wurden letztere zwischendurch nicht verändert, dann werden sie überschrieben und die Transaktion erfolgreich abgeschlossen. Werden jedoch zwischenzeitliche Änderungen in einer vorher gelesenen Tabelle erkannt, so muss auf der Ebene der Anwendung, also durch den Programmierer entschieden werden, ob es sinnvoll ist, die neuen Zeilen einer Tabelle dennoch zurückzuschreiben. Microsoft SQL Server Der MS SQL Server speichert SQL-Tabellen und XML-Dokumente. Die XML-Dokumente werden dabei als relationale Tabellen hinterlegt und Suchergebnisse können als XML-Strings ausgegeben werden. Künftig wird XML als eigener Datentyp gespeichert. Die Suche nach XML-Dokumenten erfolgt mit XPATH V2 und mittels XQuery. Die zukünftige Erweiterung des MS SQL Servers hat folgende Eigenschaften: • Programmierbarkeit mit den Sprachen von .NET auf dem Datenbank-Server Durch die Integration der CLR (Common Language Runtime)-Engine mit der Datenbank-Engine können Server-nahe Programme in C# oder VB.NET implementiert werden. • Programmierung Datenbank-naher Workflows Komplexe Abläufe können aus Gründen der Performance unmittelbar auf dem Datenbankserver angesiedelt werden. • Automatische Speicherstrukturierung Metadaten werden Anwendungen noch weiter von der konkreten Ablagestruktur für ihre Daten entkoppeln. Für die Auswertung von Massendaten, wie in Business-IntelligenceAnwendungen notwendig, oder für den Fall des Zugriffs über Suchfragen wählt der Server automatisch die dafür günstigste Speicherstruktur. • Realtime Business Intelligence Ein mehrdimensionaler Cache-Mechanismus erspart die in OLAP (Online Analytical Processing) üblichen Lade- und Aktualisierungsprozesse. MS SQL hat insbesondere Business-Intelligence-Lösungen im Fokus. Analytische Abfragen erfolgen über den Industriestandard XML/A. • Unterstützung des Business Activity Monitoring (BAM) 8.2.3 Oracle XML DB Oracle XML DB verbindet die Bedürfnisse der Verwaltung von XML-Dokumenten mit denen der Speicherung von relationalen Daten. Dabei wird einerseits ein schneller Zugriff auf komplexe XML-Dokumente erreicht und andererseits die Integration von Anwendungen über eine gemeinsame Datenbank unterstützt.

95

8 Föderierte Datenhaltungen

Oracle XML DB ist konzeptionell eine Menge von Operationen innerhalb des OracleDatenbank-Servers. Oracle XML DB fügt zur bestehenden Datenbank ein XML Repository hinzu. Eine Herausforderung bei der Verwendung einer traditionellen relationalen Datenbank zur Verwaltung von XML-Dokumenten ist die hierarchische Natur von XML. Oracle löst diese Schwierigkeit, indem es einerseits neue SQL-Operationen einführt und andererseits durch automatisches Mapping von XML-Daten auf DB-Tabellen. Die SQL-Operationen geben die Möglichkeit XPath und URL zu verwenden, XML-Dokumente abzufragen und zu aktualisieren, innerhalb der XML-Dokumente zu suchen und die Inhalte durch Trigger und Constraints zu validieren. Mit diesen Operationen ist es darüber hinaus möglich relationale Daten in XML zu speichern und weiterzuverarbeiten. Über Standardprotokolle, FTP, WebDAV und HTTP kann mit dem Server kommuniziert werden. Auf die Bestände kann also sowohl über die Navigationsfunktionen von XML als auch mittels SQL zugegriffen werden. Das Produkt überträgt Vorteile von relationalen Datenbanken auf die Manipulation von XML-Dokumenten: • Indizierung und Suche SQL kann genutzt werden, um XML-Daten abzufragen. • Updates und Transaktionen Transaktionskontrolle kann auf Teile von XML-Daten bezogen werden. • Management von Beziehungen Die im SQL-Schema gebotenen Constraints werden auf Beziehungen von Daten im XML-Dokument nutzbar. • Views auf Daten Wie bei relationalen Datenbanken üblich können Informationen auch bei XML-Daten Anwendungen gefiltert übergeben werden. • Performance und Skalierbarkeit Wenn XML-Daten intern in relationalen Tabellen vorliegen ist der Zugriff performanter, als wenn XML-Dokumente durchsucht werden müssen. Die Transformation zwischen allen internen Formaten erfolgt automatisch mit den Mitteln des Produkts. Die Dokumente können gegen XML-Schemata und DTD validiert werden. Durch XML Type Views werden existierende relationale oder Objekt-relationale Datenbanken im XML-Format zugänglich gemacht. Die Speicherart richtet sich nach den Anforderungen der Anwendung: • als CLOB XML-Dateien werden unverändert übernommen. Die gespeicherten Daten können mit Text-Indizes versehen werden und über eine Funktion gesucht werden. Nicht Schemabasierte XML-Dokumente werden immer als CLOB gespeichert. Auch als CLOB gespeicherte XML-Dokumente können mit SQL abgefragt werden. Die Abfragemöglichkeiten sind unabhängig von der Speicherungsform. Die Speicherungsform entscheidet jedoch über die Möglichkeiten des Query Optimizers und damit über die Performance. • Objekt-relational Die intern transformierten XML-Dokumente werden als Objekt-relationale Struktur gespeichert und können mittels SQL abgefragt werden. Die XML Daten werden für die Weitergabe automatisch rekonstruiert.

96

8.2 Produkte

• gemischt Teile des XML-Dokuments werden Objekt-relational, andere Teile als CLOB gespeichert. Damit kann für jeden Dokumentabschnitt die jeweils passende, für den Zugriff effizienteste Speicherungsform gewählt werden. 8.2.4 SAP TREX TREX (Search and Classification with SAP NetweaverTM) ist eine Komponente in verschiedenen Produkten (SAP Enterprise Portal, mySAP CRM Internet Sales, mySAP PLM DVS, etc.). zur Realisierung von Such-, Klassifikations- und Text-Mining-Funktionen. TREX übergreift (föderiert) unstrukturierte und strukturierte Datenhaltungen und bietet dabei Vergleiche, Ähnlichkeitssuche, unscharfe und linguistische Suche mit einem intelligenten Ranking. TREX beherrscht zwei Methoden zur automatischen Kategorisierung von Informationen. Funktionen von TREX: • Federated Search Kombination der Suchergebnisse aus unterschiedlichen Beständen. • Fuzzy Text Search Fuzzy Search bedeutet die Suche mit kleineren Einheiten (Silben) und Berechnung von Ähnlichkeiten. Damit werden Dokumente gefunden, auch wenn die Suchfrage Schreibfehler enthält. • Boolean Search Suche mit komplexen Ausdrücken und den bekannten Operatoren. • Lingusitic Search Finden von Dokumenten, in denen die Suchbegriffe in flektierten Formen genutzt werden. • Multiple Language Search Suche in zentral- und westeuropäischen Sprachen und in den vier häufigsten asiatischen und den meisten ost- und südosteuropäischen Sprachen.

97

9 Design, Monitoring und Werkzeuge föderativer Prozesse

• Welche Phasen gibt es bei der Entwicklung unternehmensübergreifender WorkflowLösungen? • Wie soll das Design eines unternehmensübergreifenden Workflows aussehen? • Was muss man beim Design beachten? • Welche Produkte unterstützen Analyse, Design, Implementierung und Monitoring?

9.1 Anforderungsanalyse und Design 9.1.1 Anforderungsanalyse Grundlage jedes Designs sind Anforderungen, denen die neu entworfene Lösung gerecht werden muss. In einem ersten Schritt müssen dazu die Ausgangssituation dokumentiert, betriebliche Abläufe festgehalten, Schwachstellen und Ursachen der gegenwärtigen Lösung identifiziert werden. Im zweiten Schritt legt eine Systembeschreibung die Funktionalität des Systems fest. Damit wird der Rahmen für die weiteren Verfeinerungen und Ergänzungen der Anforderungen abgesteckt. Diese Beschreibung soll möglichst frei sein von versteckten, später einengenden, technischen Entwurfsentscheidungen und soll nur das Was der neuen Lösung festlegen. Im Rahmen der Organisationsanalyse werden die Geschäftsprozesse des Unternehmens aufgenommen, dokumentiert und von anderen Geschäftsprozessen abgegrenzt, Schnittstellen zwischen den Prozessen und anderen Unternehmen festgelegt und schließlich die Geschäftsprozesse in einem Prozessmodell abgebildet. Unter Einbeziehung der Prozessverantwortlichen und insbesondere den vom Prozess betroffenen Personen in den Abteilungen wird der Prozess evaluiert, Schwachstellen, Liegezeiten und deren Ursachen werden ermittelt. Erhoben und analysiert werden auch die bisher eingesetzten, begrenzten Betriebsmittel (IT-Infrastruktur, Programme, usw.), die eingesetzten Hilfsmittel (Dokumente, Informationen, usw.) und die gegenseitige Abhängigkeit der Ressourcen zwischen den beteiligten organisatorischen Einheiten. Die Analyseergebnisse sind der Ausgangspunkt für die Definition von Anforderungen an eine künftige Aufbau- und Ablauforganisation. Dabei müssen Wechselwirkungen zwischen Organisationsentwicklung und Realisierung des Systems, insbesondere eines abteilungsund unternehmensübergreifenden Workflows, bedacht werden. Auch Anforderungen der Unternehmen, mit denen zukünftig in elektronischer Form kooperiert werden soll, sollen frühzeitig berücksichtigt werden.

98

9.1 Anforderungsanalyse und Design

Anforderungsanalyse Bei der Anforderungsanalyse werden die Anforderungen an den Prozess aus der Sicht des Benutzers erhoben und Anforderungen aus betriebwirtschaftlichen Erwägungen abgeleitet. In der Systembeschreibung wird festgelegt, welche fachlichen Aufgaben das System unterstützen soll. Dazu wird die Einordnung des Systems in eine Service-Infrastruktur der föderativen Organisation, also die Services von Partnern, die angebotenen Services von zentralen Abteilungen und in das Integrationsumfeld beschrieben. Die Beschreibung enthält auch quantitative Abschätzungen dynamischer und statischer Daten, die es ermöglichen, grundsätzliche technische Entscheidungen in der richtigen Größenordnung zu treffen (Netzauslegung, Rechnerkapazitäten, usw.). Hinsichtlich der Sicherheit können Ziele zum Schutz von Funktionen oder verarbeiteter Informationen festgelegt werden. Anforderungen an die Verfügbarkeit, Integrität und Vertraulichkeit werden beschrieben oder eine Sicherheitspolitik vorgegeben, die im Gesamtsystem durchgesetzt werden soll. Darüber hinaus können nicht funktionale Anforderungen an die Performanz (Durchsatz, Reaktionszeit), Verwendbarkeit, Modifizierbarkeit, Portabilität, Wiederverwendbarkeit, Integrierbarkeit und Testbarkeit festgehalten werden. 9.1.2 Design der Lösung Eine Workflow-Lösung ist eine Maßnahme, ein Konzept zur Verknüpfung von Menschen, Aufgaben und Technik zu einem Ganzen. Die aus Sicht des Gesamtunternehmens mehr oder weniger künstlichen Tätigkeits-, Funktions- und Abteilungsgrenzen werden in ihren Auswirkungen zurückgedrängt. Der Nachrichtenfluss wird zum wahren Abbild der tatsächlichen Zusammenhänge der Vorgänge im Unternehmen. Verantwortung wird zur Verantwortung für einen Workflow. Mit den Anwenderforderungen als Ausgangspunkt wird der Lösungsvorschlag für eine technische Struktur des Systems, die Systemarchitektur, erfunden (Bild 9.1). Die Definition der Systemarchitektur stellt zunächst den technischen Aufbau des Systems dar und identifiziert Komponenten und die Schnittstellen zwischen den Komponenten der Architektur und denen des Gesamtsystems nach außen. Dann beschreibt die Architektur die Dynamik des technischen Ablaufs, die Interaktion zwischen den Komponenten der Architektur. Im Entwurf wird also das Wie der Lösung bestimmt. Im Rahmen unserer Betrachtung des statischen Aufbaus meinen wir immer eine Service-orientierte Architektur (vgl. Kapitel 4.5). Komponenten sind also grundsätzlich Services oder Web Services. Augenmerk wird beim Design von neuen Lösungen ganz besonders auf die Möglichkeit des Einsatzes von vorhandenen Services gelegt. Die Komponenten des Systems sollen daher so früh wie möglich technisch beschrieben werden, um geeignete vorhandene Services aufspüren zu können. Die Festlegung der Systemarchitektur muss unter der Maßgabe erfolgen, möglichst bewährte Fertigprodukte, z. B. SAP R/3, und Services einzusetzen. Die statischen Komponenten, hier Services genannt, werden in diesem Schritt identifiziert und im System positioniert. Workflow-Management-System, Application Server, Web Server, Legacy-Systeme und die Firewall finden ihren Platz im System.

99

9 Design, Monitoring und Werkzeuge föderativer Prozesse

Bild 9.1: Vorgehensweise bei einer Service-orientierten Entwicklung. Im Vordergrund einer Service-orientierten Entwicklung steht die Suche nach bereits vorhandenen Teilen einer künftigen Lösung. Die gefundenen Teile müssen einer strengen Kontrolle unterzogen werden, ob sie für die Lösungen geeignet sind oder ob eine Anpassung des geplanten Lösungsmodells erforderlich ist, ob sie verfügbar sind und alle notwendigen Service-Level Agreements (SLAs) getroffen werden können, ob sie die Autonomie des Unternehmens beeinträchtigen und ob sie semantisch und technisch mit allen übrigen Teilen einer Lösung integriert werden können.

Architektur von Workflow-gesteuerten Service-Aggregationen Beim Entwurf der Prozessorganisation werden die dynamischen Aspekte detailliert. Die auszuführenden Aktivitäten werden festgelegt und beschrieben. Der Zweck der Aktivitäten, Eingangs- und Ausgangsinformation, die angestrebten Ergebnisse, Richtlinien und Verfahren für die Aufgabenerfüllung, einzusetzende Hilfsmittel und Informationen sowie einzusetzende Betriebsmittel (inkl. IT-Anwendungen) werden festgelegt. Die Formate der zu bearbeitenden Daten und Dokumente werden spezifiziert, der Inhalt der Informationsflüsse und auslösender Ereignisse definiert, die Abfolge der Funktionen sowie beteiligter Arbeitsplätze, Organisationen und Systeme festgelegt. Die beteiligten Organisationseinheiten werden also bestimmt, der Informationsfluss und der Prozessablauf werden festgelegt. Swimlane-Diagramme der Modellierungswerkzeuge unterstützen bei der Zuordnung der beteiligten Organisationen und Rollen zu den Aktivitäten. Das ist der herausfordernde Teil des Entwurfs. Hier muss entschieden werden, welche Teile der Steuerung als Algorithmen in die Module verpackt werden und welche Teile explizit im Workflow abgebildet werden können. Hier die richtige Auflösung zu finden, ist entscheidend dafür, ob eine ausgewogene Balance zwischen Flexibilität und Komplexität der Anwendung gehalten werden kann. Hier gilt es auch die richtigen Schnitte zu setzen und

100

9.1 Anforderungsanalyse und Design

technisch und fachlich sinnvolle Pakete von Funktionalität aus Legacy-Systemen zu lösen. Eine Aufgabe, die von einem Architekten sehr viel Weitsicht erfordert. An dieser Stelle des Vorgehens kann der Versuch unternommen werden, den Geschäftsprozess zu optimieren und die Kosten und die Durchlaufzeiten zu reduzieren. Die Schwachstellen, die in der Ist-Analyse festgestellt wurden, werden beseitigt. Bei der Gestaltung des Prozesses werden zunächst im günstigen Fall keine technischen, finanziellen oder organisatorische Restriktionen berücksichtigt. Die Aktivitäten werden so festgelegt, wie es aus Sicht der Kunden und der Betriebswirtschaft am zweckmäßigsten ist. Leitlinie zur Verbesserung des Prozesses Allgemeine Regeln zur Verbesserung des Prozesses, die im konkreten Fall auf Sinn und Realisierbarkeit überprüft werden müssen, sind: • Aktivitäten automatisieren, wo es nur eben geht. Manuelle durch IT-gestützte Bearbeitung oder noch besser automatische Bearbeitung ersetzen. Den Kontakt zu Kunden und Lieferanten durch automatische, elektronische Abwicklung von Standardvorgängen vereinfachen. Daten dort erfassen, wo sie entstehen. • Aktivitäten parallelisieren. Die Durchlaufzeit kann verringert werden, indem Aktivitäten, die voneinander unabhängig sind, parallel bearbeitet werden. • Die Zahl der Aktivitäten verringern, die nicht zur Wertschöpfung des Unternehmens beitragen. • Die Zahl der Schnittstellen verringern. Verzögerungen durch die Übergabe von Vorgängen von einem System, von einem Bearbeiter zum nächsten vermeiden. Der Feinentwurf Die Aufrufe der einzusetzenden Services und IT-gestützter Methoden werden detailliert und die Aufrufreihenfolge der Anwendungen festgelegt. Beim Entwurf unternehmensübergreifender Workflows und generell innerhalb der Serviceorientierten Architektur muss man stets im Auge behalten, dass die eigentliche Entwicklungsleistung das Finden und Erkennen funktionell und technisch geeigneter Services ist. Findet man keinen passenden Service, muss einer entwickelt werden. Die Lokalisierung von Services An dieser Stelle des Vorgehens muss entschieden und festgelegt werden, welche Services selbst entwickelt werden, ob eigene Systeme mit Service-Schnittstellen versehen, Services von Partnern eingesetzt werden oder Services fremder Anbieter genutzt werden sollen. Die einfachste, statische Form der Lokalisierung von Services ist, wenn Service und Anbieter bekannt sind, etwa bei Nutzung einer SAP R/3-Lösung. In diesem Fall können – wenn sie nicht bereits Teil einer Rahmenvereinbarung sind – in Verhandlungen von Angesicht zu Angesicht verbindliche Vereinbarungen zum Service-Level Agreement (Nutzungsgebühr, Verfügbarkeit, Wartung, Gewährleistung) getroffen werden. Der Verhandlungspartner wird zum Provider, welcher die Standardlösung für die Nutzung als Service angepasst hat (Web Service, Web BAPI). Fragen der Implementierung und Semantik der Services können geklärt werden.

101

9 Design, Monitoring und Werkzeuge föderativer Prozesse

Eine entscheidende Frage, die es dabei zu beantworten gilt, ist: Passt der Service semantisch zur Lösung? Hier ist immer eine generelle Skepsis angebracht, da betriebswirtschaftliche Services neben Eigenheiten der Architektur, die sich in den Protokollen spiegeln, auch eventuell kulturell bedingt unterschiedliche Elemente enthalten. Die Semantik des gefundenen Service muss mit den Anforderungen und damit der Semantik der neuen Lösung harmonieren. Die Auswirkungen konkurrierender Zugriffe auf Daten durch den Service einerseits und die herkömmliche, gleichzeitige interaktive Nutzung durch einen Anwender müssen beim Entwurf in ihren Konsequenzen untersucht und bewertet werden. Alternativ kann ein Kandidat für einen Service während des Entwurfs oder gar zur Laufzeit durch eine Suche in einem lokalen Verzeichnis, in einem privaten oder öffentlichen UDDIVerzeichnis lokalisiert werden. Zur Suche nach Services kann auf UDDI zurückgegriffen werden. UDDI (Universal Description, Discovery and Integration) ist auf der einen Seite ein globales Verzeichnis von Web Services und auf der anderen Seite ein Protokoll, mit Hilfe dessen Unternehmen ihre eigenen Web Services in diesem Verzeichnis registrieren können. UDDI stellt für die Entwicklung von Service-basierten Lösungen die Kontaktinformationen der Unternehmen, die angebotenen Web Services kategorisiert nach Standard-Taxonomien und technische Informationen über die Services bereit. Entwicklung eigener Services Stellt sich heraus, dass der für eine neue Lösung benötigte Service weder im eigenen Unternehmen noch im Internet oder bei einem Partner verfügbar ist, muss dieser neu entwickelt werden. Modellieren von Funktionen mit der Unified Modeling Language Im Feinentwurf werden die neu zu entwickelnden Services algorithmisch spezifiziert und die Eingangs- und Ausgangsinformationen (APIs, WSDL, Parameter, Messages, SOAP) festgelegt. Die Unified Modeling Language (UML) ist eine graphische Modellierungssprache zur objektorientierten Modellierung von Komponenten. Daneben existieren andere Verfahren die dem Konzept des strukturierten Entwurfs folgen. Die Sprachelemente der UML lassen strukturelle, verhaltens- und zustandsorientierte Aspekte objektorientierter Modelle beschreiben. Mit UML wird das Modell des Service aus verschiedenen Perspektiven modelliert (vgl. Erikson et al. 2004). Design von Datenstrukturen Daten werden vorwiegend mittels eines Entity-Relationship-Modells beschrieben, dann unter Berücksichtung der Anforderungen an die Performanz normalisiert und auf das Schema einer relationalen Datenbank abgebildet. Für die Überführung von Objekt-Klassen auf relationale Speicherstrukturen gibt es Werkzeuge und Bibliotheken, welche bei der Transformation die wichtigen dynamische Aspekte berücksichtigen. Bild 9.2 zeigt die beiden Wege des Zugriffs auf die mit UML spezifizierten Klassen einer betriebswirtschaftlichen Anwendung. Die Interaktion mit einem Agenten wird dabei als UML-Use-Case spezi-

102

9.1 Anforderungsanalyse und Design

Bild 9.2: Design-Sprachen und Methoden für Workflow-Lösungen. Die verschiedenen Elemente eines Service werden mit unterschiedlichen Beschreibungsmitteln entworfen werden. Die betriebswirtschaftlichen Funktionen werden als Klassen (UML) entwickelt, welche sowohl von der Dialoganwendung eines Workflow-Agenten (WSDL) wie auch von einer Workflow-Aktivität (BPEL) direkt verwendet werden. Beiden Ansprüchen müssen die Datenstruk-turen (ERM) in der Datenbank genügen, deswegen werden sie aus Gründen der Performance am besten zuerst entworfen.

fiziert. Automatische Aktivitäten werden wie von BPEL gefordert über WSDL-APIs angeschlossen. Dokumente können in XML-Stores gespeichert werden, ohne dass die aufwändige Prozedur der Normalisierung benötigt wird. Workflow Performance Gannon (2002) weist zu Recht darauf hin, dass es nicht in jedem Falle ratsam ist, den Datenaustausch zwischen Funktionen über einen dazwischengeschalteten WorkflowMechanismus zu bewerkstelligen. Wenn der Nachrichtenaustausch sehr intensiv ist, kann dies leicht zu Performance-Problemen führen. Dann sind im Einzelfall direkte Aufrufe oder sonstige Mittel einer Programmiersprache leistungsvoller. Dieser Entscheidung kann der Architekt speziell dann treffen, wenn sich die Funktionen auf ein und demselben Server befinden, in ein und derselben Sprache programmiert sind und wenn kein Monitoring des Ablaufs benötigt wird. Sicherheit Während des Designs ist das Autorisierungsverfahren zwischen Service und der Datenbank festzulegen. Zu diesem Zweck sollen immer spezielle Benutzer mit sehr limitierten Rechten verwendet werden. Die Verbindung zur Datenbank darf dabei nie als Superuser oder Owner der Datenbank hergestellt werden. 103

9 Design, Monitoring und Werkzeuge föderativer Prozesse

Zur Festlegung der Zugriffs- und Änderungsrechte von Daten müssen verschiedene Benutzergruppen mit unterschiedlichen Rechten definiert werden. Sicherheitsrelevante Angriffe auf Services basieren hauptsächlich auf dem Ausnutzen von Programmcode, welcher im Hinblick auf die Sicherheit geschrieben wurde. Jeglichen Daten, die von außen kommen, muss grundsätzlich misstraut und kontinuierlich auf Plausibilität überprüft werden. Nie darf Information ausgegeben werden, die Rückschlüsse auf die Datenbank selbst oder das Datenbankschema im Speziellen erlaubt. Stored Procedures und andere Mechanismen erlauben es den Datenzugriff zu abstrahieren, sodass der Benutzer des Service nicht direkt auf Tabellen oder Views zugreifen kann. Alle Zugriffe sollten protokolliert werden. Die Protokollierung verhindert zwar nicht den Missbrauch. Sie hilft jedoch die Schwachstelle zu identifizieren. Concurrency Control Damit die Zuverlässigkeit der Datenbank bei vielen gleichzeitigen Transaktionen erhalten bleibt, muss das System die Interaktion zwischen konkurrierenden Transaktionen mittels sinnvoller Lese- und Schreibsperren (Locking) kontrollieren und koordinieren. Ein solches Modell, basierend auf Sperrmechanismen, bezeichnet man als Concurrency Control. Ein feingranulares Transaktionskonzept, das Locking auf Datenebene unterstützt, steigert die Zahl gleichzeitig möglicher Zugriffe und erhöht die Performance des Systems. Es muss verhindert werden, dass ein Service Daten länger als unbedingt erforderlich sperrt. Service-Schnittstellen für Legacy-Applikationen Web-Service-Technologie ist generell eine Technologie, auch Funktionen existierender Anwendungen zu kapseln und als Web Services darzustellen. Funktionen bestehender Anwendungen, die z. B. mit COBOL oder Natural programmiert wurden, werden in Web Services umgewandelt und gekapselt. Die Kunst der Adaption ist dabei eine zweifache: • Wie kann man eine Transaktionssicherheit erreichen, wenn von der Anwendung meistens kein Transaktions(TA)-Protokoll unterstützt wird? Dieses Problem ist besonders kritisch, wenn die Integration über eine Terminalschnittstelle erfolgen muss. Hier muss aus der Reaktion des Dialogs erkannt werden, wann eine TA erfolgreich abgeschlossen ist und wie sie zurückgesetzt werden kann. • Welcher Teil der Funktionalität an der gesamten Schnittstelle eines Legacy-Systems eignet sich generell als künftiger Web Service? Hier gilt es die richtige Modularität, den richtigen Auflösungsgrad zu finden. Implementieren der Services Zur Implementierung von Services und Service Clients (Consumer) werden von verschiedenen Herstellern Werkzeuge, Frameworks und Generatoren angeboten. Die Implementierung eines Service kann in verschiedenen Programmiersprachen und mit der Unterstützung der Middleware eines Application Server und von Frameworks erfolgen, je nach der Plattform, auf welcher der Service ablaufen soll. Zunehmend entstehen Frameworks, welche bereits die ersten Web-Services-Protokolle aus dem Standard unterstützen.

104

9.1 Anforderungsanalyse und Design

Bei der konkreten Entwicklung eines Web Service werden technische Entscheidungen getroffen, welche unmittelbare Auswirkungen auf die spätere Entwicklung von Clients haben. Services prägen also die Architektur der künftigen Clients. Wird etwa ein Web Service intern von einem BPEL-Workflow gesteuert, so muss ein Client dessen externe Choreographie und dessen interne Zustandsverwaltung berücksichtigen. Wird ein Web Service mit J2EE oder CORBA implementiert, ergeben sich durch die dort gegebene Zustandsverwaltung ähnliche »Fernwirkungen«. Schmidt und Vinoski (2001) unterstreichen deutlich die lebensnotwendige Abhängigkeit der Web-Service-Technologien von den bestehenden Technologien wie CORBA und J2EE. Basistools und Generatoren: Die Programmierung eines einfachen Web Service erfolgt bei leistungsfähigen Werkzeugen (z. B. .NET Visual Studio) dadurch, dass der Entwickler bei der Definition einer Klasse im Sourcecode markiert, welche Funktionsaufrufe er von einem Web Service Client aus nützen will. Er legt fest, unter welcher URL der Service angesprochen werden soll. Alle Schnittstellen werden automatisch in WSDL exportiert. Auf der Seite des Clients erzeugt ein Generator eine lokale Client-Proxy-Klasse, mit der der ClientEntwickler prinzipiell so umgeht, als wäre der Service lokal auf seinem Client. BPEL als Design-Sprache: Enthält ein Service ein etwas komplexeres Ablaufschema als Request/Reply und bedarf es eines Dialogs mit dem künftigen Client, so ist BPEL gut geeignet diesen »Use-Case« zu spezifizieren. Das dabei entstehende Dokument zeigt das externe Verhalten des Service. Granularität von neuen Services: Ein recht anspruchsvolles Thema ist die Festlegung der Granularität eines Service. Es ergeben sich Interessenkonflikte in der Weise, dass • es bei kleiner Granularität zu vielen Services kommt, welche zwar leichter wiederverwendet werden können, welche jedoch leicht zu einer Einbuße an Performanz führen. Alle Aufrufe müssen über den Workflow als Mediator geleitet werden (vgl. Fielding 2000); die Verteilung im Netz wird erschwert. • es bei grobgranularen Services leichter ist, diese im Netz zu verteilen. Dies schränkt aber die Wiederverwendbarkeit ein. Kommunikation in einer Service-orientierten Architektur: SOA legt fest, dass ein Service über ein Netzwerk aktiviert werden kann. Die Wahl der Art der Kommunikation zwischen einem Service und seinen künftigen Clients trifft der Architekt in einer Projekt-spezifischen SOA. Wesentliches Entscheidungskriterium ist die Performanz. Das Protokoll, mit dem ein Service angesprochen werden kann, wird in der WSDL-Beschreibung des Service vermerkt. Nutzung von Plattformen und WS Frameworks: Durch die übliche Middleware und eine geeignete Programmiersprache wird der Anwendungsteil des Service realisiert. Im Normalfall wird ein Application Server und eine der objektorientierten Sprachen Java oder C# zur Implementierung gewählt. Um die besonderen Anforderungen von Web Services zu befriedigen, welche unternehmensübergreifend eingesetzt werden, entstehen Frameworks, welche wie Filter arbeiten und auf die Erzeugung und Interpretation von SOAP-Nachrichten ausgerichtet sind. Diese Frameworks betreffen Security, Routing und die Identifizierung bei Transaktion, etc. (siehe Kapitel 6). Entwicklung von Web-Service-Adaptern zu Legacy-Systemen: Diese Tätigkeit ist eine der anspruchsvollsten und kann zweifellos als künstlerisch bezeichnet werden. Wir können

105

9 Design, Monitoring und Werkzeuge föderativer Prozesse

hier nur Fassetten davon aufscheinen lassen. Die »Bezähmung« einer bestehenden Anwendung hat das Ziel, die oft nicht vollständig verstandene Semantik für einen künftigen Web Service und für eine allgemeine Anwendbarkeit zu straffen. Dies geschieht mit Ausrichtung auf die Bedürfnisse künftiger, nicht immer bekannter Nutzer und mit einem Blick auf den gesamten Bebauungsplan eines Unternehmens. Veröffentlichen der Services Zur Teilnahme an einem föderativen Netzwerk ist es notwendig, die öffentliche Sicht der Choreographie und die WSDL-APIs der eigenen Services mit denen der Partner auszutauschen. Das gibt dem Partner seinerseits die Möglichkeit eigene Anwendungen (Consumer, Clients) zu entwickeln und dabei die Abfolge des betreffenden Nachrichtenaustauschs einzuhalten. Entwurf von unternehmensübergreifenden Workflows Beim Entwurf von Workflows wird traditionell in zwei Schritten vorgegangen: Der erste Schritt umfasst die grafische Modellierung des Workflows, im zweiten Schritt werden den Aktivitäten die Funktionen zugeordnet und der Fluss der Nachrichten zwischen den Aktivitäten festgelegt. Die Integration und Synchronisation von Daten läuft also primär nicht über die Datenbank, sondern über den Austausch von Nachrichten, die von den Services, eigentlich den oben genannten Funktionen, in eigener Verantwortung persistent gemacht werden. Die Schritte der Workflow-Entwurfs (Bild 9.3): • Erstellen des Workflow-Modells als Beschreibung der automatisierbaren Abläufe in einem Geschäftsprozesses. • Implementieren des Workflows durch die Verbindung bestimmter Aktivitäten innerhalb des Modells mit so genannten Ports. Port ist ein Begriff aus WSDL. Ports repräsentieren Stellen im Workflow, von denen aus Nachrichten gesendet werden oder die Nachrichten empfangen werden. Der Nachrichtenversand kann an dieser Stelle an Service Komponenten, automatische Participants, oder an menschliche Participants, Agenten, gehen. Die Nachrichten stellen die Daten dar, die zwischen Aktivitäten und Ports übertragen werden. Die Choreographie repräsentiert die einzelnen Schritte des Workflows und deren genaue Reihenfolge zur Erreichung des Zieles. Die Choreographie eines Service ist die Sicht von Außen und wird aus der internen Sicht abgeleitet. Die Choreographie kann aber auch als Spezifikation für einen noch zu implementierenden Workflow, als eine Art Use-Case, aufgefasst werden. • Definieren des Nachrichtenflusses innerhalb des Workflows. Dazu gehören: – Analysieren und Überprüfen eingehender Nachrichten. – Überwachen ein- und ausgehender Nachrichten. – Erzeugen und Korrelieren von Empfangsbestätigungen mit den Daten beim Aussenden der verursachenden Nachricht. – Sicherstellen von Datenintegrität und -sicherheit. • Festlegen der Rechte für beteiligte Arbeitsplätze und Systeme. • Exportieren des Workflow-Modells aus dem Werkzeug in der Form von BPEL zur Weiterverwendung in einem Workflow-Management-System

106

9.1 Anforderungsanalyse und Design

Bild 9.3: Workflow-Modellierung und Ausführung. Tools der Designer für die Modellierung von Prozessen versorgen je nach dem technischen Reifegrad die Laufzeit-Datenbank der ausführbaren Workflows. Im sich ergebenden Workflow werden menschlichen Agenten Tätigkeitslisten zugespielt. Gleichzeitig stehen diesen auch bestimmte Anwendungen zur Verfügung, welche sie zur Erfüllung ihrer Aufgaben nutzen. Der Einsatz einer Laufzeit-Datenbank in einem BPMS ermöglicht die Mitführung von LoggingDateien und damit eine flexible Überwachung und Verbesserung der Abläufe.

Die Gestaltung föderativer Unternehmensprozesse verlangt nicht nur nach einer allgemein akzeptierten Modellierungsmethode mit eindeutiger Semantik, sie verlangt auch nach Weiterverwendung des Ergebnisses der Modellierung in Entwicklungs- und Produktivsystemen. Die Werkzeuge zur Modellierung sind verfügbar. Business Process Execution Language (BPEL) zur Notation der Prozesse ist standardisiert. Die damit erstellten Prozessmodelle können unmittelbar auf Workflow Engines ausgeführt werden. BPEL ist einerseits ausführbar, jedoch gleichzeitig als Basis zur grafischen Darstellung des Prozessmodells verwendbar. Die grundsätzliche Vorgehensweise haben wir hier skizziert. Es bedarf jedoch tiefergreifender Überlegungen für eine Entwicklungsmethode im Umfeld von SOA. Design von Clients (Consumer) und GUI Normalerweise werden End-User-Dialoge als Zustandsautomaten implementiert, da nur so die notwendige Performance und Flexibilität in der Dialoggestaltung erreicht wird. Es gibt zahlreiche Visual-Tools, welche auf die Gestaltung von GUIs ausgerichtet sind und welche als Framework alle notwendigen Steuerungsfunktionen mitliefern. Die notwendigen Aktionen, etwa das Zwischenspeichern von Eingaben werden einfach als Aufrufe bei den Bedienelementen hinterlegt. Beim Abschluss einer Interaktionssequenz wird dann ein Ergebnisdokument zusammengebaut und ggf. an das Workflow-System übergeben.

107

9 Design, Monitoring und Werkzeuge föderativer Prozesse

An Arbeitsplätzen kann eine Vielzahl unterschiedlicher Geräte zur Interaktion mit dem Workflow genutzt werden: Menschliche Participants verwenden stationäre und mobile Geräte. Voice Recognition oder Barcode-Leser können den Workflow steuern. Daneben können automatische Sensoren und Zustandsänderungen in Systemen Einfluss auf die Steuerung nehmen. Multichannel Integration Server und Multidevice Frameworks unterstützen dabei. Wenn ein Workflow die Beteiligung eines Menschen erfordert, so geschieht dies über das Portal, in welchem einer Work-List in einem Portlet ein neues Item hinzugefügt wird. Diese Worklist dient als Launch Pad für das Tool, welches der Erfüllung der Aufgabe dient. 9.1.3 Integration, Test und Inbetriebnahme In der letzten Phase der Entwicklung eines föderativen Prozesses erfolgt die Integration der Services unterschiedlicher Herkunft und mit unterschiedlichen Besitzrechten mit dem Workflow und den anderen Elementen der Systemarchitektur. Die Komponente (Service) wird auf der Ziel-Hardware unter annähernd realen Bedingungen durch Simulation der Systemumgebung und mit Unterstützung von Diagnose-Werkzeugen getestet. Es kann natürlich sein, dass auch ein Partner in Verbindung mit dessen Service online in den Test einbezogen wird. Der Test erfolgt im Hinblick auf: • Synchronisation und Kommunikation der Aktivitäten und Services • Fehlererkennung und -toleranz Der Test des gesamten Systems sollte umfassen: • Test gegen die Anwenderforderungen und die Systemarchitektur. • Test des technischen und funktionalen Zusammenwirkens mit dem Hauptaugenmerk auf: – Systembelastung hinsichtlich Effizienz und Robustheit – Verhalten in »Worst-Case«-Bedingungen – Demonstration der Systemsicherheit – typische Situationen und Bedingungen – kritische Situationen und Funktionen Schließlich folgen alle Tätigkeiten, die notwendig sind, um das fertig gestellte System an der vorgesehenen Stelle zu installieren und in Betrieb zu nehmen.

9.2 Management- und Modellierwerkzeuge 9.2.1 Business-Process-Management-Produkte BEA – WebLogic Enterprise Platform Die BEA WebLogic Enterprise Platform stellt die Infrastruktur bereit, mit der sich interne und externe Informationsflüsse vereinfachen und Unternehmen intern und unternehmensübergreifend in Systeme einbinden lassen. Kernkomponente dieser Infrastruktur ist der WebLogic Server. Weitere Bestandteile sind die Portal-Lösung WebLogic Portal, WebLo-

108

9.2 Management- und Modellierwerkzeuge

Bild 9.4: Die Produkt Suite von BEA. Kernkomponente der WebLogic Enterprise Platform ist der WebLogic Server. Hinzu kommen die Portal-Lösung WebLogic Portal, WebLogic Integration, die Entwicklungs- und Implementierungsumgebung WebLogic Workshop.

gic Integration, die Entwicklungs- und Implementierungsumgebung WebLogic Workshop und WebLogic JRockit, eine administrierbare Java Virtual Machine. Daneben bietet das Informations-Integrations-Produkt Liquid Data for WebLogic Zugriff auf Daten aus heterogenen Quellen (Bild 9.4). WebLogic Integration unterstützt die üblichen Komponenten der Geschäftsintegration: Geschäftsprozess-Management, Datentransformation, Connectivity, Message Brokering und Benutzerinteraktion. WebLogic Integration liefert diese Funktionen im WebLogic Workshop Framework: Web Services, Business Process Management, Workflow Designer, Daten-Transformation und Message Broker. WebLogic Integration nutzt Schlüsselstandards: die Java Connector Architecture (JCA), Java Messaging Service (JMS), Web Services Standard, inklusive SOAP, WSDL und dem UDDI Standard. BEA WebLogic Integration besteht aus einem Framework und einem Adapter Development Kit. Das Framework stellt die Technologie für die Koordinierung von Nachrichten zwischen Anwendungen zur Verfügung. Das Übermittlungsprotokoll basiert auf XML. Web-Services-Unterstützung: Die Automatisierung von lange laufenden Geschäftsprozessen setzt die Integration und Orchestrierung von unterschiedlichen Anwendungen voraus, die auf getrennten Systemen ablaufen. Die Process Engine von WebLogic Integration steuert Prozessschritte, die menschliche Interaktion benötigen, führt aber auch automatische Prozessschritte durch. Automatische Prozessschritte können Dienste von Java-Anwendungen, JCA-Schnittstellen zu Nicht-Java-Anwendungen und Web Services sein. Anwender können den Geschäftsprozess in Echtzeit überwachen und Reports über das Leistungsverhalten der Prozesse erstellen.

109

9 Design, Monitoring und Werkzeuge föderativer Prozesse

Business-Process-Management-Unterstützung: WebLogic Integration BPM (Business Process Management) erlaubt dem Anwender Geschäftsprozesse zu modellieren und auszuführen, die sich über unterschiedliche interne und externe Systeme und Ressourcen spannen. Aus dieser Perspektive ist das Unternehmen eine Menge von Services, die – um einen Geschäftsprozess zu bilden – manipuliert und über Controls genutzt werden. WebLogic Integration unterstützt synchrone und asynchrone Kommunikation und zustandslose und zustandsbehaftete Prozesse. Data Transformation: Integration WebLogic liefert Bestandteile und Werkzeuge für Datenumwandlung. Message Brokering: WebLogic Integration bietet einen Message Broker an, der es Geschäftsprozessen ermöglicht, anonym miteinander in Verbindung zu treten. BPEL-Unterstützung: BEA unterstützt Java Business Integration (JBI) mit SPIs (Service Provider Interface). Die SPIs ermöglichen die Entwicklung einer Java-GeschäftsprozessIntegrationsumgebung für WSCI und BPEL4WS. WebLogic Platform stellt ein BPELInterface, so dass BPEL-Definitionen in die WebLogic Platform BPM-Umgebung importiert werden können. IBM – WebSphere Business Integration Die Plattform WebSphere Business Integration (WBI) ist eine Sammlung von integrierbaren Standardprodukten zur Zusammenführung von Anwendungen und zur Abwicklung von Geschäftsprozessen innerhalb und zwischen Organisationen. Die Produkte werden projektspezifisch nach den Anforderungen und Einsatzszenarien des existierenden Systems und der Gesamtarchitektur des Unternehmens zusammengestellt. Das Vorgehensmodell enthält jedenfalls die Schritte Modelling, Integrating, Connecting, Monitoring und Managing. Das Produkt-Portfolio von IBM befindet sich in ständiger Erweiterung, die Funktionalität der Produkte wird ausgedehnt und neue Standards werden implementiert. • WBI Modeler and Monitor Das grafische Werkzeug unterstützt die Modellierung, die Simulation und die Anpassung von Geschäftsprozessen. Analysefunktionen ergeben Aufstellungen über die zu erwartenden Kosten, die Zykluszeiten und die Auslastung der Ressourcen. Die so entstandenen Modelle werden in den WBI MQ Workflow importiert. Der WBI Monitor sammelt zur Laufzeit des WBI MQ Workflow Daten über Durchlaufzeiten und die wirkliche Ressourcen-Belastung des Geschäftsprozesses. • WBI MQ Workflow integriert die Arbeitsabläufe zwischen Menschen. Ein damit geschaffener Workflow regelt die direkten Arbeitsschritte, z. B. die von Reviews, und regelt Verantwortungen und Ausnahmen. Es gibt eine automatisierte, optimierte Aufgabenverteilung (Staff Resolution), History- und Audit-Trails. Die MQ Workflow-Technologie enthält die Unterstützung von GUI-Clients, die Unterbrechbarkeit der Workflows und ihre parallele Bearbeitung. Durch die Workflows kann navigiert werden und der Status von Prozessen kann abgefragt werden. Die Integration mit Anwendungen erfolgt über Web Service Interfaces. • WBI InterChange Server and Monitor definiert automatisierte Geschäftsprozesse zur Integration von unterschiedlichen Anwendungen innerhalb und außerhalb des Unternehmens. Dazu und zur Synchronisierung der

110

9.2 Management- und Modellierwerkzeuge

Bild 9.5: WebSphere Business Integration von IBM. WebSphere Business Integration bietet Software-Komponenten zur Definition, Steuerung und zum Monitoring von Geschäftsprozessen innerhalb und zwischen Organisationen.

Datenbestände nutzt der WBI InterChange Server WBI Adapter für Read- und UpdateOperationen, welche die Daten auf ein Zwischenformat transformieren und von dort auf die Schnittstellen von Standardlösungen wie SAP, Clarify, BroadVision und Oracle abbilden. Das Konzept der Synchronisationsprozesse wurde von Siebel in deren UAN übernommen. WBI InterChange Server integriert Web Services und stellt Workflows als Web Service bereit. Die Java-basierte Workflow Engine unterstützt BPEL4WS für Import/Export. BPEL-Prozesse von Siebel UAN (Universal Network Architecture) können künftig darauf direkt ausgeführt werden. WBI Modeler and Monitor besitzt eine Brücke für den Austausch von Workflow-Definitionen mit dem WBI InterChange Server. • WBI Message Broker verteilt Nachrichten nach dem Publish and Subscribe Prinzip. Der WBI Message Brocker entlastet die integrierten Anwendungen vom Routing und dem Mapping der Nachrichtenformate und nutzt die WBI Adapter für Read- und Update-Operationen. • WBI Adapter ist eine Sammlung von Adaptern zu Anwendungen (z. B. SAP, Siebel), TechnologieAdaptern (z. B. SWIFT, JMS, XML) und Mainframe-Adaptern (z. B. ADABAS, CICS, IMS). • WebSphere Business Connection/Data Connection sind Gateways zum Management von B2B-Protokollen wie EDI oder Web Services (Bild 9.5). Microsoft BizTalk™ Server 2004 Die Produktfamilie BizTalk™ Server stellt Werkzeuge zur Integration von Unternehmensanwendungen, zur B2B-Integration und zur Orchestrierung von Geschäftsprozessen bereit

111

9 Design, Monitoring und Werkzeuge föderativer Prozesse

(Bild 9.6). Über die Entwicklungsumgebung Visual Studio.Net können lose gekoppelte Systeme sowohl innerhalb des Unternehmens als auch zwischen Unternehmen (B2B) in Geschäftsprozesse eingegliedert werden. Mit dem Orchestrierungswerkzeug werden die Geschäftsprozesse modelliert und die Integrationslogik verwaltet. Messaging-Dienste unterstützen das Senden und Empfangen von Nachrichten zwischen Partnern und Anwendungen. BizTalk™ Server 2004 realisiert folgende Konzepte: • Web Services Web Services werden direkt unterstützt. BizTalk™ unterstützt SOAP, WSDL, UDDI, WS Security, WS Routing, und BPEL4WS. In BPEL4WS beschriebene Geschäftsprozesse können importiert und exportiert werden. • BPEL4WS Als interne Sprache zur Definition und zur Orchestrierung von Geschäftsprozessen, die Web Services nützen, nutzt BizTalk XLANG/S. Die Geschäftsprozesse werden innerhalb von Visual Studio .NET grafisch modelliert und lassen sich in BPEL4WS exportieren. Die Prozessmodelle werden in Intermediate Language kompiliert und werden zur Laufzeit innerhalb der .NET Runtime Engine abgearbeitet. BPEL4WS wurde gemeinsam mit BEA und IBM entwickelt und liegt OASIS zur Standardisierung vor. Erst seit kurzer Zeit sind SAP und Siebel involviert.

Bild 9.6: Die Architektur von BizTalk. BizTalk stellt Werkzeuge zur Integration von Unternehmensanwendungen, zur B2B-Integration und zur Orchestrierung von Geschäftsprozessen bereit. Adapter für HTTP, SOAP, MSMQ, ftp und File gehören zur Grundausstattung. MQSeries und SAP Adapter sind verfügbar. Über ein Adapter-Framework sind weitere Adapter realisierbar, die sich in die Administrationsoberfläche einfügen.

112

9.2 Management- und Modellierwerkzeuge

• Human Workflow Services Human Workflow Services erlauben die Definition von Geschäftsprozessen, die zwischen Menschen ablaufen, z. B. das Ausfüllen und Weiterleiten eines InfoPath-Formulars oder Bestätigen einer E-Mail. InfoPath ist ein Formularsystem im Office2003. • Orchestration Designer Für Entwickler ist das Modellierungswerkzeug in Visual Studio.Net integriert. Eine Untermenge der Funktionalität ist zusätzlich über Visio zugänglich. • Business Rules Engine Entscheidungsregeln innerhalb von Orchestrations werden mit einem Business Rule Composer erstellt und geändert. Die Regeln werden an die Engine übergeben und sind ab dann im Geschäftsprozess gültig. • Transformation und Mapping von Daten Ein grafisches Werkzeug innerhalb der Entwicklungsumgebung Visual Studio.NET unterstützt die Transformation und das Mapping von Daten. Schema und Mapping basieren auf W3C XSD Schema und W3C XSLT. • Business Activity Monitoring Der Status aller ausgeführten Prozesse wird in einem offenen XML-Schema protokolliert und kann im MS SQL-Server gespeichert werden. Dadurch werden die Abfrage des Status von Prozessen sowie eine erweiterte Verwaltung, Überwachung und Fehlerbehebung dieser Prozesse möglich. Anwender sind in der Lage, unter Verwendung von Excel Analysen durchzuführen und Statistiken laufender Prozesse in Echtzeit zu berechnen (z. B. wie lange welche Prozesse laufen, wie lange die Zustellung bestimmter Dokumente braucht). • Grafischer Debugger von Geschäftsprozessen Laufende Prozesse können Schritt für Schritt verfolgt werden. Es besteht die Möglichkeit, Breakpoints zu setzen um Aktionen anzuhalten. Für bereits abgearbeitete Prozesse gibt es einen Replay-Modus. • Single Sign-on Die Authentifizierung zwischen heterogenen Systemen und Applikationen auf verschiedenen Plattformen ist vereinheitlicht. BizTalk verwaltet die Identitäten des Benutzers in einem Single Sign-on Server. • Health Activity Monitoring (HAT) Anwender der laufenden Geschäftsprozesse sowie Administratoren können den Zustand eines Prozesses oder einer Nachricht verfolgen. Nicht ausgeführte Prozesse oder übermittelte Nachrichten lassen sich per Benachrichtigung an den Eigentümer des Prozesses zur Korrektur zuweisen. SAP® – NetWeaver®, XI, Business Workflow® NetWeaver ist eine Integrations- und Applikationsplattform in heterogenen IT-Umgebungen. Ziel ist die unternehmensübergreifende Zusammenführung von Anwendern, Informationen und Geschäftsprozessen. Mit Hilfe des Composite Application Framework und den darin enthaltenen Werkzeugen und Methoden können neue Anwendungen entwickelt werden, die bereichsübergreifende Geschäftsprozesse unterstützen. SAP NetWeaver bietet und unterstützt • Multi-Channel Access für den On- und Offline-Zugriff auf Anwendungen über mobile Geräte oder Internet,

113

9 Design, Monitoring und Werkzeuge föderativer Prozesse

• ein Unternehmensportal als einheitliche Benutzeroberfläche für den Zugang interner und externer Anwender via Web-Browser, • Collaboration-Funktionen, die eine direkte oder asynchrone Kommunikation zwischen Personen unterstützen – in moderierter unternehmensweiten Infrastruktur für die Extraktion, Aggregation und Analyse strukturierter Geschäftsdaten aus verschiedenen Quellen, • Knowledge Management für die Vereinheitlichung unstrukturierter Informationen aus unterschiedlichen Quellen, • einen Integration Broker für die interne und externe Integration von Prozessen, basierend auf XML-Messaging und • Business Process Management für die Konzeption, Entwicklung, den Betrieb, die Überwachung und das Management von Geschäftsprozessen über Unternehmensgrenzen hinweg. Die Enterprise Services Architecture (ESA) ist für SAP die Referenzarchitektur für Geschäftsanwendungen. In der Enterprise Services Architecture werden alle Funktionalitäten als Service behandelt. NetWeaver als integrierende Applikationsplattform ist die technische Grundlage der Enterprise Services Architecture. Die Exchange Infrastructure (SAP XI) (Bild 9.7) ist Basis der übergreifenden Geschäftsprozessausführung. SAP XI umfasst ein Integration Repository (Design Time), Integration Directory (Configuration Time) und den Integration Server. Der Integration Server setzt sich aus der Integration Engine für die Ausführung der Integrationsaufgaben, der Business Process Engine für die Koordination und die Überwachung von systemübergreifenden Prozessen und der Adapter Engine für die Verwendung von JCA-basierten Adaptern zusammen. Ziel ist es, SAP- und Nicht-SAP-Anwendungen auf der Basis offener Standards zu integrieren. Zur Integration der Nicht-SAP-Systeme bietet SAP selbst eine Anzahl technischer Adapter an (z. B. Datenbank-, File- oder JMS-Adapter), die durch applikationsspezifische Adapter (z. B. zu Siebel, Baan, Peoplesoft) ergänzt werden. Ein Merkmal der SAP Exchange Infrastructure ist die Zentralisierung der für eine Integration notwendigen Informationen über SAP- und Nicht-SAP-Anwendungen in einem Inte-

Bild 9.7: NetWeaver® Exchange Infrastruktur. Die Exchange Infrastruktur besteht aus einem Integration Broker, einer Business Process Engine sowie dem Directory. Ziel ist es, SAP- und Nicht-SAP-Anwendungen auf der Basis offener Standards zu integrieren.

114

9.2 Management- und Modellierwerkzeuge

gration Repository und Integration Directory. Der Vorteil liegt in der Möglichkeit der Wiederverwendung der im Integration Repository und Integration Directory hinterlegten Inhalte, wie vordefinierte Szenarien, Prozess-Definitionen, Schnittstellen und Mappings. Dies ist unabhängig davon, ob die Integrationsaufgabe zentral oder dezentral gelöst wird. Der Integration Builder ist das Werkzeug um mit dem Integration Repository und dem Integration Directory zu arbeiten. Die Prozesse, die mit der Business Process Engine ausgeführt werden sollen, werden mit Hilfe des grafischen Process Modellers des Integration Builders erstellt und können als BPEL4WS exportiert werden. Business Workflow ist als Workflow-Management-System Bestandteil des SAP Web Application Servers. Business Workflow koordiniert den Prozessablauf innerhalb von Applikationen, was bei betriebswirtschaftlicher SAP Software intensiv genutzt wird. Das Haupteinsatzgebiet ist die Unterstützung von Produktions-Workflows und administrativen Workflows. Siebel – Universal Application Network Universal Application Network (UAN) ist ein Framework zur Integration von unternehmensübergreifenden Geschäftsprozessen und unterschiedlichen Anwendungen. UAN basiert auf Standards und kann auf jedem dafür eingerichteten Integration Server zum Ablauf gebracht werden. UAN ist nicht mit proprietären Komponenten verbunden, so dass es als neutrales Framework für die Belange der Integration eingesetzt werden kann. UAN liefert vorgefertigte unternehmens- und anwendungsübergreifende Geschäftsprozessmodelle. Die Prozessmodelle haben sich in verschiedenen Branchen bewährt und können

Bild 9.8: Universal Application Network (UAN) von Siebel. UAN ist eine Mapping-Technologie für Datenstrukturen von Standardlösungen wie SAP und Siebel. UAN ist auf allen Integrationsservern, die die notwendigen XML-Standards unterstützen, ablauffähig.

115

9 Design, Monitoring und Werkzeuge föderativer Prozesse

dabei unterschiedliche Standardlösungen als Aktivitäten ansprechen. Die Modelle lassen sich individuell an eigene Bedürfnisse und sich ändernde Bedingungen anpassen. Anpassungen sind praktisch in jedem Integrationsprojekt notwendig. Erfahrungen zeigen, dass etwa 90% der Definitionen übernommen werden können und 10% ergänzt werden müssen. Die von Siebel gelieferten Prozesse werden unter Verwendung von BPEL beschrieben. UAN ist eine Mapping-Technologie für Datenstrukturen von Standardlösungen wie SAP, Oracle oder Siebel selbst (Bild 9.8). Das Mapping wird in zwei Schritten durchgeführt. Zunächst wird die Nachricht des Senders auf einem Common Object Model abgebildet. Im einem zweiten Schritt erfolgt die Abbildung auf das API des aufgerufen Packages. Diese zweifache Abbildung ist nützlich, wenn zusätzliche Lösungen integriert oder entfernt werden sollen. Siebel bietet daneben eine Anzahl von XLST-Mapping-Skripts an. Zusätzliche Mappings können mit JScript, VBScript oder XPath geschrieben werden. Siebel ist mit UAN ein Vorreiter auf dem Weg in einen Markt für Standard-basierte, leicht adaptierbare Geschäftsprozesse für unterschiedliche Branchen und Geschäftskulturen. Komponenten (Services) können mittels BPEL gekoppelt werden und mit einer Technologie wie dem UAN synchronisiert werden. Als Schnittstelle zu den eigenen Komponenten bietet Siebel Application Service Interfaces an. Diese werden mit WSDL definiert. Mit dieser Technologie können die Siebel-Komponenten als Aktivitäten in Workflows aufgerufen werden. Eine Migration der Siebel CRM Komponenten auf IBM WebSphere ist im Gange. IBM WebSphere Business Integration enthält ein J2EE-basiertes Business-Process-Management-System, das UAN-Prozesse unmittelbar und ohne vorherige Konvertierung ausführen kann. UAN ist auf allen Integrations-Servern ablauffähig, die die notwendigen XMLStandards unterstützen. 9.2.2 Modellierungstools IDS Scheer – ARIS Die ARIS Process Platform stellt Werkzeuge zur unternehmensübergreifenden Gestaltung, Analyse und Optimierung von Geschäftsprozessen bereit. Die Unterstützung reicht von der Unternehmensstrategie und dem Design über die Umsetzung bis zum Controlling der Prozesse. Die ARIS Process Platform gruppiert sich in eine Design Platform, eine Implementation Platform und eine Controlling Platform. Darüber hinaus gibt es Vorgehensmodelle und Werkzeuge zu spezifischen Anwendungsfeldern, wie Qualitätsmanagement, Risikomanagement, Software Engineering und Re-Dokumentation von R/3-Systemen. • Design Platform Im Designer werden Modelle und Abläufe grafisch erfasst. Der Anwender wird durch eine Reihe von vorgefertigten Objekten und Symbolen unterstützt. Zur Wahrung von Widerspruchsfreiheit und Konsistenz werden Objekte in einem Repository abgelegt. Der Detaillierungsgrad innerhalb der Modelle kann in den Objekten durch Verzweigung zur nächsten Modellebene gewählt werden. Unterschiedliche Ausprägungen des Designwerkzeugs unterstützen den Einsatz und auch die Zusammenarbeit von Nutzern an international verteilten Standorten, die Fachabteilungen bei der Abbildung eines vollständigen, verteilten Unternehmensprozessmanagements und die Unternehmensleitung bei der Strategiedefinition mit Balanced Scorecard (vgl. Davis, 2002; Scheer und Jost, 2002).

116

9.2 Management- und Modellierwerkzeuge

Bild 9.9: ARIS Scenario Diagram von IDS Scheer (©2003 IDS Scheer AG, All rights reserved). Das Scenario Diagramm wird dazu genutzt Systemschnittstellen darzustellen. Dabei kann die Art der Datenübertragung zwischen den Prozessen im Detail modelliert werden, etwa der Austausch asynchroner Messages in einer Service-orientierten Architektur mittels MQSeries.

• Implementation Platform Gemeinsam mit der SAP AG hat IDS Scheer AG neue Standards und Methoden für E-Business entwickelt. ARIS for mySAP™ ist ein Werkzeug zur Planung, Modellierung, Visualisierung und Dokumentation von Geschäftsabläufen, das auf die Verbesserung der Qualität und die Verkürzung der Einführungsdauer bei der Implementierung von SAPLösungen abgestimmt ist. E-Business Scenario Diagrams (Bild 9.9) beschreiben das partnerschaftliche Zusammenwirken von Prozessen über Unternehmensgrenzen hinweg. Das SAP R/3-Referenzmodell beschreibt die betriebswirtschaftlichen Abläufe des SAP R/3-Systems. Der ARIS UML Designer setzt die Idee der Modell-basierten Softwareentwicklung in der Praxis um. Im Rahmen des Processes to Applications-Konzepts (ARIS P2A) wird zunächst die flexible Prozessarchitektur modelliert. Im nächsten Schritt werden diese Prozesse durch IT-Modelle verfeinert und ergänzt. Schließlich werden plattformspezifische Details ergänzt, die es dann mit zusätzlicher Software erlauben, aus den Modellen Code zu generieren. Dabei bedient man sich Cartridges für die jeweilige Technologie, z. B. für die Application Server von BEA oder IBM oder für J2EE, .NET oder Web Services.

117

9 Design, Monitoring und Werkzeuge föderativer Prozesse

• Controlling Platform Der ARIS Process Cost Analyzer ist das Werkzeug zur Modell-basierten Prozesskostenrechnung. Dazu werden operative Daten aus beliebigen Quellsystemen übernommen oder Kennzahlen und Strukturen direkt erfasst und berechnet. So können What-if-Analysen durchgeführt werden und die Auswirkungen von Änderungen des Systems oder der Struktur bewertet werden. Der ARIS Process Performance Manager liest aus verschiedenen Quellsystemen über anwendungsspezifische Adaptoren die zu untersuchenden Geschäftsvorfälle in das Repository ein. Prozessrelevante Laufzeitinformationen über die ausgeführten Aktivitäten werden entsprechend ihrer zeitlichen Abfolge und Zusammengehörigkeit eingelesen und zu einem Prozess zusammengesetzt. Pro Vorgang wird automatisch eine grafische Abbildung generiert, die alle Einzelaktivitäten enthält. Dadurch wird ein über Systemgrenzen hinweg zusammenhängender Ablauf einheitlich und vollständig dargestellt. IBM – WebSphere Business Integration Modeler Der WBI Modeler ist ein Paket von Werkzeugen zur Modellierung, Dokumentation, Analyse und Verbesserung von Geschäftsprozessen. Das Paket besteht aus der Workbench, dem UML Modeler und dem Xform Designer. • Workbench Informationen über Organisation und Prozesse des Unternehmens werden in einem Repository gespeichert. Die Nutzung dieser Informationen stellt sicher, dass die Prozessmodelle auf einer konsistenten Basis beruhen. Das Repository verwaltet unterschiedliche Datentypen, die den individuellen Prozessen angepasst werden. Die Datentypen sind unabhängig von der konkreten Ausformung des Prozessmodells. Geschäftsprozesse werden mit zunehmender Verfeinerung und Komplexität konstruiert und analysiert. Nach Fertigstellung des Modells bieten Analysewerkzeuge durch What-if-Analysen Entscheidungshilfen bei der Wahl der effizientesten Designvariante. Simulation ermöglicht die Analyse, wie sich der Prozess als Reaktion auf Veränderungen in der Art und der Menge von Eingaben oder der Veränderung von Ressourcenzuordnungen verhält. Weighted Average Analysis ermöglicht Prozesskostenrechnung und damit das Verhalten des Modells hinsichtlich Durchlaufzeiten und Kosten zu analysieren (Bild 9.10). Das fertige Prozessmodell kann über FDL (Flow Definition Language) direkt in die WebSphere MQ Workflow Runtime Engine exportiert werden. Die Prozessdiagramme können in verschiedene Sprachen exportiert werden z. B., eXtensible Markup Language (XML), BPEL und UML, für die Weiterverarbeitung z. B. mit Rational Rose oder XDE. Bestehende WBI Interchange Server Collaborations können direkt in der Prozessmodellierung als Aktivitätsimplementierung wieder verwendet werden, ebenso Message Flows des WBI Message Brokers und/oder WBI Intergrator Broker. • Der UML Modeler unterstützt Use-Case-, Sequence-, Collaboration- und Klassendiagramme. UML-Diagramme werden aus den Objekten des Prozessmodells, den Regeln und den Datenstrukturen entwickelt. Der UML Modeler erlaubt den Export des Objektmodells in Entwicklungswerkzeuge, wie z. B. Rational Rose oder XDE. Rose Objektmodelle können ihrerseits in den UML Modeler importiert werden.

118

9.3 Business Activity Monitoring

Bild 9.10: WebSphere Business Integration Modeler. Der WBI Modeler von IBM ist ein Paket von Werkzeugen zur Modellierung, Dokumentation, Analyse und Verbesserung von Geschäftsprozessen.

• Der Xform Designer ermöglicht die Zusammenarbeit von Anwendern und Softwareentwicklern. Anwender visualisieren mit dem Werkzeug die Bildschirmmasken, die im Prozessmodell vorgesehen sind. Das erzeugte Format kann von den Entwicklern zur Implementierung verwendet werden.

9.3 Business Activity Monitoring Business Activity Monitoring (BAM) ist das Überwachen und die Analyse von kritischen Prozess- und Unternehmenskennzahlen in Echtzeit, womit die Entscheidungsfindung in allen Managementebenen unterstützt wird (Bild 9.11). Der betriebswirtschaftliche Nutzen von BAM liegt in der Steigerung der Effizienz von Prozessen und in der Steigerung der Qualität von Produkten und Entscheidungen. BAM ist gleichsam das Nervensystem des Unternehmens. BAM bedeutet für Unternehmen kontinuierliches Überwachen von Leistungskennzahlen, Analyse von beeinflussenden Faktoren, Erkennen von Abweichungen und Anomalien sowie Anpassung der Wirkfaktoren und Prozesse. Um Geschäftsprozesse kontrollieren und korrigierend anpassen zu können, sind schnelle, präzise, ausreichende und in der Situation relevante Informationen notwendig. Business-

119

9 Design, Monitoring und Werkzeuge föderativer Prozesse

Bild 9.11: Business Activity Monitoring: Datenanalyse und Entscheidungsunterstützung (nach IBM, modifiziert). Business Activity Monitoring ermöglicht es Unternehmen, schneller auf interne oder externe Ereignisse zu reagieren und bestimmte Geschäftsprozesse anzupassen. Durch automatische Integration von relevanten Daten und Auswertung von Regeln werden Entscheidungsprozesse unterstützt.

Intelligence(BI)-Lösungen greifen in Echtzeit auf die Produktionsdaten des Unternehmens zurück. Die Leistung von BAM-Lösungen besteht darin, dass sie unter wechselnden, dynamischen Bedingungen die Unternehmenslage darstellen und diese mit Einflussfaktoren in Beziehung setzen können. Bei BI-Lösungen geht es um die Analyse von historischen Daten, bei BAM-Lösungen um die Überwachung und Steuerung von komplexen Geschäftsprozessen. Die Informationen, die zur Beurteilung einer bestimmten Situation erforderlich sind, stammen aus vielen verschiedenen, verteilten, zumeist heterogenen Datenquellen. Ausgangspunkt für BAM ist ein Prozessmodell, das Prozesse, Aktivitäten, Rollen, Daten und Leistungsindikatoren beschreibt. Das Unternehmen entscheidet dabei über die zu überwachenden Prozesse und dafür benötigte Information, damit der Normal- und der Ausnahmezustand im unternehmerischen Kontext zum Teil auf der Basis von Regeln bewertet werden kann. In zusammenfassenden und kumulierenden Ansichten überwacht der Anwender die Geschäftsprozesse zeitnah und erkennt signifikante Abweichungen der Prozesskennzahlen. Das Erscheinungsbild im Browser ist weitgehend individuell konfigurierbar. Der Anwender kann dadurch eine den eigenen Bedürfnissen angemessene Darstellung gestalten. Meist ist die Information als Portlet in das Portal eingebettet. Informationen werden gefiltert und aufbereitet. Korrelationen werden sichtbar, Problembereiche und Trends sind intuitiv erfassbar. Bei Bedarf kann der Anwender in Echtzeit auf darunter liegende Detailinformation oder Teilprozesse verzweigen.

120

9.3 Business Activity Monitoring

BAM bezieht Informationen aus vielen Quellen und sorgt für die Integration der Daten. Dazu gehört die Abbildung der Datenquellen auf das Prozessmodell, das Verbinden mit den Aktivitäten und die Anbindung zu BI-Anwendungen. Das Sammeln der Eingangsinformationen aus den Anwendungen nimmt einen beträchtlichen Teil der Implementierung ein. IDS Scheer – ARIS Process Performance Manager ARIS Process Performance Manager (ARIS PPM) ermittelt und analysiert Leistungsdaten von unternehmens- und systemübergreifenden Geschäftsprozessen (Bild 9.12). Informationen werden aus betriebswirtschaftlichen Anwendungen wie ERP-, SCM-, CRM-, E-Business- oder Workflow-Management-Systemen gewonnen. ARIS PPM liest aus einem oder mehreren Quellsystemen über Adaptoren alle zu untersuchenden Geschäftsvorfälle in das Repository ein. Dabei liegen unterschiedliche prozessrelevante Laufzeitinformationen über die ausgeführten Aktivitäten vor (z. B. Log-Dateien, Belege, Historien). Diese werden gemäß ihrer zeitlichen Abfolge und Zusammengehörigkeit eingelesen und zu einem Prozess zusammengesetzt. Pro Prozessinstanz wird dann automatisch eine grafische Abbildung generiert, die alle Einzelaktivitäten enthält. Somit wird ein über Systemgrenzen hinweg zusammenhängender Ablauf einheitlich und komplett dargestellt. ARIS PPM liefert Informationen zur Kennzahlen-basierten Bewertung der Leistungsfähigkeit von Geschäftsprozessen, zur Darstellung der tatsächlich abgelaufenen Vorgänge zur Ursachenforschung, Ableitung von Optimierungsmaßnahmen sowie zur kontinuierlichen Erfolgskontrolle.

Bild 9.12: Die Architektur von ARIS PPM mit Integrationsmöglichkeiten in Portale (nach IDS Scheer, modifiziert). Das Anwendungssystem, aus dem die Daten extrahiert werden, wird mit ARIS PPM über Adapter verbunden. Durch diese individuell konfigurierbare Darstellung im Browser bekommt der Anwender einen schnellen Überblick der kritischen Kennzahlen und wichtigsten Auswertungen. Diese Darstellung eignet sich insbesondere für die Integration in ein Unternehmensportal.

121

9 Design, Monitoring und Werkzeuge föderativer Prozesse

IBM – WebSphere Business Integration Monitor Der IBM WebSphere Business Integration (WBI) Monitor überwacht die in der Workflow Engine ablaufenden Prozesse und erstellt statistische Berichte auf der Basis von Ist-Daten (Bild 9.13). Die Daten können zurück an die WBI Workbench zur weiteren Analyse und Prozessoptimierung übergeben werden. Damit stehen Daten für ein kontinuierliches geschlossenes Geschäftsprozessmanagement bereit. Mit dem WBI Monitor werden die Funktionen Überwachen und Steuern realisiert. WBI Monitor bietet zwei Optionen zur Überwachung und Ausführung der Geschäftsprozesse: • Eine Sicht bietet Einblick auf die Laufzeitdaten, die die Workflow-Engine in einem Audit-Trail bereitstellt. Sie dient also der Überwachung von Geschäftsprozessen in Echtzeit und bietet Unterstützung bei der Fehlerbeseitigung. • Die zweite Sicht ermöglicht die Darstellung von Berichten auf der Basis gespeicherter Daten. Dazu steht eine Reihe von Analyse-Tools (z. B. für die Trendanalyse) zur Verfügung. WBI Monitor liefert Informationen zur Überwachung von Geschäftsprozessen in Echtzeit, zur Erstellung von Statistiken und stellt Soll-Ist-Vergleiche zur weiteren Prozessoptimierung bereit.

Bild 9.13: WebSphere Business Integration Monitor – Datenanalyse und Entscheidungsunterstützung (nach IBM, modifiziert). Der IBM WebSphere Business Integration (WBI) Monitor überwacht die in der Workflow Engine ablaufenden Prozesse und erstellt statistische Berichte auf der Basis von Ist-Daten.

122

9.3 Business Activity Monitoring

Microsoft – Business Activity Services Microsoft stellt eine gemeinsame Benutzerschnittstelle zu den Business Activity Services bereit. Hinter dieser allgemeinen Schnittstelle stehen vier Softwarebestandteile, die alle über SOAP und den Windows SharePoint Services mit Internet Explorer, Excel und InfoPath kommunizieren können (Bild 9.14). Über das Business Activity Monitoring Framework sucht der Anwender den gewünschten Prozess aus und wählt eine bestimmte BAMAnsicht um Details im Prozess zu überwachen. Jede Ansicht gibt eine andere Perspektive des Geschäftsprozesses wieder. Die Information in den Ansichten können täglich, stündlich oder häufiger aktualisiert werden. Weil Business Activity Monitoring von Managern verwendet wird und nicht von Entwicklern, kommen bei Microsoft vertraute Werkzeuge, wie Explorer, Excel und InfoPath zur Abfrage von BAM Informationen zum Einsatz. Hinter der allgemeinen Schnittstelle Windows SharePoint Services stehen vier Softwarebestandteile, die alle über SOAP mit Internet Explorer, Excel und InfoPath kommunizieren können. Mit Hilfe des Tracking Profile Editors konfiguriert der Entwickler eine Orchestrierung so, dass sie für eine bestimmte BAM-Ansicht auch die benötigte Information liefert. Dieses Werkzeug erlaubt dem Entwickler grafisch Ereignisse und Nachrichten einer Orchestrierung mit entsprechenden Zuständen und Daten in einer BAM-Ansicht zu verbinden. Der BizTalk Server sendet dann diese Ereignisse und Nachrichten an die Tracking Database, wo sie von der Business-Activity-Monitoring-Komponente abgegriffen werden können. Excel kann schließlich direkt über SOAP auf die BAM-Komponente zugreifen und ständig aktualisierte Informationen für die BAM-Ansicht abfragen.

Bild 9.14: Microsoft Business Activity Monitoring – Datenanalyse und Entscheidungsunterstützung (nach Microsoft, modifiziert). Microsoft stellt eine gemeinsame Benutzerschnittstelle zu den Business Activity Services bereit. Hinter dieser allgemeinen Schnittstelle stehen Softwarebestandteile, die über SOAP und die Windows SharePoint Services mit Internet Explorer, Excel und InfoPath kommunizieren.

123

10 Informationsportale

• • • • • •

Was ist ein Portal, was eine Portallösung? Was ist der Nutzen von Portalen? Was sind die speziellen Merkmale von Portalen? Was sind Portlets? Warum braucht man eine Multichannel Integration? Was ist Multidevice-Technologie?

10.1 Nutzen von Portalen Die Idee des Portals entspringt dem Wunsch vieler IT-Nutzer nach einem direkten Zugang zu allen benötigten Diensten von einer einzigen Web-Site aus und dabei der Erzeugung individueller Seiten und Antworten entsprechend den Bedürfnissen und der Berechtigung dieser Nutzer. Portale und Portallösungen führen Inhalt und Anwendungen innerhalb der Oberfläche eines Browsers zusammen. Der Anwender muss sich dazu nicht mehr gegenüber einer Vielzahl von Anwendungen anmelden, sondern über ein Single Sign-on (SSO) nur einmal am Portal-Server. Dieser besitzt entsprechende Adapter oder Konnektoren, um die Backend-Systeme anzusprechen. Die Daten oder Anwendungen stellt der Portal-Server innerhalb so genannter Portlets dar. Portlets sind Fenster im Fenster des Browsers. Jedes Portlet entspricht einem Ausgabefenster. Der Portal-Server füllt die aktuellen, speziellen Inhalte in die einzelnen Portlet-Fenster und zeigt alle zusammen im Fenster eines Browser, dem Portal, an. Der Benutzer ruft sein Portal über eine URL über seinem Browser auf, meldet sich an und bekommt dann seine personalisierte Oberfläche als HTML-Seite zurück. Diese wurde dazu auf dem Portal-Server durch die Portallösung entsprechend der gespeicherten Profile aus unterschiedlichen Informationsquellen für ihn ganz individuell zusammengebaut. Das Profil bzw. der anzuzeigende Inhalt wird von dem Benutzer manchmal selbst konfiguriert oder ausgewählt, oft aber durch einen Administrator gemäß den Befugnissen und Aufgaben des Benutzers festgelegt. Portalinstallationen haben unterschiedliche Ausbaustufen: • In einer ersten Ausbaustufe werden Inhalte in einem gemeinsamen Fenster zusammengeführt und angezeigt. • In der zweiten Stufe unterstützt das Portal Content-Management, also die Suche über Index und Kategorisierung von Inhalten. Personalisierung und einfache Anwendungsintegration ist möglich.

124

10.3 Personalisierung

• In der dritten Stufe bindet das Portal Informationen aus Backend-Systemen ein. Der Portal-Server bedient auch mobile Clients, die über drahtlose Verbindungen auf das Portal zugreifen. Es kommen Collaboration-Funktionen für elektronische Teamarbeit hinzu. • In der vierten Stufe steht Personalisierung im Vordergrund. Dies beinhaltet Single Signon, eine individuelle Anwenderoberfläche oder eine anwenderabhängige Gewichtung der Darstellung von Inhalten. Dazu gehört auch Offline-Support, um bestimmte Daten des Portals herunterzuladen beziehungsweise zu synchronisieren. • In der fünften Stufe integriert ein Portal auch Funktionen für die Kommunikation entweder über Mailing oder über Web-Chat oder gar über das Telefon (siehe Kapitel 11). Auf diese Weise entsteht ein Informations- und Kommunikations(I&K)-Portal. Portale sind keineswegs auf die Informationen und Dienste eines einzelnen Unternehmens beschränkt, sondern die genutzten Portlets können von überall her bezogen und in das Portal eingesetzt werden. Sie beziehen ihre Inhalte zur Laufzeit auch aus fremden Quellen.

10.2 Single Sign-on Damit der Vorteil von Portalen wirklich zum Tragen kommt, muss das Portal Single Sign-on (SSO) beherrschen. SSO ermöglicht es dem Anwender nach nur einmaliger Authentifikation auf mehrere Backend-Systeme oder externe Ressourcen (Web Services) zuzugreifen. Einerseits authentifiziert sich der Anwender gegenüber dem Portal. Die Zugriffsrechte speichert das Portal in einer eigenen Datenbank ab. Andererseits stößt das Portal eine Authentifizierung gegenüber seinen Ressourcen an. Dem Benutzer bleibt dies verborgen SSO hat den Vorteil der Benutzerfreundlichkeit und gibt Organisationen die Möglichkeit die Authentifikationsinformation konsistent zu administrieren. Allerdings müssen alle beteiligten Systeme dem gleichen Authentifikationsdienst vertrauen. Bei föderativem SSO meldet sich der Anwender bei nur einem System an. Dieses System ist Mitglied in einer Vertrauensgruppe. In der Folge kann der Anwender die anderen Systeme innerhalb der Gruppe nutzen, ohne sich erneut anzumelden.

10.3 Personalisierung Die Personalisierungsfunktion sorgt dafür, dass der Anwender, ein Mitarbeiter, Kunde, Lieferant oder Partner, in seinem Portalfenster nur Inhalte und Dienste sieht, die zulässig sind. Sie hilft auch, dass der Benutzer genau die Anwendungen und den Inhalt angeboten bekommt, die er für seine Arbeit benötigt. Personalisierung bedeutet darüber hinaus, dass der Nutzer seine Portaloberfläche im Inhalt und Erscheinungsbild individuell gestalten kann. Die Personalisierung erfolgt entweder durch einen Administrator oder den Anwender selbst. Der Administrator definiert, welche Portlets für eine bestimmte Rolle angeboten werden. Der Anwender kann dann noch andere, freigegebene Portlets zu seinem Portalfenster hinzufügen. Die Personalisierung findet zur Laufzeit durch die Portallösung statt. Eine besondere Art der Personalisierung entsteht nach dem automatischen Aufbau von

125

10 Informationsportale

Nutzerprofilen durch das Verfolgen aller Aktionen eines Benutzers. Dann werden die Inhalte (Recommendations) entsprechend dem Nutzerprofil indirekt angepasst. Durch den Aufbau von individuellen Nutzerprofilen entwickeln Portale ihren eigentlichen Komfort: Hinterlegt der Nutzer persönliche Präferenzen für z. B. sein Mobilitätsverhalten, z. B. Verkehrsmittel oder gewünschte Hotel-Kategorie, sind die Resultate der Dienste speziell auf seine Wünsche zugeschnitten. Dabei werden sich die Nutzerprofile über die Zeit dem Mobilitätsverhalten des Einzelnen anpassen und die Arbeit mit dem System wird durch präzisere Informationen honoriert. 10.3.1 Das Portal zur Interaktion mit Workflows Ein Agent in einem Workflow bekommt seine Arbeitsanweisungen (Work-Items) entsprechend seiner Aufgabe in einem Fenster seines Portals angeboten. Er kann einen Prozess über ein anderes Portlet überwachen. Wenn er berechtigt ist, kann er sogar in den Prozess eingreifen (Bild 10.1). Der Staff-Resolution-Mechanismus ordnet einer bestimmten Person innerhalb einer Rolle eine bestimmte Aktivität des Workflows zu. Die Zuordnung zur Person, dem Agenten, erfolgt nach Kriterien wie Verantwortung in einem Prozess, Arbeitsbelastung oder Qualifikation. Die notwendige Aktivität erscheint als Eintrag in einer Worklist in einem Portlet oder als Mail. Nach Auswahl eines bestimmten Work-List-Items wird die zugehörige Applikation gestartet. Das Ergebnis der Bearbeitung wird an das Workflow-ManagementSystem zurückgemeldet. Im Prozess-Instanz-Monitor-Fenster sieht der Bearbeiter den aktuellen Zustand und die Historie einer bestimmten Workflow-Instanz.

Bild 10.1: Prozess-Portal (nach IBM, modifiziert). Agenten können ihre Sicht auf die sie interessierenden Abläufe über Portale gestalten. Neben einem Portlet, z. B. dem eines Mail-Client, in dem die notwendigen Tätigkeiten (Work-List) eingeblendet werden, gibt es auch Portlets zur Inspektion und zum Management der Workflows selbst. Bei Problemfällen ist eine direkte Kommunikation mit anwesenden, »präsenten« Kollegen auf Knopfdruck zu starten.

126

10.5 Produkte

Der berechtigte Anwender überwacht im BAM-Fenster kritische Prozess- und Unternehmenskennzahlen in Echtzeit. Er analysiert beeinflussende Faktoren, erkennt dabei Abweichungen und Anomalien der Prozesse. Bei der Abbildung durchgängiger Geschäftsprozesse in einem Portal werden neben unternehmensinternen Applikationen auch Schnittstellen zu Partnern und Kunden angeboten.

10.4 Integration von Anwendungen und Services über Portale Ein Portal integriert Anwendungen (Portlets) primär durch die Abbildung in einer gemeinsamen Ausgabe. Es benötigt dazu Adapter für die Backend-Systeme, welche die Portalprodukte mit anbieten. Eine moderne Anbindung von Anwendungen über ein Netzwerk erfolgt über Web Services. Ein Portlet nimmt die Verbindung zu einem Backend-System oder Web Service auf, startet ihn ggf. und übernimmt die Ergebnisse. Es bereitet die Ergebnisse so auf, dass sie in den Rahmen eines Portlets passen und dort für den Benutzer verständlich sind. In einem einfachen Portal liegen die Portlets frei nebeneinander. Dies bedeutet, dass die Ergebnisse in einem Fenster keine Auswirkung auf andere Fenster haben. Bei einer Kommunikation der Portlets untereinander kann ein Portlet die Ergebnisse des anderen beeinflussen. Bei Auswahl eines Kunden in einem Fenster listet das zweite die zugehörigen Verträge auf. Web-Service-Technologien wie SOAP, WSDL oder UDDI erleichtern die Integration wesentlich. Da es für die Nutzung von Web Services keine Rolle spielt, auf welchem System sie ablaufen, sind sie eine vorzügliche Basis für ein föderatives Portal. Entsprechend gibt es Web-Service-Interfaces, die sich portalgerecht verhalten (siehe WSRP-Standard).

10.5 Produkte Jetspeed Jetspeed ist ein Teil des Java-Open-Source-Projektes der Apache Software Foundation und besteht fast ausschließlich aus einer Anzahl von Servlets. Als Inhalte können hauptsächlich textuelle Informationen wie HTML-Seiten, XML-Inhalte, sowie PHP-Skripte und CocoonPortlets (HTML-Fragmente, die aus XML unter Verwendung von XSL erzeugt werden) eingebunden werden. Diese Vielzahl der Möglichkeiten zur Einbindung von Inhalten zählt neben der offenen Implementierung zu den Vorteilen von Jetspeed. Jetspeed ist auch Grundlage des IBM WebSphere Portal Servers. IBM WebSphere Portal WebSphere Portal liefert ein umfangreiches Framework zur Erstellung von Unternehmensportalen für Unternehmen unterschiedlicher Größe. Abhängig von den Bedürfnissen der Kunden werden unterschiedliche Portaltypen bereitgestellt. Der Schwerpunkt liegt auf der Skalierung, auf Kollaboration, Personalisierung und Integration mit Backend-Systemen. Die Portal-Software ermöglicht Zugriff auf IBM Lotus Domino und Unternehmensanwen-

127

10 Informationsportale

dungen wie SAP. WebSphere Portal unterstützt unterschiedliche, auch drahtlose Endgeräte und Browser. Microsoft Office SharePoint Portal Server Mit SharePoint Portal Server werden Informationen aus unterschiedlichen Geschäftsanwendungen zusammengefasst. Single Sign-on und Personalisierungsfunktionen unterstützen dabei. Umgesetzt werden die Entwicklungen durch Nutzung von Office2003, dem .NET Framework, Web Parts (Portlets), den Integrationsfunktionen von BizTalk Server sowie InfoPath. Mit Windows SharePoint Services können Team-Sites erzeugt werden, in welchen Anwendergruppen Dokumente, Termine, Kontakte und Informationen ablegen können. Durch die Integration von Kommunikationsfunktionen kann aus einem SharePoint Portal mit den Autoren von Dokumenten direkt kommuniziert werden. SAP Enterprise Portal Der Schwerpunkt liegt hier auf der Verwaltung und Steuerung unstrukturierter Informationen aus unterschiedlichen Quellen. Vorteile sind die Offenheit der Lösung, so dass unabhängig von Gerät oder Format praktisch jede SAP- oder andere Anwendung, Informationsquelle und beliebige Webinhalte integriert werden können. Das SAP Enterprise Portal erlaubt unmittelbaren Zugriff auf Data Warehouse-, Report- und Analysefunktionen. Schnittstellen für Java- und .NET zur Unterstützung von XML, Web Services, SOAP, UDDI und WSDL sind vorhanden. Sicherheitsstandards wie LDAP, Active Directory Services, SSL, PKI und X.509 werden unterstützt.

10.6 Nutzen einer Multichannel Integration Es ist es entscheidend für wirtschaftlichen Erfolg, die internen Abläufe des Unternehmens mit den Verhaltensweisen und Prozessen von Verbrauchern, Kunden, Lieferanten und anderen, das Geschäft beeinflussenden Stellen zu synchronisieren, so dass jeder Geschäftsvorfall bei allen davon Betroffenen gleichzeitig bekannt wird. Die Grundlage derartiger Geschäftsmodelle ist die Einbindung aller Teilnehmer in ein universelles Netzwerk, das diese über beliebige Zugangsgeräte und Medien von jedem Ort aus nutzen können, insbesondere auch über Sprache. Ortsungebunden, zeitunabhängig und auf welchem Kommunikationskanal auch immer Informationen aufnehmen, verarbeiten und abrufen, das ist Multichannel Integration. Mit diesem überall zugänglichen Netz verschiedener Netze (IP, PSTN, GSM, UMTS, ...) können die Teilnehmer alle benötigten Services erreichen und über dieses Netz werden sie über alle für sie wichtigen Ereignisse informiert. Ermöglicht wird dieses durch eine neue Art von Integrationsanwendungen, welche aus einer alles übergreifenden Sicht entwickelt und gewartet (Single Point of Maintenance) werden. Eine solche Plattform, auf der diese modernen Anwendungen ablaufen, wird Multichannel-Integrationsplattform genannt.

128

10.6 Nutzen einer Multichannel Integration

10.6.1 Multichannel-Integrationsplattform Wesentliche Komponenten in dieser Multichannel-Integrationsplattform (MIP) sind so genannte Contact Server für die menschliche Kommunikation über Sprache, Mail, Fax oder Web Chat. Es werden auch alle browserfähigen Endgeräte durch ein gemeinsames Framework unterstützt. Die MIP ist einerseits die Laufzeitumgebung zur Bereitstellung von Selbstbedienungsanwendungen für Menschen, andererseits dient die Plattform der Vermittlung von Services, welche im direkten Kontakt mit Menschen erbracht werden, so genannter Assisted Services. Alle Zugangskanäle übergreifend wirkt ein Session Management, durch welches eine Benutzeraktion auf einen Kanal jederzeit unterbrochen, auf einem anderen später fortgesetzt und auf einem dritten zu Ende gebracht werden kann. Ebenso kann ein Unternehmen durch einen Web-Agenten Angebote aus unterschiedlichen Quellen einholen, diese vergleichen und bewerten und den Auswahlprozess etwa durch ein Fax an einen der ausgewählten Lieferanten abschließen. Diese Möglichkeit über längere Zeit Transaktionen offen zu halten, ist die Leitidee beim Aufbau einer Multichannel-Integrationsplattform. Die Steuerung eines derartigen Vorgangs ist die typische Aufgabe eines alles koordinierenden Workflows. Ausgangspunkt einer Multichannel-Integration ist die Überlegung, dass dasjenige Unternehmen Kundenzufriedenheit erzeugt, das es schafft, den Kunden während eines gesamten Kundenprozesses und unabhängig vom Zugangsmedium zu betreuen. Ein Kundenprozess umfasst dabei alle Aktivitäten, die ein Kunde in einem oder mehreren Geschäftsprozessen ausführt und in denen er Marktleistungen in Anspruch nimmt. Portale bündeln zudem diese Dienstleistungen, die ein Unternehmen und seine Partner über alle elektronischen Medien zur Verfügung stellen. 10.6.2 Multichannel Szenario Eine Fluggesellschaft wird versuchen den Kunden während des gesamten Reisevorganges zu unterstützen. Dieser föderativ gekoppelte Kundenprozess fängt in der Planungsphase der Reise an, geht über den Abruf aktueller Informationen zur Reisezeit, einem vereinfachten Check-In am Flughafen, die Buchung von Transportdiensten am Zielort bis zu einem After-Sales-Marketing nach Abschluss der Reise. Alle Reaktionen des Unternehmens bleiben trotz eines Wechsels des Zugangsmediums durch den Kunden zueinander konsistent. Die Integrationsfunktion der Multichannel-Plattform sorgt dafür, dass alle betroffenen Geschäftsprozesse über alle Ereignisse permanent informiert und synchronisiert werden. Die Herausforderung dabei ist, das der Kunde je nach Phase unterschiedliche Zugangsgeräte zu den Informationen nutzen wird. Der Typ der elektronischen Zugangsgeräte (Devices) reicht in diesem Beispiel vom PC (Internet) während der Planungsphase über Selbstbedienungsgeräte beim Check-In, PDA und Mobile Phone (UMTS, WAP) beim Ruf des Transportdienstes oder der Hotelreservierung am Zielort. Nur durch den Einsatz dieser unterschiedlichen Zugangsgeräte kann der Kontakt zum Kunden über den gesamten Prozess hinweg gehalten werden. Meldet sich ein mobiles Gerät am Portal-Server an, identifiziert dieser den Typ des Gerätes, erkennt die Bandbreite und den verwendeten Browser. Der Portal-Server verfügt über ein Repository, das die Eigenschaften der unterstützten mobilen Geräte enthält. Anhand 129

10 Informationsportale

dieser Informationen entscheidet der Portal-Server, wie die angeforderten Informationen verständlich für das aktuelle Gerät aufbereitet werden. Während der Browser auf einem Notebook einen Bericht übersichtlich darstellt, verliert der gleiche Bericht auf einem PDA seine Übersichtlichkeit. In diesem Fall werden nur ausgewählte Spalten oder eine Zusammenfassung des Berichts angeboten. Die unterschiedliche Displaygröße des Gerätes beeinflusst die Aufbereitung der Information und die Nutzerführung. Der in der Software abgebildete Workflow wird auf einem WAP-Gerät deutlich einfacher gestaltet sein als auf einem Notebook. Bilder werden bei zu geringer Bandbreite z. B. bei Handhelds über GPRS weggelassen oder deren Auflösung reduziert. Präsentation, Workflow und Inhalt werden auf die Möglichkeiten des jeweiligen Endgerätes und die verfügbare Bandbreite angepasst, attraktive Logos in verschiedenen Größen werden gerätespezifisch eingefügt. Die Ausgabesprache des Browsers variiert auf unterschiedlichen mobilen Geräten. Der WAP-Browser erhält die Ausgabe in WML (Wireless Markup Language). I-Mode-Geräte benötigen cHTML und Handhelds verwenden eine HTML-Untermenge. Windows-CEoder Palm-Geräte benötigen zudem unterschiedliche HTML-Versionen. Das Portal bereitet die Daten für die mobile Geräteklasse selbst auf. Der Anwender stellt das Portalfenster für eine bestimmte Geräteklasse selbst zusammen. Dabei bekommt er nur Portlets angeboten, die seine Geräteklassen unterstützen. 10.6.3 Location Based Services Location Based Services sind Dienste, die auf den jeweiligen Aufenthaltsort des Nutzers zugeschnitten sind. Wenn etwa ein Passant nach einem Speiserestaurant sucht, wäre es wenig sinnvoll, ihm eines in einer anderen Stadt zu nennen. Die Informationen über den aktuellen Standort müssen aber nicht manuell in das mobile Endgerät eingegeben werden, da jeder Mobilfunkteilnehmer durch die Position der jeweiligen Funkzelle, in der er sich gerade befindet, bis auf wenige Meter genau geortet werden kann. Die Koordinaten von Funkzellen werden somit genutzt, um den Nutzer personen- und standortbezogene Dienste zu offerieren. Diese enthalten aktuelle und ortsbezogene Informationen und Dienstleistungen für mobile Nutzer bereit. 10.6.4 Sicherer Zugang Die Sicherheit beim mobilen Zugang hängt vom gewählten Medium wie GSM, GPRS oder UMTS sowie Internet ab. Bei GPRS oder UMTS kann die Verbindung zum Portal-Server über ein VPN (Virtual Private Network) geschützt werden. PKI-Systeme (Public-KeyInfrastructure) und Wireless-PKI-Systeme (WPKI) erlauben eine starke Autorisierung und Authentifizierung im Internet. Für WAP gibt es spezielle Wireless-PKI-Systeme oder den WTSL (Wireless-Transport-Security-Layer). 10.6.5 Multidevice Technologie Multidevice Technologie im Umfeld der Multichannel Integration bedeutet die Bereitstellung einer produktiven, leicht zu ergänzenden und alle Geräte- und Browsertypen übergreifenden Entwicklungs- und Laufzeitumgebung, welche eine qualitativ hochwertige Darstellung von verständlichen Inhalten auf den verschiedenartigen Bildschirmen (z. B. hinsichtlich der Größen und der Navigationselemente) ermöglichen. 130

10.6 Nutzen einer Multichannel Integration

Der Schlüssel zu einer Infrastruktur für die Unterstützung der Geräte-Vielfalt liegt dabei in der Trennung der Elemente zur Navigation von den Inhalten und den gerätespezifischen Layouts. Dies führt dazu, dass die Entwickler alle Möglichkeiten der Präsentation unter dem Aspekt der Verständlichkeit gleichzeitig betrachten müssen und dass sie die gleichen Inhalte auf jedem der unterschiedlichen Geräte in sinnvollen Einheiten ausgeben müssen. 10.6.6 Multidevice Frameworks Frameworks liefern fertige Oberflächenelemente (Controls), welche sich automatisch an die Gegebenheiten eines speziellen Endgerätes anpassen (Rendering). Überzeugende Beispiele sind die automatische Anpassung eines Kalendermonatsblocks oder von Datenbanktabellen auf Displays mit unterschiedlicher Größe von dem eines Browser am PC bis zu dem eines kleinen Mobiltelefons. Die Frameworks basieren auf einer Konfigurationsdatei mit den Eigenschaften der verschiedenen Geräte. Die Konfigurationsdatei kann von der Multidevice-Anwendung abgefragt werden, um daraufhin die Verbesserung der Darstellung für spezielle Rendering-Aufgaben selbst zu übernehmen. Die leichte Wartbarkeit dieser Multidevice-Anwendungen auf Basis von Frameworks entspringt dem Umstand, dass nur ein Quellprogramm gepflegt werden muss. Daneben sind die Ergebnisse, also die erzeugten Ausgaben, attraktiver. Ein Framework kann außerdem Grenzprobleme bei der Darstellung besser, d.h. attraktiver lösen als ein weitgehend starrer Abbildungsmechanismus über Stylesheets. Daneben wird Testaufwand gespart, weil in der Entwicklung die Anwendung nur auf einigen typischen Geräten und nicht auf allen getestet werden muss. Microsoft stellt dazu ein Multidevice Framework bereit. Microsoft – ASP.NET Mobile Controls Eine unter Verwendung von ASP.NET Mobile Controls entwickelte mobile Anwendung funktioniert automatisch für alle unterstützten Geräte. Es ist kein weiteres Zutun hinsichtlich der Sprachen oder der Geräte erforderlich. Mobile Controls unterstützen eine große Zahl unterschiedlicher Gerätetypen wie WAP-Mobiltelefone, cHTML Cell Phones, Pocket PCs und Pagers, aber auch Desktops auf denen MS Internet Explorer läuft. Die Liste der unterstützten Geräte ist in einer Konfigurationsdatei abgelegt und kann bei Bedarf auch individuell angepasst werden. Wenn wenig Platz ist, teilen Mobile Controls den Inhalt automatisch auf mehrere Bildschirme auf. Hilfreich ist z. B. ein Object-List Control zur Ausgabe des Ergebnisses von Datenbankabfragen in tabellarischer Form auf großen Bildschirmen oder einspaltig zum Blättern auf Geräten mit kleiner Anzeige. Der Entwickler hat dennoch bei Bedarf weitreichenden Einfluss auf das Verhalten der Mobile Controls, d.h. er kann jedes einzelne Control für jedes unterstützte Gerät anpassen und optimieren. ASP.NET Mobile Controls sind Teil des .NET Frameworks. Ein Mobile Internet Designer erweitert Visual Studio .NET für die Implementierung von mobilen Anwendungen. Zukünftig wird die Trennung zwischen Desktop Controls und Mobile Controls aufgehoben. Dann werden sich alle Web Controls automatisch in der jeweils optimalen Form darstellen können.

131

11 Kommunikationsportale

• • • • • •

Was bietet die moderne Kommunikationstechnologie virtuellen Organisationen? Was ist Presence-Management? Welche Rolle spielen Portale bei der Zusammenarbeit? Wie können Prozesse reviewed werden? Wie werden laufende Prozesse überwacht? Wie unterstützen Microsoft und IBM unternehmensübergreifende Zusammenarbeit beim Management von Prozessen?

11.1 Motivation Das Fundament jeglicher Zusammenarbeit ist Kommunikation und das dabei ständig erneuerte gegenseitige Vertrauen. Heute bietet sich den Menschen, auch jenseits der direkten Begegnung, eine Vielfalt an technischen Möglichkeiten, miteinander in Kontakt zu treten. Der Begriff des virtuellen Unternehmens bezeichnet das temporäre Zusammenwirken von Teams jenseits ihrer Organisationseinheiten. In diesem Kapitel wird die verfügbare Kommunikationstechnologie mit den Notwendigkeiten unternehmensübergreifender Prozesse in Verbindung gebracht.

11.2 Management gemeinsamer Prozesse Durch die Kopplung von Prozessen erfolgt der Austausch von Leistungen und Gütern zwischen Unternehmen automatisch. Bis ein derartiger Zustand erreicht ist, müssen die Partner über die Modalitäten des Zusammenspiels verhandeln. Dies ist auch der Fall, wenn Ereignisse auftreten, welche die Änderung der Prozessabläufe notwendig erscheinen lassen. Gravierende Ereignisse sind, wenn Teile eines Unternehmens still gelegt und durch externe Zulieferer oder Dienstleister ersetzt werden, wenn ein Zulieferer in Konkurs geht oder wenn einer der Partner den Betrieb der IT übernimmt. Jedoch ist es der Prozess der Produktentwicklung selbst, welcher einer intensiven Kommunikation zwischen den Beteiligten bedarf. Dabei werden sowohl der gemeinsame Entwicklungsprozess und die Struktur der Produkt-Masterdaten, die Stückliste und die Verantwortlichkeiten abgestimmt. Die Entwicklung neuer Produkte, z. B. der eines Triebwerks oder von Softwarelösungen sind aus der Sicht von Workflows wenig automatisierbar. Hier steht die permanente, organisationsübergreifende Diskussion und Erprobung neuer Ideen im Vordergrund. Dies

132

11.2 Management gemeinsamer Prozesse

Bild 11.1: Kommunikationsarten und Methoden für die Kollaboration. Aus der Sicht organisationsübergreifender Prozesse stellt sich die Kommunikation zwischen den Verantwortlichen in unterschiedlicher Ausprägung dar. Reviews von Vorschlägen werden meist über Mailing abgewickelt und von einem Verantwortlichen, werden die Kommentare zusammengetragen. In wichtigen Angelegenheiten werden Telefon- oder Videokonferenzen zur Klärung von Problemen in einem Prozessablauf genutzt. Allgemeine Fragen werden in Foren vorgetragen und diskutiert. Es wird ein Workshop oder eine Konferenz einberufen, bei der sich die Verantwortlichen direkt kennenlernen und Vertrauen zueinander gewinnen.

geschieht ständig unter der Bedingung, dass die neu geschaffenen Produkte auch produziert, geliefert und gewartet werden können. Der Fertigungsprozess wird quasi implizit mit entwickelt. Diese Kommunikation ist anfangs keinen starren Regeln unterworfen, sie dient jedoch dazu, die Regeln für den Produktionsprozess zu finden. Lösungen für alle die Prozesse und Organisationen übergreifende Kommunikation gibt es unter dem Namen Groupware. Groupware bietet vielseitige Möglichkeiten mit Partnern in Verbindung zu treten. Seit langem wird über Telefon, Fax und E-Mail kommuniziert. Nun kommen weitere Varianten hinzu, die auf die Erreichbarkeit der Partner und die effiziente Gestaltung von Verhandlungen ausgerichtet sind. Multichannel-Konzepte weiten die Technologie von Call/Contact-Centern auf alle Mitarbeiter des Unternehmens aus. Ebenso bieten sich für ein unternehmensübergreifendes Team vielfältige, technische Möglichkeiten zur Kontaktaufnahme beim gemeinsamen Entwurf (Modellierung), der Überwachung (Reporting, Real-time Monitoring) und der Wartung unternehmensübergreifender Prozesse. Das Zusammenwirken von Partnern in einem Netzwerk wird auch Kollaboration genannt (Bild 11.1). Es gibt zwei Ansätze in der Kollaboration: • Bei der zeitversetzten (asynchronen) Kollaboration greifen verschiedene Partner auf die gleiche Information zu. Wie im Web üblich stellt ein Mitglied Informationen bereit und die übrigen nutzen diese.

133

11 Kommunikationsportale

• Bei einer (synchronen) Kollaboration in Echtzeit wird Information von Mensch zu Mensch direkt ausgetauscht. Dies geschieht in der klassischen Form über das Telefon. Inzwischen sind Kommunikationstechnologien, wie Web Chat, Conferencing oder das Co-Browsing hinzugekommen. Beim Co-Browsing kann in einem virtuellen Meeting jeder gleichzeitig die Dokumente sehen, um die es gerade geht. Eine neue Dimension der Teamkommunikation stellen Presence Server dar. Ein solcher Server verwaltet die aktuelle Kommunikationsbereitschaft jedes Teilnehmers. Des Weiteren ist dort das Medium hinterlegt, über das der Teilnehmer gerade angesprochen werden will. Beides erspart in dringenden Situationen erfolglose Versuche der Kontaktaufnahme. Die Aufgabe der Presence Server ist das Bereitstellen einer aktuellen Verfügbarkeitsliste (Buddy List) im Netzwerk der Geschäftspartner. Presence Server verteilen die Information nach dem Subscriber-Prinzip auf Application Server (SIP Servlets), welche andererseits Media Server (z. B. eine PBX) via CPL (Call Processing Language) steuern, um eine gewünschte Kommunikationsverbindung herzustellen. Wenn man davon ausgeht, dass heute nur zwei von fünf Anrufen im Bürobereich zu Gesprächsverbindungen führen, so ist der Nutzen der Technologie offensichtlich. Kommunikationsportale Neuartig ist das Verschmelzen von Portal-Funktionen mit Kommunikations-Funktionen. So kann das Mitglied eines Teams, welches durch einen Hinweis, der im Portal aufläuft, Unregelmäßigkeiten in der Struktur oder im Ablauf eines Prozesses entdeckt, diese sofort mit dem Verursacher direkt klären. Er erkennt im Portal-Fenster, ob dieser gerade erreichbar ist, klickt auf einen Button am Rand und schon meldet sich der gewünschte Kommunikati-

Bild 11.2: End-to-End-Prozess-Entwicklung und -Monitoring. Die Nutzung und Wartung von unternehmensübergreifenden Services und Prozessen basiert auf Teamwork. Das Business Activity Monitoring (BAM) liefert den Prozessverantwortlichen Einblick in das aktuelle Geschehen. Über Prozess-Portale mit Kommunikations-Portlets kann eine Problemkonferenz (Chat) spontan ausgelöst werden.

134

11.3 Groupware-Produkte

onspartner. Das Zusammenspiel des Teams erfolgt unternehmens- und systemübergreifend. Gemeinsame Dokumente sind dabei im WebDAV-Format hinterlegt (Bild 11.2). Contact Server Contact Server stellen die Verbindung von einem Kunden, der sich über unterschiedliche Medien an ein Unternehmen wendet, zu einem Contact Center her. Die damit zusammenhängenden Funktionen in einer Multichannel Integration Platform sind Universal Queue und Routing Server. Die Universal Queue ist eine multimediale Warteschlange eines Contact Servers und puffert nicht nur Telefonanrufe, sondern auch Fax-Nachrichten und E-Mails sowie InternetRequests für Web Chats, über spezielle Web Seiten ausgelöste Telefonanrufe oder für CoBrowsing, das synchrone Navigieren von Kunden und Agenten in einer Website. Der Routing Server bewertet alle eingehenden Anfragen durch mehr oder minder komplexe Entscheidungsregeln, um den für einen Kunden am besten geeigneten und verfügbaren Agenten auszuwählen. Grundlage des Routings ist eine Datenbank, welche sowohl Informationen über den Kunden, wie etwa seine Wichtigkeit für das Geschäft, seine Vorlieben, seinen Aufenthaltsort, seine Interaktionshistorie usw., als auch über den Agenten enthält. Beim Routing der Anfrage übergibt der Contact Server alle Kenndaten über den Anfragenden an die CRM-Anwendung. Die für die Gesprächsführung notwendigen Inhalte werden im Agenten-Portal zusammengestellt und präsentiert.

11.3 Groupware-Produkte Microsoft Live Communications Server (LCS) Der LCS ist ein Produkt zur Echtzeit-Kommunikation. Er integriert den MSN Messenger Connect und fügt den Offices Tools Präsenzfunktionen hinzu. So erscheint auf einem Word-Dokument oder einer Outlook-Mail ein Icon, wenn der Autor momentan verfügbar ist. Ein Leser klickt auf den Namen des Autors um mit ihm in Verbindung zu treten, ohne dabei Word oder Outlook zu verlassen. LCS ist das erste Produkt, welches das SIP/SIMPLE-Protokoll umgesetzt hat. Mit dem Windows Messenger liefert Microsoft den erforderlichen SIP-kompatiblen Client. LCS verwendet Kerberos zur Identifizierung von Benutzern im Active Directory. Die Signalisierung der Präsenz erfolgt Hersteller-, Netzwerk- und Geräte-übergreifend. Der Fokus von LCS liegt auf Audio-, Video- und Datenkonferenzen im Intranet sowie Instant Messaging und Chat im Intranet und Internet. Für Audio-, Video- und Datenkonferenzen im Internet gibt es den Service Microsoft Office Live Meeting, den man mieten oder auf eigener Infrastruktur betreiben kann. Microsoft Windows SharePoint Services Die Windows SharePoint Services unterstützen Ad-hoc-Kollaboration und bieten elektronische Arbeitsräume, die auch mit Partnern im Extranet genutzt werden können. Sie enthalten unter anderem Funktionen für Newsgroups, Kontaktverwaltung, Terminkalender, Dokumentenmanagement. Zum Ausbau von Microsoft Office SharePoint zu einem voll135

11 Kommunikationsportale

Bild 11.3: Präsenzinformation in Microsoft Outlook2003. Microsoft nutzt in Outlook die Möglichkeiten zur Anzeige, ob ein Partner am Arbeitsplatz anwesend ist und ob er bereit ist, mit dem Leser einer Mail direkt zu kommunizieren. Verschiedene Formen und Farben zeigen dies an. Durch Klicken eines dieser Buttons wird auch angezeigt, wann ein Mitarbeiter erreichbar ist und über welches Medium er erreicht werden kann.

wertigen Portal Server gibt es Funktionen zum Suchen in Datenbeständen unterschiedlichen Typs, den vollen Zugang zur Integrationstechnologe über BizTalk und einen Single Sign-on Mechanismus. Reports im Rahmen des Business Activity Monitoring (BAM) können in die Dokumentverwaltung der Windows SharePoint Services eingespeist und als Portlet (bei Microsoft »Web Part«) zur Anzeige gebracht werden. Durch die Integration der Funktionen des Live Communications Server können Dokumente von Microsoft Office (Word, Powerpoint, Excel oder Mail) als Ausgangspunkt für eine direkte Kommunikation genutzt werden (Bild 11.3). Die Telefonie über VoIP wird durch die Integration der Windows-Messenger-Produkte ermöglicht. Microsoft Exchange Exchange ist der Mail- und Personal-Information-Management-Server. IBM Lotus Instant Messaging und Web Conferencing Diese Lotus-Produkte dienen der Kollaboration und Kommunikation von Mitarbeitern in einem Unternehmen in Echtzeit. Die entsprechenden Dienste sind als Portlets in Portale integrierbar oder auf jeder Web-Site nutzbar. 136

11.3 Groupware-Produkte

Die Dienste sind: • Chat Ermöglicht Chats zwischen zwei und mehreren Personen, mit oder ohne Moderation. • Whiteboard Damit können Erklärungen und Zeichnungen, etwa Prozess-Pläne, auf einem Whiteboard dargestellt werden und sind so allen Teilnehmern einer Konferenz gleichzeitig präsent. • Application Sharing In einer Konferenz kann der Bildschirm einer Anwendung, ein Process Activity Panel, Chart oder Report über einen Moderator allen Teilnehmern zugänglich gemacht werden. • Conferencing Für eine Konferenz könnte die Präsenzfunktion genutzt werden, davon ausgegehend über Chatting oder eine Sprach- oder Video-Konferenz zur Besprechung eines Problems im Prozessablauf verwendet werden. Lotus nutzt bei Konferenzen die standardisierten Protokolle und kann deshalb mit Microsoft Exchange interagieren. Damit steht einer gemeinsamen Diskussion von Prozessen, die unterschiedliche Welten überspannen, nichts im Wege. IBM Lotus Team Workplace Das Produkt unterstützt verteilte Entwicklungsteams beim Austausch von Ideen, beim Review von Dokumenten und damit auch bei der Entwicklung von Prozessen. Es dient der gemeinsamen Verwaltung von Dokumenten sowie einer Volltextsuche, der Verwaltung von Kalenderinformationen und von Tasklisten. Föderierte Suche in unterschiedlichen Datenhaltungen insbesondere im Bereich von Domino erfolgt mit dem Zusatzprodukt Lotus Discovery Server. Die Produkte Lotus Instant Messaging und Web Conferencing können in Lotus Team Workplace integriert werden. IBM Lotus Domino (Notes) Lotus Domino (Bild 11.4) unterstützt E-Mail und die Dokument-basierte Kollaboration auf Basis von Workflows, Diskussionsforen, Content Management, Calendering und Scheduling. IBM Lotus Workplace Dies ist eine Toolbox, mit der Funktionen eines Informations- und Kommunikationsportals auf die Bedürfnisse eines Benutzers zugeschnitten werden können, wie sie seinem Arbeitsablauf entsprechen. Brainloop Secure Dataroom Secure Dataroom von Brainloop dient der sicheren, unternehmensübergreifenden Bearbeitung von Geschäftsdokumenten bei kollaborativen Angeboten, Verträgen, Design und Spezifikation, komplexem Einkauf und bei Großprojekten. Secure Dataroom ist implementiert in .NET und benötigt Outlook und den Windows Explorer sowie zur Identifizierung der User ein Mobiltelefon. Secure Dataroom besitzt die folgenden wesentlichen Merkmale: 137

11 Kommunikationsportale

Bild 11.4: Präsenzinformation und Chat in Lotus (Notes). Ähnlich wie bei Outlook wird von Lotus Notes das SIP-Protokoll unterstützt. Das Bild zeigt den Start eines Chats auf Grund einer eingegangenen Mail. Der SIP-Standard verknüpft Lotus mit der Microsoft-Welt.

• Management von Dokumenten mit vollständiger Änderungshistorie; • Zugriff auf Dokumente aus dem Explorer und aus Office-Anwendungen unter Nutzung von WebDAV; • Check-in/Check-out für längeren Änderungszyklus mit zwischenzeitlichem Lesezugriff durch andere; • Konvertierung von Office-Formaten in PDF inklusive einer Markierung (Brainmark), die es ermöglicht Papierdokumente mit ihrem elektronischen Original zu verbinden und eindeutig zu kennzeichnen; • Unterstützung von kollaborativen Prozessen über Aufgaben, Meilensteine und Diskussionen, sowie Integration von externen Conferencing-und Instant-Messaging-Diensten. Zusätzlich steht ein Benachrichtigungsdienst zur Verfügung, der es jedem Teilnehmer ermöglicht, über Änderungen an Dokumenten informiert zu werden. Das System basiert auf sich selbst organisierenden Gruppen. Neue Mitglieder können jederzeit eingeladen werden und erhalten sofort Zugriff. Identifikation der Benutzer erfolgt über Login und Passwort und optional zusätzlich über einen One-Time-Key, der per SMS auf das Mobiltelefon gesandt wird. Damit ist eine sichere Identifikation von Benutzern möglich. Das System unterstützt die Verschlüsselung der Datenströme und der Dokumente auf der Festplatte, so dass die Dokumente nur den Berechtigten zugänglich sind und selbst Systemadministratoren keinen Zugriff auf die Dokumente haben. 138

12 Kontrolle und Vertrauen in föderativen Netzwerken

Damit Unternehmen die Früchte ihrer Kernkompetenz ernten können, ist es notwendig, mit Anbietern unterstützender Kompetenzen eine Partnerschaft einzugehen. Kooperationen, strategische Allianzen, Joint Ventures, Netzwerke, Franchising und Lizenzabkommen sind mögliche Gestaltungsformen. Durch die Zusammenarbeit von rechtlich und wirtschaftlich unabhängigen Unternehmen entstehen für alle Beteiligten einerseits Abhängigkeit und andererseits erhebliche Nutzeffekte. Die Abhängigkeit birgt freilich die Gefahr der opportunistischen Ausnutzung (vgl. Picot et al, 2003), doch der Ertrag kann, Reife der Partner vorausgesetzt, enorm sein. Das Wesen dieser Abhängigkeit lässt sich gut mit dem Prisoner’s Dilemma (z. B. Rapoport und Chammah, 1965) erklären. Die Partner müssen reif genug sein, Entscheidungen zu treffen, die zwar für alle die günstigsten sind, sich selbst aber dabei im Fall eines Vertrauensbruchs durch einen der Partner zum Verlierer machen können. Um die Gefahr der Ausnutzung zu mindern, streben die Unternehmen enge Verbindungen untereinander an, die neben Verträgen ganz besonders auch auf Vertrauen basieren. Die wirtschaftlichen, räumlichen und rechtlichen Grenzen der Unternehmen verwischen, weil Unternehmen zusehends Leistungen, die sie ursprünglich selbst erbrachten, vom Markt beziehen, weil durch den Einsatz von Informationstechnologie Standortgrenzen überwunden werden und weil selbst innerhalb der Unternehmen Aufgaben von externen Partnern durchgeführt werden. Ohne Vorkehrungen führt dies zu höherer Komplexität, zu Missverständnissen oder opportunistischer Ausnutzung. Abhilfe schaffen Vertrauen, Kommunikation und Integration der Unternehmensprozesse. Es gibt z. B. keinen Schritt im Lieferprozess des PC-Herstellers Dell, an dem etwa die Qualität der Monitore eines Zulieferers überprüft wird oder überprüft werden müsste. Die Zulieferer sind von sich aus stark daran interessiert, das Ansehen von Dell beim Endkunden zu steigern bzw. es jedenfalls nicht zu schädigen (Dell, 1999). Unternehmen sparen durch Kooperationen Kosten, bezahlen dafür jedoch mit einem größeren Aufwand für die Pflege besserer Beziehungen im Wertschöpfungsnetzwerk. Wie sollen diese übergreifenden Beziehungen gestaltet werden? Kooperationen sind mittel- bis langfristig angelegte Formen vertraglich geregelter Zusammenarbeit rechtlich selbstständiger, autonomer Unternehmen. Unternehmen sind in dem Grade autonom, in dem sie Entscheidungen über Aufnahme und Beendigung der Kooperation selbst fällen können. Die Zusammenarbeit dient dem gegenseitigen Nutzen. Solche symbiotischen Kooperationen werden dann eingegangen, wenn damit Zeit-, Kosten-, Know-how-Vorteile, Kompetenzgewinn, Verringerung von Risiken und Marktzugang erreicht wird. Kooperationen sind also eine Form der Ressourcenzusammenlegung. In Gremien werden Art und Umfang der einzubringenden Ressourcen und die Verteilung der erzielbaren Erträge festgelegt.

139

12 Kontrolle und Vertrauen in föderativen Netzwerken

Dabei lassen sich vertikale, horizontale und diagonale Kooperationen unterscheiden: • Vertikale Kooperationen liegen vor, wenn Unternehmen der gleichen Branche aber aus aufeinander folgenden Stufen der Wertschöpfungskette zusammenarbeiten (z. B. Zulieferer in der Automobilindustrie). • In horizontaler Kooperation arbeiten Unternehmen der gleichen Branche und Stufe der Wertschöpfungskette zusammen. Forschungszusammenarbeit ist ein typisches Beispiel dafür. • Bei diagonalen Kooperationen arbeiten Unternehmen unterschiedlicher Branchen und unterschiedlicher Stufe der Wertschöpfungskette zusammen (z. B. Restaurantketten und Mobiltelefonhersteller). Natürlich beschränken sich Kooperationen nicht auf jeweils zwei Partner. Rechtlich mehr oder weniger unabhängige Unternehmen organisieren sich zu übergreifender Zusammenarbeit in Netzwerken. Um eine Kooperation eingehen zu können, muss das eigene Unternehmen die Anforderungen von Kunden, Wettbewerb, technologischen und gesellschaftlichen Veränderungen erkennen. Aus dem Vergleich dieser Anforderungen mit den im Unternehmen vorhandenen Ressourcen lassen sich die Defizite identifizieren. Diese Defizite gilt es durch Kooperation zu beseitigen. Bei der Entscheidung über eine Kooperation müssen sowohl die Vorteile als auch Nachteile berücksichtigt werden. Für das Eingehen einer Kooperation spricht die Möglichkeit, die eigene Wettbewerbsfähigkeit durch die Hilfe eines Partners zu steigern. Ein Nachteil einer Kooperation ist immer auch die damit verbundene Verringerung der eigenen Autonomie. Bei der Wahl eines Kooperationspartners spielen Größe, Macht oder Ressourcen eines Unternehmens genau so eine Rolle wie die Vertrauenswürdigkeit und die Zuverlässigkeit. Im Rahmen eines Gestaltungsprozesses müssen die Organisationsstrukturen, die Unternehmenskulturen, die Management-Philosophien oder die Ressourcenbeiträge aufeinander abgestimmt werden. Kooperationen müssen einer permanenten Bewertung hinsichtlich ihrer Wirkung unterzogen werden. Positive Wirkungen sind der Ausgangspunkt für einen weiteren Ausbau und zu einer Stabilisierung. Die Ursachen negativer Wirkungen müssen analysiert werden, um frühzeitig Gegenmaßnahmen einleiten zu können. Diese Bewertung ist die Basis für eine verbesserte Gestaltung der Kooperation.

12.1 Vertrauen und Verträge Kooperation ist nicht nur ein wirtschaftlicher, sondern auch ein sozialer Prozess, der in erster Linie von Menschen getragen wird, die über vertragliche Verpflichtungen hinaus wechselseitige Beziehungen ausbilden und pflegen. Voraussetzung zur Ausbildung von Beziehungen ist das Wiedererkennen von Menschen und Objekten. Wesentlichen Einfluss auf dieses Geschehen hat die Erfahrung, dass das Verhalten des Kooperationspartners vorhersehbar und auf gemeinsamen Nutzen ausgerichtet ist. Grundlage jeder Kooperation ist Vertrauen. Vertrauen ist ein psychisches und soziales Phänomen zur Überbrückung von Unsicherheit über das Verhalten von Kooperationspartnern. Im wirtschaftlichen Kontext können Leistung und Gegenleistung oftmals nur zeitlich ver140

12.1 Vertrauen und Verträge

zögert und nacheinander ausgetauscht werden. Aus dem sequentiellen Charakter ergibt sich die Bedrohung, dass der Kooperationspartner die impliziten oder expliziten Vereinbarungen bricht. Vertrauen tritt als Mechanismus beim Vertrauenden auf, der die Unsicherheit ausblendet und ihn handlungs- und entscheidungsfähig hält (vgl. Preisendörfer, 1995). Vertrauen beruht auf einer Einschätzung des Kooperationspartners. Die Einschätzung beruht entweder auf eigener Erfahrung oder Erfahrung Dritter. Reputation ist öffentliche Information über das vergangene Verhalten des Kooperationspartners. Entscheidend für die Aussagekraft der Reputation für das zukünftige Verhalten des Partners ist neben der Güte der Informationsquelle auch die Möglichkeit zur Sanktion und Veröffentlichung gegenteiliger Erfahrung. Die Aussagekraft der Reputation ist umso höher als im Falle opportunistischen Verhaltens durch Reputationsverlust Kooperationsgewinne zukünftig nicht mehr erreichbar wären. Vertrauen bringen Menschen nicht nur anderen Menschen, sondern auch technischen Systemen und Organisationen entgegen (vgl. Koch et al., 2000). Vertrauen als psychisches und soziales Phänomen verschafft dem Handelnden Sicherheit in Situationen, die er hinsichtlich des Ergebnisses nicht unter Kontrolle hat. Das Risiko des Vertrauensbruchs wird nebenbei durch Gesetze, Konventionen und Moral gemindert. Stabile soziale Bezüge und Regeln innerhalb von Organisationen geben einen zusätzlichen Rahmen für die Entwicklung von Vertrauen, so dass ein Teil der individuellen Prüfung des Kooperationspartners unnötig und Rituale reduziert werden können. Die Dauer einer Beziehung und die dabei gemachten guten Erfahrungen mit dem Kooperationspartner festigen das Vertrauen. An Vertrauen knüpft sich aber auch die Erwartung, dass der Kooperationspartner die Verantwortung für seinen Teil der Kooperation übernimmt. Er steht mit der Übernahme der Verantwortung für das Ergebnis gegenüber dem Kooperationspartner ein. Verträge Nicht nur Vertrauen und die Übernahme von Verantwortung im Rahmen von Geschäftsprozessen. auch vertragliche Vereinbarungen und den Kooperationspartnern verschaffen Sicherheit. In Verträgen werden die Rechte und Pflichten der Vertragspartner rechtsverbindlich festgelegt werden. Der Vertragsabschluss erfolgt in der Regel schon durch die Abgabe übereinstimmender Willenserklärungen der Vertragspartner. Der Vertrag legt meist auch Sanktionen, Zwangsmittel zur Durchsetzung rechtlicher Verpflichtungen fest. Sanktionen werden angewandt, wenn ein Kooperationspartner übernommene Verpflichtungen nicht erfüllt. Non-Disclosure Vertrauensvolle Kooperation setzt die vertrauliche Behandlung und Geheimhaltung der übermittelten Information voraus. Im Non-Disclosure Agreement (NDA) verpflichten sich Kooperationspartner einerseits zur Übermittlung relevanter Information an den Partner und andererseits zur Geheimhaltung, der gegenseitig mitgeteilten Erkenntnisse und Informationen, die insbesondere im Zusammenhang mit Neuentwicklungen, Vorführungen, Versuchen und Gesprächen stehen. Sie treffen alle erforderlichen Maßnahmen, um deren Kennt-

141

12 Kontrolle und Vertrauen in föderativen Netzwerken

nisnahme und Verwertung durch Dritte zu verhindern. Bei einem Verstoß gegen die Vereinbarung kann neben einer Vertragsstrafe auch Schadensersatz beansprucht werden. Non-Compete Ein Non-Compete Agreement verpflichtet Kooperationspartner dazu, am Markt nicht zu konkurrieren und direkt mit den Kunden des Kooperationspartners Geschäfte zu machen. Dies gilt besonders dann, wenn dazu Informationen genützt werden, die aus der Kooperation gewonnen wurden. Service-Level Agreement Ein Service-Level Agreement (SLA) legt fest, welche Services oder Anwendungen mit welchen Funktionalitäten dem Partner zur Verfügung stehen und in welchem Umfang der Service verfügbar ist. Ein SLA kann beispielsweise festlegen, dass mindestens 98 Prozent aller Transaktionen eines Service in maximal einer Sekunde durchgeführt werden müssen. Angaben, die ein SLA typischerweise enthält, sind detaillierte Angaben zu Art, Umfang und Handhabung von Services, genaue Preise, Laufzeit der Vereinbarung, Ausmaß der Verfügbarkeit, also Mindestbandbreiten, Skalierbarkeit, Zugriffszeiten, Sicherung der Verfügbarkeit, Sicherheitsvorkehrungen, mögliche Ersatzdienste und Informationspflichten des Anbieters. Ein SLA beschreibt also die Nutzungsbedingungen und die Interaktionen zwischen Nutzer und Anbieter über den gesamten Lebenszyklus eines Service. Die einzelnen Phasen reichen von Provisioning bis Termination und sollten je nach Art, Umfang und Wichtigkeit des Dienstes im SLA beschrieben werden: • Provisioning Die Bereitstellung des Service umfasst Installation, Test und Abnahme und, wenn notwendig, Migration von vorhandenen Services. • Nutzung Normale Nutzung des Service beinhaltet z. B. die typische Antwortzeit. • Betrieb Alle Aktivitäten in Zusammenhang mit Administration und Betrieb des Service durch den Anbieter. • Wartung Geplante Aktivitäten zur Aufrechterhaltung und Verbesserung des Service. • Accounting Sammeln und Verarbeiten von Daten zur Abrechnung. • Change Management Erweiterung, Beendigung und Änderung des Service. • Problem Management Benachrichtigung über Identifikation und Lösung von Problemen des Service. • SLA Management Anpassung und Kontrolle der Einhaltung des SLA. • Customer Care Unterstützung der Nutzer.

142

12.2 Organisation kooperativer Prozesse

• Termination Deinstallation des Service. Darüber hinaus sind Vereinbarungen bezüglich Art und Umfang der Dokumentation, Eskalationsmechanismen und Art und Höhe von Entschädigungen bei Nichteinhaltung der zugesicherten Service-Levels zu treffen. Web Service-Level Agreements IBM spezifiziert ein Web Service-Level Agreement (WSLA) Framework um SLAs mittels XML zu beschreiben. Die Zusicherungen des Service-Anbieters beruhen auf definierten Parametern und Algorithmen und Beschreibungen, wie diese Metriken gemessen und zusammengefasst werden. WSLA kann auch die Operationen beschreiben, die den Service überwachen und administrieren. Diese maschinenlesbare Vereinbarung kann direkt als Regulations-, Überwachungs- und Steuerungsinstrument eingesetzt werden. Wenn die Anwortzeit unter den vereinbarten Schwellenwert sinkt, wird automatisch ein weiterer Rechner in den Grid (Kapitel 7) integriert (vgl. Leff et al., 2003).

12.2 Organisation kooperativer Prozesse Durch die gestiegene Zahl an internen und externen Interaktionen und bei steigender Variabilität dieser Beziehungen steigt die Komplexität der Organisation. Gleichzeitig kommt es zu einem erhöhten Koordinationsbedarf im Rahmen der betrieblichen Leistungsbringung. Der Markt, dem sich die Unternehmen möglichst schnell und mit geringem Aufwand anpassen müssen, verändert sich kontinuierlich. Die Anpassungsvorgänge führen in Verbindung mit den vor- und nachgelagerten Kooperationspartnern zu einer Zunahme der Komplexität der Prozesse im Unternehmen. Um handlungsfähig zu bleiben und damit die Stellung am Markt zu erhalten und auszubauen zu können, müssen die Unternehmen dieser Komplexität entgegensteuern, z. B. durch geeignete Organisationsformen (Bild 12.1), und sie beherrschen. Traditionelle, hierarchische Organisationsstrukturen sind zu langsam, um rasch auf veränderte Anforderungen zu reagieren. Die hierarchische Organisation ist gekennzeichnet durch die räumliche und personelle Trennung von konzeptionellen, steuernden und überwachenden Aufgaben, von planender und ausführender Arbeit. Die Prozesse sind auf Zerlegung standardisierter Arbeitsschritte ausgelegt. Im Vordergrund steht die Produktivitätssteigerung der einzelnen Unternehmensbereiche durch Spezialisierung. Verstärkte Innovationsfähigkeit, schnellere Aufgabenbewältigung und kürzere Reaktionszeit auf Veränderungen des Marktes und die Vernetzung zwischen Unternehmen sind durch horizontale, modulare Organisationsformen besser zu erreichen. Eine vertikale, modulare Organisation baut auf der vollständigen Abwicklung kundennaher Prozesse durch relativ kleine, überschaubare Einheiten auf. Die Module zeichnen sich durch dezentrale Entscheidungskompetenz und Ergebnisverantwortung aus. Die Koordination zwischen den modularen Einheiten erfolgt verstärkt durch Zielvorgaben. Merkmale modularer Organisation sind schwache Abhängigkeiten zwischen den Modulen und starke Abhängigkeiten innerhalb der Module. Beabsichtigte Wirkungen sind eine reduzierte Anzahl von Beziehungen zwischen den Modulen und intensive Beziehungen inner-

143

12 Kontrolle und Vertrauen in föderativen Netzwerken

Bild 12.1: Organisationstypen (nach Picot et al. 2003, modifiziert). Marktunsicherheit bedeutet Planungsunsicherheit. Die Betrachtung von Transaktionskosten zeigt die Effizienz eines Organisationstyps im Zusammenhang mit der Komplexität von Märkten und Produkten. Durch ein verschärftes Controlling vermindern hierarchische Strukturen die bei virtuellen Organisationen normalerweise gegebenen »Costs of Non-Conformance«.

halb der Module. Die Analogie zur Modularisierung aus der Softwareentwicklung (Parnass, 1972) lässt sich nicht leugnen. Modulare Organisationsformen sind Voraussetzung für Föderation. Die Performanz bei der Verteilung von Software Services in einem Netzwerk ist ein Äquivalent für die Einsparung von Transaktionskosten (Fielding 2000). Modularisierung unterstützt die Ausrichtung der Organisation an Geschäftsprozessen. Reichwald und Möslein (1997) meinen: »Vorrangiges Ziel der prozessorientierten Ansätze ist die Reduktion organisatorischer Schnittstellen im Leistungsprozess. Schnittstellenprobleme, wie z. B. Kommunikationsbarrieren, Zielkonflikte oder Liegezeiten an den Grenzen zwischen Funktionalabteilungen sind in den letzten Jahren als eine der wichtigsten organisatorischen Ursachen für mangelhafte Wettbewerbsfähigkeit von Unternehmen erkannt worden.«

12.3 Neue Rollen für Kunden, Mitarbeiter und Führungskräfte Neue Rollen für die Kunden Die Rolle des Kunden wandelt sich vom Waren- und Dienstleistungsempfänger zum Partner bei der Entwicklung und Gestaltung von Produkten. Er wird zum Partner, mit dem ein Anbieter das erwartete Produkt spezifiziert, konfiguriert und entwickelt (vgl. Reichwald und Piller, 2002; Siebel und House, 2000).

144

12.3 Neue Rollen für Kunden, Mitarbeiter und Führungskräfte

Hier ein Beispiel für das Prinzip einer durchgängigen Nutzenorientierung: In der Wertschöpfungskette der Form »Endkunde-Hersteller-Zulieferer« wird der Hersteller frühzeitig in den Forschungs- und Entwicklungsprozess des Zulieferers eingebunden. Die Anforderungen an das Produkt werden mittelbar vom Endkunden des Herstellers bestimmt. Also muss der Zulieferer vom Hersteller qualitative, preisliche und zeitliche Anforderungen an das Produkt erfahren. Mitarbeiter des Herstellers werden daher frühzeitig in das Entwicklungsteam des Zulieferes einbezogen. Ist eine Entscheidung über die Produktentwicklung gefallen, werden zusätzlich Endkunden einbezogen. Diese frühe Integration des Endkunden, die frühzeitige Ausrichtung an den Marktbedürfnissen, ist in der Regel sehr rentabel. Es ist eine Tatsache, dass die Mehrzahl der Innovationen von einem Bedürfnis des Marktes und damit direkt vom Endkunden ausgelöst werden und nicht von neuen Technologien und Konzepten. Der Endkunde sagt dem Hersteller (Ingenieur), was er will. Je mehr Aufwand der Kunde aus der Sicht des Lieferanten investiert, desto mehr Interesse wird er haben, die Beziehung zum Lieferanten aufrecht zu erhalten. Es lohnt sich für den Kunden loyal zu sein. Neue Lieferanten zu suchen, Vertrauen aufzubauen, gemeinsame Regeln und Normen zu vereinbaren, ist ein mühsamer und aufwändiger Vorgang. Neue Rollen für Mitarbeiter und Führungskräfte Mit den steigenden Anforderungen des Marktes und der Kunden steigen auch die Anforderungen an die Mitarbeiter, an ihre fachlichen und persönlichen Qualifikationen, ihre Leistungsbereitschaft, ihre Umsicht und an ihr Verantwortungsbewusstsein. Die Führungskräfte unterstützen und coachen die Mitarbeiter. Bei der Produktion komplexer Produkte durch erfahrene Mitarbeiter und selbständig agierende Teams kann die Qualität durch eine Führungskraft nicht mehr kontrolliert werden. Im Unternehmen wird jeder Mitarbeiter selbst verantwortlich für sein Handeln. Führen bedeutet nun, die Interessen des Unternehmens und der Mitarbeiter miteinander in Einklang zu bringen. Mitarbeiter wollen den Sinn ihrer Arbeit verstehen und nicht nur Befehle ausführen. Wenn sie über die Zusammenhänge, die Ziele und ihre Rolle im Unternehmen, im Projekt Klarheit bekommen, bewegen sie sich von selbst auf das Ziel zu. Gute Führungskräfte sorgen dafür, dass die Mitarbeiter immer größere Komplexität beherrschen können. Eine Führungskraft hat dafür zu sorgen, dass die Leistung der ihr anvertrauten Mitarbeiter den Wert am Weltmarkt erhält oder erhöht. Dazu müssen die Führungskräfte ihre Mitarbeiter fördern, fordern und weiterentwickeln zu neuen Aufgaben und Rollen. Überwachung und Change Management für Prozesse Wie können die Geschäftspartner rasch und flexibel auf neue Anforderungen des Marktes reagieren? Es wird notwendig werden, dass die Entscheidungskompetenz über Prozesse an Prozessverantwortliche (Process Owner) übertragen wird. Diese werden dann gleichsam mit Prozess-Prokura ausgestattet sein. Diese Vollmacht gibt den Verantwortlichen die Möglichkeit Prozesse zu verändern und anzupassen. In Prozess-Review-Teams werden sich die Kooperationspartner zusammenfinden, um die notwendigen Anpassungen am externen Prozess zu beschließen.

145

12 Kontrolle und Vertrauen in föderativen Netzwerken

Beziehungen einzugehen ist ein komplexer, emotionaler Vorgang, geprägt von Gefühlen wie Vertrauen, Reputation und Verantwortung. Unternehmen werden umso attraktiver sein, je schneller sie in der Lage sind Vertrauen zu schaffen und zusammen mit ihren Partnern externe Prozesse zu vereinbaren, zu verändern und umzusetzen. Die internen Prozesse jedoch, also die Vorgehensweisen, mit denen ein Unternehmen seine Leistung erbringt, bleiben ein Erfahrungskapital und damit das Geheimnis auch zwischen Partnern.

146

13 Rückblick und Ausblick

• • • • •

Was will das Buch vermitteln? Was wird und soll sich ändern? Wie ändern sich Organisationen? Gibt es Software Engineering? Können Integrationsvorhaben von der neuen Technologie profitieren?

13.1 Rückblick Aus unseren Überlegungen ziehen wir den Schluss, dass die untersuchten technologischen Konzepte die richtigen für die Modellierung zukünftiger Unternehmen sind, in denen die organisatorischen Anforderungen mit den technischen in Einklang gebracht sind. Das untersuchte Konzept von lose gekoppelten Services und adaptiven Prozessen ist eine Erweiterung dieses Prinzips über die Grenzen von Unternehmen hinaus. Dem Besten wird es dadurch möglich seine Ziele zu verfolgen und sich föderativ in das Netzwerk der Wertschöpfung einzugliedern. Die bedeutsamsten Aussagen sind: • Kapitel 1 Das föderative Organisationsprinzip, welches dem Zusammenwirken von Unternehmen Robustheit und Vitalität verleiht, wird als grundlegendes Konzept für das Zusammenwirken von Geschäftspartnern postuliert. • Kapitel 2 Grundlegende Konzepte betriebswirtschaftlichen Geschehens werden erläutert. Die Ansprüche, die Unternehmen in föderativen Organisationen haben, werden skizziert. • Kapitel 3 Unternehmen werden ihre Prozesse und Services neu definieren und als Blaupause ihren Partnern anbieten. Dies erleichtert die Suche nach neuen Geschäftspartnern für geänderte und neue Geschäftsideen. Die Blaupausen dienen zudem als Mittel der Strukturierung künftiger Standardlösungen. • Kapitel 4 Die Service-orientierte Architektur verfolgt den Gedanken der Wiederverwendung von Anwendungen und Daten über Netzwerke. Die Anwendungen (Services) sind mit einem Standard-Interface versehen und über das Netz aufrufbar. Die Daten der Services in einem Wertschöpfungsnetzwerk bilden zusammen eine virtuelle Datenbank. Sie müssen permanent über Abgleichsprozesse synchronisiert werden. • Kapitel 5 Workflows sind ein bevorzugtes Mittel zur Modularisierung von betriebswirtschaftlichen Lösungen. Sie erlauben eine rasche Anpassung von Lösungen an neue Anforderungen, wie etwa die Integration zusätzlicher Geschäftspartner. 147

13 Rückblick und Ausblick

• Kapitel 6 Web Services sind nur zum Teil standardisiert. Web Service Security ist die heikelste Herausforderung bei der unternehmensübergreifenden Nutzung von Web Services. Die Standardisierung von Workflows in Form der Business Process Execution Language (BPEL) ist in vollem Gange. Derzeit werden Frameworks angeboten, welche die im Standard noch fehlenden Elemente als proprietäre Ergänzungen enthalten. • Kapitel 7 Grid Services und Grids sind eine Technologie zur Nutzung und verbesserten Auslastung heterogener IT-Ressourcen. Im Bereich betriebswirtschaftlicher Anwendungen werden daraus große Rechenzentren entstehen. • Kapitel 8 Föderierte Datenhaltungen bündeln Datenbanken unterschiedlichen Typs unter einer gemeinsamen Zugriffsschicht. Dabei können die auf die unterschiedlichen Bedürfnisse zugeschnittenen Speicherstrukturen beibehalten werden. • Kapitel 9 Die Entwicklung von Lösungen auf der Basis der Integration bereits vorhandener Services lehnt sich in der Methode an die Erweiterung von Standardlösungen wie etwa SAP R/3 an. Es entsteht eine Konvergenz von Analyse-, Modellierungs-, Design- und Implementierungstools. • Kapitel 10 Informationsportale dienen der Integration unterschiedlicher Anwendungen am Arbeitsplatz über das grafische User-Interface unter Berücksichtigung der Erfordernisse des Benutzers. Verschiedene Services in einem Netzwerk werden als Portlets eingebunden. Zugriffe über unterschiedliche Endgeräte auf den gleichen Vorgang werden zum gängigen Szenario. • Kapitel 11 Kommunikationsportale sind eine Generalisierung der Agentenportale in Contact Centern. Alle auf einem Bildschirm gezeigten Informationen werden mit Präsenzinformation über die Autoren verknüpft und auf Knopfdruck kann mit diesen direkt Kontakt aufgenommen werden, z. B. durch einen Web-Chat oder über Telefon. • Kapitel 12 Modulare, autonome Organisationen entstehen aus der Notwendigkeit der schnellen Anpassung des Geschäfts an sich sprunghaft verändernde Märkte und als Mittel zur Senkung der Transaktionskosten in den Unternehmen. Die zunehmende Disaggregation von Unternehmen erfordert ein Überdenken der Spielregeln von Vertrauen und Kontrolle zur Stabilisierung der volatilen Organisationsformen.

13.2 Ausblick Nicht die Zukunft vorherzusagen, ist unsere Absicht, sondern auf Möglichkeiten und Chancen hinzuweisen. Web Services und Workflows ante portas Das Interesse an Web Services als Minimalstandard ist begründet in einer Konvergenz von drei wichtigen und erfolgreichen Technologiebereichen:

148

13.2 Ausblick

• World Wide Web Web Services bieten die Chance zu einer Internet-basierten Integration jenseits der Browser-Technologie. • Middleware Web Services werden mittelfristig die Middleware-Technologie (J2EE, CORBA, .NET) als Laufzeitumgebungen für Services integrieren. • Traditionelles EDI Web Services bieten einen universellen Ansatz für den Leistungsaustausch in einer semantisch heterogenen Geschäftswelt. Es ist zu vermuten, dass grenzenlose Unternehmungen (Picot et al., 2003) als Folge der Geschwindigkeit, mit der sich Wissen über den Erdball verbreitet, die einzige Chance sind als leistungsfähiges Unternehmen zu überleben. Der Bau von Web Services ist keine anspruchsvolle Entwicklungstechnologie. In Kombination mit bewährten Konzepten ist sie einfach praktizierbar. Web Services sind aber eine organisatorische, ja politische Herausforderung ersten Ranges. Es ist heute schwer abzusehen, wie sich die Technologie im Bereich der unternehmensübergreifenden Interaktionen entwickeln wird. Viele Unternehmen wollen Herr im eigenen Haus bleiben. Nur im Bedarfsfall kommunizieren sie mit ihren Partnern und dann nur über das Notwendigste. Ungern geben sie Einblick in Zusammenhänge, in ihre Daten, ihre internen Prozesse, ihre Kernkompetenzen. Diese sind der Informationsvorsprung. Unternehmen öffnen sich nur, wenn sie der Markt dazu zwingt. Aber es sind die in diesem Buch vorgestellten Konzepte, welche den weltweit operierenden Unternehmen dabei helfen ihre Selbstständigkeit zu bewahren. Leider sehen erfolgreiche Hersteller im Gegensatz zu den Kunden Standards als Gefahr und betrachten sie immer mit einem gewissen Argwohn. Standards züchten quasi Konkurrenz, weil sie die Kosten und damit die Preise senken. Sie geben Neueinsteigern Chancen und bringen »Platzhirsche« in Bedrängnis. Standards liegen im Interesse des Kunden, und der will Qualität und niedrige Preise. Dadurch entsteht Druck vom Markt, der unumgänglich zu einer weiteren Rationalisierung, also zu einer Standardisierung der Prozesstechnologie, führen wird. Und umgekehrt hat dies unmittelbare Auswirkungen auf die Unternehmensorganisation in der Zukunft. Der Übergang zu Unternehmensnetzwerken Das Muster für die Organisation von Unternehmen stammt ursprünglich aus dem militärischen Bereich. Dort sind es die Waffengattungen und das Training dafür, welche die organisatorische Klammer bilden. Freilich wurden die zunächst auf zentrale Führung ausgelegten Befehlsstrukturen schon im 19. Jahrhundert bei den europäischen Armeen gelockert, was zu einer erheblichen Steigerung der Effizienz führte (Henkel, 2003). Im Bereich der Organisation kam es in den 90er Jahren des letzten Jahrhunderts zur Einführung dieses subsidiären Prinzips. Die Verantwortung wird an die Stelle im Unternehmen übertragen, an welcher die größte Kompetenz zur Bewältigung einer Aufgabe vorliegt. Dies soll insbesondere dazu dienen, die Reaktionszeit zu verringern, mit der ein Unternehmen seine Geschäfte erledigen kann. Auf der Seite der Technologie entspricht dies dem Client-Server-Prinzip.

149

13 Rückblick und Ausblick

Bild 13.1: Transformation von Organisationseinheiten in Knoten von Unternehmensnetzwerken. Die Mitarbeiter eines Unternehmens werden zunehmend mehreren Aufgabenbereichen eines Unternehmens zugeordnet. Die klassischen Hierarchien lösen sich damit auf. Es entstehen weitgehend selbständige Aktionsknoten, welche sich schneller den neuen Anforderungen des Marktes anpassen.

Die Funktionsfähigkeit von Organisationen hängt immer mehr von der verwendeten Software ab. Mitarbeiter arbeiten heute mit einer großen Zahl verschiedener Werkzeuge und sie arbeiten immer unabhängiger zu ihren organisatorischen Einheiten. Sie arbeiten in Netzwerken (Bild 13.1). Dabei kann jeder Mitarbeiter gleichzeitig in unterschiedliche Netzwerke eingebunden sein. Diese Netzwerke verfolgen unterschiedliche Ziele und sind dabei eine Virtualisierung der klassischen Organisationseinheiten. Beispiele für diese virtualisierten Einheiten könnten sein: Personalwesen, Marketing, Planung, Kostenrechnung, Verkauf, Kundenservice, Produktentwicklung, Auslieferung oder Einkauf. Die technologische Basis dieser Netzwerke sind Kollaborations- bzw. Koordinationsplattformen. Portale und insbesondere Workflows sind geeignet, das Zusammenspiel in den Netzwerken erheblich zu unterstützen. Die lange Zeit vom mittleren Management geleistete Koordinationsaufgabe wird dabei reduziert. Die Ausrichtung dieser Netzwerke und ihrer Mitarbeiter an den Unternehmenszielen geschieht durch permanente Durchsprachen der Zielrichtung. Automatisches Prozessdatenmanagement und Verdichtung erlauben es dem Management, Einblick in die Performance der Prozesse zu nehmen und von Fall zu Fall einzugreifen. Ein mittelbares Reporting des mittleren Managements wird drastisch reduziert. Dabei entwickelt sich vielleicht die Rolle des heutigen Process Owners zu der eines aktiven Process Managers oder gar Service Node Managers. Somit ist das Paradigma von Workflows weit mehr als ein neuer Programmierstil für besser wartbare betriebswirtschaftliche Anwendungen. Es steht auch für die Virtualisierung aller

150

13.2 Ausblick

betriebswirtschaftlichen Einheiten, bei denen ein räumliches Zusammenwirken von Mitarbeitern keine notwendige Bedingung ist. Die elektronischen Netzwerke erlauben es, dass Mitarbeiter die unterschiedlichsten Aufgaben eines Unternehmens ad-hoc übernehmen. Dies fördert die Abwechselung am Arbeitsplatz und gleichzeitig die bessere Nutzung der Fähigkeiten von Mitarbeitern. Eine Qualitätssicherung bei Leistungen erfolgt durch Reviews. Dieses Geben und Nehmen, wie auch heute noch in intakten Dorfgemeinschaften üblich, ist auch im globalen Dorf von Vorteil. Technologische Treiber der Virtualisierung von Organisationen Am Beginn der industriellen Produktion stand die Arbeitsteilung mit der Spezialisierung einzelner Arbeiter für bestimmte Aufgaben. Der Grund lag im Wunsch, viele wenig geschulte Arbeiter in die Produktion, z. B. von Automobilen, einzubeziehen. Dies war aber zugleich eine Einschränkung des Freiraums. Deshalb mögen viele die Workflow-Technologie als eine Wiederkehr des Taylorismus beargwöhnen. Damals hatte die neue Einteilung der Arbeit in kleine Einzelschritte den Zweck, ungelernte Arbeitkräfte innerhalb der mechanischen Fertigung von Produkten nutzen zu können. Die Festlegung der Vorgehensweise lag dabei allein bei den Ingenieuren. In einem nächsten Schritt wurde der Blickwinkel von der eigenen Produktion auf die Beziehung eines Unternehmens zu seiner Außenwelt gelenkt und die Leistung eines Unternehmens wurde nicht mehr allein in operativen Bereich gesehen, sondern als Glied in einer Wertschöpfungskette. Föderativ organisierte Unternehmen gehen noch einen Schritt weiter, indem nun der Fokus auf dem strategischen Bereich und abgelöst von der konkreten Arbeit gesehen wird. Im Vordergrund stehen nun die Antworten, welche ein Unternehmen auf die sich aktuell bietenden Geschäftsmöglichkeiten im Markt geben kann. Um Chancen sofort zu nutzen, geht es nicht ohne eine weitere Delegation von Verantwortung an den einzelnen Mitarbeiter. Manager haben längst erkannt, dass es leichtfertig ist, die Intelligenz, Erfahrung und Initiative von Mitarbeitern brach liegen zu lassen, insbesondere dann, wenn Technologie die einfachen Aufgaben erledigen kann. Und dass es viel vernünftiger ist, das von den Mitarbeitern zu fordern, was eine Maschine eben nicht zu leisten vermag: Initiative, Behandlung von Ausnahmen, Erkennen neuer Chancen, Abstraktion von Information, Phantasie und insbesondere den Mut zum Handeln. So gesehen sind Workflows dazu da, aufmerksame, kreative und verantwortungsvolle Mitarbeiter von Routinearbeiten zu entlasten und einer neuen Art von Unternehmen zum Leben zu verhelfen. Workflows verschwinden dabei im Hintergrund und werden zu selbstverständlicher Routine. Der Vergleich mit der mechanischen Fertigung ist schon deswegen unangebracht, weil dort heute vorwiegend Roboter arbeiten. Das neue Paradigma der automatischen Services, welche im Kern mittels Workflows gesteuert und über Nachrichten integriert werden, kann und muss auf die von den Menschen erbrachten Services ausgedehnt werden. Ein Service-Knoten bündelt beide Serviceangebote (Bild 13.2). Damit werden Menschen nicht technischen Anwendungen gleichgestellt. Sie sind Träger der Verantwortung, die Partner für Service-Level Agreements und sie erbringen alle Service-Leistungen, welche nicht automatisch erbracht werden können. Sie können bei Störungsfällen eingreifen und auf Grund ihres Überblicks, ihrer Phantasie und ihrer Höflichkeit dem Unternehmen Geld und Ärger sparen. Dieser eindeutige Trend 151

13 Rückblick und Ausblick

Bild 13.2: Das Service-orientierte Unternehmen. Die zunehmende Nutzung von Werkzeugen und Anwendungen führt zu einer Virtualisierung der Organisation. Die Services werden in einem Unternehmen sowohl intellektuell als auch vollautomatisiert und in einem Mix von beiden erbracht. Mitarbeiter arbeiten über Portale mit Services und Geschäftspartner greifen unmittelbar über Programme oder mittelbar über Portale im Extranet darauf zu.

zur Höherqualifizierung der Mitarbeiter bedeutet in Konsequenz die weitere Automatisierung von formalisierten Routineprozessen durch die Technologie der Workflows. Die Konstruktion technischer Prozesse und das Ermöglichen des menschlichen Zusammenwirkens wird dabei zur vornehmsten Aufgabe der Managements im Service-orientierten Unternehmen. Senge (1994) veranschaulicht die Rolle des modernen Managers mit der des Designers eines Schiffs – und nicht, wie man vielleicht erwarten könnte, mit einem Kapitän oder Steuermann. Der Designer (Manager) eines Service-Knotens erstellt das Konzept, die Mission und die Vision für einen Service-Knoten. Der Mitarbeiter (Kapitän) kann später lediglich von den Gegebenheiten ausgehen, vor denen er im Einzelfall steht. Um im Bild zu bleiben, braucht jedes Schiff auch einen Polarstern, denn jeder Mitarbeiter, dem Verantwortung übergeben wird, braucht mehr persönliche Führung und Zielorientierung als bisher. Die gezeigten Service-Knoten sind die fossilen Überreste der früheren Organisationseinheiten bzw. Abteilungen. Die Unternehmen werden grenzenlos, sowohl in ihrer internen wie externen Zusammenarbeit. Es entsteht ein sensibles Netz der Wertschöpfung für Kunden und die Unternehmen. Doch die Virtualisierung geht noch einen Schritt weiter. Mit zunehmender Durchdringung allen Geschehens durch Netzwerke und dem Fallen von Grenzen ist der Standort, an dem eine Leistung erbracht wird, weitgehend unerheblich geworden. Einer Verlagerung der Fertigung von Produkten in Niedriglohnländer gibt es schon lange. Jetzt ist das Off-Shoring intellektueller Leistungen in vollem Gange. Diese Verlagerung hat heute die gesamte Software-Entwicklung erfasst. 152

13.2 Ausblick

Bild 13.3: Virtualisierung von Services eines Unternehmens in einem Grid. Automatische Services sind künftig nicht mehr an bestimmte Computing-Ressourcen gebunden. Sie werden dort ausgeführt, wo ihre Ausführung am wenigsten kostet und sie mit der gleichen Qualität erbracht werden. Genauso werden intellektuelle Services nach Kosten und Anforderungen verteilt. Durch die Transpondertechnologie wird der Fluss von Gütern besser überwachbar und die Route steuerbar, mit Rückwirkungen auf alle Partner in einer Supply Chain.

Nun konkurrieren nicht nur mehr die Löhne, sondern auch noch die Mieten für IT-Ressourcen. Automatische Services werden dorthin ausgelagert und ausgeführt, wo Rechner nicht ausgelastet sind oder wo die Steuern gering sind. Die für das Grid Computing erforderlichen Hochgeschwindigkeitsnetze sind, zumindest im Bereich der Wissenschaft und des Militärs, bereits installiert. Es entstehen die Application-Service-Provider-Netze der nächsten Generation, bei denen die Leistungen nicht mehr an einem bestimmten Standort erbracht werden, sondern an Stellen freier und kostengünstiger Rechenkapazität (Bild 13.3). Mit dem Grid Computing schwinden somit die Grenzen von Unternehmen selbst bei der genutzten IT. Was übrig bleibt, ist die Geschäftsidee, welche jeden Tag überprüft und neu umgesetzt werden muss, so wie es eben der Markt gerade erfordert. Was außerdem übrig bleibt, ist das Vertrauen in die Marke, unter der ein Unternehmen sein Geschäft betreibt – der Name der Firma, der für Leistung und Qualität steht. Alles andere wird virtualisiert in einem Grid von den automatischen IT-Services bis hin zu den intellektuell erbrachten Dienstleistungen. Aber auch die Routen, welche Güter nehmen, sind künftig variabel. Durch den Einsatz der Technologie von Transpondern (RF-ID) sind sie auf ihren Weg permanent lokalisierbar und nach aktuellen Bedürfnissen steuerbar. Vertrauen ist die Seele eines jeden Unternehmens. Dieses Vertrauen basiert auf den ungeschrieben Werten und Normen einer gemeinsamen Unternehmenskultur. Fukuyama (1999) nennt es das Sozialkapital. Dieses Vertrauen wird in jedem Gespräch von Mitarbeiter zu Mitarbeiter immer neu erworben. In jedem Gespräch wird die gemeinsame Wirklichkeit

153

13 Rückblick und Ausblick

neu konstruiert, die jedem Halt gibt. Deshalb ist gerade bei der zunehmenden Globalisierung der Aktivitäten der Hautkontakt unverzichtbar. Darum bergen die Netzwerke eine Chance und eine Gefahr zugleich. Sie erledigen Routine viel effizienter, aber sie schmälern immer öfter die Chance für eine wahre, ehrenhafte Auseinandersetzung über gemeinsame Ziele und Wünsche. Ausgedehntes Out- und Insourcing durch föderative Technologien Durch den empfundenen Kostendruck neigen viele Unternehmen dazu, vollständige Prozesse auszulagern (BPO, Business Process Outsourcing). Dadurch soll das Budget insbesondere von Back-Office-Aktivitäten von kompetenten und kostengünstigeren Providern übernommen werden. In einer zweiten Welle des Out- und In-sourcings fokussiert sich das Angebots-Portfolio auf die Übernahme der kompletten Shared-Services eines Konzerns. Solche gemeinsamen Dienstleistungen werden nicht mehr intern erbracht und kontrolliert, sondern durch Unternehmen, mit denen Verträge geschlossen werden. Beispiele dazu sind Personalwesen, Buchhaltung oder Logistik. Die IT-Infrastruktur für ein disaggregiertes, internationales Unternehmen, das nahtlose grenzübergreifende Prozesse benötigt, ist komplex. Die Auflösung von Unternehmen in Konglomerate effizienter, autonomer Service Provider hat ihren Preis. Damit der Unternehmenskern die Leistungen auch wirklich nutzen kann, müssen alle Teile des entstehenden Netzwerks föderatives Verhalten zeigen. Dies gilt sowohl in strategischer Hinsicht, wie auch im Hinblick auf die Technologie durch permanente Abstimmung der Prozesse der Partner. Andererseits bieten die neu hinzukommenden Schnittstellen zu den Partnerunternehmen die Möglichkeit den Leistungsaustausch auf eine rechtsverbindliche Grundlage zu stellen, ein Vorteil, der im innerbetrieblichen Verhältnis zwischen Service-Provider und Consumer nicht immer gegeben ist. Die Verbindlichkeit bei Shared Services (Kagelmann, 2001) muss dort einer quasivertraglichen Regelung unterworfen werden, notfalls mit Sanktionen auch in der innerbetrieblichen Leistungsvergütung. Werden Services ausgelagert und durch andere erbracht, so kommt dem Thema Sicherheit beim Austausch von Leistungen auf elektronischem Wege eine gewichtige Rolle zu. Es wird zum Thema Nummer Eins einer über viele Unternehmen verteilten Service-orientierten Architektur. Erwartungen an die Zukunft des Software-Engineering Betrachtet man die Geschichte der Computertechnologie und hat diese zum großen Teil selbst miterlebt, so fällt im Nachhinein auf, dass jedes neu gefundene Paradigma sofort mit einem Universalitätsanspruch ausgestattet wurde. Rückblickend gesehen, ist von allen Technologien etwas übrig geblieben. Sie werden heute durchwegs als Mittel zum Zweck bei der Lösung entsprechender Probleme genutzt. Die großen Ereignisse in der Geschichte der IT waren zweifellos die Einführung der höheren Programmiersprachen, FORTRAN für den Bereich der Wissenschaft und COBOL für den der Wirtschaft. Ein Schritt mit bedeutenden Auswirkungen auf die Architektur von Lösungen war die Erfindung des relationalen Datenbankmodells. Mit der Einführung von Browsern auf stationären und mobilen Endgeräten wurden die Lösungen zunehmend unabhängig von diesen.

154

13.2 Ausblick

Bild 13.4: Integration heterogener Services durch einen Workflow. Die standardisierte Workflow-Technologie gibt Anlass zu der Vermutung, dass daraus ein Schritt in Richtung einer vorzüglichen Integrationstechnologie getan wird. Genau betrachtet sind es zwei Standards, welche dies bestärken, der zur Orchestrierung von Services (BPEL Abstract Process) und der zur Beschreibung des API einer zu integrierenden Komponente mit WSDL. Mit beiden Standards wird es erstmals möglich, alle möglichen Anwendungen, heute Services genannt, über organisatorische Grenzen hinweg zu kombinieren.

Heute sind wir am Beginn einer weiteren Modularisierung der Anwendungsarchitektur durch Workflows und Service-Schnittstellen. Mit der Technologie der Workflows ergibt sich ein flexibles Instrument für die Kombination lose gekoppelter Komponenten, wie sie den Anforderungen betriebswirtschaftlicher Software entspricht. Die bedeutendste Eigenschaft eines lose gekoppelten Web Service ist eine offen gelegte Choreographie, die dem Nutzer (Consumer) eines Service enthüllt, wie er schrittweise zu reagieren hat, um sein Ziel zu erreichen. Diese Choreographie entspricht der inneren Arbeitweise des Web Service, verdeckt jedoch die genauen Zusammenhänge. Aus der Sicht eines Workflows ist die Choreographie das bedeutendste Mittel der Integration von weiteren Services und deren Workflows. Die integrierten Services können unterschiedlicher Natur und Herkunft sein. Sie können zustandsbehaftet, zustandslos oder sie können bewährte Legacy-Systeme sein. Die integrierte Lösung ist demzufolge in sich heterogen. So gesehen ist ein Workflow eine Brücke zwischen bewährten Technologien und schafft damit eine neue Möglichkeit in der Technologie der Systemintegration (Bild 13.4). Das gezeigte Konzept ist auch eine vernünftige Grundlage für eine Modellierung von Systemen. Es verbindet verschiedene Plattformen und insbesondere Legacy-Systeme. Im unserem letzten Bild 13.5 werfen wir den Speer sehr weit. Es zeigt eine breitere Modularisierung der Architektur von Anwendungen in der Form orchestrierter Services und das künftig alles verbindende Grid-Netzwerk.

155

13 Rückblick und Ausblick

Bild 13.5: Die Zukunft der Lösungsarchitektur. In Zukunft kommt es zu einer andersartigen Segmentierung der Architektur von Lösungen. Diese Lösungen werden in ihren Teilen (Services) Organisationen übergreifen und dabei Services von Vertragspartnern wieder verwenden. Die Datenhaltungen dieser Services werden permanent synchronisiert. Damit wird auf eine direkte Re-Integration von Datenhaltungen verzichtet. Services sind die Nachfolger von Objekten und Workflows. Sie sind deren Korrektiv. Die Kosten für den Ablauf von Services werden über Grids gesenkt. Föderative Unternehmen stellen Services bereit und sind die Knoten in dem künftigen Grid.

Ähnlich der Einführung der relationalen Datenbanken in den 90igern können die beschriebenen Entwicklungen zu einer Deregulierung des Marktes für Standardlösungen führen. Kern der Technologie werden die Orchestrierung von Services sein und Hintergrundprozesse für die Synchronisation von deren Datenhaltungen. Technologien dazu sind bekannt. Die zitierten Produkte leisten einen erheblichen Beitrag zur Gestaltung Service-orientierter Lösungen. Die Standardisierung der Workflow- und Kommunikationstechnologien wird einen völlig veränderten Lösungsmarkt schaffen. Unternehmensnetze und Prozesse sind keine Utopie. Nein, das Neue, Andere lebt schon mitten unter uns. So ist es, wie alle historische Erfahrung zeigt, immer gewesen. Das Morgen ist schon im Heute vorhanden. Denn »die Zukunft hat schon begonnen« (Jungk, 1952).

156

14 Abkürzungen

ABAP ACID ADO API ASP ASP B2B BAM BAPI BI BPEL BPEL4WS BPO BWH CICS CLOB CLR COBOL COM+ CORBA CPL CRM DB DBMS DCOM DII DTD DVS DWH EAI EDI EJB ERM ERP FDL GPRS GSH GSM GSP

Advanced Business Application Programming (SAP) Atomic Concurrent Isolation Duration ActiveX Data Objects (Microsoft) Application Program Interface Application Service Provisioning (Microsoft) Active Server Page Business to Business Business Activity Monitoring Business Application Programming Interface (SAP) Business Intelligence Business Proces Execution Langauge Business Proces Execution Language for Web Services Business Process Outsourcing Business Warehouse Common Information Control System Character Large Object Common Language Runtime Common Business Oriented Language Common Object Model (Microsoft) Common Object Request Broker Architectur (OMG) Call Processing Language Customer Relationship Management Datenbank Database Management System Distributed Common Object Model Dynamic Invocation Interface Document Type Definition Dokumentenverwaltungs-System Data Warehouse Enterprise Application Integration Electronic Data Exchange Enterprise Java Bean Entity Relationship Model Enterprise Resource Planning Flow Definition Language General Packet Radio Service Grid Service Handle Global System for Mobil Communications Grid Service Provisioning

157

14 Abkürzungen

GSR GUI HTML HTTP I&K I/O IDL IDOC IIOP IMS IP IT JBI JCA JDBC JIT JMS JSP JSR KPI LAN LCS LDAP MDB MIP MISL MPEG MQT MSMQ MSN MVC NDA ODBC OGSA OGSI OLAP OLE OO OQL ORB OS PBX PC PDA PDF PHP PKI 158

Grid Service Reference Graphical User Interface Hypertext Markup Language Hypertext Transfer Protocol Information & Kommunikation Input/Output Interface Description Language Interface Document Internet Inter-ORB Protocol Information Management System Internet Protocol Informationstechnologie, Information Technology Java Business Integration Java Connector Architecture Java Database Connection Just-in-Time Java Message Service Java Server Page Java Specification Request Key Performance Indicator Local Area Network Life Communication Server Lightweight Directory Access Protocol Monitor Database Multichannel Integration Plattform Microsoft Intermediate Language Moving Pictures Experts Group Materialized Query Table Microsoft Message Queuing Microsoft Network Model View Controller Non-Disclosure Agreement Open Database Connection Open Grid Service Architecture Open Grid Service Interface Online Analytical Processing Object Linking and Embedding Objekt-orientiert Object Query Language Object Request Broker (OMG) Operating System Public Exchange Personal Computer Personal Digital Assistent Portable Document Format Perl Hypertext Processor Public Key Infrastructure

14 Abkürzungen

PLM PPM PPS PSTN RMI RMS RPC SAML SCHUFA SIMPLE SIP SLA SOA SOAP SPI SQL SSL SSO TA TCP TPM UAN UDDI UML UMTS URI URL VoIP VPN W3C WAP WBI WebDAV WML WPKI WS WSDL WSFL WSIF WSLA XI XPath XQL XrML XSLT XSD

Product Lifecycle Management Process Performance Manager (IDS Scheer) Produkt-Planungs-System Public Switched Telephone Network Remote Method Invocation Relationship Management System Remote Procedure Call Security Assertion Markup Language Schutzgemeinschaft für Kreditauskunft Simple Mail Transfer Protocol Session Initiation Protocol Service-Level Agreement Service-orientierte Architektur Simple Object Access Protocol Service Provider Interface Structured Query Language Secure Socket Layer Single Sign-on Transaction Transmission Control Protocol Trading Partner Management Universal Application Network (Siebel) Universal Description, Discovery and Integration Universal Modelling Language Universal Mobile Telecommunication System Universal Resource Identifier Universal Resource Location Voice over IP Virtual Private Network World Wide Web Consortium Wireless Access Protocol WebSphere Business Integration Web-based Distributed Authoring and Versioning Wireless Markup Language Wireless Public Key Infrastructure Web Service Web Service Description Language Web Service Flow Language (IBM) Web Service Invocation Interface (IBM/Apache) Web Service-Level Agreement eXchange Infrastructure (SAP) XML Path Language XML Query Language eXtensible rights Markup Language Extensible Style(sheet) Language Transformations XML Schema Definition

159

15 Glossar

Abstract Process

Externe, nicht ausführbare Spezifikation (Protokoll) eines Prozesses als Hilfe bei der Programmierung eines Client.

Abstraktion

Verbergen von Detailentscheidungen innerhalb einer Schicht oder Komponente, um die Nutzer von Änderungen der Details möglichst unabhängig zu machen (Wartbarkeit, Reuse).

ActiveX

Microsoft-Technologie für Komponenten (z. B. GUI-Komponenten), die auch in Webseiten für Windows Browser eingebettet sein können.

Adapter

Zusatz zu einer vorhandenen Lösung für einen geregelten Datenaustausch, um Protokolle und Datenformate anzupassen (Integrationsprotokoll). Es gibt technische Adapter zur Verbindung mit Datenbanken, Kommunikations-Middleware, TP-Monitore und ObjectRequest-Brokern, außerdem Anwendungsadapter für Standard-Lösungen (SAP) und vertikale Industrieprotokolle (z. B. RosettaNet, SWIFT).

Agent

Autonome (SW-)Einheit, die automatisch Aufträge ausführt. Menschliche Agenten: Mitarbeiter eines Call Centers oder Bearbeiter von Meldungen eines Workflows.

Agent Technology

Im Bereich des Roboting übliche Architektur autonomer Systemprozesse, welche zusammen ein gemeinsames Ziel verfolgen. Große Parallelen dazu gibt es bei den diskutierten lose gekoppelten Systemen.

Aggregat

Komposition von Komponenten.

Aktion

Ausführung einer Aktivität.

Aktivität

Funktion innerhalb eines Workflow.

Anwenderprogramm

SW-Teile einer Lösung, die eine ablauffähige Einheit bilden.

Anwendung

Teile einer Lösung für ein Problem.

Anwendungsarchitektur

Abstraktion des Verhaltens von Laufzeit-Elementen in bestimmten Phasen des Ablaufs. Diese Abstraktionen können wiederum eigene Architekturen enthalten. Die Elemente einer Architektur sind Komponenten, Konnektoren und Daten, welche zueinander bestimmten Beschränkungen unterliegen. Eine Architektur ist Bestandteil der

160

15 Glossar

Anwendung selbst und nicht die Beschreibung der Anwendung. Bei einer netzbasierten, verteilten Anwendung, wie dies Service-orientierte Anwendungen und Workflow-Anwendungen meist sind, ist die Art der Daten, deren Ort im Netz und die Bewegung dieser Daten über das Netzwerk das einzig bestimmende Element beim Design des Verhaltens von derartigen Anwendungen. API

Application Programming Interface; Software-Schnittstelle zum Aufrufen von Funktionen oder Services.

Application Server

Laufzeitumgebung für Komponenten einer J2EE-Web-Anwendung.

Architektur

Abstrakter Aufbau von Anwendungen (siehe Anwendungsarchitektur) oder von ganzen Systemen. Architekturen werden durch die eingesetzten Middleware-Produkte und Frameworks weitgehend geprägt.

asynchron

Zeitversetzte Reaktion von Systemen. Der Sender einer Nachricht fährt mit der Verarbeitung fort und wartet nicht auf das Eintreffen einer Antwort.

asynchrone Kopplung

Kopplung über Warteschlangen.

Atomic Transaction

Klassische Steuerung von (verteilten) Transaktionen mit persistenter Speicherung von Änderungen beim Erfolg und Roll-back beim Scheitern einer einzelnen Aktion. (ACID)

Authentifizierung

Feststellen der Identität eines Nutzers.

autonom vernetzte Anwendungen

Anwendungen, welche asynchron über Warteschlangen oder oneway kommunizieren. Dieses Prinzip ist für alle betriebswirtschaftlichen Anwendungen günstig, insbesondere wenn menschliche Entscheidungen bei Prozessen benötigt werden oder das Blockieren fremder Datenbanken vermieden werden soll.

betriebswirtschaftlich

Mit Waren und Handel und Geld verbunden.

betriebswirtschaftliche Anwendung

Lösung eines betriebswirtschaftlichen Problems mit Mitteln der IT.

betriebswirtschaftliche Funktion

Teil in einer betriebswirtschaftlichen Anwendung mit einer bestimmten Aufgabe.

betriebswirtschaftliche Komponente

Spezielle wiederverwendbare SW-Einheit, die im Container eines Application Server abläuft.

betriebswirtschaftlicher Prozess

Reihenfolge aller Aktivitäten, welche ein bestimmtes Ziel verfolgen.

Binding

Kopplung von SW-Teilen, um ein Zusammenwirken zu ermöglichen.

161

15 Glossar

Browser

Dünner (ohne anwendungsspezifische Funktionalität) Client zur Interaktion mit Websites über HTTP und HTML.

Business Activity Monitoring

Gemäß Gartner ein Konzept für den Zugriff auf kritische Geschäftskennwerte in Realzeit.

Business Modeling

Dokumentation, Analyse und Design der Struktur von Geschäftsprozessen, ihrer Verbindungen mit den Ressourcen, die benötigt werden um sie zu implementieren, und der Umgebung in der sie verwendet werden.

Business Process

Definition von Aktivitäten und der Reihenfolge dieser Aktivitäten, um eine betriebswirtschaftliche Funktion auszuführen (dt. Geschäftsprozess, betriebswirtschaftlicher Prozess).

Business Process Management

Bezeichnung für alle derzeitigen Entwicklungen (Methode, Tool, Environment, Framework) im Umfeld ausführbarer Prozesse.

Caching

Temporäres Zwischenspeichern von Daten aus anderen Quellen aus Gründen der Performance.

Choreographie

Sie legt fest, wie Web Services aufeinander wirken müssen, um übergreifende Geschäftsprozesse zu implementieren. Eine Choreographie hilft auch, die Reihenfolge von Messages, logischen Abhängigkeiten und Exception-Handling zu verfolgen.

Client

Aufrufer eines Service, auch Consumer genannt.

Composite Service

Service, der mehrere andere Services in einer bestimmten Reihenfolge aufruft. Diese Aufruffolge kann als Workflow verstanden werden. Er wird allerdings nicht durch ein Workflow-Management-System unterstützt.

Computing on Demand

Temporäre Nutzung von Computerleistung in einem Netzwerk bzw. von Grid Services mit standardisierten Schnittstellen (siehe OSGA).

Consumer

Client.

Contact Server

Sammelbegriff für alle Server, die eine multimediale Interaktion mit einem menschlichen Agenten unterstützen.

Container

Ablaufumgebung von Komponenten auf einem Application Server.

Context

Zustandsinformationen von langlaufenden Transaktionen, welche in einem Container zwischengespeichert werden. Es kann auch ein gemeinsamer Context zwischen mehreren Web Services vereinbart werden.

Coordination Type

Die Summe der Protokolle, welche benötigt werden, um verteilte Services zu einem gemeinsamen Ergebnis zu führen.

CORBA

Common Object Request Broker Architecture; Protokoll- und Interface-Standard für verteilte, objektorientierte Verarbeitung.

162

15 Glossar

CRM-Lösung

Customer-Relationship-Management-Lösung; Lösung zur besseren Bedienung der Kunden eines Unternehmens.

DataSets

Microsoft-Begriff für temporäre Tabellen in einem ADO-Client.

Datei

Persistente Einheit auf einem Speicher.

Datenmodell

Struktur einer Datenbank, die in einem Schema hinterlegt ist.

De-Marshalling

Umwandlung eines Protokoll-Formats in Strukturen zur weiteren Verarbeitung einer Nachricht, z. B. von SOAP in Aufrufe in das API einer Programmiersprache.

Design

Die Methode, welche beschreibt, wie ein Modell der Geschäftsanalyse in einer bestimmten technischen Umgebung implementiert werden kann. Das Design-Modell enthält genügend Details, um es in einer bestimmten Programmiersprache, insbesondere den damit verbundenen Service-APIs und ggf. mittels bestimmter Frameworks implementieren zu können.

Digitale Signatur

Digitale Unterschrift unter ein Dokument, welche die zweifelsfreie Herkunft und Unverfälschtheit des Dokuments garantiert. Wird erstellt durch Verschlüsselung der Prüfsumme mit einem privaten Schlüssel und an einen Empfänger zusammen mit dem Dokument übertragen.

Disaggregiertes Unternehmen

Auf Erkenntnissen des Nobelpreisträgers Roland Coarse zu Transaktionskosten zurückzuführende schonungslose Konzentration eines Unternehmens auf seine Kernkompetenzen.

DiscoveryMechanismus

Technologie für die Suche in einem Directory.

End-to-End Business Process

Verkettung aller betriebswirtschaftlichen Einheiten zur Erreichung eines Ziels.

End-to-End Process Engineering

Gemeinsame Gestaltung unternehmensübergreifender Prozesse inklusive vertraglicher Vereinbarungen.

Entscheidungslogik

Verzweigung in betriebswirtschaftlichen Lösungen nach Prüfung von bestimmten Regeln.

ERM

Entity Relationship Model; Analyse und Design der Struktur betriebswirtschaftlicher Daten.

E-Services

Summe alle Leistungen, welche eine Unternehmen über Netzwerke anbietet.

Façade

API eines Services zur Nutzung dessen über einen bestimmten Transportmechanismus (Begriff von Microsoft).

Factory

Eine zustandslose Komponente in einem Application- oder GridServer, der eine temporäre (möglicherweise zustandsbehaftete) Instanz erzeugen kann und ein Handle (Adresse) zurückliefert.

163

15 Glossar

Federated Search

Zugriff auf Datenbanken mit unterschiedlichen Datentypen und mit unterschiedlicher Strukturierung über eine gemeinsame SearchEngine (Query-Language: XQuery). Diese Zugriffe können Prozesse (embedded) nutzen.

Firewall

Server, der den Zugang zu einem Unternehmen über das Internet regelt

Flow Programming

Modularisierung von Systemen als Komponenten mit expliziter Steuerung dieser Komponenten über leicht adaptierbare Prozessablauf-Programme. Dabei entsteht eine Flow-based Application.

Föderativ

Autonomes, anpassungsfähiges Verhalten als Eigenschaft von Systemeinheiten.

Föderatives Datenbanksystem

Selbständige heterogene Datenressourcen mit einer übergreifenden, aufeinander abgestimmten Zugriffsschale. Beispiele: DB2 II, ADO.NET, TREX.

Framework

Wiederverwendbare Grundarchitektur für eine spezielle Art von Softwarelösungen (z. B. Struts für eine MVC-Architektur). Die durch Tools genutzten Bibliotheken der Frameworks werden ein Bestandteil der Softwarelösung.

Funktion

SW-Teil mit einer bestimmten Aufgabe und einem API für dessen Aktivierung; Aktivität innerhalb eines Workflows.

Geschäftsablauf

Alle Prozesse zum Erreichen der Unternehmensziele.

Geschäftspartner

Unternehmen, mit dem Verträge über Leistungen im Geschäftsinteresse bestehen.

Grid

Verbund von verteilten, heterogenen Computern, welcher in einer Anwendung als ein einziges großes Computersystem erscheint. Es ist eine Schicht vernetzter Services, welche einem Benutzer ein Single Sign-on beim Zugriff auf verteilte Computer, Daten und Anwendungs-Ressourcen erlaubt. Ein Grid dient virtuellen Organisationen (VO) zur gemeinsamen Verwendung und Konsolidierung ihrer Computer Ressourcen.

Grid Computing

»Lieferung« von Computerleistung im Bedarfsfall wie bei der Elektrizität, bei Strom oder Gas.

Grid Server

Computer, der in einem Grid Services zur Verfügung stellt.

Grid Service

Form eines Web Service mit speziellen Interfaces zur Bereitstellung von Funktionen in einem Grid. Grid Service Interfaces sind wie die von Web Services mit WSDL definiert.

Handle

Referenzadresse z. B. eines Grid Service.

HTML

HyperText Markup Language; Format für Nachrichten, die ein Browser versteht.

164

15 Glossar

Identity Flow

Weiterreichen von Informationen zur Prüfung von Berechtigungen.

IIOP

Internet Inter-ORB Protocol; synchrones Protokoll von CORBA und einem ORB.

Image

Digitales Bild.

Implementierung

Realisierung einer Lösung durch Programmierung.

Indexing

Auszeichnen von Dokumenten mit Stichworten zur Beschleunigung der Suche.

Instanz

Ablaufeinheit eines Programms oder einer Komponente, welche die temporären Daten und den Dialogzustand enthält.

Integration

Anpassung vorhandener Lösungen an die Bedürfnisse einer neuen Lösung über unterschiedliche Kommunikationsprinzipien.

IT-Lösung

Anwendung.

Kapselung

Abgrenzen einer Softwareeinheit mit deren Daten. Es entsteht ein Objekt, dessen Daten über ein API geändert werden können.

Klasse

Muster in der OO-Technologie als Basis für die Instanzierung.

Kollaborieren

Zu einem bestimmten Zweck zusammenarbeiten.

Kollektion

Aggregat.

Kompensation

Abwicklung nicht-blockierender betriebswirtschaftlicher Aktivitäten mit (UNDO-)Funktionen im Fall des Nicht-Erfolges.

Komponente

Wiederverwendbare Funktion einer Anwendung, die im Container eines Application Servers abläuft. Eine Komponente ist eine abstrakte Einheit von Softwareinstruktionen und einem internen Zustand, welche eine Datentransformation durch ihr Interface durchführt. Die Definition einer Komponente hängt weniger von ihrer internen Implementierung ab als von ihrem Verhalten gegenüber anderen Komponenten. Services sind in diesem Sinne Komponenten, deren Interfaces mit WSDL beschrieben sind.

Konnektor

Wrapper zur Kopplung von SW-Teilen bei der Integration unter einer einheitlichen Systematik. Ein Konnektor ist ein abstrakter Mechanismus, welcher die Kommunikation, Koordination und Kooperation unter Komponenten regelt.

Konsistenz

Folgerichtiges Verhalten von SW-Teilen.

Konsolidierung

Bereinigung von Systemen zur Einsparung von Kosten.

Kontext

Summe aller Daten, die zur Weiterführung einer Transaktion benötigt werden.

Koordination

Steuerung von langen Transaktionen.

165

15 Glossar

Late Binding

Verbindung von Clients und »virtuellen« Services unabhängig von Protokollen und Formaten zum Zeitpunkt eines Aufrufes über einen sogenannten Service Bus.

Layer

Eine Ebene gleichrangiger, abstrakter Interfaces in einer Architektur.

LegacyAnwendungen

Funktionstüchtige, notwendige aber meist etwas undurchsichtige, oft alte, Großrechner-basierte Anwendungen eines Unternehmens, die lose mit neuen Anwendungen gekoppelt werden.

Long Transaction

Remote ausgeführte Verarbeitung über eine längere Zeitdauer, auf deren Durchführung ein Verursacher nicht wartet. Erfolglose lange Transaktionen werden kompensiert (UNDO-Prozess).

Lösung

Anwendung.

Marshalling

Transformation von Datenstrukturen in ein serielles Übertragungsformat.

Message

Format und Inhalt einer Nachricht in einem Netz, die von einem Empfänger verstanden wird.

Message Broker

Verteiler von Messages und Events an Subscriber.

Message-Bus

Fiktives Bild angelehnt an einen Hardware-Bus zur Erklärung der Wirkungsweise von Dynamic Binding.

Message Queue System

Middleware zum Management asynchroner Kommunikation.

Messaging

Nachrichtenübertragung.

Middleware

Softwareschicht zwischen Betriebssystem und Anwendung.

Modell

Abstrakte Beschreibung einer Organisation und ihres Bedarfs an IT, welche mittels Diagrammen dargestellt ist.

Modellierung

Darstellung eines Unternehmens durch Modelle mit dem Ziel, die Kluft zwischen den unterschiedlichen Vorstellungen der Geschäftsleute und der IT-Leute zu überbrücken.

Multi-Tier

Aufteilung von Servertypen in Gruppen (Zonen) mit dedizierten Aufgaben.

Nachricht

Übertragener Inhalt und deren Darstellungsformat bei der Kommunikation zwischen Systemen.

Objekt

Geschlossene Einheit von SW-Funktionen und Daten.

Objektmenge

Instanzierte Objekte des gleichen Typs.

Objekt-orientierte Programmierung

Methode des Designs von Software nach dem Prinzip der Kapselung von Daten.

166

15 Glossar

Objektorientierung

Paradigma der Entwicklung von Software auf Basis von Objekten und Klassen, insbesondere zur Simulation und für das GUI.

Objekt-Zustand

Ein Objekt ist eine Kapselung von Funktionen und Daten, welche über ein Interface angesprochen werden. Der Zustand eines Objekts repräsentiert die aktuell in ihm gekapselten Dateninhalte. Einzelne Objekte reagieren bei einem erneuten Aufruf auf der Basis mitgelieferter Parameter und des aktuellen Zustandes ihrer Daten konsistent.

ODBC

Open DataBase Connectivity; Generelle SQL-Schnittstelle von Microsoft.

OLE

Object Linking and Embedding; erstes Komponentenkonzept von Microsoft.

Operation

Ausführung einer Funktion.

Orchestrierung

Management der Abfolge von Services auf Basis einer externen Prozessdefinition.

Peer-to-Peer

Direkte Kommunikation zwischen zwei Partnern.

Performance

Durchsatz oder Reaktionsgeschwindigkeit einer Anwendung.

Persistence Service

Service zur dauerhaften Speicherung von Daten z. B. in einer Datenbank.

Persistenz

Dauerhafte Speicherung von Daten.

Petri-Netze

Spezielle Systemtheorie für parallele Prozesse.

π-Calculus

Neue Systemtheorie von Millner (1999) für parallele, zustandbehaftete Prozesse mit Behandlung von Nicht-Verfügbarkeit (Mobility).

Plattform

Systeminfrastruktur; Hardware und Systemsoftware für den Ablauf von Anwendungen.

PlattformUnabhängigkeit

In einer Service-orientierten Architektur ist die Plattform für einen Client (Consumer) unabhängig von der, auf der ein von ihm genutzter Service abläuft.

Port

Interface zu einem automatischen oder menschlichen Service.

Portal

Grafisches Interface zur personalisierten, gleichzeitigen Präsentation von Inhalten aus unterschiedlichen Anwendungen in einem Browser.

Portallösung

Alle Integrationsprogramme, Portlets, Konfigurationsdaten und Profile, welche die Personalisierung und individuelle Darstellung eines Portals zur Laufzeit bewirken.

Portal-Server

Ablaufumgebung für eine Portallösung, welche ein Portal mit Inhalten versorgt.

Portlet

Anwendungskomponente einer Portallösung, welche einem einzelnen Bereich in einem Portal zugeordnet ist.

167

15 Glossar

Portlet, generic

Proxy Code auf einem Portal-Server, welcher über ein Interface konform dem WSRP (Web Services for Remote Portals) Standard ähnlich der Technologie von CORBA-IDL zugreift. Die Portlet-Provider-Lösung im Netzwerk berücksichtigt in ihrem Mark-up die aktuellen Bedingungen im Portal, z. B. die Größe der Ausgabefläche.

Präsentationsfunktion

z. B. Servlet.

Process Modeling

Spezifikation von Abläufen unterschiedlicher Strukturelemente mit einem von Maschinen (Process Engines) ausführbarem Ergebnis.

Process Monitoring

Beobachtung von Prozessen beim Ablauf zum Erkennen von Engpässen oder der Ursachen.

Process Prototyping

Test von Unternehmensprozessen zur Aufdeckung von Fehlern, Blockaden und des Lastverhaltens. Derzeit meist auf der Basis von Petri-Netzen oder über Prototypen.

Profil

Beschreibung aller Annahmen und Vereinbarungen bei einer Kommunikation; bei Portalen die Bedingungen für die Personalisierung der Inhalte.

Programm

Software in einer bestimmten Programmiersprache.

Programmiermodell

Konzept der Softwareentwicklung.

Protokoll

Beschreibung der notwendigen Schritte bei der Kommunikation von Komponenten.

Protokollierung

Aufzeichnung von Abläufen.

Process Owner

Organisationsrolle für eine Person, welche die Entwicklung und Verbesserung eines Prozesses verantwortet.

Prozess

Geschäftsvorgänge.

Prozessbeschreibung

Beschreibung von Abläufen in einer Standard-Notation.

Prozessdefinition

Prozessbeschreibung.

Prozessmodellierung

Darstellung von Abläufen mit grafischen Mitteln.

Prozessschritt

Übergang von einem Zustand vor einer Aktivität zu einem nach dieser Aktivität.

Prozess-Schritte

Summe von Übergängen.

Prozessstruktur

Prozessschritt.

RDB

Relationale Datenbank.

168

15 Glossar

Replikation

Automatisches Erstellen von Datenkopien als Vorkehrung gegen Systemausfälle oder zur Verteilung im Netz.

Request

Aufruf eines Service.

Robustheit

Stabilität von Software bei Ausnahmefällen.

Rolle

Beschreibung der Rechte in einem System mit der Zuordnung von bestimmten Personen.

Routing

Weiterleiten von Nachrichten an einen oder mehrere Empfänger nach bestimmten Kriterien. Unterschieden wird das zustandslose Routing, bei dem keine Antwort erwartet wird und das Senden einer Nachricht an einen bestimmten Empfänger durch ein WorkflowManagementsystem, welches den Zustand beim Aussenden der Nachricht speichert.

Schema

Explizite Beschreibung der Struktur einer Datenbank.

Schichtung; Layer

API-Hierarchie in einer Software, die der Abstraktion folgt.

Schnittstelle

Beschreibung des Zugangs zu einer SW-Funktion.

Security Token

Schlüssel zur Identifizierung des Senders einer Nachricht an einen Web Service.

SEED Package

Technologie des Microsoft BizTalk Servers zur Integration von Handelspartnern. Im SEED Package werden die für die Anbindung notwendigen Informationen gebündelt übermittelt. Die Kopplung kann damit unmittelbar getestet werden.

Semantik

Lehre von der Bedeutung von Zeichen, Wörtern und Sätzen. In natürlichen Sprachen das, was die Sätze wirklich aussagen oder in Computersprachen, welche Funktion und Bedeutung ein Sprachkonstrukt hat.

Serialisierung

Transformation von SW-Strukturen in ein serielles, übertragungsfähiges Format (Marshalling).

Server

Middleware auf einem Computer, der auf einen bestimmten Zweck ausgerichtet ist.

Service

Ein Service ist eine über ein Netzwerk aktivierbare Anwendung mit einem mittels WSDL beschriebenen Interface, welche ihre eigenen Daten verwaltet. Services sind Komponenten. Das Verhalten eines Service kann durch einen Workflow gesteuert werden und dieser kann als externes Protokoll zu dessen Orchestrierung publiziert sein. Die Verantwortung für einen Service (Anwendung) liegt normalerweise außerhalb der Organisation, die diesen nutzt.

Service Bus

Automatische Suche eines Web Service für einen User nach funktionellen Anforderungen und aktuellen Bedingungen.

169

15 Glossar

Services Aggregation

Allgemeines Modell zur Komposition von Web Services. Sie spezifiziert sowohl den Zugriff auf Services, als auch die von einen Aggregat benötigten Services. Ein Aggregat ist durch ein damit verbundenes Geschäftsmodell stark strukturiert und in seinem Verhalten bestimmten Einschränkungen, einer Choreographie, unterworfen.

Service-Semantik

Betriebswirtschaftliche Bedeutung eines Service und damit auch die Summe aller möglichen Verhaltensweisen eines Service in Verbindung mit den von ihm verwalteten Daten und den von ihm genutzten externen Ressourcen. Genau genommen betrifft diese Semantik auch die von einem Service im realen Geschäft ausgelösten Aktivitäten, welche der Service widerspiegelt (z. B. eine Auftrags- und Lieferservice).

Servlet Engine

Ablaufumgebung für Servlets, enthält Interpreter für in Servlets verwendete Skriptsprachen.

Session

Eine langanhaltende Verbindung zwischen Client und Server zur Abwicklung eines Geschäftsvorfalls.

Shareable Component

Prozess auf einem Server, der mit seinen Daten, wie die Datenbank, von allen Client-Prozessen gemeinsam genutzt wird und der die Daten in der Datenbank persistent speichert.

Shared Service

Gemeinsame Dienstleistung für mehrere Bereiche eines großen Unternehmens zur Einsparung von Kosten, oftmals als Vorstufe zum Outsourcing.

Signatur

Digitale Unterschrift unter ein Dokument, welche die zweifelsfreie Herkunft und Unverfälschtheit des Dokuments garantiert.

Skriptsprache

Regel-basierte Sprache zur Aggregation von Komponenten. MikroSkript: ASP, JSP; Makro-Skript: Workflow/BPEL.

SOA: Service-orientierte Architektur

Sie erlaubt es Dienste (E-Services) zu spezifizieren, welche über Meta-Informationen gefunden und über ein Netzwerk genutzt werden. Der Fokus einer SOA liegt auf der Interoperation und nicht auf der Technologie der Implementierung eines Service selbst. Jede Applikation kann in einer SOA ablaufen, wenn ihr Interface und ihre Semantik den Vorgaben konform ist. SOA nutzt WSDL für die Service-APIs und lässt jedes Protokoll zu.

SOAP

Simple Object Access Protocol; XML-basiertes Übertragungsformat zum Aufruf von Web Services.

Speicherstruktur

Darstellung von Daten im Memory.

SSO

Single Sign-on. Mechanismus der Identifikation eines Benutzers bei nachgelagerten Anwendungen, etwa bei allen von einem Portal verwendeten Backend-Systemen oder Web Services.

Staff Resolution

Zuordnung von Bearbeitern zu Aufgaben (Aktivitäten) durch ein Workflow-Management-System.

170

15 Glossar

Stateful Session Component

Prozess eines Clients auf einem Server, der aktuelle Daten speichert und beim nächsten Dialogschritt erneut bereitstellt.

Steuerung

Kontrolle des Ablaufs.

Stored Procedure

Programm auf einem Datenbank-Server.

Struts

Framework zur Realisierung von Dialogprogrammen in Java gemäß dem Model View Controller Konzept.

Stub

Kleine Programmroutine, als Stellvertreter auf einem Client für den Zugriff auf ein Programm auf einem Server.

Supply Chain

Zusammenwirken von Partnern in der Produktion.

Swimlane

Bereich in einem Prozessdiagramm, welcher einem menschlichen Leistungsersteller, einer dazu vergebenen Rolle, einer Organisation oder einem physikalischen Ort der Leistungserbringung zugeordnet ist. Aus der Sicht von BPEL entspricht dies den Ports.

Synchronisation

Abgleich von Datendubletten zur Wiederherstellung von deren Gültigkeit.

Syndication

Begriff aus dem Zeitungswesen bei der Verteilung von Inhalten.

System

Dynamisches Wirkungsgefüge.

Technologie

Summe aller Mittel zur Entwicklung von Lösungen.

Transaktion

Vorgang, welcher ohne Einfluss durch andere Nutzer vollständig abläuft und bei Erfolg eine Datenbank in einem neuen Zustand überführt, oder bei Nicht-Erfolg keine Änderung bewirkt.

Transaktionskosten

Kosten, die den Teilnehmern eines Marktes durch die Inanspruchnahme des Marktes (Information, Vereinbarung/Verhandlung, Abwicklung) entstehen. Durch den Einsatz geeigneter Informationsund Kommunikationstechnologien über alle drei Phasen der Markttransaktion hinweg lassen sich die Transaktionskosten in transaktionsorientierten Unternehmensnetzwerken im Vergleich zu klassischen Märkten erheblich verringern. Dadurch verschiebt sich das Verhältnis der Kosten von »Make« (eigene Entwicklung, Herstellung, Steuerung, Kontrolle, etc.) zu den Kosten von »Buy« (Kauf einer benötigten Leistung) und führt damit zum Trend einer verringerten Fertigungs- und Leistungstiefe von Unternehmen (siehe Disaggregiertes Unternehmen).

Transaktionssicherheit

Eigenschaft von Systemen bei der Verarbeitung geschäftlicher Daten durch Transaktionen. Ein konsistenter Zustand in einen anderen konsistenten Zustand wird überführt. Wird vor allem beim Zugriff auf Datenbanken sichergestellt.

Transformation

Syntaktische und semantische Datenkonversion von Geschäftsdokumenten, Nachrichten, Dateien und Parameter, welche zwischen Anwendungen ausgetauscht werden.

171

15 Glossar

Transponder

Ein Transponder ist ein drahtloses Kommunikations-, Anzeige- oder Kontrollgerät, das eingehende Signale aufnimmt und automatisch darauf antwortet (RF-ID Tag).

Two-Level Paradigm

Implementierung eines Web Services, welcher aus weiteren Services besteht, die über einen Workflow gesteuert werden. Eine Sprache zur Implementierung eines Workflow ist BPEL (auch Two-Level-Programmierung).

Unternehmensprozessmodell

Summe aller Geschäftsprozesse eines Unternehmens. Das Unternehmensprozessmodell ist eine Repräsentation aller Prozesse, Aktivitäten, der dabei notwendigen zentralen Informationen, der Ressourcen, wie der IT-Infrastruktur und der Mitarbeiter, der Ziele und der Beschränkungen eines Unternehmens.

Unternehmenübergreifend, überbetrieblich

Aktionen, die über die rechtlichen und sicherheitsrelevanten Grenzen eines Unternehmens hinausgehen.

Unternehmenübergreifende Prozesse

End-to-End-Prozesse, an denen mehr als ein Unternehmen beteiligt ist.

User Interface

Interaktionsmöglichkeiten für einen menschlichen Benutzer an einem Endgerät.

Vertrauensbereich

Bereich, in dem keine Sicherheitsprüfungen stattfinden.

Virtualisierung

Konzept des temporären Zusammenwirkens von Systemteilen zur Erreichung eines Ziels.

Wartbarkeit

Verständlichkeit und Änderbarkeit von Software.

Web Service

Ein Web Service ist eine Software, welche im Netz über eine Standard-Schnittstelle aufgerufen werden kann, die mit WSDL beschrieben ist.

Web Service Framework

Sortiment von Bibliothekselementen zur Realisierung von Interoperationsprotokollen auf der Basis des SOAP-Formats.

Workflow

Ausführbare Beschreibung eines Geschäftsablaufs zur Steuerung der Reihenfolge von Aktivitäten, welche durch Software Komponenten, Web Services oder Menschen realisiert sind. Automatisierbarer Teil eines Geschäftsprozesses als Ergebnis der Modellierung.

Workflow Engine

Komponente eines Workflow-Management-Systems, welche neben den Funktionen der Steuerung auch die der Überwachung von Prozessen übernimmt.

Workflow-Management-System

Middleware zur Ausführung und Überwachung von Workflows.

Workflow Patterns

Verschiedene erprobte Muster für Prozessabläufe.

172

15 Glossar

Wrapper

Zusätzliche Kapselung einer vorhandenen Lösung um Protokolle und Datenformate anzupassen.

XML-Store

Datenhaltung für XML-Dokumente

Zone; Tier

Funktions-, Performance- und Sicherheits-relevante Gruppierung von Servern.

173

16 Standards

16.1 XML XML (eXtensible Markup Language) XML ist eine vom W3C entwickelte Spezifikation für die Definition von Sprachen zur Formatierung von Dokumenten. XML stellt eine abgespeckte Variante von SGML, einer Dokumentauszeichnungs-Metasprache, dar, das auf Grund seiner Komplexität im World Wide Web nie Fuß fassen konnte. XML erweitert die Möglichkeiten von HTML dahingehend, dass man sich eine eigene Sprache für die Erstellung der Inhalte definieren kann und sich nicht einer vorgegebenen Menge von Sprachelementen unterordnen muss, wie das bei HTML wegen der Browser der Fall ist. Ein weiterer Vorteil ist die Trennung zwischen Struktur und Layout der Dokumente. Die Struktur wird über die mit XML definierte Sprache erstellt und das Layout z.B. mit CSS (Cascading Style Sheets) festgelegt. XML ist die Basis der Web-Service-Kommunikation und damit eine wichtige Integrationstechnologie. XPath (XML Path Language) Notation zur Adressierung von Dokumententeilen in XML-Dokumenten, wird u.a. von XSLT und XPointer verwendet. Die wichtigste Aufgabe von XPath ist der Zugriff auf Teile eines XML-Dokuments. Dazu liefert es die Möglichkeit zur Manipulation von Strings, Zahlen und booleschen Werten. Dies kann in Verbindung mit Workflow Engines zur Manipulation von Messages genutzt werden.

16.2 Nachrichten-orientierte Spezifikationen SOAP (Simple Object Access Protocol) Das beim World Wide Web Consortium (W3C) entwickelte SOAP-Format basiert auf XML und dient normalerweise dazu, Services remote aufzurufen. Dazu werden in einem Client ganz normale Aufrufe in ein XML-Textformat (SOAP) ungewandelt (Marshalling) und Antworten des Service wiederum als Parameter zur Verfügung gestellt. SOAP-Messages werden normalerweise, etwa beim Aufruf von Web Services, über HTTP transportiert, sind jedoch nicht an dieses Protokoll gebunden. WSDL (Web Services Description Language) WSDL dient als XML-Dokument der Beschreibung von (Web) Services als eine Menge von Anschlüssen (Endpoints), die mit Nachrichten arbeiten. Die Services sind abstrakt definiert über Nachrichtenstrukturen und simple Operationen. Sie werden bei Nutzung an ein konkretes Netzwerkprotokoll und Datenformat gebunden. Dabei entsteht ein konkreter Endpunkt. Ein Service kann mehrere konkrete Endpunkte, sog. abstrakte Endpunkte besit-

174

16.3 Prozess/Workflow-Spezifikationen

zen. WSDL ist erweiterbar in der Beschreibung von Endpunkten und in der konkreten Definition von Formaten und Protokollen. Ein WSDL-Dokument für jeden Service ist eine vollständige Beschreibung des API und wird von Entwicklungstools genutzt, um daraus automatisch Proxy-Stubs zu generieren, welche einen Remote-Service als lokales Objekt auf einem Client stellvertretend repräsentieren. Der Programmierer nutzt den Remote-Service wie jedes andere Objekt. WSRP (Web Service for Remote Portal) Erweiterung des Zugriffs auf Web Services, welche die Interaktion in einem Portal berücksichtigt, z.B. die aktuelle Größe des Darstellungsbereichs und die Navigation. Die Provider(Producer)-Seite managed dabei zustandsbehaftete Sessions und wird aus dem PortalServer in einem Stil wie bei CORBA-IDL angesprochen. OGSI (Open Grid Service Infrastructure) OGSI ist eine Spezifikation des API eines Grid Service durch das Global Grid Forum. OGSA (Open Grid Services Architecture) Ist ein Standardisierungsvorschlag zur Sicherung des Quality-of-Service in einem Computer Grid Netzwerk. OGSA ist gleichzeitig der Vorschlag einer Grid-Services-Architektur, der auf der Integration von Konzepten und Technologien von Web Services beruht. GRAM (Grid Resource Allocation & Management) Die von Globus vorgeschlagenen Protokolle dienen der Reservierung, dem Monitoring und der Kontrolle bei Grid-Ressourcen.

16.3 Prozess/Workflow-Spezifikationen XLANG XML-basierte Definitionssprache von Microsoft für Prozesse auf dem BizTalk Server. Basiert auf π-Calculus WSFL (Web Service Flow Language) XML-Sprache zur Beschreibung eines Workflow, dessen Aktivitäten als Web Services vorliegen. WSFL wurde von IBM entwickelt und nutzt die Spezifikationen von SOAP, WSDL, XMLP und UDDI. BPEL4WS (Business Process Execution Language for Web Services, kurz BPEL) BPEL ist eine XML-basierte Flow-Sprache, die definiert, wie Geschäftsprozesse innerhalb oder zwischen Unternehmen wechselwirken. BPEL wird WSFL (IBM) und XLANG (Microsoft) ersetzen. Die Spezifikation wurde von IBM, Microsoft und BEA im August 2002 vorgeschlagen und erlaubt lange Transaktionen mit Koordination und Kompensation. Sie erlaubt die Modellierung von Prozessen und die unmittelbare Ausführung der entsprechenden Workflows. Die externe Sicht von Prozessen (das Protokoll) wird durch eine Unter-

175

16 Standards

menge von BPEL, den BPEL Abstract Process, beschrieben. Ein wesentlicher Fortschritt in BPEL ist die Vereinigung von π-Calculus und Petri-Netz-basierten Sprachen. Dabei muss sich ein Benutzer nicht mehr für eine der Welten entscheiden. Er kann in einem Modell beide Sprach-/Modellierungsmöglichkeiten nutzen. BPML (Business Process Modeling Language) Konkurrent zu BPEL mit weiteren Eigenschaften, wie (geschachtelten) Sub-Prozessen. Promotor ist das BPMI.org Gremium. Eine Zusammenführung mit BPEL bei OASIS wird von Seiten BPEL angeboten. WSCI (Web Services Choreography Interface) WSCI wurde von BEA, SAP, Sun und Intalio veröffentlicht und beschreibt das externe Protokoll von BPML. Es entspricht dem BPEL Abstract Process. WSCI basiert auf WSDL. PIP (RosettaNet) (Partner Interface Processes) Ein RosettaNet Partner Interface Process definiert den öffentlichen Prozess, mit dem Geschäftspartner Informationen austauschen. Der private Prozess, den Unternehmen intern verwenden, um diese Informationen zu verarbeiten, wird hierdurch jedoch nicht definiert. Die RosettaNet-Beschreibungen sind im Gegensatz zu BPEL grundsätzlich nicht ausführbar. RNIF (RosettaNet Implementation Framework) Eine Messaging-Schicht, um die Signale, Events und Dokument-Strukturen zwischen Geschäftspartnern zu kommunizieren. RNIF unterstützt das Packaging, Routing und den Transport von RosettaNet-PIP-Nachrichten und Business Events. PIP (Partner Interface Process) ist ein Protokoll zur externen Aktivierung von Prozessen eines Geschäftspartners. BPSS (ebXML) (Business Process Specification Scheme) Definiert einen Public-Process im Kontext einer Geschäftstransaktion. BPSS ist eine Schicht über den Web Services. BPSS ist eine DTD (Data Type Definition) zur Definition von XML-Dokumenten, die die Möglichkeiten eines Unternehmens zur Geschäftsabwicklung im Bereich E-Business beschreibt. Das BPSS beschreibt also den zugrunde liegenden Geschäftsprozess. Dazu zählen unter anderem existierende Rollen, durchzuführende Transaktionen, der Workflow sowie rechtliche und sicherheitstechnische Aspekte. Das BPSS kann als eine Untermenge der Unified Modeling Methodology (UMM) der UN/CEFACT angesehen werden, da die Architektur von ebXML auf UMM basiert. UMM schreibt vor, wie Geschäftsprozesse im Bereich E-Business mit Hilfe der Unified Modeling Language (UML) zu beschreiben sind. MSS (ebXML) (Message Service Specification) Definiert das Reliable Messaging Protocol. Die Message Service Specification (MSS) ist ein Protokoll zum Austausch von elektronischen Nachrichten zwischen Geschäftspartnern. Es besitzt ebenso wie SOAP eine flexible Envelope-Technologie und interoperiert mit SOAP und RosettaNet.

176

16.4 J2EE-Plattform für Workflows und Web Services

16.4 J2EE-Plattform für Workflows und Web Services Framework für lange Transaktionen (JSR 95) Mit den Standardisierungsvorhaben JSR 95 (Activity Service) soll ein Framework für lange Transaktionen geschaffen werden, um Workflow Engines besser in die J2EE-Plattform oberhalb des Application Server integrieren zu können. Spezielle Transaktionsmodelle mit eigener Semantik können ähnlich der JCA-Technologie integriert werden. Das Framework hilft primär bei der Korrelation von Anfragen und der Koordination von Ressourcen über lange Zeitintervalle. Die Kompensation von Transaktionen wird jedoch von den Workflowprogrammen selbst vorgenommen. Process Definition für Java (JSR 207) Mit dieser Spezifikation werden Metadaten, Interfaces und ein Laufzeitmodell definiert, die es erlauben Workflows mit Java zu implementieren und in einem J2EE Container ablaufen zu lassen. Die Sprachkonstrukte von Java werden dazu um parallele Abläufe und asynchrone Verarbeitung erweitet. Diese Funktionen des Containers können auch für BPEL genutzt werden. Die Spezifikation soll ab der Release J2EE 1.4 gelten. Implementierung von Enterprise Web Services (JSR 109) Diese Spezifikation definiert das Programmiermodell und die Laufzeitarchitektur zur Implementierung von Web Services unter J2EE und wird Teil der J2EE 1.4 Spezifikation sein. Die Spezifikation referenziert die JSR 67 (XML messaging), JSR 93 (XML registries) und insbesonderes JSR 101 (JAX-RPC). Das Ziel ist ähnlich dem von RMI (RMI-IIOP) und JNDI, nicht jedoch als Erweiterung der Spezifikationen für EJBs gedacht. Festlegungen der JSR 109 sind: • Eine Servlet-basierte Bean wird in einen Web-Container und als ein zustandsloses EJB in einen EJB Container zum Ablauf gebracht. Beide nutzen das SEI (Service Endpoint Interface) der JSR 101. • Life Cycle Modell: Erzeugen des Beans, Ablaufbereitschaft und Entfernen durch den Administrator. • Ein Web Service Client auf Basis von J2EE ruft den Web Service wie einen lokalen Aufruf einer Java-Klasse. Es gibt drei Alternativen: – Static Stub: Statische Bindung der Java-Klasse auf dem Client. – Dynamic Proxy: Keine Generierung einer Klasse auf dem Client, aber das SEI muss initialisiert sein. Eine gute Architektur beim Testen von Web Services. – Dynamic Invocation Interface: Das DII ist vergleichbar mit dem Java Reflection Interface. Der Client wird über ein spezielles Objekt gebunden, wenn er Angaben über Funktion, Parameter, den Porttyp, die Portadresse und das benötigte Protokoll macht (siehe das WSIF von IBM und Apache).

177

16 Standards

16.5 Domain-Modelle OAGIS Open Application Group Integration Specification (SW Suppliers) OAGIS versucht zentrale Datenobjekte (Business Object Documents, BODs) und entsprechende Integrationsszenarien zu definieren. BODs können quer zu verschiedenen Industriezweigen (z.B. Telekommunikation und Automotive) und für Aspekte der Supply-ChainAutomatisierung (Bestellung, Katalog-Austausch, etc.) verwendet werden. RosettaNet (IT&Electronics) RosettaNet Standards umfassen die Definition von PIPs (s.o.) für Kernprozesse wie Produktinformation, Bestell- und Lagerwesen. RosettaNet legt dabei nicht fest, wie die konkreten Systeme der einzelnen Partner interoperieren und wie die Integration mit der Business-Lösung eines Handelspartners erfolgt und auch nicht, welche das externe Protokoll (PIP) produzieren. XML/EDI Verwendet XML für EDI. Die XML-Spezifikation erlaubt den Austausch unterschiedlicher Datentypen (z.B. für eine Rechnung, einen Projekt-Status, etc.). Sie enthält außerdem die Implementierung von EDI Directories und On-line Repositories. UBL (Universal Business Language) UBL ist ein Ansatz von OASIS zur Zusammenfassung existierender XML-Business-Document-Libraries zu einer universellen Business-Sprache. CPFR (Collaborative Planning, Forecasting and Replenishment) (UCC-Uniform Code Council, VICS-Voluntary Inter-industry Commerce Standards) CPFR dient Prognose-Modellen und dabei der Optimierung von Transaktionen innerhalb einer Supply-Chain. SCOR Model (Supply Chain Operation Reference) (SCC-Supply Chain Council) SCOR dient der uniformen Beschreibung einer Supply Chain zur Unterstützung einer effektiven Kommunikation unter den Partnern. STP (Straight-through Processing) (Wall Street Systems) (Stockbroking) Mit STP werden Informationen zwischen einem Broker und einer Bank sowie einem Clearing-Haus ausgetauscht.

16.6 Security-Standards Encryption (XML Encryption) Definiert die Technologie für die Verschlüsselung von Daten mit der Repräsentation des Ergebnisses in XML.

178

16.7 Content-Zugriffs-Standards

Authentication (XML Digital Signature) Definiert eine XML-Syntax zur Repräsentation von Signaturen für Web-Dokumente und definiert Prozeduren zur Verifizierung solcher Signaturen. Signaturen gewährleisten die Unverfälschtheit und Authentisierung von Nachrichten jeden Typs. Authorization (SAML – Security Assertion Markup Language) OASIS SAML ist ein XML-Framework zum Austausch von Informationen für die Authentifizierung und Autorisierung. SAML liefert Web-orientierte Security-Funktionen wie Single Sign-on über verschiedene Firmen hinweg. SAML nutzt Industrie-Standard-Protokolle und Nachrichten-Frameworks, wie XML-Signature, XML Encryption und SOAP. XrML (eXtensible rights Markup Language) Allgemeine Methode zur Festlegung von Rechten und Bedingungen in Verbindung mit der Verwendung und dem Schutz von digitalen Inhalten und von Services. WS-Security (OASIS) Die Web Service Security Specification für die sichere Interoperation von Web Services baut auf anderen Security-Standards für Signaturen auf. Sie beschreibt Erweiterungen des SOAP-Headers für die Integrität von Nachrichten, Vertraulichkeit und Authentisierung. WS-Security liefert auch einen allgemeinen Mechanismus, Security-Tokens (von Kerberos, X.405) mit Nachrichten zu verbinden. WS-Security lässt durch sein offenes Konzept (SOAP Enhancements) den Geschäftspartnern die Wahl bei der konkreten Gestaltung der Security-Vorkehrungen (Plug-in).

16.7 Content-Zugriffs-Standards WebDAV (Web-based Distributed Authoring and Versioning) WebDAV dient dem Cross-Platform File Sharing und ist eine Erweiterung des HTTPProtokolls mit dem Ziel, Cross-Company Teams zu unterstützen. Dazu gibt es z. B. File Locking und Versionskontrolle. XQUERY (XML Query Language) Abfragesprache für heterogene Datenhaltungen, die entweder in XML gespeichert sind oder durch Middleware in diese Form transformiert werden. ICE (Internet Content Exchange) ICE ist das favorisierte Format zum Austausch (Syndication) von Dokumenten im XMLFormat.

179

16 Standards

16.8 Content-Präsentations-Standards xHTML (eXtensible HyperText Markup Language) Die xHTML-Spezifikation beschreibt eine Grundmenge von Tags (APIs) und Regeln, wie diese Menge erweitert werden kann. xHTML entspricht HTML 4.01. xHTML-Dokumente sind XML-Dokumente. SALT (Speech Application Language Tags) Dient der multimodalen Nutzung von Clients. Die verschiedenen Modes umfassen Sprache, Keyboard, KeyPad, Mouse, Stylus für den Input und Text-to-Speech, Audio, Text, Video oder Grafik für den Output. Jeder Modus kann unabhängig voneinander oder gleichzeitig genutzt werden.

16.9 Collaboration Platform Standards CPL (Call Processing Language) Sprache zur Steuerung von Telefonie-Servern, einer der verschiedenen Arten von MedienServern im Instant Messaging. Damit kann beispielsweise ein Application Server eine Konferenzschaltung initiieren. POP (Post Office Protocol) Wird als Protokoll für den Zugriff auf Mail auf einem Mail-Server genutzt. Eine Alternative dazu ist IMAP (Internet Message Access Protocol). Es gibt zwei Versionen von POP. POP2 basiert beim Senden von Nachrichten auf SMTP. POP3 kommt ohne STMP aus. SMTP (Simple Mail Transfer Protocol) Ein Protokoll zum Austausch von Nachrichten zwischen Servern, etwa um Mails von einem Server zum anderen weiterzuleiten. Auch ein Mail Client schickt seine Nachrichten zum Client via STMP, holt solche jedoch von dort mittels POP- oder IMAP-Protokoll. CAP (Calendar Access Protocol) Erlaubt Clients und Servern verschiedener Hersteller, Kalenderinformationen auszutauschen. IETF definiert momentan ICAP für das Internet. SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) SIMPLE nutzt das SIP-Protokoll in der Server-Server- und Client-Server-Interoperabilität beim Instant Messaging. SIP (Session Initiation Protocol) Ein Standard-Protokoll der IETF (Internet Engineering Task Force) zum Starten von Sessions mit Multimedia-Funktionen wie Video, Chat, Games, etc. SIP kann zudem InternetTelefonate steuern. SIP unterstützt die Umleitung von Services und macht es so den Anwendern möglich, sich frei im Netz zu bewegen.

180

16.9 Collaboration Platform Standards

H.323 H.323 ist ein »Umbrella«-Standard für die Real-time-Multimedia-Kommunikation und war zunächst der wichtigste Standard für VoIP. Mit der Einführung von SIP verliert dieser Standard etwas an Bedeutung. H.323 definiert Mechanismen für Call-Routing, Call-Signalling, Capabilities-Exchange, Media-Control und Supplementary Services. H.323 wird von PBXHerstellern genutzt, um diese Anlagen über LAN, WAN oder das Internet zu koppeln. Somit ist das Protokoll eine Kerntechnologie beim Aufbau verteilter PC-unterstützter Telefonsysteme. Darüber hinaus wird das Protokoll von Multimedia-Anwendungen genutzt, wie etwa Microsoft NetMeeting oder den IP Desktop-Telefonen.

181

17 Literaturverzeichnis

Berman, F., Fox, J. C. und Hey, A. J. G. (2003). Grid Computing. John Wiley, Chichester. Booch, G. (1995). Objektorientierte Analyse und Design. Addison-Wesley. Brahm, M., Pargmann, H. (2003). Workflow Management mit SAP® Webflow®. Das Handbuch für die Praxis. Springer. Berlin. Carr, N G. (2003). IT doesn’t matter. Harvard Business Review, May, S. 41-49. Chappel, D. (2003a). The big bet. Application Development Trends, October, S. 26. Chappel, D. (2003b). WS-Security, New Technologies Help You Make Your Web Services More Secure. msdn Magazine, April 2003. Davis, R. (2002). Business Process Modelling with ARIS. Springer, London. Dell, M. (1999). Direct from Dell. HarperCollinsBusiness, London. Erikson, H.-E., et. al. (2004) UML 2 Toolkit. Wiley, Indianapolis. Fielding, T. R. (2000). Architectural Styles and the Design of Network-based Software Architecture. Dissertation, University of California, Irvine. Fink, D., Köhler, T. und Scholtissek, S. (2004). Die dritte Revolution der Wertschöpfung. Econ. Fukuyama, F. (1999). Der große Aufbruch. Wie unsere Gesellschaft eine neue Ordnung erfindet. Paul Zsolnay, Wien. Gaedke, M., Turowski, K. und Rehse, J. (1999). Föderierung betrieblicher Anwendungssysteme auf der Grundlage Webbasierter Dienste. In: R.-D. Kutsche; U. Leser; J. C. Freytag (Hrsg.): 4. Workshop »Föderierte Datenbanken«: Integration heterogener Informationsquellen (FDBS-99). Berlin, S. 51-70. Gannon, D. et al. (2002). Grid Web Services and Application Factories. Department of Computer Science, Indiana University. www.extreme.indiana.edu/xcat/publications/ AppFactory.pdf. Geiß, M. (2002). Architektur für transaktionssichere Web-Service-Anwendungen. Diplomarbeit an der Technischen Universität München. Henkel, O. (2003). Die Ethik des Erfolgs, Spielregeln für die globalisierte Gesellschaft. Econ. Jeckle, M., Zenger, B. (2002). SOAP – aber sicher. Objektspektrum 01/2002, S. 17-27. Jhingran, A.D. et. al. (2002). Information integration: A research agenda. IBM Systems Journal Vol 41, No 4, 2002.

182

17 Literaturverzeichnis

Jungk, R. (1952). Die Zukunft hat schon begonnen. Amerikas Allmacht und Ohnmacht. Scherz & Goverts Verlag, Stuttgart. Kagelmann, U. (2001). Shared Services als alternative Organisationsform, am Beispiel der Finanzfunktion im multinationalen Konzern. Deutscher Universitäts-Verlag. Kaye, D. (2003). Loosely Coupled – The Missing Pieces of Web Services. RD Press. Koch, M., Möslein, K. und Wagner, K. (2000). Vertrauen und Reputation in OnlineAnwendungen und virtuellen Gemeinschaften. http://www11.informatik.tu-muenchen.de/ publications/pdf/Koch2000b.pdf. Leff, A., Rayfield, J. T., und Dias, D. M. (2003). Service-Level Agreements and Commercial Grids. IEEE Internet Computing, July-August, S. 44-55. Leymann, F. (2003). Choreographie: Geschäftsprozesse mit Web Services. Objektspektrum 05/2003, S. 19-21. Leymann, F., Roller, D. (1997). Workflow-Based Applications. IBM Systems Journal 36(1): S. 102-123. Leymann, F., Roller, D. (2000). Production Workflow: Concepts and Techniques. Prentice Hall, New Jersey. Löwe, U. M. (2003). Verschieben Web Services Unternehmensgrenzen? Erklärungsbeiträge zweier Theorien der Unternehmung. Arbeitspapier, 2. Draft/2003-02-18. LudwigMaximilians-Universität München, Department für Betriebswirtschaft, Institut für Unternehmensentwicklung und Organisation Informations- und Kommunikationsforschung. Microsoft (2002). Application Architecture for .NET: Designing Applications and Services. Patterns & Practices. Millner, R. (1999). Communicating and Mobile Systems: The π-Calculus. Cambridge University Press, Cambridge. Newcomer, E. (2002). Understanding Web Services. Addison-Wesley. Boston. Nilsson, A., G., Tolis, C. und Nellborn, C. (1999). Perspectives on Business Modelling: Understanding and Changing Organisation. Springer, Heidelberg. Parnas, D. (1972). On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12), S. 1053-1058. Picot, A., Reichwald, R. und Wigand, R. T. (2003). Die Grenzenlose Unternehmung. Information, Organisation und Management. Gabler, Wiesbaden. Preisendörfer, P. (1995). Vertrauen als soziologische Kategorie. Zeitschrift für Soziologie 4, S. 263-272. Ranadivé, V. (1999). The Power of Now. McGraw-Hill, New York. Rapoport, A. Chammah, A. (1965). Prisoner’s Dilemma; A Study in Conflict and Cooperation. University of Michigan Press, Ann Arbor. Reichwald, R., Möslein, K. (1997). Organisation: Strukturen und Gestaltung. http://www.aib.wiso.tu-muenchen.de.

183

17 Literaturverzeichnis

Reichwald, R., Piller, F. (2002). Customer Integration – Formen und Prinzipien einer Integration der Kunden in die unternehmerische Wertschöpfung, Arbeitspapier Nr. 26, München. Roth, M.A. et.al. (2002). Information integration: A new generation of information technology. IBM Systems Journal Vol 41, No 4, 2002. Rust, R. T., Kannan, P. K. (2002). e-Service. New Directions in Theory and Practice. M. E. Sharpe New York. Scheer, A.-W., Jost, W. (2002): ARIS in der Praxis 2003. Springer, Berlin. Schmidt, D. C., Vinoski, S. (2001). Object Interconnections: Corba and XMl – Part 3: SOAP and Web Services. C/C++ Users Journal C++ Experts Forum. http://cuj.com/ experts/1910/vinoski.htm. Senge, P. (1994). The Fifth Discipline: The Art and Practice of the Learning Organization. Doubleday Books. Siebel, T. M., House, P. (2000). Cyber Rules. Die neuen Regeln für Spitzenerfolg im e-Business. Verlag Moderne Industrie. Smith, H., Fingar, P. (2003). Business Process Management: The Third Wave. MeghanKiffer Press, Tampa. Woods, D. (2003a). Enterprise Service Architecture. O’Reilly, Sebastopol. Woods, D. (2003b). Packaged Composite Applications. O’Reilly, Sebastopol.

184

Hersteller- und Stichwortverzeichnis

BEA Systems 108 Brainloop 137 IBM 76-80, 110, 118, 122, 136-137

IDS Scheer 116, 121 Microsoft 75, 93-95, 111, 123, 135 Oracle 95

SAP 97, 113 Siebel 115 z

Business Activity Monitoring, BAM 25, 98, 119, 134, 157 Business Process 162, 168 Business Process Outsourcing, BPO 154, 157

Framework 6, 14, 35, 39, 51, 63-64, 72, 75, 104, 131, 143, 164

zz π-Calculus 57, 70, 167

A Abstract Process 160 Abstraktion 16, 34, 36, 39-40, 42, 44, 51, 54, 78, 160 ACID, Transaction 66, 157, 161 Adapter 34, 61, 79, 85, 91, 105, 124, 160 Agent 29, 53, 58, 74, 107, 126, 129, 135, 160 Aktivität 19, 37, 53, 57-58, 67, 100, 106, 126, 160 Anwendungsarchitektur 45-46, 155, 160 Application Server 34, 43, 54, 64, 73-74, 82, 104, 161 Application Service Provider, ASP 88, 157 Architektur 13-14, 16, 22, 25, 30-31, 41, 45-46, 52, 63, 83, 99-100, 102, 105, 154, 156, 161 asynchrone Kopplung 48, 161 Authentifizierung 68

B Beans 75 Binding, Late Binding 46, 73, 78, 161, 166 BPEL, BPEL4WS 17, 23, 59, 67, 70, 72, 79, 105, 107, 155, 157 BPEL Abstract Process 59-60, 70-71, 176

C Choreographie 58, 105, 155, 162 Contact Server 35, 129, 135, 162 Container 74, 85, 88, 162 CORBA 15, 34, 62-63, 82, 84, 88, 157 CRM 55, 157

D Design 34, 36, 40, 42, 52, 98, 107, 163 Digitale Signatur 69, 163 Disaggregiertes Unternehmen 148, 154, 163 Discovery 83, 102 DTD 96

E EDI 20, 111, 149, 157 EJB, Java Beans 77, 79-80, 157 Encryption 69 E-Services 27

F Factory 46, 72, 83, 87, 163 Federated Search 92, 97, 164 Firewall 24, 34, 61, 99, 164 föderativ 6, 10, 17, 19, 22, 31, 55, 89, 98, 125, 127, 129, 139, 151, 154, 156, 164

G GPRS 130, 157 Grid, Grid Computing, Grid Service 18, 31, 49, 81, 84-86, 88, 90, 92, 153, 156, 164

H Handle, Grid Service Handle 82, 84-85, 87, 164

I IIOP 54, 62, 75, 158 Instanz, Prozess-Instanz, Objekt-Instanz, Grid Service Instanz 19, 23, 37, 42, 59, 64, 72, 82, 85, 126, 165

J Java Beans, EJB 77, 79-80, 157 JIT 59, 71, 158

K Klasse 42-43, 52, 102, 105, 165 Kollektion 52, 165 Kompensation 42, 71, 74, 165 Komponente 15-16, 22, 24, 30, 38, 42-43, 45-46, 52, 55, 58, 64, 72, 74-75, 85, 99, 102, 106, 108, 155, 165 Konnektor (→ Adapter) 35 185

Hersteller- und Stichwortverzeichnis Konsistenz, Inkonsistenz 24, 37, 43-44, 66-67, 129, 165

L Layer 34, 45, 63, 166 LDAP 128, 158

M Marshalling 174 Message 40, 70-72, 166 Middleware 21, 34-36, 39, 44, 84, 149, 161, 166 Modell 20-21, 102, 106, 166 Modellierung 17, 21, 23, 38, 70, 73, 79, 100, 102, 106-108, 116-117, 155, 166, 168 MSMQ 49, 112, 158 MSN 135, 158 Multi-Tier 52, 166 MVC 13, 51, 158, 164

O Objekt 37, 43, 175 Objektorientierung 36-38, 167 ODBC 54, 158, 167 OGSA 82-83, 158, 175 OGSI 83, 85, 158, 175 OLE 167 OO 35-37, 42, 52, 158, 165 OQL 92, 158 ORB 158, 165 Orchestrierung 11, 28, 30, 59, 109, 111-112, 155-156, 167, 169

P PBX 134, 158, 181 Petri-Netze 57, 70, 167 PKI 130, 158 Port 72-73, 79, 106, 167 Portal 25, 53, 108, 124, 127, 132, 134, 167 Prozess, Geschäftsprozess, Synchronisationsprozess 10-12, 17, 19-20, 22-23, 27, 29, 31, 38-39, 42, 54, 56, 59, 70, 74, 88, 98, 100-101, 120, 129, 132, 134, 143, 145, 149-150, 156, 168 PSTN 128, 159 186

R RMI 15, 159, 177 RPC 62, 80

S SAML 70, 159, 179 Semantik 23, 47, 55, 72, 92, 102, 106, 169-170 Serialisierung 93, 169 Service 12, 23, 28, 30, 33, 41, 48, 51, 81, 101, 104 Service Bus 46-47, 77, 166, 169 Service-orientierte Architektur (SOA) 32, 40-41, 43-44, 48, 61, 90, 105, 159, 170 Servlet Engine 64, 86, 170 Session 72, 75, 129, 170 Shareable Enterprise Component 75 Shared Service 154, 170 Signatur 70, 170 SIMPLE 135, 159, 180 SIP 134-135, 138, 159, 180 Skriptsprache 170 SLA 25, 100, 142, 159 SOA (Service-orientierte Architektur) 32, 40-41, 43-44, 48, 61, 90, 105, 159, 170 SOAP 16, 24, 40, 46, 49, 61, 65, 68, 71, 80, 123, 159, 170, 174 SQL 14, 34, 40, 91, 96, 159 SSL 69, 159 SSO 25, 124, 159, 170 Staff Resolution 110, 170 Stored Procedure 91, 171 Stub 80, 171 Swimlane 100, 171 Synchronisation 43, 56, 106, 156, 171 Syndication 89, 171, 179

T Transaction, ACID 66, 157, 161 Transaktion 15, 24, 58, 66, 104, 166, 171, 176-177 Transaktionskosten 144, 171 Transaktionssicherheit 66, 104, 171

Transformation 22, 46, 56, 76, 102, 171 Transponder 153, 172 Two-Level Paradigm 16, 172

U UAN 111, 115-116, 159 UDDI 16, 102, 109, 112, 127, 159, 175 UML 102, 159, 176 UMTS 128-130, 159 Unternehmensprozessmodell 20, 172 URI 61, 79, 84, 159 URL 87, 96, 105, 124, 159

V Virtualisierung 82, 150, 152-153, 172 VoIP 136, 159, 181

W W3C 113, 159, 174 WAP 129-130, 159 WBI 110, 122, 159 WDSL 78 Web Service 12, 16, 31, 61, 172 WebDAV 135, 138, 159, 179 WML 14, 130, 159 Workflow 14, 20, 22, 39, 52, 172 WPKI 130, 159 Wrapper 34, 61, 79, 165, 173 WS 159 WSCI 110, 176 WSDL 24, 40, 44, 54, 61, 63, 71, 79, 83, 159, 174 WSFL 70, 159, 175 WSIF 62, 75, 77, 80, 159 WS-Security 68-69, 179

X XLANG 70, 175 XML 71, 96, 174 XPATH 71, 95, 159 XPath 174 XrML 70, 159, 179 XSLT 113, 159

Z Zone 33, 35, 44, 166, 173

Linnartz, W.; Heck, G.; Kohlhoff, B.; Schmidt, B.

Application Management Services und Support Softwarebetreuung systematisch planen, Softwareanwendungen systematisch betreuen 2004, 256 Seiten, 14,3 cm x 22,5 cm, gebunden ISBN 3-89578-224-6 49,90 € [D] / 75,00 sFr Im Spannungsfeld zwischen Mensch, Software und Geschäft gibt es keine Patentlösungen für den Support von IT-Anwendungen. Der Alltag nach der Einführung einer Unternehmenssoftware zeigt immer wieder, dass ein hoher Bedarf an einer Entscheidungsgrundlage besteht, wie Softwaresupport organisiert und durchgeführt werden soll. Dieses Buch ermöglicht Planern, IT-Betreuern und IT-Verantwortlichen die strukturierte Analyse des Supportbedarfs im eigenen Unternehmen. Der Leser erkennt dabei, welche nachhaltig positiven Auswirkungen eine anwenderfreundliche Systemkultur sowie professionelle Vorgehensweisen bei der Konzeption und Durchführung von Supportmodellen haben. Beispiele aus der Praxis zeigen die großen Qualitäts- und Kostenpotenziale, die systematisches Anwendungsmanagement erschließen kann.

Wiehler, Gerhard

Mobility, Security und Web Services Neue Technologien und Service-orientierte Architekturen für zukunftsweisende IT-Lösungen August 2004, ca. 240 Seiten, ca. 80 Abbildungen, 17,3 cm x 25 cm, gebunden ISBN 3-89578-228-9 49,90 € [D] / 75,00 sFr Mobile Netze und Internet wachsen immer mehr zusammen, Web Services werden zum neuen Paradigma für IT-Anwendungen. Diese sich ergänzenden Megatrends und eine Service-orientierte Architektur eröffnen faszinierende, neue Möglichkeiten: größere Mobilität, die Innovation von Geschäftsprozessen, neue Lösungswege für die Integration von Anwendungen und firmenübergreifende Prozessoptimierungen – Schlüsselfaktoren für „agil“ handelnde und zeitnah reagierende Unternehmen. Alle diese Techniken müssen ein Sicherheitsniveau bieten, mit dem sich größere Risiken vermeiden und sicherheitskritische Abläufe schützen lassen. Dieses Buch ist eine Pflichtlektüre für alle, die zukunftsweisende IT-Lösungen verstehen, kompetent agieren und ihren Marktwert erhöhen wollen, insbesondere CIOs, CTOs, IT-Architekten, Consultants, Projektmanager, Netzwerkspezialisten, Anwendungsentwickler, IT-Entscheider, Fachabteilungsleiter aus Industrie und Verwaltung sowie Studenten aus technischen und betriebswirtschaftlichen Studiengängen.

Gläßer, Lothar

IT-Lösungen im E-Business Die technischen Grundlagen: einfach, praxisnah, zukunftsorientiert 2003, 220 Seiten, 84 Abbildungen, 56 Listings, 17,3 cm x 25 cm, gebunden ISBN 3-89578-203-3 49,90 € [D] / sFr 75,00 Moderne Unternehmen machen ihre Anwendungen Web-fähig um ihren Kundenservice zu verbessern, ihren Einkauf zu optimieren, neue Märkte zu erreichen oder alte auszubauen. E-Business ist und bleibt damit ein wichtiger Baustein um im globalen Wettbewerb konkurrenzfähig zu bleiben. Dieses Buch gibt einen Überblick über die im Rahmen der Entwicklung von E-BusinessLösungen relevanten Technologien und Architekturen: heutigen und zukünftigen Basistechnologien des Internets und des World Wide Web bis zu Komponenten-Technologien. Eine Darstellung der Systemarchitektur moderner IT-Lösungen und der Systembausteine rundet den Inhalt ab. So ermöglicht das Buch für Profis einen schnellen Einstieg in das komplexe Thema. Mitarbeiter in IT-Abteilungen von Unternehmen und Behörden, Studenten, aber auch generell technisch Interessierte erhalten eine mit zahlreichen einfachen Beispielen illustrierte, verständliche Übersicht, ohne sich mit den zahlreichen Details oder Spezifikationen auseinandersetzen zu müssen.

Gläßer, Lothar

Open Source Software Projekte, Geschäftsmodelle, Rechtsfragen und Anwendungsszenarien – was IT-Anwender und Entscheider wissen müssen Juni 2004, ca. 120 Seiten, 14,3 cm x 22,5 cm, kartoniert ISBN 3-89578-240-8 Ca. 29,90 € [D] / sFr 45,00 Der Einsatz von Open Source Software (OSS) wird mehr und mehr auch für kommerzielle Unternehmen, Behörden und Verwaltungen interessant. Neben wirtschaftlichen Gründen sind Qualität, Sicherheit, Stabilität und Herstellerunabhängigkeit die Hauptargumente. Ehemalige Schwachstellen von OSS wie mangelhafte Verfügbarkeit von Anwendungen und effektiver Support durch kommerzielle Dienstleistungsunternehmen sind heute kaum noch ein Thema. Für fast alle professionellen und privaten Anwendungsbereiche gibt es fertige OS-Programme. Im Bereich der Middleware liefern zahlreiche Open-Source-Projekte die zur Realisierung von Unternehmensanwendungen notwendigen Bausteine. Dieses Buch gibt Anwendern und Entscheidern in Industrie und Verwaltung einen Einblick in die Möglichkeiten des Einsatzes von OSS im Unternehmen. Sie erhalten einen kompakten Überblick über die wichtigsten Open-Source-Projekte aus den Bereichen Betriebssystem (z. B. Linux), Office (z. B. OpenOffice), Middleware (z. B. Projekte der Apache Software Foundation) und Entwicklungswerkzeuge (z. B. Eclipse, ArgoUML). Die verschiedenen Lizenzmodelle werden vorgestellt und die rechtlichen Konsequenzen des Einsatzes von Open Source Software erläutert.