WebServices und WSDL



  • Hallo Forum

    ich bin gerade dabei mich in WebServices einzulesen und hab auch kein Problem damit, in C# eine MEthode als WebServices bereitzustellen. Ich hänge im Moment an dem Problem, dass ich meine WSDL bei einem Broker bekanntmache und ein anderer Client diese WSDL einbinden kann bzw. abrufen. Und genau da verstehe ich leider nicht mehr wie das funktioniert. Wenn ich jetzt einen bestimmten Service suche, den in dem Broker in einer WSDL finde, wie binde ich dann den Service bei mir in der Laufzeit mit ein? Bisher habe ich das immer so verstanden dass ich dann was einbinden muss und neu kompilieren und so Zeug. Ich will aber die Services während der Laufzeit meines Programms nutzen können. Hat mir da jemand ein Beispiel wie das dann funktioniert? Das wäre super, vielen Dank! Im Moment steht mir da wirklich jemand auf dem Schlauch.



  • Hast du dich schon mal mit SOAs befasst? Also unter Einbinden ist hier gemeint, dass dein WS einen anderen bei einem Broker (z.B. ein UDDI-Verzeichnis) sucht und den dann per Fernaufruf nutzt. Wie das dein Service machen kann, ist dann in der WSDL beschrieben.



  • Also, was ich nicht verstehe ist, wenn ich als Client fungiere, über UDDI den Dienst gefunden habe den ich haben möchte, wie ich dann den Dienst auch nutzen kann. Bisher habe ich das so verstanden, dass ich dann die WSDL bei mir im Code kompiliere, die Stubs generiere und dann den Dienst nutzen kann. Wie kann ich das aber zur Laufzeit meines Programmes machen? Kann ich den Dienst zur Laufzeit auch gleich nutzen oder habe ich immer den Kompilierschritt dazwischen?



  • Uh uh uh...weg von dem Gedanken, dass du da was kompilieren muss. [edit]Ausser natürlich du erstellst die WSDL erst zur Laufzeit. Allerdings sollte die schon vorliegen, es sei denn deine Schnittstellen ändern sich ständig.[/edit]

    Es stehen sich gegenüber dein fertiger Web Service und ein anderer. WSDL ist so wie der Name (Web Service Description Language) sagt eine Beschreibung des WS auf XML-Basis.
    Wenn du also einen WS per z.B. UDDI gefunden hast, kannst du eine WSDL (vorrausgesetzt es ist eine vorhanden) des Service auslesen und daran die Schnittstellen auslesen. Auf Basis dieser Beschreibung, die auch das zu verwendende Protokoll festlegt oder festlegen soll, kannst du dann diese Schnittstellen über z.B. SOAP oder XML-RPC benutzen.
    Wie gesagt es sind Fernaufrufe. Also du schickst ne Nachricht und bekommst ne Antwort. In dem Sinne bist du also erst Client des Verzeichnisses und wirst dann zum Client des gefunden WS.

    So sieht zumindest die idealisierte Idee hinter SOAs aus.



  • Danke für deine Hilfe. Was ich jetzt allerdings noch nicht ganz verstehe ist der Part mit den Service auslesen und Schnittstellen benutzen. Dazu muss ich doch die WSDL parsen und mir daraus den Code generieren, mit dem ich dann die Services nutzen kann. Oder nicht? Oder kann ich schon anhand einer WSDL und des darin beschriebenen Dienstes meine Soap-Nachrichten direkt an den Host, der diesen Dienst zur Verfügung stellt, schicken?

    In Visual Studio habe ich das halt bisher mit der wsdl.exe gemacht, also eine WSDL Datei genommen, mit der wsdl.exe den C# Code generiert für meinen Client und dann konnte ich die Services nutzen.



  • samo schrieb:

    Oder kann ich schon anhand einer WSDL und des darin beschriebenen Dienstes meine Soap-Nachrichten direkt an den Host, der diesen Dienst zur Verfügung stellt, schicken?

    Genau...Was du dir aus der WSDL generierst sind die SOAP-Nachrichten (gesetz dem Fall SOAP wird unterstützt), die du schicken musst damit dich der aufzurufende WS versteht.
    Gleichzeitig sollte auch die Struktur beschrieben werden, die du als Antwort erhalten wirst. Was noch in der WSDL steht, ist die Reihenfolge, in der die bestimmten Nachrichten mit dem WS ausgetauscht werden.

    samo schrieb:

    In Visual Studio habe ich das halt bisher mit der wsdl.exe gemacht, also eine WSDL Datei genommen, mit der wsdl.exe den C# Code generiert für meinen Client und dann konnte ich die Services nutzen.

    Na wenn du die Möglichkeit hast, dann sollte doch die Kommunikation kein Problem mehr sein. Wenn ich das richtig verstehe, wird dir eine Komponente generiert, die SOAP-Nachrichten automatisch erstellen können sollte und du musst "nur" noch deine Werte an die richtige Stelle setzen. Oder steh ich jetzt auf dem Schlauch? 😕



  • Maffe001 schrieb:

    Na wenn du die Möglichkeit hast, dann sollte doch die Kommunikation kein Problem mehr sein. Wenn ich das richtig verstehe, wird dir eine Komponente generiert, die SOAP-Nachrichten automatisch erstellen können sollte und du musst "nur" noch deine Werte an die richtige Stelle setzen. Oder steh ich jetzt auf dem Schlauch? 😕

    Er möchte wohl, in C#, ohne Kompilierung (sprich: wsdl.exe fällt weg) eine WSDL von einem Verzeichnis ziehen und damit dann den Service aufrufen. Dynamisch und automatisiert. Vermutlich, ohne selbst bereits WSDL studiert zu haben. In etwa vielleicht so:

    WebService x = DynamicWebServices.GenerateFrom("http://xyz.com/service.wsdl");
    
    HashMap r = x.CallMethod("GetLocalTime"); // wirft, wenn Methode nicht existiert
    r["LocalDate"];
    r["LocalTime"]; // keine durch wsdl.exe generierte Klasse, sondern dynamisch zur Laufzeit gefülltes Feld
    

    @samo: So in etwa? 🙂



  • Hallo LordJaxom

    ja genau so in etwa habe ich mir das gedacht. Mein WebService muss sich dynamisch auf sich veränderte WSDL Dateien und sich damit auch ändernde Services einstellen können. Zur Laufzeit und automatisiert. Das scheint also noch nicht wirklich State-of-the-art zu sein. Da ich mich erst sehr kurz mit WebServices befasse und mir das immer so vorgestellt habe dass ich halt über UDDI meinen Service finde den ich brauche und dann einfach per SOAP ansprechen kann bin ich gerade etwas ernüchtert. Es scheint ja doch so zu sein dass ich über UDDI die Beschreibung des Services per WSDL erhalte, um dann aber den Service nutzen zu können erstmal einen Clienten "erzeugen" (kompilieren) muss, der dann anhand von SOAP den Dienst ansprechen kann. Habe ich das jetzt richtig verstanden?



  • Also ich hab sowas selbst noch nicht geschrieben, sondern nur mal SOAs inner Seminararbeit behandelt.
    Da WSDL eigentlich nur ne XML-Datei ist, würde ich sie auch als solche parsen. Vielleicht gibt es auch schon Parser, die speziell für WSDL geschrieben wurden.
    Was ja eigentlich wichtig ist, sind die Nachrichtenstrukturen, die verwendet werden. Da die i.d.R. als XML-Schema (per Referenz gegegeben) definiert werden, sollte es ja kein Problem sein, sich automatisch den Schnittstellenbeschreibungen anzupassen.

    Wenn ich mich jetzt auf dem Holzweg befinde, weil du eigentlich was anderes vorhast, dann bremst mich bitte. 😃



  • samo schrieb:

    Hallo LordJaxom

    ja genau so in etwa habe ich mir das gedacht. Mein WebService muss sich dynamisch auf sich veränderte WSDL Dateien und sich damit auch ändernde Services einstellen können. Zur Laufzeit und automatisiert. Das scheint also noch nicht wirklich State-of-the-art zu sein. Da ich mich erst sehr kurz mit WebServices befasse und mir das immer so vorgestellt habe dass ich halt über UDDI meinen Service finde den ich brauche und dann einfach per SOAP ansprechen kann bin ich gerade etwas ernüchtert. Es scheint ja doch so zu sein dass ich über UDDI die Beschreibung des Services per WSDL erhalte, um dann aber den Service nutzen zu können erstmal einen Clienten "erzeugen" (kompilieren) muss, der dann anhand von SOAP den Dienst ansprechen kann. Habe ich das jetzt richtig verstanden?

    Also ums gleich vorwegzunehmen, ich bin auch (noch) nicht so bewandert in der ganzen Thematik, aber prinzipiell hast du recht mit dem was du sagst. Letztlich sind WebServices was das angeht auch nicht die Wunderwaffe (für das sie manchmal angepriesen werden).
    Andererseits ist das was du beschreibst aber prinzipiell schon möglich, d.h. dass man wirklich alles komplett dynmamisch macht, ohne in einem vorherigen Schritt aus der WSDL die entsprechenden Proxies zu generieren. Das setzt aber vorraus, dass es innerhalb der Services die du nutzen und auffinden willst standardisierte Interfaces gibt. Dafür gibt es heute sogar tatsächlich reale Beispiele, wie z.B. im Reise/Hotel-Bereich (da gibts z.B. nen exisiterenden Standard für Hotelreservierungen den angebotene Services einhalten sollten).
    Hab ich zumindest so mal irgendwo gelesen.


Anmelden zum Antworten