SOAP oder REST Web Service definieren immer eine Schnittstelle zu einem bestimmten Softwaresystem. Jedoch kann sich die Implementierung hinter dieser Schnittstelle jederzeit ändern. Mithilfe einer einzelnen Methode sollte man stets die aktuelle Version der Implementierung einsehen können. In diesem Beitrag zeige ich, wie so eine Methode aussehen kann und was sie beinhalten sollte.
Die Fehlerursache Nummer 1 bei Web Services ist schlicht weg die Infrastruktur. Die Web Service Technik an sich ist sehr robust, aber wenn der entsprechende Server nicht erreichbar oder überlastet ist – war die ganze Vorarbeit umsonst und man erhält eine Exception. In diesem Artikel beschreibe ich, wie man vorab einen Web Service prüfen kann.
Unglaublich aber wahr, ich fange zum ersten Mal in meiner Bloggerkarriere eine Serie an:-)
Toll oder? Aber nun zurück zum Thema: In dieser Serie geht es um gutes Web Service Design, d.h. ich berichte von Methoden und Möglichkeiten, um effektiv mit Web Services arbeiten zu können. Über folgende Themen werde ich in den nächsten Wochen ausführlich berichten:
In dem Beitrag: „Java: SOAP – Web Service Client schreiben“ habe ich gezeigt, wie man mit Hilfe von JAX-WS in sehr kurzer Zeit einen schönen Web Service Client in Java programmieren kann. Jedoch hat der Beitrag einen Makel und zwar betrachtet er den Sachverhalt nur eindimensional.
Im Klartext: Der SOAP Web Service Client spricht nur mit dem Web Service Provider, der in der WSDL angegeben ist und das ist im Worst Case Localhost.
Möchte man nun den Web Service Client und den Web Service Provider trennen, hat man ein Problem. In diesem Beitrag erweitere ich meinen SOAP Web Service Client so, dass man beliebige Web Service Provider(Endpoints) ansteuern bzw. ansprechen kann. Dies ist auch die Grundlage für verteilte Anwendungen und das Umgebungskonzept.
Am 10. Oktober 2011 habe ich behauptet, dass wirklich JEDER Java-Entwickler einen Web Service innerhalb von 15 Sekunden schreiben kann. Diese Behauptung konnte bisher keiner wiederlegen:-)
Darum behaupte ich heute, dass wirklich JEDER PHP-Entwickler einen Web Service Client in nur 10 Sekunden schreiben kann. Man brauch lediglich einen Web Service (WSDL + Endpoint) und einen php-fähigen Server (z.B. Apache). Lasst uns los legen und keine Zeit verlieren!
Nicht immer hat man die Zeit und die Lust einen Web Service Client zu schreiben. Zum Glück gibt es ein Programm namens „SoapUI“, dass diese Aufgabe effizient erledigt. Egal ob SOAP, REST oder AMF, SoapUI benötigt nur die eine WSDL (Adresse oder Datei) und einen Endpoint.
(mehr …)
In den letzten Wochen habe ich gebloggt, wie man einen sehr einfachen Web Service in Java veröffentlichen/bereitstellen kann. Jetzt es geht um die Nutzung eines Web Services. Hierfür wird ein sogenannter Client benötigt, den ich zunächst in Java implementieren werde. (Hier ist Beitrag zu PHP) Ausgangspunkt ist wieder mein Rechteck Web Service.
ACHTUNG! Für bekennende Java-Entwickler habe ich hier einen ausführlicheren Beitrag geschrieben!
Seit Java 6 gibt es die Möglichkeit, selbst geschriebene Web Service – Klassen ohne Applikationserver und/oder Includes bereitzustellen. Hierzu wird die Endpoint-Klasse aus dem Package javax.xml.ws verwendet. Als Ausgangspunkt nehme ich den Rechteck-Web Service aus dem vorherigen Beitrag.
A und O einer serviceorientierten Architektur sind sogenannte Web Services. Web Services sind technische Schnittstellen, die bestimmte Informationen und/oder Funktionen bereitstellen. Überwiegend werden Web Service zur Kommunikation zwischen verschiedenen Programmen, Systemen, etc. verwendet.
Ich behaupte, dass innerhalb von 15 Sekunden wirklich JEDER Java-Entwickler einen eignen Webservice schreiben kann! Anhand der legendären Rechteck-Klasse erläutere ich den „Code First“-Ansatz. Beachten Sie bitte, dass ich das JDK 6 benutze und mit Eclipse arbeite.
(mehr …)