Analyse der Umsetzungen von Services einer serviceorientierten Architektur in Unternehmen


Projektarbeit, 2009

46 Seiten, Note: 1,7


Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Zielsetzung der Arbeit
1.2 Aufbau der Arbeit

2 Grundlagen der serviceorientierten Architektur
2.1 Definition einer serviceorientierten Architektur
2.2 Die Kriterien für einen Service
2.2.1 Service-Arten
2.2.1.1 Kategorisierung nach Abstraktionsgrad
2.2.1.2 Kategorisierung nach Funktionalität
2.2.1.3 Gemeinsamkeiten der Klassifizierungsmöglichkeiten
2.2.2 Eigenschaften eines Service
2.2.2.1 Zentrale Eigenschaften eines Service
2.2.2.2 Unterstützende Merkmale eines Service
2.2.2.3 Die Beziehungen der Eigenschaften zueinander

3 Analyse der Umsetzungen von Services
3.1 Darstellung der ausgewählten Unternehmen
3.2 Umgesetzte Service-Arten in Unternehmen
3.2.1 Realisierungen von bekannten Service-Formen
3.2.2 Vergleich der realisierten Architekturen
3.2.3 Einsatz von neuen Service-Typen
3.2.3.1 Realisierung einer Kommunikationsverbindung für den Volks- und Raiffeisenbankverbund mittels Services
3.2.3.2 Stärken und Schwächen der VR-Services
3.3 Realisierbarkeit der Eigenschaften von Services
3.3.1 Einhaltung der Wiederverwendbarkeit bei Services
3.3.1.1 Wiederverwendbarkeit als ganzheitliche Maxime
3.3.1.2 Bedingte Umsetzung der Wiederverwendbarkeit
3.3.1.3 Vergleich der Methoden
3.3.2 Die lose Kopplung und Kompositionsfähigkeit von Services in der Praxis
3.3.2.1 Das Domänen-Konzept als Grundlage der losen Kopplung 3
3.3.2.2 Technologien zur Realisierung der losen Kopplung und Kompositionsfähigkeit
3.3.2.3 Nutzung der Technologien in den Unternehmen
3.4 Mögliche Modifizierungen der Service-Kriterien

4 Schlussfolgerung

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 2.1: Service-Kategorien nach Erl

Abbildung 2.2: Vergleich der Klassifizierungen von Services nach Erl, Krafzig et al. und Hess et al.

Tabellenverzeichnis

Tabelle 2.1: Gegenüberstellung von zentralen Eigenschaften eines Services und den dazugehörigen unterstützenden Merkmalen

Tabelle 3.1: Realisierte Services in den untersuchten Unternehmen

Tabelle 3.2: Vor- und Nachteile der VR-Services

Tabelle 3.3: Vor- und Nachteile der Umsetzung der Wiederverwendbarkeit bei sämtlichen Services einer SOA

Tabelle 3.4: Eingesetzte Technologien in den Unternehmen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Als neuer technologischer Trend tritt nach einer aktuellen Umfrage durch Progress Software unter 224 Independent Software Vendors (ISV) die serviceorientierte Architektur (SOA) zunehmest in den Vordergrund. Die Umfrage ergab, dass 71,4 Prozent der in Deutschland, der Schweiz und Österreich ansässigen ISVs SOA als eine der wichtigsten Tendenzen sehen (vgl. [Prog2008a]). Unternehmen müssen daher in der Lage sein, künftig auf diese Entwicklung zu reagieren und die Prinzipien von SOA in ihren Informationstechnik (IT) -Landschaften umsetzen können.

Weitere Studien verdeutlichen jedoch, dass sich im Zuge der Realisierungen von Services und deren Kontrollinstanzen zahlreiche Probleme ergeben. Es existieren beispielweise erst bei 30 Prozent der Unternehmen wieder verwendbare Services (vgl. [Prog2008b]) und lediglich 26 Prozent der deutschen Chief Information Officers haben eine SOA-Governance[1] implementiert (vgl. [Prog2008c]).

Die Ergebnisse der Untersuchungen veranschaulichen, dass SOA zwar als zukunftsweisende Architektur angesehen wird, jedoch aktuell erst wenige Umsetzungen die Charakteristika und Gestaltungsmöglichkeiten von Services sowie die notwendigen Kontrollinstanzen vollständig berücksichtigen. Josuttis bekräftigt diesen Eindruck und weist darauf hin, dass bei unvollkommenen Realisierungen vorzugsweise monolithische Systeme entstehen, welche allerdings die Innovativität in Hinblick auf die Geschäftsprozessmodellierung auf Abteilungsebene verlagert und keinen ganzheitlichen Ansatz für die gesamte Organisation bildet (vgl. [Josu2007, S. 657-659]).

Für eine erfolgreiche Einführung einer SOA sind daher die Kenntnisse über Services und deren Aufbau unabdingbar, damit die Geschäftsprozessstruktur entsprechend modelliert und implementiert werden kann. Des Weiteren ist das Wissen über mögliche Vor- und Nachteile der unterschiedlichen Service-Infrastrukturen für die Auswahl einer geeigneten Organisationsform unerlässlich.

