14.3 WebServices mit.net

Transkript

1 Die Ausführungen zu ASP.NET können an dieser Stelle nicht vertieft werden, da dieses Thema derartig komplex ist, dass es den Rahmen dieses Buches sprengen würde. Statt dessen sei auf das sehr eindrucksvolle Werk von P. Lorenz [Lor03] verwiesen, das auf so ziemlich jede Frage zu ASP.NET eine Antwort weiß. Auch empfehlenswert ist das Original-Training von Microsoft [Mic02a] WebServices mit.net Als Teil des ASP.NET Frameworks sind auch WebServices eine interessante Technologie zur Entwicklung von verteilten Komponenten. Auf die zugrunde liegenden Konzepte von WebServices sind wir bereits in Kapitel eingegangen. Da WebServices auf der.net-plattform sehr einfach und transparent zu entwickeln sind, bleibt uns hier nur der Verweis auf Spezialliteratur wie z. B. [Sho02]. Wir wollen uns an dieser Stelle nur noch der Frage widmen, wann Sie WebServices und wann Sie verteilte Objekte nach.net Remoting verwenden sollten. Verwenden Sie WebServices, wenn Sie Dienste oder sonstige Funktionalität im Internet veröffentlichen wollen/müssen. Auch wenn Sie planen, dem System weitere Bestandteile hinzuzufügen oder es mit anderen Systemen zu integrieren, sind Sie mit WebServices gut beraten. Sie bieten Ihnen die Möglichkeit, einfach und unkompliziert interoperable Dienste zu erstellen, die Sie ohne größere Schwierigkeiten in heterogene Systeme integrieren können. Wann WebServices und wann.net Remoting? Verwenden Sie.NET Remoting, wenn Sie in einer Intranetanwendung ausschließlich eine leichte, schnelle CLR-basierte RPC-Kommunikation benötigen. Auch wenn Sie Typsicherheit, statusbehaftete Objekte etc. benötigen, sollten Sie.NET Remoting den WebServices vorziehen. Vergessen Sie an dieser Stelle nie: Auch eine Hybridlösung kann die gewünschten Effekte erziehlen Codename: Indigo In den vorangegangenen Abschnitten haben wir einen kompakten Überblick über die aktuell verfügbaren Technologien für.net-basierte verteilte Systeme gegeben. Lassen Sie uns nun einen Blick in die Zukunft riskieren und die Frage stellen, wie zukunfts- und somit investitionssicher.net-anwendungen sind, die mit diesen Technologien erstellt wurden WebServices mit.net 331

2 Ein kritischer Blick Stellen wir uns doch einmal der Frage, wo noch Möglichkeiten der Verbesserung sind und gehen wir dabei alle behandelten Technologien der Reihe nach durch:.netremoting ist die Weiterentwicklung von DCOM. Die Vorteile liegen auf der Hand über die Programmierbarkeit von (D)COM brauchen wir uns hier nicht zu unterhalten. Doch wo liegen die Nachteile? Wie Sie in den vorangegangenen Kapiteln sicherlich bemerkt haben, ist im Prinzip immer alles ganz einfach, jedoch gibt es an vielen Stellen noch das eine oder andere Problem, z. B. bei der Verteilung der Metadaten oder bei der Ereignisbehandlung..NET Enterprise Services sind die.net-version von COM+. Hier gilt die gleiche Aussage wie oben. Weiterhin ist zu bemerken, dass hier der native Applikationsserver fehlt. Der Umweg über COM+ ist zwar durchaus in Ordnung, jedoch ist immer die InterOP-Schicht beteiligt, was auf Dauer unbefriedigend ist. ASP.NET stellt aufgrund der Umstellung des Programmiermodells allein schon einen großen Schritt nach vorn dar. Erinnern wir uns: Nachnutzung unter ASP (ohne.net) hieß zumeist copy n paste. Zusätzliche Komponenten mussten, da COM-basiert, immer registriert werden. Damit ist nun Schluss und es steht ein gutes objektorientiertes API zur Verfügung. Negativ fallen hier fehlende Designvorlagen mit Corporate-Charakter ähnlich der visuellen Vererbung bei Windows-Forms auf. XML-WebServices sind relativ neu und die Technologie ist noch im Fluss, sodass hier mit Sicherheit noch einiges an Entwicklungen folgen wird. Große Vorhaben, die noch zur Standardisierung ausstehen sind bspw. Transaktionen und Sicherheit. Was nun? Da ist doch eine recht stattliche Liste zusammengekommen, oder? Wir wollen nun einen dieser Bereiche herausnehmen und Ihnen hierfür einen kleinen Ausblick in die Zukunft geben. Dem Anliegen dieses Buches folgend wählen wir natürlich den Remoting-Teil Windows Longhorn, WinFX und Co. In den nächsten ein bis zwei Jahren wird der Nachfolger von Windows XP das Licht der Welt erblicken. Momentan geistert er unter dem Codenamen Longhorn durch die Medien. Ein Blick auf das Longhorn Software Development Kit (Longhorn-SDK) verrät, in welche Richtung es in etwa mit.net und auch.net Remoting gehen wird Konzepte für große Anwendungen

