Web Services mit Java

Transkript

1 Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag

2 Kapitel 3 Web Services eine Einführung 3.1 Was sind Web Services? Die Grundlagen Sun ONE versus.net Zusammenfassung 87

3 72 Was sind Web Services? 3.1 Was sind Web Services? Nun, diese Frage lässt sich wohl noch am einfachsten beantworten. Zu der Kategorie der Web Services können all jene Client/Server-Applikationen gezählt werden, die ihre Dienste über ein Web zur Verfügung stellen. Speziell auf dieses Buch bezogen haben solche Applikationen ein gemeinsames Charakteristikum: Alle Web Services kommunizieren miteinander, wobei die Kommunikation über das SOAP-Protokoll stattfindet. Gerade weil diese Technologie noch sehr jung ist, lassen sich in Fachmagazinen nur selten Praxisberichte finden, in denen Entwickler und Projektleiter die Umstellung der internen Infrastruktur Ihrer Unternehmen auf Web Services schildern. Es wird vielmehr davon berichtet, dass man vorhabe, auf diesen Technologiezug aufzuspringen. Web Services sollen von ihrer Idee her nicht nur alleine im Internet angeboten werden, sondern auch einen großen Einzug in das betriebliche Informationssystem (BIS) halten. Im ersten Kapitel wurde bereits darüber berichtet, dass die Softwareentwicklung bis dato zwar effektiv war, leider aber das Thema der Interoperabilität mit anderen Rechnerwelten (siehe Abbildung 1.1) auf Grund von Herstellerstandards sprichwörtlich am Krückstock ging. Abbildung 3.1: Kommunikation zwischen Client und Webserver Web Services wurden nicht einfach von heute auf morgen erfunden, sondern sind das Produkt einer langjährigen Entwicklungsarbeit. Sofern wie in Abbildung 3.1 dargestellt ein Client einen Dienst auf einem Server aufruft, die Kommunikation zwischen den beiden Ebenen (Tiers) über ein beliebiges Netzwerk durchgeführt wird und bei der Informationsübermittlung von Ebene I zu Ebene II ein

4 Kapitel 3 Web Services eine Einführung 73 Protokoll wie z.b. HTTP, SMTP, XML (oder Kombinationen hiervon) benutzt wird, wird die Applikation von vielen Entwicklern bereits als Web Service bezeichnet. Wenn man jedoch von DEN Web Services an sich spricht, von denen seit einiger Zeit die Rede ist, so muss diese Definition erweitert werden: Ein Web Service ist eine Server-Applikation, die mit dem Client über das auf XML basierende Protokoll SOAP kommuniziert und dabei ein beliebiges Trägerprotokoll (z.b. HTTP) zum Transport der Informationen benutzt. Und genau dies macht die Web Services nicht neu. Ein solches Konzept ist schon seit mehreren Jahren bekannt und wird auch schon genauso lange praktiziert. Die eigentliche Revolution, durch die der»hype«um die Web Services entstanden ist, beruht auf der Tatsache, dass dank der Einigung auf ein gemeinsames XML-Protokoll verschiedene Rechnerwelten miteinander verbunden werden können. Glaubt man Analysten, z.b. von Gartner, so werden spätestens 2005 sämtliche Server-Lösungen mittels Web Services angetrieben. Große Unterstützung findet diese Technologie nicht nur durch Anbieter wie IBM, sondern vor allem durch Microsoft. Microsoft gehört mit zu den Hauptakteuren im Spiel um diese Technologie und betreibt vor allem für seine.net-plattform einen riesigen Marketing-Aufwand, um seinen Ansatz unter die Entwicklergemeinde zu bringen. Ein wesentlicher Bestandteil der.net-plattform sind die Möglichkeiten, mit Web Services auf einfachste Weise zu arbeiten. Dies ist der lang ersehnte Schritt, Microsoft-Rechnerwelten mit Nicht-Microsoft- Rechnerwelten zu verbinden. Im Klartext heißt das, dass dank der Web Services Microsoft- und Java-Applikationen nun miteinander kommunizieren können. Die Euphorie muss an dieser Stelle jedoch etwas gedämpft werden: Obwohl Web Services eine so viel versprechende Technologie sind, ist ihr Einsatz gewissen Beschränkungen unterworfen. Ein Grund dafür ist die schlechte Performance, die auf dem Austausch und Parsen von XML-formatierten Informationen beruht. Echtzeitsysteme, die ein vorgeschriebenes Frage-/Antwortzeitverhältnis aufweisen müssen, werden keine Verwendung für Web Services haben Web Services die Grundlagen Wie in Abbildung 3.1 und 3.2 dargestellt, fungiert ein Web Service als Vermittler zwischen Client- und Server-Applikationen. Die Aufgabe dieses Vermittlers kann klar definiert werden: 1. Das Annehmen von Anfragen seitens des Clients 2. Durchreichen dieser Informationen an eine Serverkomponente 1 Auf Grund der suboptimalen Performance kann die vielerorts hochgelobte Middleware- Technologie CORBA im wahren Leben auch nur schwer Freunde finden. Ein einfaches Beispiel ist das XETRA-Handelssystem der Deutschen Börse AG. Wenn es nämlich darum geht, Massen von Daten in kürzester Zeit zu verarbeiten, ist CORBA keine gute Wahl. Daher hat man bei XETRA eine eigene Middleware-Technologie entworfen.

