Hawlitzek GmbH/ Veröffentlichungen/ Web Services mit WSAD/
 

Hawlitzek IT-Consulting GmbH ©Foto Kirsten Literski-Hawlitzek

Web Services mit WSAD

Dieser Artikel ist im JavaMagazin 4/02 erschienen. Vielen Dank an den Software & Support Verlag für die Genehmigung zur Veröffentlichung auf dieser Webseite!

Web Services effizient entwickeln

Erstellung von Web Services mit IBM WebSphere Studio Application Developer

Web Services sind der neue Hype am Softwarehimmel. Endlich kann man verschiedenartigste Umgebungen standardisiert koppeln. Leider ist es aber nicht ganz einfach, all die Konfigurationsdateien richtig bereitzustellen. Wohl dem, der ein Tool besitzt, das all dies erledigt.

Mit Web Services haben wir uns im Java Magazin schon des öfteren beschäftigt (z. B. Schwerpunktthema in Ausgabe 9/2001), deshalb nur ganz wenige Worte zu Technik: Ein Web Service ist ein Dienst, der im Internet registriert ist. Er ähnelt einem Servlet, das unter einer URL ansprechbar, in der Regel mit Parametern aufrufbar und Bestandteil einer größeren Anwendung ist. Im Unterschied zum Servlet liefert der Web Service jedoch keine Ausgabe für einen Browser zurück (z. B. eine HTML-Seite), sondern eine XML-Datenstuktur. Der Aufrufer ist also kein Mensch, sondern ein Programm. Der andere Unterschied ist die Registrierung: Während eine servlet-basierende Anwendung, deren URL nicht bekannt ist, im Internet nur umständlich per  Suchmaschinen oder Portale gesucht werden kann, ist ein Web Service bei einer Registry eingetragen und beschrieben – und dies nicht nur in fachlicher, sondern auch in technischer Sicht.

Zum Aufruf eines Web Services und zur Rückübertragung der Ergebnisse wird das SOAP-Protokoll benutzt (Simple Object Access Protocol), das alle Daten als XML-Dokument kodiert. Die Beschreibung des Dienstes erfolgt ebenfalls als XML-Dokument, das in der Web Services Description Language (WSDL) abgefasst ist und in einer UDDI-Registry (Universal Description Discovery & Integration) abgelegt wird.


Abbildung 1: Registrierung und Nutzung eines Web Services

Bewertung

Web Services bzw. das darunter liegende Protokoll SOAP ist neben CORBA, RMI, DCOM oder EDI ein weiterer Ansatz zur Koppelung von Anwendungen auf verschiedenen Rechnern. Und das noch nicht einmal ein besonders innovativer oder komfortabler: Es ist eine Umwandlung der Parameter und Ergebnisse in die Datentypen der Programmiersprachen notwendig und diese erfolgt nicht einmal automatisch (wie z. B. bei EJB bzw. RMI over IIOP), außerdem bläht das XML -Format die Daten erheblich auf. Beides kostet Performance. Es gibt keinen gemeinsamen Adressraum, Referenzen auf Remote-Objekte oder einen Sitzungskontext. Das bedeutet, dass bei einer Anwendung, die aus aufeinander aufbauenden Aktionen bestehen, wie z. B. die einzelnen Schritte Produktauswahl, Bezahlung und Versand in einem Onlineshop, der Kontextbezug zu einer Anwendungssitzung aufwendig durch den Entwickler verwaltet werden muss. Ein weiterer Nachteil ist die fehlende Verschlüsselung auf dieser Protokollebene.

Warum sind Web Services trotzdem ein Renner und in welchen Fällen macht der Einsatz Sinn? Protokolle wie CORBA haben im Internet  kaum eine Chance, da sie durch Firewalls blockiert werden. Außer Emails und HTTP-Verkehr wird kaum etwas durchgelassen, so dass sich die Entwickler Tricks überlegen müssen, wie sie Daten und Methodenaufrufe in HTTP-Paketen durch die Firewall „hindurch tunneln“ können.  SOAP ist ein solches HTTP-Tunneling-Protokoll und damit sehr flexibel und ohne administrativen Aufwand einsetzbar.

