public
Description: Akka: RESTful Distributed Fault-tolerant Persistent Transactional Actors
Home | Edit | New

Modules: The High-Level View

Starting with the high-level view, we’ll walk through the different modules.

Akka is built up by a set of core modules that can be used altogether or in isolation. These modules are:

Actor (Scala) and Active Object (Java) module

  • Java and Scala API
  • Fault tolerance (using Erlang-style supervisor hierarchies) on service level
  • Powerful and simple concurrency abstractions through the Actor Model and Active Object Model
  • Event-based, staged, asynchronous workflows (SEDA-in-a-box)
  • Lightweight thread dispatcher (you can easily create millions of a single workstation)
  • Native thread dispatcher
  • Highly configurable message queue semantics, queue depth, thread pools strategies etc.
  • Performant but designed for scalability and high throughput

Remoting/Distributed services module

  • Scalability and High-Availability
  • Another dimensional fault tolerance (on JVM/box level)
  • Remote supervision and error managament
  • Run 1-100+ Akka instances

Transactors: Software Transactional Memory (STM) module

Actors are excellent for solving of problems where you have many independent processes that can work in isolation and only interact with other Actors through message passing. This model fits many problems. But the actor model is unfortunately a terrible model for implementing truly shared state. E.g. when you need to have consensus and a stable view of state across many components. The classic example is the bank account to clients to deposits and withdrawals in which each operation needs to be atomic. For detailed discussion on the topic see this JavaOne presentation.

STM on the other hand is excellent for problems where you need consensus and a stable view of the state by providing compositional transactional shared state. Some of the really nice traits of STM is that transactions compose and that it raises the abstraction level from lock-based concurrency.

Akkas’ Transactors, e.g. being able to optionally combine Actors and STM provides IMHO the best of the Actor model (concurrency and asynchronous event-based programming) and STM (compositional transactional shared state) by providing transactional, compositional,
asynchronous, event-based message flows.

  • Transactional (in-memory) Map, Vector & Reference
  • Implements the Clojure’s state model using Managed References and persistent data structures
  • The STM understands the Actor model, e.g.
    • allows you to orchestrate composed asynchronous message flows if you have a need for consensus across many Actors
    • is not tied to a specific thread but follows the message across thread boundaries
    • works with asynchronous calls (that never returns)
  • Distributed transactions will come very soon, backed up by ZooKeeper.

REST & Comet (push/streaming REST/AJAX) module

  • Expose Actors & Active Objects as REST services through JAX-RS
  • Expose Actors & Active Objects as Comet services through Atmosphere

Persistence module

  • Provides persistence abstraction exposed through Transactional Map, Vector & Reference
  • Works with the Software Transactional Memory to provide transactional storage
  • Attempts to provide both:

Servlet

  • To be deployed in arbitrary servlet container

Kernel

  • Embedding servlet container implementing a full enterprise stack

Management and Monitoring

Exposes all configuration parameters, such as thread pools, queue sizes and current depth, fault rates etc. through:

  • JMX allowing both management and monitoring
  • w3c logging
Last edited by jboner, Thu Jul 30 07:47:17 -0700 2009
Home | Edit | New
Versions: