Webservice Config / SoapStub: Best Practice

[Bär]

Hallo!

Ich habe verschiedene Systeme/Server auf denen eine Applikation läuft: DEV, TEST, und LIVE. Nun habe ich in DEV einen Test WebserviceClient implementiert, der einen TEST Webservice auf einem fremden System aufruft. Soweit, so gut...

Letztendlich soll mein WebserviceClient im LIVE System auf den LIVE Webservice des fremden Systems zugreifen. Um also sauber zwischen den Systemen zu deployen, sollten die URL`s im WebserviceSoapStub ausgelagert werden. So, dass der Aufruf des Webservices von dem umgebenden System abhängt (DEV/LIVE).

Nun gibt es viele Möglichkeiten die URLs auszulagern aber keine meiner Ideen erscheint mir richtig gut. Wie macht ihr das?

Danke und Gruß!

 

[DerFeivel]

Hallo!

Ich habe verschiedene Systeme/Server auf denen eine Applikation läuft: DEV, TEST, und LIVE. Nun habe ich in DEV einen Test WebserviceClient implementiert, der einen TEST Webservice auf einem fremden System aufruft. Soweit, so gut...

Letztendlich soll mein WebserviceClient im LIVE System auf den LIVE Webservice des fremden Systems zugreifen. Um also sauber zwischen den Systemen zu deployen, sollten die URL`s im WebserviceSoapStub ausgelagert werden. So, dass der Aufruf des Webservices von dem umgebenden System abhängt (DEV/LIVE).

Nun gibt es viele Möglichkeiten die URLs auszulagern aber keine meiner Ideen erscheint mir richtig gut. Wie macht ihr das?

Danke und Gruß!

Hat es spezielle Gründe, warum der DEV-Service auf den TEST-Service zugreift?
Der Sinn an der Trennung Entwicklung/Test/Produktion ist ja, dass man in den unterschiedlichen Phasen der Entwicklung jeweils ein gleich konfiguriertes System zur Verfügung hat.

Welche Ideen hast du denn?


Wenn du es besonders dynamisch haben möchtest, könntest du eine Konfiguration über JMX umsetzen.

 

[Bär]

@DerFeivel: Es gibt eine Dev-Welt für mich, eine Test-Welt für die Anwender und eine Live-Welt. Und natürlich greift keine Welt in die Andere. Vielleicht habe ich mich da etwas unverständlich ausgedrückt.

Das Problem ist, dass ein in Eclipse angelegter WebserviceClient automatisch, an mehreren Stellen URLs in die 5 Klassen des Clients schreibt. Verbinde ich in der Test-Welt einen Test-Webservice, ist das also fix. Mit dem Release über die Test-Welt in die Echt-Welt soll dann natürlich der Client den Echt-Webservice ansprechen.

Meine Ideen zur Lösung:

-Programmatisch: Feststellen in welcher Umgebung sich der Client befindet und dann die URLs entsprechend setzen.

-Konfiguration: Auslagern von URLs in eine myWsClient.conf, die dann auf den Systemen unterschiedlich ist.

-Über den Release Prozess: Da der Client einmalig und automatisch auf jedem System angelegt wird, reicht ein einmaliges einchecken in SVN. Danach die automatisiert erzeugten Klassen aus dem SVN entkoppeln. Dann überschreibt die Test Variante nicht die Echt Variante.

Wie gesagt: So richtig toll ist davon nichts. Ich werde jetzt erstmal die Test Welt fertig bauen. Vielleicht fällt mir dann ja etwas besseres ein.

 

[DerFeivel]

@DerFeivel: Es gibt eine Dev-Welt für mich, eine Test-Welt für die Anwender und eine Live-Welt. Und natürlich greift keine Welt in die Andere. Vielleicht habe ich mich da etwas unverständlich ausgedrückt.

Das Problem ist, dass ein in Eclipse angelegter WebserviceClient automatisch, an mehreren Stellen URLs in die 5 Klassen des Clients schreibt. Verbinde ich in der Test-Welt einen Test-Webservice, ist das also fix. Mit dem Release über die Test-Welt in die Echt-Welt soll dann natürlich der Client den Echt-Webservice ansprechen.

Meine Ideen zur Lösung:

-Programmatisch: Feststellen in welcher Umgebung sich der Client befindet und dann die URLs entsprechend setzen.

-Konfiguration: Auslagern von URLs in eine myWsClient.conf, die dann auf den Systemen unterschiedlich ist.

-Über den Release Prozess: Da der Client einmalig und automatisch auf jedem System angelegt wird, reicht ein einmaliges einchecken in SVN. Danach die automatisiert erzeugten Klassen aus dem SVN entkoppeln. Dann überschreibt die Test Variante nicht die Echt Variante.

Wie gesagt: So richtig toll ist davon nichts. Ich werde jetzt erstmal die Test Welt fertig bauen. Vielleicht fällt mir dann ja etwas besseres ein.

Mit Anwender meinst du Tester, oder 😀😉 ?

Wieso versuchst es nicht mit einer Kombination?

Systemspezifische Konfiguration der URLs in Config-Dateien auslagern.
Diese programmatisch auslesen.
Und die Config im Buildprozess - abhängig für was gebaut werden soll - im jeweiligen erzeugten Artefakt (also bspw. in die .war) einsetzen.