Event processing and domain specific languages

I wrote recently about the move towards the definition of a meta-language for event processing so that the meta-language could be standardised and then mapped to the specific language being used by the vendor. This put me in mind of two things: first, my recent discussions here on the impossibility of 5GLs and, secondly, on a recent briefing I had from Metacase about its MetaEdit+ product.

MetaEdit+ provides, in a sense, a meta-language although most people would think of it as a modelling tool.

There are two phases in working with MetaEdit+. In the first phase you define a modelling environment (a combination of modelling constructs and language) that is specific to your environment and you define how that will map to whatever language you want the software to generate. The company has customers that variously generate Java, Python, Assembler and XML, for example. This, of course, involves some work on the part of the developer but MetaEdit+ provides a variety of capabilities to make this as simple as possible and it doesn’t take as long as you might think.

What you get at the end of this process is a model-driven development tool that uses your business terminology and which provides full (note, full) code generation into a language that is specific to your requirements (for example, to embed functionality into a microcontroller you might use assembler, into a phone, Python, and so on). This represents the start of the second phase of the use of MetaEdit+, where you actually develop your business applications. For obvious reasons the fact that the modelling now directly reflects the nature of your business should have a significant impact on the development of applications.

However, there is a proviso: using business terminology in your development process is only useful if the people building the applications understand the business. My guess is that, although there are exceptions (Metacase has customers in the Insurance sector for example), this is the reason why the majority of the company’s customers are using the tool to develop applications for embedded devices such as micro-controllers or mobile phones. But with today’s emphasis on IT understanding the business one can easily imagine the use of MetaEdit+ helping to drive this. Alternatively, of course, it potentially opens up the possibility of business analysts developing applications directly, once the initial definition process has been completed.

Anyway, to return to the beginning, if and when a meta-language is defined for event processing, it becomes obvious that a tool like MetaEdit+ (actually, I don’t think there are any other tools like MetaEdit+, but tell me if you know different) could have a ready market in mapping the meta-language to whatever is required by the different event processing vendors.