[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]  

Die XML Datei präsentiert sich wie folgt:

Hier liegt die gesamte Information über den zur Verfügung gestellten Service vor. Es handelt sich hierbei quasi um eine Typelib im XML Format.

Visualisierung

Folgende Grafik veranschaulicht das Zusammenspiel und illustriert die Rollenverteilung im gesamten SOAP Anwendungsbeispiel. Die Grafik ist aus dem "ROPE Samples Tutorial", eine sehr zu empfehlende Lektüre.

Erstellen der ASP und SDL Dateien

Obwohl das Erstellen der ASP Dateien zusammen mit den XML Dateien auch von Hand erledigt werden kann, ist es ratsam, den eigens dazu zur Verfügung gestellten Wizard Namens "sdlwizard.exe" zu verwenden.

Der Einsatz dieses Wizards ist sehr einfach:

Man wählt lediglich die eigene dll an. Im nächsten Schritt wird ausgewählt, für welche Methoden der Code erstellt werden soll:

Anschliessend muss der SOAP Listener noch angegeben werden. Diese Information wird dazu verwendet, im generierten ASP File die Konstante SOAP_SDLURI zu setzen (s. Oben)

Auf der letzten Seite kann noch angegeben werden, wohin die Dateien generiert werden sollen. Das Resultat dieses Wizards sind die Dateien address.asp, address.xml, general.asp sowie general.xml. Die Dateien general.* beinhalten allgemeine Funktionen. Die Dateien address.* beinhalten die ASP Datei sowie die SDL Datei.

Schlussbemerkung

Es braucht nunmehr wenig Fantasie um sich vorzustellen, dass sich in Zukunft eine auf SOAP basierte Kommunikation zwischen dem Client und dem Server vermehr durchsetzen wird. Bestimmt wird im kommenden microsoft.net Framework noch einiges vereinfacht werden, doch als Entwickler investiert man sicherlich in die richtige Technologie, wenn man die eigenen n-Tier Anwendungen bereits auf die XML Revolution vorbereitet.

Bei unseren n-Tier Projekten werden wir Clientseitig einen Layer einfügen, der den Anwendungsentwickler der Client Applikation davor beschützt, sich mit den Unterschieden zwischen DCOM und SOAP auseinanderzusetzen. Er ruft einfach die Methode xy einer Interface Klasse auf. Je nachdem, ob DCOM oder SOAP verwendet wird, läuft schlussendlich der Code ab, um die Middle Tier Komponente aufzurufen.

Ich finde die gesamte Entwicklung in der n-Tier Umgebung je länger desto spannender und erkenne laufend neuen Kundennutzen. Diesen in die Projektarbeit einfliessen zu lassen, ist für mich oberstes Ziel. In diesem Zusammenhang möchte ich auch erwähnen, dass von der puren Performance her, n-Tier Anwendungen sehr wohl gegenüber Fat Client/Server Anwendungen im Vorteilk sein können. Vor allem bei nicht so leistungsfähigen Clients ist die Performance durch das "Delegieren" des ganzen Datenzugriffscodes spürbar besser. Ganz generell ist der Einsatz einer Windows Anwendung mit allem damit verbundenem Kundennutzen zusammen mit dem Internet als Kommunikationsmittel wie eine Segelreise mit gutem Wind auf hoher See, quasi grenzenlos.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]