michoLee: Was ist SOA / WSDL

Hallo Leute,
ich verstehe leider nicht ganz den Unterschied der folgenden Begriffe:

SOA
SOAP
WSDL
Web Service

  1. Liege ich in etwa richtig: SOA (Serviced Orientied Architecture) ist einfach nur die Beschreibung der Architektur, so dass eine Applikation auch Services von anderen Applikationen nutzen kann.

  2. WSDL wäre dann auf Basis von XML die Beschreibung eines Services. (Bsp. Welche IP, welcher Port, wie heißt die Methode, welchen Rückgabewert gibt es usw.)
    Dieser Service könnte dann zum Beispiel (1st Generation) auf einem zentralen "Service Registry" liegen, wo man allgemein die Anfragen stellen kann, wenn man einen Service benutzen will.

  3. SOAP ist dann anschließend nur das Protokoll, um den Service direkt beim Service Provider zu nutzen. (Damit Sie sich auch verstehen). Generell könnte man diese SOAP-Nachrichten über HTTP, aber auch über Email oder sonstige Wege verschicken.

  4. Wenn man WebService hört, meint man eigentlich WSDL damit?

a) Liege ich mit meinem Verständnis richtig? (Nur grob)
b) Wie wird eigentlich es eigentlich gehandled, wer einen bestimmten Service auch nutzen darf oder nicht. (Auf welcher Ebene werden die Einschränkungen und Berechtigungen gemacht?
c) Ich habe noch diese Grafik gefunden, bei dem es in der Mitte einen Umsetzer geben soll. Sprich, wenn ich als Requestor Java benutze aber der Provider PHP hat, setzt die "Core Service Logic" die Umsetzung von Java zu PHP zum. Web Service Link
c1) Was versteht man unter Service Contract?
c2) Liegt diese "Core Service Logic" dann beim Provider, der beim Aufruf eingesetzt wird? (Warum ist dann aber dahinter nochmal ein "Message Processing Logic"?

Über kleine Tipps wäre ich euch sehr dankbar. Mir geht es wirklich nur um das grobe Verständnis, deshalb würden mir auch nur sehr grobe Antworten ausreichen, falls es zu meinem Verständnis beiträgt. (Mein Script ist da etwas verwirrend. Vor allem, was 1st Generationd und 2st Generation Web Service betrifft. Da werden auch die Wörter so umeinander geworfen, da versteht man nicht mehr, wo vorne oder hinten ist, deshalb meine evtl. blöden fragen oben.

Grüße an alle

  1. Hi!

    1. Wenn man WebService hört, meint man eigentlich WSDL damit?

    Nein, sondern SOAP oder andere Systeme, die konkret Daten liefern. WSDL ist nur eine Beschreibung eines SOAP-Diesnstes und nicht dafür notwendig.

    a) Liege ich mit meinem Verständnis richtig? (Nur grob)

    Ansonsten ja.

    b) Wie wird eigentlich es eigentlich gehandled, wer einen bestimmten Service auch nutzen darf oder nicht. (Auf welcher Ebene werden die Einschränkungen und Berechtigungen gemacht?

    Da es mehrere Arten Webservice gibt, kann man das auch auf mehrere Arten realisieren. HTTP-Authentication wäre eine, der Aufruf einer speziellen Anmeldeprozedur und anschließend immer Tokens mitreichen wäre eine andere.

    c) Ich habe noch diese Grafik gefunden, bei dem es in der Mitte einen Umsetzer geben soll. Sprich, wenn ich als Requestor Java benutze aber der Provider PHP hat, setzt die "Core Service Logic" die Umsetzung von Java zu PHP zum. Web Service Link

    Es werden Daten ausgetauscht. Diese unterscheiden sich - wenn man den Webservice universal anlegen will - nicht zwischen irgendwelchen Programmiersprachen. Man nimmt eher ein universelles Dateiformat, wie XML oder JSON.

    c1) Was versteht man unter Service Contract?
    c2) Liegt diese "Core Service Logic" dann beim Provider, der beim Aufruf eingesetzt wird? (Warum ist dann aber dahinter nochmal ein "Message Processing Logic"?

    Ich passe.

    Lo!

    1. Hi,

      Ansonsten ja.

      hey danke für alle Antworten. Bin etwas erleichtert, dass ich auf dem richtigen Weg bin :-)

      c) Ich habe noch diese Grafik gefunden, bei dem es in der Mitte einen Umsetzer geben soll. Sprich, wenn ich als Requestor Java benutze aber der Provider PHP hat, setzt die "Core Service Logic" die Umsetzung von Java zu PHP zum. Web Service Link

      Es werden Daten ausgetauscht. Diese unterscheiden sich - wenn man den Webservice universal anlegen will - nicht zwischen irgendwelchen Programmiersprachen. Man nimmt eher ein universelles Dateiformat, wie XML oder JSON.

      Für den Datenaustausch ja. Ich dachte aber, dass man aber auch bestimmte Methoden/Interfaces von der Applikationen des Providers nutzen kann. Sprich, aus meiner Java Applikation heraus direkt einen Methode aufrufen, die beim Provider liegt und mir einen bestimmten Rückgabewert liefert.

      c1) Was versteht man unter Service Contract?
      c2) Liegt diese "Core Service Logic" dann beim Provider, der beim Aufruf eingesetzt wird? (Warum ist dann aber dahinter nochmal ein "Message Processing Logic"?

      Ich passe.

      Danke für alles. Die letzte Frage versuche ich noch selber zu lösen/verstehen.

      1. Hi!

        Es werden Daten ausgetauscht. Diese unterscheiden sich - wenn man den Webservice universal anlegen will - nicht zwischen irgendwelchen Programmiersprachen. Man nimmt eher ein universelles Dateiformat, wie XML oder JSON.
        Für den Datenaustausch ja. Ich dachte aber, dass man aber auch bestimmte Methoden/Interfaces von der Applikationen des Providers nutzen kann. Sprich, aus meiner Java Applikation heraus direkt einen Methode aufrufen, die beim Provider liegt und mir einen bestimmten Rückgabewert liefert.

        Nein, direkte Aufrufe von Code über Rechner-Grenzen hinweg sind generell nicht möglich, deswegen schaltet man ja solche Konstrukte wie Webservices dazwischen, die Requests annehmen und Codeaufrufe draus machen.

        Lo!

        1. Hi,

          Nein, direkte Aufrufe von Code über Rechner-Grenzen hinweg sind generell nicht möglich, deswegen schaltet man ja solche Konstrukte wie Webservices dazwischen, die Requests annehmen und Codeaufrufe draus machen.

          Wobei etwa gängige XML-RPC-Bibliotheken das ganze durchaus so aussehen lassen können, als ob der Code lokal wäre.

          Bis die Tage,
          Matti

          1. hey

            Nein, direkte Aufrufe von Code über Rechner-Grenzen hinweg sind generell nicht möglich, deswegen schaltet man ja solche Konstrukte wie Webservices dazwischen, die Requests annehmen und Codeaufrufe draus machen.

            Wobei etwa gängige XML-RPC-Bibliotheken das ganze durchaus so aussehen lassen können, als ob der Code lokal wäre.

            ihr habt beide recht. von netbeans heraus sieht es halt optisch so aus, als würde man den code direkt aufrufen, was aber natürlich nicht so ist, sondern nur so aussieht :-)

            danke euch beiden für die hilfestellung