CCOW Implementation in a web browser

Posted by Martin P in Development, IHE      2 comments

May
2

I’ve written before that I’m a fan of CCOW (given that it’s probably a little bloated for what it does). It still dismays me that so few vendors support it – obviously not enough buyers ask for it and I don’t know why. But there is an issue with the implementation of CCOW in applications written to run in web browsers – which an increasing number are, and it won’t be long before the majority of clinical application do so.

There are two defined interfaces to CCOW – ActiveX and Web (meaning http, but I’ll ignore the distinction just this once). I’ll immediately discount ActiveX from this discussion, since it is limited to IE and I believe browser-based software should be browser independent (in as much as possible/reasonable). Others may have a different position (and do!) but there you go. That’s me.

The CCOW web interface involves the following (massively simplified, of course) :
1. Application registers with a context broker to enter a given context.
2. Application listens on a port for http messages indicating a change in status within that context
3. http message arrives, application processes accordingly.

So where does the issue lay? There are no standards based mechanisms for browsers to listen on a socket, even though there are a small handful of mechanisms for effecting some kind of ‘push communication’ from the server (but only by using browser features in ways that they weren’t really designed to be, and then, browser independence is largely compromised again. There are good reasons – certainly with respect to security – why browsers are thus shackled. But in this case, there is also a good reason to unshackle.

There are ways around the shackle. However, the work-arounds inevitably include one of the following downsides:

1. Breaks cross-browser compatibility. As an example, trusted XUL can be used in Mozilla browsers (Firefox), but of course will not work in any of the other browsers. ActiveX suffers the same limitation.

2. Requires 3-party plug-in. The most obvious example of this is Java. It is possible to write an applet that will present this functionality but there are downsides – there is additional overhead when loading the application and some sites object to Java for security reasons. The first of these is a real concern for a feature that may be a tiny element in an overall application. The second I wouldn’t worry about so much. If multiple clinical applications are being run concurrently, then it is invariably in the context of a LAN. On a LAN, there are many way of mitigating the risk presented by Java, and an IT department that cannot balance that risk against one of clinical error due to patient misidentification should park it where the sun doesn’t shine (which, BTW, includes Ireland so far this year . Java suffers another limitation in its ability (or lack of) to handle a tabbed browsing experience (or even multiple windows, for that matter). Yes, it is possible to build in ‘thread safety’ in the code itself but that is introducing unnecessary complications. KISS.

3. Resort to polling. In principle, it would be possible for a browser-app to asynchronously poll for a status update from a proxy server that does the ‘listening’ on behalf of the app, but this is a little clunky and involves some latency – lets say 2s from the time context changes to time the app knows about it. That may not seem much, except the way CCOW works behind the scenes means that 2s is a big deal. When another application attempts to change context, it doesn’t simply communicate the change to other apps in the context group – it asks permission. Effectively, the in-focus app asks all other apps “are you in an appropriate state for me to change context?”. Clearly, if it is 2 seconds or more before that question is even answered, then the simplest context changes are going to become extremely annoying.

So there are options (and indeed combinations of options), some more elegant and less compromising than others but my experience has taught me to pursue the elegant, and when one tires of the pursuit, code in some polling.

What exactly is wrong with polling, aside from being ‘inelegant’? Primarily, the latency. But can this polling be arranged to minimise this? Lets say the polling interval is set to 500ms and XHR used in asynchronous mode so the UI isn’t locked. Resources at the server side can be entirely memory based, as the information being polled is fundamentally transient, so it would be fairly simple to optimise performance and make the polling process fairly slick. But how does that scale? Take my ‘day job’ hospital and crunch some back-of-the-envelope numbers. Lets say we have around 500 workstations doing patient-related stuff. Obviously, not all are in use concurrently so lets say 200 are concurrent. The point of CCOW is to communicate between apps so lets assume each has 2 apps wishing to engage in a context. Thats 800 hits/second. Not impossible, particularly since we’ve optimised (crudely) the data model, but would need some seriously beefy hardware and possibly load balancing (which substantially complicates the context management). So aside from the inelegance, we have a delicate balance between latency and scalability.

But lets step back for a second. As with many problems, others have had come across it before. The concept of having a server asynchronously signal an event back to a browser has been mooted before and there are a number of instances (e.g. web-chat sites) which get around the problem. The concept has even been given a name – Comet, which is a catch-all term for the collection of technologies which offer ways around the limitation. The term was originally coined by Alex Russell of the Dojo javascript toolkit team, who has also started a process of defining a standard for possible submission to the IETF. In the meantime, there are both commercial and open source implementations of Comet, summarised nicely here, and discussed roundly (as one would expect) at AJAXian. Of the Open Source options, Meteor stands out as most complete (never mind currently active).

But that isn’t enough to comprise a complete CCOW endpoint. CCOW expects there to be an HTTP listener at the endpoint – not a simple datasink (which is largely what Comet represents). As it turns out, there is an implementation of an http server (actually, full servlet container) that runs in the context of the browser but requires Java and is too resource-hungry for this one tiny element of a browser application.  There is of course an element of balance between server-side and client-side resource requirements.  In the context of Jetty, a back-of-the-envelope calculation of resource requirements (albeit just for the thread stacks – not considering application resources) would indicate that close to 1GB memory would be required just to maintain threads for 10,000 clients.  But put into the real-world context, a CCOW server serving 10,000 concurrent clients would be a serious piece of strategic infrastructure & provisioning several GB of RAM to do so would not be an issue.  This would then allow a more nimble approach on the browser.
So what is needed alongside the CCOW broker, is a server-based CCOW proxy, to relay context messages between the http that the CCOW broker expects, and the Comet mechanisms picked up by the browser. Meteor seems to provide that out of the box. Now all we need is the broker.