Konzept: Serviceorientierte Architektur
In diesem Konzept wird die serviceorientierte Architektur (SOA) in verschiedenen Dimensionen charakterisiert: als Technologieinfrastruktur, als konzeptionelles Design-Framework, als Brücke zwischen Geschäft und IT und als Weiterentwicklung komponenten- und objektorientierter Techniken.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

Die Schwierigkeiten bei der Erstellung unternehmensweiter Softwarelösungen ergeben sich in mindestens vier Hauptbereichen:

  1. Verständnis hochkomplexer Geschäftsbereiche
  2. Ermittlung der effizientesten Nutzung von IT-Ressourcen zur Erfüllung geschäftlicher Bedürfnisse
  3. Steuerung der Entwicklungsarbeit großer Entwicklerteams über mehrere Projektphasen und viele Monate hinweg
  4. Die Implementierung von Lösungen in einem komplexen Sortiment von Infrastrukturtechnologien, die sich über viele Jahre entwickelt haben und eine Vielzahl von Middleware-Produkten verschiedener Anbieter umfassen, die in spärlich dokumentierten Integrationsvorgängen unterschiedlicher Qualität assembliert wurden.

Lösungen in diesem Kontext zu entwickeln, erfordert einen Ansatz in der Softwarearchitektur, der Architekten hilft, ihre Lösungen auf flexible Weise weiterzuentwickeln und bereits geleistete Arbeit im Kontext neuer Funktionen wiederzuverwenden, die Geschäftsfunktionen schnell implementieren, auch wenn die Zielinfrastruktur selbst sich weiterentwickelt. Um diesen Anforderungen besser gerecht werden zu können, versuchen viele Organisationen, Informationsquellen als weitgehend unabhängige, wiederverwendbare, funktionale Funktionen zu reorganisieren, die eine per se anpassbare Umgebung erstellen. Durch Beschreibung dieser wiederverwendbaren Funktionen mit offenen Standardprotokollen kann eine Organisation selbsterklärende Services erstellen, die unabhängig von der zugrunde liegenden Technologie verwendet werden können. Diese technische Unabhängigkeit erlaubt es, Services in verschiedenen Kontexten zu verwenden, um Geschäftsprozesse, Regeln und Richtlinien zu standardisieren. Es wird jetzt allgemein anerkannt, dass dieser Ansatz für IT-Systeme, der als serviceorientierte Architektur (SOA) bezeichnet wird, das Potenzial für eine enorme Verbesserung der Reaktionsfähigkeit von Geschäfts- und IT-Abteilungen hat.

Die Entwicklung hin zur SOA stellt eine Organisationen vor viele Herausforderungen. Serviceorientierte Konzepte führen beispielsweise neue Begriffe und Modelle ein und fördern die Interoperabilität und Prozessintegration. Außerdem kann die Integration vieler zugrunde liegender Technologieschichten, die eine serviceorientierte Architektur ausmachen, eine sehr komplexe Aufgabe sein. IT-Abteilungen kommen oft zu der Erkenntnis, dass es notwendig ist, das Konzept zu ändern, das Know-how auf den neuesten Stand zu bringen, neue Funktionen in die Entwicklungsumgebungen aufzunehmen oder Änderungen an den Prozessen für Lösungsdesign vorzunehmen. Das Konzept der SOA, das erst seit kurzem existiert, besteht in dem Bestreben, alle diese Anforderungen zusammenzubringen. Es gibt allerdings verschiedene klare Perspektiven zur Spezifik einer SOA und ihrer Rolle bei der Handhabung wichtiger Probleme im Zusammenhang mit der Entwicklung von Softwarelösungen für Unternehmen.

SOA als Technologieinfrastruktur

Systeme setzen sich aus Sammlungen von Services zusammen, die Aufrufe für Operationen durchführen, die über ihre Serviceschnittstellen definiert sind. Viele Organisationen drücken jetzt ihre Lösungen durch Services und deren Zusammenwirken aus. Das höchste Ziel bei der Anpassung einer SOA besteht darin, Flexibilität für das Geschäft und den IT-Bereich zu schaffen. Es wurden eine Reihe wichtiger Technologien zur Unterstützung eines SOA-Ansatzes definiert, besonders wenn die Services auf viele Maschinen verteilt sind und eine Verbindung zu ihnen über das Internet oder ein Intranet besteht. Diese Web-Services-Ansätze stützen sich auf Kommunikationsprotokolle wie SOAP, die zwischen Services verwendet werden, und bieten die Möglichkeit, Web-Services-Schnittstellen (ausgedrückt in WSDL (Web Services Definition Language)) bei öffentlichen Verzeichnissen zu registrieren und in UDDI-Registrys (Universal Description, Discovery and Integration) zu durchsuchen. Außerdem nutzen sie Informationen in Dokumenten, die in XML definiert und in Standardschemata beschrieben werden, gemeinsam. Darüber hinaus werden Standards entwickelt, um weitere Bereiche wie Richtlinien, Zuverlässigkeit, Ermittlung usw. abzudecken. Diese Standardfamilie wird im Allgemeinen mit "WS-* family" bezeichnet.

Die serviceorientierte Architektur ist jedoch genauso wenig nur eine Gruppe von Standards und Servicebeschreibungen wie die Objektorientierung einfach nur eine Gruppe von Klassenhierarchien ist. Tatsächlich besteht die Möglichkeit, eine SOA aufzubauen, die keine Web-Services-Technologie verwendet, und es ist auch möglich, die Web-Services-Technologie nicht serviceorientiert zu nutzen. Es gibt wesentlich mehr Punkte zu berücksichtigen, wenn man verstehen möchte, warum ein serviceorientierter Blickpunkt einem Geschäft Nutzen bringt und wie serviceorientierte Lösungen entworfen, implementiert und verwaltet werden. [SOA ist nicht mit WS identisch]

SOA als konzeptionelles Framework für Design

Lösungen für SOA zu erstellen, bedeutet, das Konzept von Systemen, die heute entwickelt werden, sowie das Know-how in Organisationen zu überdenken. Es bedeutet auch, die Art und Weise der Zusammenarbeit von Teammitgliedern neu zu definieren. Wichtig ist vor allem, dass bei einer serviceorientierten Lösungsentwicklung die Auswirkungen auf das Lösungsdesign umfassender geprüft werden müssen. Es muss geprüft werden, wie die Lösungen aus den verschiedenen Services zusammengestellt und implementierte serviceorientierte Lösungen verwaltet und weiterentwickelt werden.

Eine wichtige Änderung in diesem Zusammenhang ist, dass der Begriff "Anwendung", wie schon erläutert, problematisch wird. Es findet eine Verlagerung statt: von der Anwendung als zentraler Größe aller Projekte hin zum Service-Portfolio, auf dem ein Geschäft basiert. Diesbezüglich kann die Verlagerung von anwendungsorientierten zu serviceorientierten Projekten als Verlagerung vom Design einer vertikal integrierten Gruppe von Komponenten, die eine Anwendung ausmachen, hin zum Design einer horizontalen Servicegruppe betrachtet werden. In Zukunft wird der Begriff der Anwendung wohl nur noch zur Beschreibung einer kleinen Schicht spezifischer, mit den Services für die Benutzerinteraktion in engem Zusammenhang stehender Geschäftslogik verwendet, die die Geschäfts- und Infrastrukturservices mit dem größten Nutzen bereitstellen.

Gartner bezeichnet diesen weiteren Kontext der Serviceorientierung als serviceorientierte Entwicklung von Anwendungen (Service-Oriented Development of Applications, SODA). Er geht bei der SODA von folgenden fünf Grundsätzen aus: Zusammensetzung, adaptives Prozessmanagement, servicebasierte Interoperabilität und Integration, Erkennung und Beschreibung sowie schnelle Anwendungspflege. Aus der Perspektive des Toolherstellers beziehen sich diese Punkte auf Technologieunterstützung in drei Bereichen:

SOA-Lebenszyklus. Die Grundsätze "Erkennung und Beschreibung" und "Schnelle Anwendungspflege" beziehen sich auf den Lebenszyklus, die Lokalisierung, Anwendung, Weiterentwicklung und Pflege von Services. Toolhersteller stellen immer mehr Methoden bereit, mit denen Services gespeichert, katalogisiert, gesucht und abgerufen werden können. Unterstützung für die laufende Weiterentwicklung von Services ist in diesem Zusammenhang ein kritischer Aspekt, der zu vielen Serviceversionen führt.

SOA-Plattform und -Programmiermodell. Der Grundsatz "Servicebasierte Interoperabilität und Integration" bezieht sich auf die Verbindung, das Deployment und die Verwaltung von Services in einer bestimmten Laufzeitplattform. Die wichtigsten Plattformhersteller unterstützen serviceorientierte Funktionen direkt als Teil der Middleware-Laufzeiten und entwickeln die Laufzeitprogrammiermodelle weiter, um die Servicekonzepte als Elemente ersten Grades bereitzustellen. Infolgedessen können Lösungen aus einer einzigen servicebasierten Perspektive konzipiert, entworfen, implementiert und verwaltet werden.

SOA-Verfahren und -Tools. Die Grundsätze "Komposition" und "Management adaptiver Prozesse" beziehen sich auf die Erstellung und Assemblierung von Services im Kontext der Lösung sich ändernder Geschäftsanforderungen. Toolhersteller unterstützen die Filterung vorhandener Anwendungen zur Ermittlung potenzieller Services, wobei man vorhandene Funktionen als Basis verwendet, um die Leistungsmerkmale als Services zur Verfügung zu stellen. Des Weiteren unterstützen Toolhersteller die Erstellung neuer Services und die Verbindung von Services, wobei Verbindungen zwischen dem über die Schnittstellen bereitgestellten Verhalten hergestellt werden. Von entscheidender Bedeutung in diesem Zusammenhang sind klare Anleitungen und bewährte Verfahren für die Entwicklung serviceorientierter Lösungen, die wiederholbar und voraussagbar sind.

Alle drei Bereiche sind für den Erfolg bei der Entwicklung serviceorientierter Lösungen wichtig. Sie müssen alle berücksichtigt werden, um den Anforderungen einer Organisation in Bezug auf die effiziente Erstellung flexiblerer Lösungen, die besser auf die geschäftlichen Ziele ausgerichtet sind, gerecht zu werden.

SOA als ganzheitlicher Ansatz für Lösungen, die Geschäft mit IT verbinden

Eine der primären Herausforderungen bei der Entwicklung unternehmensweiter Lösungen ist, die domänenspezifischen, durch Geschäftsanalysten ausgedrückten Anforderungen mit den technologiespezifischen, von der IT-Abteilung entworfenen Lösungen zu verbinden. Normalerweise ist die Verbindung zwischen diesen zwei getrennten Welten nicht positiv. Die zwei Communitys haben ein sehr unterschiedliches Know-how, verwenden verschiedene Modellierungskonzepte und Notationen (falls überhaupt) und haben oft keine Vorstellung von der Zuordnung zwischen ihnen. Die Verwendung eines serviceorientierten Ansatzes soll diese Lücke zwischen den Geschäftsanalytikern, den Geschäftsbereichsspezialisten und IT-Spezialisten, z. B. Architekten, Systemanalytikern, Integratoren, Designern und Entwicklern, überbrücken helfen. Insbesondere die Integration von Prozessen, Assets und Liefergegenständen sollen diese zwei verschiedenen Aspekte des Systems klar und präzise verbinden.

SOA stellt eine serviceorientierte Sicht bereit, um diese Herausforderungen zu bewältigen:

Diskrepanz zwischen Geschäft und IT überbrücken. Es ist von wesentlicher Bedeutung, die Geschäftssicht von Aktivitäten und Prozessen an der Technologie auszurichten, die zur Realisierung von Teilen dieser Aktivitäten verwendet wird. Diese Ausrichtung beinhaltet die Fähigkeit von Geschäftsmodellen, Downstream-Entwicklung zu steuern und die Geschäftsmodelle und IT-Lösungen in Kombination zu entwickeln. Das Servicekonzept ist für diese Ausrichtung von entscheidender Bedeutung. Services und servicebasierte Denkweise bilden die allgemeine Grundlage, die Geschäftsanalytiker, IT-Architekten, Integratoren und Entwickler miteinander verbindet. Die Spezifik von Services, der Unterteilungs- und Kapselungsstufe, die sie unterstützen, erlaubt ihnen eine viel stärkere Ausrichtung auf die Geschäftsprozessmodelle, die das Geschäft steuern. Allgemeine Designverfahren sind von entscheidender Bedeutung, um sicherzustellen, dass die Konzepte, Arbeitsergebnisse und Aufgaben in diesen verschiedenen Perspektiven synchronisiert werden. Außerdem sind Tools, die Modelle, die die Geschäftsabsicht repräsentieren, in effiziente Implementierungen umwandeln können, sehr wichtig, um die Lücke zwischen Geschäft und IT zu überbrücken.

Die sich ändernden Rollen in der IT-Abteilung unterstützen. Die Verlagerung hin zu serviceorientierter Denkweise ändert das Know-how und die Zusammensetzung von Teams in einer Organisation. Der Fokus der Entwicklung liegt darauf, Services zu suchen, definieren, verwalten und assemblieren, mit architektonischen Beschreibungen, die Service-Level-Agreements (SLAs) und Protokolle zwischen Services hervorheben. Die traditionelle Gliederung von Toolfunktionen in die heutige Produktaufstellung lässt sich mit diesem Ansatz nicht vereinbaren. Es gibt eine andere Mischung von Funktionen, die von den verschiedenen Mitgliedern in IT-Abteilungen angefragt werden. Beispielsweise wird das Know-how, das von vorhandenen Rollen, z. B. dem Softwarearchitekten, sich dahingehend ändern, dass es die Assemblierung und das Management von Services in einer anderen Gruppe von Serviceprovidern stärker betont. Analog dazu entstehen neue Rollen wie die des Integrationsspezialisten, die sich auf die Assemblierung einer servicebasierten Wertschöpfungskette zur Unterstützung der wichtigsten Geschäftsziele einer Organisation konzentrieren.

Fokus auf Assets und Wiederverwendung. Die Berücksichtigung von Services als wichtige Assets im Systemdesign ändert den Blick einer Organisation auf den Nutzen, den die Wiederverwendung dieser Services bringt. Zuvor wurde die Verlagerung von der vertikalen Entwicklung einer Gruppe von Anwendungskomponenten hin zur horizontalen Integration von Komponenten erläutert. Ein wichtiger Aspekt in diesem Zusammenhang ist, dass die Services selbst in höherem Maße wiederverwendet werden können. Tatsächlich ist die Kombination der Services zu neuen Funktionen, ihre Zusammensetzung zu neuen Services ein grundlegender Aspekt der Änderung. In vielen Geschäften rechtfertigt diese Hoffnung auf eine bessere Wiederverwendung im Rahmen einer SOA die Kosten, die mit dem Design und der Entwicklung eines Service-Portfolios verbunden sind. Infolgedessen werden Technologien und Techniken zur Verwaltung und Steuerung von Assets sowie wiederholbare Methoden zur Erfassung von Mustern für die Kombination von Assets sehr viel wichtiger. In einem assetbasierten Entwicklungsansatz haben diese Assets einen großen Wert für die Organisation und müssen sorgfältig verwaltet werden. Die Infrastruktur des Teams für die Asset-Verwaltung übernimmt in diesem Ansatz eine wichtige Rolle.

Mehr Kollaborationsebenen in Anwenderrollen und darüber hinaus. Die Entwicklung von Unternehmensanwendungen basierte schon immer auf Teamarbeit und konzentrierte ihre Aufmerksamkeit im gesamten Lebenszyklus von Projekten auf die Verwaltung gemeinsam genutzter Assets, die Rückverfolgbarkeit von Arbeitsergebnissen und gemeinsam genutzte Verfahren und Prozesse. Die Interaktivität der Softwareentwicklung gewinnt mit größerer geographischer Verteilung von Organisationen, verbesserter Echtzeitkommunikation zwischen Einzelpersonen in Teams und Software, die als Bestandteil breiter angelegter Initiativen zur Systementwicklung integriert werden, an Bedeutung. Die Rolle der Infrastrukturen der Softwareentwicklung wird in immer stärkerem Maße als interaktive Entwicklungsumgebung für Softwareanwender gesehen, die die teamübergreifende gemeinsame Nutzung und Wiederverwendung von Services unterstützen.

