Context Sensitive Subscription - a pattern

We have a lot of trains - over 2000. On these trains we also have a lot of personnel like drivers and conductors. A main characteristic is that the trains and the personnel move across the country and so their locations change as time progresses. Another characteristic is that the movements of the physical entities do not have a stable pattern; one day a train runs from north to south and the next day the same physical train may run from east to west. And personnel change trains every few hours and they also have days off. This means that the context is changing all the time.

Trains have standard applications for instance to collect data about delays of other trains and to provide the passengers with relevant travel information. The same applies for the PDA's of the personnel on duty. So there are thousands of instances of the same applications deployed and running. Now it's getting interesting: how do I distinguish between the different instances of the same application when it comes to communicating with these applications? Sending messages from these moving application instances in changing contexts is not a big deal, but consuming just the right messages relevant in the specific and frequently changing context is another story.

All of our new application system designs take the event-driven architecture paradigm as a base. We are very keen on that. So what we need is a way to implement context sensitive subscriptions. We keep the application-layer independent from the network-layer by using an Enterprise Service Bus between the two layers. We therefore don't allow to identify or address our applications at the IP-level, so a unique logical identifier (name) per instance is required.

We already use the context aware services of Appear Networks (see video) to be able to deploy (or eliminate) business software depending on the - predefined - context of the concerning devices (owner, time, role, location). In trains, for instance, these context aware services may take advantage of on-board GPS-equipment. A pre-installed generic client initiates this process. Based on the use of these context aware services that we already got, we developed a very simple design-pattern for context sensitive subscriptions. Here is how it works...


The idea is as follows:

1. There are a lot of instances of the same application (one on every device or train)
2. Every instance of the application has the same name (identifier) on every device or train
3. To be able to have the infrastructure route the correct messages to the correct application instances, the instances must be distinguishable
4. Use a uniquely identifiable proxy (Subscriber) in front of the application instance (id based on predefined context characteristics)
5. On change of context (published by context services) generate a new proxy based on a template - including subscription parameters and an identifier both based on the context - and replace to old proxy
6. Have the proxy subscribe itself to the relevant publications (may be content based)

So the idea is to re-subscribe. In this pattern the "context sensitive" part is not a filter but a context-unique subscriber. We want the endpoints only to receive relevant messages. This makes the solution more scalable and - compared to a filter solution - it decreases the load on the mobile network and at the endpoints tremendously.

The pattern is not only of use in wireless mobile environments, but also in plug-and-play devices like gates and information displays on our railway stations. All gates on all stations function in the same way with the same software, but they differ in location. The same applies to the information displays. To be able to receive only the messages relevant for their own specific location, the devices must be uniquely identifiable at the application-level.

It as an enormous effort to pre-configure all those devices separately for the specific location where every device is planned to be installed. It's much cheaper and much more flexible when all devices are generically configured with general software such as location detection software (e.g. context aware service) and context sensitive subscription software. The location detection software may use detection appliances like a GPS-receiver, or it may make use of a simple user-interface to get a location-code. Once the location is determined, the generic software in the device generates a context sensitive subscription. In this way it doesn't matter which device is installed at which location. And devices can be moved to other locations without reconfiguring the software.

An example of the use of this pattern is an information display at a main railway station, which can be installed on the fly and can show information of other main stations in the country by a simply entering the desired location-code.

Another example is a traveler who buys a ticket via Internet. The Internet application issues an event which is published on the ESB. The ESB supports some enrichment by adding the location-codes of the railway stations on the route. Only the gates on this route receive and store the message of this traveler and allow passage (only today and only once) when the traveler puts his id-card in the reader of the gate; without any travel-rights loaded on the id-card and without querying a central database.

At this very moment of writing we are merely discussing the abstract - implementation agnostic - pattern of context sensitive subscriptions; the idea. But we think that an implementation of this pattern will bring us a lot of flexibility and ease.

Please feel free to react.