Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Not that am pushing Flex in fan boy fashion, but matter of factly this is the kind of architecture we build into all our Flex-based applications routinely. Here is what we do on Flex - no doubt it could be suitably translated to Silverlight:</p> <p>We take three ingredients and integrate them together to accomplish this capability:</p> <ol> <li>Comet pattern (an HTTP compatible way to do server push notifications - look on Wikipedia for more info)</li> <li>JMS messaging topics (publish/subscriber queues)</li> <li>The Adobe BlazeDS servlet</li> </ol> <p>The latter item implements the Comet pattern, supports AMF object marshaling (Adobe's binary serialization format for ActionScript3 objects), and bridges to a JMS queue or topic. When bridging to a topic, then multiple Flex clients running in a browser can be proxied in as subscribers to a JMS topic. So if any client publishes a message (or the server-side code publishes into the topic), all client subscribers will have the message pushed to them via BlazeDS and the Comet Pattern implementation.</p> <p>Effectively you need to locate or write a component that accomplishes what BlazeDS does. You might also need to implement some client code that interacts with the Comet pattern of this server-side component.</p> <p>Does WCF support the Comet Pattern and bi-directional messaging? Especially where complies to HTTP and port 80 or port 443 for SSL. Looks like you've already looked into that and not found anything for bi-directional messaging. So you may need to roll your sleeves up and do some coding.</p> <p>Some things to note about doing server push to a web app:</p> <p>BlazeDS supports two primary modes of implementing the Comet pattern (there's actually a 3rd polling option but am ignoring it):</p> <ol> <li>long-polling</li> <li>HTTP streaming</li> </ol> <p>The long-polling one you should find to be more universally supportable to most web browsers. So you might streamline to just supporting that initially. Or you could spend the time to make your client code try HTTP streaming first and switch to long-polling if necessary.</p> <p>As to a message broker that can provide publish/suscribe capatibility, you might consider using ActiveMQ JMS. It is open source and free with active community support (you can buy support too). Plus you can use NMS to integrate as a .NET client.</p> <p>Having a message broker sitting in the middle-tier is actually important because it will be a place for messages to be placed safely. If your clients are doing long-polling, you wouldn't want them to miss any new message during an interval when they're not actually connected.</p> <p>Another thing to consider in high traffic volume scenarios (hundreds or thousands of clients, such as a web site on the Internet), you need to have an approach to the Comet Pattern that is scalable.</p> <p>In the Flex/Java world, the BlazeDS servlet (which is open source) has been modified to work with asynchronous model. In Java a socket listener can be built to use NIO channels and Java Concurrency Executor thread pools. The Tomcat web server has a NIO listener and support for asynchronous Servlet 3.0 events. BlazeDS in particular has been modified, though, to work with the Jetty web server. The bottom line is that the scalability of this asynchronous approach means a single physical web server can be enhanced to support up to around 20,000 concurrent Comet-style client connections.</p> <p>It's been a while since I've done serious .NET programming but used to the io capabilities were much like Java 1.1 except with an asynchronous result handler capability. This, though, is not the same thing as creating asynchronous socket listeners via Java NIO channels. A NIO channel implementation can support hundreds to thousands of socket connections with a relatively small thread pool. But C# and .NET has gone through two or three significant revs - perhaps there have been new io capabilities added that are comparable to NIO channels.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload