Channels

Distributing an Axum Application

Axum: Isolation, Agents, and Message-passing in .NET — Thu, 30 Apr 2009 02:49:10 GMT

Note: a variant of this text also appears in the Axum Programmer’s Guide, which will be distributed with

re: Channels

Niklas Gustafsson — Wed, 04 Mar 2009 08:07:05 GMT

Interfaces and channels are checked at compile-time in that respect, i.e. that ports are used correctly from a type perspective.

What is different about channels is that they have protocols, which interfaces obviously don't (although adding them doesn't take much imagination). We currently check them at runtime, but it is also possible to do static verification of contracts through model checking, which can be quite expensive to do.

On the positive side, model checking seems more feasible to do in finite time when you have bilateral chcannels rather then many-to-one or many-to-many mailboxes that are sometimes used in actor-based models.

Hopefully, this addresses your question.

re: Channels

Rajesh Karmani — Wed, 04 Mar 2009 06:23:30 GMT

Sorry for being vague. I meant that correct usage (calling methods) of an interface type is checked at compile time.

re: Channels

Niklas Gustafsson — Wed, 04 Mar 2009 02:07:02 GMT

Rajesh,

What do you mean with "interfaces are enforced at compile time"?

re: Channels

Rajesh Karmani — Wed, 04 Mar 2009 00:20:12 GMT

Channel contracts seem similar to interface contracts in OO programming: they separate the behavior from the implementation. But interfaces are enforced at compile time. As I understand, channel contracts are enforced at run-time in Maestro. Can they be enforced at compile time?

re: Channels

Niklas Gustafsson — Tue, 03 Mar 2009 23:53:21 GMT

Regarding caring about message order:

While stateless patterns are usually good for scalability, there are good uses for stateful actors, particularly for in-process uses. Open a book on Erlang and you'll find lots of very stateful actors.

Thus, Maestro doesn't take a stand -- use stateless protocols if they serve your purposes. If you find the need for stateful contracts, the language is there to help.

Regarding pi and F#:

I would say that Maestro's model is closer to CSP than it is to pi-calculus. However, it's not quite CSP, either -- Maestro communication is asynchronous and buffered.

F# -- interesting that you would bring it up. It would be fascinating to explore what such a langiage would look like, wouldn't it?

re: Channels

Jeffry Borror — Tue, 03 Mar 2009 21:07:28 GMT

Thanks for an interesting set of posts. I feel like I've walked into the middle of the movie.

How does Maestro compare to process calculi such as the pi calculus? It seems that there is a relation to the join calculus.

Have you considered a version of Maestro based on F#? Not only does it have objects and mutable data, but pipelining is the metaphor for function composition. Maestro provides a natural generalization to the concurrent world. (Maybe the F# team would give you way to mark a function as pure.) It might be more natural to express your operations as combinators.

re: Channels

Steve Bjorg — Tue, 03 Mar 2009 01:25:07 GMT

I'm surprised that you care about stateful protocols. Didn't REST and now web-oriented architecture (WOA) make a compelling case for stateless protocols? They have been shown to scale and work well for the vast majority of applications with some exceptions of course, but there are always exceptions.

Rather than focusing on message order, why not focus on data longevity instead? Good downstream cache-management and "data revalidation hints" are a pain to deal with, yet essential to scalable deployments. Having support for such concepts at the Maestro level would, imho, provide a lot more benefit than worrying about message order.

Cheers,

- Steve

Click & Solve » Channels

Click & Solve » Channels — Mon, 02 Mar 2009 21:38:15 GMT

PingBack from http://www.clickandsolve.com/?p=16734