Hallo, willkommen zum ersten Teil meiner 3-Artikelserie über die Entwicklung von SOAP-basierten Anwendungen mit Java. Bei dieser Serie handelt es sich nicht um eine detaillierte Beschreibung des SOAP-Protokolls, sondern lediglich um ein Schnellstart-Tutorial, das zeigt, wie wir Java und SOAP gemeinsam verwenden können. Im ersten Teil werde ich die grundlegende Anatomie von SOAP, die Installation von Apache SOAP 2.2 und Konfigurationsprobleme mit Jakarta Tomcat 3.2.1 behandeln und eine sehr einfache SOAP-Anwendung entwickeln, bereitstellen und ausführen. In Teil 2 der Serie werde ich einen komplexeren Java-Bean-basierten SOAP-Dienst entwickeln und in Teil 3 werde ich Ihnen eine Vorstellung von anderen komplexen Aspekten von SOAP geben. Dann fangen wir an.
Anatomie von Seife
Das Simple Object Access Protocol oder SOAP ist im Wesentlichen darauf ausgelegt, einen sehr einfachen und leichten Mechanismus zum Austausch strukturierter Informationen in einer dezentralen und verteilten Umgebung bereitzustellen. Es handelt sich im Wesentlichen um ein Modell zum Kodieren von Daten in einem standardisierten XML-Format, das in verschiedenen Situationen wie Messaging und Remote Procedure Calls (RPC) verwendet werden kann. Die SOAP besteht aus drei wesentlichen Teilen:
- Umschlag: Dies ist das XML-Element der obersten Ebene oder das Stammelement in einer XML-codierten SOAP-Nachricht. Der Umschlag enthält oder kann notwendigerweise die folgenden Informationen enthalten, wie den Empfänger der Nachricht, den Inhalt der Nachricht und die Verarbeitungsanweisung der Nachricht.
- Kodierungsregeln: Die Kodierungsregeln geben die Art und Weise an, wie die anwendungsdefinierten Datentypinstanzen ausgetauscht werden.
- RPC: Die Remote Procedure Call- oder RPC-Darstellungen definieren eine Konvention für die Darstellung der Remote Procedure Calls und der Antworten darauf.
Um die drei Teile der SOAP-Nachricht zu verstehen, betrachten wir eine beispielhafte SOAP-Nachricht:
POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Inhaltstyp: text/xml; charset="utf-8"Content-Length: nnnn SOAPAction:"Some-URI" DIS
Das obige Beispiel zeigt eine typische SOAP-Nachricht in einer HTTP-Anforderungsbindung. Das Envelope-Element ist Namespace-qualifiziert (SOAP-ENV), um es von allen anderen anwendungsspezifischen Bezeichnern zu trennen. Dieses Element enthält auch Informationen zur Namensraumkodierung. Das unmittelbar untergeordnete Element des Umschlags ist in diesem Beispiel das Body-Element. Dieses Element MUSS in einer SOAP-Nachricht vorhanden sein und enthält die Informationen über den Namen der aufzurufenden Remote-Prozedur (GetLastTraderPrice) und kodiert außerdem die für die Remote-Prozedur erforderlichen Parameter. In dieser speziellen Nachricht benötigt das Remote-Verfahren den Namen des Unternehmens (DIS), von dem der letzte Handelspreis abgerufen werden soll. Optional enthält das Body-Element Informationen zu allen Fehlern, die während des RPC aufgetreten sind, und wird in einem Fault-Element codiert. Das Fault-Element enthält die Fehler-/Statusinformationen mit einer SOAP-Nachricht und kann, falls vorhanden, nur einmal als untergeordnetes Element des Body-Elements erscheinen.
In komplexen Fällen von SOAP-Nachrichten kann das Envelope-Element ein weiteres untergeordnetes Element namens Header enthalten. Wenn dieses Element in einem SOAP-Envelope vorhanden ist, muss es das unmittelbar untergeordnete Element des Envelope-Elements sein. Das Header-Element kann normalerweise Informationen zur Authentifizierung, Transaktionsverwaltung usw. enthalten. In unserem speziellen Beispiel würden wir diese Header-Informationen jedoch nicht verwenden. Ebenso hat ein SOAP-Antwortdokument eine ähnliche Struktur.
HTTP/1.1 200 OK Inhaltstyp: text/xml; charset="utf-8"Inhaltslänge: nnnn 34.5
Das Envelope-Element enthält das Body-Element, das wiederum die angeforderten Informationen oder eine Fehlerzeichenfolge enthält, falls während des Serviceabrufs ein Fehler generiert wird.
Umgebung einrichten
Nachdem Sie die Binärdistribution der SOAP-Version 2.2 heruntergeladen haben, entpacken Sie sie in einen Ordner in Ihrem System. Obwohl SOAP mit jedem Servlet/JSP-Container funktionieren kann, werden wir Jakarta Tomcat 3.2.1 für unser Modell wählen. Sobald Sie den Tomcat in Ihrem System eingerichtet haben,
- Gehen Sie in das Verzeichnis /lib Ihrer Soap-Installation und kopieren Sie die Datei Soap.jar in das Verzeichnis /lib der Tomcat-Installation.
- Holen Sie sich die Datei xerces.jar und platzieren Sie sie im Verzeichnis /lib der Tomcat-Installation. Hier ist nun ein Punkt. Tomcat wird bereits mit parser.jar und jaxp.jar geliefert. Daher besteht ein potenzieller Konflikt mit der neu installierten xerces.jar. Um es zu umgehen:
- Bearbeiten Sie die Datei tomcat.bat und gehen Sie zu dem Abschnitt, in dem der Klassenpfad festgelegt wird. Stellen Sie den Klassenpfad von xerces.jar davor, sodass xerces.jar zuerst im Klassenpfad geladen wird.
- Platzieren Sie die Datei „soap.war“ aus dem lib-Verzeichnis der SOAP-Binärdistribution und platzieren Sie sie im Verzeichnis /webapps des Tomcat. Sobald Sie Tomcat neu starten, wird diese Soap.war-Datei erweitert.
- Starten Sie nun Tomcat neu.
Damit Sie das Befehlszeilendienstprogramm zum Bereitstellen und Verwalten der Dienste sowie zum Ausführen des SOAP-Clients verwenden können, den wir entwickeln werden, muss die Systemumgebungsvariable CLASSPATH die folgenden .jar-Dateien enthalten:
- Seifenglas
- aktivierung.jar
- mail.jar
- xerces.jar