Der zweite große Vorteil ist die Plattformunabhängigkeit. Java wirbt seit jeher mit diesem Argument, schließlich gibt es fast für jeden Rechner eine VM. Trotzdem gibt es noch eine Welt jenseits von Java und auch eine Kopplung von Windows/COM-Anwendungen und Programmen in anderen Sprachen sind notwendig. SOAP wurde von IBM, Microsoft und Ariba erschaffen, mittlerweile sind viele andere Firmen hinzugekommen (z. B. SAP, HP, Compaq, IONA). Das Protokoll ist ein wichtiger Bestandteil von Micrsoft .NET-Architektur und steht damit auch Sprachen wie C++., C#, VB und Delphi offen. Neben der Microsoft-SOAP-Implementierung gibt es die von IBM, welche mittlerweile an Apache übergeben wurde und in Java realisiert ist.

Wofür eignen sich nun SOAP und Web Services? Im Intranet eignet sich SOAP als Verbindungsprotokoll zwischen Java- und COM-Anwendungen. Eine UDDI-Registrierung ist hier meist überflüssig, in größeren Konzernen bietet sich jedoch eine zentrale Verwaltung mittels privater Registry an. Im Internet kommt der http-Tunnel zum Tragen und außerdem die feste Spezifikation und die Suchfunktionen in öffentlichen UDDI-Registries.

WebSphere Studio Application Developer

Der Application Developer von IBM kam Ende 2001 auf den Markt und tritt in vielen Bereichen die Nachfolge von VisualAge for Java und dem „alten“ WebSphere Studio an. Es umfasst Werkzeuge rund um die Entwicklung von J2EE -Anwendungen (EJB, JSP, Servlets, ...), Weboberflächen, XML und WebServices. Zwei Bereiche fehlen gegenüber dem bisherigen VisualAge: die wizard-gestützte Entwicklung von Fatclients mit dem Visual Composition Editor und die Anbindung von Host- und ERP-Systemen mittels Connectoren (J2EE Connector Architecture bzw. IBMs Common Connector Framework). Für beide Zwecke wird derzeit noch VisualAge for Java 4.0 im Pakte mitgeliefert, für die Connectoren ist jedoch für die nächsten Monate die Enterprise Developer Edition in Entwicklung.

Der Application Developer setzt auf einer offenen Workbench auf, die IBM im Rahmen des Eclipse-Projektes als Open Source freigegeben hat. Die einzelnen Werkzeuge sind darin als Plug-Ins realisiert. IBM hofft mit dieser Öffnung neben Rational, Instantiations oder Merant noch viele weitere Partner zu finden, die Eclipse eine ähnliche Verbreitung wie Microsofts Visual Studio bereiten soll. Im Unterschied zu VisualAge setzt WSAD nicht mehr auf einem zentralen Code-Repository auf, sondern arbeitet datei-basiert.

Entwicklung von Web Services

Voraussetzung zur Entwicklung eines Web Services ist ein sogenanntes Web Project. Dieses legt man mit dem Project-Wizard an und versieht es mit einem Namen. WSAD legt nun ein Stammverzeichnis an. Darunter gibt es die Verzeichnisse „source“ und „webApplication“.  In letzterem befindet sich dann später der zu deployende Code und die Konfigurationsdateien (siehe Abbildung 2).

Abbildung 2: Web-Perspektive des Beispielprojektes

Häufig entwickelt man den Web Service nicht vollkommen neu, sondern setzt auf vorhandenem Code auf. WSAD erlaubt neben der Neuimplementierung das Wrappen eines Web Services um eine JavaBean, eine EJB oder Datenbankanweisungen. In unserem Beispiel möchten wir eine Art Shopsuche für Handys anbieten. Der Nutzer, z.B. ein Händler oder ein Portal gibt ein bestimmtes Handy per Marke und Modell an und unserer Service liefert die URL mit der Handy-Detailinfo bzw. Bestellseite zurück.

