Technology

Today's paradigms and APIs for distributed and parallel programming are too difficult for the average programmer under project pressure. Before getting to the meat of her problem domain she wants to tackle in a distributed and/or parallel manner, she easily gets lost in a myriad of details regarding her communication API du jour or her threading library of choice.

This must not be like this! Software distribution and parallelization needs to become much easier, otherwise applications will fall back behind what is possible with the available network and processor hardware.

Wanted: Abstractions for the Masses

At Xcoordination we compare the current situation with the early 1990s: Back then it was possible to develop software with graphical user interface supporting dialog windows and mouse control. It certainly was possible - but it was very hard to do. Only few developers had the time to master the intricate GUI APIs.

Then came Microsoft's Visual Basic and Borland's Delphi and suddenly GUIs were everywhere. Not just a few developers, but developer masses were able to produce more or less appealing GUIs. GUI designers and easy event-driven programming abstraction made all the difference.

Although distributed and multithreaded software is developed by many programming shops, we at Xcoordination feel it is still too difficult to reap all its benefits. Many programmers shy away from parallel/asynchronous designs and instead invest huge amounts of time into optimizations. To make a code unit faster by endless tuning of its synchronous workings seems to be more rewarding (or less painful) than switching to a new thinking/programming paradigm.

In addition there are many projects which adopted distribution and parallelization - but now are caught in a tangle of hard to understand infrastructure code. Or even worse: Suboptimal usage of complicated APIs lead to the opposite of what was desired. Instead gaining scalability many projects are confounded by bad performance.

Lacking: Current Abstractions

We at Xcoordination believe that this situation can only improve by looking at the problem of distribution and parallelization from a new point of view. We need to step back and approach both together. Where RPC, Corba, DCOM, Web services, .NET Remoting, and also WCF (Windows Communication Foundation)  all stand in the same line and thus each are examples of the "more of the same" problem solving strategy, Xcoordination breaks with this tradition. Also Xcoordination breaks with the tradition of separating software distribution and parallelization.

The assumption behind our efforts at Xcoordination is that software should start to cooperate like living beings do. Because cooperation is what distribution is about and what makes parallel programming harder than synchronous programming.

Current multithreading APIs are not about cooperation, though. They just provide low level mechanisms with which a developer can build cooperation abstractions himself. But that is a tough business and distracts him from his main task: implementing problem domain code.

Many current communication APIs are also not about cooperation. They are about synchronous commands directed at a service itself. But that is not how the rest of the world is cooperating. Cooperation is based on basic independence and autonomy - which is present in distributed software, but purposely hidden. Cooperation is by definition an asynchronous undertaking. However a lot of mainstream communication APIs are trying hard to abstract this away.

That is working to a certain extent - until LOLA is kicking in. It is because of the Law of Leaky Abstractions that many distributed systems based on mainstream communication APIs are not living up to the expectations. The fundamental asynchronicity of cooperation cannot be abstracted away without paying a price.

Spaces as a New Unifying Abstraction

Here is where Xcoordination sees the need for a new approach to distribution as well as parallelization. Both are about asynchronicity: parallel code should not wait for an answer lest it reduces the concurrentness of the whole. Commands, requests, and responses thus must be sent and received asynchronously. On the other hand, distributed code by nature is parallel code; so distributed communication also is asynchronous. And this should not be hidden!

Space Based Computing (SBC) is Xcoordination's stab at unifying the view of distributed and parallel code. SBC does not try to hide the natural asynchronicity of both, but provide a conceptual model for designing meshes of cooperating functional units.

Our technologies - Xcoordination Application Space and Xcoordination Coordination Space - then are manifestations of the SBC paradigm separating different concerns into tangible, easy to use products.

So what makes SBC different from current communication and parallelization paradigms?

At the very heart of Space Based Computing is the notion of a space shared by cooperating units of code. The space is like a whiteboard shared by several developers while dicussing the design of a software. Or it´s like an inbox on a desktop shared by a clerk and his co-workers to receive tasks.

In both examples a shared space (or medium) is used to place data which then is interpreted by others. Instead of directly commanding each other, cooperating parties observe changes in a common environment, the shared space.

When and how cooperating parties react to the changes to their shared space is up to them. Of course they should have agreed to some contract defining valid changes to the space (syntax), their meaning (semantics), and some service level (e.g. minimum response time). But otherwise the cooperating parties retain their autonomy.

Essentially the space leads to an inversion of control. It is no longer the requestors who determines when some action if going to be taken; senders of data are no longer in control. Rather receivers/observers decide about their re-action. That's how it is in real life. So that's how it should be in "digital life" once software is made up of autonomous parts (call them threads or processes or processor cores or machines).

Direct synchronous command and control is simple and efficient even through a chain of command. But when it comes to complexity and autonomy then it reaches its limits. Whereas autocracy (like in the military) tries to get rid of autonomy, even the simplest parallel - not to speak of distributed - software system is based on autonomy. That is why we at Xcoordination deem any API which tries to transfer the command and control pattern to parallel or distributed software as misleading and unsuitable.

Command and control is about obedience. Coordination and beyond it collaboration are about self-determination. SBC thus gives up any direct coupling between cooperating parties. Its credo is: Communication and coordination between distributed and parallel functional units must never be immediate and straight. Distributed and parallel systems require indirect, loose coupling which needs to be visible to the developer.

Developmental Stages of Software

Our aim at Xcoordination is to draw a bigger picture of software. Today local method calls do not seem to have to do anything with multithreading. And multithreading is not supposed to have to do anything with distributing software.

We think, however, they are dots that need to be connected. The line connecting them is the line of a natural development of software.

• Software started out as pieces of code (subroutines) synchronously coupled by calls. Still today local synchronous method calls are the main way to request services within a software.

• Then software was parallelized. Local synchronous requests for processing some data became local asynchronous requests.

• Only after the "invention" of parallel functional units distribution entered the stage.

Neither mainstream technologies, nor formal programmer training reflects this development of software. The majority of work is still done on the first developmental level of software. Programmers are looking for local synchronous solutions first.

At Xcoordination we understand this very well - but we want to provide a smooth migration path to the next developmental stages. We think programmers should not jump from local synchronous coupling to distributed synchronous. Instead we strongly believe developers should first step up to local asynchronous designs. Only once they feel comfortable with such a design they should move on to distributed software.

Interestingly though, this step then will be to natural distributed asynchronous processing instead of the artificial distributed synchronous alternative whose implementations are LOLA-ridden.

A latin proverb say "natura non facit saltus" - nature does not jump. We think, neither should software developers. Rather they should smoothly progress from one to the next developmental stages guided and supported by easy to use technologies.

That is where our products come into play:

• With the Xcoordination Application Space we are trying hard to provide a single framework to set up cooperating meshes of software from local synchronous coupling through local asynchronous to distributed asynchronous coupling.

• The Xcoordination Coordination Space then complements the Xcoordination Application Space by helping to minimize the traffic between cooperating parties and any shared state in their space. Since a space by definition is a central, maybe quite remote resource it is prudent to have an optimization strategy in store for communicating with it.
  

Summary

Distributed and parallel programming need better abstractions to become truly mainstream. Xcoordination deems Space Based Computing (SBC) to be such a beneficial abstraction. Coordination or more generally communication needs to become asynchronous and indirect between close and remote parallel function units.

But whereas bus infrastructures already provide indirection SBC adds statefulness to communication: a space is a shared state container. It is the medium which is changed and observed by cooperating parties thereby guaranteeing their autonomy. And this helps to model scalable as well as complex systems in a very natural way.