Webdienste sind Standards, die für den Datenaustausch über das Web definiert sind. Das bedeutet nicht, dass Webdienste dem Internet zugänglich gemacht werden, sondern lediglich, dass es einen vereinbarten Satz von „Webstandards“ gibt, die von vielen Produkten unterstützt werden. Bei der Entscheidung, welche Norm übernommen werden soll, ist oft der Rat des technischen Personals das Wichtigste.
Sie empfehlen Ihnen möglicherweise einen Standard, der am einfachsten zu implementieren ist, den umfassendsten technischen Support für das Produkt bietet und am wahrscheinlichsten in Ihrer Umgebung gut funktioniert. Für eine erfolgreiche SOA-Implementierung, die sich bewährt und auch in Zukunft skaliert, sind alle drei Faktoren äußerst wichtig.
WS-I
Die Web Services Interoperability Organization (WS-I) ist auf die Entwicklung von Best Practices für Webstandards spezialisiert, um die Interoperabilität zwischen verschiedenen Betriebssystemen, Plattformen oder Programmiersprachen sicherzustellen. WS-I ist für die Definition von Best-Practice-Dokumenten wie Web-Service-Sicherheit und technischen Spezifikationen für die Web-Service-Verarbeitung verantwortlich. Diese Dokumentation hilft Entwicklern und Unternehmen dabei, sich an Praktiken zu halten, die andere verwenden, um die Benutzerfreundlichkeit sicherzustellen.
WS-I veröffentlicht außerdem technische Spezifikationen, Testsuiten und Beispiele für die Bereitstellung dieser Protokolle. Tatsächlich ist WS-I ein Leitungsgremium, das von vielen Organisationen wie Microsoft und IBM gebildet wird und dessen Aufgabe es ist, interoperable Webdienste zu fördern.
Nutzungsvereinbarung
Webdienste sind auf Protokolle angewiesen, um sicherzustellen, dass die Kommunikation sinnvoll ist. Der Inhalt der zwischen Diensten gesendeten Daten muss zuvor vereinbart werden, um sicherzustellen, dass beide Parteien wissen, welche Inhalte empfangen werden. SOAP ist ein Beispiel für das am weitesten verbreitete Protokoll beim Datenaustausch. SOAP verwendet die Programmiersprache XML und ermöglicht es beiden Parteien, die gesendeten Informationen zu dekodieren und die hin- und hergesendeten Informationen zu formatieren.
veranschaulichen
Wir werden bald auf einige Architekturen eingehen und auch auf einige Webdienstprotokolle verweisen. Es ist wichtig, diese beiden Dinge nicht zu verwechseln. Lassen Sie uns es im Folgenden kurz vorstellen.
Softwarearchitekturen wie REST und RPC sind keine Protokolle. Dabei handelt es sich um Methoden, die festlegen, wie die Vereinbarung umgesetzt werden soll.
WSDL (Web Services Description Language) ist eine Sprache, die verwendet wird, um einen bestimmten Webdienst auf formatierte Weise zu beschreiben, damit Anwendungen den Dienst analysieren können. WSDL selbst stellt keine Funktionalität in Form von Webservices-Interaktionen bereit.
Die Protokolle selbst, etwa SOAP, XML-RPC oder DCOM, legen genau fest, wie Nachrichten zugestellt werden und wie ein Programm die empfangenen Daten versteht.
Es gibt zwei Haupttypen von Architekturen in SOA: die RPC-Protokollfamilie und den Representational State Transfer (REST)-Ansatz.
RPC
Mit der RPC-Methode (Remote Procedure Call) können Programmierer Ressourcen eines Remote-Systems aufrufen, genau wie beim Programmieren auf einem System lokale Ressourcen „aufrufen“. Der Nachteil von Diensten im RPC-Stil besteht darin, dass die Benutzer sie tendenziell so verwenden, als ob sie mit der Programmiersprache auf der jeweiligen Plattform vertraut wären. Es ist sogar einfach, eine Remote-Prozedur aufzurufen, wenn sie mit der lokalen Prozedur identisch ist.
Diese Logik verstößt gegen das Konzept der „losen Kopplung“. Das Konzept der losen Kopplung bedeutet eigentlich, dass der Remote-Prozess nicht von einem bestimmten Betriebssystem oder einer bestimmten Programmiersprache abhängen sollte.
SOAP ist das Nachfolgeprotokoll von XML-RPC und lediglich ein Remote-Prozeduraufruf, der seine Informationen in XML enthält. SOAP verwendet zum Senden von Daten das HTTP-Protokoll, was zwar schön und einfach ist, aber auch einige Nachteile mit sich bringt. Dennoch verwenden die meisten Webdienste heutzutage immer noch das HTTP-Protokoll für die Kommunikation, da sie auf dem SOAP-Protokoll basieren.
AUSRUHEN
Der Representational State Transfer (REST)-Ansatz unterscheidet sich grundlegend von Remote-Prozeduraufrufen, da er auf einer anderen Ebene funktioniert. Ein REST-Aufruf sieht aus wie jede andere Webanforderung über das HTTP-Protokoll, während ein RPC-Aufruf wie ein Standardfunktionsaufruf aussieht. Der Schwerpunkt von REST liegt auf dem Betrieb mit stabilen Ressourcen und nicht auf einzelnen Nachrichten, was zu einer standardisierten und allgemein verständlichen Art der Interaktion führt, ähnlich wie beim HTTP-Protokoll selbst. REST übernimmt die Übertragung einfacher Datenblöcke, während RPC komplexe Prozesse überträgt.
Sollte REST oder RPC verwendet werden?
Die Frage, ob REST verwendet werden soll, ist sicherlich eine gute Frage. Es scheint der Weg der Zukunft zu sein. Allerdings muss Ihre SOA in jede Software integriert werden, die Sie derzeit verwenden. Die Einführung von REST verlief langsam, hauptsächlich aufgrund der Webservice-Unterstützung. Obwohl ein REST-System WSDL verwenden kann, um eine SOAP-Nachricht über HTTP zu beschreiben, gibt es nicht genügend Unterstützung, um es tatsächlich zu verwenden. Beispielsweise unterstützt Apache nicht einmal die Methoden, die zur Verwendung von REST erforderlich sind, ohne das Plug-in-Modul zu installieren.
Es gibt andere Standards, die nicht zur Familie der Webdienste gehören. Aber wie zu erwarten ist, finden diese Standards keine breite Unterstützung. Jini, WCF und CORBA sind einige Beispiele. Wenn Ihnen ein Anbieter ein Produkt anbietet, das nur eine der oben genannten Technologien unterstützt, möchten Sie weglaufen, nicht weggehen. Webdienste werden mittlerweile weitgehend unterstützt. Die Nutzung von Webdiensten wird weiter zunehmen. SOA selbst gilt als neu, instabil und riskant. Diese Risiken können jedoch weitgehend gemindert werden, wenn Sie einen geeigneten Webdienststandard wählen, der über umfassende technische Unterstützung verfügt.
Schließlich ist das Festhalten an SOAP der alten Schule anstelle eines Systems im RPC-Stil derzeit ein praktikabler Mechanismus für die Erstellung von SOA mithilfe von Webdiensten. Wenn Sie dies tun, verringern Sie die Wahrscheinlichkeit einer Lieferantenbindung erheblich.