Kurz vorgestellt
WCF- und WF-Dienste in .NET Framework 4.0 und „Dublin“
Aaron Skonnard
Dieser Artikel basiert auf einer Vorabversion von .NET Framework 4.0 und „Dublin“. Änderungen an allen Informationen in diesem Artikel sind vorbehalten.
Themen in diesem Artikel:
|
In diesem Artikel werden folgende Technologien verwendet: .NET Framework 4.0, „Dublin“ |
Inhalt
Umstellung auf .NET Framework 4.0
WF-Basisaktivitätsbibliothek
WF-Aktivitätsprogrammiermodell
Weitere neue WCF-Features in .NET Framework 4.0
Die Notwendigkeit von „Dublin“
Ein Leitfaden zu „Dublin“
Erstellen eines WCF-Workflowdiensts für „Dublin“
Bereitstellen von Anwendungen mit „Dublin“
Verwalten ausgeführter Anwendungen
Aktualisieren ausgeführter Anwendungen
Überwachen ausgeführter Anwendungen
Von „Dublin“ nach „Oslo“?
Wie steht es mit BizTalk Server?
Im Rahmen der Professional Developer's Conference (PDC) im Oktober 2008 veröffentlichte Microsoft Einzelheiten zu zahlreichen Verbesserungen, die in Microsoft .NET Framework 4.0 enthalten sein werden, speziell in den Bereichen Windows Communication Foundation (WCF) und Windows Workflow Foundation (WF). Microsoft führte auch einige Erweiterungen zu Windows Server (Codename „Dublin“) ein, die eine verbesserte Hosting- und Verwaltungsfunktionalität für WCF- und WF-Anwendungen bieten.
Die Integration von WF und WCF in .NET Framework 4.0 vereinfacht das Entwickeln verteilter dienstorientierter Anwendungen. Sie werden statusbehaftete Workflowdienste mithilfe eines vollständig deklarativen Modells erstellen können, das mehr Flexibilität und geschäftliche Flexibilität bietet.
Die neuen Hosting- und Verwaltungserweiterungen, die von „Dublin“ eingeführt werden, ergänzen diese Fortschritte beim Framework. Die Kombination aus Fortschritten beim Framework selbst und bei den Betriebstools, die das Framework unterstützen, bedeutet, dass die Anwendungsserverfunktion in Windows Server einen bedeutenden Sprung nach vorn machen wird.
In diesem Artikel werden einige wichtige neue WCF- und WF-Features in .NET Framework 4.0 sowie die neuen Anwendungsserverfunktionen vorgestellt, die von den „Dublin“-Erweiterungen bereitgestellt werden.
Umstellung auf .NET Framework 4.0
WCF und WF sind einander ergänzende Technologien. Wenn Sie mit Ihnen nicht vertraut sind, stellen Sie sich dieses Paar am besten so vor: WCF befindet sich außen und WF innen. WCF dient zum Verfügbarmachen der externen Dienstschnittstelle einer Anwendung, während WF zum Beschreiben des internen Flusses, der Zustände und der Übergänge einer Anwendung dient.
Mit .NET Framework 3.5 wurde eine überzeugende Integration der beiden eingeführt, speziell in der Form von WF-Send- und Receive-Aktivitäten. Mit diesen Aktivitäten können Sie WF zum Vereinfachen des Prozesses beim Koordinieren mehrerer Dienstinteraktionen verwenden, um komplexe, lang andauernde Workflows zu koordinieren. Sie können diese Aktivitäten auch verwenden, um die Reichweite Ihrer WF-Workflows zu erweitern, indem Sie sie mit WCF-Endpunkten verwenden (siehe Abbildung 1). Dies ermöglicht im Grunde, WF als Implementierung für Ihre WCF-Dienste einzusetzen, was in diesem Artikel als WCF-Workflowdienste bezeichnet wird.
Abbildung 1 WCF-Workflowdienste
Obwohl WCF-Workflowdienste in .NET Framework 3.5 implementiert werden können, ist dies nicht einfach. Zunächst einmal lässt die Integrationsschicht zwischen WCF und WF zu wünschen übrig. In .NET Framework 3.5 müssen die WCF-Artefakte mithilfe des WCF-Programmier- und Konfigurationsmodells definiert und konfiguriert werden, während der Workflow mithilfe eines anderen Modells definiert wird. Schließlich sind mehrere Artefakte vorhanden, die separat bereitgestellt, konfiguriert und verwaltet werden müssen.
Ein weiterer erschwerender Grund besteht darin, dass sich die derzeitige Basisaktivitätsbibliothek auf Aktivitäten der Flusssteuerung und Logik konzentriert und nicht viele Arbeitsaktivitäten bietet. Sie müssen daher eine Bibliothek benutzerdefinierter Aktivitäten schreiben, bevor Sie reale Workflowdienste mit WF implementieren können. Da diese Aufgabe sehr komplex ist, haben einige Entwickler bereits aufgegeben, bevor sie die Vorteile von WF erleben konnten.
Neben diesen Problemen mangelt es dem derzeitigen WF auch an Toolunterstützung für Workflows, die ausschließlich in XAML (eXtensible Application Markup Language) erstellt werden. Diese werden auch als deklarative Workflows bezeichnet, da sie vollständig in einer XML-Datei ohne CodeBehind-Dateien beschrieben werden. Der Nur-XAML-Ansatz führt zu einigen überzeugenden Möglichkeiten beim Hosten und Bereitstellen von Workflows. Die Leistungsfähigkeit eines deklarativen Workflows besteht darin, dass es sich nur um Daten handelt, die überall gespeichert und innerhalb einer WF-Laufzeitumgebung ausgeführt werden können, die die verwendeten Aktivitäten kennt.
Ein deklarativer Workflow kann in einer Laufzeit in der Wolke oder in einer Arbeitsstation unter Ihrem Schreibtisch bereitgestellt werden (vorausgesetzt, dass die Aktivitäten auf dem Laufzeithost bereitgestellt wurden). Deklarative Workflows lassen sich auch einfacher versionieren, und sie können in Szenarios mit teilweiser Vertrauenswürdigkeit (denken Sie an die „Wolke“) verwendet werden. Für das Nur-XAML-Modell lassen sich auch Tools einfacher erstellen, da die Tools nur mit XML-Dateien arbeiten.
Im Allgemeinen war das Nur-XAML-Modell schon immer die Endvision für WF als Technologie, was aus den frühen Schriften der Architekten hervorgeht. Die derzeitige WF-Toolunterstützung realisiert diese Vision nicht vollständig. Obwohl es möglich ist, Nur-XAML-Workflows mit .NET Framework 3.5 zu erstellen, müssen die derzeitigen Visual Studio-Vorlagen umgangen und wichtige Features, wie z. B. das Debugging, aufgegeben werden.
Das Hauptziel für WCF und WF in .NET Framework 4.0 besteht darin, die Entwicklerfunktionalität um deklarative Workflows und Dienste herum zu vereinfachen, wobei vollständig auf ein Nur-XAML-Modell gebaut wird. Zudem wollte Microsoft noch einen Schritt weiter gehen, indem das Definieren deklarativer Workflowdienste ermöglicht wird. Dabei handelt es sich um WCF-Dienste, die vollständig im Hinblick auf XAML definiert sind, einschließlich Dienstvertragsdefinitionen, Endpunktkonfigurationen und der eigentlichen Dienstimplementierung (in Form eines XAML-basierten Workflows).
Um dies zu erreichen, hat Microsoft zahlreiche Verbesserungen in .NET Framework 4.0 vorgenommen, zu denen eine erweiterte Basisklassen-Aktivitätsbibliothek, ein einfacheres Programmiermodell für benutzerdefinierte Aktivitäten, ein neuer Flussdiagramm-Workflowtyp und zahlreiche WCF-spezifische Verbesserungen zählen.
WF-Basisaktivitätsbibliothek
.NET Framework 4.0 verfügt über eine verbesserte Basisaktivitätsbibliothek, die mehrere neue Aktivitäten enthält (siehe Abbildung 2). Microsoft plant zudem, über CodePlex zusätzliche WF-Aktivitäten zwischen .NET Framework-Hauptversionen verfügbar zu machen. Außerdem werden weitere Arbeitsaktivitäten (beispielsweise die PowerShellCommand-Aktivität) in zukünftigen Veröffentlichungen (oder in CodePlex) erscheinen, wodurch der Bedarf an benutzerdefinierter Aktivitätsentwicklung verringert wird. Da CodePlex von Microsoft verwendet wird, bietet sich Ihnen die gute Gelegenheit mitzuteilen, welche zusätzlichen Aktivitäten für Sie wichtig sind.
.NET Framework 4.0 führt einige zentrale Aktivitäten ein, die mehr Optionen zur Flusssteuerung bieten, beispielsweise die FlowChart-, ForEach-, DoWhile- und Break-Aktivitäten. Die neue FlowChart-Aktivität ist eine der interessantesten Ergänzungen, da sie einen guten Kompromiss zwischen dem Sequential- und dem StateMachine-Flusssteuerungsmodell bietet. Mithilfe von FlowChart können Sie einen schrittweisen Ansatz verwenden, der mit einfachen Entscheidungen und Schaltern verbessert wurde, aber auch die Rückkehr zu früheren Aktivitäten im Workflow ermöglicht. Flussdiagramme scheinen für viele Benutzer im Allgemeinen intuitiver zu sein. Abbildung 3 zeigt, wie der FlowChart-Designer im neuen Workflowdesigner in Visual Studio 2010 aussieht (weitere Informationen sind in der Randleiste „Der neue Workflowdesigner“ enthalten).
Abbildung 3 Der neue FlowChart-Aktivitätsdesigner
.NET Framework 4.0 führt auch einige neue Laufzeitaktivitäten zum Aufrufen von CLR-Methoden (MethodInvoke), zum Zuweisen von Werten zu Workflowvariablen (Assign) und zum expliziten Beibehalten einer ausgeführten Workflowinstanz (Persist) ein.
Schließlich verfügt .NET Framework 4.0 über einen neuen Satz WCF-basierter Aktivitäten, die den Prozess der Bereitstellung von Workflows als Dienst oder die Nutzung von Diensten in Ihren Workflows vereinfachen. .NET Framework 3.5 stellte zwei Aktivitäten (Send und Receive) zum Senden und Empfangen von Nachrichten über WCF bereit. In Version 4.0 sind SendMessage- und ReceiveMessage-Aktivitäten enthalten, die (ähnlich wie Send und Receive in Version 3.5) zum Senden und Empfangen unidirektionaler Nachrichten dienen, sowie eine Abstraktion höherer Ebene für Anforderung/Antwort-Vorgänge über die ClientOperation- und ServiceOperation-Aktivität. Ein Workflow, der einen Dienstvorgang verfügbar machen will, sollte die ServiceOperation-Aktivität verwenden. Ein Workflow, der einen externen Dienst nutzen will, sollte hingegen die ClientOperation-Aktivität verwenden.
Neben diesen WCF-Hauptaktivitäten bietet .NET Framework 4.0 auch Unterstützung für die Korrelation über verschiedene unidirektionale Vorgänge hinweg, um sicherzustellen, dass eine bestimmte Nachricht wieder zur richtigen Workflowinstanz zurückkehrt. Das Framework verfügt über eine Aktivität zum Definieren eines neuen Korrelationsbereichs (CorrelationScope) und zum Initialisieren der Korrelationswerte (InitializeCorrelation), bevor eine ausgehende Nachricht über WCF gesendet wird.
Der neue Workflowdesigner
Ein neuer Workflowdesigner, der Visual Studio 2010 hinzugefügt wurde, bietet eine überzeugende Benutzerfunktionalität für viele der wichtigsten WCF- und WF-Features, die in diesem Artikel erörtert werden. Er bietet beispielsweise eine verbesserte Workflownavigation (eine Analyse zusammengesetzter Aktivitäten) mit Brotkrümelpfaden, um im Bereich zurückzugehen, direkte Aktivitätsbearbeitung (sodass kein Eigenschaftenfenster erforderlich ist), Zoomfunktionen und eine Übersichtsnavigation. Zudem bietet der neue Designer ein verbessertes Modell zum Anpassen und Neuhosten. Visual Studio 2010 wird außerdem eine Suite neuer oder verbesserter Projektvorlagen bieten, sodass Sie die Arbeit mit Flussdiagrammen und Nur-XAML-Workflows schnell beginnen können, und es wird vollständige Unterstützung für XAML-basiertes Debugging bei der Arbeit mit deklarativen Workflows und Diensten bieten.
WF-Aktivitätsprogrammiermodell
Selbst mit diesen Verbesserungen müssen Sie möglicherweise bisweilen dennoch benutzerdefinierte Aktivitäten schreiben. Um dies zu vereinfachen, hat Microsoft die Basisklassen für benutzerdefinierte Aktivitäten neu entworfen. Die neue Basisklasse für benutzerdefinierte Aktivitäten heißt „WorkflowElement“, und es gibt eine weitere von ihr abgeleitete Klasse namens „Activity“. Mithilfe der Activity-Klasse können leicht neue benutzerdefinierte Aktivitäten aus vorhandenen Aktivitäten erstellt werden, ohne viel Code zu schreiben, falls dies überhaupt erforderlich ist.
Abbildung 4 beispielsweise zeigt, wie eine neue benutzerdefinierte Aktivität namens „CopyFile“ durch Ableiten aus Activity und Überschreiben von CreateBody definiert wird. Die Implementierung erstellt eine angepasste PowerShellCommand-Instanz, die so konfiguriert ist, dass sie den integrierten Befehl zum Kopieren von Elementen verwendet. Benutzerdefinierte Aktivitäten wie diese können auch leicht mithilfe des neuen Workflowdesigners in Visual Studio 2010 über den grafischen Aktivitätsdesigner erstellt werden, wenn Sie diese Art von Code lieber gänzlich vermeiden möchten.
Abbildung 4 Benutzerdefinierte CopyFile-Aktivität
class CopyFile : Activity
{
public InArgument<string> Source { get; set; }
public InArgument<string> Destination { get; set; }
protected override WorkflowElement CreateBody()
{
return new PowerShellCommand
{
CommandText = "copy-item",
Parameters =
{
{ "path", new InArgument<string>(Source) },
{ "destination", new InArgument<string>(Destination) } ,
{ "recurse", new InArgument<bool>(false) }
},
};
}
}
Wenn Sie eine benutzerdefinierte Aktivität von Grund auf neu definieren müssen (also eine Aktivität, die nicht auf vorhandenen Aktivitäten basiert), müssen Sie diese aus WorkflowElement ableiten und die Execute-Methode außer Kraft setzen. Für diesen Ansatz ist etwas mehr Code erforderlich, und er ähnelt dem heute üblichen Ableiten aus Activity. Microsoft hat jedoch das Schreiben dieser benutzerdefinierten Aktivitäten noch weiter vereinfacht.
Eines der Dinge, die das Schreiben einer benutzerdefinierten Aktivität erschweren, ist das Verwalten des Datenflusses zur Aktivität und aus ihr heraus. So ist es beispielsweise heute nicht möglich, einen Satz typisierter Argumente zu definieren, die an eine Aktivität und von ihr übergeben werden. Normalerweise schreiben Entwickler benutzerdefinierte Klassen, die Argumente aus einer Workflowwarteschlange serialisieren und deserialisieren. (Weitere Informationen dazu finden Sie in Michael Kennedys Artikel Webanwendungen, die lang andauernde Vorgänge unterstützen.) Das Schreiben dieses Grundstrukturcodes ist nicht schwierig, aber es ist zusätzliche Arbeit, die vom Hauptziel beim Modellieren des Anwendungsflusses ablenkt. .NET Framework 4.0 erweitert das Aktivitätsprogrammiermodell mit drei neuen Datenflusskonzepten, die das Ganze stark vereinfachen dürften: Argumenten, Variablen und Ausdrücken.
Sie verwenden Argumente, um die Art und Weise des Datenflusses in eine Aktivität bzw. aus ihr heraus zu definieren. Jedes Argument hat eine angegebene Bindungsrichtung wie Eingabe, Ausgabe oder Eingabe/Ausgabe. Das folgende Beispiel zeigt, wie eine einfache Audit-Aktivität mit einem einzelnen Eingabeargument namens „AuditMessage“ erstellt wird:
public class Audit: WorkflowElement {
public InArgument<string> AuditMessage{ get; set; }
protected override void Execute(ActivityExecutionContext context) {
WriteToEventLog(AuditMessage.Get(context));
}
}
Variable bieten eine Möglichkeit zum Deklarieren eines benannten Speichers für Daten. Variable können sowohl in Code als auch in XAML-basierten Workflows definiert werden. Variable können auch in verschiedenen Bereichen innerhalb eines Workflows (innerhalb geschachtelter Workflowelemente) definiert werden, und sie sind Teil der Workflowprogrammdefinition zur Entwurfszeit, während die Werte in der Workflowinstanz zur Laufzeit gespeichert werden.
Das folgende Beispiel zeigt, wie ein XAML-Workflow geschrieben wird, der eine als Nachricht bezeichnete Variable definiert, ihr einen Wert (mithilfe der neuen Assign-Aktivität) zuteilt und dann den Wert der Variablen an die zuvor definierte benutzerdefinierte Audit-Aktivität übergibt:
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<Assign x:TypeArguments="p:String" To="[message]"
Value="Audit message: something bad happened" />
<s:Audit Text="[message]" />
</Sequence>
Ein Ausdruck ist ein Konstrukt, das eines oder mehrere Eingabeargumente annimmt, einen Vorgang oder ein Verhalten an diesen Eingabeargumenten durchführt und dann einen Wert zurückgibt. Ausdrücke werden durch Ableiten einer Klasse aus ValueExpression definiert, das sich wiederum aus WorkflowElement ableitet. Ausdrücke können also überall dort verwendet werden, wo eine Aktivität verwendet werden kann. Ausdrücke können auch als Bindung an das Argument einer anderen Aktivität verwendet werden. Dieses Beispiel definiert einen einfachen Format-Ausdruck:
public class Format : ValueExpression<string> {
public InArgument<string> FormatString { get; set; }
public InArgument<string> Arg { get; set; }
protected override void Execute(ActivityExecutionContext context) {
context.SetValue(Result,
String.Format(FormatString.Get(context), Arg.Get(context)));
}
}
Sie können diesen Ausdruck wie jede andere Aktivität in Ihre XAML-Workflows integrieren. Der folgende Workflow beispielsweise zeigt, wie das Ergebnis des Format-Ausdrucks an die Audit-Aktivität übergeben wird, um das Ergebnis in das Ereignisprotokoll zu schreiben (dies setzt voraus, dass der Inhalt von Audit dem Nachrichtenargument zugeordnet wird):
<Sequence
xmlns="https://schemas.microsoft.com/netfx/2009/xaml/workflowmodel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:s="clr-namespace:Samples;assembly=Samples"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
<Sequence.Variables>
<Variable Name="message" x:TypeArguments="p:String" />
</Sequence.Variables>
<s:Audit>
<s:Format FormatString="Audit message: {0}" Arg="[message]"/>
</s:Audit>
</Sequence>
Ein weiterer Aspekt ist, dass es bei der Stammaktivität keine Besonderheiten gibt. Alles, was sich aus dem WorkflowElement ableitet, kann im Stamm oder an beliebiger Stelle innerhalb des Workflows verwendet werden. Auf diese Weise können Sie verschiedene Workflowstile beliebig innerhalb von einander erstellen (beispielsweise einen Statuscomputer innerhalb eines Flussdiagramms innerhalb einer Sequenz).
Die meisten dieser Programmiermodelländerungen tragen dazu bei, dass deklarative Workflows zu wesentlichen Bestandteilen werden, da Sie keine imperativen CodeBehind-Dateien mehr zum Definieren von Datenflusseigenschaften benötigen. Dies kann nun alles deklarativ in XAML erfolgen. Da es sich jedoch um recht fundamentale Änderungen handelt, waren einige bedeutende Änderungen an der WF-Laufzeit erforderlich, die letztlich die Kompatibilität mit Ihren .NET Framework 3.x-Aktivitäten stören (in der Randleiste zur Migration von Workflows finden Sie weitere Informationen). Dennoch ist Microsoft überzeugt, dass WF-Entwickler im Laufe der Zeit erheblich vom Vereinfachen des WF-Programmiermodells profitieren werden.
Migrieren von Workflows nach .NET 4.0
Für das neue .NET Framework 4.0-Aktivitätsprogrammiermodell waren einige bedeutende Änderungen an der zentralen WF-Laufzeit erforderlich. Daher können benutzerdefinierte Aktivitäten, die für .NET Framework 3.0 und 3.5 entworfen wurden, nicht ohne weiteres innerhalb eines .NET Framework 4.0-Workflowhosts ausgeführt werden.
Um die Interoperabilität zu vereinfachen, verfügt .NET Framework 4.0 über eine besondere Interopaktivität, dank derer das Umschließen einer benutzerdefinierten .NET 3.x-Aktivität innerhalb eines .NET 4.0-Hosts ganz einfach ist. Dieser Ansatz funktioniert nicht bei allen .NET 3.x-Aktivitäten und insbesondere nicht bei Stammaktivitäten. Wenn Sie zu Visual Studio 2010 wechseln, müssen Sie daher Ihre Workflows mithilfe des neuen Workflowdesigners neu entwerfen (da sich dieser ebenfalls stark verändert hat). Anschließend können Sie benutzerdefinierte .NET 3.x-Aktivitäten mithilfe der neuen Interopaktivität innerhalb Ihrer neuen Workflowdefinitionen umschließen.
Weitere neue WCF-Features in .NET Framework 4.0
Es ist ziemlich offensichtlich, wie Sie einen WCF-Dienst mit einem Workflow implementieren können, aber um wirklich einen deklarativen Workflowdienst herzustellen, müssen Sie auch Dienstverträge definieren und Endpunktdefinitionen mithilfe des deklarativen Nur-XAML-Modells konfigurieren können. Genau dazu dient WCF in .NET Framework 4.0. Angenommen, Sie haben diese WCF-Dienstvertragsdefinition:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int Op1, int Op2);
[OperationContract]
int Subtract(int Op1, int Op2);
};
In .NET Framework 4.0 können Sie denselben Vertrag deklarativ mithilfe der folgenden XAML-Definition definieren:
<ServiceContract Name="ICalculator">
<OperationContract Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res1" Type="p:Int32" />
</OperationContract>
<OperationContract Name="Subtract">
<OperationArgument Name="Op3" Type="p:Int32" />
<OperationArgument Name="Op4" Type="p:Int32" />
<OperationArgument Direction="Out" Name="res2" Type="p:Int32" />
</OperationContract>
</ServiceContract>
Nachdem nun der Dienstvertrag in XAML definiert wurde, besteht der nächste Schritt darin zu definieren, wie der Vertrag projiziert und übertragen werden soll. .NET Framework 4.0 führt das Konzept einer Vertragsprojektion zum Trennen der logischen Vertragsdefinition von der Darstellung der gesendeten und empfangenen Nachrichten ein. Dies ermöglicht Ihnen das Definieren eines Einzeldienstvertrags, der unterschiedlich projiziert werden kann, um verschiedene Messagingstile zu unterstützen.
Sie können beispielsweise eine Vertragsprojektion für SOAP-basiertes Messaging und eine andere Projektion für REST/POX-Messaging haben, aber beide basieren auf demselben logischen Dienstvertrag. Hier sehen Sie, wie eine SOAP-Vertragsprojektion für den gerade definierten Dienstvertrag definiert werden kann:
<Service.KnownProjections>
<SoapContractProjection Name="ICalculatorSoapProjection">
<!-- service contract definition goes here -->
</SoapContractProjection>
</Service.KnownProjections>
Sobald diese Vertragsdefinition und Projektion vorhanden sind, können Sie die Dienstlogik in XAML implementieren. Das Stammelement für die XAML-Dienstdefinition ist „Service“. Das Service-Element enthält den Vertrag und die Projektionsdefinitionen im untergeordneten Service.KnownProjections-Element. Die Dienstimplementierung wird auf dem Service.Implementation-Element abgebildet (bei dem es sich um einen deklarativen Workflow handelt). Schließlich wird die Endpunktkonfiguration des Diensts auf dem Service.Endpoints-Element abgebildet. Abbildung 5 zeigt die vollständige deklarative Dienstdefinition in XAML.
Abbildung 5 Deklarativer WCF-Dienst
<Service xmlns="clr-namespace:System.ServiceModel;assembly=System.WorkflowServiceModel"
xmlns:p="https://schemas.microsoft.com/netfx/2008/xaml/schema"
xmlns:ss="clr-namespace:System.ServiceModel;assembly=System.ServiceModel"
xmlns:sw="clr-namespace:System.WorkflowServiceModel;assembly=System.WorkfowServiceModel"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:x2="https://schemas.microsoft.com/netfx/2008/xaml">
<Service.KnownProjections>
<SoapContractProjection x:Name="ICalculatorSoapProjection">
<ServiceContract x:Name="ICalculatorContract"
<OperationContract Name="Add" x:Name="Add">
<OperationArgument Name="Op1" Type="p:Int32" />
<OperationArgument Name="Op2" Type="p:Int32" />
<OperationArgument Direction="Out" Name="Result"
Type="p:Int32" />
</OperationContract>
</ServiceContract>
</SoapContractProjection>
</Service.KnownProjections>
<Service.Implementation>
<sw:WorkflowServiceImplementation>
<!-- place service implementation here -->
</sw:WorkflowServiceImplementation>
</Service.Implementation>
<Service.Endpoints>
<Endpoint Uri="http://localhost:8080/calc"
ContractProjection="{x2:Reference ICalculatorSoapProjection}">
<Endpoint.Binding>
<ss:BasicHttpBinding />
</Endpoint.Binding>
</Endpoint>
</Service.Endpoints>
</Service>
Ein Nachteil zu diesem frühen Zeitpunkt besteht darin, dass es keinen visuellen Designer zum deklarativen Erstellen von Diensten gibt. Ich hoffe, dass Microsoft beim Bereitstellen der Community Technology Previews (CTPs) eine entwicklerfreundliche Designerfunktionalität für die Arbeit mit der XAML-Definition zur Verfügung stellen wird.
Zusätzlich zur deklarativen Dienstunterstützung und den bereits erwähnten WCF-basierten Aktivitäten verfügt .NET Framework 4.0 über mehrere andere WCF-Verbesserungen auf tieferer Ebene. Einige dieser Features ermöglichen das Verwalten von Workflowdiensten mit den neuen „Dublin“-Erweiterungen. Diese Features umfassen eine verbesserte Konfiguration, Nachrichtenkorrelation, dauerhafte Duplexkommunikation, dauerhafte Zeitgeber und Integration der Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW). Andere Funktionen, die beim Hosten Ihrer Dienste in einer verwalteten Umgebung von Nutzen sind, sind Standardsteuerungsendpunkte und das automatische Starten. In den nächsten Monaten werden Sie mehr über diese Features erfahren.
Die Notwendigkeit von „Dublin“
In der Praxis besteht eine weitere Herausforderung bei der Arbeit mit WCF und WF darin herauszufinden, wo Ihre Dienste und Workflows in einer Serverumgebung gehostet werden sollen. Für WCF ist die Antwort zumeist recht einfach. Häufig werden IIS und der Windows-Prozessaktivierungsdienst (Windows Process Activation Service, WAS) in Windows Server 2008 verwendet.
Heute bietet die Kombination von IIS und WAS mehrere wichtige Features einschließlich Prozessaktivierung als Antwort auf eingehende Nachrichten, Prozessüberwachung und Zustandsverwaltung, Prozesswiederverwendung, CLR-AppDomain-Integration, integrierte Sicherheit sowie einige grundlegende Verwaltungsfunktionen, die über IIS-Manager und Windows PowerShell-Cmdlets zur Verfügung gestellt werden. Aufgrund dieser kombinierten Features ist IIS/WAS in der Regel die richtige Wahl für das Hosten von WCF-Diensten in einer Serverumgebung, da die meisten Entwickler diese Dinge nicht selbst erstellen möchten.
Obwohl IIS/WAS eine Grundlage zum Hosten von WCF-Anwendungen bietet, bleibt es in einigen wichtigen Bereichen hinter den Erwartungen zurück. Der größte Mangel macht sich im Bereich der Dienstverwaltbarkeit bemerkbar. IIS/WAS bietet im Grunde keine WCF-spezifischen Dienstverwaltungsfunktionen wie beispielsweise Dienstablaufverfolgung, Überwachung sowie Analyse ausgeführter Dienstinstanzen. Ein Administrator kann beispielsweise derzeit nicht alle WCF-Dienste auflisten, die in IIS konfiguriert sind – es ist nicht möglich, den Status aller gehosteten Dienste abzufragen. IIS/WAS stellt zudem keine integrierte Unterstützung für das Vereinfachen ausskalierter Bereitstellungen oder häufiger WCF-Konfigurationsaufgaben bereit, was sich als wunder Punkt für WCF erweist.
Die Hostingherausforderungen sind für WF-Anwendungen in Serverumgebungen noch größer aufgrund des inhärent statusbehafteten Modells, das zum Unterstützen lang andauernder Workflows in Serverfarmen erforderlich ist. Aufgrund dieser Komplexitäten hatte Microsoft in .NET Framework 3.0 keinen WF-Serverhost bereitgestellt. Die Entwickler mussten ihn selbst schreiben. Erst mit .NET Framework 3.5 war es mit der Einführung der WorkflowServiceHost-Klasse möglich, WF-Workflows standardmäßig als WCF-Dienste zu hosten, sodass es nun möglich ist, Ihre WF-Workflows auch innerhalb von IIS/WAS zu hosten.
WorkflowServiceHost war ein guter Anfang, aber es war keine Toolunterstützung zum Verwalten statusbehafteter Workflows in einer gesamten Webserverfarm vorhanden, und es wurden keine Tools zum Überwachen und Verwalten ausgeführter Workflowinstanzen zur Laufzeit bereitgestellt.
Im Hinblick auf Verwaltungsfeatures für Dienste und Workflows erwarten die meisten Entwickler eine Funktionalität, die der von BizTalk Server bereitgestellten entspricht, aber gleichzeitig einfacher ist. Viele Organisationen wünschen die BizTalk-Verwaltungsfunktionalität, aber nicht die Integrationsfunktionen oder die Zuverlässigkeitssemantik (und die entsprechenden Leistungseinbußen), die bei der MessageBox von BizTalk Server vorhanden sind. Ein einfacheres, speziell für WCF- und WF-Anwendungen entworfenes Modell ist besser geeignet.
Ein Leitfaden zu „Dublin“
Microsoft hat an einem neuen Satz von Erweiterungen für Windows Server – Codename „Dublin“ – gearbeitet, der wertvolle Hosting- und Verwaltungsfeatures für Ihre WCF- und WF-Anwendungen bietet. „Dublin“ ist im Grunde ein Satz von Dienstverwaltungserweiterungen, die auf IIS basieren und als Teil von Windows Server ausgeliefert werden. Beim Verwenden der „Dublin“-Erweiterungen werden Ihr Dienst und Ihre Workflows weiterhin in IIS/WAS gehostet, aber Ihre Anwendungen verfügen über zusätzliche WCF- und WF-spezifische Verwaltungsfunktionen und Tools, die derzeit in IIS/WAS nicht vorhanden sind.
Die verschiedenen „Dublin“-Erweiterungen werden in einer zukünftigen Version von Windows Server als Teil der Windows Server-Anwendungsserverrolle bereitgestellt. Daher wird der Featuresatz oft als Windows Application Server bezeichnet, obwohl dies nicht der offizielle von Microsoft verwendete Name ist. Im Folgenden werden die neuen Windows Server-Anwendungsservererweiterungen einfach als „Dublin“ bezeichnet.
Die von „Dublin“ gebotenen Hauptfunktionen umfassen Verwaltungsunterstützung für zuverlässige und dauerhafte Dienste und lang andauernde Workflows. „Dublin“ ermöglicht das Bereitstellen einer Anwendung auf einzelnen Servern in einer Farm. Zudem werden die Tools bereitgestellt, die für bestimmte Dienstverwaltungsaufgaben erforderlich sind. Diese Funktionen werden in den folgenden Abschnitten ausführlicher behandelt, aber zuerst geht es um die Gesamtarchitektur, die in Abbildung 6 dargestellt ist.
Abbildung 6 Die „Dublin“-Architektur
Wie Sie sehen, bietet „Dublin“ mehrere Laufzeitdatenbanken, die eine Grundlage für Dienstdauerhaftigkeit und Überwachung bilden. Es gibt eine Schicht von Laufzeitkomponenten und Diensten, die von .NET Framework bereitgestellt werden und auf diesen Datenbanken aufbauen. „Dublin“ erweitert diese Laufzeiten weiter, um integriertes Hosting, Dauerhaftigkeit, Überwachung und Messagingfunktionen bereitzustellen. Diese Schicht bildet in Verbindung mit den zugrunde liegenden Laufzeitdatenbanken das, was als „Dublin“ bezeichnet wird.
Aufgrund der beiden obersten Schichten in der Architektur kann „Dublin“ von Menschen verwendet werden. Es gibt eine Verwaltungs-API-Schicht, die die verschiedenen Funktionen über Windows PowerShell-Cmdlets skriptfähig macht. Zusätzlich ist eine IIS-Manager-Funktionalität vorhanden, mit der die IIS-Administratoren von heute vertraut sein sollten, da sie auf den Windows PowerShell-Cmdlets aufbaut. Sie können also alles, was in IIS-Manager möglich ist, auch in Windows PowerShell tun.
Microsoft hat IIS-Manager zahlreiche Benutzeroberflächenerweiterungen hinzugefügt, damit die verschiedenen, in diesem Abschnitt beschriebenen Hosting- und Verwaltungsaufgaben durchgeführt werden können. Es gibt Erweiterungen zum Bereitstellen und Konfigurieren, zum Verwalten sowie zum Überwachen von Anwendungen. Diese Erweiterungen bieten zudem ein Laufzeitdashboard Ihres Systems, das Dinge wie ausgeführte, angehaltene und beibehaltene Workflowinstanzen anzeigt.
Erstellen eines WCF-Workflowdiensts für „Dublin“
Mithilfe von Visual Studio 2010 ist es wirklich einfach, Dienste zu erstellen, die über eine neue Projektvorlage auf die „Dublin“-Erweiterungen abzielen (siehe Abbildung 7). Diese Projektvorlage bietet Ihnen eine web.config-Datei, die mit dem von „Dublin“ angebotenen Persistenzanbieter und dem dauerhaften Zeitgeberdienst vorkonfiguriert ist.
Abbildung 7 Erstellen einer neuen „Dublin“-Dienstbibliothek
Nachdem Sie das Projekt generiert haben, können Sie sich auf das Implementieren des WCF-Workflowdiensts mithilfe der verschiedenen Verfahren konzentrieren, die bereits in diesem Artikel beschrieben wurden. Die neue Workflowdesignerfunktionalität ermöglicht das Implementieren Ihres gesamten Diensts mithilfe des Ansatzes zur grafischen Workflowentwicklung. Nachdem Sie Ihren vollständigen Workflowdienst erstellt haben, können Sie den Dienst auf einem Windows Server bereitstellen, der mit den „Dublin“-Erweiterungen aktiviert wurde.
Sie können Ihre Dienste in IIS/WAS mit jedem beliebigen Verfahren bereitstellen, das Sie normalerweise für Webanwendungen verwenden (die Bereitstellung kann direkt aus Visual Studio erfolgen, wenn Ihre Umgebung dies zulässt). Sie können zum Automatisieren dieser Aufgaben auch Windows PowerShell-Cmdlets verwenden. (Diese Cmdlets ermöglichen Ihnen das Erstellen automatisierter Bereitstellungsskripts für Ihre WCF- und WF-Umgebung. Wenn Sie diese Cmdlets ausprobieren möchten, öffnen Sie einfach Windows PowerShell auf einem Windows-Anwendungsserver. Dann geben Sie „help <command>“ ein, um etwas über die Grundlagen der Verwendung des jeweiligen Befehls zu erfahren.) Nach der Bereitstellung können Sie IIS-Manager verwenden, um auf die verschiedenen „Dublin“-Erweiterungen zuzugreifen, die in Abbildung 8 hervorgehoben sind.
Abbildung 8 Die „Dublin“-Erweiterungen in IIS-Manager
Bereitstellen von Anwendungen mit „Dublin“
Aus Sicherheits- und Isolierungsgründen ermöglichen viele Umgebungen Entwicklern nicht, Dienste direkt auf ihren verwalteten Servern bereitzustellen. „Dublin“ bietet eine alternative Lösung für das Bereitstellen von Diensten über die Features für den Anwendungsexport/-import.
Sie können WCF- und WF-Anwendungen zur Bereitstellung auf anderen Servern verpacken, indem Sie das Anwendungsexportfeature in IIS-Manager auswählen. Es wird ein Dialogfeld angezeigt, das Sie auffordert, eine spezifische Anwendung zum Exportieren auszuwählen. Nachdem Sie einen Speicherort angegeben haben, wird durch Drücken der Export-Schaltfläche ein Dateipaket mit einer .zip-Erweiterung generiert, das den gesamten WCF- und WF-Code sowie alle Metadaten und Konfigurationseinstellungen für eine einzelne Anwendung enthält. Dieses Paket kann dann über die „Dublin“-Erweiterungen verschoben und von einem anderen Server importiert werden. Jetzt können Sie dem IT-Experten, der Ihre Server verwaltet, einfach die .zip-Datei senden, sodass er sich um alles weitere kümmern kann.
Das ExportApplication-Cmdlet von Windows PowerShell leistet dasselbe. Diese Anwendungsexportfunktion ist auch sehr gut für Systemtest- und Prüfungsumgebungen geeignet.
Sie können eine WCF- und WF-Anwendung durch Auswählen des Anwendungsimportfeatures oder mithilfe des ImportApplication-Cmdlets importieren (Sie können sich den Inhalt eines Pakets auch mithilfe des GetPackageManifest-Cmdlets anzeigen lassen). Anschließend fordert das Importfeature Sie zum Auswählen des Pakets (.zip-Datei) auf, das Sie importieren möchten.
Während des Prozesses können Sie bei Bedarf den Anwendungsnamen, den Anwendungspool und den physischen Pfad für die Anwendung angeben. Da „Dublin“ zentralisierte Persistenzkonfiguration bietet, müssen Sie sich beim Bereitstellen Ihrer Workflowdienste auf einem anderen Server über das Ändern der Persistenzkonfiguration auf Anwendungsebene keine Gedanken machen. Es wird einfach die neue Persistenzdatenbank verwendet, die dem neuen Server zugeordnet ist. Mithilfe dieser Features kann der für diese Aufgaben verantwortliche Systemadministrator den Prozess beim Bereitstellen von WCF- und WF-Anwendungen in einer Serverumgebung sehr einfach handhaben.
Nachdem Sie erfolgreich eine Anwendung bereitgestellt haben, können Sie damit beginnen, Ihre Dienste über die anderen, von „Dublin“ bereitgestellten Erweiterungen zu konfigurieren. In einigen Situationen könnte es beispielsweise erforderlich sein, dass der Systemadministrator die Laufzeitkonfiguration für die Persistenz- und Überwachungsdatenbanken manuell konfiguriert. Mit den „Dublin“-Erweiterungen ist dies recht einfach. Wählen Sie einfach in der Standardansicht die Option „Services“ (Dienste) aus, und es wird eine Liste aller verwalteten Dienste zusammen mit einem rechten Fensterbereich angezeigt, der verschiedene Dienstkonfigurationsoptionen zur Verfügung stellt (siehe Abbildung 9). Mithilfe dieser Optionen können die Persistenzeinstellungen, die Überwachungseinstellungen sowie andere WCF-Einstellungen im Zusammenhang mit der Sicherheit und Einschränkung leicht geändert werden. Eine WCF-Konfigurationsdatei muss dabei nie angerührt werden.
Abbildung 9 Anzeigen und Konfigurieren von Diensten mit den „Dublin“-Erweiterungen
Es gibt mehrere Windows PowerShell-Cmdlets zum Durchführen dieser Aufgaben, einschließlich GetServicePersistence, SetServicePersistence, EnableServiceTracking und GetTrackingParticipant. Dadurch ist es viel einfacher, die Einrichtung und Konfiguration einer Anwendungsserverumgebung zu automatisieren.
Verwalten ausgeführter Anwendungen
Während des Lebenszyklus einer Anwendung müssen Entwickler und Systemadministratoren in der Lage sein, den Zustand der Anwendung zu überwachen, problematische Workflowinstanzen zu identifizieren und anzuzeigen und sie bei Bedarf zu beenden. „Dublin“ bietet zahlreiche Erweiterungen, die auf diese häufigen Verwaltungsanforderungen abzielen.
Wenn in IIS-Manager die Option „Persisted Instances“ (Beibehaltene Instanzen) ausgewählt wird (Abbildung 8), wechseln Sie zu einer Dashboardansicht, die einen Überblick über die ausgeführten Workflowinstanzen bietet, die beibehalten und möglicherweise angehalten wurden (siehe Abbildung 10). Das Feld „Overview“ (Übersicht) zeigt (in Abhängigkeit vom ausgewählten Bereich) die Gesamtzahl der Anwendungen und Dienste, die auf dem Server, auf der Website oder in der Anwendung bereitgestellt werden.
Abbildung 10 Anzeigen beibehaltener Workflowinstanzen
Das Feld „Persisted Instances“ zeigt eine Zusammenfassung der ausgeführten und beibehaltenen Workflowinstanzen an und ruft jene auf, die gesperrt oder angehalten sein könnten (dies bedeutet, dass sie mit einem Fehler geendet haben). Da es sich bei den angehaltenen Instanzen um jene handelt, die in der Regel direkt manuell behandelt werden müssen, bieten sie mehrere andere Felder an, mit deren Hilfe bestimmte angehaltene Instanzen basierend auf dem virtuellen Pfad, dem Dienstnamen oder der Art der Ausnahme leicht isoliert werden können.
Sie können auf einen der (blau dargestellten) Links klicken, um die Liste beibehaltener Instanzen und ihre Details anzuzeigen. An dieser Stelle können Sie Dienstinstanzen durch Auswählen einer der im rechten Fensterbereich angezeigten Aktionen manuell anhalten, beenden oder abbrechen (siehe Abbildung 11). Durch Anhalten einer Dienstinstanz wird das Ausführen der Instanz beendet und das Empfangen neuer Nachrichten verhindert. Die Ausführung angehaltener Instanzen kann später wieder fortgesetzt werden, sodass Nachrichten erneut empfangen werden. Das Beenden einer Dienstinstanz beendet die Ausführung der Instanz und entfernt sie aus dem persistenten Speicher, sodass die Ausführung nicht fortgesetzt werden kann. Schließlich löscht das Abbrechen einer Dienstinstanz den Arbeitsspeicher, der sich auf die betreffende Instanz bezieht, und stellt den letzten Persistenzpunkt wieder her (der im persistenten Speicher gespeichert ist).
Abbildung 11 Anzeigen einzelner beibehaltener Instanzen
Die Windows PowerShell-Cmdlets „GetServiceInstance“ und „StopServiceInstance“ bieten gleichwertige Funktionen von der Befehlszeile aus. Sie stellen zahlreiche Befehlszeilenoptionen zum Identifizieren bestimmter Diensteinstanzen bereit.
Aktualisieren ausgeführter Anwendungen
Ein besonders problematischer Aspekt beim Arbeiten mit realen Systemen ist die Anforderung, sie regelmäßig zu aktualisieren. Für die meisten komplexen verteilten Anwendungen kann die richtige Umsetzung dessen schwierig sein, wenn für die notwendigen Änderungen gleichzeitig Aktualisierungen der Datenbank, der Geschäftslogik und des Dienstcodes erforderlich sind. In der Regel ist es nicht möglich, umfangreiche Aktualisierungen automatisch anzuwenden, während die Anwendung ausgeführt wird.
Eine Möglichkeit zur Lösung dieses Problems besteht darin, die Anwendung offline einzusetzen, während die Aktualisierung durchgeführt wird. Es ist jedoch nicht einfach, eine IIS/WAS-Anwendung offline einzusetzen, während gleichzeitig die Aktualisierung einer Website durchgeführt wird. Dies ist ein weiterer Bereich, in dem „Dublin“-Erweiterungen durch ein einfaches Offlinefeature den Nutzen erhöhen.
Sie können im IIS-Manager eine Anwendung auswählen und dann im rechten Fensterbereich den Befehl „Disable Protocols“ (Protokolle deaktivieren) auswählen, der in Abbildung 8 dargestellt ist (dieser Befehl wird in einer zukünftigen Version wahrscheinlich umbenannt). Dies führt dazu, dass alle Instanzen der Dienste der Anwendung in einem gesperrten Zustand enden oder ihre Ausführung natürlich beenden, wobei das Verarbeiten neuer eingehender Anforderungen nicht möglich ist.
Zu diesem Zeitpunkt wurde der Nachrichtenfluss für diese Anwendung im Grunde beendet, sodass Clients keine Nachrichten mehr an Dienste senden können, ohne Fehler zu erhalten (sie werden nicht in eine Warteschlange gestellt, wie dies sonst in BizTalk Server der Fall wäre). Die Funktionsweise im Hintergrund ist recht einfach: Die „Dublin“-Erweiterung entfernt einfach alle Protokollhandler für die jeweilige Anwendung und speichert sie, sodass sie nach erfolgter Aktualisierung problemlos wiederhergestellt werden können.
Wenn die Anwendung offline ist, können Sie alle erforderlichen Aktualisierungen durchführen. Wenn die Aktualisierungen durchgeführt wurden und Sie bereit sind, die Anwendung wieder online zu stellen, können Sie den Befehl „Restore Protocols“ (Protokolle wiederherstellen) auswählen. Die Windows PowerShell-Cmdlets „DisableApplicationMessageFlow“ und „EnableApplicationMessageFlow“ können verwendet werden, um von der Befehlszeile aus dieselben Aufgaben durchzuführen.
Überwachen ausgeführter Anwendungen
Unternehmen müssen zudem ausgeführte Anwendungen überwachen können, um zu sehen, wie alles funktioniert und welche Änderungen notwendig sein könnten. Die WCF- und WF-Laufzeiten verfügen bereits über eine integrierte Überwachungsinfrastruktur, auf der die „Dublin“-Erweiterungen aufbauen, sodass die Überwachung innerhalb Ihrer WCF- und WF-Anwendungen leicht aktiviert werden kann.
Abbildung 12 Konfigurieren der Standardüberwachung
Es gibt zwei wichtige Akteure in der .NET Framework 4.0-Überwachungsarchitektur: Überwachungsprofile und Überwachsteilnehmer. Entwickler definieren Überwachungsprofile, die der Laufzeit mitteilen, welche Ereignisse überwacht werden sollen, und Überwachungsteilnehmer können diese Ereignisse dann abonnieren.
„Dublin“ hat einige integrierte Überwachungsprofile, mit deren Hilfe ein Standardsatz nützlicher Ereignisse leicht überwacht werden kann. Sie können die Überwachung Ihrer Anwendung leicht aktivieren, indem Sie zu einem bestimmten Dienst in IIS-Manager navigieren und im rechten Fensterbereich die Option „Tracking“ (Überwachung) auswählen.
Das in Abbildung 12 dargestellte Dialogfeld wird angezeigt. Dort können sie einige grundlegende Überwachungsfunktionen für Ihre Workflows und Dienste konfigurieren. Nach erfolgter Konfiguration werden die entsprechenden Aktualisierungen Ihrer Konfiguration durchgeführt, und die WCF/WF-Überwachungsinfrastruktur wird aktiv.
Bei Bedarf können Sie Überwachungsdaten auch über die „Dublin“-Erweiterungen anzeigen. Sie können „View Tracking Data“ (Überwachungsdaten anzeigen) auswählen, während beibehaltene Dienstinstanzen geprüft werden (siehe Abbildung 11). Dabei wird eine SQL-Abfrage an den Überwachungsspeicher durchgeführt, um eine Liste von Überwachungsereignissen zu erstellen und anzuzeigen (siehe Abbildung 13). Wenn Sie benutzerdefinierte Ereignisse überwachen möchten, können Sie benutzerdefinierte Überwachungsprofile definieren und diese über die Option „Tracking Profiles“ (Überwachungsprofile) in der IIS-Manager-Hauptansicht konfigurieren.
Abbildung 13 Anzeigen von Überwachungsdaten
Es ist nicht möglich, hier alle „Dublin“-Features zu besprechen. Es gibt etliche andere überzeugende Features, die weiter erörtert werden sollten (weitere Informationen dazu finden Sie in der Randleiste ,Zusätzliche „Dublin“-Features‘), aber ich hoffe, dass Sie nun über ein besseres Verständnis der Rolle von „Dublin“ und einiger bereitgestellter Hauptfeatures verfügen.
Von „Dublin“ zu „Oslo“?
Wenn Sie von der Plattform mit dem Codenamen „Oslo“ gehört haben, fragen Sie sich jetzt wahrscheinlich, in welchem Zusammenhang „Dublin“ mit dieser Initiative steht. „Oslo“ ist eine neue Modellierungsplattform, die von Microsoft entwickelt wird, um die Art und Weise zu vereinfachen, wie verteilte Anwendungen entworfen, erstellt und verwaltet werden. Die Modellierungsplattform besteht aus drei Hauptkomponenten: aus der „Oslo“-Modelliersprache (auch als „M“ bezeichnet), dem „Oslo“-Repository und dem „Oslo“-Modelliertool (das auch als „Quadrant“ bezeichnet wird). „Oslo“ ist in der Tat eine Plattform, auf der andere Anwendungen und Technologien aufbauen können, um die Benutzerfunktionalität durch einen modellgesteuerten Ansatz zu vereinfachen.
Zusätzliche „Dublin“-Features
„Dublin“ verfügt über mehrere andere Features, die in diesem Artikel nicht im Detail vorgestellt werden konnten. Aber ein Feature, das erwähnt werden sollte, ist die Unterstützung ausskalierter Bereitstellungen in Serverfarmen, die in vorhandene Lösungen für den Lastenausgleich integriert werden, beispielsweise jene für das Verwalten beibehaltener Dienstinstanzen in der Farm über eine zentralisierte Persistenzdatenbank. Die integrierte Fehlerbehandlungslogik ermöglicht das Ausführen beibehaltener Instanzen auf jedem beliebigen Knoten in der Farm und verhindert Racebedingungen, wenn mehrere Knoten um dieselbe Instanz konkurrieren.
Die andere wichtige Komponente ist der Weiterleitungsdienst. Dieser Dienst ermöglicht das Abfangen aller eingehenden Nachrichten, um zentrales Routing basierend auf dem Nachrichteninhalt durchzuführen. Insbesondere bietet dieses Feature eine gute Grundlage für das Erstellen hochentwickelter Lösungen für die Dienstversionsverwaltung.
„Dublin“ verfügt zudem über mehrere wichtige Dienste zum Verwalten des Lebenszyklus von Dienstinstanzen, einschließlich Durable Timer Server und Instance Restart Service. „Dublin“ kann auch den Instance Control Endpoint nutzen, der von .NET Framework 4.0 bereitgestellt wird, und das neue IIS/WAS-Autostartfeature, das das Starten von Diensten ermöglicht, sobald der Computer startet, statt auf die erste Nachricht zu warten. Weitere Artikel zu diesen Features werden in den nächsten Monaten veröffentlicht.
„Dublin“ wird eine der ersten Technologien sein, die die „Oslo“-Modellierplattform nutzt. Sie können „Oslo“-Anwendungen aus dem Repository exportieren und problemlos in „Dublin“ bereitstellen, wo sie von den verschiedenen, in diesem Artikel erörterten Hosting- und Verwaltungsfeatures profitieren können. Das Verwenden von Modellen zum Beschreiben und Automatisieren von Anwendungsbereitstellungen ist sicherlich ein Gewinn für komplexe IT-Umgebungen.
Bei zunehmender Reife von „Dublin“ und „Oslo“ ist es wahrscheinlich, dass die Integration zwischen beiden Technologien zunimmt. Microsoft hat erklärt, dass die beiden Technologien einander stark ergänzen werden.
Wie steht es mit BizTalk Server?
Eine andere häufige Frage lautet, welche Beziehung zwischen „Dublin“ und BizTalk Server besteht. In vielerlei Hinsicht hat BizTalk Server zu vielen Features angeregt, die heute in „Dublin“ vorhanden sind. Obwohl beide Technologien ähnliche Verwaltungsfunktionen bieten, besteht ein großer Unterschied bei ihrem jeweiligen Schwerpunkt. „Dublin“ fügt Windows Server Hosting- und Verwaltungserweiterungen hinzu, die speziell für WCF- und WF-Anwendungen entworfen wurden, während der Schwerpunkt von BizTalk Server die Anwendungsintegration in Nicht-Microsoft-Systeme mithilfe einer Vielfalt verschiedener Nachrichtenformate, Transportmethoden und Zuordnungsverfahren ist.
Der Schwerpunkt von BizTalk Server war immer die Integration in Nicht-Microsoft-Systeme (Branchenanwendungen, Legacysysteme, RFID-Geräte und Business-to-Business-Protokolle), und dies wird auch zukünftig so bleiben. Diese speziellen Stärken werden in den kommenden Jahren weiterhin Schwerpunkt von BizTalk Server bleiben. Im Allgemeinen sollten Sie BizTalk Server weiterhin verwenden, wenn diese Arten von Szenarios der Unternehmensanwendungsintegration für Sie den Schwerpunkt bilden.
Da jedoch viele WCF- und WF-Anwendungen diese Arten von Integrationsfunktionen nicht benötigen, ist BizTalk Server oft nicht sinnvoll. Genau hier kommt „Dublin“ ins Spiel: als einfachere Alternative, die ähnliche Verwaltungsfunktionen bietet. Letztendlich wird „Dublin“ für diese Szenarios kostengünstiger als BizTalk Server sein, da die „Dublin“-Erweiterungen als zentraler Bestandteil in Windows Server enthalten sind, sodass Sie keine Integrationsadapter erwerben müssen, die gar nicht benötigt werden. Es ist wahrscheinlich, dass eine zukünftige Version von BizTalk Server auf den „Dublin“-Erweiterungen aufbauen wird, um die Verwaltungsinvestitionen in Windows Server zu nutzen.
Besonderer Dank für ihre Hilfe bei diesem Artikel gilt Eileen Rumwell, Mark Berman, Dino Chiesa, Mark Fussell, Ford McKinstry, Marjan Kalantar, Cliff Simpkins, Kent Brown, Kris Horrocks und Kenny Wolf.
Aaron Skonnard ist Mitbegründer von Pluralsight, einem führenden Anbieter von Microsoft .NET-Schulungen, der sowohl Schulungen mit Kursleiter als auch Onlineschulungskurse anbietet. Aaron Skonnard ist Autor zahlreicher Bücher, Whitepaper und Artikel sowie Pluralsight-Schulungen zu REST, Windows Communication Foundation und BizTalk Server. Sie erreichen ihn unter pluralsight.com/aaron.