Home

When? - 25th March 2009

Where? - Arizona Biltmore Resort and Spa, Phoenix, Arizona

George James Software and M/Gateway Developments will host the next in their popular and unique series of Out of the Slipstream conferences. Speakers will be drawn from various international businesses to give their slant on 'the cloud'.

Not only will you be enthralled by thought-provoking presentations, but we are planning some good old British fun for the evening. Watch this space for news and details of how to secure your place.

Well, after all that talk about Mumps as an Internet-scale hierarchical, schemaless database, we decided to do something about it:

We are pleased and excited to announce M/DB, our new API-compatible alternative to Amazon's SimpleDB. M/DB makes use of the inherent natural hierarchical, schemaless characteristics of the Mumps database to deliver an identical experience to SimpleDB.

Actually M/DB's use of Mumps has allowed it to pull off two tricks that differentiate it from SimpleDB:

- SimpleDB limits you to just 1k per attribute which many people find to be just too limiting. M/DB increases that to 32k (and I think that, too, can be increased).

- SimpleDB treats everything as text, so if you need to hold integer or real values and make comparative queries on them, you have to do extremely tedious tricks such as packing them out with leading zeros. M/DB's underlying Mumps engine, of course, applies its dynamic data-typing, so numbers behave properly as numbers without needing any
packing whatsoever.

The initial beta release of M/DB is in the form of a VMWare Virtual Appliance, so it can be used as a standalone "black-box" database, accessed via its REST APIs. The Virtual Appliance has been built using GT.M and our latest version of the MGWSI gateway which provides direct HTTP access to the GT.M engine via Apache.

If anyone is interested in building their own M/DB system on top of an existing GT.M or Cache platform, get in touch. Yes, you saw that correctly: M/DB will also run on top of Cache.

We believe that M/DB heralds a new role for the Mumps database technology in the Internet-scale database world, particularly for cloud service providers who want to produce an alternative or back-up to SimpleDB.

For more information about M/DB, visit our web site at http://www.mgateway.com

By the way, we're looking for others to consider adding value-added services to M/DB through simple, abstracted REST APIs. Backup and other such administrative tasks is one area that comes to mind. Get in touch if you have any thoughts and ideas.

I stumbled across a very nice web-based IRC client today so I thought I'd add it to the site. Click here or click on Chat at the top right of this page to access it.

It'll take you into two IRC chat rooms. One for slipstream and one for gtm. If you want to get something off your chest then try out one of these. This is very much an experiment and I'll be interested to see how each channel gets used.

I've been doing quite a bit more thinking recently about the role, position and future of Mumps, particularly based on issues raised in the many blogs I've been reading. There's a lot of naive and uninformed bashing of Mumps, particularly with respect to its role and relevance in healthcare, and also in terms of its role in the modern world.

So I thought I'd pull together some thoughts and provide a fairly in-depth analysis.

Firstly, and crucially, we need to separate out the two components of Mumps: the database and the language.

The database is actually an interesting beast. It's a schema-less hierarchical database engine: characteristics which are coming back into vogue, as witnessed by the likes of Google's AppEngine, Amazon's simpleDB and Apache couchDB. This style of database is being driven by the demands of the so-called Internet-scale database. See:

http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=576aecc0-607b-4f42-9cf5-fda2b42a74fa

and, for our analysis with respect to the Mumps *database*, see:

http://www.slideshare.net/george.james/mumps-the-internet-scale-database-presentation

With GT.M providing a free open-source implementation of the Mumps database engine (http://www.fis-gtm.com), I believe that there's great merit in the kind of modern developers who are being attracted by this style of database taking a look at just what the Mumps database engine is capable of. For some background on the Mumps database and how you can use it, see our paper at:

http://gradvs1.mgateway.com/download/extreme1.pdf

In the "olden days", a lot of the bad press encountered by Mumps was due to its closed nature, its lack of a schema and the associated inability to apply SQL to search the database. Now let's be clear about two things:

1) this was originally due to restrictions in the Mumps *language* which used to be the only way in which you could interact with a Mumps *database*.

2) these days the Mumps database is much more readily accessible, eg:

- InterSystems have added object/relational projections, allowing the core Mumps database to be queried by their embedded SQL and also (and crucially), allowed their objects to be accessible natively from within the more modern mainstream languages such as C++, .Net and Java. Additionally, their web gateways (the result of pioneering work by our company) allow both the Cache object/relational projections *and* any legacy Mumps database records to be accessible via a browser interface, allowing much of the client-side scripting to be written using Javascript.

- our own company's gateway technology (MGWSI) further allows the Mumps database in both Cache and, perhaps more interestingly, GT.M to be fully accessible and integrated with any modern mainstream scripting language: eg Java, .Net, C++, PHP, and, in our next forthcoming release, Ruby, Python, and Perl.

So, in fact, the reality is that there is no reason why the very interesting features and capabilities of the Mumps database can't now be explored and experienced by a modern generation of programmers using their favourite pet language.

It is absolutely true that the Mumps *language* can appear very cryptic and arcane to an outsider, and unfortunately it's a language in which it very easy to write unmaintanable code - another of the themes that has come up in this debate. With the move away from the old "green screen" days to client/server and, more latterly. web/ajax applications, there's actually very little need to write much in the way of Mumps code any more - most of the scripting is done in other languages. Most of my work, for example, is now in the Javascript domain. So the statement "it’s widely-regarded outside of healthcare IT that MUMPS is relatively unmaintainable compared to modern languages/platforms" is true only if you're talking about applications written entirely using the Mumps *language*. Modern healthcare applications written using Cache or GT.M rely very little on the Mumps language.

