At the JavaZone 2010 conference last week, Kresten Krab Thorup from Trifork talked about lessons learned while implementing an Erlang virtual machine on top of JVM. One of the key messages of his presentation, at least for me, was that actor-based process modelling is the next big step in object-oriented design (or that it finally provides teams with a way to implement true object-oriented principles, depending on how you look at it).
Thorup said that the original idea with object oriented design was to model objects to represent entities that communicate by sending messages, but the industry somehow took synchronous method invocation as the best way to implement that. Method invocation is how ‘messages’ are passed between objects in all the most popular object programming languages. Such a model requires central synchronisation for distributed systems.
The Erlang Actors model, with independent entities that communicate using asynchronous messages, is famous for its reliability and fault tolerance. One of the key ideas when designing that platform was to enable developers to “build reliable systems in the presence of errors” said Thorup, so the Actors model relies heavily on isolation and concurrency. The platform takes care of asynchronous messaging and thread management, objects are inherently isolated and the only way they can communicate is to pass messages around. This at the same time relieves programmers from thinking about threading and synchronization issues and limits what they can do with individual processes.
According to Thorup, forcing people to think about isolated concurrent processing leads to better object design. “Actors and messages allow us to build more complex systems” said Krab, illustrating that with an analogy with the popular Pacman game. He said:
A process is like a little Pacman that walks around. Yellow dots are the state. Programming with threads is like playing Pacman and constantly looking that you are not in the way of the other guys, and at the end you’ll lose anyway. In the actors model, everyone is in a little enclosure. Instead of grabbing state, they send messages.
Actors push developers towards Anthropomorphic programming, coined by Morven Gentleman, which asks designers to think about parts of a software system as people. Treating parts of the program as independent, concurrently operating and thinking objects that can react to messages but not share state is much closer to the original object orientation ideas than synchronous method invocation. “Actor modelling is an evolution of OO”, concluded Thorup.
Pushing people towards OO best practices
I’m not sure how much this is an evolution and how much it actually just pushes people in the right direction. I have not tried to build anything apart from a very simple example project with Actors, so I can’t really speak about that from real-world experience, but it looks as if it the constraints of the Actors model push designs towards many tried and tested OO best practices. Because Actors do not share state, software has to be designed around aggregates that run independently from each-other. This promotes low coupling, tight cohesion and clearly defined responsibilities. It also forces people to think about aggregates (DDD) upfront.
The actors execution environment handles the infrastructure, threading and asynchronous messaging. Implicit links between actors allow developers to model fault-tolerant systems by thinking of independent processing where collaborators can disappear. This promotes a clear separation of infrastructural processing and business code (and allows developers to focus on modelling the business functionality). Actors also support aggregation into request pipelines, allowing developers to easily set constraints such as time-outs at system boundaries without having to build checks and time-outs at every step of an internal process.
The Actors model fits in very nicely with the Domain-Driven-Design ideas about domain events and aggregates, especially CQRS and event sourcing which have seen quite a surge of interest recently. Scala, which boasts an implementation of Actors that runs on JVM, is also grabbing headlines at the moment and seems destined to become the new Java. I wouldn’t be surprised if Actors become the preferred way to design and implement OO systems in the near future.
|
|
Actors are interesting, but in what sense does Scala seem destined to become the new Java? Scala has some interesting ideas, but it’s overly complicated and difficult to learn. I’d recommend giving a serious look at Clojure, which seems much more flexible and powerful to me, if you’re considering using a functional language on the JVM.
At several conferences I recently attended there was a lot of talk about Scala being a cleaned up alternative for Java for green-field development. Clojure seems interesting as well, but I guess the transition to Scala is going to be easier.
Hm… why does the next step beyond OO need to involve asynchronicity? That would add more complexity than necessary to make software design easier.
My current opinion is, that we need to step back from the von-Neumann architecture of which OOP is a child. The von-Neumann model “dictates” a global memory to which many functional units have access to share data. That´s making all sorts of trouble – although it kinda looks like so natural.
Functional programming is an alternative. (Which Erlang takes to the realm of async and distributed software.) Data flow programming is another alternative, I´d say. I´m experimenting with that – and like it quite a bit
It makes designing software very easy once you get the knack of it.
-Ralf