Christian Weyer's Blog

Axum and the CCR: what and how?

This is copied verbatim from a MSDN Forums post about how Axum uses parts of the CCR:

Here's what we did:

1. We took the CCR sources, changed most of the names, slightly refactored the interfaces and added a few things.
2. We built it into Microsoft.Axum.Runtime.dll
3. We built channel ports on top of CCR Ports (renamed OrderedInteractionPoints).
4. We exposed OIP to programmers (see the WebFetcher sample).
5. We built 'async,' 'sync,' and 'const' empty/full storage capabilites on some additions we made to CCR.
6. The 'receive' expression utilizes a Receiver to hook into the source.

One reason for the rename is that in the CTP, you really need to use the Axum capabilities (data-flow networks, receives, etc.) to program the local (within-domain) message-passing capabilites, and we didn't want to create another distribution of the CCR. If you want to use CCR, please get it separately, as it is not currently safe to use with Axum unless you go through the language capabilities. It is likewise not generally safe to create your own threads from within an Axum domain, and there is no need to.

Source

Axum - a service-oriented programming language(?)

The more I read about Axum and hack the first lines of code, the more I feel there will be something that could make my life easier.
In the past years I tried to advocate the idea of service-orientation (and no: I am *not* talking about SOA - if you ever attended a session of mine you know that I am more than explicit about this point).

I like the idea of explicit boundaries, description via interfaces and contracts and definition of policies for runtime information. It goes that far that I try to follow the service-orientation principles wherever it makes sense (usually being a bit weak on the policies side).
Please note that I am not talking about WCF, I am talking about service-orientation. Yes, WCF is quite a nice framework (read: tool) to realize service-oriented systems. But then it is also a communication foundation which means it can be used to accomplish a lot more than the prototypical thinking around service-orientation.

Service-orientation is an attitude.

Now with Axum I can smell service-orientation in my language.

In service orientation there are services. In service orientation data is exchanged via channels and messages. In service orientation there are message handlers. In service orientation there are interfaces and contracts to describe the boundary.

In Axum there are domains for isolation. In Axum information is passed via channels and messages. In Axum there are agents for handling communication (either in a domain or between domains). In Axum there is schema to describe the exchanged information.

Pure joy (there seem to be more equivalent ideas, but this is good enough for starters).
We will see how this all turns out. On one hand, I am still starting to understand Axum. On the other hand, Axum is currently an incubation project, nothing more.

P.S.: the last Microsoft incubation project I was working on/with was code-named "Biztalk Services". This is now known as .NET Services as part of the Azure Services Platform...


BTW: I am *not* advocating that every class should be a service (at least there is no concept of a class in Axum ;)).

I *think* I see the future: Axum (or is it just Erlang for .NET?)

Holy cow. There have been a lot of announcements recently in the space of parallel programming, language- and tool-wise (just look at what happened at PDC08). And I must admit I could not keep up with researching each and every announcement.

I played around a bit the other day (OK, the other year...) with the Concurrency & Coordination Runtime (CCR) from the Microsoft Robotics team - but I could not really get convinced that this is what we are supposed to do in the future when planning, architecting and writing highly distributed, concurrent applications (or actually algorithms or 'pieces of code'). No, this just feels too clumsy, too much tool- and library-heavy.
And no, I did not yet look in depth into the new stuff that .NET 4.0 will bring us. Just a matter of time, I guess.

Then, on Friday, I stumbled over something that looks promising: Axum.
And the more I read about it and the more I play around (it is really just playing, trying to grok, to understand, to learn) the more I *think* this *could* be the future of parallel programming and processing. One nice thing is that Axum builds on top of some of the CCR features, but gives us a language and not a lib and tool feeling.

Browsing the web I can already see discussions how Axum relates and compares to Erlang. I not really such a big language expert, but borrowing from a very successful language (which solves exactly the problems it was invented for) is nothing to trash :)

Just a note, though.