Event-Driven Communication Foundation

• Download demo Chat Room project - 21.2 KB
• Download source - 13.4 KB

Introduction

It is common knowledge that WCF is a very powerful technology. Unfortunately, it is practically impossible to achieve this power without complex concepts such as proxies, asynchronous delegates, duplex channels and callback handlers. Even if you are an expert in these concepts, you will have to write tons of code to implement effective and reliable messaging.

Moreover, since GUI and Event-Driven Architecture have become standard, you will need to design Asynchronous Event Engines with multi-casting and filtering. I am sure these words do not scare you and you are definitely up to this work, but why not to take advantage of ready-to-use solutions that save you time and allow thinking more about your business tasks? Let's take a smooth look at one such solution.

I want to introduce a tool that I am going to use in all my projects. In a few words, this is an event-driven framework for WCF. We called it Event Driven Communication Foundation (EdCF) and it is based on the Publisher/Subscriber pattern. Puzzling code has been hidden and now all you need to do for organizing bidirectional, asynchronous, reliable messaging is just list your events and write event handlers.

Now I will try to partition our framework into functional pieces and get down to the nitty-gritty.

Publisher/Subscriber Pattern

First of all, I want to say several words about the Publisher/Subscriber pattern. Why have we chosen this pattern as the basis for the framework? Because there is a number of different communication scenarios: one-to-one, one-to-many, many-to-many. As soon as we decided that our framework should be able to implement all these scenarios, the most suitable design pattern was the Publisher/Subscriber one with an intermediate pub/sub service.

How does this work? Any remote peer takes the role of the publisher or/and subscriber. The publisher informs the intermediate Pub/Sub service that it is able to fire events. If a subscriber wants to get notification about any specific event, it asks the Pub/Sub service to add him to the list of interested subscribers. Whenever the publisher changes state, it fires an event. The intermediate Pub/Sub service stores a list of subscribers and multi-casts the event to all subscribers from this list. For more information, please refer to this article.

Asynchronous Messaging

This is the first tricky lock you will face if you've decided to do all the work by yourself. The scenario is simple: your server needs to process the same request from two different clients.

The first client has a slow connection. If your server knows nothing about asynchronous messaging, the second client will wait until the first request is processed. What should we do if we have dozens of concurrent clients? We should perform each request in the separated thread from a thread pool. This requires decisions on an architecture level and knowledge about asynchronous delegates. To illustrate how confusing this code may be, I show you the following:

I have the list of subscribers and want to publish the MyEvent event. I will write something like this:

public static Publish (TSub[] subscribers, string eventName)
{
    foreach (TSub subscriber in subscribers)
    {
        Invoke(subscriber, eventName)
    }
}

If I decided to do the same but asynchronously, I would have much more typing:

public static Publish (TSub[] subscribers, string eventName)
{
    WaitCallback callbackDelegate = delegate (TSub subscriber) 
    {
        Invoke(subscriber, eventName);
    }

    Action<TSub>queueUp = delegate(TSub subscriber)
    {
        ThreadPool.QueueUserWorkItem(callbackDelegate, subscriber)
    }

    Array.ForEach(subscriber, queueUp);
}

Fortunately, this entire outfit is hidden deep in the framework. From the end-user's point of view, it looks like a single method invocation:

PublishingService.MyEvent();

Result Collector

One of the advantages of the Publisher/Subscriber pattern with the intermediate Pub/Sub service is decoupling publishers and subscribers. The subscriber has no knowledge about the publisher and vice-versa. This is very important behavior, since you need to build a stable and extensible solution with hundreds of clients.

However, what if you need to implement communication between a few closely tied peers? In this case, the ability to get the result of event raising is disabled. For example, imagine the classic calculator scenario. A client connects to the server and asks it to sum two values and return the result. As you remember, we wanted to have a framework working in a wide spectrum of scenarios. Thus, the described problem should not bother our users. We should offer a solution and be able to pass results of the event to the publisher.

For example, any single subscriber should return a string. The publisher wants to have a list of strings from all subscribers as the result of the event raising. From the end-user standpoint, the most useful would be the following:

string [] myResult = PublishingService.MyEvent();

However, this code will freeze up the publisher thread until all subscribers reply. We are not going to have such a drawback. We want to collect results asynchronously and get them as soon as they are ready. The solution is to use callbacks. The publisher is able to raise any event described in the IMyEvents_Pub interface.

[ServiceContract]
public interface IMyEvents_Pub
{
    [OperationContract(IsOneWay = true)]
    [EventDrivenOperationContract(IsWithReply = true)]
    string MyEvent();
}

If you need to get the results of the event, you need to mark the corresponding method of the IMyEvent_Pub interface with the [EventDrivenOperationContract(IsWithReply = true)] attribute. Based on this information, the framework will automatically generate the whole infrastructure, interfaces, callback contracts, proxies and bindings. The only thing you need to do is just define a class implementing the IMyEvents_PubCallback interface on the publisher side. For more information, please refer to the "Code Generation" section of this document.

public class MyPublishCallbackHandler : IMyEvents_PubCallback
{
    public void MyEventReply(string[] returnedResults)
    {
        Console.WriteLine("Returned results: ");
        foreach (string s in returnedResults)
            Console.WriteLine("\t" + s);
    }
}

The publisher raises an event. As soon as the results are ready, the Pub/Sub service makes a callback to the publisher with an array of results as parameters.

Subscriber Filtering

The filtering of subscribers is quite a common task for distributed applications. It is set when the list of subscribers is not permanent and depends on the event we need to process. For example, take a simple Chat sample with two ChatRooms. If a subscriber enters the first ChatRoom, it is not interested in messages published in the second one. So, we should be able to prevent receipt of wrong messages. To take advantage of the filtering options of the framework, an end-user should do the following:

1. Define a Filter enum as a member of the Pub/Sub service:

   [Flags]
   public enum Filter
   {
       ChatRoom1 = 0x1,
       ChatRoom2 = 0x2
   }

2. Mark appropriate events with the [EventDrivenOperationContract(IsWithFilter = true)] attribute:

   [ServiceContract]
   public interface IMyEvents_Pub
   {
       [OperationContract(IsOneWay = true)]
       [EventDrivenOperationContract(IsWithFilter = true)]
       void MyEvent(Filter filter);
   }

3. Subscribe subscribers with the corresponding filter:

   SubscribeWithFilter("MyEvent", (int)Filter.ChatRoom1);

To subscribe with several filters, just use the bitwise OR operator:

SubscribeWithFilter("MyEvent", 
    (int)(Filter.ChatRoom1 | Filter.ChatRoom2));

Code Generation

This simplicity appears self-evident, but the framework is doing hard work behind the scenes. As I mentioned before, the framework is actively used in our everyday work. Sometimes it is very tedious to write the same pieces of code again and again. So, we decided to apply automatic code generation to eradicate some boring work. Although this code generation is widely used, the end-user will never face it. Thus, to save your and my time, I will not uncover all the places and dig all the code. I'll just show you an example and you will understand the gist.

Let's return to the "Result Collector" section. To use this functionality, the end-user should write only five short lines of code:

//Define an event and mark it with special atribute 

[EventDrivenOperationContract(IsWithReply = true)]
string MyEvent();

//Write a callback handler 

public class MyPublishCallbackHandler : IMyEvents_PubCallback
{
public void MyEventReply(string[] returnedResults)
{            
}
}

Very simple, isn't it? That's because the framework is doing all the work instead of us.

1. It generates the IPublishCallback interface. Publisher should realize this interface to collect the results. This interface contains methods with the Reply postfix corresponding to every event marked with the [EventDrivenOperationContract(IsWithReply = true)] attribute.
2. It offers the PublishCallbackBiulder builder, which generates instances of transparent proxy of type IPublishCallback. The proxy is retrieved from the OperationContext of the calls and actively use in the framework.
3. It wraps the IMyEvent_Pub interface, as it should require IPublishCallback implementation on the publisher side.
4. It generates the ReturnedResultsConverter class. As you understand, any single subscriber returns a single value, but a publisher should have a list of all results from all subscribers. The ReturnResultConverter class greatly helps here. It makes it possible to convert subscribers returned with results of type Object[] (System.Reflection.MethodInfo.Invoke() returns Object) to the array collection of the correct return type (e.g. if subscriber returns String then the publisher expects String[]).
5. The ReturnedResultsConverter class content corresponds to each event method marked with the ReplyResultsConverter postfix

Now take a look at the hidden code. Let's imagine we have a single MyEvent event, as defined in the beginning of the section.

