Dieser Artikel wurde maschinell übersetzt.

Grundlagen

Workflowdienste für die lokale Kommunikation

Matt Milner

Downloaden des Codebeispiels

In einer vorherigen Spalte (Siehe “Workflow Communications” im September 2007 Ausstellen von MSDN Magazine, msdn.microsoft.com/magazine/cc163365.aspx) schrieb ich über die Kernarchitektur Kommunikation in Windows Workflow Foundation 3 (WF3). Ein Thema nicht eingegangen, ist die lokale Kommunikation Aktivitäten, die eine Abstraktion über diesen Kommunikationsarchitektur sind. Wenn Sie .NET Framework 4 Beta 1 betrachten, sehen Sie keine HandleExternalEvent-Aktivität. Tatsächlich werden die enthaltenen Aktivitäten für Kommunikation mit WF4, auf Windows Communication Foundation (WCF) erstellt. In diesem Monat zeige ich Ihnen zum Verwenden von WCF für die Kommunikation zwischen einem Workflow und eine Host-Anwendung in Windows Workflow Foundation 3. Dieses Wissen erlangen sollten Sie Hilfe zu Ihrer Entwicklungsprojekte mit WF3 und WF4, wobei WCF die einzige Abstraktion über Warteschlangen ist (bezeichnet als “ Lesezeichen ” in WF4), die im Lieferumfang des Frameworks vorbereiten. (Grundlegende Informationen zum Workflow Services in WF3 finden Sie in meinem Foundations-Rubrik in der Visual Studio 2008 Starten des MSDN Magazine, msdn.microsoft.com/magazine/cc164251.aspx).

Übersicht

Kommunikation zwischen Anwendungen Host und Workflows beweist für einige Entwickler eine Herausforderung, da Sie einfach die Tatsache übersehen können, die den Workflow und Host häufig in unterschiedlichen Threads ausgeführt werden. Der Entwurf der Kommunikationsarchitektur soll Entwickler davor, Verwalten von Threadkontext Marshalling Daten und andere Low-Level-Details kümmern abschirmen. Eine Abstraktion über die Warteschlangen-Architektur in WF ist der WCF-messaging-Integration, die in Version 3.5 von .NET Framework eingeführt wurde. Die meisten Beispiele und Übungen zeigen, wie die Aktivitäten und Erweiterungen zu WCF einen Workflow für Clients verfügbar zu machen, die für den Hostprozess externen verwendet werden können, aber dieses dieselbe Kommunikation Framework kann für die Kommunikation innerhalb desselben Prozesses verwendet werden.

Implementieren die Kommunikation umfasst mehrere Schritte, aber die Arbeit nicht zu viel Betrag mehr als was Sie mit der lokalen Kommunikationsaktivitäten zu tun haben würde.

Bevor Sie etwas anderes tun können, müssen Sie die Verträge für die Kommunikation mit WCF Serviceverträge definieren (oder nur minimal in eine iterative Ansatz definieren beginnen). Als Nächstes müssen Sie diese Verträge in Ihren Workflows verwenden, um die Kommunikation Punkte in der Logik zu modellieren. Schließlich müssen alle miteinander zu verknüpfen, den Workflow und andere Dienste als WCF-Dienste mit Endpunkten konfiguriert gehostet werden.

Erstellen von Bedrohungsmodellen Kommunikation

Die erste Schritt in Modellierung Kommunikation besteht darin, die Verträge zwischen der Anwendung Host und den Workflow zu definieren. WCF-Dienste verwenden Verträge, um die Auflistung der Vorgänge zu definieren, aus denen der Dienst und die Nachrichten, die gesendet und empfangen werden. Da Sie aus der Host an den Workflow und von den Workflow auf die Host kommunizieren, müssen Sie in diesem Fall zwei Serviceverträge und Verwandte Datenverträge zu definieren, wie zeigt Abbildung 1 .

Abbildung 1 für die Kommunikation Verträge

[ServiceContract(
    Namespace = "urn:MSDN/Foundations/LocalCommunications/WCF")]
