Hochschule Furtwangen. Seminar Aktuelle Themen der Informatik. Ausarbeitung Service Orientierte Architekturen

Transkript

1 Hochschule Furtwangen Seminar Aktuelle Themen der Informatik Ausarbeitung Service Orientierte Architekturen Andreas Fink, CN8 Datum:

2 Einführung... 3 Definition...3 SOA: Bestandteile und Rollen... 4 Enterprise Service Bus...6 Zusammenhang Services, Komponenten, Objekte...7 Technologische Abgrenzungen... 8 Abgrenzung SOA und Web Services...8 Abgrenzung SOA und CORBA...9 Abgrenzung SOA und J2EE...9 Produkte...10 Fazit... 11

3 Einführung Definition Die beste Definition der SOA, meiner Meinung nach: "Service Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocol-independent distributed applications composed from well-defined, selfcontained 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. Des Weiteren trifft Folgendes einer SOA zu: SOA ist ein Software Design Ansatz SOA ist eine semantische höhere Form der Anwendungsentwicklung Zusammenbau grobkörniger Services Die Services erlauben Zugriff auf z.b. Daten, Infrastruktur (z.b. CMS), Geschäftsprozesse (z.b. ERPs, CRMs) Services einer SOA kommunizieren miteinander Service-Schnittstellen sind standardbasiert Im Vordergrund einer SOA steht jedoch stets der Anspruch, das originäre Geschäft eines Unternehmens mittels IT bestmöglich zu unterstützen. Abstraktion der Business Prozesse von Applikationen mittels Service [5]

4 Das Spannungsfeld zwischen der Abhängigkeit von der IT einerseits und deren Inflexibilität gegenüber Änderungen andererseits führt zu akutem Handlungsbedarf. An diesem Punkt setzt SOA mit seinen IT-bezogenen Zielen Flexibilisierung, Komplexitätsreduktion und Kostenreduktion an. Die Folge sind sinkende Unterhaltskosten, steigende Kapazität für Weiterentwicklung und kürzere Reaktionszeiten zur Umsetzung von Änderungen oder Neuerungen. Die serviceorientierte Systemarchitektur erleichtert maßgeblich den Aufbau und die Umsetzung von flexiblen Geschäftsprozessen und schafft damit eine Voraussetzung für eine schnelle Anpassung der Unternehmensstrategie an die nationale oder internationale Marktentwicklung. Dabei können sowohl interne wie externe Prozesse entlang der Wertschöpfungskette einfacher angepasst werden. Selbst komplexe Geschäftsprozesse lassen sich durch Aneinanderreihung von Service-Aufrufen einzelner Funktionen abbilden. In einem Top-Down-Ansatz werden aus in dem Business Prozess Layer beschriebenen Geschäftsszenario heraus Elemente einer serviceorientierten Architektur identifiziert und abgeleitet. SOA: Bestandteile und Rollen Eine SOA besteht aus Softwarekomponenten die drei fundamentale Rollen annehmen: Service Provider: Implementiert Service Service Consumer: Benutzt Service Service Broker: Veröffentlicht und erlaubt Suche Service-Consumer, -Provider, -Broker, [6] Service Provider Dabei entsprechen die Service Provider den Dienstleistern. Ein Dienstleister kann entweder eine Softwarekomponente oder ein Dienst-anbietendes Unternehmen sein. Dies

