基於具有NamedNetPipes綁定的解析端點地址動態創建WCF ServiceHost

Question

需要一種方法來使知名端點上的一項服務返回作為相對地址的字符串。 然后，客戶端可以使用這些相對地址連接到端點。 顯然，這在某種程度上類似於REST，但是在這種情況下，使用NetNamedPipeBinding for IPC運行Windows服務，因此不需要HTTP。

不想提前創建端點，因為可能會有大量的相對地址，只有客戶端會感興趣的相對地址。

所有合同都是事先知道的。

試圖找到使用AddressFilterMode的解決方案，但不確定如何提供新的Binding，以便客戶端連接到UriTemplate，但不想使用HTTP框架。 由於限於.Net 3.5，因此尚未研究RoutingService 。

客戶端的偽代碼如下所示...

namespace Testing
{
    class RunTest
    {
        static void Test()
        {
            NetNamedPipeBinding namedpipe = new NetNamedPipeBinding();
            ChannelFactory<Contracts.IRoot> factoryRoot =
                new ChannelFactory<Contracts.IRoot>(
                namedpipe
                , new EndpointAddress("net.pipe://localhost/root");
            );
            Contracts.IRoot root = factoryRoot.CreateChannel();
            ICommunicationObject commsRoot = root as ICommunicationObject;
            commsRoot.Open();

            // Service examines address and creates Endpoint dynamically.
            string address = root.SomeFunctionWhichGetsARelativeAddress();

            // IBar service routes endpoint requests internally based on
            // "address" variable.
            ChannelFactory<Contracts.IBar> factoryBar = 
                new ChannelFactory<Contracts.IBar>(
                namedpipe
                , new EndpointAddress("net.pipe://localhost/root/IBar/" +
                                       address)
            );
            Contracts.IBar bar = factoryBar.CreateChannel();
            bar.DoSomething();
        }
    } // Ends class RunTest
} // Ends namespace Testing

Answer 1

AddressFilterMode.Prefix可能就足夠了。 使用的實際端點可以在經由服務方法進行檢查的OperationContext 。 目前 。 IncomingMessageHeaders 。 至

助手代碼可以解析終結點並從那里進行任何必要的內部處理。 希望服務器端具有一些可擴展性，可以簡化該代碼。

主機的偽代碼：

namespace Services
{
    [System.ServiceModel.ServiceBehavior(AddressFilterMode =
         System.ServiceModel.AddressFilterMode.Prefix)]
    class BarService : Contracts.IBar
    {
        #region IBar Members

        public void DoSomething()
        {
            System.Uri endpoint = System.ServiceModel.OperationContext.Current.IncomingMessageHeaders.To;
            Console.WriteLine("DoSomething endpoint: {0}", endpoint);
        }
    } // Ends class BarService
} // Ends namespace Services
class RunHost
{
    static void HostIBar()
    {
        System.Uri uriBase = new System.Uri("net.pipe://localhost");
        System.ServiceModel.ServiceHost hostBar =
            new System.ServiceModel.ServiceHost(
            typeof(Services.BarService),
            uriBase);
        hostBar.AddServiceEndpoint(
              typeof(Contracts.IBar) // Type implementedContract
            , namedpipeBinding // System.ServiceModel.Channels.Binding binding
            , "root/IBar" //string address
        );
        hostBar.Open();

        Console.WriteLine("Press <ENTER> to stop...");
        Console.ReadLine();
    }
}

更正：我本來是說這不會將"net.pipe://localhost/root/IBar/1"和"net.pipe://localhost/root/IBar/2"作為不同的端點，但是做。 每個都導致創建和調用其自己的WCF服務實例。

另一個更改是將數據編碼為URL樣式查詢參數，而不是將其嵌入路徑中。 例如： "net.pipe://localhost/root/IBar?something=1&somethingelse=11"和"net.pipe://localhost/root/IBar?something=2&somethingelse=22"使用HttpUtility.ParseQueryString

Answer 2

郵件篩選器是解決方法。 您可以使用“前綴”或創建自定義。

WCF深度尋址

在本文的“ 消息過濾器”部分中：

...它使用消息過濾器確定匹配的端點（如果存在）。 您可以選擇使用哪個消息過濾器，也可以提供自己的消息過濾器。 這種靈活性使您在使用Windows Communication Foundation來實現除傳統SOAP之外的功能時可以擺脫傳統的調度模型的束縛，例如，此處描述的技術使您可以在Windows Communication Foundation消息傳遞基礎上實現REST / POX樣式的服務。

順便問一個好問題。 我學到了一些東西試圖解決這個問題。