The architecture of all these gateways is conceptually similar and quite simple to understand, but has a specific characteristic that is important to understand: it provides a stateless environment though which the Mumps/Cache programming environment is accessed.
Whilst lots of people I meet and talk to nod their heads knowledgeably when I say this, I’ve recently realised that very few people actually know what this really means, far less its consequences, benefits and challenges when it comes to building applications.
In fact I’ve recently started asking audiences during my presentations: “hand up those of you who actually know how web applications actually work”. Nobody has ever raised their hands.
This is a pretty interesting and scary thing to discover, not least since web development using Mumps and Cache has been possible since 1994, and also since these same people have often been messing about attempting to build web front-ends to Mumps and Cache applications using all manner of “mainstream” web development technologies and frameworks.
Worse still, there are lots of “experts” who have been providing expensive consultancy advice to organisations who use legacy Cache or Mumps applications on how they can be modernised using web technologies. Those experts consistently (and wrongly) assume that “mainstream” web technologies and frameworks are required and must be grafted on, apparently ignorant of or dismissive of the native web capabilities that Chris’s gateways have made possible for many years.
I’ve also realised that there is a huge gulf in knowledge about the true capabilities of Mumps as a technology. Whilst I’m not of the “let’s do everything in Mumps” school of thinking, I am also strongly of the “let’s keep everything as simple as possible with as few moving parts as possible” school of thinking. Less is more. Simple is cheaper and easier to maintain, and there’s less to go wrong. I liken it to a helicopter versus a fixed wing aircraft: which would you feel safer flying in?
Contrary to “expert” opinion, when it comes to web enablement of legacy Mumps applications (or shiny new Cache applications for that matter), there is no need to reach for frameworks from the .Net, C#, Java, Python, Ruby or PHP worlds. Everything those frameworks are designed to do can be achieved just as effectively (and usually more so) using the native capabilities of Mumps in combination with Chris’s gateways.
Going back to that stateless behaviour of the gateways (WebLink, CSP and m_apache): this is important because it’s what leads to a level of performance and scalability that is far beyond what you’ll otherwise achieve by grafting on other technologies. It’s often forgotten (or simply not realised) by those folks who graft on web technologies to Mumps and Cache systems that one of its most powerful features has been the sheer raw performance and scalability of its database and integrated language. Our philosophy at M/Gateway Developments has been as follows: let’s exploit those inherent capabilities to create one of the more performant and scalable web architectures possible.
So, personally it grieves me when I see people who should should know better wasting so much of their time trying to figure out how to integrate some new “flavour of the month” web framework with Mumps or Cache systems, needlessly reinventing wheels as they go along. It disappoints me when I discover how few people who use Cache or Mumps systems actually know what’s possible when it comes to the native web capabilities of those systems, despite the native solutions having been around for so long.
There’s a huge amount of ignorance about Mumps and Cache as database technologies, and a huge amount of ignorance and uninformed nonsense surrounding the Mumps language.
Used properly, a Mumps or Cache system is up there with the very best of the NoSQL database-backed web environments: I would actually go so far as to say that its the very best web technology you can use today.
Part of the reason why lots of people believe you have to turn to those “mainstream” web technologies and frameworks is because they’ve been convinced by the IT industry that they are needed. Indeed I’d go as far as to suggest that the IT industry has gone out of its way to instill the belief that web applications represent a complex programming challenge that can only be tamed by the use of equally complex technical frameworks and the introduction of layers of weird and wonderful concepts and buzzwords. The reality is that this is almost completely self-fulfilling nonsense: the web, as a technology, is inherently beautifully simple, and the development of web applications should be equally simple. Indeed my interest and ongoing fascination with web technologies stems from that inherent simplicity. I also challenge the notion that web application development is first and formost a programming issue. My experience is that the programming can and should be reduced to pretty trivial proportions, and that web applications are first and formost a design issue. How it all became deemed to be so damned technically complex is one of my great disappointments over the last 15+ years.
So, one of the things I’ve been determined to do is to debunk that complexity, and EWD is the product I’ve built to demonstrate that all that complexity is fabricated nonsense.
Anyway, I’ve decided that the time has come to try to change all this cluelessness: hence this blog. I’m going to try to explain what’s actually possible, and how little technology you actually need in order to do all the new and modern, cool web-based things that people expect in 2012: it’s all using technology that has been under the noses of people for many years….since 1996 in fact!
So, my aim over coming weeks and months is to explain in more detail what I’m alluding to and why it’s so beneficial to forget all that “mainstream” stuff and use what’s natively available in Mumps and Cache systems.
In doing so, I will also explain why our EWD framework for Mumps and Cache has been developed, why it does what it does, and why it’s been designed the way it’s been designed. In particular I’ll explain its key role of creating the important task of creating the illusion of a state-ful run-time environment on top of the stateless environment created by those gateways that Chris was responsible for designing.
Time, then, to remove that cluelessness out there!