views:

1302

answers:

3

Recently i have been getting into alternative languages that support an actor/agent/shared nothing architecture - ie. scala, clojure etc (clojure also supports shared state).

So far most of the documentation that I have read focus around the intro level. What I am looking for is more advanced documentation along the gang of four but instead shared nothing based.

Why ? It helps to grok the change in design thinking. Simple examples are easy, but in a real world java application (single threaded) you can have object graphs with 1000's of members with complex relationships. But with agent based concurrency development it introduces a whole new set of ideas to comprehend when designing large systems. ie. Agent granularity - how much state should one agent manage - implications on performance etc or are their good patterns for mapping shared state object graphs to agent based system. tips on mapping domain models to design. Discussions not on the technology but more on how to BEST use the technology in design (real world "complex" examples would be great).

A: 

I asked a similar question here which had some reasonable answers that may help. I'm watching yours carefully. I haven't yet found something which has really helped me, but I am very actively looking.

I think the mind-shift is the single largest barrier to stepping to concurrent architectures and languages and until that is cracked developers are going to stick with easy to learn MS style paradigms. For it to really become mainstream it needs to find its way into schools and be taught alongside C# and VB.

My answer to the 2080 programmers question is "concurrently".

Simon
+5  A: 

Even if I cannot come up with any good real world examples that provide you with design patterns straight up, there are a few places to start.

The first is getting your head wrapped properly round the concepts. One book helping you do this is Making reliable distributed systems in the presence of software errors written by an Erlang Guru Joe Armstrong where explains Concurrency Oriented Programming in a very accessible way. It is in fact a Ph.D. thesis, but do not let that scare you. It is by far easier to read, and pleasant into the bargain, than most common text books.

Looking at actual systems normally means that you have to learn too much about the actual language for it too make sense just to evaluate things. For Erlang the documentation provides design methodology and behaviours(Erlang speek for design pattern libraries). This will illustrate the design patterns most commonly used in this setting. And these have proved to be effective in building large scale systems, i.e. millions of lines of code (comparable to a factor 4 to 10 of other languages such as Java) and milloins of concurrent processes running on one machine in distributed clusters of machines. A recent example of a real live system is Facebook Chat.

For the other frameworks I cannot really help you I am afraid.

Jan Henry Nystrom
the facebook chat sounds interesting. When you look at the issue of chat/pbx design, "interaction" objects make a good "agent" because an interaction is for the most part self contained in terms of state (parties, fsm for each party etc). It would be nice to see what they did design wise.
nso1
+1  A: 

An "actor" is itself the unifying pattern for concurrent programming (an asynchronous message queue plus an execution context for processing it), but there are many design patterns which assist in specifying aspects or elements of agent-based systems. Many of the most common can be found in Wikipedia's article on Concurrency Patterns. Some highlights:

If you haven't come across it already, Akka may be of interest to you -- it is a "purely" event-driven actor framework running on the JVM.

Joe