Seid einer ganze Weile habe ich mich jetzt schon mit WebServices auseinander gesetzt und sitze momentan daran einen WebService zu implementieren, der eine Java-Application mit einer .Net-Application koppelt. Zu diesem Zweck wurden zunächst einmal Contracts in Form von WSDLs erzeugt. Aus diesen sollten dann später die eigentlichen Services und Clients erzeugt werden. Leider musste ich dabei feststellen, dass die Unterstützung einen Service aus einer WSDL zu generieren in Microsofts .Net 3.0 WCF (Indigo) doch ziemlich mager ist. Ich habe bereits einige Webcasts gesehen und auch diverse Artikel gelesen in denen immer wieder propagiert wird, dass ein “Contract-First”-Ansatz der richtige (sofern man hier überhaupt von richtig und falsch sprechen kann) Weg sei einen WebService zu entwickeln. Stellt sich mir nur die Frage, was ist der richtige Contract dazu.

Aus Microsofts Sichtweise scheint wohl der richtige Weg einen Service Contract zu beschreiben eine Interface Definition z.B. in C# zu sein. Eine WSLD (mit XSD und Policies und …) scheint nur als eine Art Nebenprodukt angesehen zu werden, das zur Laufzeit generiert wird. Aber ist das wirklich der richtige Weg um Contracts aufzusetzen?

Meiner Ansicht nach nicht.

Wie soll beispielsweise eine Java-Application einen solchen in C# verfassten Contract verstehen? Ich persönlich würde auch niemals einen in Französisch verfassten Arbeitsvertrag unterschreiben, weil ich Ihn nicht verstehen würde. Erst wenn die Firma mit der ich einen solchen Vertrag abschließen würde, mir diesen in Deutsch vorlegen würde, könnte ich ruhigen gewissens unterschreiben, da ich dann auch wirklich verstehen kann, was in diesem Vertrag festgelegt wird.

Was ich sagen will ist, dass ein Contract in einer Sprache geschrieben sein muss, die beide Seiten verstehen können. In diesem Fall sollte man doch wohl WSDL als den eigentlichen wahren Contract ansehen! Daher ist mir absolut unverständlich, warum die Unterstützung in der WCF dabei so schlecht ist. Jetzt kann natürlich jeder argumentieren, dass die zur Laufzeit generierte WSDL als ein solcher Vertrag genutzt werden kann. Die Entwicklung des WebServices für die Kopplung der bereits oben erwähnten Systeme zeigt mir aber eindeutig, dass die Übersetzung der nativen Programmiersprache zu WSDL, XSD und so weiter zur Laufzeit die Interoparabilität stark gefährdet und einem doch einige Steine in den Weg legt. In der Realität werden aber gerade SOA-Applications durch eine ganzen Haufen von unterschiedlichsten Programmiersprachen und Framworks umgesetzt.

Leider scheint diese Tatsache viele Entwickler nicht zu stören und sie entwickeln ihre Software weiterhin einfach in ihrer “gewohnten Umgebung” ohne sich um solche Dinge wie Interoparabilität Gedanken zu machen. Nichtsdestotrotz ändert das die Realität nicht – WSDL bleibt der wahre Contract, da dort die eigentliche Übereinkunft der beiden Parteien festgelegt wird. Schließlich interessiert einen Client auch nicht in welche nativen Programmiersprache ein Service implementiert wurde oder welches Framework dem zu Grunde liegt. Der Service stellt einfach seinen Contract (WSDL) zur Verfügung, der Client stimmt diesem zu und weiss was die Implementierung auf der Gegenseite macht und weiss auch was von ihm erwartet wird zu tun.

Nicht das mich jemand falsch versteht, ich finde den “Contract-First”-Gedanken absolut richtig, nur sollte es mehr Tools und Entwicklungsumgebungen geben, die diesen Gedanken auch wirklich aufgreifen und den wahren Contract an den Anfang der Implementierung stellen.

Im The ServerSide Interoperability Blog findet sich ein interessantes Gespräch zwischen Ted Neward und Adrian Trenaman zum Thema.

Image is taken from photocase.com uploaded by kn!ps.