What we mean by "Space"

Usually communication between (distributed) functional units in software is described as message passing: A client is sending a message to a server. That´s like Peter sending Mary a letter. And if Peter is requesting a service of Mary he´s going to wait right by his mailbox until Mary´s response arrives.


As established this programming model or even programming paradigm is, we at Xcoordination think it might not be the best one for all programming tasks - and certainly is not the only one existing.

Think of your workplace: Are you passing around letters to your colleagues? Sure, you often write them an email, but you prefer to talk to them in person. If you want to work on something together, i.e. if you truely want to collaborate you come together at a whiteboard. It´s much quicker to jointly flesh out some ideas standing at the whiteboard than sending emails around.

Source: <1>

That´s what we want to bring to mainstream programming: pieces of software collaborating.

Instead of passing messages we´d like to see components working in a shared space. Team members are collaborating in a shared space on a shared medium, the whiteboard. Software components should be able to do the same like they see fit.

What would be the benefit? Software components would retain there autonomy. Because that´s what collaboration is about: autonomous entities working together towards a common goal. The real world is full of such autonomous entities. Each living being, each machine is such an entity. And they cannot even help but to use shared space to communicate with each other. All interaction in the real world thus is asynchronous. And it scales very well.

But in software development the notion of synchronous message passing (remember: object orientation is about messages, too) is so prevalent that it starts to hurt. Software that doesn´t benefit from multi-core processors, software that scales poorly... it´s all a result of the dominating synchronous programming paradigm.

Sure, there are event-driven architectures. There is asynchronous messaging. But they are far from mainstream. And the tools are too expensive or lack in usability for the average programmer. Plus, even async messaging still is "just" messaging, it´s still just like sending letters - although Peter no longer waits at his mailbox.

This is where Space Based Computing (SBC) enters the stage. It changes the programming paradigm fundamentally from dependent synchronous functional units to autonomous asynchronous ones. And it proposes to let those autonomous functional units collaborate only by manipulating shared state. Yes, that´s right: shared state is central to SBC. Where usual thinking about distributed systems tries to get rid of shared state or push it into the database SBC promotes it to center stage.

The reason for this change of mind is simple: shared state is so natural wherever autonomous parties are collaborating. Reasoning about collaborating software units thus promises to become simpler if they, too, can easily share state.


The Application Space is our first step in this direction. It provides the basic means for spanning a space. It defines what autonomous entities are - asynchronous components aka Workers -, it provides the basic means to let them communicate with each other - CCR ports -, and it makes it easy to distribute them.

And if you think about it you realize that there is no real difference between you, your colleagues, and a whiteboard. At least on a very, very abstract level of thinking. You are all autonomous entities - where the whiteboard is, well, not really exerting its fundamental autonomy. So in the end the workers of the Application Space don´t just stand for the collaborators, but also for the state of a collaboration.


The Application Space thus just is made up of workers: workers with some business responsibility, and workers keeping the state of a collaboration. It´s just workers communicating asynchronously with each other - like in the real world. That´s even a double indirection: collaborating workers should only communicate via an intermediary (indirection 1), and this communication runs asynchronously via a "channel" (or queue) (indirection 2). That´s why we usually draw worker communication not as a straigth line.

The Application Space, though, is only about workers and "channels". Other projects at Xcoordination will build on that platform/concept. And so can your applications. We´re confident this will lead to more scalable, evolvable, and natural software systems.


<1> http://www.irf.tu-dortmund.de/cms/en/IS/Research/Handwriting/index.html

Last edited May 22, 2009 at 4:57 PM by ralfw, version 4


No comments yet.