3 Longhorn-BETA Die folgenden Ausführungen basieren auf dem zur PDC 2003 herausgegebenen Longhorn-SDK. Sie haben die Möglichkeit, sich bereits vorab im Internet unter näher zu informieren oder direkt im Longhorn Developer Center http: //msdn.microsoft.com/longhorn nach Informationen zu suchen. Beachten Sie: Die hier gemachten Aussagen basieren auf der Beta-Version des SDKs. Dieses unterliegt bis zur entgültigen Freigabe steten Veränderungen. Achtung! Eine Reihe von Schlagwörtern und Codenamen kursieren momentan um Longhorn. Das interessanteste ist mit Sicherheit WinFX, das objektorientierte,.net-basierte Betriebssystem-API. Mit WinFX scheint langsam die Ablösung des Win32-APIs zu kommen. WinFX ist ebenfalls Anlaufpunkt für alle weiteren Technologien: > Avalon ist eine neue Grafik-Engine, die als Nachfolger für das GDI+ positioniert wird. Oberflächen werden durch XML (XAML) beschrieben und können mit Code verlinkt werden. Dieser an ASP.NET angelehnte Ansatz entkoppelt Funktionalität von Präsentation (MVC Design Pattern). > WinFS ist ein SQL-Datenbank basiertes Dateisystem, das NTFS und SQL-Server vereinigt. Dateien sind nun nicht mehr an eine Verzeichnishierarchie gebunden (Pfade), sondern über Anfragen, Kategorien etc. erreichbar. > Indigo ist ein Framework für den Aufbau verteilter Systeme Indigo Indigo bezeichnet ein Framework, das basierend auf.net ein dienstorientiertes Programmierparadigma umsetzen soll. Das Framework ist im Wesentlichen eine Weiterentwicklung von COM+ und.net, welche die Vorteile von >.NET Remoting, > ASP.NET-WebServices, >.NET Enterprise Services/COM+ und > MSMQ (Messaging) vereint und über das einfache Programmiermodell von.net zugänglich macht. Abbildung 14.4 zeigt einen Überblick über das Indigo Framework Codename: Indigo 333

