Ein Service Bus für’s Internet – Der .NET Service Bus (Teil 1)

von Dariusz Parys (Microsoft) Windows Azure ist der Name von Microsoft"s neuer Cloud Computing Plattform. Windows Azure kann als ein Betriebssystem für Cloud Computing-Anwendungen betrachtet werden. Wie für alle Betriebssystemen gibt es auch für Windows Azure programmierbare, wiederverwendbare Funktionen, bei Windows Azure in Form von Diensten: Die Windows Azure Services. Die Windows Azure Services sind Bausteine, die Anwendungen eine Funktionalität anbieten und selbst auf der Windows Azure Plattform gehostet sind.Die Azure-Services gibt es in verschiedenen Funktionen und für verschiedene Bereiche der Anwendungsentwicklung. Für Entwickler relevante Dienste befinden sich in den Bereichen Live Services, SQL Data Services und .NET Services. Letzterer "Service Block" beinhaltet einen Dienst, der im Folgenden näher vorgestellt werden soll: Der .NET Service Bus.Der .NET Service Bus als Enterprise BusDer .NET Service Bus beinhaltet die Funktionalitäten eines Enterprise Service Bus: Naming, Service-Registry und Messaging Fabric. Der entscheidende Unterschied ist, dass der .NET Service Bus in der "Cloud" gehostet wird und dort verschiedene Dienste miteinander verbindet. Einsatzszenarien für einen Internet-basierten Service Bus gibt es viele. Unternehmensübergreifende Dienstverwendung, Anbindung von eigenständigen Filialsystemen mit Großhändlern, Consumer-basierte Endgeräte, die Daten aus zentralen Diensten verwenden möchten, Geräte aus der Unterhaltungselektronik, die mit "Dienstleistungen" aus dem Internet verbunden werden sollen, usw. Der .NET Service Bus wurde für diese Einsatzszenarien geschaffen.Die Rolle des NamingMöchte Unternehmen A seinen Dienst, der z.B. in WCF (Windows Communication Foundation) implementiert ist, für einen ausgewählten Kreis an Partnern und Kunden zur Verfügung stellen, muss dazu zuerst der Zugriffsendpunkt definiert werden. Als Basis wird ein eigenes Naming-Schema herangezogen, das ausgehend von einer Root-Adresse dem Ersteller eine freie und flexible Gestaltung des Namenbereiches ermöglicht. Die für die Adressierung verwendete URI besitzt das folgende Format: [sb|http]://services.windows.net/services/{solutionname}/freidefinierbarZum Registrieren eines EventLogCollector-Dienstes ließe sich folgende URI definieren:sb://services.windows.net/services/Kouder/monitoring/eventlogcollectorDa sich der .NET Service Bus (als Teil des.NET Services SDK vom November 2008) noch in der Entwicklungsphase befindet, kann es bis zum finalen Release noch Änderungen am Namensschema geben. Das endgültige Schema wird voraussichtlich wie folgt aussehen:[sb|http]://{solutionname}.services.windows.net/freidefinierbarService-Registry & Messaging FabricWurde für einen Dienst eine eindeutige URI bestimmt, gilt es den Dienst für den .NET Service Bus zu registrieren. Generell sind die Windows Azure Services nicht auf die .NET-Technologie beschränkt, sondern können genauso von Java, PHP, usw. genutzt werden. Für .NET gibt es allerdings hilfreiche Klassen, im Fall vom .NET Service Bus WCF-Erweiterungen, die in Gestalt der Assembly Microsoft.ServiceBus.dll Teil des .NET Services SDK sind. Mit dabei sind u.a. auch WCF Bindings, die speziell für den .NET Service Bus geschrieben sind. Tabelle 1 gibt eine Übersicht über diese WCF Bindings und stellt sie den Pendants im Service Bus gegenüber. Zu zwei Bindings gibt es noch kein direktes Gegenstück: NetOnewayRelayBinding und NetEventRelayBinding. Relay Bindings sorgen dafür, dass die entsprechende WCF-Nachricht korrekt erstellt wird und in der Service-Registry der Dienst unter dem sog. "Naming Scope" angesprochen werden kann. Registrierte Dienste lassen sich per Atom Feed in der Cloud lokalisieren und damit ansprechen. Die Atom Feed-URI lautet für eine Solution mit dem Namen "Kouder" http://services.windows.net/services/Kouder. Das Standardverhalten, das publizierte Dienste automatisch in diesem Feed auftauchen, lässt sich auch abschalten.Tabelle 1: WCF-Bindings und ihre Service Bus-PendantsRegistrieren eines WCF Dienstes am Service BusUm einen WCF-Dienst am .NET Service Bus zu registrieren, benötigt man die URI und das Binding, über das die Kommunikation stattfinden soll. Ein Beispiel aus dem .NET Services SDK: 1: 2: 3: binding="netOnewayRelayBinding" bindingConfiguration="default" 4: name="RelayEndpoint" contract="Microsoft.ServiceBus.Samples.IOnewayContract" /> 5: Die Konfiguration des Bindings wird in der Anwendungskonfigurationsdatei der Anwendung hinterlegt. Zeile 3 zeigt die Verwendung des NetOnewayRelayBinding-Bindings. Der Service Contract definiert eine Methode Send mit dem Attribut IsOneWay=true: 1: [ServiceContract(Name = "IOnewayContract",2: Namespace = "http://samples.microsoft.com/ServiceModel/Relay/")] 3: public interface IOnewayContract 4: { 5: [OperationContract(IsOneWay = true)] 6: void Send(int count);7: } Die konkrete Implementierung von Send spielt in diesem Zusammenhang keine Rolle. Viel interessanter ist die Registrierung des lokalen Dienstes an den .NET Service Bus: 1: string serviceBusSolutionName = GetServiceBusSolutionName(); 2: Uri address = new Uri( 3: String.Format("sb://{0}/services/{1}/OnewayService/", 4: ServiceBusEnvironment.DefaultRelayHostName, 5: serviceBusSolutionName)); 6:7: ServiceHost host = new ServiceHost(typeof(OnewayService), address); 8: host.Open(); Die zusammengesetzte URI besteht aus den Bestandteilen des Solutionnamens und dem DefaultRelayHost, welcher über das Objektmodell angefragt wird. Daraus ergibt sich die komplette URI: sb://services.windows.net/services/Kouder/OnewayService Wird der Service Host gestartet, liefert die Atom Feed-URI die Namen der aktuelle publizierten Dienste zurück: 1: 2: Publicly Listed Services 3: This is the list of publicly-listed 4: services currently available5: uuid:fa7daf73-e61f-4823-affe-da314af88aaf;id=12066: 2009-01-26T12:44:53Z 7: Microsoft Service Bus 8: 9: 10: uuid:fa7daf73-e61f-4823-affe-da314af88aaf;id=1207 11: onewayservice12: 2009-01-26T12:44:53Z 13:Peter Monadiemi