5 74 Web Services die Grundlagen 3. Abwarten, bis die Serverkomponente ein Ergebnis zurückliefert 4. Weiterleiten dieses Rückgabewertes an den Client Abbildung 3.2: Web Services als klassische Middleware Auch diese Funktionalität ist nicht neu. Wie bereits angesprochen wurde, hieß eines der bisherigen Konzepte Middleware. Die klassische Middleware operiert dabei ebenfalls als Vermittler zwischen zwei oder mehr Welten. Abbildung 3.3 zeigt dies am Beispiel der Middleware-Technologie CORBA. Zentrales Organ der Kommunikationsübertragung ist ein so genannter Broker 2. Ein Broker nimmt bei CORBA ebenfalls Anfragen entgegen, leitet sie an eine Serverkomponente weiter und liefert dem anfragenden Client einen entsprechenden Rückgabewert zurück. Das dabei vom CORBA-Standard benutzte Protokoll ist normalerweise IIOP. Als Vermittler überbrückt ein Web Service unterschiedliche Technologiewelten. Der in Abbildung 3.2 aufgezeichnete Fall stellt eine Kommunikation zwischen drei verschiedenen Rechnerwelten dar. In Welt A arbeiten in C++ programmierte Programme auf Linux-Rechnern. In Welt B operieren vornehmlich mit Visual Basic programmierte Applikationen auf dem Betriebssystem Microsoft Windows. Über Welt C existieren keine Informationen über die Systemeigenschaften. Es ist 2 zu Deutsch: Vermittler

6 Kapitel 3 Web Services eine Einführung 75 lediglich wichtig zu wissen, dass die in Welt C existierenden Programme in Form von Web Services zugänglich sind, wobei das Protokoll SOAP benutzt werden muss. Vor der Existenz von Web Services waren zur Lösung eines solchen Problems lediglich proprietäre Lösungen denkbar. Durch Web Services ist es jedoch möglich, dass beide Welten, A und B, die Dienste einer dritten Welt C gemeinsam in Anspruch nehmen können. Dies macht Web Services unabhängig von einer spezifischen Plattform, und die als Web Services offerierten Dienste werden auch als plattformübergreifend bezeichnet. Ein weiterer Vorteil der Web Services ist die Erreichbarkeit. TCP/IP-basierte Middleware-Technologien kommunizieren fast ausnahmslos über einen Port. Wenn jedoch zwischen Client und Server eine Firewall existiert, muss in dieser erst der verwendete Port freigeschaltet werden. Web Services verwenden jedoch als Trägerprotokoll HTTP, wodurch die Kommunikation überall dort lauffähig ist, wo ein Browser ins Internet kommen könnte. 3 Abbildung 3.3: Die Arbeitsweise klassischer Middleware am Beispiel von CORBA 3 In der Praxis treten jedoch auch häufig schon einmal Probleme mit Proxyservern auf. Proxyserver dienen als Cache, indem sie aufgerufene Informationen lokal für einen bestimmten Zeitraum zwischenlagern und bei jeder neuen Anfrage diese veralteten Informationen zurückliefern.