Wir bauen hier auf einer JavaBean auf, die in einer Datenbank mit Handydaten die passende URL heraussucht (de.hawlitzek.jm.webservices.HandySuchBean.java).  Im Wizard geben wir nun als Web Service Type „Java bean Web service“ an und wählen unsere Bean aus, die wir zuvor im source-Verzeichnis des Projektes abgelegt hatten. Auf der nächsten Seite des Wizards (Abbildung 3) können wir einige Angaben zu den Konfigrationsdateien machen. Hier gibt man die Namen und Pfade der WSDL-Files an: das Binding-Dokument beinhaltet später die Schnittstellen- und Protokollbeschreibung unseres Dienstes, das Service-Dokument die Adressen und Namensräume. Ebenfalls auf dieser Seite spezifizieren wir die Ziel-URL unseres Dienstes und im Falle von JavaBean den Scope, in dem die JavaBean erzeugt werden soll, z.B. pro Anfrage, nur einmal usw.


Abbildung 3: JavaBean als Grundlage eines Web Services konfigurieren

 <?xml version="1.0" encoding="UTF-8"?>

<definitions name="HandySuchBeanRemoteInterface"
targetNamespace="http://www.handysuchbean.com/definitions/HandySuchBeanRemoteInterface"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.handysuchbean .com/definitions/HandySuchBeanRemoteInterface"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">

  <message name="searchHandyRequest">
    <partname="marke" type="xsd:string"/>
    <partname="modell" type="xsd:string"/>
  </message>
  <message name="searchHandyResponse">
    <partname="result" type="xsd:string"/>
  </message>

  <portType name="HandySuchBeanJavaPortType">
    <operation name="searchHandy">
      <input name="searchHandyRequest" message="tns:searchHandyRequest"/>
      <output name="searchHandyResponse" message="tns:searchHandyResponse"/>
    </operation>
  </portType>

  <binding name="HandySuchBeanBinding" type="tns:HandySuchBeanJavaPortType">
    <soap:bindingstyle="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="searchHandy">
      <soap:operation soapAction="" style="rpc"/>
      <input name="searchHandyRequest">
        <soap:body use="encoded"
     encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
     namespace="http://localhost:8080/Handysuche"/>
      </input>

      <output name="searchHandyResponse">
        <soap:body use="encoded" 
     encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
     namespace="http://localhost:8080/Handysuche"/>
      </output>
    </operation>
  </binding>
</definitions>
Listing 1: WSDL-Binding-Datei

 Im nächsten Schritt können wir nun die einzelnen Methoden unserer JavaBean (oder EJB) selektieren, die wir als Dienste mappen möchten. Wir wählen die Methode searchHandy(String marke, String modell). Hierbei gibt es verschiedene Möglichkeiten, die Parameter und  Rückgabewerte in die SOAP-XML-Form zu bringen, so dass einfache Datentypen ohne viel Aufwand und XML-Parsing eingesetzt werden können, aber auch komplexe, benutzerdefinierte Mappings möglich sind.


Abbildung 4: Mapping der Java-Datentypen nach XML

Schließlich können wir uns noch einen Proxy und einen Testclient generieren, mit dem wir unseren Web Service auch ohne Client-Anwendung und noch vor der UDDI-Registrierung als Servlet/JSP-Anwendung ausprobieren können.

Was wurde nun erzeugt:

  • zwei WSDL-Dateien (Binding und Service)
  • der SOAP Deployment Deskriptor (dds.xml)
  • eine Webanwendung zum Testen des Dienstes
  • eine Administrationsanwendung zum Starten und Stoppen des Web Services
  • ein Client-Proxy, der den programmatischen Zugriff auf den Dienst vereinfacht

Abbildung 5: Generierter Testclient

<root>
 <isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment"
  id="http://localhost:8080/Handysuche" checkMustUnderstands="false">
   <isd:provider type="java" scope="Application" methods="searchHandy">
     <isd:java class="de.hawlitzek.jm.webservices.HandySuchBean"static="false"/>
   </isd:provider>
 </isd:service>
</root>
Listing 2: SOAP Deployment Deskriptor

Test

WSAD bietet für den Test eine Serverumgebung auf Basis des Applikationsservers WebSphere Advanced Single Server 4.0.1. Für den Test können wir die Standardkonfiguration in der WSAD-Server-Perspektive weitgehend übernehmen. Nur auf der Seite „Data source“ tragen wir noch unsere JDBC-Datenquelle mit der Handy-Datenbank ein, auf die die HandySuchBean zugreift.

