This project is read-only.

SSB with Silverlight Client

May 19, 2009 at 12:38 AM

I am designing the architecture for the rewrite of an existing system.  I have been following Udi's blog for sometime and just recently found this project.  I plan on utilizing an ESB in the architecture and also want to have Comman/Query Separation as described by Udi.  However, my plan is to utilize Silverlight for the client UI which raises a couple of questions.

First, it seems that I should be able to use SSB with Data Contract Serialization and have the Silverlight client use WCF and share the same service layer code regardless of whether the service layer operation was initiated through an SSB message or a Silverlight client call.  Would you agree with this?

Second, I would like to be able to somehow have Silverlight clients subscribe to certain messages.  This is of course an issue since Silverlight does not have support for MSMQ; though it does support sockets.  I haven't looked very deep into the code yet, but would it be possible to support a socket transport within SSB for this purpose?  I'd probably have to give up the "durable" aspect provided through MSMQ, but then I don't really care about that part when sending messages to a UI client.  There are other ways to handle this issue without trying to shoehorn it into SSB, so perhaps this is not the right approach to the problem.

May 19, 2009 at 1:33 AM

Yes, I would agree with your first question. If your service layer were aware of the bus it could mediate between WCF and the SSB messaging interfaces, and use shared messages courtesy of the DataContractSerializer.

Depending on your application, I think a great way to do real time, asynchronous messaging from within Silverlight would be to write a transport on top of XMPP. The caveat is that you'd probably need to host an XMPP server, but there are lots of open source options for XMPP servers as well as commercial, and there is at least one and probably more XMPP clients for Silvelight out there. I don't think an XMPP transport would be hard to write, and it would have nearly universal reach, as XMPP libraries exist for virtually every significant platform. Other commercial alternatives would be to use Amazon SQS, or Online MQ. Additionally Linxter is coming out with Silverlight and REST API's, but I'm not aware of the time frame. Active-MQ is also an option, as I believe Active-MQ supports RESTful access to queues. It would also be pretty easy to write your WCF Polling based queuing mechanism, RESTful or otherwise, using a transactional database and WCF that your silverlight clients could use to communicate on the bus.

Writing your own socket-based implementation via a custom transport is certainly achievable, but it doesn't sound like much fun.

Also, WCF supports a duplex binding, which is a two way connection. You could write a Transport on top of WCF that maintained a duplex connection to each client, but I think you would run into scalability issues after x number of clients, and given that you're writing your UI in silverlight, I am guessing there are going to be more than a few dozen clients to support.

I don't really know how to answer your questions, except to say that if you do settle on an asychronous, pub/sub architecture, there is no reason you couldn't create a transport in SSB to support it. You might also consider posting your question (architecturally speaking, of course, not as it relates to SSB) to the NServiceBus group over at Yahoo Groups. There seems to be quite a few good minds in that group.


May 20, 2009 at 12:08 AM

I really appreciate you taking the time to reply.  Using XMPP is not something I had considered, but I will need to do some research since I'm not really familiar with it.  I was aware of WCF duplex binding and haven't ruled it out, but had mentioned sockets because (as ugly as it may be), I've been working with them for years (plus I'll probably end up with socket based interfaces to external systems).  I'll try posting on the NServiceBus group.


May 20, 2009 at 12:27 AM

If you have to write a socket interface to other systems anyway, then re-using that effort from silverlight makes a lot more sense. If you remember, please let me know the solution you end up with. I think this is kind of an unsolved problem, at least in the .NET space. Azure is supposed to deal with it, but when that technology will be commercially available, what its barriers to entry will be from a licensing perspective, and how complex it will make your solution are still pretty much unknowns as far as I know.

Ideally, you should be able to connect virtually any running process, Silverlight, JavaScript, mobile anything, whatever, to your central messaging system without having to drag your development team across a cheese grater to make it happen. Probably some of the big ESB/MOM vendors provide such components, but for the rest of us I think all those balls are still in largely in the air while the messaging paradigm continues to sink in and the RPC paradigm continues to fade out.

Anyway, I hope you find an elegant solution.

Apr 19, 2010 at 11:32 PM

I guess this situation has not improved in the meantime..?

So far this is the best information on the subject I could google up...