7 76 Web Services die Grundlagen Der Aufbau Der Aufbau von Web Service-Architekturen ähnelt den bereits bekannten klassischen Middleware-Architekturen. Wenn wie in Abbildung 3.3 ein Client einen Dienst auf dem CORBA-Server ausführen möchte, muss er erst ein Serverobjekt benennen, mit dem er in Dienstleistungskontakt treten möchte. Um dies zu ermöglichen, muss die Server-Applikation zuvor über das zentrale Middleware- Organ, den ORB, ihren Dienst bei einem Namensdienst anmelden und als Dienst registrieren. Die Vorgehensweise bei Web Services ist ähnlich. Insgesamt lassen sich wie in Abbildung 3.4 dargestellt folgende drei Rollen vergeben: der Dienste-Konsument 4, der Dienste-Anbieter 5 und die»gelben Seiten«6. Der Dienste-Anbieter: Der Dienste-Anbieter (oder auch Dienstleister) entwickelt eine Dienstleistung, etwa die Lieferung von Realtime-Aktienkursen. Damit später ein Dienste-Konsument diese Aktienkurse abfragen kann, muss der Anbieter diese Dienstleistung zunächst in einem standardisierten Format beschreiben. Die standardisierte Beschreibungssprache für Web Services ist WSDL 7. WSDL basiert ebenfalls auf XML und ist vergleichbar mit der IDL 8, die bei klassischen Middleware-Technologien zum Einsatz kommt. Nach dieser Beschreibung empfiehlt es sich für den Dienste-Anbieter, seinen Dienst an einem zentralen Anlaufpunkt anzumelden, der für den Anfragenden zugänglich ist und es erlaubt, eine breite Masse von Dienste-Konsumenten anzusprechen. Die»Gelben Seiten«: Die»Gelben Seiten«sind eine Registry, in der Dienste- Anbieter publizieren können, wie ihre Dienstleistung aussieht. Diese Registry ist durchaus vergleichbar mit den in Deutschland bekannten»gelben Seiten«, in denen Handwerker ihre Dienstleistungen anbieten. Genau wie in diesem von der Telekom veröffentlichten Dokument alle Informationen enthalten sind, wo welcher Dienstleister für welche Tätigkeit zu finden ist, wird in den»gelben Seiten«für Web Services die Dienstleistung eines Dienste-Anbieters beschrieben. Die Beschreibung ist ebenfalls standardisiert und erfolgt mittels UDDI 9. Der Dienste-Konsument: Jeder, der Dienste eines Dienste-Anbieters in Anspruch nimmt, wird als Dienste-Konsument (oder kurz: Konsument) bezeichnet. Genau wie ein»häuslebauer«nach einem Handwerker in den»gelben Seiten«sucht, findet er einen Dienstleister in der Registry. Nachdem er alle Informationen über diese Dienstleistung kennt, ist er in der Lage, die 4 Engl.: Service Consumer 5 Engl.: Service Provider 6 Engl.: Service Registry 7 Web Services Description Language 8 Interface Description Language 9 Universal Definition, Discovery and Integration

8 Anmeldung Kapitel 3 Web Services eine Einführung 77 Dienste des Anbieters in Anspruch zu nehmen. Das bedeutet, dass der Konsument entfernte Methodenaufrufe auf dem Server durchführt genau das Konzept, das bereits in den siebziger Jahren als RPC 10 bekannt wurde. Die Informationen, die zwischen Konsument, Dienstleister und der Registry ausgetauscht werden, werden über ein Trägerprotokoll (wie HTTP oder FTP) übertragen. Konsument und Dienstleister codieren die auszutauschenden Informationen mittels SOAP. Ein weiterer, sich hieraus ergebender Vorteil ist die einfache Nutzung von Internettechniken. Genau wie im Homebanking-Bereich das HTTPS-Protokoll genutzt werden kann, um sichere Informationen zwischen Browser und Webserver auszutauschen, kann diese Verbindung auch für Web Services genutzt werden, ohne dass hierfür großer Programmieraufwand nötig wäre (siehe Kapitel 11). sucht nach Dienst nimmt Dienst in Anspruch Abbildung 3.4: Das Zusammenspiel von Dienste-Kosument, -Anbieter und -Registry: Der Konsument nimmt Dienste des Anbieters in Anspruch, welcher wiederum den Dienst an einer Registry anmeldet, sodass der Konsument diesen Dienst suchen kann 10 Remote Procedure Call

9 78 Web Services die Grundlagen Die Bestandteile der Architektur im Überblick SOAP Das Simple Object Access Protocol legt eine Formatierung fest, mit der die Informationen, die von einem Rechner zum anderen übertragen werden, codiert werden müssen, um eine»globale«verständigung zwischen den jeweiligen Rechnerwelten zu erreichen. SOAP basiert auf der XML-Syntax und kann daher von Standard-Parsern eingelesen werden, ohne dass hierfür erst noch eigene Lösungen programmiert werden müssen. SOAP umfasst lediglich die Formatierung von Daten, nicht aber, wie die Daten von A nach B gelangen oder wie es vielleicht technisch realisierbar ist, dass ein RPC über das Internet durchgeführt wird. Und genau dies ist die Stärke der Web Services: Wie ein RPC auf dem Zielrechner ausgeführt wird, darum muss sich der Anbieter der Plattform kümmern. Der Dienste-Konsument muss, wie bereits in Abbildung 3.4 vorgeführt, lediglich wissen, wo er den Dienst wie aufruft. Da sich die Implementierungstechnologie primär auf den Plattformhersteller beschränkt, ist es möglich, dass Microsoft fleißig an seiner.net-version herumbastelt, sie für seine Zwecke verbessert und auf der anderen Seite z.b. IBM Weiterentwicklungen für den WebSphere-Server durchführt. Der Dienste-Konsument muss sich nur noch auf seine Plattform beschränken und erhält dadurch einen größeren Spielraum, um sich auf seine Applikation konzentrieren zu können. Auf Grund seiner XML-Basis ist es möglich, SOAP für eigene Bedürfnisse zu erweitern. Ein Beispiel hierfür sind Transaktionsnummern oder Sicherheitsaspekte, denen später in diesem Buch ein eigener Abschnitt (Kapitel 12) gewidmet wird. Und an dieser Stelle endet bereits die Interoperabilität des Protokolls. Wie später ausführlich diskutiert werden wird, haben viele der großen Software- Anbieter (IBM, Microsoft, Sun usw.) Eigenentwicklungen von auf SOAP aufsetzenden Standards für den Datenaustausch im B2B-Bereich entwickelt. Speziell für die Beschreibung von Geschäftsabläufen legen viele Anbieter unterschiedliche Konzepte vor, die sich auf dem Markt noch beweisen müssen. Eine gemäß dem SOAP-Format codierte Information wird als SOAP-Nachricht bezeichnet. Eine SOAP-Nachricht ähnelt bildlich wie in Abbildung 3.5 dargestellt einem»normalen«brief. Außen umfasst ein Briefumschlag (Envelope) die zu versendende Nachricht (damit nichts herausfallen kann). Innerhalb des Briefumschlags findet sich ein Zettel, der in zwei Teile aufgeteilt ist. In der oberen Hälfte befindet sich eine Kopfzeile (Header), in der z.b. Absenderinformationen untergebracht werden können. In der unteren Hälfte finden Sie den eigentlichen Nachrichtentext (Body), der die Informationen über die Daten enthält, die von A nach B übertragen werden sollen. Das XML-Dokument in Listing 3.1 beinhaltet eine SOAP-Nachricht, die einen entfernten Methodenaufruf bewirken soll. Da ich auf SOAP später (s. Kapitel 6) noch detailliert eingehe, verzichte ich an dieser Stelle auf eine genaue Erklärung.

10 Kapitel 3 Web Services eine Einführung 79 Abbildung 3.5: Die Analogie zwischen einer SOAP-Nachricht und einem Brief Listing 3.1: kapitel3\rpc SOAP-Nachricht.xml 01: <?xml version="1.0"?> 02: 03: <!-- Briefumschlag --> 04: <SOAP:Envelope 05: xmlns:soap=" 06: SOAP:encodingStyle=" 07: 08: 09: <!-- Kopfzeile --> 10: <SOAP:Header> 11: 12: <xyz:transaction 13: xmlns:xyz="soap-transaction" 14: SOAP:mustUnderstand="true"> 15: <transactionid>1234</transactionid> 16: </xyz:transaction> 17: 18: </SOAP:Header> 19: 20: <!-- Nachrichtentext --> 21: <SOAP:Body> 22: <dienst:getkurs xmlns:dienst="urn:realtimekursservice"> 23: <wkn xsi:type="xsd:string">923835</wkn> 24: </dienst:getkurs> 25: </SOAP:Body>

