Austausch von Webservices

[andy_engel]

Hi Leute,

ich habe da mal ne Frage zum Austausch von Webservices.

Es geht um folgendes:

Wir testen unsere Entwicklungen mit einem automatisierten Testtool. Im testtool kann über das Kontextmenü ein neues Ticket in Jira erzeugt werden. Das Testtool nutzt die SOAP Schnittstelle eines Bug-Tracking-Tools (Jira).

Wir überlegen nun ein eigenes Bugtracking-Tool zu entwicklen, das anstelle von jira genutzt werden soll. Jetzt zum Problem. Unser Testtool kommuniziert über die SOAP Schnittstelle mit dem Bug-Tracking-Tool Jira. Das Testtool wird nicht bei uns entwickelt - es ist ein externes Tool. Das Testtool wurde bereits angepasst, damit es mit Jira über SOAP kommunizieren kann.

Damit für das testtool keine neue Schnittstelle programmiert werden muss, habe ich überlegt die vorhandene Schnittstelle zu Jira zu nutzen.

Ist soetwas möglich?

SO habe ich es versucht:
Ich habe also die WSDL vom Jira SOAP Service genutzt um mit Eclipse den Web Service aus der WSDL generieren zu lassen. Da hat auch geklappt. Danach habe ich den Webservice in meinen JBoss deployed. Der Webservice ist ansprechbar.

Nun habe ich im Testtool die URL zur SOAP Schnittstelle angepasst - ich habe die URL zur WSDL auf meinem Jboss gesetzt.

Wenn ich jetzt im Testtool ein Ticket in Jira erzeugen möchte erhalte ich die Fehlermeldung:

Fehlgeschlagen: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.


Hat jemand hier eine Ahnung wie ich den Web Service austauschen kann, sodass die vorhandene Schnittstelle genutzt werden kann?

 

[grinser]

Verstehe ich das richtig, dass du aus der WSDL ein Service Skeleton erstellt hast?

Soweit ich das beurteilen kann ist dies nur ein Skeleton ohne Businesslogik. Zum anderen sind Web Services gerade dafür gedacht sie wiederzuverwenden. Warum also ein eigenen Service entwickeln, wenn es mit dem aktuellen läuft? Gerade dies ist das Konzept von SOA.

 

[JohannisderKaeufer]

Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Die Fehlermeldung klingt sehr stark nach Microsoft .Net C# VB.


Zusammengefasst:
Bisher:
Testtool === SOAP (over HTTP) ===> JIRA

Nun:

Testtool === SOAP (over HTTP) ===> Skeleton auf JBoss

Meine Vermutung die Fehlermeldungen entstammen dem Testtool.
Eine weitere Vermutung, die Fehlermeldungen entstehen, da der Skeleton keine korrekte Antwort liefert, da es nur ein Skeleton ist.

Mein Vorschlag:

Testtool === SOAP (over HTTP) ===> Skeleton auf JBoss (als Proxy Implementieren) === SOAP (over HTTP) ===> JIRA

Also erstmal JIRA weiter als Backend nutzen und den Webservice als Proxy vermitteln lassen, bis man die eigene Implementierung fertig hat. (Frei nach dem Motto, wenn das Testtool eine korrekte antwort bekommt, sollten die Fehlermeldungen verschwinden)

Meine Empfehlung:
Schau dir das Thema ESB (Enterprise Service Bus) genauer an. Die Implementierungen von Sun (OpenESB), JBoss ESB (kenne ich leider nicht) bringen für diese Szenarios schon ein gutes Tooling mit.

Testtool === SOAP (over HTTP) ===> ESB === SOAP (over HTTP) ===> JIRA
                                       === beliebiges Protokoll ===> beliebiges Backend

Skeletons aus WSDL-Dateien generieren und andere lästige Dinge bleiben einem dann oftmals erspart.

 

[DerFeivel]

Meine Empfehlung:
Schau dir das Thema ESB (Enterprise Service Bus) genauer an. Die Implementierungen von Sun (OpenESB), JBoss ESB (kenne ich leider nicht) bringen für diese Szenarios schon ein gutes Tooling mit.

Wozu an dieser Stelle ein ESB????:L

Du führst hier, m.E. völlig ohne Grund, zusätzliche Abstraktionen und Technologien ein. Da er scheinbar schon mit SOAP allein kleinere Probleme hat sicherlich nicht sehr zielführend.


@andy_engel:

Hast du deine Webservice-Implementierung mal in SoapUI getestet?

Allgemein:

Hast du eine vollständige Beschreibung des genutzten Funktionsumfangs der aktuellen Webservice-Schnittstelle? (eventuell Log's des Testtools, welche die Dienstanfragen mitloggen?)

Wenn ja, würde ich mir die (aus der Funktionsbeschreibung resultierenden/geloggten) Anfragen als Testfälle in SoapUI hinterlegen.
Gegen diese Testfälle kannst du dann deine Webservice-Schnittstelle implementieren, so dass sie dann für das neue Bugtracking-Tool das gleiche Verhalten bereitstellt wie für Jira