Ausarbeitung für das Seminar Aktuelle Themen der Informatik. Thema: Serviceorientierte Architekturen (SOA)

Transkript

1 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.: St. Georgen, den 14. Oktober 2006

2 Einführung Inhaltsverzeichnis 1 Einführung Allgemeines zu SOA Begriffserklärung Gründe für eine SOA Was ist ein Service? Merkmale einer SOA Bestandteile und Rollen in einer SOA Lebenszyklus eines Service SOA-Architektur Komponenten einer SOA Aufbau einer SOA SOA mit CORBA SOA mit RMI SOA mit Web Services Enterprise Service Bus Einsatzmöglichkeiten einer SOA SOA-Anbieter IBM SAP BEA Fazit Literaturverzeichnis Seite 2 -

3 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 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 -

4 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 -

5 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 Kommunikationszweck Innerhalb Applikation Innerhalb Applikation Tabelle 1 - Vergleich zwischen Services, Komponenten und Objekten [Reich1] Innerhalb Unternehmen - Seite 5 -

6 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 -

7 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 BPEL 1 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 -

8 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 -

9 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 -

10 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 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 -

11 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 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 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 -

12 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 -

13 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 -

14 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 -

15 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 -

16 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] Abbildung 6 - Web Services und SOA mit Web Services [Rausch1] Abbildung 7 - Enterprise Service Bus (Quelle: IBM) Seite 16 -

17 Literaturverzeichnis 8 Literaturverzeichnis [AJAXW1] Best Practices For Building SOA Applications, Online Ressource (Abruf ) [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 hema06_praesentation.pdf (Abruf ) [Rausch1] Till Rausch, Service Orientierte Architektur und Einordnung, 2006, Online Ressource (Abruf ) [Reich1] Christoph Reich, Folien Veranstaltung XML & Web Services, 2005 [SACOM] Online Ressource (Abruf ) [Voelter1] Markus Voelter, Services, Komponenten und Modelle, Objektspektrum, Ausgabe 2/ Seite 17 -

18 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/ Seite 18 -