public interface IHostInterface
{
[OperationContract]
void OrderStatusChange(Order order, string newStatus, string oldStatus);
}

[ServiceContract(
    Namespace="urn:MSDN/Foundations/LocalCommunications/WCF")]
public interface IWorkflowInterface
{
    [OperationContract]
    void SubmitOrder(Order newOrder);

    [OperationContract]
    bool UpdateOrder(Order updatedOrder);
}

[DataContract]
public class Order
{
    [DataMember]
    public int OrderID { get; set; }
    [DataMember]
    public string CustomerName { get; set; }
    [DataMember]
    public double OrderTotal { get; set; }
    [DataMember]
    public string OrderStatus { get; set; }
    }

Mit den Verträgen vorhanden funktioniert den Workflow mit die Send und Receive-Aktivitäten zu modellieren, wie für die Remotekommunikation. Das ist eine der wunderschönes Aspekte von WCF: Remote- oder lokalen, entspricht das Programmiermodell der. Abbildung 2 zeigt als ein einfaches Beispiel einen Workflow mit zwei Receive-Aktivitäten und eine Send-Aktivität, die die Kommunikation zwischen den Workflow und die Host zu modellieren. Die Receive-Aktivitäten mit dem IWorkflowInterface der Servicevertrag konfiguriert sind, und die Send-Aktivität verwendet den IHostInterface-Vertrag.

Bisher mit WCF für die lokale Kommunikation unterscheidet sich nicht wesentlich von WCF für die Remotedatenübertragung verwenden und mithilfe der lokale Kommunikation Aktivitäten und Dienste sehr ähnlich ist. Der Hauptunterschied geht wie der Host Code geschrieben wird, den Workflow starten und Behandeln der Kommunikation, die den Workflow entnommen.

Abbildung 2 Workflow Modelle gegen Verträge

Die Dienste hosten

Da wir Kommunikation in beide Richtungen mit WCF fließen soll, müssen wir Host zwei Dienste – der Workflowdienst des Workflows und einen Dienst in der Anwendung Host zum Empfangen von Nachrichten aus der Workflow ausgeführt. In meinem Beispiel ich eine einfache Windows Presentation Foundation (WPF)-Anwendung als die Host erstellt und der App-Klasse OnStartup und OnExit Methoden zum Verwalten von den Hosts verwendet. Ihre erste Ansichtsneigung bestimmt möglicherweise der WorkflowServiceHost-Klasse, und öffnen Sie es in die OnStartup-Methode nach rechts zu erstellen. Da die Open-Methode nicht blockiert wird, nachdem die Host geöffnet ist, können Sie Verarbeitung fortsetzen, Benutzeroberfläche laden und beginnen mit dem Workflow interagieren. Da WPF (und andere Client-Technologien) einen einzelnen Thread zur Verarbeitung verwendet wird, führt dies schnell zu Problemen, da sowohl der Dienst und der Clientaufruf im gleichen Thread verwenden können, so dass der Client das Zeitlimit überschritten. Um dies zu vermeiden, der WorkflowServiceHost wird erstellt in einem anderen Thread mit den ThreadPool wie dargestellt in Abbildung 3.

Abbildung 3 Hosting den Workflowdienst

ThreadPool.QueueUserWorkItem((o) =>
{

//host the workflow
workflowHost = new WorkflowServiceHost(typeof(
    WorkflowsAndActivities.OrderWorkflow));
workflowHost.AddServiceEndpoint(
    "Contracts.IWorkflowInterface", LocalBinding, WFAddress);
try
{
    workflowHost.Open();
}
catch (Exception ex)
{
    workflowHost.Abort();
    MessageBox.Show(String.Format(
        "There was an error hosting the workflow as a service: {0}",
    ex.Message));
}
});

Die nächste Herausforderung, die auftreten, wird die entsprechende Bindung für die lokale Kommunikation auswählen. Derzeit steht kein Speicher oder in-Process-Bindung ist sehr kompakt für diese Arten von Szenarien. Die beste Option für eine einfache Channel ist die Verwendung der NetNamedPipeBinding mit Sicherheit deaktiviert. Leider Wenn Sie versuchen, diese Bindung und Host verwenden den Workflow als Dienst, erhalten Sie eine Fehlermeldung darüber informiert, dass der Host eine Bindung mit dem Kontext Kanal vorhanden, benötigt da für Ihren Dienstvertrag eventuell eine Sitzung erforderlich ist. Außerdem ist kein Lieferumfang von .NET Framework, der im Lieferumfang von nur drei Kontextbindungen NetNamedPipeContextBinding: BasicHttpContextBinding, NetTcpContextBinding und WSHttpContextBinding. Glücklicherweise können Sie Ihre eigenen benutzerdefinierten Bindungen an der Kontextkanal umfassen erstellen. Abbildung 4 zeigt eine benutzerdefinierte Bindung, die von der NetNamedPipeBinding-Klasse abgeleitet und fügt dem ContextBindingElement in der Bindung. Kommunikation in beide Richtungen kann nun diese Bindung in der Registrierung Endpunkt verwenden, indem Sie verschiedene Adressen.

Abbildung 4 NetNamedPipeContextBinding

public class NetNamedPipeContextBinding : NetNamedPipeBinding
{
    public NetNamedPipeContextBinding() : base(){}

    public NetNamedPipeContextBinding(
        NetNamedPipeSecurityMode securityMode):
        base(securityMode) {}

    public NetNamedPipeContextBinding(string configurationName) :
        base(configurationName) {}

    public override BindingElementCollection CreateBindingElements()
    {
        BindingElementCollection baseElements = base.CreateBindingElements();
        baseElements.Insert(0, new ContextBindingElement(
            ProtectionLevel.EncryptAndSign,
            ContextExchangeMechanism.ContextSoapHeader));

        return baseElements;
    }
}

Mit dieser neuen Bindung können Sie einen Endpunkt auf der WorkflowServiceHost erstellen und öffnen die Host ohne weitere Fehler. Der Workflow ist für den Empfang von Daten von der Host mit den der Servicevertrag bereit. Um diese Daten zu senden, müssen Sie erstellen einen Proxy und Aufrufvorgang, wie in Abbildung 5 dargestellt.

Abbildung 5 Host Code, um einen Workflow starten

App a = (App)Application.Current;
    IWorkflowInterface proxy = new ChannelFactory<IWorkflowInterface>(
    a.LocalBinding, a.WFAddress).CreateChannel();

    proxy.SubmitOrder(
        new Order
        {
            CustomerName = "Matt",
            OrderID = 0,
            OrderTotal = 250.00
        });

Da Sie die Verträge gemeinsam nutzen, ist keine Proxyklasse, so dass Sie die ChannelFactory < TChannel > verwenden, um den Clientproxy zu erstellen.

Während der Workflow gehosteten und zum Empfangen von Nachrichten bereit ist, muss Sie immer noch zum Senden von Nachrichten an die Host konfiguriert werden. Am wichtigsten ist, muss der Workflow einen Clientendpunkt abzurufen, wenn die Send-Aktivität verwenden zu können. Die Send-Aktivität können Sie den Endpunktnamen angeben, in der Regel eine Zuordnung zu einem benannten Endpunkt in der Konfigurationsdatei. Obwohl versetzen die Endpunktinformationen in eine Konfigurationsdatei funktioniert, können Sie zum Speichern der Clientendpunkte, die von der Send-Aktivitäten im Workflow verwendet auch die ChannelManagerService (wie in meinem Artikel vom August 2008 msdn.microsoft.com/magazine/cc721606.aspx besprochen). Abbildung 6 zeigt den Hostcode erstellen Sie den Dienst, und versehen es mit einem benannten Endpunkt WorkflowRuntime gehostet wird, in der WorkflowServiceHost hinzugefügt.

Abbildung 6 Hinzufügen der ChannelManagerService auf die Runtime

ServiceEndpoint endpoint = new ServiceEndpoint
(
    ContractDescription.GetContract(typeof(Contracts.IHostInterface)),
        LocalBinding, new EndpointAddress(HostAddress)
);
endpoint.Name = "HostEndpoint";

WorkflowRuntime runtime =
    workflowHost.Description.Behaviors.Find<WorkflowRuntimeBehavior>().
WorkflowRuntime;

ChannelManagerService chanMan =
    new ChannelManagerService(
        new List<ServiceEndpoint>
        {
            endpoint
        });

runtime.AddService(chanMan);

Wenn des Workflow-Dienstes gehostet bietet die Möglichkeit zum Senden von Nachrichten von den Host an den Workflow, aber Nachrichten an die Host zurückzukehren, benötigen Sie einen WCF-Dienst, der Nachrichten von den Workflow erhalten kann. Dieser Dienst ist ein standard WCF-Dienst in der Anwendung betrieben. Da der Dienst nicht um einen Workflowdienst ist, können Sie die standardmäßigen NetNamedPipeBinding verwenden oder Wiederverwenden der zuvor gezeigten NetNamedPipeContextBinding. Schließlich, da dieser Dienst aus der Workflow aufgerufen wird, kann es auf dem Benutzeroberflächenthread, Interaktion mit UI-Elemente einfacher machen gehostet werden. Abbildung 7 zeigt den hostenden Code für den Dienst.

Abbildung 7 Hosting der Hostdienst

ServiceHost appHost = new ServiceHost(new HostService());
appHost.AddServiceEndpoint("Contracts.IHostInterface",
LocalBinding, HostAddress);

try
{
    appHost.Open();
}
catch (Exception ex)
{
    appHost.Abort();
    MessageBox.Show(String.Format(
        "There was an error hosting the local service: {0}",
    ex.Message));
}

Mit beiden Diensten gehostet wird können nun den Workflow ausführen, eine Nachricht senden und eine Meldung zurück. Jedoch, wenn Sie versuchen zu senden eine zweite Meldung angezeigt, die mithilfe dieses Codes der zweiten Aktivität im Workflow empfangen, wird eine Fehlermeldung über den Kontext.

Behandlung Instanz Korrelation

Eine Möglichkeit, behandeln das Kontext-Problem besteht darin, den gleichen Clientproxy für jeden Aufruf des Dienstes verwenden. Dadurch wird den Clientproxy-die Kontext-IDs (mithilfe der NetNamedPipeContextBinding) verwalten und wieder an den Dienst mit nachfolgenden Anforderungen zu senden.

In einigen Szenarien ist es nicht möglich, den gleichen Proxy um für alle Anforderungen beibehalten. Betrachten Sie den Fall, in dem Sie einen Workflow starten, es zu einer Datenbank beibehalten und die Client-Anwendung zu schließen. Wenn die Clientanwendung erneut startet, benötigen Sie eine Möglichkeit, den Workflow fortsetzen, indem Sie auf diese spezielle Instanz einer anderen Nachricht senden. Der allgemeine Anwendungsfall ist, wenn Sie einen einzelnen Clientproxy verwenden möchten, aber Sie für die Interaktion mit mehreren Workflowinstanzen mit einem eindeutigen Bezeichner müssen. Beispielsweise wird die Benutzeroberfläche enthält eine Liste der Bestellungen, jeweils mit einem entsprechenden Workflow, und wenn der Benutzer ein Aktion in einem ausgewählten aufruft, müssen Sie eine Nachricht an die Workflowinstanz zu senden. Lassen die Bindung verwalten die Kontext-ID funktioniert in diesem Szenario nicht, da es immer den Bezeichner des letzten Workflows verwenden wird mit dem Sie interagiert.

Für das erste Szenario – einen neuen Proxy für jeden Aufruf verwenden, müssen Sie manuell die Workflow-ID in den Kontext mithilfe der IContextManager-Schnittstelle festlegen. IContextManager erfolgt über die GetProperty < TProperty >-Methode auf der IClientChannel-Schnittstelle. Sobald Sie die IContextManager haben, können Sie es zum Abrufen oder Festlegen des Kontexts.

Der Kontext selbst ist ein Wörterbuch mit Name / Wert-Paare, die wichtigste der InstanceId-Wert ist. Der folgende Code zeigt, wie abgerufen die ID aus dem Kontext damit es von der Clientanwendung für zu einem späteren Zeitpunkt gespeichert werden kann Wenn Sie mit der gleichen Workflowinstanz interagieren müssen. In diesem Beispiel wird die ID in einer Datenbank gespeichert werden, anstatt die Client-Benutzeroberfläche angezeigt wird:

IContextManager mgr = ((IClientChannel)proxy).GetProperty<IContextManager>();
      
string wfID = mgr.GetContext()["instanceId"];
wfIdText.Text = wfID;

Sobald Sie mit dem ersten Aufruf der Workflowdienst vornehmen, wird der Kontext automatisch mit der Instanz-ID des Workflows durch Kontextbindung auf den Dienstendpunkt aufgefüllt.

Wenn Sie einen neu erstellten Proxy verwenden, um die Kommunikation mit einer Workflowinstanz, das zuvor erstellt wurde, können Sie eine ähnliche Methode verwenden, um den Bezeichner im Kontext, stellen Sie sicher, dass Ihre Nachricht an der richtigen Workflowinstanz weitergeleitet wird wie folgt festgelegt:

IContextManager mgr = ((IClientChannel)proxy).GetProperty<IContextManager>();
  mgr.SetContext(new Dictionary<string, string>{
    {"instanceId", wfIdText.Text}
  });

Wenn Sie einen neu erstellten Proxy dieser Code funktioniert problemlos das erste Mal haben jedoch nicht, wenn Sie versuchen, den Kontext ein zweites Mal zum Aufrufen einer anderen Workflowinstanz festzulegen. Der Fehler, der Sie darüber informiert, dass den Kontext nicht geändert werden kann, wenn die automatische Kontextverwaltung aktiviert ist. Sie sind im Wesentlichen mitgeteilt, dass Sie können nicht den Kuchen und Essen zu. Wenn den Kontext automatisch verwaltet werden soll, können nicht Sie diese manuell bearbeiten. Wenn Sie den Kontext manuell verwalten möchten, nicht Sie leider automatische Verwaltung abrufen, was bedeutet, Sie die Workflowinstanz-ID aus dem Kontext abrufen können dass, wie ich zuvor gezeigt.

Für den Umgang mit dieser Diskrepanz nicht behandeln jeweils separat. Für den ersten Aufruf zu einem Workflow verwenden Sie einen neuen Proxy, aber für alle nachfolgenden Aufrufe an eine vorhandene Workflowinstanz, verwenden Sie einen einzelnen Clientproxy und den Kontext manuell verwalten.

Für den ersten Aufruf sollten Sie eine einzelne ChannelFactory < TChannel > verwenden, um die Proxys zu erstellen. Dies führt zu einer verbesserten Leistung, da die Erstellung der ChannelFactory Mehraufwand hat Sie nicht zum Duplizieren für jeden ersten Aufruf. Mithilfe von Code, wie die weiter oben in Abbildung 5 können Sie eine einzelne ChannelFactory < TChannel > zum Erstellen des ersten Proxys verwenden. Im aufrufenden Code sollten Sie nach der Verwendung des Proxys die Close-Methode aufrufen, um den Proxy Freigeben der best Practice folgen.

Dies ist die standard-WCF-Code für den Proxy mit die Factorymethode Kanal erstellen. Da die Bindung eine Kontextbindung ist, erhalten Sie automatische Kontextverwaltung in der Standardeinstellung, d. h., Sie den Instanzenbezeichner Workflow aus dem Kontext extrahieren können, nach dem ersten Aufrufen an den Workflow.

Für nachfolgende Anrufe, müssen Sie den Kontext selbst verwalten, und dies umfasst mithilfe von WCF-Clientcode, der nicht so häufig von Entwicklern verwendet wird. Um den Kontext manuell festzulegen, müssen Sie eine OperationContextScope verwenden und die MessageContextProperty zu erstellen. Die MessageContextProperty ist für die Nachricht festlegen, wie es, gesendet wird, ist äquivalent zur Verwendung der IContextManager zum Festlegen des Kontexts, mit der Ausnahme, dass die Eigenschaft direkt mit funktioniert auch dann, wenn die Kontextverwaltung deaktiviert ist. Abbildung 8 zeigt den Code zum Erstellen des Proxys die gleiche ChannelFactory < TChannel >, die verwendet wurde, für den ersten Proxy verwenden. Der Unterschied besteht darin, dass in diesem Fall die IContextManager verwendet, wird um das automatische Kontext Management-Feature deaktivieren und ein zwischengespeicherter Proxy verwendet wird, statt bei jeder Anforderung eine neue zu erstellen.

Abbildung 8 Deaktivieren von Automatische Context Verwaltung

App a = (App)Application.Current;

if (updateProxy == null)
{
    if (factory == null)
        factory = new ChannelFactory<IWorkflowInterface>(
            a.LocalBinding, a.WFAddress);

        updateProxy = factory.CreateChannel();
        IContextManager mgr =
            ((IClientChannel)updateProxy).GetProperty<IContextManager>();
        mgr.Enabled = false;
        ((IClientChannel)updateProxy).Open();
}

Nachdem der Proxy erstellt wurde, müssen Sie erstellen eine OperationContextScope und die ausgehende Nachrichteneigenschaften auf den Bereich der MessageContextProperty hinzuzufügen. Dadurch wird die Eigenschaft an, die während der Dauer des Bereichs in die ausgehenden Nachrichten eingeschlossen werden sollen. Abbildung 9 zeigt den Code erstellen und die Message-Eigenschaft unter Verwendung der OperationContextScope festlegen.

Abbildung 9 verwenden OperationContextScope

using (OperationContextScope scope =
    new OperationContextScope((IContextChannel)proxy))
{
    ContextMessageProperty property = new ContextMessageProperty(
        new Dictionary<string, string>
        {
            {“instanceId”, wfIdText.Text}
        });

OperationContext.Current.OutgoingMessageProperties.Add(
    "ContextMessageProperty", property);

proxy.UpdateOrder(
    new Order
        {
            CustomerName = "Matt",
            OrderID = 2,
            OrderTotal = 250.00,
            OrderStatus = "Updated"
        });
}

Dies mag wie ziemlich etwas Arbeit nur für die Kommunikation zwischen den Host und der Workflow. Die gute Nachricht ist, dass ein Großteil dieser Logik und die Verwaltung von Bezeichnern in ein paar Klassen gekapselt werden kann. Allerdings es, weil codieren Ihr Client in einer bestimmten Art und Weise, die sicherstellen, dass der Kontext für diese Fälle korrekt verwaltet werden, in dem Sie mehr als eine Nachricht an die Workflowinstanz zu senden müssen. Im Codedownload für diesen Artikel ich habe eine Beispiel-Host für einen Workflow mit lokale Kommunikation, der versucht, ein Großteil der Komplexität kapseln beigefügt, und die Beispielanwendung veranschaulicht, wie Sie mit der Host.

Ein Word Informationen zu Interface Benutzereingriff

Einer der Hauptgründe, Senden von Daten aus den Workflow auf die Host, ist, dass Sie es an einen Benutzer in der Application Interface präsentieren möchten. Glücklicherweise müssen Sie bei diesem Modell einige Optionen festlegen, um die Features der Benutzeroberfläche, einschließlich Datenbindung in WPF nutzen. Ein einfaches Beispiel wenn Sie möchten Ihre Benutzeroberfläche die Datenbindung verwenden und die Benutzeroberfläche aktualisiert, wenn Daten aus den Workflow empfangen werden können Sie Ihre Benutzeroberfläche direkt an die Host-Dienstinstanz binden.

Der Schlüssel zur Verwendung der Dienstinstanz als den Datenkontext für das Fenster ist, dass die Instanz als Singleton gehostet werden muss. Wenn Sie den Dienst Host als Singleton, Sie haben Zugriff auf die Instanz, und es in Ihrer Benutzeroberfläche verwenden können. Der in Abbildung 10 gezeigten einfachen Host-Dienst aktualisiert eine Eigenschaft, wenn es Informationen von den Workflow empfängt und die INotifyPropertyChangedInterface, verwendet um die Datenbindung Infrastruktur, die Änderungen sofort übernommen. Beachten Sie, die ServiceBehavior Attribut angibt, dass diese Klasse als Singleton gehostet werden soll. Wenn Sie wieder zu Abbildung 7 betrachten, sehen Sie die ServiceHost-Instanz nicht in einen Typ, sondern mit einer Instanz der Klasse instanziiert.

Abbildung 10 Service-Implementierung mit INotifyPropertyChanged

[ServiceBehavior(InstanceContextMode=InstanceContextMode.Single)]
internal class HostService : IHostInterface, INotifyPropertyChanged
{
    public void OrderStatusChange(Order order, string newStatus,
        string oldStatus)
    {
        CurrentMessage = String.Format("Order status changed to {0}",
            newStatus);
    }

private string msg;

public string CurrentMessage {
get { return msg; }
set
    {
        msg = value;
        if (PropertyChanged != null)
            PropertyChanged(this, new PropertyChangedEventArgs(
                "CurrentMessage"));
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

Zur Datenbindung mit diesem Wert kann der DataContext des Fensters oder ein bestimmtes Steuerelement im Fenster mit der Instanz festgelegt werden. Die Instanz kann durch Verwendung der SingletonInstance-Eigenschaft für die ServiceHost-Klasse abgerufen werden, wie hier gezeigt:

HostService host = ((App)Application.Current).appHost.SingletonInstance as HostService;
  if (host != null)
    this.DataContext = host;

Jetzt können Sie einfach Elemente im Fenster Eigenschaften für das Objekt binden wie mit diesem TextBlock dargestellt:

<TextBlock Text="{Binding CurrentMessage}" Grid.Row="3" />

Wie bereits erwähnt, ist dies ein einfaches Beispiel für was Sie tun können. In einer realen Anwendung würden Sie wahrscheinlich nicht direkt an die Dienstinstanz binden jedoch stattdessen auf einige Objekte, auf welche, die beide Ihre Fenster und die Dienstimplementierung Zugriff hatten, binden.

Blick in die Zukunft zu WF4

WF4 bietet einige Features, die lokale Kommunikation über WCF noch leichter machen. Das primäre Feature ist Nachrichtenkorrelation, die nicht auf das Protokoll basiert. D. h. die Verwendung einer Workflow-Instanz-ID werden immer noch eine Option, jedoch wird eine neue Option Nachrichten je nach Inhalt der Nachricht korreliert werden aktiviert. Also, wenn jeder Ihrer Nachrichten eine Bestell-Nr., eine Kunden ID oder einige andere Daten enthalten, können Sie Korrelationen zwischen dieser Nachrichten definieren und keine Bindung zu verwenden, die Kontextverwaltung unterstützt.

Die Tatsache, die sowohl WPF als auch WF auf den gleichen Kern XAML-APIs in .NET Framework, Version 4 aufbauen kann darüber hinaus einige interessanten Möglichkeiten für die Integration von Technologien auf neue Weise öffnen. Wie wir näher auf die Version von .NET Framework 4 erhalten, wird ich weitere Details enthalten, auf die Integration von WF in WCF und WPF, zusammen mit anderen Inhalte für die interne Funktionsweise des WF4.

Matt Milner ist Mitglied des technischen Personals bei Pluralsight, wo er auf verbundener Systeme Technologien (WCF, Windows Workflow Foundation, BizTalk, “ Dublin ” und die Azure Services-Plattform) konzentriert. Matt ist ebenfalls ein unabhängiger Berater, spezialisiert auf Microsoft .NET Anwendung entwerfen und entwickeln. Er kann seine liebe Technologie regelmäßig, indem er hält Vorträge auf lokale, regionale und internationale Konferenzen wie Tech · Ed. Microsoft hat Milner als MVP für seine Beiträge Community, um verbundene Systeme Technologie erkannt. Sie können ihn über seinen Blog unter pluralsight.com/community/blogs/matt-Kontakt.