1.1 Zielsetzung der Arbeit

In dieser Arbeit werden bisher bekannte Ansätze für die Typisierung und Realisierung von Services mit den Erfahrungen bei Umsetzungen in Unternehmen verglichen. Hierfür werden im ersten Schritt die Arten von Services einer serviceorientierten Architektur und deren Eigenschaften ausgearbeitet und mit praktischen Umsetzungen in Unternehmen verglichen. In diesem Kontext werden die Realisierungen daraufhin untersucht, inwieweit sie mit den theoretischen Ansätzen übereinstimmen und welche Modifizierungen und Ergänzungen bei den Arten und Merkmalen eines Service möglich sind.

1.2 Aufbau der Arbeit

Im Anschluss an dieses Kapitel wird in Kapitel 2 eine Definition des Begriffes serviceorientierte Architektur erarbeitet. Des Weiteren werden die Arten und Eigenschaften von Services bei SOA ausgearbeitet.

Die in Kapitel 2 erarbeiteten Service-Merkmale werden in Kapitel 3 den praktischen Umsetzungen in Unternehmen gegenübergestellt, wobei mögliche Differenzen zwischen den theoretischen Ansätzen und praktischen Erfahrungen bei der Realisierung von Services herausgestellt werden. Aufbauend auf diesen Unterschieden erfolgt eine Darstellung von möglichen Modifizierungen hinsichtlich der Service-Kriterien.

Kapitel 4 beinhaltet die Schlussfolgerungen aus den durchgeführten Analysen und weist auf mögliche künftige Entwicklungen im Bereich serviceorientierter Architekturen hin.

2 Grundlagen der serviceorientierten Architektur

2.1 Definition einer serviceorientierten Architektur

Bevor im weiteren Verlauf dieser Arbeit näher auf Services einer SOA eingegangen wird, erfolgt an dieser Stelle eine Definition der Begrifflichkeit. Erl beschreibt eine SOA wie folgt:

„SOA führt ein Architekturmodell ein, das Effizienz, Agilität und Produktivität eines Unternehmens dadurch steigern will, dass die Lösungslogik im Wesentlichen durch Services dargestellt wird.“ [Erl2008, S. 52]

Aus dieser Darstellung wird ersichtlich, dass SOA eher als Architektur und nicht als Technologie zu verstehen ist, welche mittels Services und deren Kompositionen die Geschäftslogik eines Unternehmens abbildet. Die von Erl aufgeführten Vorteile für Unternehmen bei der Nutzung von SOA werden ebenfalls von BEA Systems bestätigt, additiv hierzu werden die Eigenschaften und Vorteile von Services deutlich herausgestellt:

„A Service-Oriented Architecture (SOA) is a software design approach that allows enterprises to focus on business processes in their application development, rather then focusing at a lower level on integration or application issues. An SOA is a collection of reusable network services, communicating through well-defined, platform-independent interfaces. These services provide access to data, business processes, and IT infrastructure, and they allow for service provision, consumption, and lifecycle management.“ [BEA2007, S. 17]

Die Nutzung einer serviceorientierten Architektur bietet demnach die Möglichkeit, die Geschäftsprozesse auf einer abstrakten Ebene zu analysieren und dementsprechend zu modellieren, bevor diese implementiert werden. Als Resultat entsteht eine Service-Komposition, bei der wiederverwendbare Netzwerk-Services über wohl definierte Schnittstellen miteinander kommunizieren können. Diese ermöglichen den Zugriff auf Daten und Geschäftsprozesse und erlauben die Dienstnutzung der bereitgestellten Funktionalität.

Eine abstraktere Sicht auf eine serviceorientierte Architektur erfolgt nach Krafzig et al:

„Eine Serviceorientierte Architektur (SOA) ist eine Softwarearchitektur, die auf den folgenden Schlüsselkomponenten basiert: Anwendungs-Frontend, Service, Service-Repository und Service-Bus. Ein Service besteht aus einem Vertrag, einer oder mehreren Schnittstellen und einer Implementierung.“ [KrBS2007, S. 77]

Krafzig et al verdeutlichen die verschiedenen Bestandteile einer serviceorientierten Architektur und zwar das Anwendungs-Frontend, den Service, das Service-Repository sowie den Service-Bus. Des Weiteren geben sie den allgemeinen Aufbau von Services wieder.

Unter einem Anwendungs-Frontend werden dabei die aktiven Teile einer SOA verstanden, diese initiieren und kontrollieren alle Aktivitäten eines Enterprise-Systems (vgl. [KrBS2007, S. 78]). Services sind nach Krafzig et al eine Softwarekomponente mit einer ganz bestimmten funktionalen Bedeutung, die ein Geschäftskonzept höherer Ebene einkapselt. Damit die Services erkannt und Informationen über diese angefordert werden können, wird das Service-Repository benötigt, dieses beinhaltet neben den eigentlichen Service-Informationen weitere Angaben über beispielsweise den Provider, die Nutzungsgebühren und ähnliches (vgl. [KrBS2007, S. 78 – 80]).