5 hängt im Wesentlichen von der aktuellen Sicht auf die Architektur ab. Ein Service Provider stellt somit im Allgemeinen eine Funktionalität oder eine Ressource und eine korrespondierende Beschreibung zur Verfügung. Die Beschreibung entspricht dabei einem Vertrag (contract). Dieser Vertrag beschreibt die Art und Weise der Interaktion mit dem Dienst (Schnittstellenbeschreibung) und kann darüber hinaus noch weitere Informationen enthalten, die nicht an die konkrete Funktionalität gebunden sind (nichtfunktionale Aspekte). Registry Die (Service) Registry ist eine (de-)zentrale Registrierung für die angebotenen Dienste. Service Provider registrieren ihre Dienste bei einer Registrierung mithilfe eines Vertrags (service interface). Eine Registrierung kann dabei unterschiedlich ausgelegt sein. So sind Konzepte wie Verzeichnis-artige Registrierungen á la UDDI gerade im Bereich der Web Services weit verbreitet (siehe Verfahren Methode/Technik WebServices UDDI). Eine derartige Registrierung ist passiv, sie kann nur Aufträge von Service Providern entgegennehmen (registrieren, updaten, löschen eines Dienstes) oder Anfragen von potenziellen Clients (suche nach Dienstangebot) entgegennehmen. Aaktive Registrierungen stellen eine weitere Möglichkeit dar, die neben den Aufgaben einfacher Registrierungen weitere komplexe Aufgaben wahrnehmen können. Zu nennen sind hier Konzepte, wie sie beispielsweise in ODP (Open Distributed Processing) mithilfe von Tradern beschrieben werden. Weitere Aufgaben der Registrierungen sind Kategorisierung und Katalogisierung sowie Priorisierung und Ranking. Service Consumer Service Requestoren sind mit Clients üblicher Client/Server-Architekturen, z.b. aus dem Bereich der betrieblichen Informationssysteme, vergleichbar. Sie kennen lediglich eine (oder mehrere) Registrierung(en), an die sie Suchanfragen nach bestimmten Dienstleistungen stellen können. Die Dienstvermittlung erfolgt dann auf der Basis der registrierten Verträge, die in der Registrierung abgelegt sind. Analog zu Client/Server- Architekturen ist die Diensterbringung für den Client transparent und hinter einer Schnittstelle versteckt. Zusammenhang der SOA Elemente

6 Enterprise Service Bus Der Enterprise Service Bus (ESB) soll die technologische Basis für die Einführung von SOAs in Unternehmen bilden. Er stellt Basisfunktionalität zur Verfügung, damit Dienste in einer SOA miteinander kommunizieren können und einfache Dienste ohne großen Entwicklungsaufwand zu komplexen Diensten kombiniert werden können. Dies umfasst zum Beispiel den Aufruf von Diensten, inklusive Routing, das Umformen von Nachrichten, Verschlüsselung, Quality of Service und auch Management-Funktionalität. Ein ESB bietet also ähnliche Funktionalität wie traditionelle EAI- (Enterprise Application Integration) Lösungen, allerdings mit einer besonderen Ausrichtung auf SOAs. Die Abbildung unten zeigt als Beispiel eine SOA, die für die Integration und Mediation eines Multi-Channel-Prozesses im Finanzhandel genutzt wird. Diese Implementierung stellt eine Kombination aus bestehenden Systemen, die mit einer Services-Schnittstelle "verpackt" sind, und neuen Diensten dar, die zur Verbesserung des Geschäftsprozesses erzeugt wurden. Das Beispiel verdeutlicht, wie die Datenelemente eines Auftrags im Wertehandel aus einem Order Management Service so umgewandelt werden, dass sie den Anforderungen des Trading und Compliance Services entsprechen. Im weiteren Prozessablauf wird ein Trigger für einen Geldtransfer vom Funds Transfer Service angestoßen und der Auftrag schließlich als ausgeführte Transaktion im Logging Service abgelegt. Der Trade-Prozess wird nicht als integrierte Anwendung ausgeführt, sondern als eine Sequenz von heterogenen Prozessschritten, die von der SOA-Infrastruktur koordiniert werden. Ein ESB-Prozess Das Herzstück der SOA-unterstützenden IT-Infrastruktur ist der Enterprise Service Bus (ESB), der die gesamte Kommunikation und Interaktion zwischen den Services vermittelt und

7 zusammenfügt. Im vorgestellten Beispiel liefert der ESB die Konnektivität einschließlich des Routings zwischen den Diensten, die Umwandlung der XML-Daten, um die Kommunikation zwischen Services mit unterschiedlichen Schnittstellen zu ermöglichen, und die Abfolge der Dienste für den Geschäftsprozess. Zusammenhang Services, Komponenten, Objekte Nach [8] beschäftigt sich SOA mit Entwurf, Implementierung, Deployment, Wiederverwendung, vereinfachter Verwendung, und Suche nach Services. Danach schildert [8] Services vereinfachen den Zugriff auf die Logik eines Objekts, einer Komponente oder einer Anwendung. Diese Zusammenhänge werden nochmals sehr gut in einer Grafik veranschaulicht: [4]

