Xcoordination Application Space
The Xcoordination Application Space is Xcoordination's vision of a fundamental platform for Space Based Computing (SBC). It provides the basic means to span a space between cooperating parties.
To achieve this, the Xcoordination Application Space assembles a number of existing and proven technologies and concepts under its roof. The goal is to pick up the average developer where she stands today and gradually move her up the developmental levels of software.
Local Synchronous Components
Components as basic buildings blocks provide a number of benefits for software construction. They are binary functional units (black boxes) with a separate and explicit contract fostering parallel implementation, isolated testing, automatic production, evolvability, and also reusability.
Such components can easily be integrated into larger wholes using Dependency Injection (DI) using DI containers like Spring.Net, Castle Windsor, Microsoft Unity, NinJect and the like. They literally weave a mesh of local responsibilities, albeit synchronous ones. Components communicate via the stack.
Nevertheless the Xcoordination Application Space provides DI container functionality based on Microsoft Unity, because "thinking in components" is what is needed to make the transition from local to remote, from small to large systems. They are at the boundary from the first developmental stage of software to the next higher.
Local Asynchronous Components
To enter the next level of software development, the Xcoordination Application Space builds upon Microsoft´s Concurrency Coordination Runtime (CCR).
In order to benefit from future processor generations software needs to increase its internal concurrency. As Intel says: Software needs to double its parallelism every 2 years to keep up with processor development. But how to do that? Thinking in terms of threads and locks certainly is not the way to go. Higher abstractions are needed. That´s what the CCR provides: a higher level view of parallelism based on the notion of tasks initiating each other with events on so called ports. Ports can be used as single event sinks or they can be "tied together" by coordination primitives like Join or Choice.
Xcoordination found this to be a perfect foundation for the next level of component orientation. The Xcoordination Application Space uses CCR structures to define asynchronous components - or what we call workers - and make them as easily usable as synchronous components.
This allows software developers to use the same infrastructure tool to build synchronous and/or asynchronous component oriented software.
Distributed Asynchronous Components
Traditionally it´s quite special to develop distributed software. Communication functional units residing in different and remote address spaces is completely unlike synchronous communication between methods in the same process. This difference can be liked to the difference between Newtonian and relativistic physics.
However, RPC, Corba, DCOM, Web services, .NET Remoting, and still WCF tried and are trying to gloss over this difference so that remote functionality can be used like local functionality. This works to a certain extent - but many projects have experienced difficulties when it comes to scalability. They hit a glass ceiling; the method call programming paradigm invented for local synchronous delegation of work broke down beneath them.
That´s why we at Xcoordination think we need a completely different approach to distributed software. One based on messages and events - and in addition on the notion of a coordination space.
Proponents of messaging platforms and event-driven architectures as well as programmers of embedded systems have long since advocated the use of asynchronous communication to decouple functional units. So far it has been comparatively difficult to switch from local synchronous architectures to distributed asynchronous architectures. That´s why so much effort has been invested into infrastructure technologies to keep up the synchronous programming model even in distributed scenarios.
But the technological landscape has changed! Xcoordination has aggregated established communication technologies like TCP sockets, WCF, or Jabber with the CCR into a larger whole making the transition from local to distributed very easy. Again, no change of infrastructure is needed. The same Xcoordination Application Space used for local synchronous components is used to host asynchronous components in a distributed fashion.
Our credo is: once you think component oriented, and once you switch to asynchronous components, then distribution comes for free. That´s not to mean distribution looses all its challenges (like higher requirements in terms of security); but at least the Xcoordination Application Spaces removes the glass ceiling over your applications.
Design for local asynchronous operation. Test and debug locallly. Once you´re satisfied with the results distribute your components. There need not be any difference in your code.
Xcoordination Application Space: It´s distribution that simply works.
It´s based on proven technologies. It´s providing a single platform for a smooth transition from
- single code blob to multiple components,
- single core multithreading to true multi-core multitasking.
- single process hosting to multi-process hosting,
- single machine applications to mutiple real or virtual machines in a local network,
- single network applications to worldwide multi network architectures communicating "through the cloud" or even easily hosting services in the cloud.
On top of that the Xcoordination Application Space of course is extensible. So if you find it´s lacking some kind of communication medium besides all that TCP sockets, WCF, and Jabber are providing, then you can role your own communication service. It´s just a simple interface to implement, and all messages posted to CCR ports belonging to a remote asynchronous components will be transported via your own communication channel. Xcoordination would be glad to assist you in extending the Xcoordination Application Space in this and other ways.