11 80 Web Services die Grundlagen 26: 27: 28: <!-- ENDE --> 29: </SOAP:Envelope> WSDL Aus Abbildung 3.4 geht hervor, dass WSDL auf der Serverseite einzuordnen ist. WSDL steht für Web Services Definition Language und ist eine auf XML basierende»sprache«, mit der das Dienstangebot eines Servers beschrieben werden kann. Im Klartext: Mit Hilfe von WSDL kann definiert werden, welche Methoden bei der Serverkomponente vom Client ausgeführt werden können, welche Parameter dabei übergeben werden müssen und was für einen Rückgabewert diese einzelnen Methoden liefern. Ein einfacher Trick, um Web Services verstehen zu können, ist, sie mit»herkömmlichen«verfahren zu vergleichen, wie sie von den klassischen Middleware- Technologien geboten werden. Führende Konzepte dieser Technologie-Kategorien speziell für den Bereich Java sind CORBA und RMI 11. Abbildung 3.3 hat bereits die Funktionalität von Middleware am Beispiel CORBA gezeigt. Zwischen Client und Server existiert die Middleware-Schicht. Um Methoden seitens des Clients auf dem Server ausführen zu können, müssen die hierfür nötigen Informationen vom Client an den Broker gesendet werden, der erkennt, welche Methode auf welchem Server ausgeführt werden soll. Um die Programmierung zu vereinfachen, werden die aufrufbaren Methoden des Servers (die»dienste«) in Form eines Interface publiziert. Dieses Interface ist im Fall von CORBA mit Hilfe der CORBA-eigenen Sprache IDL entwickelt worden. Nach der Publikation kann sich jeder Programmierer, dessen Programmiersprache CORBA-fähig ist, aus diesem Interface Programmcode für seine entsprechende Programmiersprache generieren lassen. Dies bedeutet, dass spätestens ab dem Zeitpunkt der IDL-Publikation es schlichtweg egal wird, mit welcher Programmiersprache der Server entwickelt wurde. Es kommt nur noch darauf an, ob der Client in der Lage ist, mit seiner Programmiersprache auf den CORBA-Server zuzugreifen. Und genau dieses Verfahren lässt sich bei den Web Services wiederfinden. Was die IDL für CORBA ist, ist WSDL für Web Services. Abbildung 3.6 visualisiert den Aufbau einer Web Service-Beschreibung. Konkret wird ein WSDL-Dokument in zwei Teile aufgeteilt. Zum einen existiert eine abstrakte und wiederverwendbare Definition im oberen Teil und zum anderen eine implementationsabhängige Definition im unteren Teil des Dokuments. Erstere ist unabhängig von dem jeweils verwendeten Transportprotokoll und unterstreicht daher erneut die Stärke von Web Services. Das tatsächlich verwendete Transportprotokoll (SOAP, HTTP etc.) wird innerhalb eines Binding-Elements untergebracht, wodurch der Web Service als solcher technologieunabhängig wird. 11 Remote Method Invocation

12 Kapitel 3 Web Services eine Einführung 81 Weil auch dieses Thema sehr umfangreich ist, gehe ich in Kapitel 7 noch einmal detaillierter darauf ein. Abbildung 3.6: Der grobe Aufbau eines WSDL-Dokuments für einen Web Service UDDI Der letzte Schlüsselbegriff, der im Zusammenhang mit Web Services unbedingt zu erwähnen ist, ist UDDI. UDDI steht für Universal Description, Discovery and Integration und ist sozusagen die»registry«für sämtliche Web Services. Abbildung 3.4 hat bereits den Zusammenhang zwischen Konsument, Dienstleister und dieser Registry gezeigt. Nachdem ein Web Service mittels WSDL definiert wurde, muss er veröffentlicht werden. Dieser Vorgang ist vergleichbar mit einer Bekanntmachung auf einer Liste, die allen Personen öffentlich zugänglich ist. Wer einen Web Service entwickelt und mit WSDL beschrieben hat, der muss dies nur noch auf dieser»liste«eintragen (samt den Daten, wo dieser Dienst gefunden werden kann, wer der Autor ist usw.). Ein weiteres Beispiel aus der Nicht-Computerwelt sind die»gelben Seiten«. Wer einen Handwerker sucht, der sieht in den»gelben Seiten«nach. Dort findet er alle nötigen Informationen, um mit diesem Handwerker in Kontakt zu treten und als Konsument die Dienstleistung dieses Dienste-Anbieters in Anspruch zu nehmen. WSDL hat bereits sämtliche Informationen, mit denen ein Konsument die Dienstleistung in Anspruch nehmen kann, beschrieben; UDDI ist lediglich ein Standard, mit dessen Hilfe u. a. diese WSDL-Informationen zugänglich gemacht werden können. Abbildung 3.7 zeigt, dass ein Dienste-Anbieter aber nicht nur WSDL- Informationen innerhalb einer UDDI Registry ablegen kann. Da Web Services für einen globalen Marktplatz gedacht sind, auf dem sich viele Unternehmen als Dienstleister anbieten, können in der Registry insgesamt drei verschiedene Informationstypen untergebracht werden: Business-, Service- und Technik-Informationen. Diese werden im Englischen auch als»white Pages«,»Yellow Pages«und»Green Pages«bezeichnet.

