Hauptbeschreibung |
Ali Arsanjani, Simon Johnston, John Smith, IBM © Copyright 2005, 2006, IBM Corporation. All Rights Reserved.
Themen
Dieses Dokument beschreibt die dritte Aktualisierung von RUP (Rational Unified Process), bei der es schwerpunktmäßig um
die serviceorientierte Architektur (SOA) geht. Diese Aktualisierung ist ein wichtiger Meilenstein in den
RUP-Anleitungen zur SOA, denn sie stellt eine konsolidierte Methode bereit, die bisherige Inhalte von RUP für SOA mit
Inhalten der von IBM Global Business
Services (GBS) entwickelten Methode Service-Oriented Modeling and Architecture (SOMA) kombiniert. Die Methode SOMA wurde von IBM in
einer Reihe von Kundenprojekten erfolgreich angewendet. Ursprünglich wurde diese Methode unter Nutzung der vorhandenen
IBM GS-Methode (IBM Global Services Method) entwickelt. Mehr und mehr zeigte sich jedoch, dass sowohl IBM als auch die
Kunden der IBM im Bereich der SOA mehr von einem konsolidierten Methodenansatz als von zwei verschiedenen Methoden
profitieren würden. Bei einer Betrachtung der beiden Methoden wird klar, dass die Autoren sehr ähnliche Ziele
verfolgten und die Methoden auf ähnliche Weise strukturierten. So haben sich die beiden Teams im Jahr 2004 getroffen
und einige Änderungen an beiden Methoden vorgenommen, um die Terminologie anzugleichen. Diese Angleichung mutet nicht
überraschend an, da sich beide Methoden auf die pragmatischen Aktivitäten bei der Entwicklung einer serviceorientierten
Lösung fokussiert haben. Es wurde jedoch festgestellt, dass sich ein generisches Gerüst extrahieren lässt, mit dem
beide Methoden auf hohem Niveau beschrieben werden können.
Kunden, die mit dem klassischen RUP vertraut sind, wird hier das Konzept Serviceorientierte Lösungen entwickeln empfohlen.
IBM Mitarbeiter, die sich mit SOMA auskennen, möchten wir auf die Roadmap Statusänderung von IBM SOMA aufmerksam machen.
Die folgende Abbildung veranschaulicht das oben erwähnte Gerüst. Sie stellt eine methodenneutrale Gruppe von
Aktivitäten dar, die für jeden Prozess bei der Entwicklung serviceorientierter Lösungen erforderlich sind. Diese
Abbildung ist zwar eine starke Vereinfachung der Inhalte beider Methoden, stellt aber dennoch deutlich die Aktivitäten
der beiden Methoden dar - Serviceidentifikation, Servicespezifikation und Servicerealisierung. Es war klar, dass im
Bereich der Arbeitsergebnisse ein hoher konzeptioneller Angleichungsaufwand notwendig sein würde. Es waren ähnliche
Arbeitsergebnisse mit ähnlichen Rollen und Stakeholdern erforderlich, die jedoch in einigen Fällen unterschiedlich
realisiert werden, z. B. als UML-Modell oder als Word-Dokument. Dies wurde allerdings als relativ einfache Angleichung
angesehen. Generell korrespondieren die Haupteinflüsse recht gut mit den Aktivitäten, obwohl alle Anforderungen in der
Realität gewisse Auswirkungen auf alle Aktivitäten haben.
Abbildung - Konsolidiertes SOA-Methodengerüst
Es ist möglich, das Gerüst um eine Ebene zu erweitern, denn die hier identifizierten Aktivitäten werden von einer Reihe
von Verfahren unterstützt, und gerade im Bereich der detaillierten Verfahren findet die Integration der Methoden statt.
Dieses Dokument enthält keine detaillierte Beschreibung der Verfahrensintegration. Dennoch soll hier angemerkt werden,
dass die Entwicklung einer einzelnen kohärenten Methode zu einigen Änderungen bei beiden Ausgangsmethoden geführt hat,
um sicherzustellen, dass dem Leser konsistente Definitionen für Konzept, Strategie, Aufgaben und Arbeitsergebnisse
präsentiert werden. Um beim Inhalt eine gewissen Konsistenz zu erzielen, wurde beispielsweise entschieden, das
Servicemodell von RUP für SOA als Primärquelle zu verwenden, aus der eine Reihe von Berichten und Tabellen generiert
werden können, um die von SOMA-Fachleuten erwarteten Arbeitsergebnisse bereitzustellen. Generell ist diese Änderung von
Wert, weil sich das UML-Servicemodell durch eine zusätzliche Semantik auszeichnet und zur Entwicklung von
Servicespezifikations- und Servicerealisierungsmodellen verwendet werden kann. Das Servicemodell muss allerdings so
erweitert werden, dass es zusätzliche Informationen aufnehmen kann, die für vorhandene SOMA-Arbeitsergebnisse
erforderlich sind. Das Arbeitsergebnis Servicespezifikation wurde beispielsweise um die zusätzlichen Eigenschaften
'source' und 'status' erweitert, die routinemäßig von SOMA-Fachleuten verwendete Informationen erfassen.
Das Plug-in orientiert sich an folgenden Leitgedanken:
-
Es soll Raum für künftiges Wachstum gelassen werden. Dafür ist es wichtig, Bedingungen zu minimieren oder zu
vermeiden, die das Hinzufügen neuer Aktivitäten, Arbeitsergebnisse, Rollen usw. beschränken könnten.
-
Es soll die Möglichkeit offen gehalten werden, zu derzeitigen oder künftigen kommerziellen Methoden proprietäre
Erweiterungen hinzuzufügen, z. B. branchenspezifische Erweiterungen oder Assets in SOMA. Proprietäre Inhalte können
auch für die Servicewiederverwendung zum Gerüst hinzugefügt werden.
-
Der direkte Kontakt zum Kunden und die Nutzung des internen IBM Messaging sind gleichermaßen wichtig.
-
Eine Methode muss toolunabhängig sein, sollte jedoch Richtlinien für die Integration von Toolmentoren
bereitstellen, die das IBM Portfolio favorisieren.
-
Das Leistungsspektrum der Methodenaktivitäten sollte sich entfalten können und nicht ausgehend von der GS-Methode
oder von RUP oder anderen herkömmlichen Methoden beschränkt werden.
Bei dieser Aktualisierung für Rational Unified Process (RUP) handelt es sich um eine für den Softwarearchtitekten und den Designer bestimmten einführenden Anleitung zur Entwicklung eines
Servicemodells. Dieses Modell stellt ein Serviceportfolio dar,
das als Basis für Aufgaben, die in RUP bereits vorhanden sind, verwendet werden kann. Es soll auch die Verbindung
zwischen Geschäftsmodellierung und Servicemodell beschrieben werden. Viele SOA-Projekte verwenden
Geschäftsprozessmodelle, um ihre geschäftlichen Aufgaben, funktionalen Anforderungen und Services, die zur
Unterstützung eines Prozesses erforderlich sind, zu verstehen.
Der Umfang dieser Aktualisierung wurde in der Einführung kurz behandelt. Hier werden nun kurz die Angaben zu den
Anforderungen und zum Umfang vorgestellt, die für die Leitung des Projekts verwendet werden.
-
Vorhandenen RUP nutzen. In diesem Fall bedeutet das, neue Aufgaben und Arbeitsergebnisse, wo
möglich, mit Bezug zu bereits vorhandenen Aufgaben und Arbeitsergebnissen in RUP zu beschreiben und nicht unnötig
neue Konzepte hinzuzufügen. Auch neue Elemente sollten so hinzugefügt werden, dass sie sich in den gesamten
Verarbeitungsablauf von RUP einfügen.
-
Künftige Toolfunktionen berücksichtigen. RUP ist nicht toolabhängig. Allerdings sollte klar sein,
dass es keinen Sinn macht, Inhalt in Bereichen zu entwickeln, in denen es niemals Tools geben wird, und dass es
andererseits nicht erforderlich ist, ein Thema nicht zu schreiben, weil das Tool noch nicht am Markt ist, aber
wahrscheinlich sein wird.
-
Integration anderer Erfahrungen von IBM im Bereich SOA. Es ist klar, dass andere Gruppen innerhalb
IBM Erfahrungen gemacht haben, die genutzt, zusammengestellt und den einzuführenden Konzepten, Richtlinien und
Verfahren hinzugefügt werden können.
-
Umfangsänderungen für Analyse und Design. Die Anwendung der SOA auf das Geschäftsdesign und die
Auswirkungen der SOA auf die Geschäftsmodelle, die Organisation der Nutzung und die Geschäftsintegration werden in
der einschlägigen Literatur ausführlich beschrieben. Auch die Unterschiede, die bei der SOA hinsichtlich
Implementierung, Deployment und Organisationsverwaltung bestehen, wurden untersucht. Diese Themen sind für die
erste Iteration zu umfangreich, daher konzentriert sich dieser Abschnitt auf Fragen der Architektur und des
Designs.
-
Basis bereitstellen. Dies ist die erste Iteration. Es wird erwartet, dass weitere Anleitungen zu
dem hier vorgestellten Framework und der Verbindung, die zwischen diesem Inhalt und dem übrigen RUP in späteren
Iterationen hergestellt wird, hinzugefügt werden können.
-
Notwendige Änderungen der Basis prüfen, aber auf nächstes Release verschieben. Es ist klar, dass
manche eingeführten Konzepte mit Terminologie- oder anderen kleineren Änderungen am Basis-RUP besser funktionieren
würden. Es gibt sicherlich Situationen, in denen es wünschenswert wäre, RUP zu ändern, das hätte jedoch
umfangreiche Auswirkungen und würde sehr viel Zeit in Anspruch nehmen.
Dieser Inhalt soll im nächsten kommerziellen Release des Produkts Bestandteil des Basis-RUP sein. In der Zwischenzeit
soll der Inhalt Kunden zur Verfügung gestellt werden, damit hier beschriebener Inhalt als RUP-Plug-in gepackt und für
den Download bereitgestellt werden kann.
Parallel dazu werden Änderungen an der Disziplin "Geschäftsmodellierung" vorgenommen, die die Verbindung zwischen
Geschäftsmodellierung und SOA stärken. Es wurde jedoch die Entscheidung getroffen, die Änderungen an der
Geschäftsmodellierung abzuwarten, bevor das SOA-Plug-in fertig gestellt wird. Beide Änderungsgruppen werden für die
kommerzielle Freigabe integriert.
Eine Reihe von Schlüsselideen wird von der Service-Oriented Modeling and Architecture
(SOMA) von GBS eingebunden. Es ist zwar nicht möglich, alle Ideen und Anleitungen in die SOMA einzubinden -
insbesondere dort, wo sie den definierten Bereich überschreitet -, als Leitfaden bei der Arbeit ist sie jedoch
nützlich.
Es wurden bestimmte neue Prinzipien eingeführt, einschließlich bestimmter Konzepte, die die Bearbeitung des restlichen
Inhalts betreffen. Eines dieser Konzepte ist das so genannte Serviceportfolio und eine unternehmensweite Sicht der im
Unternehmen bereitgestellten Services.
Die Verfasser möchten folgenden Personen für ihren wertvollen Beitrag zu dieser Arbeit danken. Alan Brown und Sky
Matthews für ihre Unterstützung und die Prüfung des Inhalts. Eoin Lane, Steve Graham, Ed Kahan und Grant Larsen für
ihre Kommentare und ihre vielen nützlichen Beispiele. Den Kollegen und Kolleginnen, die an SOMA arbeiten, Ali
Arsanjani, Luba Cherbakov und Kerrie Holley. In diese überarbeitete Fassung wurde zusätzliches Material von Maryann
Hondo aufgenommen, die Web Services Security Architect bei IBM ist.
Wir möchten Claus Torp Jensen und seinem Team von der Danske Bank für das offene und ehrliche Gespräch über die realen
Erfahrungen der Bank mit der Anwendung der serviceorientierten Architektur danken.
|