EAI und Web Services

Transkript

1 EAI und Web Services Seminararbeit Für das Seminar aus Informationswirtschaft (3230) im WS 2002/03 Leitung: o. Univ. Prof. Dkfm. Dr. Wolfgang H. Janko Univ.-Ass. Mag. Dr. Michael Hahsler Von Hans Berr ( ) 1

2 Inhaltsverzeichnis: Seite Stichworte / Keywords 3 Zusammenfassung / Abstract 3 Kernpunkte für das Management 4 1. Einleitung 4 2. Was verbirgt sich hinter Web Services 5 3. Berichte aus der Praxis Neuer Webauftritt des ADAC Microsoft.NET in der Versicherungsbranche Content Flow mit direktem Zugriff auf das SAP System Web Services mit.net und J2EE Die Beschreibung von Web Services Die Implementierung von Web Services Web Services publizieren, aufspüren und einbinden Web Services abrufen und ausführen Ausblick 13 2

3 EAI und Web Services EAI and Web Services Stichworte: Web Services, SOAP, UDDI, WSDL, WS-Coordination, WS-Transaction, WS- Security, Business Process Execution Language for Web Services,.NET, J2EE Keywords: Web Services, SOAP, UDDI, WSDL, WS-Coordination, WS-Transaction, WS- Security, Business Process Execution Language for Web Services,.NET, J2EE Zusammenfassung Der vorliegende Artikel stellt die Struktur und die Möglichkeiten von Web Services dar und wie dadurch neue Möglichkeiten für eine Enterprise Application Integration entstehen. Beleuchtet werden derzeitiger Stand und mögliche Entwicklungen dieser neuen offenen Architektur. Dies versuche ich durch Darstellung der Standards und mit Hilfe von Berichten über Unternehmen, die bereits eine erfolgreiche Implementierung Web basierender Plattformen durchgeführt haben. Den Abschluss meiner Arbeit bildet ein Ausblick auf zukünftige Entwicklungen der Web Services Standards. Abstract This paper describes the structure and possibilities of the fairly new Web Services and the given possibilities for Enterprise Application Integration. The goal is to show the actual standards and the future perspective of this open architecture. I will present the standards of Web Services and articles about enterprises which already implemented Web Services architecture very successfully. At the end of my article I will give you the latest development of Web Services standards and their future development. 3

4 Kernpunkte für das Management Dieser Beitrag soll den derzeitigen Stand der Web-Services Technologie darstellen. Aufgezeigt werden die bereits bestehenden Vorteile, aber auch die noch zu lösenden Probleme. Vorteile: Web basierende Technologie garantiert Einfachheit und somit großes Kosteneinsparungspotential. Nachteile: Sehr junge Technologie und daher noch nicht ausgereift, speziell die Sicherheitsproblematik des Internets muss noch gelöst werden. 1. Einleitung In letzter Zeit macht eine neue Entwicklung von sich reden, von der sich die Fachwelt eine Revolution auf dem Gebiet der Enterprise Application Integration erhofft. Diese Technologie nennt sich Web Services und alle Namhaften Softwarehäuser möchten zu den führenden Entwicklern auf diesem Gebiet zählen. In diesem Beitrag möchte ich den derzeitigen Stand der Entwicklung darstellen und auch zukünftige Entwicklungstendenzen aufzeigen. Dabei möchte ich auf die Standards, die Sicherheitsproblematik und die verschiedenen Lösungsansätze von IBM mit J2EE und Microsoft mit den.net Produkten eingehen. Ein Kapitel stellt die bisherigen Erfahrungen des ADAC, des Alten Leipziger Unternehmensverbunds und der Softwareschmiede projoin mit der Web Services Technologie dar. Alle diese Berichte werden zeigen, dass diese Technologie nicht nur im Stande sein wird Applikationen Betriebsystemübergreifend zu verbinden sondern darüber hinaus, aufgrund der Einfachheit und Offenheit in der Lage sein wird Kosten einzusparen. Da die Web Services allerdings noch in den Kinderschuhen stecken und somit weder eine große Anzahl von Unternehmungen diese implementiert haben, noch in einer Unternehmung eine bereits länger umgesetzte Lösung für EAI darstellen, lässt sich derzeit nur vermuten in welchen Bereichen und in welcher Höhe Einsparungen lukriert werden können. 4

5 2. Was verbirgt sich hinter Web Services Worin liegen nun die Vorteile von Web Services gegenüber all den EAI Technologien, die in den vorigen Kapiteln erläutert wurden? Ein großer Vorteil der Web Services ist, wie ihr Name schon vermuten lässt, dass sie auf der Technologie des world wide web aufbauen. Durch die Verwendung von Standard XML Protokollen und Formaten ist es erstmals möglich eine Anbieter Unabhängigkeit zu erreichen. Dies öffnet neue Möglichkeiten für die in großen Unternehmen angesiedelten EDV Abteilungen. Die Anwendungen sind dadurch nicht nur leichter zu entwickeln sondern auch die Wartung und Erweiterung ist innerhalb eines Unternehmens wieder leichter möglich. Web Services eliminieren die Interoperabilitätsprobleme der bestehenden Lösungen wie zum Beispiel CORBA, durch die Verwendung offener Internetstandards wie: Web Services Description Language (WSDL): als Sprache Universal Description, Discovery and Integration (UDDI): als Informationsfinder Simple Object Access Protocol (SOAP): als Übertragungsprotokoll Web Services Flow Language (WSFL): zur Definition der work flows 2.1 Das technologische Konzept der Web-Services WSDL (Web Services Description Language) Die auf XML basierende WSDL ist der Standard mit dem alle fundamentalen Merkmale der Web Services beschrieben werden. Aus dieser Beschreibung muss das verwendete Protokoll, die Adresse, die Portnummer, die möglichen Formate, Prozeduren und Funktionen für Eingabe und Ausgabe hervorgehen. Eine standardisierte Beschreibung ist unabdingbar um zu gewährleisten, dass sich die verschiedenen Web Services erkennen und verstehen können. Aufgrund der Tatsache, dass gerade die Verbindung mehrerer Applikationen die wesentlichen Vorteile der Web Services darstellen, bildet WSDL die Basis für die Ermöglichung der Dienste dar UDDI (Universal Description, Discovery and Integration) Um das gegenseitige Verstehen der Applikationen überhaupt erst zu ermöglichen, ist es notwendig, dass sich die Dienste im Internet auch finden. Hierzu ist ein Verzeichnis nötig, in dem die Anbieter ihre Services anbieten können. Dies bewahrt potentielle User vor mühevollen Internet Suchroutinen. UDDI wurde von Microsoft, IBM und Ariba ins Leben gerufen und definiert auf XML basierende Standards, die die Dienste definieren. Das Verzeichnis besteht aus drei Komponenten, den white, yellow und green pages. Die white pages haben zur Aufgabe die Identifizierungsmerkmale der Anbieter wie Namen, Adressen etc.. Die Branchenzugehörigkeit, das Angebot und die Kontaktmöglichkeiten werden in den yellow pages beschrieben. In den green pages schließlich werden die von den registrierten Anbieter angebotenen Webservices 5

6 ausführlich beschrieben. Sowohl Anwender als auch verschiedene Web Services können das Verzeichnis durchsuchen, um die Dienste aufzufinden und zu vergleichen SOAP (Simple Object Access Protocoll) Wenn nun einmal der gesuchte Web Services ausfindig gemacht wurde muss dieser auch aufgerufen werden können. Hier ist SOAP das geeignete Protokoll. Es handelt sich dabei um einen, auf dem XML Protokoll aufbauenden Standard für das Versenden und Empfangen von Nachrichten. Schnelle Verbreitung findet SOAP nicht nur durch die mögliche einfache Implementierung sondern auch durch die Herstellerund Plattformunabhängigkeit. SOAP, WSDL und UDDI bilden also die Technologie, die es ermöglicht eine hersteller- und plattformunabhängige Kommunikation zwischen verschiedensten Applikationen zu gewährleisten. Somit können Web Services auf allen beliebigen Betriebssystemen und mit verschiedenen Programmiersprachen verwendet werden. Es ist daher möglich, in einer Windows-Anwendung auf einen Web Service zuzugreifen, der unter Linux implementiert und betrieben wird. Die hierfür erforderliche Schnittstelle ist WSDL. Dies bedeutet, dass die Applikation Integration auf Basis der Web Services den Beginn einer Technologie darstellt. Sobald die derzeit noch bestehenden Sicherheitsprobleme gelöst sind steht einer Vernetzung von Unternehmen nichts mehr im Wege. Wenn die Unternehmen intern bereits mit Web Services arbeiten ist dafür keine weitere Software mehr nötig. Dadurch ersparen sich diese Unternehmungen nicht nur hohe Softwarekosten sondern darüber hinaus die Implementierungskosten und lange Anlaufzeiten bis eine klaglose Kommunikation gewährleistet ist. Die folgende Abbildung (Abb. 1) zeigt wie ein Web Services Aufruf gestaltet ist: Applikation I 3 Applikation II 2 UDDI white pages yellow pages green pages 1 [Abb 1.] Abfrageschema von Web Services mit.net 6

7 1. Die Applikation II meldet dem UDDI welche Informationen abrufbar sind. 2. Die Applikation I stellt eine Anfrage an das UDDI und erhält als Antwort die Daten wo und wie die gewünschte Information bei Applikation II beschafft werden kann. 3. Die Applikation I fragt die gewünschte Information direkt bei Applikation II ab. 4. Das Übertragungsprotokoll des gesamten Datenaustausches erfolgt mittels SOAP Protokoll. 5. Die Kommunikation der einzelnen Applikationen untereinander erfolgt mittels WSDL. Nach Gunjan Samtani und Dimple Sadhwani seien als wichtigste Unterschiede zwischen traditioneller EAI Lösungen und somit als Vorteile für Web Services folgende Kriterien genannt. Dabei sind auch die zu erwarteten Entwicklungen der Web Services Technologie berücksichtigt: Einfachheit: Web Services sind viel einfacher zu entwerfen, entwickeln, warten und nutzen als bisherige typische EAI. Wenn einmal das Gerüst der Entwicklung und Nutzung der Web Services steht, wird es relativ einfach sein neue Geschäftsprozesse, die sich auf mehrere Applikationen erstrecken zu automatisieren. Offene Standards: Ungleich der gängigen EAI Lösungen basieren Web Services auf offenen Standards und dies ist mit Sicherheit der wichtigste Einzelfaktor, der zu einer weiten Verbreitung von Web Services führen wird. Flexibilität: Web Services sind nicht an Point to Point Integration gebunden, somit müssen nicht Änderungen an einem Ende zwangsläufige Änderungen an dem anderen Ende nach sich ziehen. Daher sind Web Services mit ihrer losen Verbindung zwischen der Applikation die das Service bereitstellt und der Applikation die auf den Service zurückgreift viel flexibler. Kostenfaktor: EAI Lösungen mit Message Brokern sind sehr teuer zu implementieren. Web Services können das selbe erreichen, viel schneller und billiger. Größe: Durch die Möglichkeit große Applikationen auf kleine logische Einheiten aufzuteilen erleichtern Web Services die EAI. Effizienz: Durch die Möglichkeit Applikationen auf kleinere Einheiten zu reduzieren steigt die Effizienz. Dynamik: Web Services bieten einen dynamischen Zugang zu EAI durch dynamische Interfaces wohingegen traditionelle Lösungen sehr statisch sind. Wenn eine erfolgreiche Web Services basierte EAI einmal erfolgt ist und alle derzeitig herrschenden Unzulänglichkeiten der Web Services beseitigt sind steht einer weltweiten Vernetzung nichts mehr entgegen. Für diese Vernetzung wurde der Begriff Business to Business Integration (B2Bi) gewählt. Der Markt für B2Bi ist gewaltig. Einem kürzlich erschienen Bericht der International Data Corporation Group zufolge wird B2B e-commerce im Jahre 2005 eine Größenordnung von 4,7 Billionen US $ erreichen. Die kurze Erwähnung von B2Bi soll dazu dienen aufzuzeigen, dass sich der Vorteil von Web Services nicht alleine darauf beschränkt einzelne Applikationen einer Unternehmung oder eines Konzernes zusammenzuführen sondern darüber hinaus auch noch die Entwicklung des e-commerces nachhaltig steigern wird, wie in der folgenden Abbildung dargestellt. 7

8 Abb 2. Weltweite Vernetzung [SamSad] 3. Berichte aus der Praxis In diesem Kapitel möchte ich die Vorteile der Web Services darstellen, wie sie von den Verantwortlichen der Betriebe gesehen werden, die bereits erfolgreich diese Technologie implementiert haben. Im ebusiness Report erfolgten Gespräche mit Hr. Dr. Peczynski vom ADAC, Hr. Kuhn vom Alte Leipziger Unternehmensverbund und Hr. Joachim von der Softwarefirma projoin. 3.1 Neuer Webauftritt des ADAC Seit 1997 ist der ADAC, der deutsche Automobilklub mit einer Website im Internet vertreten. Nach der Idee einer virtuellen Club- Geschäftsstelle waren die Onlineinhalte in erster Linie als Dienstleistung für Clubmitglieder gedacht und erst in zweiter Linie für die breite Öffentlichkeit bestimmt. Die Zahl der Zugriffe stieg stark an, und bald war deutlich erkennbar, dass der Provider die UNIX basierende Hardware-Installation beim Provider ausbauen muss. Im gleichen Zeitraum ist der 8

9 Webauftritt auf über Seiten angewachsen. Der Großteil der abrufbaren Informationen muss täglich erneuert werden, die Verkehrsinformationen sogar alle zehn Minuten. Die bestehende Lösung verursachte durch die zentrale Wartung der Inhalte einen sehr hohen Aufwand. In Ermangelung eigener, geeignet qualifizierter Fachkräfte war die Fachabteilung der Münchner ADAC Zentrale für die Weiterentwicklung der Site-Struktur in hohem Maße auf externe Hilfe angewiesen. Probleme mit der Stabilität Da sich während des Jahres 2000 der monatliche Seitenzugriff auf über sieben Millionen erhöhte waren bereits starke Stabilitätsprobleme an der Tagesordnung. Daher war den verantwortlichen des ADAC klar, dass für den Internet-Auftritt eine neue technische Basis erforderlich war. Ein weiterer Aspekt für eine Neugestaltung der Site war die Verbesserung des Mitgliederservice. Durch Personalisierung sollte der nur für Mitglieder zugängliche Teil der Web-Site besser auf die individuellen Bedürfnisse der Besucher adaptierbar sein. Für die Datenpflege wurde die schnelle und einfache dezentrale Erfassung der Daten als oberstes Ziel angesehen. Der Wunsch war diese Daten gleich in den Abteilungen in denen sie anfielen online stellen zu können. Auch ein Webshop war einzurichten. Seit dem Relaunch der Website haben sich die Reaktionszeiten stark reduziert, besonders zu den Hauptreisezeiten ist es jetzt schnell möglich zum Beispiel Stauberichte abzurufen. Besondere Angebote sind schon auf der Startseite zu finden und wechselt man vom Informationsteil für die Allgemeinheit zu den, den Mitgliedern vorbehaltenen Seiten erscheint ein Login Fenster in welches der Besucher seinen Namen und die Mitgliedsnummer eintragen muss. Es besteht die Möglichkeit online Mitglied zu werden und der Onlineshop bietet die Möglichkeit Reiseutensilien und ADAC-Accessoires zu bestellen. Der ADAC entschied sich für die Softwareplattform.NET von Microsoft. Der Unterschied gegenüber einer Sun/Java-basierten Lösung lag für unser Projekt bei 20 Prozent Kosteneinsparung, erklärte Dr. Peczynski, Leiter der Informationsverarbeitung beim ADAC. Grund für diese Entscheidung war die Modulbauweise dieser Softwaretechnologie, die eine leichtere Wartung und Erweiterung verspricht und so für eine hohe Wirtschaftlichkeit sorgt. Die Basis bildet der.net-fähige Microsoft Commerce Server 2000, der die Erstellung von Kundenprofilen und der damit verbundenen individuellen Ansprache von Mitgliedern erlaubt. Darüber hinaus erlaubt es ausgefeilte Suchfunktionen, bestmögliche Bestellabwicklung und Auswertungsmöglichkeiten für die verschiedenen Geschäftsvorgänge Kostensenkungen verwirklicht Obwohl die Performance gesteigert werden konnte ist es dem ADAC möglich sowohl bei den Hardware- als auch bei den Softwarekosten zu sparen und somit haben sich die erwarteten Kostenvorteile in die Praxis umsetzten lassen. Einen weiteren Beitrag zur Kostensenkung bringt die nun mögliche Pflege und Weiterentwicklung der Website durch eigenes Personal. Laut Dr. Peczynski ist aber ein indirekter Kosteneffekt entscheidend: Unser Web-Auftritt hatte von Anfang an die Aufgabe, Transaktionskosten zu reduzieren etwa bei der telefonischen Verkehrsinformation: Dort kostet ein Anruf ca. 1,50 Euro. Auf diesem Gebiet bringt uns eine stabile Internet-Präsenz mit hoher Leistung finanzielle Vorteile. 9

10 3.2 Microsoft.NET in der Versicherungsbranche Der Alte Leipziger Unternehmensverbund sieht sich als serviceorientierten Dienstleister, der auf eine vernetzte Multi-Kanal-Strategie zur Kommunikation mit Kunden, Geschäftspartnern und Mitarbeitern vertraut. Durch ein neues Vermittlerportal steht für Geschäftspartner nun ein leistungsfähiges Angebot an Information, Service und Kommunikation online bereit. Die alte Leipziger zählt mit ihren 3400 Mitarbeitern, ihrem Umsatz von 2,3 Milliarden Euro und Kapitaleinlagen von etwa 15 Milliarden Euro zu den mittelgroßen Versicherungsunternehmen und Finanzdienstleistern in Deutschland. Das Angebot umfasst Lebens-, Kranken-, und Sachversicherungen, Bauspar- und Investmentprodukte sowie spezielle Dienstleistungen wie Risikobegutachtung und Schadensprognosen. Das Ziel der neu entwickelten Anwendung Kundeninformation ist es, den Vermittlern einen Echtzeitzugang zu den operativen Systemen der Versicherung zur Verfügung zu stellen. Geschäftsabläufe wurden optimiert und ermöglichten Recherchen nach Verträgen oder Kunden und darüber hinaus lieferten sie zugehörige Bearbeitungsstände zurück. Dadurch war es der Alten Leipziger möglich eine engere Bindung der Makler, Mehrfach- und Generalagenten an das Unternehmen sowie verbesserte Kundenbeziehungen zu erreichen. Dadurch konnte die Attraktivität der Versicherung gegenüber Vermittlern gesteigert werden, da die umgesetzten Funktionen eine absolute Neuheit in dieser Branche darstellen. Diese Tatsache lässt auf Auswirkungen auf die Neukundengewinnung hoffen. Woraus setzt sich die neue Anwendung zusammen: Statusinformationen zum Stand eines Vorgangs bezieht das Portal aus einem Windows-basierten Workflow-Managementsystem: der in Zusammenarbeit mit dem Systemhaus TeamWiSE, Mönchengladbach, entwickelten Versicherungslösung Technische Anwendungsarchitektur kurz TAA. Kunden- und Vertragsdaten entstammen einem zentralen GDV-Datenpool, wobei GDV hier als Name für das standardisierte Datenaustauschformat in der deutschen Versicherungswirtschaft steht. Elektronische Dokumente, wie gescannter Schriftverkehr, Anträge oder Schadensmeldungen, aber auch Versicherungspolicen oder Provisionsabrechnungen werden als tiff-dateien in einem optischen Archiv von ixos gehalten. Mit.NET konnten wir unterschiedlichste Systeme und Plattformen sehr flexibel mit dem Vermittler-Portal koppeln. Der Entwicklungsaufwand war überraschend gering. Änderungen, die früher Tage beanspruchten, dauern heute nur wenige Stunden, fasst Michael Kuhn, verantwortlicher Software-Architekt des Alten Leipziger Unternehmensverbunds, seine bisherigen Erfahrungen mit Visual Studio.NET zusammen. 10

11 Fazit Die Verantwortlichen der Alten Leipziger Versicherung sind überzeugt, dass die.net Strategie ihren Praxis-Test bestanden hat: Die Produktivität konnte gesteigert werden, der niedrigere Aufwand für die Entwicklung und Tests für Software sparen Zeit und Kosten. Daher kann der Nuten neuer Softwarelösungen früher als bisher generiert werden. Darüber hinaus beschleunigt.net die Integration von Anwendungen und Verfahren innerhalb und zwischen externen Partnern und den Versicherungsgesellschaften. 3.3 Content Flow mit direktem Zugriff auf das SAP System Die Softwarefirma projoin GmbH realisierte für einen großen deutschen Baukonzern ein Management-Informations-System mit dessen Hilfe Führungskräfte eine praxisorientierte Entscheidungshilfe zur Verfügung haben. Dadurch wird es ermöglicht ein einheitliches Vorgehen in allen Bereichen des Konzerns durchzusetzen. Das Content Flow Systems CFS mit seinem XML-basiertem Ansatz ermöglicht eine Vielzahl weiterer Problemfelder im Berichtswesen abzudecken. Für die Erstellung eines jährlichen Geschäftsberichts müssen zahlreiche unterschiedliche Datenquellen im Unternehmen unter meist hohem Zeitdruck aufgerufen werden, von einer simplen Excel Liste bis hin zum operativen SAP-System. Im Gegensatz zu Data Warehouse-Lösungen, die einen für sie notwendigen zusätzlichen Datenpool mit hoher Komplexität im Unternehmen aufbauen, war es das Ziel von projoin eine Reduktion der Komplexität zu erreichen: wir nutzen XML- Konzepte, um ein einfaches Interface zur Verfügung zu stellen, das eine Meta-Sicht, eine Art integrative Perspektive auf heterogene Datenquellen im Unternehmen ermöglicht, erläutert Thomas Joachim, Geschäftsführer von projoin. Die Vorteile von CFS liegen allerdings nicht nur bei einzelnen Ausgabemedien sondern ermöglichen auch eine problemlose Integration anderer Dokumente, wie etwa einer Darstellung automatisch aktualisierte Umsatzzahlen in einem Word Dokument. Dies generiert eine große Zeiteinsparung bei den Führungskräften, da jederzeit nicht nur die aktuellen Zahlen verfügbar sind sondern diese auch in der benötigten Form ausgegeben werden können. Dies bedeutet, dass jederzeit Dokumente für die Außendarstellung des Unternehmens und auch interne Geschäftsberichte per Knopfdruck zur Verfügung stehen. [KMan202] 4. Web Services mit.net oder J2EE Nachdem in Kapitel 3 alle beschriebenen Unternehmen auf die.net Technologie bauen möchte ich in diesem Kapitel die Unterschiede zwischen.net und J2EE darstellen. 11

12 4.1 Die Beschreibung von Web Services Die wichtigste Komponente um Web Services gut strukturiert zu beschreiben ist WSDL. In WSDL wird die abstrakte Definition von Endpunkten und Nachrichten von ihren konkreten Inhalten oder Bindungen getrennt. J2EE nützt WSDL um eine Übereinstimmung über das geeignete Format für jedes transferiertes XML Dokument zu erzielen. Die Inhalte, die ein J2EE basiertes Web Service anbietet werden in einer Registry dargestellt..net nützt ein WSDL Dokument um sich selbst zu beschreiben und um die Endpunkte der Web Services eindeutig zu definieren. 4.2 Die Implementierung von Web Services Web Services implementieren bedeutet derzeit Operationen und Datenstrukturierung innerhalb eines XML Dokuments zu erstellen. Sind Web Services einmal implementiert kann eine Applikation eine Abfrage in Form einer XML Nachricht versenden und erhält als Antwort wieder ein XML Dokument. Bestehende Java Applikationen können in Java API für XML basierte JAX-RPC (Remote Procedure Call) eingebettet und als Web Services dargestellt werden. Die J2EE Web Services Architektur ist ein Set von XML-basierten Netzwerken, das die Infrastruktur liefert, die es Unternehmen ermöglicht Web Services zu etablieren, an Stelle unabhängiger Schnittstellen die früher erstellt werden mussten..net benützt einen binären Code, der dann in den jeweiligen entsprechenden Code mit Hilfe eines Just In Time Übersetzers JIT transformiert wird. Der Microsoft SOAP Toolkit bietet Komponenten, die die Konstruktion, die Sendung, das Lesen und den Prozess von SOAP Nachrichten erstellen. 4.3 Web Services publizieren, aufspüren und einbinden Sobald ein Web Service implementiert ist, muss es irgendwo publiziert werden, damit Interessierte darauf zugreifen können. Auch muss bekannt gegeben werden wie die Web Services verbunden werden können und ein Datenaustausch ermöglicht wird. Diese Verbindungs- und Kommunikationsinformation wird als Bindungsinformation bezeichnet. Sun Microsystems positioniert sein Java API für XML Registrierungsdateien als ein einfaches API, dass mit multiplen Registrierungsdateien zusammenarbeiten kann. Genannt wird dieses Tool JAXR..Net benützt zu diesem Zweck das UDDI. 4.4 Web Services abrufen und ausführen SOAP bildet das Rückgrad um strukturierte Daten über das Web zu transportieren. J2EE benützt Java API für XML basierte JAX-RPC um SOAP ähnliche Abfragen zu generieren. Das JAX-RPC erlaubt Java Entwicklern Web Services zu 12

13 programmieren, die unter Einbeziehung des XML basierten RPC den SOAP 1.1 Standard erfüllen..net transportiert die Daten mittels SOAP Protokolls. Dieser Vergleich zeigt, dass sowohl.net als auch J2EE sehr ähnliche Lösungen für Web Services entwickelt haben und die Zeit zeigen wird welche der Lösungen sich durchsetzten wird. Wenn man die derzeitige Verbreitung und die in der Werbung versprochene einfache Einbindung in bestehende Microsoft Betriebssysteme und Programme mit in die Betrachtung einfließen lässt liegt der Schluss nahe, dass auch hier Bill Gates das Rennen gewinnen wird. 5. Ausblick Wie in den drei oben angeführten Beispielen aus der Praxis erkennbar ist, beginnen immer mehr Firmen die Potentiale von Web Services zu erkennen und zu nutzen. Freilich noch in verschiedenem Ausmaß, dass sie jedoch in Zukunft viel Entwicklungspotential für das jeweilige Unternehmen aufgrund der Einführung von Web Services Technologie sehen, wird die Entwicklung weiter vorantreiben. Bisher fand die Standardisierung vor allem in Gremien statt dem W3C (World Wide Web Consortium) im Falle von SOAP, WSDL, HTML usw. oder OASIS (Organization for the Advancement of Structured Information Standards) im Falle von ebxml. Dass dies nicht immer so bleiben würde, kündigte sich mit der Gründung der Web Services Interoperability Organization (WS-I) an.sie soll den wichtigen Bereich der Kompatibilität zwischen verschiedenen Webservices-Implementierungen garantieren, was zweifellos notwendig dafür ist, dass sich Web Services durchsetzten. An diesem neugegründeten Gremium sind zwar IBM, Microsoft, BEA und viele andere beteiligt, aber Sun ist bis jetzt ferngeblieben. Die neuen Standardvorschläge in diesem Bereich umfassen: WS-Coordination: Dieser Standard soll die Koordination verschiedener Web Services ermöglichen und ist die Basis für WS-Transaction. WS-Transaction: Hiermit können Transaktionen über mehrere Web Services definiert werden. WS-Security: Diese Spezifikation definiert verschiedene Mechanismen, um die Sicherheitsaspekte von Web Services abzudecken. Business Process Execution Language for Web Services (BPEL4WS): Mit Hilfe dieser Sprache ist es möglich, Business Prozesse zu definieren, die dann durch die Orchestrierung von Web Services abgearbeitet werden können. 13

14 WS-Coordination WS-Coordination bietet einen generischen Service für die Koordinierung von Web Services in kollaborativen Aktivitäten an. Dabei sind bei dem Coordination Service drei Bereiche zu unterscheiden (siehe Abb. 3) Abb. 3 Scematische Darstellung des Coordination Service [Wol 3.02] Activation Service: Hiermit können neue Aktivitäten gestartet werden. Dabei kann definiert werden, welches Protokoll verwendet werden soll und ob die neue Aktivität Teil einer anderen Aktivität sein soll. Im Bereich der transaktionen könnten also Bespielsweise ein Two Phase Commit Protokoll definiert werden oder Transaktionen, die Teil einer übergeordneten Transaktion sind. Ergebnis des Startens einer Aktivität ist ein Coordination Context. Der Activation Service ist optionaler Bestandteil des Coordination Service Registration Service: Hier können sich Web Services als Teilnehmer an einer Aktivität registrieren. Dazu müssen sie einen Coordination Context angeben, den siedirekt oder indirekt von dem Web Service erhalten haben, der die Aktivität gestartet hat. Jeder Coordination Service muss einen Registration Service anbieten. Protocol Service: Hiermit können Nachrichten zwischen verschiedenen Coordination Services oder einer Anwendung und einem Coordination Service ausgetauscht werden. Welche Nachrichten hier verschickt werden können, ist in WS-Coordination nicht spezifiziert, sondern muss in einer getrennten Spezifikation wie beispielsweise WS-Transaction festgelegt werden. [Wol3.02] 14

15 WS-Transaction Um also den Coordination Service mit Leben zu füllen und konkrete Koordinierungsmechanismen zu definieren, bietet es sich an, einen transaction Service wie WS-Transaction zu spezifizieren. Abbildung 4 zeigt wie eine Atomic Transaction aufgebaut ist. Abb. 4 Aufbau einer Atomic Transaction [Wol 3.03] Das Web-Frontend entscheidet, dass eine Koordination der verschiedenen Web Services notwendig ist, und zwar sollen sie so koordiniert werden, dass entweder alle Web Services ihre Aktionen erfolgreich ausführen oder keine der Aktionen der Web Services ausgeführt wird also gerade die klassische Definition der alles oder nichts -Atomizität einer Transaktion. (Abb.2)[Wol3.02] WS-Security Der WS-Security Standard versucht generische Lösungen anzubieten. Zunächst ist es für die Absicherung der Datennotwendig, einen öffentlichen Schlüssel zu übertragen. Dabei hat sich das X.509-Zertifikat als Standard durchgesetzt. Dieses enthält neben Informationen zur Identität des Benutzers und dem öffentlichen Schlüssel die Signatur einer Certificate Authority, sodass man wirklich sicher sein kann, dass man keinen gefälschten öffentlichen Schlüssel untergeschoben bekommt. WS-Security ist ein recht einfacher Standard, vor allem, weil es im Prinzip lediglich XML Encryption und XML Signature mit SOAP verbindet, sodass der Standard selbst nicht viel regeln muss. Die meisten Sicherheitsprobleme sind abgedeckt, jedoch ist zu bedenken, dass die Sicherheit von Web-Services deshalb solch ein heißes Thema ist, weil Webservices einen direkten Zugang zu auf Geschäftsdaten erlauben und das über ein weit verbreitetes Protokoll wie http. 15

16 BPEL4WS Die BPEL4WS-Spezifikation definiert eine recht mächtige Umgebung zur Festlegung von Geschäftsprozessen. Dabei ist sie vor allem interessant, weil sie verspricht, die Orchestrierung von Web Services recht einfach zu machen. [Wol1.03] Alle 4 Standards sind recht einfach und kompakt. Einfachheit war schon ein wichtiger Grund dafür, dass sich HTML gegenüber SGML und dass sich TCP/IP und http durchgesetzt haben. Dieser Aspekt ist sicher auch ein wichtiger Grund für das Interesse an Web Services und die Probleme, die CORBA im Moment hat. All das zeigt, dass im Umfeld von Web Services spannende neue Entwicklungen bevorstehen, die garantieren sollen, dass einerseits tatsächlich eine grenzenlose Kommunikation zwischen allen erdenklichen Applikationen möglich ist, andererseits aber auch die notwendige Sicherheit für die teilweise hoch sensiblen Daten gefunden werden müssen. Die Dynamik um das Festlegen der neuen Standards garantiert einerseits, dass sich die Entwicklung der Web Services schnell vorantreibt, birgt aber andererseits die Gefahr der Unüberschaubarkeit und der damit verbundenen Ressentiments der Anwender diese unausgereifte Technologie im Unternehmen zu implementieren. Die größte und entscheidendste Waffe der Web Services gegenüber allen anderen Enterprise Application Integration Technologien ist aber die Möglichkeit der Kosteneinsparung und diese wird dafür sorgen, dass das Interesse der großen und kleinen Unternehmen weltweit stimuliert wird. 16

17 Literaturverzeichnis: [Asch702] Aschenbrenner K.: SQLXML: Web Services mit dem SQL Server In: DOTNETPRO Ausgabe 7/2002 S [SamSad] Samtani G. und Sadhwani D.: B2Bi and Web Services Auf: ( 8. Dez. 2002) [Heim202] Heimannsberg V.: Neuer Web-Auftritt des ADAC In: ebusiness Report Edition S [KMan202] Mantzel K.: Content Flow mit direktem Zugriff auf das SAP System In: ebusiness Report Edition S [Man202] Mantzel K.: Microsoft.NET in der Versicherungsbranche In: ebusiness Report Edition S [Wol3.02] Wolff E: Web Services: The Next Generation In: XML magazin & WEB SERVICES 3.02 S [Wol1.03] Wolff E: Web Services: The Next Generation In: XML magazin & WEB SERVICES 1.03 S [JuMy] Myerson M. J.: Web Services Architectures how they stack up Auf: ( 25. Jan. 2002) [MaWa] Waterhouse M.: Web Services Architect Review Auf: ( 25. Jan. 2002) [MoMoKe] Morrison M. Morrison J / Keys A.: Integrating Web Sites and Databases In: ebusiness Report Edition S [Gar] Gardner T.: An Introduction to Web Services Auf: ( 17. Sep. 2002) [LiHu] Liberty J. Hurwitz D.: Web Services Overview In: Programming ASP.NET Chapter 15 First Edition S [CFHIWT] Clark M., Fletcher P., Hanson J. J., Irani R., Waterhouse M., Thelin j.: Web Services Business Strategies and Architectures Expert Press (August 2002=. [MaWe] Marks E. A., Werell M.: Executive s Guide To Web Services John Wiley / Sons 1. Ausgabe [NE] Newcomer E.: Understanding Web Services XML, WSDL, SOAP and UDDI Addison Wesley Professional 1. Ausgabe