Wie bereits berichtet wird EJOE 0.4.0 u.a. Unterstützung für abstrahierte Remote Services in Form einer Crispy-Erweiterung mitbringen. Im Zuge dessen habe ich mich nun endlich auch mal mit WSIF (Web Services Invocation Framework) auseinandergesetzt. (Wenn jemand jetzt noch nichts von WSIF gehört hat, sollte er evtl. vorm weiterlesen mal diesen Artikel im Java Magazin überfliegen…)

Mit WSIF ist es u.a. möglich nicht-service-orientierte Architekturen über WSDL Beschreibungen service-fähig zu machen – vorausgesetzt es existieren die entsprechenden WSDL-Erweiterungen sowie eine entsprechende Providerimplementierung für WSIF.

Kurz und knapp aus EJOE-Sicht: Rein theorethisch könnte man EJOE mittels WSIF-Unterstützung in der Form service-fähig machen, dass…

• ein Client EJOE abstrahiert benutzen kann (keine direkte Bindung an EJOE oder eine andere Transportschicht, z.B. SOAP)
• EJOE-Serveroperationen aussagekräftig beschrieben (WSDL) und rein anhand der Beschreibung benutzt werden können
• EJOE-Serveroperationen ohne Änderungen am Client-Code bspw.durch SOAP-Dienste ersetzt werden können (und natürlich ungekehrt)
• somit bspw. im Hinblick auf EJOE als Erweiterung von Legacy-Anwendungen bestehende Funktionen dieser mit EJOE “aufgebohrten” Legacy-Anwendungen entschieden leichter auch für Schnittstellenpartner zur Anbindung freigegeben werden könnten, da diese Funktionen plötzlich als sehr standardnahe Services zur Verfügung gestellt werden könnten

Ok, ok, die meisten der obigen Punkte deckt Crispy ebenfalls ab, aber:
WSIF…

• scheint verbreiteter als Crispy zu sein
• ist durch seine WSDL-Nähe weitaus konformer zu bestehenden Standards
• weist einen höheren Abstraktionsgrad als Crispy auf, die konkrete Client-Bindung wird auf die austauschbare WSDL reduziert
• wird von der Apache-Foundation (und IBM) vorangetrieben, was für eine gewisse Sicherheit in punkto Wartung, Support und langfristige Weiterentwicklung sorgt

Auf der anderen Hand ist die Implementierung einer WSIF-Erweiterung aufwendiger und schwieriger als bei Crispy. Darüber hinaus lässt sich mit Crispy – ohne dass ich das jetzt auf Anhieb konkretisieren könnte – irgendwie leichter programmieren. Konzept verstehen, Executor einbinden – fertig. Das ist bei WSIF auf Grund WSDL-Basis und höherer Abstraktion alles ein bisschen aufwendiger – sowohl bei der Einarbeitung als auch bei der Programmierung.

Conclusion: Mit WSIF-Support könnte EJOE einen ganz wichtigen Schritt vom reinen Client/Server IO-Framework zu einem sehr standardnahen ServiceLayer machen. EJOE würde weiterhin seine Vorteile wie die leichte Integration und Anbindung, problemlose Objektserialisierung sowie sehr schnelle, lastfähige Netzwerkkommunikation auspielen und zusätzlich den Nachteil fehlender Unterstützung von Standards überwinden – oder zumindest stark verringern.

Da wir manchmal auch von der schnellen Sorte sind und uns WSIF-Unterstützung sehr vorteilhaft und wünschenswert erscheint, ist die Arbeit an WSIF-Erweiterungen für EJOE 0.4.0 mit Unterstützung von MultiObject-ServerHandlern sowie Remoting ServerHandlern (Remote Reflection) bereits im Gange. Die notwendigen WSDL-Erweiterungen wurden definiert und implementiert. WSIF-Provider, -Port und -Operation (siehe Providers und Developers Guide) sowie entsprechende Testcases sind in Arbeit und werden bereits im ersten Milestone (0.3.9.1) enthalten sein…

Leave a Reply

Using Gravatars in the comments - get your own and be recognized!

XHTML: These are some of the tags you can use: <a href=""> <b> <blockquote> <code> <em> <i> <strike> <strong>