Ausarbeitung für das Seminar "Aktuelle Themen der Informatik" Thema: Serviceorientierte Architekturen (SOA)
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Ausarbeitung für das Seminar
„Aktuelle Themen der Informatik“
Thema:
Serviceorientierte Architekturen (SOA)
Fakultät Informatik
Studiengang Computer-Networking
HOCHSCHULE FURTWANGEN UNIVERSITY
Bearbeiter:
Pierfranco Cosco
Matrikel-Nr.: 217009
pierfranco.cosco@gmx.de
St. Georgen, den 14. Oktober 2006
Einführung
Inhaltsverzeichnis
1 Einführung ....................................................................................................................3
2 Allgemeines zu SOA......................................................................................................3
2.1 Begriffserklärung ....................................................................................................3
2.2 Gründe für eine SOA ..............................................................................................4
2.3 Was ist ein Service?................................................................................................4
2.4 Merkmale einer SOA ..............................................................................................6
3 Bestandteile und Rollen in einer SOA ........................................................................6
3.1 Lebenszyklus eines Service ....................................................................................7
4 SOA-Architektur ..........................................................................................................7
4.1 Komponenten einer SOA........................................................................................8
4.2 Aufbau einer SOA ................................................................................................10
4.2.1 SOA mit CORBA ............................................................................................10
4.2.2 SOA mit RMI...................................................................................................11
4.2.3 SOA mit Web Services ....................................................................................11
4.3 Enterprise Service Bus..........................................................................................13
5 Einsatzmöglichkeiten einer SOA...............................................................................14
6 SOA-Anbieter..............................................................................................................14
6.1 IBM.......................................................................................................................14
6.2 SAP .......................................................................................................................15
6.3 BEA ......................................................................................................................15
7 Fazit..............................................................................................................................15
8 Literaturverzeichnis ...................................................................................................17
- Seite 2 -
Einführung
1 Einführung
Diese Ausarbeitung wurde im Rahmen des Seminars „Aktuelle Themen der Informatik“ im
Wintersemester 2006/2007 verfasst.
Sie behandelt die Grundlagen der Thematik „Service-Orientierten Architekturen (SOA)“.
Der Aufbau der Ausarbeitung gestaltet sich wie folgt.
Es wird zunächst eine allgemeine Definition gegeben, in dem die Bezeichnung SOA näher
erläutert werden. Anschließend werden die Möglichkeiten für den Aufbau einer SOA
gegenübergestellt und erklärt welche Paradigmen zugrunde liegen und welche
Technologien eingesetzt werden können. Parallel hierzu werden Vor- und Nachteile zu
SOA allgemein und zu den einzelnen Realisierungsarten erläutert.
Gegen Ende wird ein kurzer Einblick darin gewährt wie bestimmte kommerzielle Anbieter
SOA interpretieren und auf welche Art sie versuchen, eine solche aufzubauen.
Abgeschlossen wird die Ausarbeitung durch ein allgemeines persönliches Fazit zu SOA.
2 Allgemeines zu SOA
2.1 Begriffserklärung
In den letzten Monaten ist der Hype-Begriff SOA in aller Munde, welcher für Service
Oriented Architecture steht. Eine eindeutige Definition des Begriffs SOA gibt es nicht.
Man liegt bei fast jeder Begriffsdefinition weder völlig falsch noch völlig richtig. Viele
Hersteller sehen SOA unterschiedlich und interpretieren diese auch auf sehr
unterschiedliche Weisen, d.h. es gibt mehrere SOA-Philosophien. Deshalb kann in dieser
Ausarbeitung auch keine eindeutige Begriffsdefinition zu SOA gegeben werden.
Auf der Internetseite www.service-architecture.com findet sich eine Definition für den
Begriff SOA: „A service-oriented architecture is essentially a collection of services. These
services communicate with each other. The communication can involve either simple data
passing or it could involve two or more services coordinating some activity. Some means of
connecting services to each other is needed.” [SACOM]
Das bedeutet, dass eine SOA im Prinzip nichts anderes ist als viele Services, die
miteinander kommunizieren, und dass diese eine Möglichkeit haben müssen, gegenseitig
Verbindungen aufzubauen. Prinzipiell ist diese Definition nicht falsch, sie ist sogar
weitgehend richtig. Allerdings trifft sie den Kern, was eine SOA bedeutet, nicht. Eine SOA
ist nicht nur eine simple Ansammlung von Services, die miteinander kommunizieren,
sondern muss auch als Architekturkonzept verstanden werden, welches das originäre
Geschäft eines Unternehmens bestmöglich unterstützt. Die Definition von Ankur Gupta ist
deshalb treffender: “Service Oriented Architecture (SOA) is an approach to the
development of loosely coupled, protocol-independent distributed applications composed
from well-defined, self-contained software resources accessible as Services across the
extended enterprise in a standardized way, enhancing re-usability and interoperability."
Ankur Gupta, marketing manager, Fiorano Software Inc.
- Seite 3 -
Allgemeines zu SOA
Häufig wird auch der Begriff EAI (Enterprise Application Integration) in Verbindung mit
SOA gebracht. Das ist falsch, denn SOA ist definitiv nicht EAI! EAI ist dazu gedacht,
autonome Anwendungen oder Prozesse miteinander mittels eines zentralisierten Hubs zu
koppeln, damit für die Gesamtanwendung sinnvolle Verarbeitungsmöglichkeiten entstehen.
Die bestehenden Anwendungen bzw. Prozesse bleiben dabei möglichst unverändert. In
einer SOA hingegen werden Services und nicht Anwendungssysteme betrachtet. [ENTW1]
Kurz gesagt geht es bei SOA darum: Es soll eine Architektur geschaffen werden, bei der
die Geschäftsprozesse eines Unternehmens als flexible miteinander verknüpfte Services
abgebildet werden können. Dabei soll das Gesamtsystem wartungsarm, flexibel und
hochgradig erweiterbar sein.
2.2 Gründe für eine SOA
IT-Landschaften vieler Unternehmen sind zunehmend heterogen und sind im Laufe der
Jahre sehr gewachsen. Außerdem haben sie deutlich an Komplexität zugenommen. Eine
SOA soll bei der Beherrschung der Komplexität helfen und sowohl die Wartung als auch
die Erweiterung der IT vereinfachen, denn diese Aktivitäten kosten viel Geld und nehmen
sehr viel Zeit in Anspruch. Somit kann eine SOA zu einer Kosten- und
Komplexitätsreduktion führen. Eine SOA setzt an diesen Problemen an.
2.3 Was ist ein Service?
Das was hinter einer SOA und dem Begriff „Service“ steckt ist nicht trivial. Manche sind
der Meinung es seien „Web Services“ oder ein „Enterprise Service Bus“. Prinzipiell ist das
nicht falsch, da man eine SOA mit den o. g. Technologien aufbauen kann. Es ist aber
einfach nicht alles und trifft nicht die zentrale Bedeutung.
Der Begriff „Service“ wird häufig falsch oder unpassend gedeutet. Unter einem Service
lässt sich zweifellos eine lose gekoppelte Softwarekomponente verstehen. Was im Falle
einer SOA die richtige Beschreibung ist. Folgende Eigenschaften treffen zusätzlich in
Bezug auf eine SOA auf Services zu:
• Genügend grob granular, um eine abgeschlossene geschäftliche Bedeutung zu
tragen
• Genügend fein granular, um in unterschiedlichem Kontext Verwendung finden zu
können
• Der Contract bzw. die Servicebeschreibung wird in einer Registry veröffentlicht
• Die Wiederverwendbarkeit des Service muss sehr hoch sein, damit er sinnvoll ist.
Deshalb sollte auf die nötige Abstrahierung geachtet werden
• Einzelne Services sind sehr lose gekoppelt, d.h. sie haben wenige oder gar keine
Abhängigkeiten zueinander
• Services sind modular und können somit mit anderen Services zusammen einfach
zu einer Gesamtapplikation zusammengefügt werden
• Services haben eine standardisierte Schnittstelle, die über ein Netzwerk adressierbar
ist
- Seite 4 -
Allgemeines zu SOA
• Services sind ortstransparent
• Services sind in einem Verzeichnis auffindbar und können dynamisch gebunden
werden
Für ein besseres Verständnis des Begriffs „Service“ sollte der Zusammenhang zwischen
Services, Komponenten und Objekten aufgezeigt werden. Im Allgemeinen wird die
Granularität von den Objekten über die Komponenten zu den Services gröber und die
Kopplung loser. Dies verdeutlicht Abbildung 1. Zudem zeigt diese Abbildung, dass die
Services im Kontext eines Business Process laufen, der in BPEL definiert ist. D.h. die
Services einer SOA sind Teil eines oder mehrere Business Processes, welche wiederum
zusammen die Applikation bilden. Eine nähere Erläuterung hierzu erfolgt im Hauptteil.
Abbildung 1 - Zusammenhang zwischen Services, Komponenten und Objekten [JavaMag1]
Einen detaillierten Vergleich zwischen Services, Komponenten und Objekten zeigt Tabelle
1.
Objekte Komponenten Services
Granularität Fein Mittel Grob
Vertrag Öffentlich/privat Öffentlich Veröffentlicht
Wiederverwendbarkeit Gering Mittel Hoch
Kopplung Eng Lose Sehr lose
Abhängigkeiten Compile-Zeit Compile-Zeit Laufzeit
Innerhalb Innerhalb Innerhalb
Kommunikationszweck
Applikation Applikation Unternehmen
Tabelle 1 - Vergleich zwischen Services, Komponenten und Objekten [Reich1]
- Seite 5 -Bestandteile und Rollen in einer SOA
2.4 Merkmale einer SOA
Zusammenfassend lassen sich folgende Merkmale für SOA feststellen:
• SOA ist ein Ansatz für Software-Design und keine neue Technologie
• Bei einer SOA werden granulare Services zusammengebaut
• Services in einer SOA kommunizieren miteinander
• Im Vordergrund stehen Geschäftsprozesse
• Geschäftsprozesse können durch Orchestrierung von Services zusammengestellt
werden
3 Bestandteile und Rollen in einer SOA
Damit Services in einer SOA kommunizieren können bedarf es drei Komponenten, die drei
sehr wichtige Rollen übernehmen:
1. Service Provider: Stellt den Service zur Verfügung. Dies kann eine bestimmte
Funktionalität, Geschäftslogik oder eine Ressource sein
2. Service Consumer: Ist der Client, der den Service nutzt.
3. Service Registry: Ist vergleichbar mit einem Service Broker. Sie ist ein zentraler
Verzeichnisdienst für alle verfügbaren Dienste.
Abbildung 2 - Das Service-Dreieck [Dapeng]
Der Service Provider registriert die von ihm bereitgestellten Services bei der Service
Registry. Der Service Consumer stellt eine Suchanfrage an die Service Registry für einen
bestimmten Service. Der Service Consumer kann sich durch die erhaltenen Informationen
nun an den Service Provider binden, der den Service zur Verfügung stellt. Somit kann zur
Laufzeit ein neuer Service gefunden und benutzt werden.
- Seite 6 -SOA-Architektur
3.1 Lebenszyklus eines Service
Das abgebildete Service-Dreieck (Abbildung 2) deutet den Lebenszyklus von Services an.
Dabei kann zwischen den folgenden Stufen für den Lebenszyklus des Service
unterschieden werden:
• Modellierung: In diesem Schritt wird der Kontrakt festgelegt, den der Service erfüllen
muss – also die Definition des Service. Dazu gehören das Bestimmen der Datentypen,
Nachrichtenformate und Operationen.
• Konformität: Eine Qualitätssicherung achtet darauf, dass sämtliche Richtlinien von IT-
Systemen beachtet werden (IT-Governance und Compliance). Es kann sich dabei um
geschäftliche und technische Richtlinien halten. Bei Web Services können bspw.
Forderungen nach standardkonformen Datentypen vorhanden sein.
• Veröffentlichung: Services, bei denen die Richtlinien eingehalten sind, werden in
einem zentralen Verzeichnis (Service-Repository) registriert. Dieses Verzeichnis liefert
anschließend alle benötigten Informationen, die für den Service-Aufruf von Bedeutung
sind.
• Orchestrierung: In dieser Phase wird das Zusammenspiel der Services festgelegt. Es
wird z.B. bei der Verwendung des Standards „BPEL1“ eine Prozessbeschreibung
erstellt, die die Abfolge aller benötigten Aktivitäten definiert. Eine Aktivität kann auch
über einen Partner-Link mit einem Web Service verbunden sein und mit diesem
Nachrichten austauschen. Auf diese Weise werden die „eingebundenen“ Web-Services
in der gewünschten Reihenfolge ausgeführt, so dass ein sinnvoller Geschäftsprozess
entsteht.
• Überwachung: In dieser Phase kommt das Business Activity Monitoring (BAM) ins
Spiel. Hiermit lassen sich einzelne Geschäftsprozesse anpassen bzw. ändern und
zusätzlich der Prozessfortschritt überwachen und protokollieren. Durch die Ergebnisse
der Protokollierung und Überwachung kann man Prozessoptimierung ableiten.
• Entsorgung: In dieser Phase werden nicht mehr benötigte aus dem Service-Repository
entfernt. Davor muss aber zunächst der Service als nicht mehr benötigt gekennzeichnet
werden. Sobald alle Prozessbeschreibungen, die dieses Service benutzen angepasst
wurden kann der Service aus dem Verzeichnis genommen werden.
4 SOA-Architektur
Für den Aufbau einer SOA darf man nicht ausschließlich die einsetzbaren Technologien für
die Realisierung in betracht ziehen. Organisatorische Faktoren sind für den Erfolg u. U.
ebenfalls sehr wichtig. [AJAXW1]
1
BPEL: Business Process Execution Language
- Seite 7 -SOA-Architektur
Dieses Kapitel beschäftigt sich mit den technologischen und architekturrelevanten
Eigenschaften einer SOA: also das „Was“ und „Womit“. Da es öfters zu
Missverständnissen führt sei zum „Womit“ bereits zu diesem Zeitpunkt angemerkt, dass
man eine SOA nicht ausschließlich mit Web Services aufbauen kann. Zudem ist eine
Ansammlung von Web Services, die miteinander kommunizieren, nicht gleich eine SOA.
4.1 Komponenten einer SOA
Laut [WeyBeck1] lässt sich eine SOA aus vier verschiedenen Blickwinkeln (Abbildung 3)
betrachten. Das bedeutet, dass man sich vor dem Aufbau einer SOA, Gedanken zu
folgenden vier Fragen machen muss:
1. Warum soll eine SOA aufgebaut werden?
2. Wie soll die SOA aufgebaut werden?
3. Womit soll sie aufgebaut werden?
4. Was soll dabei aufgebaut werden?
Abbildung 3 - Die vier Dimensionen einer SOA [WeyBeck1]
Man kann daraus ablesen, dass sowohl strategisches und geschäftsorientiertes Denken als
auch technologische Kompetenz erforderlich ist, um eine SOA aufzubauen und anwenden
zu können.
Abbildung 4 zeigt die wesentlichen Komponenten einer SOA aus technischer Sicht.
- Seite 8 -SOA-Architektur
Abbildung 4 - SOA-Architektur-Stack [ENTW1]
Die Basis einer SOA ist stets ein Service Repository, welches die verfügbaren,
implementierten Services enthält. Das Repository legt auch Syntax und Semantik der
auszutauschenden Nachrichten fest und sorgt so für universell gültige Datentypen. Auf dem
Service Repository setzt das Process Repository auf, welches die verfügbaren Prozesse
verwaltet. Ein solcher Prozess stellt die Orchestrierung bestimmter Services dar. Bezüglich
Prozessmodellierung zeichnet sich ein deutlicher Trend zu grafischen
Beschreibungsformen dieser Prozesse ab. Die Wurzeln hiervon liegen in der
Geschäftsprozess bzw. Workflow-Modellierung. Oberhalb des Prozess-Repository befindet
sich eine Prozess-Engine, die die definierten Prozesse in der gewünschten Reihenfolge und
unter den gewünschten Bedingungen (Prozessablauf) ausführen kann. Zuständig hierfür ist
der Process Container, der sämtliche Prozesse verwaltet. Beim Start des Prozesses wird die
Prozessbeschreibung instanziiert und ausgeführt. Die Prozess-Engine muss sich dabei um
ein korrektes Nachrichten-Routing, Nachrichtentransformation, Fehlerbehandlung,
Validierungen usw. kümmern. Auf der Prozess-Engine baute eine Präsentations-Engine
auf. Ihre Aufgabe ist die Ermöglichung einer Nutzerinteraktion im Prozessablauf. Derartige
Präsentations-Engines könnten bspw. Portal-Anwendungen oder Groupware- Systeme sein.
[ENTW1]
Einen detaillierten Überblick über die Komponenten einer SOA und deren Funktionalität
zeigt Abbildung 5. Als Beispiel wird hier eine bestehende, verteilte und heterogene
Anwendungslandschaft angenommen. Die Präsentationsschicht ist zuständig für die
Aufbereitung der Informationen und die Interaktion mit den Usern. Die darunter liegende
Schicht der Geschäftsprozesse enthält die Verknüpfungen der Services zu Prozessen und
kümmert sich um die Orchestrierung und somit um die Abfolge der Aufrufe und die
Koordination dieser. Eine Schicht darunter liegen die definierten Services. Sie entkoppeln
die Funktionalität von der tatsächlichen Realisierung einer Anwendung. Die Anwendungen
liegen nämlich unterhalb der Services und stellen die Geschäftslogik bereit. Hauptaufgabe
des ESB (Enterprise Service Bus) ist das Bereitstellen Integrationsfunktionalität. Näheres
hierzu liefert Abschnitt 4.3. BPM und BAM hingegen bieten Dienste an, die das
Überwachen und Protokollieren von Geschäftsprozessen ermöglichen. Der Bereich
- Seite 9 -SOA-Architektur
„Infrastruktur“ in Abbildung 5 stellt die Soft- und Hardware dar, die eine unterstützende
Funktion haben (z.B. Datenbanken, Netzwerk und Message Queues). Im Bereich
„Betriebssysteme“ sind Hard- und Software aufgeführt, auf denen die Anwendungen
laufen.
Abbildung 5 - SOA-Schichtenmodell [WeyBeck1]
4.2 Aufbau einer SOA
Der Designansatz einer SOA ist unabhängig von der Technologie. Eine SOA kann mit
verschiedenen (auch unterschiedlichen) Technologien umgesetzt werden. Dieser Abschnitt
soll zeigen mit welchen verschiedenen Technologien eine SOA (bzw. die Services hierfür)
realisiert werden kann.
Wie bereits erwähnt muss eine SOA nicht unbedingt mit Web Services aufgebaut werden.
[KrJa2003] gibt an: „Web Services basieren auf einer SOA (Service Oriented
Architecture)“ und „SOA = Modell, bei dem drei unterschiedliche Interaktionen auf einem
Web Servicedurchführen“. Diese Aussagen sind nicht richtig. Eine SOA lässt sich bspw.
auch mit den Technologien CORBA oder RMI implementieren.
4.2.1 SOA mit CORBA
CORBA ist durchaus eine geeignete Technik für die Implementierung einer SOA, es hat
allerdings einige Nachteile. Mit der IDL (Interface Definition Language) bietet CORBA
eine standardisierte Schnittstellenbeschreibungssprache. Da CORBA-Objekte durch das
Konzept der IDL zudem programmiersprachenunabhängig sind und das Interface-
Repository, welches durch Benutzung des CORBA Name Service, als zentraler
Verzeichnisdienst dienen könnte, wäre CORBA eine ausreichend geeignete Technologie.
- Seite 10 -SOA-Architektur
Allerdings wird CORBA trotzdem nicht sehr häufig für die Realisierung einer SOA
eingesetzt. Dies hat mehrere Gründe. CORBA besitzt einerseits ein binäres Protokoll,
welches nicht durch Firewalls gesnifft werden kann (im Gegensatz zu http). Zudem wurde
Nummer des Portes des benutzten IIOP-Protokolls noch nicht standardisiert. Dies würde
bei mehreren CORBA-Kommunikationspartnern zu einer erhöhten Anzahl an offenen Ports
in der Firewall führen. Für den Einsatz innerhalb eines Unternehmens ist CORBA sogar
bestens geeignet. Da ein binäres Protokoll eingesetzt wird, ist die Performanz im Vergleich
zu Web Services aufgrund eines geringeren Overheads (z.B. Parsen der Nachricht) viel
besser. Zudem besteht gegenüber RMI der Vorteil der Sprachunabhängigkeit.
4.2.2 SOA mit RMI
Die Realisierung einer SOA mit RMI ist auch möglich. Die Architektur von RMI ist
vergleichbar mit CORBA (ebenfalls Stub/Skeleton). Allerdings ist die Mächtigkeit im
Vergleich zu CORBA geringer. So gibt es keine standardisierte Schnittstellenbschreibung
wie die IDL. Die Beschreibung muss durch Java-Interfaces erfolgen. Daraus folgt zudem,
dass keine weitere Programmiersprache benutzt werden kann. Das Problem mit der
Firewall besteht auch hier: Die Kommunikation erfolgt über den RMI-IIOP-Port und
verursacht somit ein weiteres Öffnen von Ports in der Firewall. Bei Web Services reicht es
im Normalfall den http-Port 80 freizugeben.
Die Wiederfindbarkeit eines Service bzw. Java-Objekts ist gewährleistet durch das Java
Naming an Directory Interface (JNDI) und der RMI-Registry, die alle registrierten Java-
Objekte zur Verfügung stellt. Hinsichtlich der Performanz besteht, wie bei CORBA, ein
Vorteil gegenüber Web Services. Java-RMI benutzt ebenfalls ein binäres Protokoll,
welches weniger Datenaufkommen verursacht und keines Nachrichten-Parsings bedarf.
Allerdings kann das binäre Protokoll nicht durch die Firewall gesnifft werden und stellt
somit ein erhöhtes Sicherheitsrisiko dar.
4.2.3 SOA mit Web Services
Die wohl einfachste Möglichkeit, eine SOA zu implementieren, sind Web Services.
Obwohl wieder angemerkt werden sollte, dass Web Services nicht mit SOA gleichzustellen
sind (vgl. hierzu Abbildung 6). Eine Ansammlung von Web Services ist noch lange keine
SOA. Erst eine entprechend grobe Granularität, Wiederverwendbarkeit, Ausrichtung an
Geschäftsprozessen und die Möglichkeit die Web Services zu orchestrieren [Felbeck1]
führt zu einer SOA.
- Seite 11 -SOA-Architektur
Abbildung 6 - Web Services und SOA mit Web Services [Rausch1]
Der Nachrichtenaustausch bei Web Services erfolgt XML-basiert mit Hilfe von SOAP,
welches über http transportiert werden kann. Damit kann die Firewall die Nachrichten ohne
Probleme sniffen und es muss kein weiterer Port geöffnet werden, da die Kommunikation
über Port http/80 läuft. Es sei allerdings angemerkt, dass die Verarbeitung bzw. das Parsing
von SOAP-Messages zeitintensiv und somit mit Abstrichen in der Performance gegenüber
CORBA und RMI zu rechnen ist.
Durch die WSDL gibt es eine standardisierte, plattform- und
programmiersprachenunabhängige Schnittstellenbeschreibungsspssprache. Mit UDDI
lassen sich Web Services in einem zentralen Verzeichnisdienst bereitstellen und wieder
finden. WSDL-Dateien und SOAP-Messages reichen für die Implementierung von Services
nicht aus. Die darunter liegende Funktionalität kann allerdings mit verschiedensten
Technologien bzw. Programmiersprachen wegen des offenen Standards und der
Programmiersprachenunabhängigkeit. Einsetzbar wären bspw. J2EE oder .NET.
Für Java und J2EE gibt es mehrere Möglichkeiten Business Logic als Web Services
bereitzustellen und zu verarbeiten: z.B. das Java Web Service Developer Pack, welches
von Sun zur Verfügung gestellt wird und SOAP, UDDI und WSDL unterstützt. Mit
Apache Axis steht ein Open-Source-Projekt für die Entwicklung von Java Web Services
bereit. Ein weiteres Projekt ist Apache Beehive. Dies ist ein Framework, das die Integration
von Java Web Services unterstützt.
ASP.NET eröffnet ähnliche Möglichkeiten wie die drei vorgestellten Möglichkeiten für
J2EE.
Der alleinige Einsatz von Web Services reicht für manche Problematiken nicht aus. So
kann man z.B. keine Datenformate umwandeln oder Altsysteme mit unterschiedlichen
Protokollen einbinden. Hierzu bedarf es einer weiteren Komponente, dem Enterprise
Service Bus (ESB). Näheres hierzu folgt im nächsten Kapitel (4.3).
- Seite 12 -SOA-Architektur
4.3 Enterprise Service Bus
Der Enterprise Service Bus (ESB) dient als Infrastruktur, der die serviceorientierten
Lösungen zum Laufen bringt und die Kommunikation der Dienste in einer SOA
ermöglicht. Er ist prinzipiell vergleichbar mit dem Bussystem in einem PC, ohne ihn gäbe
es einen riesigen Kabelsalat. Der ESB übernimmt dabei nicht nur Transport und Mediation
der Daten, sondern ist auch zuständig für viele andere Tätigkeiten. Er ist z.B. zuständig für
das Lokalisieren von Services. Ein Benutzer muss nicht wissen welcher Service seine
Aufgabe erledigen kann, sondern nur, dass es ich gibt. Der ESB übernimmt auch das
Weiterleiten der Aufgabe an den lokalisierten Dienst. Der Vorteil hiervon liegt auf der
Hand. Jeder Service kann jederzeit durch einen anderen/neuen Dienst ausgetauscht werden.
Die einzelnen Service-Schnittstellen müssen nicht zwingend kompatibel zueinander sein,
da der ESB hier eine Übersetzung ausführen kann. Er ist programmiersprachen- und
plattformunabhängig, so dass bspw. Java und .NET Applikation miteinander
kommunizieren können. Zum weiteren Funktionsumfang des ESB gehören folgende
Punkte:
• Routing und Umformen von Nachrichten
• Verschlüsselung
• Quality of Service
• Koordination der Geschäftsprozesse
• Unterstützung verschiedener Interaktionsformen (synchron und asynchron)
Abbildung 7 - Enterprise Service Bus (Quelle: IBM)
- Seite 13 -Einsatzmöglichkeiten einer SOA
5 Einsatzmöglichkeiten einer SOA
Das Haupteinsatzgebiet von SOA liegt im Business Process Management (BPM).
Normalerweise besteht eine Applikation aus dem Sourcecode für die Implementierung von
Business-Funktionalität (z.B. „Bestellung aufgeben“) und dem Sourcecode, der den
logischen „Flow“ der Applikation entsprechend der jeweiligen
Unternehmensanforderungen abbildet. Im Falle einer Änderung der
Unternehmensanforderungen muss der Sourcecode (meistens der „Flow“-Sourcecode)
angepasst werden. Selten muss die Implementierung der Business-Funktionalität selbst
geändert werden.
Mit der Einführung der Business Processes hat sich die Vorgehensweise für die
Entwicklung von Applikationen geändert. Durch eine Business Process Engine ist eine
Applikations-Architektur möglich, bei der Implementierung der Business-Funktionalität
von der „Flow“-Logik (Business Logic) getrennt wird. Das Resultat ist eine Business-
Process basierte Applikation, bei der der Ablauf durch ein Business Process Management
System gesteuert wird. Dieses System ist zuständig für den Aufruf der Business-
Funktionen entsprechend der Business Logic.
Durch den serviceorientierten Ansatz wird ein Prozess durch mehrere Services abgebildet.
Jeder Service ist lose gekoppelt und somit jederzeit austauschbar und erweiterbar.
6 SOA-Anbieter
Mehrere kommerzielle Anbieter setzen voll auf SOA. Obwohl SOA kein Produkt ist, wird
es als solches verkauft. Dieses Kapitel soll einen kleinen Einblick in die Interpretation von
SOA einiger großer IT-Unternehmen gewähren und zeigen wie bei diesen SOA umgesetzt
wird.
6.1 IBM
Bei IBM werden Anwendungen innerhalb einer serviceorientierten Architektur als Services
aufgefasst. Diese Services können beliebig zusammengesetzt und gemischt werden, sodass
sie schnell neue Geschäftsprozesse abdecken. IBM sieht eine serviceorientierte Architektur
als ein Mittel, um dem Geschäft eines Unternehmens die vom Markt geforderte Flexibilität
zu ermöglichen. Für die Einführung einer SOA bietet IBM sowohl Produkte,
Beratungsleistungen und eine Partner-Community an. Auf Produktseite ist als
prominentester Vertreter die IBM-WebSphere-Produktlinie zu nennen mit leistungsfähigen
Funktionen zur Anwendungsintegration. IBM orientiert ihr Produktportfolio für die
Erstellung und Verwaltung von SOA-basierten Anwendungen am Lebenszyklus der
Services. Dabei teilt IBM die Entwicklung einer SOA in die Stadien Model, Assemble,
Deploy und Manage auf. [ENTW1]
Der WebSphere Process Server fungiert als SOA-Integrations-Plattform. Der Process
Server kann benutzt werden, um Business-Process-Applikationen in einer SOA
- Seite 14 -Fazit
auszuführen. WebSphere Integration Developer (WID) wird zur Entwicklung solcher
Applikationen verwendet.
6.2 SAP
SAP bietet mit der NetWeaver-Plattform eine SOA-Lösung an, die einen umfangreichen
Funktionsumfang aufweist. SAP NetWeaver ist die technologische Weiterentwicklung der
ERP-Lösung. Die Vision einer serviceorientierten Architektur sieht SAP in der
NetWeaver-Plattform verwirklicht [ENTW1].
SAP unterscheidet zwischen Web Services und Enterprise Services. Enterprise Services
bezeichnen Web-Services, die Business-Funktionalität enthalten. Sie können aus mehreren
Web Services zusammengesetzt sein. Diese Enterprise Services stellen zusätzlich eine
Qualität of Service für die Business-Funktionalität zur Verfügung wie z. B. Security,
Skalierbarkeit oder Managebarkeit.
6.3 BEA
BEA definiert eine serviceorientierte Architektur als eine IT-Strategie, die die vorhandene
Geschäftsfunktionalität von Anwendungssystemen in eine Menge von interoperablen,
standardbasierten Services reorganisiert. Diese Services können zur Erfüllung der
Geschäftsziele problemlos kombiniert und wieder verwendet werden. IT wird nicht mehr in
Form von Anwendungssystemen gedacht, sondern als Services. Die Komplexität der
Anwendungssysteme wird hinter den Service-Schnittstellen verborgen. [ENTW1]
7 Fazit
Meiner Meinung nach ist SOA ein sehr interessanter Ansatz. Durch die Serviceorientierung
ist die Entwicklung neuer Applikationen einfacher geworden. Sie erleichtert zudem die
Beherrschung komplexer verteilter Applikationen und durch die lose Kopplung ist die
Erweiterbarkeit des Systems auch kein großer Aufwand.
SOA ermöglicht das Bauen von Enterprise-Software, die unabhängig von Sprachen,
Systemen und Technologien ist. Dieser Ansatz wird sich deshalb in den nächsten Jahren
etablieren. Die Unternehmen werden nach und nach die Vorteile einer SOA erkennen und
versuchen, diese umzusetzen.
Allerdings ist zu beachten, dass der Aufbau einer SOA kein leichtes Unterfangen ist. Eine
SOA kann man nicht schnell kurz umsetzen, da eine detaillierte Planung erforderlich ist.
Man muss sich nämlich nicht nur auf die technischen Lösungen konzentrieren, sondern ein
Umdenken auf Management- und Mitarbeiterebene ist ebenso erforderlich. Es gibt dann
nicht mehr die eine Kundenverwaltung, sondern mehrere Services/Komponenten, die die
Gesamtaufgabe übernehmen.
- Seite 15 -Fazit
Tabellenverzeichnis
Tabelle 1 - Vergleich zwischen Services, Komponenten und Objekten [Reich1]................. 5
Abbildungsverzeichnis
Abbildung 1 - Zusammenhang zwischen Services, Komponenten und Objekten
[JavaMag1] .................................................................................................................... 5
Abbildung 2 - Das Service-Dreieck [Dapeng]....................................................................... 6
Abbildung 3 - Die vier Dimensionen einer SOA [WeyBeck1] ............................................. 8
Abbildung 4 - SOA-Architektur-Stack [ENTW1]................................................................. 9
Abbildung 5 - SOA-Schichtenmodell [WeyBeck1] ............................................................ 10
Abbildung 6 - Web Services und SOA mit Web Services [Rausch1] ................................. 12
Abbildung 7 - Enterprise Service Bus (Quelle: IBM) ......................................................... 13
- Seite 16 -Literaturverzeichnis
8 Literaturverzeichnis
[AJAXW1] Best Practices For Building SOA Applications, Online Ressource
http://ajax.sys-con.com/read/275111.htm
(Abruf 05.10.2006)
[BIEN1] Adam Bien: Das XML der Komponenten, Java Magazin, 2004, Heft 11
[Dapeng] Dapeng Wang, Wo ist mein Web Service?, Java Magazin, Ausgabe
12/2003
[ENTW1] Entwickler Magazin, Ausgabe 3/06, S. 107
[JavaMag1] SOA konkret: Service Orientierte Architekturen J2EE-Projekte. Java
Magazin, 2004, Heft 11
[KrJa2003] Kraushaar und Jander, Web-Services – Die Technologie der Zukunft,
Online Ressource
http://www.informatik.fhmuenchen.de/~erik/labor/cim/Seminare/ws02/T
hema06_Praesentation.pdf
(Abruf 07.10.2006)
[Rausch1] Till Rausch, Service Orientierte Architektur und Einordnung, 2006,
Online Ressource
http://www.till-rausch.de/assets/baxml/soa_akt.pdf
(Abruf 05.10.2006)
[Reich1] Christoph Reich, Folien Veranstaltung „XML & Web Services“, 2005
[SACOM] Online Ressource
http://www.service-architecture.com/web-services/articles/service-
oriented_architecture_soa_definition.html
(Abruf 04.10.2006)
[Voelter1] Markus Voelter, Services, Komponenten und Modelle, Objektspektrum,
Ausgabe 2/2006
- Seite 17 -Literaturverzeichnis
[WeyBeck1] Weyerhäuser und Becker, Enterprise SOA, Javaspektrum, Ausgabe
4/2005
[Zimm1] Olaf Zimmerman et al., Elements of Service-Oriented Analysis and
Design, IBM Developer Works, Juni/2004
- Seite 18 -Sie können auch lesen