1. The generated IPublishCallback looks like this:

   public interface IPublishCallback 
   {
       [OperationContract(IsOneWay=true)]
       void MyEventReply(string[] returnedResults);        
   }

2. The generated PublishCallBackBuilder looks like this:

   public class PublishCallbackBiulder 
   { 
       public static IPublishCallback publishCallback;
          
       public static void BuildCallback() 
       {
           publishCallback = OperationContext.Current.GetCallbackChannel();
       }
   }

3. The generated proxy looks like this:

   [System.ServiceModel.ServiceContract(CallbackContract=
       typeof(EDSOAFW.IPublishCallback), Name="IMyEvents_Pub")]
       public interface IMyEvents_Pub_Wrap : EDSOA.IMyEvents_Pub {}

4. The generated ReturnedResultsConverter looks like this:

   public class ReturnedResultsConverter 
   {
       public static string[] MyEventReplyResultsConverter(
           object[] returnedResults) 
       {
           string[] returnArray = new string[returnedResults.Length];
           for (int i = 0; (i < returnedResults.Length); i = (i + 1))
           {
               returnArray[i] = (String)returnedResults[i];
           }
           return returnArray;
       }
   }

Of course, we can do this manually, but imagine that you have several decades of different events. You will have to continuously retype this code for each one. The framework will not allow you to die from boredom during tedious coding.

And the last accord: I want to demonstrate all this stuff with the help of a simple chat sample.

Chat Sample Introduction

First of all, let's define basic terms. This will guarantee that we are speaking the same language. The following terms will be widely used in the future, so please glance at the list to check whether you have the same meaning in your head.

Publisher/Subscriber Service is an intermediate remote peer, handling the list of publishers and subscribers. It conveys messages from a publisher to subscribers. This service is also responsible for message routing, batching and queuing. If we are talking in terms of client-server architecture, this is our server.

Publisher is the remote side initializing message sending. In a simple word, this is a client side that is able to send messages to the server.

Subscriber is the remote side waiting for a message. This is a client side that is able to receive messages.

Publisher/Subscriber Client is an application combining publisher and subscriber functionality.

Event is the process satisfying the following statements:

1. A publisher sends the same message to several subscribers.
2. All subscribers are called concurrently. This means that if the connection to a specific subscriber is slow (or is broken), sending to the rest of the clients will not be delayed until the problem subscriber answers.

Our sample implements simple chat. Thus, from the business point of view, we have a little bit different terminology. We have ChatRoom, which is nothing but Publisher/Subscriber service. We also have ChatClient, which is a client application that is able act as publisher and subscriber simultaneously.

There is a thing I want to mention before we go further. In my writing, I rely on the fact that you are familiar with basic WCF concepts. If you are not, of course you can continue with EdCF, but I would recommend finding some information about WCF basics. You can start with MSDN.

OK, we have agreed about the basic terms. Now we have a number of steps needed to build a chat sample. I put the description corresponding to each step in a separate HOWTO.

HOWTO: Create and Configure a Publisher/Subscriber Service (ChatRoom)

Currently, the sample has the only event: OnMessageSent. If you want to have additional events, you should just add corresponding methods to the IMyEvents_Pub and IMyEvents_Sub interfaces. Let's imagine you want to add a new event called MyNewEvent. The only changes you should do are just modifying the service contract interface for publishing...

[erviceContract]
public interface IMyEvents_Pub
{
    [OperationContract(IsOneWay = true)]
    [EventDrivenOperationContract(IsWithReply = true)]
    void OnMessageSent(string message);

    [OperationContract(IsOneWay = true)]
    void MyNewEvent();
}

...and the corresponding service contract for subscribing:

[erviceContract]
public interface IMyEvents_Sub
{
    [OperationContract(IsOneWay = false)]
    string OnMessageSent(string message);

    [OperationContract(IsOneWay = true)]
    void MyNewEvent();
}

The last thing you need to do is to change the BaseAddress value in the App.config file to the appropriate IP address.

<service name="ChatRoom.MySubscriptionService" 
    behaviorConfiguration="ForDebuggingBehavior">
<host>
    <baseAddresses>
        <add baseAddress="http://localhost:8000/MySubscriptionService"/>
    </baseAddresses>
</host>
…
<service name="ChatRoom.MyPublishService_Wrapper" 
    behaviorConfiguration="ForDebuggingBehavior">
<host>
    <baseAddresses>
        <add baseAddress="http://localhost:8000/MyPublishService"/>
    </baseAddresses>
</host>

HOHOWTO: Create a Proxy for Publishing/Subscribing

Well, we have configured and hosted WCF Service. Now we want to have a Proxy that allows our clients to connect to the service. As MSDN says, you have three options:

1. Retrieve the WSDL from the service and handcraft the proxy.
2. Use the Add Service Reference feature of Visual Studio 2005.
3. Use the SvcUtil.exe tool to generate proxy classes.

However, I would advise selecting another one. The ChatSample solution has already created proxies for publishing and subscribing. If you want to add a new event in your solution, just use these proxies with a small amount of modification. For example, say you want to add a new MyNewEvent.

ChatClient >> clientForSubscription.cs

public interface IMySubscriptionServiceCallback
{
    [System.ServiceModel.OperationContractAttribute(
        Action="http://tempuri.org/IMySubscriptionService/OnMessageSent", 
        ReplyAction=
        "http://tempuri.org/IMySubscriptionService/OnMessageSentResponse")]
        string OnMessageSent(string message);

    [System.ServiceModel.OperationContractAttribute(
        Action="http://tempuri.org/IMySubscriptionService/MyNewEvent",
        ReplyAction=
        "http://tempuri.org/IMySubscriptionService/MyNewEventResponse")]
    void MyNewEvent();
}

ChatClient >> clientForPublishing.cs

public interface IMyEvents_Pub
{    
    [System.ServiceModel.OperationContractAttribute(IsOneWay=true,
        Action="http://tempuri.org/IMyEvents_Pub/OnMessageSent")]
    void OnMessageSent(string message);

    [System.ServiceModel.OperationContractAttribute(IsOneWay=true,
        Action="http://tempuri.org/IMyEvents_Pub/MyNewEvent")]
    void MyNewEvent();
}

HOWTO: Configure a Publisher/Subscriber Client (ChatClient)

Since you prepared a Proxy, your client is able to connect to the service. However, you need to set up transport settings and addresses of services. All configurable values are located in the App.config file. Here you are able to change a number of parameters. This number is really huge and I would advise you to refer to the official documentation if you want to fine-tune your transport. However, if you want to start immediately, you need only to set up the service's address and the client base address for callbacks.

<client>
    <endpoint address="http://localhost:8000/MySubscriptionService"
        binding="wsDualHttpBinding" bindingConfiguration="sub1Binding"
        contract="IMySubscriptionService" name="MainEndpoint" />

    <endpoint address="http://localhost:8000/MyPublishService" 
        binding="wsDualHttpBinding"
        bindingConfiguration="pub1Binding" contract="IMyEvents_Pub" /> 
</client>

<bindings>
    <wsDualHttpBinding>
        <binding name="sub1Binding" openTimeout="00:10:00" 
            receiveTimeout="00:10:00" sendTimeout="00:10:00" 
            bypassProxyOnLocal="false" 
            clientBaseAddress="http://localhost:8000/myClient1sub/"
            useDefaultWebProxy="true" />

        <binding name="pub1Binding" openTimeout="00:10:00" 
            receiveTimeout="00:10:00" sendTimeout="00:10:00" 
            bypassProxyOnLocal="false" 
            clientBaseAddress="http://localhost:8000/myClient1pub/"
            useDefaultWebProxy="true" />

    </wsDualHttpBinding>
</bindings>

HOWTO: Subscribe to an Event and Publish an Event

We are close to the end. The whole infrastructure is ready and now we have to perform four last steps. Take a look at the rest of the code we should write.

1. The first step is to create a proxy for event subscription.

   MySubscriptionServiceClient subscriptionServiceClient = 
       new MySubscriptionServiceClient(
       subInstanceContext, endpointConfigurationName);

2. The second step is to subscribe to our event.

   subscriptionServiceClient.Subscribe("MyNewEvent");

3. The third step is to create a proxy for event publishing.

   MyEvents_PubClient eventsClient = 
       new MyEvents_PubClient(pubInstanceContext);

4. The last step is to publish the event.

   eventsClient.MyNewEvent();

That's all; you now have asynchronous, reliable messaging with multicast support.

Points of Interest

