computerwoche.de

Office & Collaboration

Systemkopplung via Web-Services

23.08.2007
Von Nikolai Bauer und Peter Mandl

Fazit

  • Trotz einiger Schwierigkeiten ist die Nutzung von Web-Services für diese Anwendungsfälle insgesamt positiv zu bewerten.

  • Bei heterogenen Technologieumgebungen (.NET, Java) muss man sich noch mit Kompatibilitätsproblemen befassen, die aber lösbar sind.

  • Echte Performance-Probleme traten trotz deutlicher Einbußen bei der Übertragung und beim Parsen der Nachrichten in den Projekten nicht auf.

  • Nicht Web-Services, sondern der Zugriffe auf Datenbanken stellen oft den Flaschenhals dar. Bei der Nutzung von Web-Services in der Batch-Verarbeitung sind frühzeitige Benchmarks aber unbedingt notwendig.

  • Der Einsatz von Web-Services kann insbesondere bei einfacher Transaktionsverarbeitung sehr nützlich sein, sollte aber – wie alle anderen Lösungsvarianten auch - nicht als Allheilmittel für sämtliche Architekturprobleme angesehen werden.

Nachrichtenformate und Kodierungen

Der Zusammenhang zwischen Kommunikationsmodell und Kodierungsstil ist sehr verwirrend. Daher sollen die Zusammenhänge nochmals kurz zusammengefasst werden. Das Kommunikationsmodell, also die Art und Weise, wie die Kommunikationspartner miteinander kommunizieren, ist unabhängig vom Nachrichtenformat. Prinzipiell sind Soap-Nachrichten so konzipiert, dass sie jeden beliebigen wohlgeformten XML-Code aufnehmen können.

Beim Nachrichtenformat gibt es zwei Varianten, die mit "RPC" und "Document" bezeichnet werden (siehe Binding-Element, Style-Attribut):

  • Im Nachrichtenformat "Dokument" enthält der Soap-Body ein oder mehrere Kindelemente, die als Parts bezeichnet werden. Es werden keine Soap-Kodierungsregeln für den Body angewendet. Der Aufbau der Soap-Nachricht muss zwischen den Kommunikationspartnern abgestimmt werden und wird in XML formuliert.

  • Im Nachrichtenformat "RPC" steht im Soap-Body genau ein Element, das auch noch den Namen der Operation enthält, die aufgerufen werden soll. Für jeden Parameter wird in diesem Element ein weiteres Element (Subelement) übertragen.

  • Der Wert "wrapped" im Style-Attribut gibt an, dass alle Parameter einer Operation in ein Root-Schema-Element mit dem gleichen Namen wie die Operation eingebettet sind.

Die Bedeutung des Style-Attributs lässt sich aus der Namensgebung nicht exakt ableiten, denn man kann - wie bereits angedeutet - auch mit dem Dokumentenstil einen Request-/Response-Ansatz realisieren und umgekehrt mit dem RPC-Stil (asynchrone) Nachrichten versenden.

Kodierungsstile (Der Begriff "Kodierungsstil" bezeichnet hier einen Satz von Regeln, die exakt festlegen, wie Datentypen in einer allgemein verbindlichen XML-Syntax zu kodieren sind) legen bei Web-Services die Art der Kodierung fest. Die Problematik ist aus RPC, RMI und sonstigen Techniken verteilter Kommunikation bekannt. Hier ist also festgelegt, in welcher Form eine Kodierung der Soap-Nachrichteninhalte stattfinden soll. WSDL kennt zwei Möglichkeiten:

  • "Soap-Encoding" wird im Attribut encodingStyle für beliebige Blöcke im Soap-Body oder im Use-Attribut (siehe Binding) angegeben. In diesem Fall werden spezielle Serialisierungsregeln aus der Soap-Spezifikation verwendet. Sie wird auch Section-5-Encoding genannt, da die Regeln in der Section 5 der Soap-Spezifikation festgelegt sind.

  • "Literal" wird im Use-Attribut (siehe Binding) angegeben. Bei dieser Art der Kodierung werden die Daten im Soap-Body gemäß der Festlegung in der XML-Schema-Spezifikation kodiert.

Die Kombination aus Nachrichtenformat und Kodierungsstil ergibt wiederum mehrere Möglichkeiten (Nachrichtenformat = Style-Attribut, Kodierungsstil = Use-Attribut) ergeben:

  • Style=Document/Use=Literal: Der Soap-Message-Body enthält hier ausschließlich Dokumente nach XML-Schema, dass heißt, die ganze Nachricht lässt sich vollständig validieren. Dieser Stil wird Innerhalb der Web-Service-Community als favorisierte Lösung propagiert.

  • Style=RPC/Use=Literal: Hier werden die Soap-Nachrichten als RPC-Aufrufe mit Parametern und Returncodes realisiert. Jede Nachricht hat einen eigenen Schematyp. Die Datentypen der Parameter werden in der Nachricht nicht explizit angegeben, sondern sie ergeben sich aus der konkreten Schema-Beschreibung.

  • Auch die Kombination Style=RPC/Use=Encoded ist möglich. Diese Kombination wird aufgrund der mangelnden Interoperabilität nicht mehr von allen Standards und Herstellern unterstützt. Er wurde eingeführt, als es noch kein WS-I-Basic-Profile (siehe unten) gab. Heute verfügbare Web-Service-Implementierungen nutzen diesen Kodierungsstil aber noch sehr häufig.

Anmerkung: Man sollte sich bei der Entwicklung von Web-Services auf die Kombination Style=Document/Use=Literal oder Style=RPC/Use=Literal beschränken. Hier gibt es Unterschiede im Nachrichtenaufbau, aber alle Web-Service-Plattformen dürften diese beiden Kombinationen kennen. Will man ganz sicher gehen, dass Web-Services auch in heterogener Umgebung funktionieren, so ist die Kombination Style=Document/Use=Literal am besten, da diese auch von .NET verwendet wird. Soap-Encoding sollte nicht mehr verwendet werden.