SOA als Weiterentwicklung komponentenbasierter und objektorientierter Techniken

Bei jeder neuen Entwicklung im Bereich des Software-Engineering ist es sehr einfach, anzunehmen, dass jemand dieselben Techniken und Tools anwenden kann, die in vorherigen Projekten funktionierten. Diese Tendenz, neue Probleme mit veralteten Lösungen zu beheben, ist nicht neu. Als Entwickler begannen, komponentenbasierte Anwendungen zu entwickeln, versuchten sie, Probleme zu lösen, indem sie ihre Erfahrung mit objektorientierter Entwicklung nutzten. Mit zunehmender Erfahrung begriff man, dass objektorientierte Technologie und Sprachen sehr gut zur Implementierung von Komponenten geeignet sind, obwohl man sich über die Kompromisse bei Entscheidungen und Implementierung im Klaren sein muss. Beispielsweise muss hinsichtlich der Implementierung polymorphen Verhaltens oder der Überarbeitung von Klassenbibliotheken ein Kompromiss zwischen Übernahme und Aggregation gefunden werden, damit Komponentengruppen als Basis für eine monolithische C++-Anwendung verwendet werden können.

Analog dazu bieten Komponenten die beste Möglichkeit zur Implementierung von Services, obwohl betont werden muss, dass eine vorbildliche komponentenbasierte Anwendung nicht notwendigerweise eine vorbildliche SOA ausmacht. Wenn Sie sich mit der Rolle, die Services in der Anwendungsarchitektur spielen, vertraut gemacht haben, haben Sie eine gute Chance, die Komponentenentwickler Ihres Unternehmens einzusetzen und vorhandene Komponenten zu verwenden. Wichtig zur Durchführung dieses Übergangs ist, zu erkennen, dass ein serviceorientierter Ansatz eine zusätzliche Schicht der Anwendungsarchitektur einschließt. Die Abbildung unten zeigt, wie man Technologieschichten auf die Anwendungsarchitektur anwenden kann, um allgemeiner definierte Implementierungen bereitzustellen, wenn man sich den Konsumenten der Lösung annähert. Für diesen Bereich des Systems wird der Begriff "Anwendungsrand" verwendet, der zum Ausdruck bringt, dass ein Service sich gut dazu eignet, eine externe Sicht eines Systems offen zu legen, mit interner Wiederverwendung und Komposition, bei Verwendung des traditionellen Komponentendesigns. Eine Möglichkeit, die Unterschiede zwischen Objekten, Komponenten und Services zu untersuchen, besteht in der Art und Weise, auf die sie an ihre Implementierung gekoppelt sind. Ein Objekt ist fest an seine Programmiersprache gekoppelt, Komponenten sind an eine Laufzeit oder Plattform (COM, CORBA, J2EE u. Ä.) gekoppelt, wohingegen Services wirklich nur an die Gruppe der Standards gekoppelt sind, die deren Spezifikation beschreiben.

Diagramm ist im Textinhalt beschrieben.

Allgemein betrachtet nahm der Wechsel von der objektorientierten zur komponentenbasierten Methode zwischen 6 und 18 Monate in Anspruch. In dieser Zeit machten sich die Entwickler mit dieser neuen Technologie und ihren Anforderungen vertraut. Es bleibt zu hoffen, dass der Wechsel zu serviceorientierten Lösungen schneller vonstatten geht. Um das möglich zu machen, müssen Entwickler sich mit den Herausforderungen, Kompromissen und designbezogenen Entscheidungen vertraut machen, die die Entwicklung und Wiederverwendung von Komponenten zur Unterstützung serviceorientierter Lösungen ermöglichen.