Let's move to a second issue:

Something that comes up time and time again in these debates is the suggestion that it's about time that Healthcare abandoned the old fashioned Mumps technology and that something more modern and maintainable was used for applications in healthcare. I wish people who harp on about this would actually examine and ponder the track record of previous attempts to migrate from Mumps to something more modern and mainstream. The fact is that in over 25 years of watching these attempts, I'm not aware of a single one that's been successful, despite the best endeavours of some of the biggest names in IT armed with, in some cases, astronomically large sacks of cash. You need only look at the embarrassingly snail-like rate of progress within the UK's NHS IT Strategy where they're all still waiting for the much vaunted replacements products. They're years behind schedule and there's a trail of some very large companies who have become casualties in this multi-billion pound exercise. eg see:

http://www.computerweekly.com/Articles/2008/01/22/229021/fujitsu-may-quit-nhs-national-programme-for-it.htm

http://www.guardian.co.uk/society/2008/aug/10/nhs.computersystem

Now discussion of this issue normally descends into another futile debate about whether or not there must be something inherently different about the data within healthcare that makes the Mumps database suitable and the RDBMS unsuitable. My opinion is that this is far too naive an argument. I believe there's a lot more to it than this, but I'd summarise the situation by saying that the demands within the healthcare environment have an interesting similarity to those being experienced in the Internet-scale arena. For example:

- healthcare IT projects have a terrible habit of suffering from scope drift, often due to changing statutory requirements for data collection as political strategies related to healthcare come and go during the development of the applications. Suddenly that originally nice and tidy database schema needs a bunch of other stuff added to it. This is certainly an area where the schemaless databases come into their own and one of the features that Amazon promote for simpleDB (see the paragraph titled "Flexible" in http://www.amazon.com/gp/browse.html?node=342335011). Conversely it can play hell with an RDBMS implementation.

- cost-effective scalability: Healthcare systems for an entire metropolitan area have to be extremely large, with high peak loads and the need for high performance by busy healthcare professionals. Whilst it's possible for the mainstream RDBMS's to be scaled up to vast sizes and deliver high performance, it requires a *lot* of hardware, expensive licenses and DBAs. In many cases it's just not a cost-effective solution for the highly budget-conscious healthcare community.

- rapid development: Healthcare systems are far from simple in scope. They include a lot of functionality, and if systems are to be delivered speedily to the healthcare community, that requires extremely rapid development. I have to say, based on experience of working on all kinds of languages and platforms, the mainstream view of what constitutes rapid development is a long way removed from what I've seen possible in Mumps and Cache. I think that forms part of the great frustration of Mumps devotees: they see great claims being made about the latest and greatest new technologies in terms of their abilities for rapid application development, but they seem like a sad joke compared with what they know they've been able to achieve with their old Mumps stuff. Why this should be so is beyond the scope of this discussion, but something worthy of further analysis elsewhere. Anyway the result is that even the fastest mainstream rapid development techniques prove inadequate, so development just ends up taking too long.

So, the net result is that it's clearly not as simple as the many IT consultants, advisors and pundits would have us believe. It's not as simple as just getting rid of that old Mumps stuff and rewriting those applications in something more modern and maintainable. If it was that simple, that old Mumps stuff would have been long gone, but it's still there, and there in droves. In my opinion a lot more people should be analysing in more depth just why such an apparently anomalous situation should exist, and comparison with the Internet-scale database requirements goes some way to explaining it.

The third issue that I've seen discussed relates to the lack of a thriving community ("the weak MUMPS ecosystem"). This is an interesting one. I totally agree that one of the great problems is the dearth of people creating value-added features and libraries of modules and until recently I was of the belief that it was a terminal problem, but now I'm not so sure. I think it is partly a historical/timing issue. The great emergence of massive thriving communities has really been a result of the Internet, and therefore a phenomenon of the last 10 years. That coincides with exactly the time when all but one of the original Mumps implementations was bought out by InterSystems and buried into their proprietary Cache product. I think it's fair to say that InterSystems are a company that likes to tightly control and determine the use of their product, and I think as a result, there's been little incentive for third parties to create a wealth of add-odd products. It's also greatly limited because Cache is not a free, open-source product.

Now the interesting factor is GT.M. It was a somewhat unusual implementation of Mumps and never had a particularly big following. So when InterSystems snapped up the other vendors, it acquired most of the then Mumps developer community as users. most of whom would have found the GT.M implementation just too different for their liking and comfort.

Since then, a couple of things have happened. GT.M has been released as free open-source, around about the very time when the demands of Internet-scale databases are causing people to look beyond the relational model. And of course we have the Internet which can, as we've seen with Ruby, allow an explosive growth in a hitherto little-known technology.

Contrary to the views that I see expressed about the future for Mumps, I therefore believe that conditions are now pretty much right for a new-found interest in it. Not, I suspect, in the Mumps language, but I believe there's a great opportunity for a new community to emerge, discovering the potential of the Mumps database, and adding value, features and libraries to the free, open-source GT.M Mumps database engine to fill in its deficiencies etc. Our company has already provided the gateways that open it out to the mainstream languages, and I would love to see new people discovering the potential of the Mumps database as a persistence layer for their particular language.

Will this happen? Let's wait and see. I would love to see it happen and there's great treasures for new people to discover. The kind of things I can do with ease, speed and simplicity in Mumps would be a real eye-opener to a great many of the new kids out there.