Der Service-Bus verbindet alle Teilnehmer einer SOA, möchten zwei Teilnehmen miteinander kommunizieren, so wird dies durch den Service-Bus ermöglicht. Ein Service-Bus ist nicht von einer bestimmten Technologie abhängig, sondern kann eine Vielzahl von Produkten und Konzepten beinhalten (vgl. [KrBS2007, S. 83]).

Die vorgenannten Definitionen verdeutlichen, dass die Nutzung einer SOA eine Möglichkeit darstellt, die Geschäftsprozesse eines Unternehmens auf einer abstrakteren Schicht darzustellen bevor diese implementiert werden. Das Hauptaugenmerk liegt hierbei auf den Services welche die gewünschte Funktionalität eines Geschäftsprozesses zur Verfügung stellen und über wohl definierte Schnittstellen genutzt werden können. Von besonderer Bedeutung ist dabei, dass eine SOA kein Konzept für eine bestimmte Technologie darstellt, sondern vielmehr ein plattformunabhängiges Architekturkonzept bildet. Dies bestätigen auch Krafzig et al. mit ihrer Aussage: „Letztlich hat die SOA die Aufgabe, Geschäftsanwendungen von technischen Services zu entkoppeln und das Unternehmen von einer speziellen technischen Implementierung oder Infrastruktur unabhängig zu machen.“ [KrSB2007, S. 77] Beinhauer et al. sprechen bei SOA konkret von einem fachlichen IT-Architekturkonzept, welches kein Technologie-Konzept widerspiegeln soll (vgl. [BeHS2008, S. 20]).

2.2 Die Kriterien für einen Service

Die zentrale Bedeutung von Services bei SOA wurde aus den bisher aufgeführten Definitionen deutlich. Ein Service stellt dabei allerdings nicht eine Komponente dar, die stets den gleichen Aufbau besitzt und standardisierte Funktionalitäten übernimmt, vielmehr sind Services sehr individuelle Komponenten, welche je nach Einsatzgebiet und Abstraktionsschicht verschiedenartig konzipiert sind.

Die folgenden beiden Abschnitte zeigen mögliche Klassifikationen für Services auf und geben einen Überblick über die Eigenschaften eines Service. Diese werden im weiteren Verlauf dieser Arbeit als Vergleichskriterium für die reale Umsetzung von Services verwendet.

2.2.1 Service-Arten

Erl, Krafzig et al. sowie Hess et al. geben verschiedene Ansätze für die Typisierung von Services vor, welche entweder nach dem Abstraktionsgrad oder dem Funktionsumfang eines Service unterteilt sind. In den nachstehenden Abschnitten werden die unterschiedlichen Kategorisierungsmöglichkeiten vorgestellt und anschließend miteinander verglichen.

2.2.1.1 Kategorisierung nach Abstraktionsgrad

Nach Erl können Services in Utility-Services, Entity-Services und Task-Services unterschieden werden. Jede Art repräsentiert eine andere Abstraktionsebene für einen Geschäftsprozess beziehungsweise die in ihm enthaltenen Funktionalitäten (vgl. [Erl2008, S. 58–61]).

Utility-Services

Sie stellen einen eigenen funktionalen Kontext her, welcher nicht an einem Geschäftsprozess orientiert ist und bilden eine eigene technologieorientierte Service-Ebene. Auf dieser Ebene werden wieder verwendbare, übergreifende Utility-Funktionalitäten wie beispielsweise Ereignisprotokollierung und Benachrichtigung zur Verfügung gestellt (vgl. [Erl2008, S. 61]).

Entity-Services

Entity-Services bilden wirtschaftsorientierte Prozesse ab, deren Funktionen und Kontext auf einen oder mehreren Business-Entities basieren. Unter dem Begriff Business-Entities werden zum Beispiel Kunden, Mitarbeiter, Rechnungen und Forderungen verstanden. Dieser Service ist hochgradig wieder verwendbar, da er von übergeordneten Prozessen unabhängig ist, daraus folgt, dass er zur Automatisierung mehrerer Geschäftsprozesse genutzt werden kann (vgl. [Erl2008, S. 58]).

Task-Services und orchestrierte Task-Services

Ein Task-Service ist direkt an einen übergeordneten Business-Task oder Geschäftsprozess gebunden und besitzt in der Regel ein geringes Wiederverwendungspotenzial, da er als Controller einer Komposition eingesetzt wird. Ein Beispiel hierfür ist ein Prozess, welcher Rechnungsdaten mit Kundendaten vergleicht und das konsolidierte Ergebnis weitergibt (vgl. [Erl2008, S. 59-60]).

Task-Services können ebenfalls direkt Geschäftsprozessdefinitionen repräsentierten, welche auf einer Orchestrierungsebene angesiedelt sind. Sie werden in diesem Fall als orchestrierte Task-Services bezeichnet (vgl. [Erl2008, S. 60]).

Die vorgenannten Service-Kategorien nach Erl können auf Services der gleichen und sämtlichen untergeordneten Ebenen zugreifen. In Abbildung 2.1 werden die zuvor dargestellten Service-Typen und die möglichen Beziehungen untereinander dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Service-Kategorien nach Erl

2.2.1.2 Kategorisierung nach Funktionalität

