Some design questions

Sep 2, 2012 at 11:52 PM

While trying to implement a Silverlight client (which afeter some struggle - I did managed to), I wondered about several design decisions made in this project, and I'll be very greatfull if you can take a short time to clear my confusion.

I admit, that probably most of them are just the result of my relatively shallow experience with the code, but perhaps some may suggest future improvements (though - I humbly take the place of just trying to understand better - not to suggest anything....), so:

  1. One of the toughest parts of implementing the SL client, and in general to understand the architecture, is the lack of sharp separation between “Client Side” components and “server side” components. Basically the client references the whole IL-Merged server. Is there a reason for that? Is there a plan to make such a separation in the future? This can make it much easier to implement new clients (btw - the Java client came here to rescue – since it’s concerned only with, well, client stuff).
  2. Talking about the IL-Merging – is there any reason why you merge everything into one assembly? It makes it quite difficult to debug, especially the server side?
  3. I think that a natural evolution of the already elegant fluent API you’ve implemented would be to use the new Task Based AsyncPattern, do you have plans to move to this style?

Probably I have much more, but these are the major ones. In any case – I enjoy your work very much, and looking forward for v-next.

Coordinator
Sep 3, 2012 at 12:27 AM
Good job on getting the Silverlight client, I actually started working on the Silverlight client also which code base will be used also for the Windows Phone client. I am following similar style as the JS API which contains register, unregister, publish, subscribe(takes a callback as a parameter removing the need to worry about creating instance of subscriber), and unsubscribe. I am going to make same changes to the Java Client.

As for the use of ILMerge, I did that because the amount of assemblies required to develop an application is growing. Even though I generate a single assembly, you don't have to use it. You still have the option to use individual dll as needed. For example, you reference PServiceBus.Transports with PServiceBus.TcpTransport if you want to use TcpTransport in your client application.

The server side does not use the ILMerge dll, the ILMerged dll is only meant for the client application. All the sample codes i created used the ILMerge dll for simplicity sake.

Sorry for confusion of client and server code :). The only dll needed for Client application are:
PServiceBus.Services.Gateway (Contains the Subscriber, Topic, ESB class),
PServiceBus.Transports(This dll is also reference by the server side, because the MessageDispatcher has to call the transport class for subscribers as needed),
PServiceBus.[TCP,MSMQ,RabbitMQ.e.t.c]Transport (You include this as needed based on the transport you specify for your subscriber)

For the client API except C# Client, I would want for the other (WP7, Silverlight, Javascript, Java) is to keep a very simple api across the board. So I would want to have something like this

I currently have the below for my working implementation for Silverlight/Windows Phone in the next version

//Register topic
PSBClient.Register<MyTopic>();

//Publish message
PSBClient.Publish(new MyTopic());

//Subscribe to Topic
PSBClient.Subscribe<MyTopic>(msg => { Console.WriteLine(msg); }, interval: TimeSpan.FromMillisecond(1000), batchSize: 1);

//Unsubscribe
PSBClient.UnSubscribe<MyTopic>();

The next version(2.0.1) should be here by end of Oct which will have the new API for Windows Phone, Silverlight, Javascript, and Java.