Seite 4: .NET als Dienstenutzer

Inhaltsverzeichnis

.NET als Dienstenutzer

Um das Ganze spannend zu halten, sei jetzt eine andere Sprache und ein anderes System als Dienstenutzer ausprobiert – und was wäre da besser geeignet als .NET und C#. Angemerkt sei aber, dass sich auch andere Systeme nutzen lassen, Hauptsache, sie verstehen die Web Service Policies.

Der Dienst wurde im letzten Abschnitt entwickelt, konfiguriert und läuft hoffentlich noch. Wenn nicht, muss man wieder in das Java-Projekt gehen sowie den Enterprise Service Bus und dadurch gleichzeitig den Dienst starten.

Als Erstes beschreibt der Artikel die Benutzerschnittstelle des Dienstenutzers. Dazu ist ein neues Windows-Application-Projekt anzulegen (siehe Abb. 4).

In dem neuen Projekt entwirft man eine Minimalbenutzeroberfläche. Sie besteht aus einer Eingabezeile für den Namen der gewünschten Theatervorstellung (alle weiteren Informationen seien weggelassen), dem Button zum Absenden der Anfrage und einem Label, das Sitzplatz und Reihe anzeigt. Das ist eine minimalistische Variante, aber der Entwickler soll ja nur das prinzipielle Funktionieren überprüfen. Abbildung 5 stellt die Benutzeroberfläche im Designer dar.

Nachdem die Benutzeroberfläche angelegt ist, lässt sich der Dienst-Stub importieren. Damit ist eine Beschreibung des Dienstes und des .NET-C#-Stubs für den Zugriff gemeint. Dazu öffnet man den Wizard für den Dienstverweis unter Projekt | Rechte Maustaste | Dienstverweis hinzufügen.... Es sollte jetzt der Konfigurationsdialog für einen Dienstverweis zu sehen sein (Abb. 6).

Jetzt wird es interessant: Was ist mit den Eigenschaften des Dienstes passiert? Damit alles funktioniert, müssen auf beiden Seiten die richtigen kompatiblen Handler und APIs vorhanden, installiert und aktiviert sein. Dazu kann man sich am besten die generierte app.config anschauen. Die Datei ist als Ergebnis eines internen WSDL-zu-C#-Übersetzungsprozesses entstanden.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  ...
  <binding name="ATMServiceSOAP">
    <!--    WsdlImporter ermittelte unerkannte Richtlinienassertionen 
            in ServiceDescription "http://www.fi.com/atm":    -->
    <!--    <wsdl:binding name='ATMServiceSOAP'>    -->
    <!--        <ns1:OptimizedTCPTransport
                    xmlns:ns1="http://java.sun.com/xml/ns/... 
                    </ns1:OptimizedTCPTransport>    -->
                    
    <mtomMessageEncoding maxReadPoolSize="64" 
      maxWritePoolSize="16" messageVersion="Soap11" 
      maxBufferSize="65536" writeEncoding="utf-8">
      <readerQuotas maxDepth="32" 
        maxStringContentLength="8192" maxArrayLength="16384"
        maxBytesPerRead="4096" maxNameTableCharCount="16384" />
    </mtomMessageEncoding>
    
    <httpTransport manualAddressing="false" maxBufferPoolSize="524288"
      maxReceivedMessageSize="65536" allowCookies="false" 
      authenticationScheme="Anonymous" bypassProxyOnLocal="false" 
      hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true"
      maxBufferSize="65536" proxyAuthenticationScheme="Anonymous"
      realm="" transferMode="Buffered" 
      unsafeConnectionNtlmAuthentication="false"
      useDefaultWebProxy="true" />
  </binding>
  ...
</configuration>

Liest man die Datei aufmerksam durch, stellt sich die Frage, was mit dem TCP-Transport geschehen ist. Die Lösung ist recht einfach. Wie der Namespace aussagt (xmlns:ns1=''http://java.sun.com/...''), handelt es sich um eine Erweiterung der Eigenschaften eines Dienstes von Sun. Sie ist in der benutzten .NET-Version noch nicht bekannt und lässt sich demnach nicht automatisch behandeln. Im Gegensatz dazu sind die MTOM-Eigenschaften sehr wohl standardisiert und damit im Handling unproblematisch anzuwenden.

Damit zurück zu den Eigenschaften (Policies) von Diensten. Heute sind die wichtigsten davon für alle standardisiert, weitere kommen in Zukunft dazu. Versetzt man sich gedanklich ein paar Jahre zurück: Damals musst man ohne Policies alles von Hand konfigurieren. Was bedeutet das aber jetzt für den Entwickler?

• Dienst – ist kein Problem: Binding, Ports und Datentypen sind standardisiert und wurden erkannt.
• Eigenschaft MTOM – ist kein Problem: Policies sind standardisiert und wurden erkannt.
• Eigenschaft TCP-Transport – wurde nicht erkannt. Im Fall der TCP-Übertragung kann man sich jedoch auf den internen Mechanismus der verwendeten Service-Engines berufen. Da beide mit dem Fall umgehen können, stellt das kein Problem dar. Das Vorgehen bei solchen nicht standardisierten Eigenschaften und die daraus resultierenden Auswirkungen sind meistens der Dokumentation zu entnehmen. Nicht zuletzt ist die Suche in Newsgroups oder das Konsultieren eines Experten hilfreich.

Jedoch sollte man im Allgemeinen vorsichtig bei unbekannten Policies sein. Es könnte zu Problemen kommen. Die Warnung gilt aber für alle Service-Engines.

Zurück zum Beispiel. Nachdem der erste Schreck verdaut ist, geht es zur Implementierung der Funktion für das Bestellen der Theaterkarten.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

using Test_ATM_Consumer.de.fi.atm.consumer;

namespace Test_ATM_Consumer
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }

        private void btnSend_Click(object sender, EventArgs e)
        {
            ATMServicePortClient cl = new ATMServicePortClient();
            ATMOrderType orders = new ATMOrderType();
            PersonType[] persons = new PersonType[1];

            persons[0] = new PersonType();
            persons[0].lastname = "Kainer";
            orders.People = persons;
            ATMOrderConfirmation[] cons = cl.bookTicket(orders);

            lblNo.Text = cons[0].ticketno;
        }
    }
}

Bleibt am Ende noch das Ausprobieren übrig. Startet man das Beispiel, ist der Dialog aus Abbildung 7 zu sehen. Im Textfeld tippt man die gewünschte Vorstellung ein und bekommt im Anschluss die Ticketnummer angezeigt.