Abstraction of concurrency from software application logic

(a.k.a: “I feel the need… the need for - Concurrency…”)

From Monolith to Component Architectures

In the olden days of computing, everything was combined into a single lump of software - including operating system functions, application logic, data, user presentation. After some time, we realized that creating a separation between the hardware and the software application would be useful, and the operating system was born. Some time later, we realized that managing the data was a distinct task, and databases became a separate entity. Some time after that, we decided that it would be a good idea to split out the user interface, and the era of client/server began.

So it went, the software industry continued to evolve our architectures into more componentized and modular arrangements.

Architecting for Concurrent Computing

Now that multi-core architectures are common and the need for concurrency in software architectures well understood, the next question is how best to architect our applications and how best to structure development organizations to support them. For the moment, let’s talk about the development organization. In the past, concurrency was a task limited to edge cases, but now ubiquitous multi-core hardware is making it much more common.

There are two ways to handle this. First, train all your software developers to be experts in concurrency (yikes…). Second, have concurrency specialists to focus on making your applications parallel. Since training all of your software developers to be experts in concurrency seems daunting, it would seem that the second option is better. But if concurrency is now required through significant portion of your application architecture, how can only a few engineers or architects be responsible for it?

The answer lies in abstracting the concurrency model from the application logic. While this may not be possible for all aspects of your concurrency model, it certainly should be for some - especially for well-defined services (in the SOA definition of the word). Services can be run in multiple instances across multiple threads and multiple cores (even multiple servers) to achieve a significant degree of concurrency without rewriting the code inside the service.

To the extent that you can do this, you can allow your application developers to focus on application logic and your concurrency experts to focus on concurrency. In addition, you can gain quite a bit more flexibility to your application architecture. The more your concurrency is abstracted, the easier it is to change without affecting the application logic. It’s really just an extension of the idea of loose coupling.

The Concurrency Model

This means that the application developer does not have to be the primary owner of the concurrency model. The application developer is able to focus on the application, and a concurrency expert can design about the concurrency model, just as a DBA does with the data model - I wouldn’t be surprised if we start to see something like a Concurrency Model Architect (CMA?).

Anyway, the whole thing relies on being able to separate your concurrency model from your application logic. More on that later.

Patrick

It was our second year participating in the OOP conference in Munich last week.  This conference focuses on aspects of modern software engineering, so as you can imagine, it is heavily infused with SOA technologies.  I gave two talks, one about modernizing C++ applications, and the other on creating a service grid.  In my talks I focused on the challenges of maintaining performance characteristics when moving from a monolithic application to an SOA, while also dealing with distributed computing issues that may not have been previously relevant.  Both drew a good number of people and several of them came by our booth later to discuss their situation and how it would fit in with what I discussed. 

I was a bit surprised that there were a good number of people that said they have problems dealing with large XML files.  We call this VLM (Very Large Messaging) and we are very familiar with the issues surrounding it.  The most common issue has to do with memory consumption.  Typical DOM based parsers use about 6 times the size of the original XML file in memory.  When you start dealing with large files, that quickly becomes a problem.  The other main issue people are having is rooted in performance.  Parsing large files is time consuming, especially when unexpected things like garbage collection kick in.  We have been solving this problem for a while now with our HydraSDO for XML product.  It’s very fast being written in C++, provides a native Java API as well that utilizes shared memory so as not to impact performance, and uses a non-extractive, indexed parsing model that gives a 1.5 times original XML document size memory footprint. 

I’m excited for the opportunity to help these people with the large XML file problems they’re having.  If you’re having similar issues, let me know and we can get you some quick help.