Zunächst starten wir den Web Service. Dazu wechseln wir wieder in die Web-Perspektive, wählen in unserem Projekt, die Datei webApplication\admin\index.html und rufen „Run on Server“ im Kontextmenü auf. Dies startet automatisch die Testumgebung. Mit der Adminoberfläche können wir nun unseren Dienst auswählen und starten (siehe Abbildung 6).


Abbildung 6: Generierte Adminoberfläche

Analog starten wir die generierte JSP-Beispielanwendung unter webApplication\sample\TestClient.jsp.
Und so sieht ein Paar von SOAP-Nachrichten aus, die wir über den Testclient an unseren Server geschickt haben:

Request:

<?xml version='1.0' encoding='UTF-8'?>
 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <SOAP-ENV:Body>
  <ns1:searchHandy xmlns:ns1="http://localhost:8080/Handysuche"
   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <marke xsi:type="xsd:string">Nokia</marke>
   <modell xsi:type="xsd:string">6310</modell>
  </ns1:searchHandy>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Response:

<?xml version='1.0' encoding='UTF-8'?>
 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">

 <SOAP-ENV:Body>
  <ns1:searchHandyResponse xmlns:ns1="http://localhost:8080/Handysuche"
   SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <return xsi:type="xsd:string">
    http://localhost:8080/servlet/de.hawlitzek.schulung.servlet.HandyAuswahlServlet?
    marke=Nokia&amp;modell=6310
   </return>
  </ns1:searchHandyResponse>
 
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Listing 3: SOAP Request und Reponse

Deployment und Registrierung

Nachdem der lokale Test erfolgreich verlaufen ist, können wir den Web Service nun für den Betrieb fertig stellen. Dazu müssen die WSDL-Dateien so überarbeiten, dass die Pfade auf unseren Produktionsserver zeigen (statt wie in den Listings auf localhost:8080). Hierbei hilft der eingebaute XML-Editor.

Für das Deployment der Webanwendung als J2EE-EAR-Datei wird auch noch das Konfigruationsfile web.xml benötigt, das WSAD ebenfalls generiert hat. Wichtig für unseren Server ist das darin registrierte Servlet namens rpcrouter. Dabei handelt es sich um die IBM/Apache-SOAP-Implementierung, die eingehende Requests an die Web Services weiterleitet. Danach exportieren wir die gesamte Anwendung als EAR-Datei und spielen sie im Server ein.

Für die Registrierung des Dienstes in eine UDDI-Registry rufen wir „Export | UDDI“ und starten damit den IBM UDDI Explorer. In diesem Tool können Sie beliebige Registry kontaktieren, z. B. eine private, die Business Registries von IBM und Microsoft oder eine der Test Registries. Voreingestellt ist die IBM Test Registry, in der jede seine Dienste beliebiger Art kostenlos anmelden kann. Wir wählen unsere WSDL-Datei aus und können nun noch eine Beschreibung und eine Kategorisierung hinzufügen. Jetzt bleibt nur noch hoffen, das jemand unseren Dienst findet und nutzt.


Abbildung 7: Registrierung in einer UDDI-Registry

Unsere Testanwendung könnte man sinnvollerweise als Preissuche erweitern, das heißt die Suchfunktion liefert jeweils den preiswertesten Anbieter. Zusätzlich würden wir noch eine Methode für die Anbieter hinzufügen, mit der sie ihre Angebote per Web Service in unserer Datenbank registrieren bzw. updaten können.

Fazit

Die Entwicklung von Web Services ist kein leichtes Unterfangen. IBM WebSphere Studio Application Developer hilft bei der Erstellung der teilweise kryptischen Konfigrationsdateien und generiert praktische Testanwendungen. Ein kleines Manko ist die Vorgehensweise durch einen Wizard mit sehr vielen Einzelschritten. Hat man an irgendeiner Stelle einen kleinen Fehler gemacht, ist nur schwer möglich, die Korrektur nachträglich in allen betroffenen Dateien konsequent nachzuziehen. Obwohl relativ neu auf dem Markt, macht das Toolset eine gute Figur und läuft sehr stabil.

 

© 2006 Hawlitzek IT-Consulting GmbH,
Marketing&Design Kirsten Literski-Hawlitzek

Seitenanfang

Hawlitzek GmbH
Die Gründer
Dienstleistungen
Java Downloads
Vorträge
Veröffentlichungen
Kontakt
International
Sitemap