Eine weitere Möglichkeit der Klassifizierung von Services zeigen Krafzig et al. auf. Sie gehen bei ihrer Gruppierung auf die implementierten Funktionalitäten ein und leiten daraus mögliche Einstufungen ab.

Krafzig et al. unterscheiden dabei folgende Service-Typen:

- Basis-Service
- Zwischen-Services
- Prozesszentrierter Service
- Öffentlicher Unternehmens-Service (vgl. [KrBS2007, S. 87]).

Diese werden nachstehend erläutert, wobei gleichzeitig ein Vergleich mit den Ansätzen von Hess et al. erfolgt, welche einen ähnlichen Ansatz für ihre Kategorisierung wählen.

Basis-Service

Basis-Services werden in daten- und logikzentrierte Services unterschieden. Datenzentrierte Services dienen der Verarbeitung von persistenten Daten, dies beinhaltet das Speichern und Laden von Daten, Sperrmechanismen und Transaktionsmanagement. Logikzentrierte Services hingegen kapseln Algorithmen für komplexe Berechnungen oder Geschäftsregeln ein (vgl. [KrBS2007, S. 88-89]).

Bei Hess et al. findet eine ähnliche Kategorisierung statt, nach ihnen existieren Bestands- und Funktionskomponenten. Die Bestandskomponenten verwalten wie die datenzentrierten Services die sich in ihrer Hoheit befindlichen Daten (vgl. [HeHV2006, S. 5]). „Funktionskomponenten bieten Services an, welche die Geschäftsfunktionen eines Unternehmens unterstützen.“ [HeHV2006, S. 5]

Unterschiedlich ist hierbei die Konzeptionierung von logikzentrierten Services nach Krafzig et al. und den Funktionskomponenten nach Hess et al. Logikzentrierte Services sind ein Bestandteil eines Basis-Services und greifen nicht direkt auf datenzentrierte Service zu, wobei die Verbindung zwischen diesen beiden Komponenten durch den Basis-Service erfolgt (vgl. [KrBS2007, S. 88-90]). Funktionskomponenten hingegen nutzen Bestandkomponenten zur Datenermittlung und Auswertung (vgl. [HeHV2006, S. 5]) und bilden daher eine übergeordnete Form zu den Bestandkomponenten.

Zwischen-Services

Zwischen-Services dienen der Überbrückung von Technologie-Lücken oder technischer Inkonsistenzen, sie agieren dabei als statuslose Vermittler. Es wird dabei zwischen Technologie-Gateways, Adaptern, Fassaden und funktionalitätsergänzende Services als mögliche Ausprägungen unterschieden (vgl. [KrBS2007, S. 91-96]).

Technologie-Gateways überbrücken technologische Lücken und sind somit insbesondere für ältere Integrationsprojekte geeignet, bei denen bestehende Anwendungen erweitert werden müssen. Adapter hingegen sind spezielle Zwischen-Services, welche die Signaturen und Nachrichtenformate eines Service auf Anforderungen eines Clients abbilden. Fassaden stellen eine andere Ansicht auf ein oder mehrere Services dar und funktionalitätsergänzende Services bieten die Möglichkeit einen Service zu erweitern, ohne den eigentlichen Service zu ändern (vgl. [KrBS2007, S. 91-96]).

Prozesszentrierte Services

Diese Art von Service kapselt nach Krafzig et al. das Wissen über Geschäftsprozesse eines Unternehmens ein und verwaltet den Status für die unterschiedlichen Clients (vgl. [KrBS2007, S. 96]). Krafzig et al. weisen bei prozesszentrierten Services darauf hin, dass sie nicht unbedingt für Unternehmen erforderlich ist, da die Architektur so einfach wie möglich gehalten werden soll (vgl. [KrBS2007, S. 97]).

Hess et al. sehen ebenfalls die Notwendigkeit eines solchen Service-Typs und bezeichnen ihn als Prozesskomponente, welche die Abläufe von Geschäftsregeln steuern. Es werden dabei sowohl vollautomatisierte Abläufe als auch Abläufe mit Benutzerinteraktion mit einbegriffen (vgl. [HeHV2006, S. 5]).

Öffentliche Unternehmens-Services

Öffentliche Unternehmens-Services werden von einem Unternehmen seinen Partnern und Kunden zur Verfügung gestellt, damit diese mit dem Unternehmen interagieren können. Da die Benutzer öffentlicher Schnittstellen in der Regel im Vorhinein nicht bekannt sind, werden an diese Art von Service spezielle Anforderungen hinsichtlich der Sicherheit, der rechtlichen Eindeutigkeit der übertragenen Dokumente und der Entkopplung der Geschäftspartner gestellt. Aufgrund der Konzeptionierung als öffentlicher Service sind ebenfalls Besonderheiten hinsichtlich der Abrechnung und der Service Level Agreements zu beachten (vgl. [KrBS2007, S. 98-99]).

Diese Service-Art wird in modifizierter Form als Interaktionskomponente bei Hess et al. bezeichnet, allerdings werden mit diesem Begriff ebenfalls die Schnittstellen zu den internen Anwendungen (vgl. [HeHV2006, S. 5]), welche bei Krafzig et al. mit dem Begriff Anwendungs-Frontend bezeichnet werden (vgl. [KrBS2007, S. 87]), mit einbezogen.