In conclusion of the article, I want to ask the CodeProject community to not hesitate in writing any comments and questions. I know many things about SOA and Event-Driven Architecture, but I want to know more. I am able to share my knowledge and I believe that you also have something to share. Please leave me a message in the discussion area at the bottom of this article.

History

• 21 September, 2007 -- Original version posted

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 18 of 18 (Total in Forum: 18) (Refresh) FirstPrevNext

how to execute the code asnat 7:30 24 Apr '08   it seems to me that i need to execute the code twice. one for the chatroom and one for the client.how this can be done? thanks asnat Sign In·View Thread·PermaLink Automatic Code Generation wraith7 22:02 17 Mar '08   Hi, My name is wraith7. I use Visual Studio 2005. You said automatic code generation is very useful, but I can't find how to use it. Can you explain me how to use automatic code generation in detail? If you do so, I will really appreciate it. Sign In·View Thread·PermaLink Automatically fire events within WCF service without client interaction ying xu 13:00 17 Jan '08   Hi Sergey I enjoyed your article, I am new to WCF, I need functionality that will automatically(at each day certain time) fire events inside WCF service without client interaction,could you give me some idea on it, thanks a lot. Ying Sign In·View Thread·PermaLink 2.00/5 (2 votes) Message Pattern GChannon 2:04 10 Nov '07   Great Article! What message pattern would you recommend for a broadcast engine? Obviously users have to authenticate but a majority of message are one-way Thanks Sign In·View Thread·PermaLink svcutil GrangeJM 3:36 11 Oct '07   I try to compil the sample and use svcutil to generate the client subscription and publisher proxy. the subscription proxy is the same as clientforsubscription.cs but the publisher proxy is different. There is no callbackcontract attribute and the IMyEvents_PubCallBack is not generated. I use the command svcutil.exe /language:cs /config:app.config http://localhost:8000/MyPublishService/ Sign In·View Thread·PermaLink Re: svcutil GrangeJM 5:10 11 Oct '07   Sorry, it works fine. I remove "_Wrap" in contract="ChatRoom.IMyEvents_Pub_Wrap" Sign In·View Thread·PermaLink "Device not ready" error running the demo Kevin McFarlane 6:56 28 Sep '07   It doesn't like this line in ChatRoom.cs Main() PublishServiceHost MyPublishService = new PublishServiceHost(typeof(MyPublishService)); System.IO.IOException The device is not ready. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, St ring msgPath, Boolean bFromProxy) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int 32 bufferSize, FileOptions options) at System.IO.StreamWriter.CreateFile(String path, Boolean append) at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize) at System.IO.StreamWriter..ctor(String path, Boolean append) at EDSOAFW.PublishServiceHost.GenerateIPublishCallback(Type serviceType) at EDSOAFW.PublishServiceHost.CreateWrap(Type serviceType) at EDSOAFW.PublishServiceHost..ctor(Type serviceType, Uri[] baseAddresses) at ChatRoom.ChatRoom.Main(String[] args) in C:\Documents and Settings\kmcfarlane\My Documents\Vis ual Studio 2005\Projects\EdCF_demo\ChatRoom\ChatRoom.cs:line 71 Kevin Sign In·View Thread·PermaLink 3.00/5 (1 vote) Re: "Device not ready" error running the demo siroman 22:05 28 Sep '07   Maybe you don't have a drive "D:" in your pc? in the PublishServiceHost.GenerateIPublishCallback(type) method, in the region marked as "Printing", he opens a StreamWriter in "d:\IPublishCallback.cs". try changing it to "c:\IPublishCallback.cs". BTW he also hard-coded the path to the System.ServiceModel assembly (few lines later) so if you don't have an english OS you'll get another exception. Again I changed "c:\Program Files\" to "c:\Programmi" and everithing worked. bye sr Sign In·View Thread·PermaLink Re: "Device not ready" error running the demo BillInPA 11:01 11 Oct '07   I have a similar problem, but cannot find "IPublishCallback" anywhere in the solution. Also cant find "StreamWriter" Bill in PA/USA Sign In·View Thread·PermaLink Re: "Device not ready" error running the demo BillInPA 11:28 11 Oct '07   never mind - i found it - had to download two zips, not just one Bill in PA/USA Sign In·View Thread·PermaLink Good stuff siroman 1:03 27 Sep '07   Great article, really. It seems to me that you based your job after the Publish-subscribe service described in the Juval Lowy's book "Programming WCF Services" by O'Reilly: in appendix B he presents a Publish-Subscribe framework similar to that you are presenting here. If so, what's the difference between your and his fw? There is also a downloadable version of it downloadable here: http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=-1&tabid=19&download=225[^] tks sr Sign In·View Thread·PermaLink Re: Good stuff Sergey A. Tkachev 21:41 27 Sep '07   First of all I believe the book you have mentioned is one that every WCF programmer must have. Now back to your question; yes, you are right. Implementation of the Publish – Subscriber pattern is similar to Juval Lowy’s one. This is because his implementation is the best from I have ever seen. More over if any developer decided to implement his own solution using WCF callbacks, Generic collections and asynchronous actions it surely will come to this code also. OK, but what the difference is? The difference is in the basic idea of the frameworks. Juval Lowy’s framework is ideal for one/many-to-many distributed applications with loosely coupled remote pears. Its publisher knows nothing about subscribers. Its publisher does not care about whether the event was received my subscribers. Its publisher just raises an event and forgets about it. But what if you have a strict succession of events and lost of a single one will lead to not actual data or wrong procession on the client side. In this case you need to notify the publisher about the results of event rising, but this is impossible with the Juval’s framework. I had mentioned in the article, that I want to have universal solution for loosely and tightly coupled application. Thus I have added result collector, filtering and publisher callbacks. These additions allow solving more wide range of tasks. Of course if you do not need additional functionality you may use Juval’s solution. By the way we should not forget about automatic code generation in my framework. Believe me if you have more then 10 events this feature will save you a lot of time. TO THE COMMUNITY: Could you imagine the real word scenarios where described in the article framework will not work? Can you advise on what useful feature I may add to the framework? I believe by common efforts we will have more useful and reliable solution. Sergey Sign In·View Thread·PermaLink Copyright Question AndrewBex 13:22 4 Oct '07   Hi Sergey Thank you for publishing a good article and well illustrated concept. After reviewing the above post and looking at the O’Reilly book and the iDesign code it appear that your article and accompanying source code is based heavily on O’Reilly framework with your functionality inserted in the appropriate functions. I trust that you can assure the community that you have the rights under license to redistribute and modify this code without the original copyright header and license. As you can appreciate the community takes a dim view regarding plagiarism and copyright issues as the software industry is reliant on trust. If you can provide assurances that this article does uphold all rights held by other parties this will reinforce the credibility of your article. I appreciate your understanding and the basis of my concern. Andrew Sign In·View Thread·PermaLink 1.00/5 (1 vote) ASP.NET Dewey 20:26 26 Sep '07   Is this usable in web applications? Sign In·View Thread·PermaLink Re: ASP.NET Sergey A. Tkachev 20:38 27 Sep '07   I appreciate your interest to the article. As I underspend you are asking about possibility to make an ASP.Net application get notified about event raising. Unfortunately the version published here does not allow to do what you need. Giving that ASP.NET to WCF clients can do only http request the WCF service is not able to notify connected pears about an event raising. There is a solution to this but it is not trivial. You need to have an HTTP listener in your ASP.NET application bound to a unique address. In the first HTTP request you should provide this address to the service. Since that the service will be able to do callbacks and notifications. TO THE COMMUNITY: Are you really interested in this functionality? If yes, I can try to implement this solution and publish an article describing the approach in more details. Sergey A. Tkachev Sign In·View Thread·PermaLink Re: ASP.NET Dewey 16:38 4 Oct '07   In two words, VERY INTERESTED. Doesn't WCF spport duplex messaging? If so, wouldn't this work for ASP.NET? Probably the only compromise would be possibly opening another port on the server, but I'm not sure. Sign In·View Thread·PermaLink Great Article AndreiPapay 5:15 26 Sep '07   Youve saved me a heap of headache and work .. This is a really neat design and very flexible Sign In·View Thread·PermaLink Great Article AndreiPapay 5:15 26 Sep '07   Youve saved me a heap of headache and work .. This is a really neat design adn very flexible Sign In·View Thread·PermaLink 1.33/5 (2 votes)

Last Visit: Tuesday, December 2, 2008 2:45 AM     Last Update:Tuesday, December 2, 2008 2:45 AM