Eduard’s Weblog

xsd:choice ist ein verbreitetes XML Konstrukt. Das Mapping von xsd:choice auf eine objektorientierte Programmiersprache ist jedoch nicht ganz einfach. Die JAX-RPC Spezifikation für Webservices definiert z.B. kein Mapping von xsd:choice nach Java.
So mappt ein JAX-RPC Codegenerator eine xsd:choices Typdefinition in der Regel diese auf die Klasse javax.xml.soap.SOAPElement, die Teil der SAAJ API ist. Die SAAJ API ist jedoch nicht besonders benutzerfreundlich.

Hat man die Möglichkeit das XML Schema zu verändern, so besteht die Möglichkeit eine benutzerfreundliche API zu generieren in dem man das xsd:choice Konstrukt mit Polymorphismus ersetzt. Russel Butek hat dazu einen guten Artikel mit dem Titel „Use polymorphism as an alternativ to xsd:choice“ verfasst, welcher dieses Vorgehen sehr gut und detailliert erklärt.

Ich habe die XML Schema Definition für den CustomerService Beispiel aus meinen vorgehenden Beiträgen entsprechend um das Element „Payment“ aus dem Artikel von Russel Butek erweitert und mit Apache CXF auch entsprechenden Java Source Code generiert. Das Beispiel steht zum Download bereit.

Über das WSDL Binding wird ein Webservice an ein bestimmtes Messaging Protokoll gebunden. Wird SOAP als Messaging Protokoll für ein Webservice verwendet so kann der Style entweder „RPC“ oder „Document“ sein. Der SOAP Style kann wiederum entweder „encoded“ oder „literal“ sein. Dies ergibt vier Kombinationsmöglichkeiten:

• RPC/encoded
• RPC/literal
• Document/encoded
• Document/literal

Fügt man zu dieser Liste noch das „Document/literal wrapped“ Pattern hinzu, so hat man zwischen fünf Varianten auszuwählen. Doch welche davon sollte man verwenden?

Russ Butek hat dazu einen sehr guten Artikel mit dem Titel „Which style of WSDL should I use?“ geschrieben, welcher meiner Ansicht nach die Unterschiede der verschiedenen Styles sehr gut erklärt.

Meine Empfehlung:

• Legen Sie keine konzernweite Richtlinie fest, welcher Style zu verwenden ist. Es gibt Gründe für die unterschiedlichen Möglichkeiten und die Wahrscheinlichkeit ist groß, dass man in unterschiedlichen Projekten auf unterschiedliche Probleme stößt.
• Betrachten Sie die Entscheidung über den Style als ein Teil der Implementierung. Ihre System Architektur sollte von dieser Frage unbeeinflusst bleiben.

Bei einer Diskussion mit einem Kollegen wurde ich gefragt: “Worin besteht der Unterschied zwischen SDO und DAO?” Ich hatte nicht sofort eine prägnante und zufriedenstellende Antwort parat. So beschloss ich etwas ausführlicher darüber nachzudenken:

Liest man die Java Blueprints von Sun zum DAO Pattern und den JSR-235 für SDO, so erkennt man ein gemeinsames Ziel:

Sowohl das DAO Pattern als auch die SDO Spezifikation zielen auf die Entkopplung der Geschäfts- von der Persistenzlogik und bitten eine API für einen einheitlichen Zugriff auf Daten über verschiedene heterogene Datenspeicher wie Datenbank oder XML.
Es gibt jedoch auch signifikante Unterschiede:

• DAO ist ein Design Pattern und die Entwickler müssen bei jedem Projekt die DAO Klassen manuell neu programmieren. Zwar gibt es auch diverse DAO Frameworks wie z.B. iBatis, die API und die Handhabung sind im Gegensatz zu SDO je nach Framework jedoch immer etwas unterschiedlich. Die Entwickler müssen also bei jedem neuen Projekt das jeweils eingesetzten Framework und dessen Eigenheiten neu lernen. SDO dagegen ist eine Spezifikation und ermöglicht es verschiedenen Herstellern standardkompatible Werkzeuge und Frameworks mit einer gemeinsamen API zu entwickeln. Der Entwickler kann darauf vertrauen, dass unabhängig vom tatsächlich eingesetzten Produkt die API und Handlung gleich bleibt. Auf diese Weise wird der Lernaufwand für Entwickler und damit auch die Entwicklungszeit und -kosten reduziert.
• SDO bittet eine Möglichkeit einen Daten Graph ohne direkte Verbindung zur Datenquelle zwischen verschiedenen Schichten bzw. Services auszutauschen, zu modifizieren und später wieder zurück zum Daten Access Service, wo die Änderungen auf den Datenspeicher angewendet werden, zu schicken. Das DAO Design Pattern deckt diese Anforderungen nicht ab.
• SDO spezifiziert wie eine statische, fest typisierte API aus einem Schema generiert werden kann und stellt auch eine dynamische API bereit. Der Anwender hat hier die Wahl wie er auf den Datenspeicher zugreifen möchte und kann auch beide Varianten in einer Anwendung einsetzen. DAO bittet keine dynamische Zugriffsmöglichkeit und der Entwickler ist daher gezwungen auf die Low-Level API wie JDBC zurückzugreifen wenn dynamische Zugriffe erforderlich sind.
• SDO ist für den Einsatz in einer Service orientierten Architektur ausgelegt und definiert Datentypen um die Portabilität zwischen den verschiedenen Datenspeicher und unterschiedlichen Programmiersprachen zu gewährleisten. Zum jetzigen Zeitpunkt gibt es Implementierungen für Java, C++ und PHP. Das DAO Pattern dagegen adressiert diese Problematik nicht.

Die interessantere Frage ist jedoch wann sollte DAO und in welchen Fällen SDO verwendet werden:

DAO ist eine hervorragende Wahl um die Persistenzschicht und die eingesetzten Technologien wie z.B. JDBC, EJB CMP oder Hibernate zu abstrahieren und somit den Code für den Datenzugriff vom Rest der Anwendung zu isolieren.

SDO eignet sich ausgezeichnet für Anwendungen, die in einer Service orientierten Architektur eingesetzt werden, wenn in der Umgebung unterschiedliche Programmiersprachen eingesetzt werden und Daten ohne direkte Verbindung mit der Datenquelle zwischen den Services ausgetauscht werden müssen.