8 Technologische Abgrenzungen Der SOA Design Ansatz ist technologieunabhängig, kann also durch die Wahl unterschiedlicher Technologien umgesetzt werden. An dieser Stelle soll nun angerissen werden welche Technologien oft im Zusammenhang mit SOA genannt werden. Dabei wird erneut auf häufige Unschärfen der Diskussion hingewiesen. Abgrenzung SOA und Web Services Web Services sind lose gekoppelt und mit der Web Services Description Language (WSDL) existiert darüber hinaus eine standardisierte Schnittstellenbeschreibung von Webservices. Gartner führt dazu aus: Web services WSDL is an SOAsuitable interface definition standard: that is where Web services and SOA fundamentally connect. Halten wir also fest, dass sich Web Services gut zum Aufbau einer SOA eignen. Im Umkehrschluss jedoch führt die Nutzung von Web Services keinesfalls automatisch zu einer SOA. Erst eine entsprechend grobe Granularität, Wiederfindbarkeit, Ausrichtung an Geschäftsprozessen und die Möglichkeit die Web Services so zusammenstellen (orchestrieren) zu können, dass ein Geschäftsprozess abgebildet wird, führt zu einer SOA. Web Services sind nicht gleich SOA [6] Diese Unterscheidung wird oftmals nicht getroffen und führt zu Verwirrung. Der bereits erwähnte Gartner Artikel [9] der SOA als Revolution bezeichnet, nennt SOA und Web Services in einem Zug. [10] schreibt Web Services basieren auf einer Service Oriented Architecture und weiter SOA = Modell bei dem drei verschiedene Rollen unterschiedliche Interaktionen auf einem Web Service durchführen.

9 Die Verwendung von Web Services zum Aufbau einer SOA muss anhand des konkreten Einsatzgebiets untersucht werden, denn Web Services sind teuer, wenn man Performanz braucht. Web Services benutzen Text für den Datentransfer (HTTP Protokoll), binäre Protokolle wie sie CORBA oder Java-RMI verwenden sind schneller: das zu transportierende Datenvolumen ist wesentlich geringer. Es muss kein Parcing der Textdokumente gemacht werden. [7]. Abgrenzung SOA und CORBA [7] beschäftigt sich etwas detaillierter mit der Abgrenzung CORBA / SOA, speziell mit der Frage, warum CORBA nicht sehr häufig als geeignete Technik für den Aufbau einer SOA genannt wird, obwohl dies vom technischen Standpunkt aus möglich wäre. Der Autor geht davon aus, dass Service-Provider, -Requestor und Broker ebenso mit CORBA implementiert werden können. Mit der Interface Definition Language (IDL) bietet CORBA beispielsweise eine standardisierte Schnittstellenbeschreibungs-Sprache, mit dem Interface Repository steht ein Schnittstellen Repository zur Verfügung und durch das IDL Konzept sind CORBA Objekte sogar sprachunabhängig. Als Hauptgründe für die geringe Nutzung von CORBA für den Aufbau einer SOA nennt [7] folgende Gründe: Die Verwendung des neuen CORBA-spezifischen Protokolls IIOP anstatt dem bereits etablierten HTTP-Protokoll. Die bis zu CORBA 3 nicht erfolgte Standardisierung des IIOP Ports, was bei einer hohen Anzahl CORBA Kommunikationspartnern zu einer hohen Anzahl zu öffnender Ports in der Firewall führt. Die Nutzung eines binären Protokolls welches in der Firewall nicht gesnifft werden kann. Die unzureichende Spezifikation des CORBA Basic Object Adapters in den ersten CORBA Spezifikationen, was zu herstellerspezifischen Implementierungen und schließlich zu einer eingeschränkten Interoperabilität zwischen den Object Request Brokern (ORB) unterschiedlicher Hersteller führte. Diese Nachteile kommen jedoch hauptsächlich in unternehmensübergreifenden Kommunikation zum Tragen weshalb innerhalb des Unternehmens eine CORBA Implementierung durchaus in Betracht gezogen werden kann. Vor allem wenn hohe Performanz und Sprachunabhängigkeit gefordert ist, scheint CORBA Vorteile gegenüber einer Web Service (Performanz) oder J2EE (Sprachunabhängigkeit) Implementierung zu besitzen. Abgrenzung SOA und J2EE Eingangs wurde bereits erwähnt, wie Java Objekte, Java Komponenten und SOA Services zusammenhängen können. Java Objekte bilden fein granulare Funktionalität ab, Java Komponenten werden als Java Enterprise Beans (Entity-, Session- oder Message Driven Bean) implementiert und bilden etwas höher granulierte (Teil-) Geschäftsprozesse ab. SOA Services wiederum decken die höchste Granularität ab, realisieren umfassende Geschäftsprozesse und können z.b. durch Zusammenstellung von Java Komponenten implementiert werden. Für Entwicklung von Geschäftsprozessen durch das zusammenstellen von SOA Services, die wiederum auf Java Komponenten zugreifen, sowie für die dafür notwendigen Schnittstellenbeschreibungen gibt es in Java keinen Standard. BEA jedoch hat ein Framework für die Implementierung SOA konformer Services mit Java oder Web Services entwickelt und der

10 Apache Software Foundation übergeben. Dieses Open Source Projekt namens Beehive erweitert z.b. die Java Annotations, so dass die Schnittstellen der Java Enterprise Beans und Java Objekte mit Meta-Daten angereichert werden wie es für SOA Services unabdingbar ist. Darüber hinaus wird beim Service Design noch nicht entschieden ob die Services durch Java Komponenten oder Web Services implementiert werden. Diese Entscheidung fällt zu einem späteren Zeitpunkt und beide Wege werden durch Beehive unterstützt. Siehe dazu [7] und [8]. Die populäre Java IDE eclipse unterstützt Beehive massiv, es ist absehbar, dass sich dieses Konzept zu einem de-facto Standard entwickelt. Das Wiederauffinden von Services schließlich lässt sich mit Java Technologien umsetzen, wie beispielsweise dem Java Naming and Directory Interface (JNDI). Produkte Da SOA an sich kein Produkt ist, liste ich hier Produkte auf, die als Basis zur Implementierung einer SOA dienen könnten: SAP NetWeaver JBoss JEMS Oracle Application Server BEA WebLogic

11 Fazit Abschließend soll nun zusammengefasst werden, was unter einer SOA gemäß den Quellen der Fachwelt derzeit verstanden wird. Hierfür wird der bereits geschilderte Zwischenstand mit den Erkenntnissen der letzten Kapitel angereichert: In einer SOA stehen Geschäftsprozesse im Vordergrund Geschäftsprozesse können in einer SOA durch die Zusammenstellung von Services abgebildet werden, diese Zusammenstellung erfolgt mit standardisierten Darstellungsformen, wie beispielsweise BPEL für eine Implementierung der SOA Services durch Web Services oder BPELJ für eine Implementierung durch Web Services und Java Komponenten. SOA Service Schnittstellen werden durch eine standardisierte Darstellung beschrieben. Dies erfolgt je nach gewählter Technologie für die Umsetzung, beispielsweise durch WSDL (Web Services), IDL (CORBA) oder durch spezielle Java Annotations kombiniert z.b. mit der Signatur von Enterprise Java Beans. SOA Services sind grob granuliert, können durch Altanwendungen oder Web Services oder Komponenten implementiert sein oder einer Zusammenstellung dieser Bausteine. Services können nach einer Vielzahl Kriterien klassifiziert werden. Eine SOA ist geschwätzig, Technologien für Daten- und Nachrichtenaustausch werden für den Aufbau einer SOA eingesetzt.

12 Quellen: [1] Titelthema: Service-Orientierte Architekturen; Java Spektrum; 4/2005; [2] Artikel Serviceorientierte Architektur. In: Wikipedia, Die freie Enzyklopädie. URL: itektur&oldid= (Abgerufen: 22. April 2006, 10:47 UTC) [3] Dirk Krafzig; Karl Banke & Dirk Slama: Entrprise SOA: Service Oriented Architekture Best Practices. Prentice Hall, 2005 [4] SOA konkret: Service Orientierte Architekturen J2EE-Projekte. Java Magazin, 2004, Heft 11 [5] MSDN Library, SOA (Service Oriented Architekture) URL: ceorientedarchitecture.mspx (Abgerufen: 21. April 2006, 10:47 UTC) [6] Thomas Walter & Peter Soth; Service Orientierte Architekturen mit BEA WebLogic [7] Andreas Ullmann: Was sich hinter SOA verbirgt Lego für Fortgeschrittene, Java Magazin, 2004, Heft 10. [8] Adam Bien: Das XML der Komponenten, Java Magazin, 2004, Heft 11 [9] Charles Abrams, Whit Andrews: Service Orientation Catalyzes Latest Software Revolution, Gartner Research Note G , 2004 [10] Wolfram Kraushaar, Tanja Jander: Web Services Die Technologie der Zukunft?, URL: /Thema06_Praesentation.pdf,(Abruf )