I was talking to Jesper a couple of days ago, and he suggested that I should write a little background information for some of the Internet resources in my previous post. Even though I consider the resources quite useful as they are, I agree that a little context information would be good for better understanding the value of the link and also for discussional purposes. So please, if you have any input, throw me a comment, ok? :)

In this posting I will elaborate a little on the SOA: The Subscriber-Publisher Model, Introduction and Implementation resource.

First a little background info on the HTS solution, the new announcement system at Banedanmark (who owns the Danish railway infrastructure).

The HTS solution consists of 3 tiers*: the HTS smart client tier (Windows Forms .Net, this is the end user interface), the HTS (high level business logic of the HTS system exposed in an asp.net web service), the HTS Core server (low level logic, that delivers the announcement to the speaker hardware, contained in a windows service, exposed in an asp.net web service via remoting).

Now, the end users works in the HTS smart client in so called workspaces. Each workspace contains a pre defined amount of announcement resources that the user can create new announcements to. The workspace also contains two lists, one for showing scheduled announcements the next 24 hours on the resources, and a list showing processed announcements 25 hours back in time.

Now, as users can work in the same workspace on seperate computers at the same time, and because the HTS server and Core server continuously processes the scheduled announcements, the lists in the workspaces must to be updated to show the state of the system correctly. There are basically two ways to do this, pull or push. Pulling in this context means that the HTS client initiates the update of the lists at certain time intervals and polls for content from the HTS server. Push in this context would be an update of the lists initiated by the HTS server. 

Pull is easier to implement compared to push in this context, and pull was the chosen strategy for the HTS solution. However, ease does not come without a price. There's no doubt that the pull strategy is by no means as scalable as the push strategy. The pull strategy generates a lot of traffic and load to the server, even though no change may have happened on the server and the server therefore has nothing new to show to the user. However, the amount of users was known at design time, and therefore we could calculate on the server load.

However, in a different scenario with a lot more users (or workspaces), a push strategy should be considered. The server could serve many more users and still easily compete with the pull strategy in terms of traffic and load, since there's no or little communication between clients and server when there's no change to show. Only when a change happens are the subscribing clients (or maybe even just a subset of them, depending on how complex your implementation is) notified with new data.

Now, there's many differenct ways of implementing the push strategy, and the link above is one way to do it (however, the solution described was not used for Banedanmark HTS). I have also seen articles and discussions on how to do it with either .Net remoting and MSMQ. In a discussion about a .Net remoting implemention, someone cautioned of two things: Alleged instability of .Net remoting (that is, there's a relatively large chance that the message never reaches the client) and that the notification is synchronous (which can mean that a stalling client can kill the notification round or at least cause a serious delay). On the other hand MSMQ can be used to make an asynchronous notification, where the server puts the message into a MSMQ queue on the client. The client then polls the local MSMQ queue for changes. This is good because the server can deliver to one client and directly continue to the next, no matter if the first client was ready or even responsive. However, when doing this with MSMQ, remember a good rule of thumb: Deliver remote, poll local.

Anyways, even though the above just scratches the surface of how to implement push, it should be clear that push is a little more complex and demands more effort than pull. The advantages should be clear, though...

(As a side note for anyone at Banedanmark, who might be reading this: The communication part in the HTS client is properly wrapped, and is internaly based on events. So, the transition from pull to push, from HTS client perspective, should be a minor change, should you consider changing it. Impact on the HTS server however depends on the chosen technology.)

That's it for now. I hope this background info on the link gave a little insight. Please do leave a comment on subject, content or form... :)

Christer

A lot of coffee was consumed during Banedanmark HTS :)

* I'm leaving out the speaker hardware tier and data persistance tier here for simplicity.