4 Service Model Instance Manager Connector Context Manager Service Methods Channels (Datagram, Peer, etc.) Transport Channels (TCP, HTTP, etc.) Type Integration Declaration Behaviors Transacted Methods Policy Engine Channel Security Message Encoder Messaging Services Queuing Routing Eventing... System Services Communication Manager (Port) Transaction Hosting ASP.NET.container.exe NT Service DllHost Federation... Abbildung 14.4 Überblick über das Indigo Framework Indigo und.net Remoting Eines vorweg:.net Remoting (Namensraum: System.Runtime.Remoting und untergeordnete) wird weiterhin existieren. Jedoch bietet auch Indigo die Möglichkeit, verteilte Objekte zu verwenden. Dabei spielen im Wesentlichen sechs Klassen aus den Namensräumen System.Messagebus und System.Messagebus.Remoting eine wichtige Rolle (siehe Tabelle 14.3). Listing 14.2 Die Schnittstelle IAccount für Indigo using System.Messagebus.Remoting; namespace Account { [Remotable] public interface IAccount : ICloneable { int ID { get;... Der prinzipielle Aufbau eines Remoting-Systems mit Indigo unterscheidet sich nicht von den bisher verwendeten Konfigurationen. Es gibt somit also ein oder mehrere verteilte Objekte, einen Service Host und einen Client. Im Folgenden wollen wir das Anwendungsbeispiel aus Kapitel Indigo-tauglich machen. Wir wählen hierfür wieder einen Schnittstellen-basierten Ansatz. Listing 14.2 zeigt die angepasste SchnittstelleIAccount als Remotable-Interface. Wie zu sehen ist, hat sich die Schnittstelle nicht verändert. Lediglich das Attribut[Remotable] deutet darauf hin, dass wir mit diesem Interface etwas Besonderes vorhaben Konzepte für große Anwendungen

5 Tabelle 14.3 Kernklassen für verteilte Objekte mit Indigo ServiceEnvironment RemotingManager Die Klasse ServiceEnvironment aus dem Namensraum System.Messagebus stellt eine Art Container für bestimmte Funktionen bereit. Im Remoting-Kontext übernimmt sie hier Konfiguration, Starten und Anhalten von Anwendungen. Jede Funktion wird durch einen Manager realisiert. Die Klasse RemotingManager ist ein Manager für ein Service Environment, der für verteilte Objekte spezialisiert ist. Der Remoting Manager entspricht dabei weitestgehend einer Zusammenfassung der Klassen Remoting- Configuration undremotingservices. PublishedServerObject Ein (verteiltes) Objekt, das durch einen Remoting Manager publiziert wird. RemotableAttribute RemoteType ObjectToken Dieses Attribut wird auf Schnittstellen angewendet und kennzeichnet diese für die verteilte Verarbeitung. Typobjekt für den Client, der darauf basierend einen Proxy zur Interaktion erstellen kann. Repräsentiert ein gemarshaltes Objekt und enthält alle notwendigen Informationen, um eine Verbindung mit einem verteilten Objekt herstellen zu können (vgl. KlasseObjRef). Erfreulicherweise ändert sich in diesem Szenario die Implementierung der passenden Klasse CAccount nicht. Änderungen ergeben sich erst wieder bei den Client- und Server-Programmen. Im Folgenden ist der Server für ein Indigo-Konto gezeigt: using System; using System.Messabebus; using System.Messagebus.Remoting; namespace Server { using Account; class CServer { [STAThread] static void Main(string[] args) { ServiceEnvironment env = ServiceEnvironment.Load(); RemotingManager rman = (RemotingManager)env[typeof(RemotingManager)]; IAccount iacc = new CAccount(); PublishedServerObject pubso = new PublishedServerObject(iacc, new Uri("urn:AccountInterface")); rman.publishedserverobjects.add(pubso); 14.4 Codename: Indigo 335

6 env.start(); Console.WriteLine("Server up and running..."); Console.ReadLine(); env.close(); Die statische Methode Load() lädt ein neues Service Environment, welches auch in einer entsprechenden XML-Datei konfiguriert werden kann. Die Umgebung enthält verschiedene Manager, von denen jeder einen bestimmten Funktionsumfang abdeckt. Einer dieser Manager ist der Remoting Manager, welcher nun angefordert wird. Als nächstes wird eine Instanz des verteilten Objekts angelegt, welche als PublishedServer- Object der entspechenden Kollektion des Remoting Managers hinzugefügt wird. Danach wird die Umgebung gestartet, also publiziert. Damit ist der Service Host fertig. Analog dazu wird ein korrespondierender Client erstellt: namespace Server { class CClient { [STAThread] static void Main(string[] args) { ServiceEnvironment env = ServiceEnvironment.Load(); RemotingManager rman = (RemotingManager)env[typeof(RemotingManager)]; env.open(); Uri svr = new Uri("soap.tcp://localhost:9000/AccManager"); IAccount iacc = (IAccount)rman.GetObject(svr, new Uri("urn:AccountInterface"));... env.close(); Der Server-URI wird dabei in einer Konfigurationsdatei des Servers festgelegt und beschreibt, welches Environment unter welcher Adresse zu finden ist. Fertig. Beachten Sie: Remote Object Remote Object Achtung! An dieser Stelle muss noch erwähnt werden, dass Remote Objects von Indigo nicht alles können, was Sie bisher über herkömmliche verteilte Remoting-Objekte erfahren haben. Indigo Remote Objects unterstützen nicht: > SOAP-Interoperabilität, > Server Activated Objects(SAO), > Metadatenim- und-export, > Remoting Interceptionsmodell Konzepte für große Anwendungen

7 Weiteres zu Indigo Das war ein einfaches Beispiel, um zu zeigen, dass Remoting auch mit Indigo klappt. Indigo ist jedoch wesentlich mehr. Es basiert auf vier wesentlichen Elementen: 1. Nachrichten (Messages), 2. Ports, 3. Kanäle (Channels) und 4. Diensten (Services). Dabei wird hier auch wieder die Philosophie von.net Remoting weitergeführt, sodass jeder Teil von Indigo ersetzbar bzw. austauschbar ist. Beispielhaft sei hier der Port genannt. Ports sind nichts weiter als logische Endpunkte für Dienste. Sie können Nachrichten empfangen und senden, wobei die Kommunikationsschicht zwischen den Ports irrelevant ist. Wenn Sie sich jetzt an den Remoting Channel erinnern, liegen Sie gar nicht so verkehrt. Funktionsumfang von Indigo Bei den aktuellen Technologien, die.net für verteilte Systeme anbietet, gibt es einige Kritikpunkte. So fehlt bei WebServices für bestimmte Eigenschaften eine Standardisierung, Remoting fehlt standardmäßig die sichere Übertragung und die Enterprise Services sind zu komplex. Indigo bietet hier für jeden etwas. Es enthält lose gekoppelte Softwarekomponenten (Dienste vgl. mit WebServices), Transaktionen und Sicherheit (Enterprise Services), flexible asynchrone Nachrichtenkanäle (Messaging) und eine flexibel erweiterbare Infrastruktur für verteilte Objekte (Remoting). In der Tat ist bspw. das Erstellen eines einfachen Indigo-WebService recht einfach wie Listing 14.3 zeigt. Listing 14.3 Ein einfach(st)er Indigo-(Web)Service using System; using System.Messagebus; using System.Messagebus.Remoting; [DatagramPortType(Name="DoSomething", Namespace="...")] public class DoSomethingService { [ServiceMethod] public void DoSomething() { NET Remoting und danach Es bleibt nun die Frage zu klären, wann sich welche Technologie für welchen Einsatzzweck eignet und wie zukunftssicher sie z. B. im Hinblick 14.5.NET Remoting und danach 337

8