2.2.1.3 Gemeinsamkeiten der Klassifizierungsmöglichkeiten

Zwischen den bisher dargestellten Ansätzen zur Klassifizierung lassen sich einige Gemeinsamkeiten erkennen. Diese wurden für die Klassifizierungsansätze von Krafzig et al. und Hess et al. bereits in Abschnitt 2.2.1.2 dargestellt.

Parallelen finden sich ebenfalls zu den Ansätzen einer Typisierung von Services nach Erl, dies zeigt sich bei den Task-Services bzw. orchestrierten Task-Services nach Erl, den Prozess-Services nach Krafzig et al. und den Prozesskomponenten nach Hess et al. Jeder dieser Typen wird als Controller von Services untergeordneter oder gleicher Ebenen verwendet und unterstützt einen oder mehrere Geschäftsprozesse beziehungsweise bildet diesen ab. Gleichsam ist ein Zusammenhang zwischen den Entity-Services nach Erl, den Basis-Services nach Krafzig et al. und den Bestands- bzw. Funktionskomponenten nach Hess et al. zu erkennen, da sie jeweils Dienste zur Realisierung von Geschäftsfunktionen und Datenzugriffen zur Verfügung stellen.

Keine direkten Entsprechungen sind zwischen den Utility-Services und anderen Service-Typisierungen zu erkennen, dies gilt ebenfalls für die Zwischen-Services nach Krafzig et al.

Die Zusammenhänge zwischen den drei vorgenannten Ansätzen zur Kategorisierung von Services werden durch Abbildung 2.2 grafisch dargestellt. Grundlage der Ebeneneinteilung ist die Kategorisierung nach Krafzig et al. (vgl. [KrBS2007, S. 99-100]), welche um die Technologieebene ergänzt wurde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Vergleich der Klassifizierungen von Services nach Erl, Krafzig et al. und Hess et al.

2.2.2 Eigenschaften eines Service

Als zentrale Komponente einer SOA muss ein Service verschiedene Eigenschaften erfüllen, damit seine Dienste durch andere genutzt werden können und er orchestrierbar ist. Im Folgenden werden diese Eigenschaften näher erläutert, wobei sie in zentrale und unterstützende Merkmale eingeteilt werden.

2.2.2.1 Zentrale Eigenschaften eines Service

Die zentralen Eigenschaften stellen die Grundmerkmale dar, die ein Service für eine optimale Eingliederung in eine SOA besitzen muss. Sie werden durch andere Eigenschaften unterstützt, auf die in Abschnitt 2.2.2.2 näher eingegangen wird.

Wiederverwendbarkeit

Erl stellt bei der Entwicklung eines Services insbesondere die Wiederverwendbarkeit in den Vordergrund, nach ihm ist es Unternehmen hierdurch möglich, die gekapselte Service-Logik immer wieder zu verwenden und künftige Automatisierungsanforderungen zeitnah zu implementieren. Außerdem werden agnostische Service-Modelle ermöglicht und Service-Inventare mit einem hohen Anteil an agnostischen Services (vgl. [Erl2008, S. 259-264]).

Krafzig et al. sehen in Ergänzung zu Erl den Grad der Wiederverwendbarkeit in Interdependenz zu den Service-Typen. Basis-Services und öffentliche Unternehmens-Services (vgl. Abschnitt 2.2.1.2) sind ihnen zufolge hochgradig wieder verwendbar zu implementieren, hingegen benötigen Zwischen-Services sowie prozesszentrierte Services (vgl. Abschnitt 2.2.1.2) diese Eigenschaft lediglich in einem geringen Maße (vgl. [KrBS2007, S. 87]).

Aus den vorherigen Ausführungen wird ersichtlich, dass eine möglichst hohe Nutzbarkeit durch andere Services ein Hauptkriterium bei der Umsetzung von Services ist und für die Interaktion eines Unternehmens mit seiner Umwelt entscheidend sein kann. Es müssen allerdings nicht sämtliche Services wieder verwendbar implementiert werden, da sie teilweise recht spezifische Anforderungen realisieren.

Kompositionsfähigkeit

Aus Abschnitt 2.1 geht hervor, dass eine SOA in der Regel eine Architektur bestehend aus mehreren Services ist, welche teilweise auf andere Services zugreifen und als Komposition zusammen arbeiten. Erl zufolge sind daher Services unabhängig von einem tatsächlichen Kompositionsbedürfnis stets kompositionsfähig zu implementieren (vgl. [Erl2008, S. 393]).

Masak unterstützt die Ausführungen von Erl und sagt, dass die Kompositionsfähigkeit die Grundlage dafür bildet zeitnah auf Veränderungen reagieren zu können. Additiv hierzu wird durch die Umsetzung dieser Eigenschaft während der Implementierung die Wiederverwendbarkeit stark erhöht (vgl. [Masa2007, S. 104-106]). Dementsprechend spiegelt das Merkmal der Kompositionsfähigkeit die eigentliche Maxime einer SOA wieder, nämlich komplexe Geschäftsprozesse in wieder verwendbare Services zu zerlegen, welche die Dienste des jeweils anderen nutzen können.