13 82 Web Services die Grundlagen veröffentlicht sucht nach Dienst Abbildung 3.7: Der Austausch von Informationen und die Zuordnung der Teiltechnologien zu den einzelnen Akteuren Die White Pages bieten dem jeweiligen Unternehmen die Möglichkeit, sämtliche für rechtlich relevante Transaktionen benötigten Informationen unterzubringen. Neben den»normalen«informationen, wie z.b. der Adresse, können auch Geschäftsdaten wie Steuernummern oder Ähnliches in die Registry eingetragen werden. Die Yellow Pages umfassen den eigentlichen»service«, der von dem Unternehmen angeboten wird. In der Praxis kommt es oft vor, dass ein Unterneh-

14 Kapitel 3 Web Services eine Einführung 83 men nicht nur einen Web Service anbietet, sondern gleich mehrere. Dementsprechend wird dem Konsumenten eine Möglichkeit geboten, alle Dienste dieses anbietenden Unternehmens zu erfragen. Weiterhin lassen sich diese Dienste kategorisieren, z.b. in Realtime-Kursabfragen oder Ähnliches. Die Green Pages dienen technischen Spezifikationen der Web Services. WSDL ist nur eine Ausprägung dieser Spezifikationen. Das Szenario aus Abbildung 3.7 zeigt eine Situation, in der die Web Services eines Unternehmens mit der Programmiersprache Java entwickelt wurden. Im»realen Leben«kann dies eine typische J2EE-Anwendung sein, etwa ein Direkt- Broker. Ein Direkt-Broker (wie z.b. die comdirect-bank) bietet ihren Kunden die Möglichkeit, sich (mit einem Browser) über das Internet in den Homebanking- Bereich einzuloggen und von hier aus rechtsverbindliche Transaktionen durchzuführen. Die Menüsteuerung für die Clientseite erfolgt in diesem Fall auf Serverseite über Servlets oder JSPs, die dem Browser des Kunden HTML zusenden. Diese Servlets bzw. JSPs übernehmen allerdings nur präsentationstechnische Aufgaben. Die Geschäftslogik wird von Enterprise JavaBeans übernommen. Wenn nun aber ein anderes Unternehmen Dienstleistungen des Direkt-Brokers nutzen möchte, z.b. die Übernahme von deren Realtime-Kursanzeigen in das eigene System, so müsste der Anbieter über RMI Kontakt zum Direkt-Broker aufnehmen. Da der»konsument«aber über ein rein Microsoft-basiertes Programmumfeld verfügt und sämtliche Anwendungen mit VB.NET programmiert hat, baut sich hier eine nur äußerst schwer zu nehmende Hürde auf. Und um genau diese Hürde zu beseitigen, entwickelt der Dienste-Anbieter (nachdem er dieses Buch gelesen hat) sozusagen Adapter für seine bestehende J2EE- Umgebung. Um dies bewerkstelligen zu können, existieren zahlreiche Tools 12, die die Java-Klassen in WSDL beschreiben. Diese WSDL-Informationen veröffentlicht der Dienste-Anbieter in einer öffentlich zugänglichen Registry mitsamt den zusätzlichen Informationen, wie z.b. Unternehmensdaten. Der Dienste-Konsument bezieht bei Bedarf das WSDL-Dokument über die Registry und kann sich hieraus anschließend von seiner Entwicklungsumgebung Programmcode für VB.NET generieren lassen, sodass die Entwicklung nicht mehr von Hand, sondern automatisiert und viel zeitschonender durchgeführt werden kann (der umgekehrte Weg funktioniert analog). Die zwischen Konsument und Anbieter ausgetauschten Informationen werden mittels SOAP codiert und über ein beliebiges Trägerprotokoll (z. B. HTTP) übertragen. Von der Codierung in SOAP bekommt der Entwickler heute zwar nichts mehr primär mit, es ist aber immer hilfreich, die Codierung zu kennen und vor allem zu verstehen Zum Beispiel Java2WSDL, das im Axis-Kapitel besprochen wird 13 Insbesondere in Kapitel 11, in dem SOAP-Nachrichten signiert werden, muss der Entwickler teils mittels DOM auf diese XML-Dokumente zugreifen.

15 84 Sun ONE versus.net 3.3 Sun ONE versus.net Werden Sun Microsystems und Microsoft von einem neutralen Beobachter verglichen, kommt es diesem vielleicht so vor, als würde Porsche behaupten, alle Ferraris seien schlecht und umgekehrt. Da Ferrari in der Formel 1 tätig ist, würden sie behaupten, dass ihre Wagen dadurch viel besser seien als die von Porsche. Kaum hätte ein Pressesprecher von Ferrari diesen Satz ausgesprochen, träte auch schon einer von Porsche aufs Podium und würde behaupten:»wir haben zwar keinen Formel-1-Rennwagen, dafür können unsere Wagen aber von Hamburg nach München durchfahren, ohne zwischendurch an drei Werkstätten anhalten zu müssen!«fest steht jedenfalls, dass Microsoft zu einem erheblich früheren Zeitpunkt mit einem enormen Marketing-Aufwand seine.net-technologie bekannt gemacht hat. Der J2EE-Ansatz von Sun ist laut Aussage vieler Programmierer und Entscheider jedoch eine sinnvollere Technologie für Unternehmen, da diese Technologie auf Grund der Tatsache, dass lediglich Zusätze zu existierenden, erprobten Softwarebibliotheken hinzugefügt worden sind, ausfallsicherer ist als die neuere, unerprobtere.net-technologie. Fest steht auch weiterhin, dass Microsoft mit seiner Marketing-Genialität die.net-plattform exzellent in vielen Köpfen der Entwickler 14 als EINE Technologie positioniert hat. Sun hat der Entwicklergemeinde im Gegensatz dazu bisher eine Vielzahl unterschiedlicher Produkte angeboten. So gab es Forté als grafische Entwicklungsumgebung für Java oder auch den iplanet Application Server, allesamt»insellösungen«, die irgendwo eine Gemeinsamkeit besaßen, so wie dies bei Microsoft vor.net der Fall war. Weil aber bei Sun Microsystems auch hochbezahlte Marketingchefs tätig sind, dauerte es nicht lange, bis diese auf die geniale Idee kamen, ihre existierenden»insellösungen«unter dem Oberbegriff ONE zusammenzufassen. ONE steht dabei für Open Network Environment und ist da nur wenig»neues«hinzugekommen ist vergleichbar mit der Umlackierung eines Taxis: Außen sieht es zwar aus wie ein normales Auto, innen ist es aber immer noch ein Taxi. Dies sorgte für viel Verwirrung unter den Java-Entwicklern, die sich nicht im Wochentakt in Zeitschriften auf dem Laufenden gehalten haben:»was, wieso gibt s denn keinen iplanet Application Server mehr???«antwort:»doch gibt s schon noch, er heißt jetzt nur Sun ONE Application Server!«Insgesamt gesehen versucht Sun mit dieser Strategie, die Position von Java gegenüber.net zu stärken. Abbildung 3.8 zeigt den Architekturentwurf der J2EE-Welt. Auf der obersten Ebene existieren unterschiedliche Clients, die mittels verschiedener Protokolle das J2EE-System kontaktieren möchten. 14 Bei meinen Seminaren habe ich jedoch vermehrt festgestellt, dass viele COBOL-Entwickler noch nicht realisiert haben, dass Windows 95 nicht mehr aktuell ist...

16 Kapitel 3 Web Services eine Einführung 85 Abbildung 3.8: Der Sun ONE-Ansatz Der erste Rechner symbolisiert eine Applikation, die aus einer anderen Technologiewelt stammt als der von Java (z. B. Microsoft.NET). Dieser kann die Hauptapplikation, die in Form von Enterprise JavaBeans (EJBs) auf dem Server implementiert wurde, über ein XML-basiertes Protokoll ansprechen (z.b. SOAP oder ebxml, s. Kapitel 12). Um die Hauptlogik überhaupt ansprechen zu können, muss eine Art»Adapter«geschaffen werden, der die XML-Codes des Clients analysiert, versteht und in Java-Befehle umsetzt. Dies wird im Allgemeinen durch ein so genanntes»router Servlet«gelöst. Der zweite Client benutzt das Protokoll IIOP, welches CORBA und RMI-Applikationen gemein ist. Hierdurch wird ein direkter Zugriff auf das EJB-Umfeld ermöglicht. Die letzten beiden Clients nutzen das Protokoll HTML. HTML, bekannt von sämtlichen Internetseiten, ist das Format, mit dem statische Informationen codiert werden, damit der Browser diese Informationen»als bunte Bildchen«auf dem Clientrechner visualisieren kann. Diese Applikationen können Eingriffe in die Geschäftslogik vornehmen oder nicht. Falls sie es tun, so handelt

17 86 Sun ONE versus.net es sich meist um Applikationen ähnlich einem Homebanking-System. Der Kunde loggt sich über eine Website in das System ein und kann über HTML-Formulare im Browser Überweisungen tätigen. Die eigentliche Geschäftslogik ist auch in diesem Fall ein und derselbe EJB-Kern. Allerdings beschränken sich die EJBs auf Geschäftslogiken wie etwa das Buchen auf einem anderen Konto. Die Visualisierung der Daten, das Einloggen und die Annahme von Formulardaten, die der Kunde über seinen Browser an das System sendet, werden in Form von Servlets und JSPs entwickelt. Dies ermöglicht eine klare Trennung der Entwicklung in präsentierende und geschäftslogische Funktionalitäten. Abbildung 3.9: Der.NET-Ansatz Abbildung 3.9 nutzt die bereits aus Abbildung 3.8 bekannte Darstellungsweise und zeigt den entsprechenden Ansatz von Microsoft.NET. Der einzige Unterschied auf Clientseite liegt darin, dass der zweite Client das Protokoll (D)COM von Microsoft benutzt, um auf die.net-komponente im Kern des Gesamtsystems zuzugreifen. Diese Komponenten im Systemkern wurden mit einer beliebi-

18 Kapitel 3 Web Services eine Einführung 87 gen, von.net unterstützten Programmiersprache entwickelt, genauso wie der Client. Auf den ersten Blick scheint dies zu bedeuten, dass Java durch.net mit Visual Basic kommunizieren kann, was angeblich vorher nicht möglich war. Dies ist in der Tat richtig. Allerdings ist dieser Ansatz lediglich sprachunabhängig, aber nicht was eigentlich das Wichtigste ist plattformneutral. Und Letzteres ist das Ziel der Entwicklung, was bereits zu Beginn dieses Kapitels von den Technologien gefordert wurde. Der Microsoft-Ansatz in dieser Form erfordert also stets eine Mircosoft-Plattform (sonst würde die Firma ja nichts verdienen). 3.4 Zusammenfassung Lassen Sie uns noch einmal kurz Revue passieren, was bis zu diesem Haltepunkt innerhalb des Buches besprochen wurde. Nach einer kurzen, aber notwendigen Einführung in die Technologie XML im zweiten Kapitel wurde in diesem dritten Kapitel das eigentliche Kernthema dieses Buches eingeführt, wobei ich permanent versucht habe, Sie von der enormen Bedeutung der und dem großen Bedarf an Web Services zu überzeugen sowie die Thematik angemessen einfach darzustellen. Web Services haben nur einen neuen Namen und ein neues auf XML basierendes Protokoll zur Formatierung der Daten, die von A nach B fließen, aber die eigentliche Funktionsweise ist keinesfalls neu. Das Konzept stammt noch aus den sechziger Jahren, wurde damals RPC genannt und war plattform- und sprachabhängig. In den folgenden Kapiteln wird es darum gehen, die Theorie dieser ersten Kapitel in die Realität umzusetzen. Weil Web Services im Vergleich zu CORBA aber noch immer in den Kinderschuhen stecken, scheint oftmals lediglich das Protokoll SOAP standardisiert. Daher werden unterschiedliche Szenarien entwickelt, bei denen die Programme mit verschiedenen Herstellerprodukten arbeiten.