locked
WCF Abstraktion RRS feed

  • Frage

  • Hallo Leute,

    ich benutze schon länger WCF für den Kommunikationsaustausch zwischen meinen Applikationen. Mich stören ganz besonders die WCF spezifischen Attribute wie "ServiceContract", "OperationContract", usw.

    Deshalb möchte ich eine Art "Framework" entwickeln, bei deinen ich dynamisch C# Schnittstellen hinzufügen kann. Bei einem "entfernten Aufruf" wird der Aufruf intern in ein WCF Aufruf umgewandelt. Also nach außen hin soll quasi nicht bekannt sein, dass es sich um einen WCF Aufruf handelt. Ich möchte das machen, damit ich vielleicht irgendwann mal in der Zukunft die Kommunikationstechnologie austauschen kann (z.B. .NET Remoting etc.).

    Hat schon mal jemand von euch solch eine Abstraktion einer Kommunikationstechnologie gemacht? Macht das überhaupt Sinn? Wie würdet ihr das machen?

    Also im groben muss man sich das so vorstellen:

    static class MyDynamicCommunicationFramework
    {
       static T InitConnection<T>();
    }

    interface MyTimeInterface
    {
      DateTime CurrentTime {get;}
      event EventHandler TimeChanged;
    }

    MyTimeInterface myTime = MyDynamicCommunicationFramework.InitConnection<MyTimeInterface>();
    Console.WriteLine(myTime.CurrentTime);
    myTime.TimeChanged += (s, e) => { Console.WriteLine("Time changed!"); };

    Und im MyDynamicCommunicationFramework müsste dann irgendwie der echte WCF Aufruf erfolgen. Also vielleicht irgendwie über Reflection, OperationDescriptor oder ähnliches.


    • Bearbeitet user_54321 Montag, 31. Dezember 2012 15:23
    Montag, 31. Dezember 2012 15:03

Antworten

  • Hallo,

    man hat tatsächlich die Möglichkeit, den ServiceHost um Endpoints, Verhalten und Verträge dynamisch zu erweitern. Im System.ServiceModel.Description-Namensraum findest Du alle dazu benötigten Klassen (ServiceDescription, ContractDescription, OperationDescription usw.). Sieh dir bitte die Beispiele in der MSDN-Dokumentation der o.g. Klassen an. Nicht ganz trivial, wenn Du mich fragst, jedoch machbar.

    Aber was genau motiviert dich in deiner Problemstellung? - Wenn Du später mal statt dem WCF-Proxy eine andere Klasse verwenden möchtest, könntest Du ja das Strategy-Design-Pattern in deiner Anwendung implementieren, im Pseudocode etwa: 

    var configuredPolicy = MyConfiguration.GetSvcInteractionPolicy(); // z.B. UseWcfPolicy
    
    IMyTimeInterface timeInterface =
    	MyDynamicCommunicationFramework.CreateSvcInteractionObject<MyTimeInterface>(configuredPolicy);
    
    var currentTime = timeInterface.CurrentTime;

    Und wenn dir die Dependenz zum WCF-Proxy missfällt, könntest Du die Klassen etwas lockerer aneinander koppeln, indem Du nur die Schnittstelle des WCF-Proxy über MEF in deine Anwendung einbindest. So würde die konsumierende Anwendung nichts über die Implementationsdetails der importierten Parts wissen. Auch in MEF müßtest Du mit Attributen hantieren, deren Menge ist aber überschaubar.

    Das Hauptproblem dabei sehe ich aber u.a. darin (auch wg. Stichwort remoting), dass die von dem potentiellen Framework zurückgegebenen Objekte unterschiedliche Lebensdauer haben könnten. Der Consumer-Code kann unmöglich im voraus alle Szenarien abdecken, noch bevor es weiß was der konkrete Laufzeittyp hinter der Interface ist.


    Gruß
    Marcel

    Donnerstag, 3. Januar 2013 12:50

Alle Antworten

  • Hallo,

    man hat tatsächlich die Möglichkeit, den ServiceHost um Endpoints, Verhalten und Verträge dynamisch zu erweitern. Im System.ServiceModel.Description-Namensraum findest Du alle dazu benötigten Klassen (ServiceDescription, ContractDescription, OperationDescription usw.). Sieh dir bitte die Beispiele in der MSDN-Dokumentation der o.g. Klassen an. Nicht ganz trivial, wenn Du mich fragst, jedoch machbar.

    Aber was genau motiviert dich in deiner Problemstellung? - Wenn Du später mal statt dem WCF-Proxy eine andere Klasse verwenden möchtest, könntest Du ja das Strategy-Design-Pattern in deiner Anwendung implementieren, im Pseudocode etwa: 

    var configuredPolicy = MyConfiguration.GetSvcInteractionPolicy(); // z.B. UseWcfPolicy
    
    IMyTimeInterface timeInterface =
    	MyDynamicCommunicationFramework.CreateSvcInteractionObject<MyTimeInterface>(configuredPolicy);
    
    var currentTime = timeInterface.CurrentTime;

    Und wenn dir die Dependenz zum WCF-Proxy missfällt, könntest Du die Klassen etwas lockerer aneinander koppeln, indem Du nur die Schnittstelle des WCF-Proxy über MEF in deine Anwendung einbindest. So würde die konsumierende Anwendung nichts über die Implementationsdetails der importierten Parts wissen. Auch in MEF müßtest Du mit Attributen hantieren, deren Menge ist aber überschaubar.

    Das Hauptproblem dabei sehe ich aber u.a. darin (auch wg. Stichwort remoting), dass die von dem potentiellen Framework zurückgegebenen Objekte unterschiedliche Lebensdauer haben könnten. Der Consumer-Code kann unmöglich im voraus alle Szenarien abdecken, noch bevor es weiß was der konkrete Laufzeittyp hinter der Interface ist.


    Gruß
    Marcel

    Donnerstag, 3. Januar 2013 12:50
  • Hallo user_54321,

    Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert


    Robert Breitenhofer, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Mittwoch, 23. Januar 2013 15:11
    Moderator