Lose Kopplung

Grundlage der beiden vorgenannten Eigenschaften ist die lose Kopplung von Services. Nach Erl soll die Technologie und Implementierung eines Services vom Servicevertrag und den Nutzern der Funktionen abgekoppelt sein, damit Anpassungen hinsichtlich der Implementierung leichter möglich sind (vgl. [Erl2008, S. 179]). Die Reduzierung von Abhängigkeiten zwischen Services erhöht die langfristige Nutzbarkeit und deren Einsatzmöglichkeit in Kompositionen (vgl. [Erl2008, S. 208]).

Josuttis sieht in der losen Kopplung eine der bedeutendsten Eigenschaften einer serviceorientierten Architektur, da es Unternehmen mittels dieses Charakters möglich ist ihre heterogene System-Landschaft neu zu strukturieren und zu verbinden. Er warnt allerdings davor, den Aufwand für die Schaffung eines lose gekoppelten Systems zu unterschätzen, denn bis zu einer gewissen Komplexität steht der Aufwand in einem ausgewogenen Verhältnis zum Nutzen, ab einer gewissen Stelle ist dieser Sachverhalt jedoch nicht mehr gegeben (vgl. [Josu2007, S. 652]).

2.2.2.2 Unterstützende Merkmale eines Service

Neben den bisher aufgeführten Merkmalen eines Services existieren nach Erl Servicevertrage, Abstraktion, Autonomie, Zustandslosigkeit und Auffindbarkeit als weitere Eigenschaften eines Service. Sie stehen in direktem Zusammenhang mit den in Abschnitt 2.2.2.1 aufgeführten Charakteristiken und wirken bei der Umsetzung von ihnen mit. Im Folgenden werden diese fünf Kennzeichen näher erläutert und die jeweiligen Beziehungen zur Wiederverwendbarkeit, Kompositionsfähigkeit und losen Kopplung erörtert.

Serviceverträge

Serviceverträge bewirken, dass der Zweck und die Fähigkeiten eines Services leichter erkannt werden können und beschreiben die Schnittstellen. Sie können aus technischen und nichttechnischen Service-Beschreibungsdokumenten bestehen (vgl. [Erl2008, S. 143-144]).

„Je generischer, flexibler und erweiterbarer ein Vertrag ist, umso größer ist in der Regel das Wiederverwendungspotential des Service.“ [Erl2008, S. 161] Des Weiteren ist von der Granularität des Vertrages anhängig, wie kompositionsfähig ein Service ist (vgl. [Erl2008, S. 162]), durch den Vertrag selbst werden dabei die Abhängigkeiten zwischen den Services minimiert und somit die lose Kopplung unterstützt (vgl. [Erl2008, S. 159]).

Abstraktion

Services verbergen konsistent Informationen über die implementierte Technologie, Logik und Funktion, wobei lediglich die Serviceverträge für die Gewährleistung einer Interaktionsmöglichkeit veröffentlich werden. Die Abstraktion reguliert auf diese Weise die Art und den Umfang der veröffentlichten Metainformationen und beeinflusst somit die Wiederverwendbarkeit und Kompositionsfähigkeit von Services (vgl. [Erl2008, S. 223-248]). Zwischen dem Prinzip der Abstraktion und der losen Kopplung ist ein sehr enges Verhältnis vorhanden, da die Abstraktion darüber entscheidet, wie detailliert die veröffentlichten Informationen sind und dementsprechend eng die Services untereinander gekoppelt sind (vgl. [Erl2008, S. 248]).

Autonomie

Damit Services als eigenständige Komponenten innerhalb einer SOA agieren können, ist ein hohes Maß an Kontrolle über die zugrunde liegenden Ressourcen erforderlich (vgl. [Erl2008, S. 301]). Nach Erl werden hierfür 4 mögliche Ausprägungen unterschieden:

- Servicevertrag: Serviceverträge sind so aufeinander abzustimmen, dass sie sich in ihrer Funktionalität nicht überschneiden.
- Geteilte Autonomie: Logik und Ressourcen der zugrunde liegenden Implementierung werden mit anderen Teilen des Unternehmens gemeinsam genutzt.
- Service-Logik: die zugrunde liegende Logik ist isoliert, jedoch werden die Datenressourcen mit anderen Teilen des Unternehmens gemeinsam genutzt.
- Reine Autonomie: Die zugrunde liegende Logik und die Datenressourcen sind isoliert und nur dem Service gewidmet (vgl. [Erl2008, S. 306]).

Als Typen der Autonomie können zwei Formen unterschieden werden:

- Laufzeitautonomie: Ist der Grad der Kontrolle den ein Service zur Laufzeit über seine Arbeitsumgebung besitzt.
- Entwurfsautonomie: Grad der Kontrolle, den ein Service-Owner über den Service-Entwurf ausübt (vgl. [Erl2008, S. 305]).
Eine starke Kontrolle der Services über ihre Funktionen ist ein unabdingbares Entwurfsmerkmal für effektive Kompositionsmitglieder um stets eigenständig handeln zu können (vgl. [Erl2008, S. 430]). Außerdem wird durch die autonomiebedingte bessere Zuverlässigkeit und Berechenbarkeit eine vielseitigere Nutzbarkeit für mehrere Service-Consumer erreicht (vgl. [Erl2008, S. 320]) und die lose Kopplung durch die Reduzierung von Abhängigkeiten unterstützt (vgl. [Erl2008, S. 320-321]).

Zustandslosigkeit

Durch die Vermeidung von Zustandsverwaltungen wird die Nutzung von Services durch verschiedene Prozesse erleichtert, da sie keine Statusinformationen vorhalten müssen und somit besser wieder verwendbar sind. Die gängigsten Methoden für die Umsetzung sind breit angelegte Serviceverträge für den Empfang und die Übermittlung von Zustandsinformationen zur Laufzeit und interpretative Programmroutinen. Diese dienen zum Parsen verschiedenartiger Zustandsinformationen aus Nachrichten und der Reaktion auf die jeweiligen Aktionsanforderungen (vgl. [Erl2008, S. 337]). Des Weiteren führt die fehlende Verwaltung von Zustandsinformationen zu schlanken, optimal ausführbaren Kompositionsinstanzen (vgl. [Erl2008, S. 430]) und steht dabei in keinem Zusammenhang mit der losen Kopplung (vgl. [Erl2008, S. 207]).

Auffindbarkeit

Die Auffindbarkeit eines Services steht in engem Zusammenhang mit den Serviceverträgen. Sie müssen genügend Meta-Daten zur Gewährleistung der Auffindbarkeit eines Service enthalten und Zweck und die Fähigkeiten eindeutig zu formulieren (vgl. [Erl2008, S. 370]). Durch die Auffindbarkeit wird gewährleistet, dass Dienste nicht redundant implementiert werden und bereits vorhandene Services gefunden und identifiziert werden können. Sie steht daher in direktem Zusammenhang mit der Möglichkeit Services zu kombinieren und wiederzuverwenden. Dabei sind die veröffentlichten Meta-Informationen auf ein Minimum zu reduzieren, damit die lose Kopplung der Services nicht gefährdet wird.

2.2.2.3 Die Beziehungen der Eigenschaften zueinander

Die zentrale Bedeutung der Wiederverwendbarkeit, der Kompositionsfähigkeit und der losen Kopplung wurde aus den vorhergehenden beiden Abschnitten deutlich. Sie stehen in engen Zusammenhang mit den in Abschnitt 2.2.2.2 aufgeführten Merkmalen und sind eine Konsequenz aus deren Realisierung. In der weiteren Arbeit werden daher die drei Hauptmerkmale als Grundlage für die Analyse der Service-Realisierungen verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Gegenüberstellung von zentralen Eigenschaften eines Services und den dazugehörigen unterstützenden Merkmalen

3 Analyse der Umsetzungen von Services

In diesem Kapitel werden die in Kapitel 2 erarbeiteten Prinzipien zur Klassifizierung von Services mit wirklichen Umsetzungen in Unternehmen verglichen, wobei mögliche Realisierungsformen aus verschiedenen Branchen exemplarisch dargestellt werden. Des Weiteren erfolgt eine Analyse, inwieweit die Eigenschaften Wiederverwendbarkeit, Kompositionsfähigkeit und lose Kopplung bei Services von Bedeutung sind und welche Umsetzungen sich in der Realität wiederfinden. Zum Abschluss werden auf der Grundlage dieser Untersuchung mögliche Erweiterungen hinsichtlich der Kategorisierung und Merkmalszuordnung von Services herausgestellt.

3.1 Darstellung der ausgewählten Unternehmen

Für Analyse von Services wurden die Service-Infrastrukturen der Deutschen Post AG (DP) für den Dienstleistungssektor, der Volkswagen AG (VW) für die Produktionsbranche und die Unternehmen Winterthur, die Volks- und Raiffeisenbanken (VR) sowie Intelligent Finance (IF) für das Banken- und Versicherungswesen beispielhaft ausgewählt. Die Ausgangssituationen und Zielvorstellungen bei der Einführung der jeweiligen SOA waren bei diesen Unternehmen sehr unterschiedlich und zeigen daher verschiedene Wege der Service-Implementierung auf.

Deutsche Post AG

Die Entscheidung für eine serviceorientierte Architektur bei der Deutschen Post AG war darin begründet, dass aufgrund der Expansion des Unternehmens die IT stetig gewachsen ist und die Verwaltung der Kernprozesse zunehmest schwieriger wurde. Es entstanden dabei viele Anwendungen als Insellösungen die über keine eindeutige Abgrenzung ihrer Funktionalität verfügten. Im Jahr 1999 wurde daher ein erstes Konzept für eine geschäftsgetriebene SOA entworfen, bei der neben den Geschäfts-Services die Realisierung einer Service-Infrastruktur im Vordergrund. Das entsprechende Basisnetz ging im Dezember 2001 in Betrieb und ist seither im Einsatz (vgl. [KrBS2008, S. 317]).

Volkswagen AG

Als international tätiges und ständig wachsendes Unternehmen wurde es für Volkswagen erforderlich, die stetig größer werdende Komplexität der IT-Systeme zu beherrschen sowie prozessorientiert und effizient zu gestalten. Im Gegensatz zur DP stand bei VW neben der Verbesserung der internen IT-Infrastruktur die optimale Anbindung von Produktionspartnern im Vordergrund. In diesem Kontext gab es vier Herausforderungen:

- Etablierung einer standardisierten IT-Architektur mit konzernweiter Vernetzung
- Unterstützung der Geschäftsprozessintegration mit durchgängigen IT-Systemen
- Erhöhung des IT-Wertschöpfungsbeitrages durch Flexibilität und Innovationskraft
- Unterstützung internationaler Wachstumsstrategie durch IT

Diesen Anforderungen stand eine heterogene IT-Landschaft gegenüber, die über Jahre funktionell gewachsen ist. Zur Bewältigung der Differenzen zwischen Ist- und Soll-Funktionalität der vorhandenen IT-Landschaft wurde die SOA-Strategie eingeführt und sukzessive ein Service-Portfolio aufgebaut, damit eine einheitliche Datenhaltung, Prozesssteuerung und Verbindung zu den Service-Partnern gewährleistet werden kann (vgl. [Gehr2008, S. 213-220]).

Winterthur

Während bei der Deutschen Post AG und VW die Wahl für eine serviceorientierte Architektur darin begründet war, die Defizite in den jeweiligen heterogenen IT-Landschaften zu beseitigen, stand bei Winterthur die Beseitigung des monolithischen Mainframe-Systems im Vordergrund. Eines der bedeutendsten Ziele war die Schaffung neuer Kanäle für die Kunden, Partner und Mitarbeiter, wobei insbesondere der Zugriff über das Internet und Intranet ermöglicht beziehungsweise verbessert werden sollte. Zusätzlich stand die Wiederverwendung von bisherigen Funktionalitäten bei gleichzeitiger Entkopplung der Systemkomponenten im Vordergrund, um die Gesamtkomplexität des Systems zu reduzieren (vgl. [KrBS2008, S. 331]).

Intelligent Finance

Als Beispiel für eine Neugründung einer Organisationseinheit und der damit verbundenen Schaffung einer SOA wird die Service-Infrastruktur von Intelligent Finance aufgeführt. IF wurde im Jahr 2000 als Abteilung von Halifax plc gegründet, um neue Kunden außerhalb von Halifax zu finden. Zuvor wurde zwischen Mitte 1999 und Ende 1999 die IT-Infrastruktur für den neuen Unternehmenszweig entworfen, dabei überzeugten insbesondere die transaktionalen Aspekte einer SOA und bildeten die Grundlage für die Wahl dieser Architekturform. Im Zuge des Aufbaus wurden die Banking-Operationen von Grund auf neu geschaffen und bereits drei Jahre später verfügte IF über ein Anlagevermögen von 15,5 Milliarden Pfund (vgl. [KrBS2007, S. 363-366]).

Volks- und Raiffeisenbanken

Im Gegensatz zu den vorgenannten Unternehmen stand bei den Volks- und Raiffeisenbanken nicht die Neustrukturierung der gesamten IT-Landschaft an erster Stelle, sondern vielmehr die Schaffung einer einheitlichen Kommunikationsmöglichkeit zwischen den Verbundpartner. Da die jeweiligen Partner über unterschiedliche IT-Infrastrukturen verfügten wurden Services zur Verbindung der einzelnen Systeme geschaffen, welche als so genannte VR-Services bezeichnet werden. Die Entwicklung des Systems begann im Jahr 2001 mit dem Resultat, dass sich die VR-Services seit 2003 als einheitlicher Standard im Verbund durchgesetzt haben (vgl. [Adle2007, S. 681-694]).

[...]


[1] „SOA-Governance umfasst Maßnahmen und Aktivitäten zur Steuerung und Kontrolle einer serviceorientierten Architektur (SOA), einschließlich der Regelung von Entscheidungsprozessen und personellen Zuständigkeiten durch standardisierte Verfahren. […] Es erlaubt eine Kontrolle der Ausführung von Services und ein ständiges Monitoring der Performance […].“ [Prog2008c]

Ende der Leseprobe aus 46 Seiten

Details

Titel
Analyse der Umsetzungen von Services einer serviceorientierten Architektur in Unternehmen
Hochschule
Universität Duisburg-Essen  (Fachbereich Wirtschaftswissenschaften)
Note
1,7
Autor
Jahr
2009
Seiten
46
Katalognummer
V287056
ISBN (eBook)
9783656875819
ISBN (Buch)
9783656875826
Dateigröße
812 KB
Sprache
Deutsch
Schlagworte
SOA-Services, Serviceorientierte Architektur, SOA
Arbeit zitieren
M. Sc. Fabian Freitag (Autor), 2009, Analyse der Umsetzungen von Services einer serviceorientierten Architektur in Unternehmen, München, GRIN Verlag, https://www.grin.com/document/287056

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: Analyse der Umsetzungen von Services einer serviceorientierten Architektur in Unternehmen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden