Jonas Bonér

Introducing Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors

2010-01-04T00:00:00+00:00

Introducing Akka – Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors

4 Jan 2010

Introduction

Writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it’s because we are using the wrong tools and the wrong level of abstraction.

Akka is an attempt to change that.

Akka uses the Actor Model together with Software Transactional Memory to raise the abstraction level and provide a better platform to build correct concurrent and scalable applications.

For fault-tolerance Akka adopts the “Let it crash”, also called “Embrace failure”, model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop.

Actors also provides the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications.

Akka is Open Source and available under the Apache 2 License.

In this article we will introduce you to Akka and see how we can utilize it to build a highly concurrent, scalable and fault-tolerant network server.

But first let’s take a step back and discuss what Actors really are and what they are useful for.

Actors

The Actor Model provides a higher level of abstraction for writing concurrent and distributed systems. It alleviates the developer from having to deal with explicit locking and thread management. It makes it easier to write correct concurrent and parallel systems. Actors are really nothing new, they were defined in the 1963 paper by Carl Hewitt and have been popularized by the Erlang language which emerged in the mid 80s. It has been used by for example at Ericsson with great success to build highly concurrent and extremely reliable (99.9999999 % availability – 31 ms/year downtime) telecom systems.

Actors encapsulates state and behavior into a lightweight process/thread. In a sense they are like OO objects but with a major semantic difference; they do not share state with any other Actor. Each Actor have their own view of the world and can only have impact on other Actors by sending messages to them. Messages are sent asynchronously and non-blocking in a so-called “fire-and-forget” manner where the Actor sends off a message to some other Actor and then do not wait for a reply but goes off doing other things or are suspended by the runtime. Each Actor has a mailbox (ordered message queue) in which incoming messages are processed one by one. Since all processing is done asynchronously and Actors do not block and consume any resources while waiting for messages, Actors tend to give very good concurrency and scalability characteristics and are excellent for building event-based systems.

Creating Actors

Akka has both a Scala API and a Java API. In this article we will only look at the Scala API since that is the most expressive one. The article assumes some basic Scala knowledge, but even if you don’t know Scala I don’t think it will not be too hard to follow along anyway.

Akka has adopted the same style of writing Actors as Erlang in which each Actor has an explicit message handler which does pattern matching to match on the incoming messages.

Actors can be created either by:

Extending the ‘Actor’ class and implementing the ‘receive’ method.
Create an anonymous Actor using one of the ‘actor’ methods.

Here is a little example before we dive into a more interesting one.

class MyActor extends Actor {
  def receive = {
    case "test" => println("received test")
    case _ =>      println("received unknown message")
  }
}

val myActor = new MyActor
myActor.start

Here is the same Actor with the anonymous syntax. Anonymous Actors are implicitly started:

val myActor = actor { 
  case "test" => println("received test")
  case _ =>      println("received unknown message")
}

Akka Actors are extremely lightweight. Each Actor consume ~600 bytes, which means that you can create 6.5 million on 4 G RAM.

Messages are sent using the ‘!’ operator:

myActor ! "test"

Sample application

We will try to write a simple chat/IM system. It is client-server based and uses remote Actors to implement remote clients. Even if it is not likely that you will ever write a chat system I think that it can be a useful exercise since it uses patterns and idioms found in many other use-cases and domains.

We will use many of the features of Akka along the way. In particular; Actors, fault-tolerance using Actor supervision, remote Actors, Software Transactional Memory (STM) and persistence.

But let’s start by defining the messages that will flow in our system.

Creating messages

It is very important that all messages that will be sent around in the system are immutable. The Actor model relies on the simple fact that no state is shared between Actors and the only way to guarantee that is to make sure we don’t pass mutable state around as part of the messages.

In Scala we have something called case classes. These make excellent messages since they are both immutable and great to pattern match on.

Let’s now start by creating the messages that will flow in our system.

/**
 * ChatServer's internal events.
 */
sealed trait Event

case class Login(username: String) extends Event
case class Logout(username: String) extends Event

case class ChatMessage(fromUser: String, message: String) extends Event

case class GetChatLog(fromUser: String) extends Event
case class ChatLog(messages: List[String]) extends Event

As you can see with these messages we can log in and out, send a chat message and ask for and get a reply with all the messages in the chat log so far.

Client: Sending messages

Our client wraps each message send in a function, making it a bit easier to use. Here we assume that we have a reference to the chat service so we can communicate with it by sending messages. Messages are sent with the ‘!’ operator (pronounced “bang”). This sends a message of asynchronously and do not wait for a reply.

Sometimes however, there is a need for sequential logic, sending a message and wait for the reply before doing anything else. In Akka we can achieve that using the ‘!!’ (“bangbang”) operator. When sending a message with ‘!!’ we do not return immediately but wait for a reply using a Future. A ‘Future’ is a promise that we will get a result later but with the difference from regular method dispatch that the OS thread we are running on is put to sleep while waiting and that we can set a time-out for how long we wait before bailing out, retrying or doing something else. The ‘!!’ function returns a scala.Option which implements the Null Object pattern. It has two subclasses; ‘None’ which means no result and ‘Some(value)’ which means that we got a reply. The ‘Option’ class has a lot of great methods to work with the case of not getting a defined result. F.e. as you can see below we are using the ‘getOrElse’ method which will try to return the result and if there is no result defined invoke the “…OrElse” statement.

/**
 * Chat client.
 */
class ChatClient(val name: String) { 
  import Actor.Sender.Self
  def login =                 ChatService ! Login(name) 
  def logout =                ChatService ! Logout(name)  
  def post(message: String) = ChatService ! ChatMessage(name, name + ": " + message)  
  def chatLog: ChatLog = {
    val option = ChatService !! (GetChatLog(name), 1000) // timeout 1000 ms
    option.getOrElse(throw new Exception("Couldn't get the chat log"))	
  }
}

Session: Receiving messages

Now we are done with the client side and let’s dig into the server code. We start by creating a user session. The session is an Actor and is defined by extending the ‘Actor’ trait. This trait has one abstract method that we have to define; ‘receive’ which implements the message handler for the Actor.

In our example the session has state in the form of a ‘List’ with all the messages sent by the user during the session. In takes two parameters in its constructor; the user name and a reference to an Actor implementing the persistent message storage. For both of the messages it responds to, ‘ChatMessage’ and ‘GetChatLog’, it passes them on to the storage Actor.

If you look closely (in the code below) you will see that when passing on the ‘GetChatLog’ message we are not using ‘!’ but ‘forward’. This is similar to ‘!’ but with the important difference that it passes the original sender reference, in this case to the storage Actor. This means that the storage can use this reference to reply to the original sender (our client) directly.

/**
 * Internal chat client session.
 */
class Session(user: String, storage: Actor) extends Actor {
  private val loginTime = System.currentTimeMillis
  private var userLog: List[String] = Nil

  log.info("New session for user [%s] has been created at [%s]", user, loginTime)

  def receive = {
    case event: ChatMessage => 
      userLog ::= event.message
      storage ! event

    case event: GetChatLog => 
      storage forward event
  }
}

Let it crash: Implementing fault-tolerance

Akka’s approach to fault-tolerance; the “let it crash” model, is implemented by linking Actors. It is very different to what Java and most non-concurrency oriented languages/frameworks have adopted. It’s a way of dealing with failure that is designed for concurrent and distributed systems.

If we look at concurrency first. Now let’s assume we are using non-linked Actors. Throwing an exception in concurrent code, will just simply blow up the thread that currently executes the Actor. There is no way to find out that things went wrong (apart from see the stack trace in the log). There is nothing you can do about it. Here linked Actors provide a clean way of both getting notification of the error so you know what happened, as well as the Actor that crashed, so you can do something about it.

Linking Actors allow you to create sets of Actors where you can be sure that either:

All are dead
All are alive

This is very useful when you have hundreds of thousands of concurrent Actors. Some Actors might have implicit dependencies and together implement a service, computation, user session etc. for these being able to group them is very nice.

Akka encourages non-defensive programming. Don’t try to prevent things from go wrong, because they will, whether you want it or not. Instead; expect failure as a natural state in the life-cycle of your app, crash early and let someone else (that sees the whole picture), deal with it.

Now let’s look at distributed Actors. As you probably know, you can’t build a fault-tolerant system with just one single node, but you need at least two. Also, you (usually) need to know if one node is down and/or the service you are talking to on the other node is down. Here Actor supervision/linking is a critical tool for not only monitoring the health of remote services, but to actually manage the service, do something about the problem if the Actor or node is down. This could be restarting him on the same node or on another node.

To sum things up, it is a very different way of thinking but a way that is very useful (if not critical) to building fault-tolerant highly concurrent and distributed applications.

Supervisor hierarchies

A supervisor is a regular Actor that is responsible for starting, stopping and monitoring its child Actors. The basic idea of a supervisor is that it should keep its child Actors alive by restarting them when necessary. This makes for a completely different view on how to write fault-tolerant servers. Instead of trying all things possible to prevent an error from happening, this approach embraces failure. It shifts the view to look at errors as something natural and something that will happen and instead of trying to prevent it; embrace it. Just “let it crash” and reset the service to a stable state through restart.

Akka has two different restart strategies; All-For-One and One-For-One.

OneForOne: Restart only the component that has crashed.
AllForOne: Restart all the components that the supervisor is managing, including the one that have crashed.

The latter strategy should be used when you have a certain set of components that are coupled in some way that if one is crashing they all need to be reset to a stable state before continuing.

Chat server: Supervision, Traits and more

There are two ways you can define an Actor to be a supervisor; declaratively and dynamically. In this example we use the dynamic approach. There are two things we have to do:

Define the fault handler by setting the ‘faultHandler’ member field to the strategy we want.
Define the exceptions we want to “trap”, e.g. which exceptions should be handled according to the fault handling strategy we have defined. This in done by setting the ‘trapExit’ member field to a ‘List’ with all exceptions we want to trap.

The last thing we have to do to supervise Actors (in our example the storage Actor) is to ‘link’ the Actor. Invoking ‘link(actor)’ will create a link between the Actor passed as argument into ‘link’ and ourselves. This means that we will now get a notification if the linked Actor is crashing and if the cause of the crash, the exception, matches one of the exceptions in our ‘trapExit’ list then the crashed Actor is restarted according the the fault handling strategy defined in our ‘faultHandler’. We also have the ‘unlink(actor)’ function which disconnects the linked Actor from the supervisor.

In our example we are using a method called ‘startLink(actor)’ which starts the Actor and links him in an atomic operation. The linking and unlinking is done in ‘init’ and ‘shutdown’ callback methods which are invoked by the runtime when the Actor is started and shut down (shutting down is done by invoking ‘actor.stop’). In these methods we initialize our Actor, by starting and linking the storage Actor and clean up after ourselves by shutting down all the user session Actors and the storage Actor.

That is it. Now we have implemented the supervising part of the fault-tolerance for the storage Actor. But before we dive into the ‘ChatServer’ code there are some more things worth mentioning about its implementation.

It defines an abstract member field holding the ‘ChatStorage’ implementation the server wants to use. We do not define that in the ‘ChatServer’ directly since we want to decouple it from the actual storage implementation.

The ‘ChatServer’ is a ‘trait’, which is Scala’s version of mixins. A mixin can be seen as an interface with an implementation and is a very powerful tool in Object-Oriented design that makes it possible to design the system into small, reusable, highly cohesive, loosely coupled parts that can be composed into larger object and components structures.

I’ll try to show you how we can make use Scala’s mixins to decouple the Actor implementation from the business logic of managing the user sessions, routing the chat messages and storing them in the persistent storage. Each of these separate parts of the server logic will be represented by its own trait; giving us four different isolated mixins; ‘Actor’, ‘SessionManagement’, ‘ChatManagement’ and ‘ChatStorageFactory’ This will give us as loosely coupled system with high cohesion and reusability. At the end of the article I’ll show you how you can compose these mixins into a the complete runtime component we like.

/**
 * Chat server. Manages sessions and redirects all 
 * other messages to the Session for the client.
 */
trait ChatServer extends Actor {
  faultHandler = Some(OneForOneStrategy(5, 5000))
  trapExit = List(classOf[Exception])

  val storage: ChatStorage

  log.info("Chat service is starting up...")

  // actor message handler
  def receive = sessionManagement orElse chatManagement

  // abstract methods to be defined somewhere else
  protected def chatManagement: PartialFunction[Any, Unit]
  protected def sessionManagement: PartialFunction[Any, Unit]   
  protected def shutdownSessions: Unit

  override def init = startLink(storage)

  override def shutdown = { 
    log.info("Chat server is shutting down...")
    shutdownSessions
    unlink(storage)
    storage.stop
  }
}

If you look at the ‘receive’ message handler function you can see that we have defined it but instead of adding our logic there we are delegating to two different functions; ‘sessionManagement’ and ‘chatManagement’, chaining them with ‘orElse’. These two functions are defined as abstract in our ‘ChatServer’ which means that they have to be provided by some another mixin or class when we instantiate our ‘ChatServer’. Naturally we will put the ‘sessionManagement’ implementation in the ‘SessionManagement’ trait and the ‘chatManagement’ implementation in the ‘ChatManagement’ trait. First let’s create the ‘SessionManagement’ trait.

Chaining partial functions like this is a great way of composing functionality in Actors. You can for example put define one default message handle handling generic messages in the base Actor and then let deriving Actors extend that functionality by defining additional message handlers. There is a section on how that is done here.

Session management

The session management is defined in the ‘SessionManagement’ trait in which we implement the two abstract methods in the ‘ChatServer’; ‘sessionManagement’ and ‘shutdownSessions’.

The ‘SessionManagement’ trait holds a ‘HashMap’ with all the session Actors mapped by user name as well as a reference to the storage (to be able to pass it in to each newly created ‘Session’).

The ‘sessionManagement’ function performs session management by responding to the ‘Login’ and ‘Logout’ messages. For each ‘Login’ message it creates a new ‘Session’ Actor, starts it and puts it in the ‘sessions’ Map and for each ‘Logout’ message it does the opposite; shuts down the user’s session and removes it from the ‘sessions’ Map.

The ‘shutdownSessions’ function simply shuts all the sessions Actors down. That completes the user session management.

/**
 * Implements user session management.
 * <p/>
 * Uses self-type annotation 'this: Actor =>'
 * to declare that it needs to be mixed in with an Actor.
 */
trait SessionManagement { this: Actor => 

  val storage: ChatStorage // needs someone to provide the ChatStorage
  val sessions = new HashMap[String, Actor]

  protected def sessionManagement: PartialFunction[Any, Unit] = {
    case Login(username) => 
      log.info("User [%s] has logged in", username)
      val session = new Session(username, storage)
      session.start
      sessions += (username -> session)

    case Logout(username) =>        
      log.info("User [%s] has logged out", username)
      val session = sessions(username)
      session.stop
      sessions -= username 
  }  

  protected def shutdownSessions = 
    sessions.foreach { case (_, session) => session.stop }  
}

Chat message management

Chat message management is implemented by the ‘ChatManagement’ trait. It has an abstract ‘HashMap’ session member field with all the sessions. Since it is abstract it needs to be mixed in with someone that can provide this reference. If this dependency is not resolved when composing the final component, you will get a compilation error.

It implements the ‘chatManagement’ function which responds to two different messages; ‘ChatMessage’ and ‘GetChatLog’. It simply gets the session for the user (the sender of the message) and routes the message to this session. Here we also use the ‘forward’ function to make sure the original sender reference is passed along to allow the end receiver to reply back directly.

/**
 * Implements chat management, e.g. chat message dispatch.
 * <p/>
 * Uses self-type annotation 'this: Actor =>'
 * to declare that it needs to be mixed in with an Actor.
 */
trait ChatManagement { this: Actor =>
  val sessions: HashMap[String, Actor] // someone needs to provide the Session map

  protected def chatManagement: PartialFunction[Any, Unit] = {
    case msg @ ChatMessage(from, _) => sessions(from) ! msg
    case msg @ GetChatLog(from) =>     sessions(from) forward msg
  }
}

Using an Actor as a message broker, as in this example, is a very common pattern with many variations; load-balancing, master/worker, map/reduce, replication, logging etc. It becomes even more useful with remote Actors when we can use it to route messages to different nodes.

STM and Transactors

Actors are excellent for solving 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 where clients can deposit and withdraw, in which each operation needs to be atomic. For detailed discussion on the topic see this presentation.

Software Transactional Memory (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 are that transactions compose and that it raises the abstraction level from lock-based concurrency.

Akka has a STM implementation that is based on the same ideas as found in the Clojure language; Managed References working with immutable data.

Akka allows you to combine Actors and STM into what we call Transactors (short for Transactional Actors), these allow you to optionally combine Actors and STM provides IMHO the best of the Actor model (simple concurrency and asynchronous event-based programming) and STM (compositional transactional shared state) by providing transactional, compositional, asynchronous, event-based message flows. You don’t need Transactors all the time but when you do need them then you really need them.

Akka currently provides three different transactional abstractions; ‘Map’, ‘Vector’ and ‘Ref’. They can be shared between multiple Actors and they are managed by the STM. You are not allowed to modify them outside a transaction, if you do so, an exception will be thrown.

What you get is transactional memory in which multiple Actors are allowed to read and write to the same memory concurrently and if there is a clash between two transactions then both of them are aborted and retried. Aborting a transaction means that the memory is rolled back to the state it were in when the transaction was started.

In database terms STM gives you ‘ACI’ semantics; ‘Atomicity’, ‘Consistency’ and ‘Isolation’. The ‘D’ in ‘ACID’; ‘Durability’, you can’t get with an STM since it is in memory. This however is addressed by the persistence module in Akka.

Persistence: Storing the chat log

Akka provides the possibility of taking the transactional data structures we discussed above and making them persistent. It is an extension to the STM which guarantees that it has the same semantics.

The persistence module has pluggable storage back-ends. At the time of the writing it has three different storage back-ends:

Cassandra – A distributed structured storage database.
MongoDB – A high performance schema-free, document oriented data store with SQL like query facilities.
Redis – An advanced key-value store, also called a data structure server, with lists, ordered sets etc.

They all implement persistent ‘Map’, ‘Vector’ and ‘Ref’. Which can be created and retrieved by id through one of the storage modules.

val map =    RedisStorage.newMap(id)
val vector = CassandraStorage.newVector(id)
val ref =    MongoStorage.newRef(id)

Chat storage: Backed by Redis

Now let’s implement the persistent storage. We start by creating a ‘ChatStorage’ trait allowing us to have multiple different storage backend. For example one in-memory and one persistent.

/**
 * Abstraction of chat storage holding the chat log.
 */
trait ChatStorage extends Actor

Let’s use Redis to implementation the persistent storage. Redis is an excellent storage backend, blazingly fast with a rich data model.

Our ‘RedisChatStorage’ extends the ‘ChatStorage’ trait. The only state it holds is the ‘chatLog’ which is a ‘Vector’ managed by Redis. We give it an explicit id (the String “akka.chat.log”) to be able to retrieve the same vector across remote nodes and/or through server restarts.

It responds to two different messages; ‘ChatMessage’ and ‘GetChatLog’. The ‘ChatMessage’ message handler takes the ‘message’ attribute and appends it to the ‘chatLog’ vector. Here you can see that we are using the ‘atomic { … }’ block to run the vector operation in a transaction. Redis works with binary data so we need to convert the message into a binary representation. Since we are using Strings we just have to invoke ‘message.getBytes(“UTF-8”)’, but if we would have had a richer message that we wanted to persist then we would have had to use one of the Akka’s serialization traits or serializers. You can read more about that here.

The ‘GetChatLog’ message handler retrieves all the messages in the chat log storage inside an atomic block, iterates over them using the ‘map’ combinator transforming them from ‘Array[Byte] to ’String’. Then it invokes the ‘reply(message)’ function that will send the chat log to the original sender; the ‘ChatClient’.

You might rememeber that the ‘ChatServer’ was supervising the ‘ChatStorage’ actor. When we discussed that we showed you the supervising Actor’s view. Now is the time for the supervised Actor’s side of things. First, a supervised Actor need to define a life-cycle in which it declares if it should be seen as a:

‘Permanent’: which means that the actor will always be restarted.
‘Temporary’: which means that the actor will not be restarted, but it will be shut down through the regular shutdown process so the ‘shutdown’ callback function will called.

We define the ‘RedisChatStorage’ as ‘Permanent’ by setting the ‘lifeCycle’ member field to ‘Some(LifeCycle(Permanent))’.

The idea with this crash early style of designing your system is that the services should just crash and then they should be restarted and reset into a stable state and continue from there. The definition of “stable state” is domain specific and up to the application developer to define. Akka provides two callback functions; ‘preRestart’ and ‘postRestart’ that are called right before and right after the Actor is restarted. Both of these functions take a ‘Throwable’, the reason for the crash, as argument. In our case we just need to implement the ‘postRestart’ hook and there re-initialize the ‘chatLog’ member field with a fresh persistent ‘Vector’ from Redis.

/**
 * Redis-backed chat storage implementation.
 */
class RedisChatStorage extends ChatStorage {
  lifeCycle = Some(LifeCycle(Permanent))    

  private var chatLog = RedisStorage.getVector("akka.chat.log")

  log.info("Redis-based chat storage is starting up...")

  def receive = {
    case msg @ ChatMessage(from, message) => 
      log.debug("New chat message [%s]", message)
      atomic { 
        chatLog + message.getBytes("UTF-8")
      }

    case GetChatLog(_) => 
      val messageList = atomic {
       chatLog.map(bytes => new String(bytes, "UTF-8")).toList
      }
      reply(ChatLog(messageList))
  }

  override def postRestart(reason: Throwable) = 
    chatLog = RedisStorage.getVector("akka.chat.log")  
}

The last thing we need to do in terms of persistence is to create a ‘RedisChatStorageFactory’ that will take care of instantiating and resolving the ‘val storage: ChatStorage’ field in the ‘ChatServer’ with a concrete implementation of our persistence Actor.

/**
 * Creates and a RedisChatStorage.
 */
trait RedisChatStorageFactory {
  val storage: ChatStorage = new RedisChatStorage
}

Composing the full Chat Service

We have now created the full functionality for the chat server, all nicely decoupled into isolated and well-defined traits. Now let’s bring all these traits together and compose the complete concrete ‘ChatService’.

/**
 * Object encapsulating the full Chat Service.
 */
object ChatService extends 
  ChatServer with 
  SessionManagement with 
  ChatManagement with 
  RedisChatStorageFactory

Making the ChatService remote

Now that we have the ‘ChatService’ object how do we make it into a remote service that we can use from different nodes?

It is very simple. We only need to do two things. First we need to start up a remote server to run the ‘ChatService’. Then for each client that wants to use the ‘ChatService’ we just need to invoke ‘ChatService.makeRemote’ to get a handle to the remote ‘ChatService’.

Starting the first step. We have two options on how we can start up a remote server. Either start up the ‘RemoteNode’ in some part of the code that runs on the machine you want to run the server on (can just be a simple class with a ‘main’ method).

We start the ‘RemoteNode’ by invoking ‘start’ and passing in the host name and port.

RemoteNode.start("darkstar", 9999)

You can also choose to use the version of ‘start’ that takes a ‘ClassLoader’ as argument if you want to be explicit on through which class loader you want to load the class of the Actor that you want to run as remote service.

The second option is to put your application in a JAR file and drop it into the ‘AKKA_HOME/deploy’ directory and then start up the Akka microkernel. This will deploy your application and start the ‘RemoteNode’ for you. Then you use the ‘AKKA_HOME/config/akka.conf’ configuration file to configure the remote server (among many other things). The microkernel is started up like this:

export AKKA_HOME=...
cd $AKKA_HOME
java -jar $AKKA_HOME/dist/akka-0.6.jar

That was the server part. The client part is just as simple. We only need to tell the runtime system that we want to use the ‘ChatService’ as a remote Actor by invoking the ‘makeRemote(hostname, port)’ function on it. This will instantiate the Actor on the remote host and turn the local Actor instance into a proxy or handle through which we can use the remote Actor transparently with the exact same semantics as if it was a regular local Actor.

That’s it. Now let’s run a sample client session.

ChatService.makeRemote("darkstar", 9999)
ChatService.start

That’s it. Were done. Now we have a, very simple, but scalable, fault-tolerant, event-driven, persistent chat server that can without problem serve a million concurrent users on a regular workstation.

Let’s use it.

Sample client chat session

Now let’s create a simple test runner that logs in posts some messages and logs out.

import se.scalablesolutions.akka.sample.chat._

/**
 * Test runner emulating a chat session.
 */
object Runner {
  // create a handle to the remote ChatService 
  ChatService.makeRemote("localhost", 9999)
  ChatService.start

  def run = {
    val client = new ChatClient("jonas")

    client.login

    client.post("Hi there")
    println("CHAT LOG:\n\t" + client.chatLog.log.mkString("\n\t"))

    client.post("Hi again")
    println("CHAT LOG:\n\t" + client.chatLog.log.mkString("\n\t"))

    client.logout
  }
}

Sample code

All this code is available as part of the Akka distribution. It resides in the ‘./akka-samples/akka-sample-chat’ module and have a ‘README’ file explaining how to run it as well as a Maven ‘pom.xml’ build file so it is easy to build, run, hack, rebuild, run etc. You can also just read the next section for instructions on how to run it.

Or if you rather browse it online.

Run it

First we need to start up Redis.

Download Redis from here.
Step into the distribution.
Build: ‘make install’.
Run: ‘./redis-server’.

For details on how to set up Redis server have a look here.

Download and build Akka

Download Akka from http://github.com/jboner/akka/downloads.
Set ‘AKKA_HOME’ environment variable to the root of the Akka distribution.
Open up a shell and step into the Akka distribution root folder.
Build Akka by invoking ‘mvn install -Dmaven.test.skip=true’. This will also bulid the sample application and deploy it to the ‘$AKKA_HOME/deploy’ directory.

Run the microkernel

export AKKA_HOME=...
cd $AKKA_HOME
java -jar ./dist/akka-0.6.jar

Run a sample chat session

Now start up a new shell and go down into the ‘./akka-samples/akka-sample-chat’ directory.
Invoke ‘mvn scala:console -o’. This will give you a Scala REPL (interpreter) with the chat application and all its dependency JARs on the classpath.
Simply paste in the whole code block with the ‘Runner’ object above and invoke ‘Runner.run’. This run a simulated client session that will connect to the running server in the microkernel.
Invoke ‘Runner.run’ again and again…

Now you could test client reconnect by killing the running microkernel and start it up again. See the client reconnect take place in the REPL shell.

That’s it. Have fun.

Onward

There is much much more to Akka than what we have covered in this article. For example Active Objects, Cluster Membership API, a Comet module, REST (JAX-RS) integration, a Security module, AMQP integration, Spring integration, Google Guice integration, Lift integration, a rich Transaction API, tons of configuration possibilities etc.

Asynchronous Event Sourcing using Actors

2009-02-12T00:00:00+00:00

Asynchronous Event Sourcing using Actors

12 Feb 2009

Introduction

There has been some discussions lately about Event Sourcing. For example, Greg Young recently discussed how they were using Event Sourcing and explicit state transitions together with Domain-Driven Design (DDD) to build a highly scalable and loosely coupled system.

So what is Event Sourcing? Martin Fowler wrote an excellent article about some years ago and there is no use repeating it here, so please read (or at least skim) that article before reading further.

What I will do in this article is to show you how you can implement Event Sourcing using asynchronous message-passing based on actors. Actors are generally an excellent paradigm to implement asynchronous event-based systems and they allow you to easily get explicit state transitions working nicely together with an immutable domain model. This gives a concurrent system that scales very well, with the side-effect/feature of Eventual Consistency.

Domain model

I will reuse the example Martin Fowler used in his article but rewrite it using Scala Actors. So without further ado let’s start hacking. Martin’s example implements a simple Ship management system.

First, let’s define the simplistic domain model; Ship, Port and Country.

The Ship class is worth discussing a bit. It is an actor, which means that it is an isolated ‘lightweight process’ with its own state, which is only accessible and modifiable using messages (in our case, events). The Ship actor responds to four different events; set arrival and departure, query for current port and finally reset the state.

class Ship(val name: String, val home: Port) extends Actor {

  def act = loop(home)

  private def loop(current: Port) {
    react {
      case ArrivalEvent(time, port, _) => 
        println(toString + " ARRIVED  at port   " + port + " @ " + time)
        loop(port)

      case DepartureEvent(time, port, _) => 
        println(toString + " DEPARTED from port " + port  + " @ " + time)
        loop(Port.AT_SEA)

      case Reset => 
        println(toString + " has been reset")
        loop(home)

      case CurrentPort => 
        reply(current)
        loop(current)

      case unknown => 
        error("Unknown event: " + unknown)
    }
  }

  override def toString = "Ship(" + name + ")"
}

class Port(val city: String, val country: Country) {
  override def toString = "Port(" + city + ")"  
}
object Port {
  val AT_SEA = new Port("AT SEA", Country.AT_SEA)
}

case class Country(val name: String)
object Country {
  val US = new Country("US")
  val CANADA = new Country("CANADA")
  val AT_SEA = new Country("AT_SEA")
}

Note: In this example I have been managing the state in the actors (Ship and EventProcessor) by passing it on in the recursive ‘loop’, using stack-confinement. This is a slick technique but not possible if you need to persist the state in some way, either using something like Terracotta or store it in a database. Then you would have to put the state in private field(s) in the actor, something that will not affect the correctness or performance.

Events

Now let’s define our events, implementing the explicit state transitions DepartureEvent and ArrivalEvent. In Scala these are best defined as ‘case classes’ which supports pattern matching and attribute destructing. These two events encapsulate their state transition in the ‘process’ method. We also define one event for asking the Ship for its current port and one for resetting its state to its “home” port.

sealed abstract case class Event

abstract case class StateTransitionEvent(val occurred: Date) 
  extends Event {
  val recorded = new Date
  def process: Unit
}

case class DepartureEvent(val time: Date, val port: Port, val ship: Ship) 
  extends StateTransitionEvent(time) {
  override def process = ship ! this
}

case class ArrivalEvent(val time: Date, val port: Port, val ship: Ship) 
  extends StateTransitionEvent(time) {
  override def process = ship ! this
}

case object Reset extends Event

case object CurrentPort extends Event

Event processor

Finally, let’s define the event processor. This class is an actor which responds to any event that is a subtype of StateTransitionEvent, e.g. either DepartureEvent or ArrivalEvent. It also holds a history list (‘log’) with all events that it has processed. Something that we will make use of later on.

class EventProcessor extends Actor {
  def act = loop(Nil)

  private def loop(log: List[StateTransitionEvent]) {
    react {
      case event: StateTransitionEvent => 
        event.process
        loop(event :: log)

      case unknown => 
        error("Unknown event: " + unknown)
    }
  }
}

Test run 1

Now we have the basis for our Ship Management Event Sourcing framework. Let’s create some tests to drive the thing. Since each event submission is processed asynchronously we have to interleave them with calls to ‘Thread.sleep(500)’ in order to see what is going on.

class ActorBasedEventSourcingTest {

  private var shipKR: Ship = _
  private var portSFO, portLA, portYYV: Port = _
  private var processor: EventProcessor = _

  def setup = {
    processor = new EventProcessor
    processor.start
    
    portSFO = new Port("San Francisco", Country.US)
    portLA = new Port("Los Angeles", Country.US)
    portYYV = new Port("Vancouver", Country.CANADA)

    shipKR = new Ship("King Roy", portYYV)
    shipKR.start

    this
  }

  def tearDown = { 
    processor.exit
    this
  }

  def arrivalSetsShipsLocation = {
    println("\n===> arrivalSetsShipsLocation")

    processor ! DepartureEvent(new Date(2009, 2, 1), portSFO, shipKR)
    Thread.sleep(500)

    processor ! ArrivalEvent(new Date(2009, 2, 3), portSFO, shipKR)
    Thread.sleep(500)

    assert(portSFO == (shipKR !? CurrentPort))
    this
  }

  def departurePutsShipOutToSea = {
    println("\n===> departurePutsShipOutToSea")

    processor ! DepartureEvent(new Date(2009, 2, 4), portLA, shipKR)
    Thread.sleep(500)

    assert(Port.AT_SEA == (shipKR !? CurrentPort))
    this
  }

  def smallTrip = {
    println("\n===> smallTrip")

    processor ! ArrivalEvent(new Date(2009, 2, 5), portLA, shipKR)
    Thread.sleep(500)

    processor ! DepartureEvent(new Date(2009, 2, 6), portYYV, shipKR)
    Thread.sleep(500)

    processor ! ArrivalEvent(new Date(2009, 2, 8), portYYV, shipKR)
    Thread.sleep(500)

    processor ! DepartureEvent(new Date(2009, 2, 9), portSFO, shipKR)
    Thread.sleep(500)

    processor ! ArrivalEvent(new Date(2009, 2, 11), portSFO, shipKR)
    Thread.sleep(500)

    assert(portSFO == (shipKR !? CurrentPort))
    this
  }
}

(new ActorBasedEventSourcingTest)
  .setup
  .arrivalSetsShipsLocation
  .departurePutsShipOutToSea
  .smallTrip
  .tearDown

Which gives us the following output:

===> arrivalSetsShipsLocation
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909

===> departurePutsShipOutToSea
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

===> smallTrip
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

Pretty nice.

But now, let’s start to take advantage of the event persistence. Let’s implement event replay.

Replay

Implementing replay is actually very simple now when we have an event log. First we define a Replay event.

case object Replay extends Event

Then we need the EventProcessor to respond to this new event by first reversing the order of the event log (since functional lists are concatenated in reverse order) and then for each event invoke ‘process’.

class EventProcessor extends Actor {
  def act = loop(Nil)

  private def loop(log: List[DomainEvent]) {
    react {
       ...

      case Replay => 
        log.reverse.foreach(_.process) 
        loop(log)
    }
  }
}

Done deal.

Test run 2

Let’s try it out by adding a new test method to our suite. Here we make use of the Reset event which resets the ship to its initial state before replaying all state transitions.

def resetAndReplayEventLog = {
  println("\n===> resetAndReplayEventLog")

  shipKR ! Reset

  processor ! Replay
  Thread.sleep(500)

  assert(portSFO == (shipKR !? CurrentPort))
  this
}

(new ActorBasedEventSourcingTest)
  .setup
  .arrivalSetsShipsLocation
  .departurePutsShipOutToSea
  .smallTrip
  .resetAndReplayEventLog // new test method
  .tearDown

This yields the following output:

===> arrivalSetsShipsLocation
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909

===> departurePutsShipOutToSea
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

===> smallTrip
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

===> resetAndReplayEventLog
Ship(King Roy) has been reset
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

Replay up to a specific point in time

Finally, (my last example, I promise) let’s add the possibility of replaying the event log up to a specific date to get a snapshot of the system’s state at a particular point in time.

You know the drill by now, first define a new event; ReplayUpTo, holding the date.

case class ReplayUpTo(date: Date) extends Event

Here the event processor first reverses the log, then it applies a filter to the list which filters out all events that has been created after the date specified and finally run ‘process’ on all events in the resulting filtered list.

class EventProcessor extends Actor {
  def act = loop(Nil)

  private def loop(log: List[DomainEvent]) {
    react {
       ...

      case ReplayUpTo(date) => 
        log.reverse.filter(_.occurred.getTime <= date.getTime).foreach(_.process) 
        loop(log)
    }
  }
}

Test run 3

So we add a last test method to our suite, one that replays all events created in earlier tests up to the date ‘2009/2/4’.

def resetAndReplayEventLogUpToDate = {
  println("\n===> resetAndReplayEventLogUpToDate")

  shipKR ! Reset

  processor ! ReplayUpTo(new Date(2009, 2, 4))
  Thread.sleep(500)

  assert(Port.AT_SEA == (shipKR !? CurrentPort))
  this
} 

(new EventSourcingWithActorsTest)
  .setup
  .arrivalSetsShipsLocation
  .departurePutsShipOutToSea
  .smallTrip
  .resetAndReplayEventLog
  .resetAndReplayEventLogUpToDate // new test method
  .tearDown

This yield the following output.

===> arrivalSetsShipsLocation
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909

===> departurePutsShipOutToSea
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

===> smallTrip
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

===> resetAndReplayEventLog
Ship(King Roy) has been reset
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Los Angeles) @ Fri Mar 05 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Vancouver) @ Sat Mar 06 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(Vancouver) @ Mon Mar 08 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Tue Mar 09 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Thu Mar 11 00:00:00 CET 3909

===> resetAndReplayEventLogUpToDate
Ship(King Roy) has been reset
Ship(King Roy) DEPARTED from port Port(San Francisco) @ Mon Mar 01 00:00:00 CET 3909
Ship(King Roy) ARRIVED  at port   Port(San Francisco) @ Wed Mar 03 00:00:00 CET 3909
Ship(King Roy) DEPARTED from port Port(Los Angeles) @ Thu Mar 04 00:00:00 CET 3909

That’s all there’s to it. We have only scratched the surface on what can be done with asynchronous Event Sourcing, and as in all these kind of articles, the example is almost too simplistic to fully understand the power and flexibility of the solution. But I hope that you have understood the underlying principle enough to be able to apply it to a real-world enterprise system.

Slides for my Pragmatic Real-World Scala presentation

2009-01-30T00:00:00+00:00

Slides for my Pragmatic Real-World Scala presentation

30 Jan 2009

I have uploaded the slides for my ‘Pragmatic Real-World Scala’ talk that I gave at Jfokus yesterday to slideshare.

Enjoy.

Pragmatic Real-World Scala (short version)

Added Comments to Blog

2009-01-30T00:00:00+00:00

Added Comments to Blog

30 Jan 2009

Many people have asked for it, so I have decided to add comments to my blog again.

Thank you Disqus.

Let the discussion continue.

Back To Consulting

2009-01-10T00:00:00+00:00

Back To Consulting

10 Jan 2009

The last year has been a ride.

Startup in finance business, green field development, challenging and interesting problem domain, been pushing Scala to its limits in a real-world production setting. Its been a lot of fun and a great learning experience. (I have written some about the way we have used Scala in the “Real-World Scala” series of blog posts, check the archives if you are curious.)

But now its all over. Zero cash flow in. Knocked out by the financial crisis. To bad, we had a great product coming. But not much to do.

The good news is that I am back in the consulting business. Rewrote and redesigned my company site to mark the beginnning of a new era…well, at least a “new” job.

Check it out and let me know if you need help :-)

http://scalablesolutions.se

Blogging Like a Hacker using Git and Jekyll

2009-01-07T00:00:00+00:00

Blogging Like a Hacker using Git and Jekyll

7 Jan 2009

For the last year and have been falling in love with Git. Git is truly an amazing…..tool. I was going to say Source Code Management System (SCM), but that ain’t fair, Git is so much more. Git deserves a post on its own, however in this one I’m going to talk about one of the things it can help you with; to blog like a hacker.

For the last year I have not only used Git but have hosted my whole professional life on GitHub. GitHub started as a server with Git repositories but have since then grown into a thriving community with a lot of interesting and cool features and side projects up its sleeve. One of these “features” is Jekyll. Jekyll is a minimalistic blog engine based upon Git. It allows you to write all your blog posts in either Textile, Markdown or HTML while having Git (and GitHub) take care of storage, versioning etc.

It is dead simple. Generates everything into static HTML, which I think is great. And as with all viral good open source, there are already a bunch of plug-ins such as for example converting your MT, WordPress, Typo etc blogs into Textile/Markdown for Jekyll to consume. The thing I like most is that everything is plain text, residing in your Git repository (e.g. on your file system). This means that I can write my blog post in Emacs, commit the changes using the Emacs (emacs-git), push it up to GitHub using Emacs, generate my site and FTP it up to my server from Emacs (replace Emacs with your favorite editor). Never been easier (or more fun) to blog. Hopefully this will make me do it more often.

For a sample of a Jekyll-powered blog, take a look at mine: http://jonasboner.com

Real-World Scala: Fault-tolerant Concurrent Asynchronous Components

2008-12-11T00:00:00+00:00

Real-World Scala: Fault-tolerant Concurrent Asynchronous Components

Introduction

In a previous post I wrote about Scala OTP, an initial attempt to bring the power or Erlang OTP, in particular its supervisor hierarchies and generic server to the Scala Actors library. OTP is one of the key parts in the Erlang success story and is in my opinion a requirement for Scala Actors to succeed in the real world.

Actors can simplify concurrent programming and reasoning immensely and I believe that Scala Actors is a key piece in the future Java concurrency puzzle. However, programming with actors and with explicit message passing and message dispatch loops can feel a bit unnatural and unnecessary verbose for Java developers that are used to regular OO method invocations and synchronous control flow.

For example, if we want to be able to pass a single message from one actor to the next we have to define two things.

A message with optional payload.

case class MyMessage(payload: AnyRef)

A message dispatch matching loop (partial function) in the receiving actor.

def act = {
  loop {
    react {
      case MyMessage(payload) =&gt; 
        ...  // do something with payload
      case _ => 
        ... // default case
    }
  }
}

It is also complicated to do things like stateful control flow, e.g. send message to A, wait for reply, then send message to B, wait for reply, then do C. (this can in some ways be addressed using monad continuations, but is still not simple and intuitive to use).

Don’t get me wrong. Even though it has its “flaws”, using actors (message-passing concurrency) for concurrent programming is still so much simpler than using threads and locks (shared-state concurrency).

Active Objects (Concurrent Asynchronous Components)

In this post I’ll outline a little library that we have been using that tries to unify Scala Actors, Scala OTP (supervisor hierarchies for fault tolerance) and regular OO method dispatch into an asynchronous component framework that I think can be best described as Active Objects.

Each so-called Active Object (concurrent asynchronous component) is a GenericServer that is managed by a Supervisor, either in isolation or as part of a supervisor hierarchy/tree. E.g. each component is fully fault-tolerant. For more information about how supervisor hierarchies work, read this post. Each component consists of an interface (trait) and a regular Scala class as implementation for the interface. The catch is that each component has to be instantiate through a factory. Let’s first take a look at the API and how to use this thing before we dig into the actual implementation.

Usage

Here is a simple example of a component that is using default supervisor management (which among other things mean that it is not part of a supervisor tree/hierarchy, but is still managed and will be restarted upon failure). We start with the component interface and implementation.

  trait Foo {
    def foo(msg: String): String    
    @oneway def bar(msg: String)
  }

  class FooImpl extends Foo {
    def foo(msg: String): String = { println("foo: " + msg); msg } 
    def bar(msg: String) = println("bar: " + msg)
  }

Now let’s instantiate this component. The integer 1000 specifies the time interval an (asynchronous) invocation should have before timing out.

  val foo = ActiveObject.newInstance[Foo](classOf[Foo], new FooImpl, 1000)

Now we can use this component as any regular instance of Foo. The difference is that invocations are now asynchronously dispatched in an event-based actor with its return value is wrapped in a Future, this emulates synchronous behavior but is non-blocking. The exception to this behavior is if a method is annotated with the @scala.actors.annotation.oneway annotation, then it returns immediately. All components created through the factory are fault-tolerant GenericServers managed by a Supervisor, which means that they will be restarted upon failure using the restart scheme the supervisor has defined it under.

   // use as usual
   foo.foo("foo")
   foo.bar("bar") // returns immediately since annotated with @oneway

Now, if I would like to have more control over the Supervisor configuration and/or want to compose different components into supervisor hierarchies, then we can use another factory method along with a method called start that allows us to pass in a Supervisor configuration (as defined by the Scala OTP Supervisor).

Let’s take a look at a full example:

  trait Foo {
    def foo(msg: String): String    
    @oneway def bar(msg: String)
  }

  class FooImpl extends Foo {
    val bar: Bar = new BarImpl 
    def foo(msg: String): String = { println("foo: " + msg); msg } 
    def bar(msg: String) = bar.bar(msg)
  }

  trait Bar {
    def bar(msg: String)
  }

  class BarImpl extends Bar {
    def bar(msg: String) = println("bar: " + msg)
  }

First create proxies (GenericServers) for our services.

  val fooProxy = new ActiveObjectProxy(new FooImpl, 1000)
  val barProxy = new ActiveObjectProxy(new BarImpl, 1000)

Then let’s configure the GenericServer(s) by creating a list of GenericServer configurations (defining lifecycles, restart strategies etc.). This configuration is passed into the ActiveObject.supervise method which starts up the Supervisor which starts up all GenericServer’s according to their configurations before returning the Supervisor instance (which can be used for management of the components).

val supervisor = 
  ActiveObject.supervise(
    RestartStrategy(AllForOne, 3, 100),
    Component(
      fooProxy,
      LifeCycle(Permanent, 100)) ::
    Component(
      barProxy,
      LifeCycle(Permanent, 100))
    :: Nil)

Create and use the components as in the previous example..

  val foo = ActiveObject.newInstance[Foo](classOf[Foo], fooProxy)
  val bar = ActiveObject.newInstance[Bar](classOf[Bar], barProxy)

  foo.foo("foo ") 
  bar.bar("bar ")

That pretty much sums it up. So how is this implemented?

Implementation

The first thing we need to do is to define an invocation context, holding arguments, method to be invoked as well as the target instance.

  case class Invocation(val method: Method, val args: Array[AnyRef], val target: AnyRef) {
    def invoke: AnyRef = method.invoke(target, args:_*)
    override def toString: String = "Invocation [method: " + method.getName + ", args: " + args + ", target: " + target + "]"
    override def hashCode(): Int = { ... }
    override def equals(that: Any): Boolean = { ... }
  }

The second thing we need to do is to create a dynamic proxy wrapping the asynchronous dispatch. This proxy holds an instance of an actor dressed up in a GenericServer. Now comes the little trick; we will now use the Invocation context as the message to our GenericServer actor.

As you can see in the code for the dispatcher we are defining a partial function that is defined for two different messages; Invocation and 'exit. If the Invocation message is received, then we invoke the invocation context, e.g. the method on the implementation instance and are returning the result to the caller using reply(..). If we receive an 'exit message and we terminate the GenericServer.

The call flow for this proxy is as follows. When a regular synchronous method invocation is made on the service interface or component is redirected to the invoke(..) method. In this method we simply create an invocation context for this specific method invocation and sends it as a message to our GenericServer (server). Here we have two options. If the target method is annotated with the @scala.actors.annotation.oneway annotation then we fire the message and forget by invoking server ! invocation, else we are sending the message using the server !!! invocation operator which returns a Future which we then wait on (emulating a synchronous method call).

class ActiveObjectProxy(val target: AnyRef, val timeout: Int) extends InvocationHandler {
  private val oneway = classOf[scala.actors.annotation.oneway]
 
  private[ActiveObjectProxy] object dispatcher extends GenericServer {
    override def body: PartialFunction[Any, Unit] = {
      case invocation: Invocation =>
        try {
          reply(ErrRef(invocation.invoke))
        } catch {
          case e: InvocationTargetException =&gt; reply(ErrRef({ throw e.getTargetException }))
          case e =&gt; reply(ErrRef({ throw e }))
        }
      case 'exit =&gt; exit; reply()
      case unexpected => throw new ActiveObjectException("Unexpected message to actor proxy: " + unexpected)
    }
  }
 
  private[component] val server = new GenericServerContainer(target.getClass.getName, () => dispatcher)
  server.setTimeout(timeout)
  
  def invoke(proxy: AnyRef, m: Method, args: Array[AnyRef]): AnyRef = invoke(Invocation(m, args, target))
 
  def invoke(invocation: Invocation): AnyRef = {
    if (invocation.method.isAnnotationPresent(oneway)) server ! invocation // fire and forget
    else {
      val result: ErrRef[AnyRef] = server !!! (invocation, ErrRef({ throw new ActiveObjectInvocationTimeoutException("proxy invocation timed out after " + timeout + " milliseconds") }))
      result() // wait on future for result
    }
  }
}

Finally we create a factory which will do the Supervisor configuration, wiring and startup.

object ActiveObject {
 
  def newInstance[T](intf: Class[T] forSome {type T}, target: AnyRef, timeout: Int): T = {
    val proxy = new ActiveObjectProxy(target, timeout)
    supervise(proxy)
    newInstance(intf, proxy)
  }
 
  def newInstance[T](intf: Class[T] forSome {type T}, proxy: ActiveObjectProxy): T = {
    Proxy.newProxyInstance(
      proxy.target.getClass.getClassLoader,
      Array(intf),
      proxy).asInstanceOf[T]
  }
 
  def supervise(restartStrategy: RestartStrategy, components: List[Component]): Supervisor = {
    object factory extends SupervisorFactory {
      override def getSupervisorConfig: SupervisorConfig = {
        SupervisorConfig(restartStrategy, components.map(c => Worker(c.component.server, c.lifeCycle)))
      }
    }
    val supervisor = factory.newSupervisor
    supervisor ! scala.actors.behavior.Start
    supervisor
  }
 
  private def supervise(proxy: ActiveObjectProxy): Supervisor =
    supervise(
      RestartStrategy(OneForOne, 5, 1000),
      Component(
        proxy,
        LifeCycle(Permanent, 100))
      :: Nil)
}

That’s pretty much all there is to it. The code is available as part of the Scala OTP library:

http://github.com/jboner/scala-otp/tree/master/component

Check it out by invoking: git clone git://github.com/jboner/scala-otp.git

All ideas, improvements, patches etc. are most welcome.

Real-World Scala: Managing Cross-Cutting Concerns using Mixin Composition and AOP

2008-12-09T00:00:00+00:00

Real-World Scala: Managing Cross-Cutting Concerns using Mixin Composition and AOP

In a previous post I showed you how you could use mixin composition and self type annotations to enable Dependency Injection (DI). Mixin composition is an extremely powerful tool that you can utilize in many different ways to enable modular and reusable code. In this post I’ll try to show you how you can use it to solve the problem of crosscutting concerns using AOP/interceptor-style composition.

Crosscutting concerns and AOP

OOP has given us tools to reduce software complexity by introducing concepts like inheritance, abstraction, and polymorphism. However, developers face daily problems in software design that can’t be solved easily using OOP. One of these problems is how to handle cross-cutting concerns in the application.

So what is a cross-cutting concern? A concern is a particular concept or area of interest. For example, in an ordering system the core concerns could be order processing and manufacturing, while the system concerns could be transaction handling and security management. A cross-cutting concern is a concern that affects several classes or modules, a concern that is not well localized and modularized.

Symptoms of a cross-cutting concern are:

Code tangling – when a module or code section is managing several concerns simultaneously
Code scattering – when a concern is spread over many modules and is not well localized and modularized

These symptoms affect software in various ways; for example, they make it harder to maintain and reuse software as well as harder to write and understand.

Aspect-Oriented Programming (AOP) tries to solve these problems by introducing the concept of separation of concerns, in which concerns can be implemented in a modular and well-localized way. AOP solves this by adding an extra dimension to the design space, and introduces constructs that allow us to define the cross-cutting concerns, to lift them out into a new dimension and package them in a modular way.

We are currently using two different types of interceptors (aspects if you like):

Mixin composition stacks — a limited but sometimes very useful approach
Generic interceptors/aspects using a pointcut pattern language

Mixin composition stacks

Mixin composition stacks is a core language feature of Scala and is similar to Rickard Oberg’s idea on using the so-called Abstract Schema pattern for type-safe AOP in plain Java. (This is a very contrived example that probably shows that don’t know a zip about dogs, but please bare with me.)

First let’s define a couple of interfaces; Dog and DogMood modeled as a mixins (in this case without an implementation so similar to Java’s interface):

trait Dog {
  def greet(me: Human)
}

trait DogMood extends Dog {
  def greet(me: Human) {
    println(me.sayHello)
  }
}

Now let’s define two different mixin “interceptors” that implement these interfaces. The first one defining an angry dog and the other one a hungry dog:

trait AngryDog extends DogMood {
  abstract override def greet(me: Human) {
    println("Dog: Barks @ " + me)
    super.greet(me)
  }
}

trait HungryDog extends DogMood {
  abstract override def greet(me: Human) {
    super.greet(me)
    println("Dog: Bites " + me)
  }
}

As we can see in this example they both override the Mood.greet method. If we look more closely we can see that they follow the same pattern:

Enter method (greet)
Do something
Invoke the same method on super (super.greet)
Do something else

The trick here is in the semantics of the call to super. Here Scala will invoke the next mixin in a stack of mixins, e.g. the same method in the “next” mixin that have been mixed in. Exactly what f.e. AspectJ does in its proceed(..) method and what Spring does in its interceptors.

Now let’s fire up the Scala REPL and create a component based on the Dog interface. Scala’s mixin composition can take place when we instantiate an instance, e.g. it allows us to mix in functionality into specific instances that object creation time for specific object instances.

scala> val dog = new Dog with AngryDog with HungryDog 
stuff2: Dog with AngryDog with HungryDog = $anon$1@1082d45

scala> dog.greet(new Human("Me"))
Dog: Barks @ Me
Me: Hello doggiedoggie
Dog: Bites Me

As you can see the call to Dog.greet is intercepted by the different moods that are added to the dog at instantiation time.

Interceptors like this are as you can see not generically reusable since they are tied to a specific interface, however if well designed can be a pretty powerful technique. It has the advantage that everything is statically compiled and type-checked by the Scala compiler

Generic pointcut-based aspects

The main usage of generic aspects is for implementing infrastructure concerns such as logging, transaction demarcation, security, clustering, persistence etc.

In order to create a framework for implementing generic aspects, the first thing we need to do is to define an invocation context, holding arguments, method to be invoked as well as the target instance.

case class Invocation(val method: Method, val args: Array[AnyRef], val target: AnyRef) {
  def invoke: AnyRef = method.invoke(target, args:_*)
  override def toString: String = "Invocation [method: " + method.getName + ", args: " + args + ", target: " + target + "]"
  override def hashCode(): Int = { ... }
  override def equals(that: Any): Boolean = { ... }
}

The second thing that we need to do is to create a base Interceptor trait. This interface defines two different pointcut matching methods. The first one matches a precompiled AspectJ pointcut expression using the PointcutParser in AspectJ. This allows defining interceptors matches AspectJ compatible (method) pointcut expressions. The second matcher matches methods or classes that is annotated with a specific annotation.

trait Interceptor {
  protected val parser = PointcutParser.getPointcutParserSupportingAllPrimitivesAndUsingContextClassloaderForResolution

  protected def matches(pointcut: PointcutExpression, invocation: Invocation): Boolean = {
    pointcut.matchesMethodExecution(invocation.method).alwaysMatches ||
    invocation.target.getClass.getDeclaredMethods.exists(pointcut.matchesMethodExecution(_).alwaysMatches) ||
    false
  }

  protected def matches(annotationClass: Class[T] forSome {type T <: Annotation}, invocation: Invocation): Boolean = {
    invocation.method.isAnnotationPresent(annotationClass) ||
    invocation.target.getClass.isAnnotationPresent(annotationClass) ||
    false
  }

  def invoke(invocation: Invocation): AnyRef
}

The last thing we need to do is to create a factory method allows us to wire in our interceptors, declarative, in a seamless fashion. This factory is using the plain old Java Dynamic Proxy API to create a proxy for our base components.

object ManagedComponentFactory {
  def createComponent[T](intf: Class[T] forSome {type T}, proxy: ManagedComponentProxy): T =
    Proxy.newProxyInstance(
      proxy.target.getClass.getClassLoader,
      Array(intf),
      proxy).asInstanceOf[T]
}

class ManagedComponentProxy(val target: AnyRef) extends InvocationHandler {
  def invoke(proxy: AnyRef, m: Method, args: Array[AnyRef]): AnyRef = invoke(Invocation(m, args, target))
  def invoke(invocation: Invocation): AnyRef = invocation.invoke
}

Just using this factory pass is won’t do any wiring for us, which is actually good since if we would use the dynamic proxy the old-fashioned way and we would have it to invoke each interceptor explicitly using reflection. But we can do better than that. Instead we will let the Scala compiler statically compiled in an interceptor stack with all our interceptors. This is best explained with an example.

In this example we will define a couple of simple services called Foo and Bar along with their implementations. We will then implement two different infrastructure in interceptors; logging and transaction demarcation.

Let’s first define the service.

  import javax.ejb.{TransactionAttribute, TransactionAttributeType}

  trait Foo {
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    def foo(msg: String)
    def bar(msg: String)
  }

  class FooImpl extends Foo {
    val bar: Bar = new BarImpl
    def foo(msg: String) = println("msg: " + msg)
    def bar(msg: String) = bar.bar(msg)
  }

  trait Bar {
    def bar(msg: String)
  }

  class BarImpl extends Bar {
    def bar(msg: String) = println("msg: " + msg)
  }

Now let’s define a logging interceptor. Both of these interceptors are just mockups, since the actual implementation is not really of interest. The logging interceptor is defined using a standard AspectJ pointcut while the transaction interceptor is wired to a specific annotation.

  trait LoggingInterceptor extends Interceptor {
    val loggingPointcut = parser.parsePointcutExpression("execution(* *.bar(..))")

    abstract override def invoke(invocation: Invocation): AnyRef = 
      if (matches(loggingPointcut , invocation)) {
        println("=====> Enter: " + invocation.method.getName + " @ " + invocation.target.getClass.getName)
        val result = super.invoke(invocation)
        println("=====> Exit: " + invocation.method.getName + " @ " + invocation.target.getClass.getName)
        result
      } else super.invoke(invocation)
  }

  trait TransactionInterceptor extends Interceptor {
    val matchingJtaAnnotation = classOf[javax.ejb.TransactionAttribute]

    abstract override def invoke(invocation: Invocation): AnyRef = 
      if (matches(matchingJtaAnnotation, invocation)) {
        println("=====> TX begin")
        try {
          val result = super.doStuff
          println("=====> TX commit")
          result     
        } catch {
          case e: Exception => 
            println("=====> TX rollback ")
        } 
      } else super.invoke(invocation)
  }

Now let’s do the wiring. Here we are using dynamic proxy-based factory that we implemented because you can see, the actual wiring on the interceptor stack is done using Scala mixing composition and therefore has all its benefits, like compiler type checking and enforcement, the speed of statically compiled code, refactoring safety etc.

  var foo = ManagedComponentFactory.createComponent[Foo](
    classOf[Foo],
    new ManagedComponentProxy(new FooImpl)
      with LoggingInterceptor
      with TransactionInterceptor)

  foo.foo("foo")
  foo.bar("bar")
 }

This will produce the following output:

=====> TX begin
msg: foo
=====> TX commit
=====> Enter: bar @ FooImpl
msg: bar
=====> Exit: bar @ FooImpl

So this wraps it up. I hope that you have learned a little bit about how powerful mixin composition in Scala is and how it can be used to write modular and reusable components with little effort.

This is working fine for us, but there is definitely room for improvement. For example, runtime matcher in the interceptor is fast enough for the annotation matching (only a boolean check) but the AspectJ pointcut matcher is a bit slower since it has to do some more work. This might turn out be a problem or not, most infrastructure services (like persistence and security) performs quite a lot to work and in these cases the overhead over the interceptor of matching will not affect the overall performance much, but in other cases (such as logging or auditing) it might. We are so far only use the annotation matching, so it has not turned out to be a problem so far. However, if it turns out to be a performance bottleneck then we will most likely switch to using my old AspectWerkz AWProxy to get rid of all the Java reflection code and runtime matching.

For those that are interested, here is the actual JTA transaction demarcation interceptor that we are using in production (implementing all the EJB transaction semantics).

trait EjbTransactionInterceptor extends Interceptor with TransactionProtocol {
  val matchingJtaAnnotation = classOf[javax.ejb.TransactionAttribute]

  abstract override def invoke(invocation: Invocation): AnyRef = if (matches(matchingJtaAnnotation, invocation)) {
    val txType = getTransactionAttributeTypeFor(invocation.target.getClass, invocation.method)
    if (txType == TransactionAttributeType.REQUIRED)           withTxRequired { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.REQUIRES_NEW)  withTxRequiresNew { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.MANDATORY)     withTxMandatory { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.NEVER)         withTxNever { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.SUPPORTS)      withTxSupports { super.invoke(invocation) }
    else if (txType == TransactionAttributeType.NOT_SUPPORTED) withTxNotSupported { super.invoke(invocation) }
    else super.invoke(invocation)
  } else super.invoke(invocation)
}

Reward Failure

2008-10-14T00:00:00+00:00

Reward Failure

Alex Miller has written a very important post on the importance of failure, putting, what has been one of my guiding principles in leadership and working environment building, in words.

It can’t be emphasized enough that for a company to be a leader and not a follower one of the most important things is to foster an environment that encourages and rewards failure – as a potential outcome of taking risks, trying crazy ideas out and out-of-the-box-thinking. It is only in a working environment where the fear of failing has been eliminated that the employees are set free to create amazing things.

This was one of the things that I loved most while working for Terracotta, an amazing place to be working at, and one of the reason why it has managed to hire and keep so many brilliant developers and visionaries.

Real-World Scala: Dependency Injection (DI)

2008-10-06T00:00:00+00:00

Posted: 2008-10-06

In this second post in the Real-World Scala series I am going to discuss how to implement/achieve Depenency Injection (DI) in Scala. Scala is a very rich and deep language that gives you several ways of doing DI solely based on language constructs, but nothing prevents you from using existing Java DI frameworks, if that is preferred.

Using the Cake Pattern

The current strategy we are using is based on the so-called Cake Pattern. This pattern is first explained in Martin Oderskys’ paper Scalable Component Abstractions (which is an excellent paper that is highly recommended) as the way he and his team structured the Scala compiler. But rather than trying to explain the pattern and how it can be used to implement DI in plain English let’s take a look at some (naive) sample code (loosely based on our production code).

Note:
I will try to explain things in steps which I refactor towards the final version (this is only to help with the understanding), so please wait with yelling: “This sucks!”, until you have read and understood the final version (after which you are of course allowed come with any criticism/praise/suggestions/ideas you feel is necessary). Also, the sample code will, as in all these kind of examples, look like an insanely complicated way of doing almost nothing, but bare with me and try to envision real services in a large production system and how it applies there.

First, let’s create a UserRepository (DAO) implementation.

// a dummy service that is not persisting anything
// solely prints out info
class UserRepository {
  def authenticate(user: User): User = { 
    println("authenticating user: " + user)
    user
   }
  def create(user: User) = println("creating user: " + user)
  def delete(user: User) = println("deleting user: " + user)
}

Here we could have split up the implementation in a trait interface and its implementation, but in order to keep things simple I didn’t see the need.

Now let’s create a user service (also a dummy one, merely redirecting to our repository).

class UserService {
  def authenticate(username: String, password: String): User = 
    userRepository.authenticate(username, password)  

  def create(username: String, password: String) = 
    userRepository.create(new User(username, password))

  def delete(user: User) = All is statically typed.  
    userRepository.delete(user)
}

Here you can see that we are referencing an instance of the UserRepository. This is the dependency that we would like to have injected for us.

Ok. Now the interesting stuff starts. Let’s first wrap the UserRepository in an enclosing trait and instantiate the user repository there.

trait UserRepositoryComponent {
  val userRepository = new UserRepository
  class UserRepository {
    def authenticate(user: User): User = { 
      println("authenticating user: " + user)
      user
    }
    def create(user: User) = println("creating user: " + user)
    def delete(user: User) = println("deleting user: " + user)
  }
}

This simply creates a component namespace for our repository. Why? Stay with me and I’ll show you how to make use of this namespace in a second.

Now let’s look at the UserService, the user of the repository. In order to declare that we would like to have the userRepository instance injected in the UserService we will first do what we did with the repository above; wrap the it in an enclosing (namespace) trait and use a so-called self-type annotation to declare our need for the UserRepository service. Sounds more complicated than it is. Let’s look at the code.

// using self-type annotation declaring the dependencies this 
// component requires, in our case the UserRepositoryComponent
trait UserServiceComponent { this: UserRepositoryComponent =>
  val userService = new UserService  
  class UserService {
    def authenticate(username: String, password: String): User = 
      userRepository.authenticate(username, password)  
    def create(username: String, password: String) = 
      userRepository.create(new User(username, password))
    def delete(user: User) = userRepository.delete(user)
  }
}

The self-type annotation we are talking about is this code snippet:

this: UserRepositoryComponent =>

If you need to declare more than one dependency then you can compose the annotations like this:

this: Foo with Bar with Baz =>

Ok. Now we have declared the UserRepository dependency. What is left is the actual wiring.

In order to do that the only thing we need to do is to merge/join the different namespaces into one single application (or module) namespace. This is done by creating a “module” object composed of all our components. When we do that all wiring is happening automatically.

object ComponentRegistry extends
  UserServiceComponent with
  UserRepositoryComponent

One of the beauties here is that all wiring is statically typed. For example, if we have a dependency declaration missing, if it is misspelled or something else is screwed up then we get a compilation error. This also makes it very fast.

Another beauty is that everything is immutable (all dependencies are declared as val).

In order to use the application we only need to get the “top-level” component from the registry, and all other dependencies are wired for us (similar to how Guice/Spring works).

val userService = ComponentRegistry.userService
...
val user = userService.authenticate(..)

So far so good?

Well, no. This sucks.

We have strong coupling between the service implementation and its creation, the wiring configuration is scattered all over our code base; utterly inflexible.

Let’s fix it.

Instead of instantiating the services in their enclosing component trait, let’s change it to an abstract member field.

trait UserRepositoryComponent {
  val userRepository: UserRepository

  class UserRepository {
    ...
  }
}

trait UserServiceComponent { 
  this: UserRepositoryComponent => 

  val userService: UserService  

  class UserService {
    ... 
  }
}

Now, we can move the instantiation (and configuration) of the services to the ComponentRegistry module.

object ComponentRegistry extends 
  UserServiceComponent with 
  UserRepositoryComponent 
{
  val userRepository = new UserRepository
  val userService = new UserService
}

By doing this switch we have now abstracted away the actual component instantiation as well as the wiring into a single “configuration” object.

The neat thing is that we can here switch between different implementations of the services (if we had defined an interface trait and multiple implementations). But even more interestingly, we can create multiple “worlds” or “environments” by simply composing the traits in different combinations.

To show you what I mean, we’ll now create a “testing environment” to be used during unit testing.

Now, instead of instantiating the actual services we instead create mocks to each one of them. We also change the “world” to a trait (why, I will show you in a second).

trait TestEnvironment extends
  UserServiceComponent with
  UserRepositoryComponent with 
  org.specs.mock.JMocker
{
  val userRepository = mock(classOf[UserRepository])
  val userService = mock(classOf[UserService])
}

Here we are not merely creating mocks but the mocks we create are wired in as the declared dependencies wherever defined.

Ok, now comes the fun part. Let’s create a unit test in which we are mixing in the TestEnvironment mixin, which is holding all our mocks.

class UserServiceSuite extends TestNGSuite with TestEnvironment {

  @Test { val groups=Array("unit") }
  def authenticateUser = {

    // create a fresh and clean (non-mock) UserService 
    // (who's userRepository is still a mock)
    val userService = new UserService

    // record the mock invocation
    expect {
      val user = new User("test", "test")
      one(userRepository).authenticate(user) willReturn user
    }
    
    ... // test the authentication method
  }
  
  ...
}

This pretty much sums it up and is just one example on how you can compose your components in the way you want.

Other alternatives

Let’s now take a look at some other ways of doing DI in Scala. This post is already pretty long and therefore I will only walk through the techniques very briefly, but it will hopefully be enough for you to understand how it is done. I have based all these remaining examples on the same little dummy program to make it easier to digest and to compare (taken from some discussion found on the Scala User mailing list). In all these examples you can just copy the code and run it in the Scala interpreter, in case you want to play with it.

Using structural typing

This technique using structural typing was posted by Jamie Webb on the Scala User mailing list some time ago. I like this approach; elegant, immutable, type-safe.

// =======================
// service interfaces
trait OnOffDevice {
  def on: Unit
  def off: Unit
}
trait SensorDevice {
  def isCoffeePresent: Boolean
}

// =======================
// service implementations
class Heater extends OnOffDevice {
  def on = println("heater.on")
  def off = println("heater.off")
}
class PotSensor extends SensorDevice {
  def isCoffeePresent = true
}

// =======================
// service declaring two dependencies that it wants injected,
// is using structural typing to declare its dependencies
class Warmer(env: {
  val potSensor: SensorDevice
  val heater: OnOffDevice
}) {
  def trigger = {
    if (env.potSensor.isCoffeePresent) env.heater.on
    else env.heater.off
  }
}

class Client(env : { val warmer: Warmer }) {
  env.warmer.trigger
}

// =======================
// instantiate the services in a configuration module 
object Config {
  lazy val potSensor = new PotSensor
  lazy val heater = new Heater
  lazy val warmer = new Warmer(this) // this is where injection happens
}

new Client(Config)

Using implicit declarations

This approach is simple and straight-forward. But I don’t really like that the actual wiring (importing the implicit declarations) is scattered and tangled with the application code.

// =======================
// service interfaces
trait OnOffDevice {
  def on: Unit
  def off: Unit
}
trait SensorDevice {
  def isCoffeePresent: Boolean
}

// =======================
// service implementations
class Heater extends OnOffDevice {
  def on = println("heater.on")
  def off = println("heater.off")
}
class PotSensor extends SensorDevice {
  def isCoffeePresent = true
}

// =======================
// service declaring two dependencies that it wants injected
class Warmer(
  implicit val sensor: SensorDevice, 
  implicit val onOff: OnOffDevice) {

  def trigger = {
    if (sensor.isCoffeePresent) onOff.on
    else onOff.off
  }
}

// =======================
// instantiate the services in a module 
object Services {
  implicit val potSensor = new PotSensor
  implicit val heater = new Heater
}

// =======================
// import the services into the current scope and the wiring 
// is done automatically using the implicits
import Services._

val warmer = new Warmer
warmer.trigger

Using Google Guice

Scala works nicely with separate DI frameworks and early on we were using Google Guice. You can use Guice in many different ways, but here we will discuss a slick technique based on a ServiceInjector mixin that my Jan Kriesten showed me.

// =======================
// service interfaces
trait OnOffDevice {
  def on: Unit
  def off: Unit
}
trait SensorDevice {
  def isCoffeePresent: Boolean
}
trait IWarmer {
  def trigger
}
trait Client

// =======================
// service implementations
class Heater extends OnOffDevice {
  def on = println("heater.on")
  def off = println("heater.off")
}
class PotSensor extends SensorDevice {
  def isCoffeePresent = true
}
class @Inject Warmer(
  val potSensor: SensorDevice, 
  val heater: OnOffDevice) 
  extends IWarmer {

  def trigger = {
    if (potSensor.isCoffeePresent) heater.on
    else heater.off
  }
}

// =======================
// client
class @Inject Client(val warmer: Warmer) extends Client {
  warmer.trigger
}

// =======================
// Guice's configuration class that is defining the 
// interface-implementation bindings 
class DependencyModule extends Module {
  def configure(binder: Binder) = {
    binder.bind(classOf[OnOffDevice]).to(classOf[Heater])
    binder.bind(classOf[SensorDevice]).to(classOf[PotSensor])
    binder.bind(classOf[IWarmer]).to(classOf[Warmer])
    binder.bind(classOf[Client]).to(classOf[MyClient])
  }
}

// =======================
// Usage: val bean = new Bean with ServiceInjector
trait ServiceInjector {
  ServiceInjector.inject(this)
}

// helper companion object 
object ServiceInjector {
  private val injector = Guice.createInjector(
    Array[Module](new DependencyModule))
  def inject(obj: AnyRef) = injector.injectMembers(obj)
}

// =======================
// mix-in the ServiceInjector trait to perform injection
// upon instantiation
val client = new MyClient with ServiceInjector

println(client)

That sums up what I had planned to go through in this article. I hope that you have gained some insight in how one can do DI in Scala, either using language abstractions or a separate DI framework. What works best for you is up to your use-case, requirements and taste.

Update:

Below I have added a Cake Pattern version of the last example for easier comparison between the different DI strategies. Just a note, if you compare the different strategies using this naive example then the Cake Pattern might look a bit overly complicated with its nested (namespace) traits, but it really starts to shine when you have a less then trivial example with many components with more or less complex dependencies to manage.

// =======================
// service interfaces
trait OnOffDeviceComponent {
  val onOff: OnOffDevice
  trait OnOffDevice {
    def on: Unit
    def off: Unit
  }
}
trait SensorDeviceComponent {
  val sensor: SensorDevice
  trait SensorDevice {
    def isCoffeePresent: Boolean
  }
}

// =======================
// service implementations
trait OnOffDeviceComponentImpl extends OnOffDeviceComponent {
  class Heater extends OnOffDevice {
    def on = println("heater.on")
    def off = println("heater.off")
  }
}
trait SensorDeviceComponentImpl extends SensorDeviceComponent {
  class PotSensor extends SensorDevice {
    def isCoffeePresent = true
  }
}
// =======================
// service declaring two dependencies that it wants injected
trait WarmerComponentImpl {
  this: SensorDeviceComponent with OnOffDeviceComponent =>
  class Warmer {
    def trigger = {
      if (sensor.isCoffeePresent) onOff.on
      else onOff.off
    }
  }
}

// =======================
// instantiate the services in a module
object ComponentRegistry extends
  OnOffDeviceComponentImpl with
  SensorDeviceComponentImpl with
  WarmerComponentImpl {

  val onOff = new Heater
  val sensor = new PotSensor
  val warmer = new Warmer
}

// =======================
val warmer = ComponentRegistry.warmer
warmer.trigger

Real-World Scala: Introduction

2008-10-01T00:00:00+00:00

Real-World Scala: Introduction

The last nine months I have been running my own business together with some friends (Triental AB). We are building a product suite for private banking and wealth management with a focus on portfolio management, analysis and simulation.

One of the great things of being your own is that you get to choose whatever technology you like and think is best suitable for the job. The last years I have been studying and playing with Functional Programming (FP) in general and Scala in particular (among with Erlang, Clojure and Haskell). FP has been used successfully in the financial domain before (for example Jane Street Capital (OCaml) and Business Objects (CAL)), and the work we do is heavily based on mathematics which maps excellent to the FP paradigm.

Apart from the FP properties (such as immutability, high-order functions, closures etc.) Scala also have some other interesting properties such as:

Mixin composition (enables creation of components build up of reusable fragments, even runtime composition)
Actors library (message-passing concurrency, an easy way of parallelizing long-running computations and simulations out on multi-core or SMP machines)
Flexible syntax with decent type inference (high productivity, great for DSLs etc.)
Statically typed (fast, in most cases as fast as Java)
Pattern matching
Seamless interoperability with Java
and much much more

So I decided to try use FP and Scala for real.

By choosing to base the development on FP and a new and fairly unproven (at least in the industry) language like Scala, we were exposing ourselves to two main risks:

Technology: will the technology deliver, can we fix or work around the problems that will emerge down the road etc.?
Education: will the process and time needed to be invested in learning a new language and paradigm slow us down too much?

And will the benefit of using it in terms of:

higher productivity,
cleaner, more stable and more reusable code, and
more fun

outweigh the potential risks and upfront time (and money) investment?

To be honest, the trip has been a bit bumpy sometimes, but now after nine months of development I can say that Scala pulled it off. Both of these risks were manageable. We are very happy with the strategic decision to use Scala.

Technology-wise, one of the biggest problems of using Scala in a JEE application stack is that there are (currently) no frameworks, patterns or “best-practices” that will help you address fundamental issues like:

Dependency Injection (DI)
Code tangling and scattering e.g. AOP
Transaction demarcation and context propagation
Component life-cycle

Basically, we didn’t have a “container” that could handle this for us so we had to write it ourselves. The good thing is that most Java frameworks works very nicely with Scala. For example, we have had using no problems using JPA, Wicket etc. and deploy it in a standard JEE appserver.

Regarding the second risk; education, it turned out to not be much of an issue. Our developers who had never written a line in Scala and had very little experience with FP in general were fully up to speed in a couple of months. The first weeks there were some complaints but now they are loving it. Scala gives a smooth learning curve to FP since it, being a unique blend of the OO and FP paradigms, allows one to start with a very Java-esque imperative style of programming and gradually move towards a functional style. Now we have rewritten most of the imperative chunks of code that were written during the early education stages.

This is the first post in a series of articles in which I will try to explain how we are bridging the “Scala <—> Real-World” gap. I have to stress that these are by no means the only way to do things and perhaps not the best way of doing things, but simply the way we have solved our problems and what work for us. Hopefully it will also work for you.

For those that are interested here is a list of the Scala frameworks that we are currently using:

Scala (for the domain model, persistence layer, service layer, facade layer and container code)
Configgy (logging and configuration)
Scala OTP (actor management)
Lift (misc util)
scalax (misc util)
ScalaTest (testing)
ScalaCheck (testing)

The rest is a fairly standard Java stack:

Wicket
Hibernate (JPA)
Atomikos (JTA)
Terracotta
Wicket-Push (Cometd)
Dojo
AspectJ
XStream
TestNG
DBUnit
EasyMock
MySQL
Jetty
Maven
Hudson

The topics I am planning on covering are:

Dependency Injection
AOP
Transaction demarcation (JTA) and context propagation
Asynchronous event-driven components
ORM (JPA)

Stay tuned for the next article.

The Book Is Out

2008-06-30T00:00:00+00:00

The Book Is Out

The Definite Guide to Terracotta by me and my colleagues; Ari, Geert, Alex, Orion and Taylor, is now available in the stores.
It is a pragmatic and practical book, with tons of real-world examples and stories, so if you want to learn how to use Terracotta for real then go and order a copy.

Erlang-style Supervisor Module for Scala Actors

2008-06-16T00:00:00+00:00

Erlang-style Supervisor Module for Scala Actors

In this post I will explain how you can build fault-tolerant systems using Scala Actors by arranging them in Supervisor hierarchies using a library for Scala Supervisors that I just released.

But first, let’s recap what Actors are and what makes them useful.

An actor is an abstraction that implements Message-Passing Concurrency. Actors have no shared state and are communicating by sending and receiving messages. This is a paradigm that provides a very different and much simpler concurrency model than Shared-State Concurrency (the scheme adopted by C, Java, C# etc.) and making it easier to avoid problems like deadlocks, live locks, thread starvation etc. This makes it possible to write code that is deterministic and side-effect-free, something that makes easier to write, test, understand and reason about. Each actor has a mailbox in which it receives incoming messages and can use pattern matching on the messages to decide if a message is interesting and which action to take. The most well known and successful implementation of actors can be found in the Erlang language (and the OTP platform) where it has been used to implement extremely fault tolerant (99.9999999% reliability – 9 nines) and massively concurrent systems (with hundreds of thousand simultaneous actors).

So what are Supervisor hierarchies? Let’s go to the source; http://www.erlang.org/doc/design_principles/sup_princ.html#5.

A supervisor is responsible for starting, stopping and monitoring its child processes. The basic idea of a supervisor is that it should keep its child processes alive by restarting them when necessary.

It has two different restart strategies; All-For-One and One-For-One. Best explained using some pictures (referenced from erlang.org):

OneForOne

AllForOne

Naturally, the library I have written for Scala is by no means as complete and hardened as Erlang’s, but it seems to do a decent job in providing the core functionality.

The implementation consists of two main abstractions; Supervisor and GenericServer.

The Supervisor manages hierarchies of Scala actors and provides fault-tolerance in terms of different restart semantics. The configuration and semantics is almost a 1-1 port of the Erlang Supervisor implementation, explained in the erlang.org doc referenced above. Read this document in order to understand how to configure the Supervisor properly.

The GenericServer (which subclasses the Actor class) is a trait that forms the base for a server to be managed by a Supervisor.

The GenericServer is wrapped by a GenericServerContainer instance providing a necessary indirection needed to be able to fully manage the life-cycle of the GenericServer in an easy way.

So, let’s try it out by writing a small example in which we create a couple of servers, configure them, use them in various ways, kill one of them, see it recover, hotswap its implementation etc.

(Sidenote: I have written about hotswapping actors before, however this library has taken this approach a but further and provides a more flexible and powerful way of achieving this. Thanks DPP.)

This walk-through will only cover some of the API, for more details look at the code or the tests.

1. Create our server messages

import scala.actors._
import scala.actors.Actor._

import com.jonasboner.supervisor._
import com.jonasboner.supervisor.Helpers._

sealed abstract class SampleMessage
case object Ping extends SampleMessage
case object Pong extends SampleMessage
case object OneWay extends SampleMessage
case object Die extends SampleMessage

2. Create a GenericServer
We do that by extending the GenericServer trait and override the body method.

class SampleServer extends GenericServer {

  // This method implements the core server logic and naturally has to be overridden
  override def body: PartialFunction[Any, Unit] = {
    case Ping => 
      println("Received Ping"); reply(Pong)

    case OneWay => 
      println("Received OneWay")

    case Die => 
      println("Received Die..dying...") 
      throw new RuntimeException("Received Die message")
  }

}

GenericServer also has some callback life-cycle methods, such as init(..) and shutdown(..).

3. Wrap our SampleServer in a GenericServerContainer
Here we also give it a name to be able to refer to it later. We are creating two instances of the same server impl in order to try out multiple server restart in case of failure.

object sampleServer1 extends GenericServerContainer("sample1", () => new SampleServer)
object sampleServer2 extends GenericServerContainer("sample2", () => new SampleServer)

4. Create a Supervisor configuration
Here we create a SupervisorFactory that is configuring our servers. The configuration mimics the Erlang configuration and defines a general restart strategy for our Supervisor as well as a list of workers (servers) which for each we define a specific life-cycle.

object factory extends SupervisorFactory {
  override protected def getSupervisorConfig: SupervisorConfig = {
    SupervisorConfig(
      RestartStrategy(AllForOne, 3, 10000),
       Worker(
        sampleServer1,
        LifeCycle(Permanent, 1000)) ::
       Worker(
        sampleServer2,
        LifeCycle(Permanent, 1000)) ::
      Nil)
  }
}

5. Create a new Supervisor

val supervisor = factory.newSupervisor

Output:



12:25:30.031 [Thread-2] DEBUG com.jonasboner.supervisor.Supervisor – Configuring supervisor:com.jonasboner.supervisor.Supervisor@860d49

12:25:30.046 [Thread-2] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@1b9240e] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

12:25:30.062 [Thread-2] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@1808199] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

12:25:30.062 [main] DEBUG Main$factory$2$ – Supervisor successfully configured

6. Start the Supervisor
This also starts the servers.

supervisor ! Start

Output:



12:25:30.078 [Thread-8] INFO  com.jonasboner.supervisor.Supervisor – Starting server: Main$sampleServer2$2$1479feb
12:25:30.078 [Thread-8] INFO  com.jonasboner.supervisor.Supervisor - Starting server: Main$sampleServer1$2$97a560

7. Try to communicate with the servers.
Here we try to send a couple one way asynchronous messages to our servers.



sampleServer1 ! OneWay

Try to get a reference to our sampleServer2 (by name) from the Supervisor before sending a message.

supervisor.getServer("sample2") match {
  case Some(server2) => server2 ! OneWay
  case None => println("server [sample2] could not be found")
}

Output:



Received OneWay

Received OneWay

8. Send a message using a future
Try to send an asynchronous message – receive a future – and wait 100 ms (time-out) for the reply.

val future = sampleServer1 !! Ping
val reply1 = future.receiveWithin(100) match {
  case Some(reply) => 
    println("Received reply: " + reply)
  case None => 
    println("Did not get a reply witin 100 ms")
}

Output:



Received Ping

Received reply: Pong

9. Kill one of the servers
Try to send a message (Die) telling the server to kill itself (by throwing an exception).

sampleServer1 ! Die

Output:



Received Die..dying…

12:25:30.093 [Thread-8] ERROR c.j.supervisor.AllForOneStrategy – Server [Main$SampleServer$1@1b9240e] has failed due to [java.lang.RuntimeException: Received Die message] – scheduling restart – scheme: ALL_FOR_ONE.

12:25:30.093 [Thread-8] DEBUG Main$sampleServer2$2$ – Waiting 1000 milliseconds for the server to shut down before killing it.

12:25:30.093 [Thread-8] DEBUG Main$sampleServer2$2$ – Server [sample2] has been shut down cleanly.

12:25:30.093 [Thread-8] DEBUG c.j.supervisor.AllForOneStrategy – Restarting server [sample2] configured as PERMANENT.

12:25:30.093 [Thread-8] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@166aa18] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

12:25:30.093 [Thread-8] DEBUG Main$sampleServer1$2$ – Waiting 1000 milliseconds for the server to shut down before killing it.

12:25:30.093 [main] DEBUG com.jonasboner.supervisor.Helpers$ – Future timed out while waiting for actor: Main$SampleServer$1@1b9240e

Expected exception: java.lang.RuntimeException: Time-out

12:25:31.093 [Thread-8] DEBUG c.j.supervisor.AllForOneStrategy – Restarting server [sample1] configured as PERMANENT.

12:25:31.093 [Thread-8] DEBUG com.jonasboner.supervisor.Supervisor – Linking actor [Main$SampleServer$1@1968e23] to supervisor [com.jonasboner.supervisor.Supervisor@860d49]

10. Send an asyncronous message and wait on a future.

If this call times out, the error handler we define will be invoked – in this case throw an exception. It is likely that this call will time out since the server is in the middle of recovering from failure and we are on purpose defining a very short time-out to trigger this behavior.

val reply2 = try {
  sampleServer1 !!! (Ping, throw new RuntimeException("Time-out"), 10) 
} catch { case e => println("Expected exception: " + e.toString); Pong }

The output of this call (due to the async nature of actors) is interleaved with the logging for the restart of the servers. As you can see the log below can be found in the middle of the restart output.



12:25:30.093 [main] DEBUG com.jonasboner.supervisor.Helpers$ – Future timed out while waiting for actor: Main$SampleServer$1@1b9240e

Expected exception: java.lang.RuntimeException: Time-out

Server should be up again. Try the same call again

val reply3 = try {
  sampleServer1 !!! (Ping, throw new RuntimeException("Time-out"), 1000) 
} catch { case e => println("Expected exception: " + e.toString); Pong }

Output:



Received Ping

Also check that server number 2 is up and healthy.

sampleServer2 ! Ping

Output:



Received Ping

11. Try to hotswap the server implementation
Here we are passing in a completely new implementation of the server logic (doesn’t look that different tough, but it can be any piece of scala pattern matching code) to the server’s hotswap method.

sampleServer1.hotswap(Some({
  case Ping => 
    println("Hotswapped Ping")
}))

12. Try the hotswapped server out

sampleServer1 ! Ping

Output:



Hotswapped Ping

13. Hotswap again

sampleServer1.hotswap(Some({
  case Pong => 
    println("Hotswapped again, now doing Pong")
    reply(Ping)
}))

14. Send an asyncronous message that will wait on a future (using a different syntax/method).
Method returns an Option[T] which can be of two different types; Some(result) or None. If we receive Some(result) then we return the result, but if None is received then we invoke the error handler that we define in the getOrElse method. In this case print out an info message (but you could throw an exception or do whatever you like…) and return a default value (Ping).

val reply4 = (sampleServer1 !!! Pong).getOrElse({
  println("Time out when sending Pong")
  Ping
})

Output:



Hotswapped again, now doing Pong

Same invocation with pattern matching syntax.

val reply5 = sampleServer1 !!! Pong match {
  case Some(result) => result
  case None => println("Time out when sending Pong"); Ping  
}

Output:



Hotswapped again, now doing Pong

15. Hotswap back to original implementation.
This is done by passing in None to the hotswap method.

sampleServer1.hotswap(None)

16. Test the final hotswap

sampleServer1 !  Ping

Output:



Received Ping

17. Shut down the supervisor and its server(s)

supervisor ! Stop

Output:



12:25:31.093 [Thread-6] INFO  com.jonasboner.supervisor.Supervisor – Stopping server: Main$sampleServer2$2$1479feb
12:25:31.093 [Thread-6] INFO  com.jonasboner.supervisor.Supervisor - Stopping server: Main$sampleServer1$2$97a560

12:25:31.093 [Thread-6] INFO  com.jonasboner.supervisor.Supervisor – Stopping supervisor: com.jonasboner.supervisor.Supervisor@860d49

You can find this code in the sample.scala file in the root directory of the distribution. Run it by invoking:



scala -cp target/supervisor-0.3.jar:[dependency jars: slf4j and logback] sample.scala

Check out
The SCM system used is Git.

1. Download and install Git
2. Invoke git clone git@github.com:jboner/scala-supervisor.git.

Build it
The build system used is Maven 2.

1. Download and install Maven 2.
2. Step into the root dir scala-supervisor.
3. Invoke mvn install

This will build the project, run all tests, create a jar and upload it to your local Maven repository ready for use.

Runtime dependencies
Automatically downloaded my Maven.

1. Scala 2.7.1-final
2. SLF4J 1.5.2
3. LogBack Classic 0.9.9

That’s all to it.

Have fun.

AOP-style Mixin Composition Stacks in Scala

2008-02-06T00:00:00+00:00

AOP-style Mixin Composition Stacks in Scala

Scala is one those great languages that is scalable. With scalable I mean that it is the language that grows with the user, that it makes simple things easy and hard things possible. A language that is easy to get started and to become productive in, but at the same time a deep language with very powerful constructs and abstractions.

In this blog post I will try to highlight the power of Scala’s mixins and how you can use mixin composition to get AOP/interceptor-like style of programming.

First let’s define our service interface, modeled as a mixin (in this case without an implementation so similar to Java’s interface):

trait Stuff {
  def doStuff
}

Now let’s define two different mixin “interceptors” that implement the service interface. The first one manages logging and the other one transaction demarcation (but for simplicity I am just using a dummy mock for TX stuff for now):

trait LoggableStuff extends Stuff {
  abstract override def doStuff {
    println("logging enter")
    super.doStuff
    println("logging exit")
  }
}

trait TransactionalStuff extends Stuff {
  abstract override def doStuff {
    println("start TX")
    try {
      super.doStuff
      println("commit TX")      
    } catch {
      case e: Exception => 
        println("rollback TX")   
    } 
  }
}

As we can see in this example they both override the Stuff.doStuff method. If we look more closely we can see that they follow the same pattern:

Enter method (doStuff)
Do something (log, start tx etc.)
Invoke the same method on super (super.doStuff)
Do something (log, commit tx etc.)

But before we try this out, let’s create a concrete implementation of our Stuff service, called RealStuff:

class RealStuff {
  def doStuff = println("doing real stuff")
}

Now we have everything we need, so let’s fire up the Scala REPL and create a component based on the RealStuff class and a mixin stack with support for logging and transactionality. Scala’s mixin composition can take place when we instantiate an instance, e.g. it allows us to mix in functionality into specific instances that object creation time for specific object instances.

First let’s create a plain RealStuff instance and run it:



scala> import stacks._

import stacks._
scala> val stuff = new RealStuff 

stuff: stacks.RealStuff = $anon$1@6732d42
scala> stuff.doStuff

doing real stuff

Not too exciting, but let’s do it again and this time mix in the LoggableStuff mixin:

scala> val stuff2 = new RealStuff with LoggableStuff 
stuff2: stacks.RealStuff with stacks.LoggableStuff = $anon$1@1082d45

scala> stuff2.doStuff
logging enter
doing real stuff
logging exit

As you can see the call to RealStuff.doStuff is intercepted and logging is added before we are invoking this method as well as after. Let’s now add the TransactionalStuff mixin:

scala> val stuff3 = new RealStuff with LoggableStuff with TransactionalStuff
stuff3: stacks.RealStuff with stacks.LoggableStuff with stacks.TransactionalStuff = $anon$1@4512d65

scala> stuff3.doStuff
start TX
logging enter
doing real stuff
logging exit
commit TX

As you can see, the semantics for this mixin stack is the exact same as you would get with stacking AspectJ aspects or Spring interceptors. Another interesting aspect is that the whole composition is statically compiled with all its benefits of compile time error detection, performance, potential tool support etc.

This approach is similar to Rickard Oberg’s idea on using the so-called Abstract Schema pattern for type-safe AOP in plain Java.

It is both simple and intuitive to change the order of the mixin “interceptors”, simply change the order in which they are applied to the target instance:

scala> val stuff4 = new RealStuff with TransactionalStuff with LoggableStuff
stuff4: stacks.RealStuff with stacks.TransactionalStuff with stacks.LoggableStuff = $anon$1@a20232

scala> stuff4.doStuff
logging enter
start TX
doing real stuff
commit TX
logging exit

Finally, just for fun, let’s a create a mixin that can retry failing operations. This particular one will catch any exception that the service might throw and retry it three times before giving up:

trait RetryStuff extends Stuff {
  abstract override def doStuff {
    var times = 0
    var retry = true
    while (retry) {
      try {
        super.doStuff      
        retry = false
      } catch {
        case e: Exception => 
          if (times < 3) { // retry 3 times
            times += 1
            println("operation failed - retrying: " + times)
          } else {
            retry = false
            throw e 
          }
      }
    }
  }
}

To test this behavior (as well as the rollback feature in the TransactionalStuff) we can change the RealStuff.getStuff method to throw an exception:



class RealStuff {

  def doStuff {

    println(“doing real stuff”)

    throw new RuntimeException(“expected”)

  }

}

Now we can try to add this mixin to the beginning of our our stack and run the service:

scala> val stuff5 = new RealStuff with RetryStuff with TransactionalStuff  with LoggableStuff
stuff5: stacks.RealStuff with stacks.RetryStuff with stacks.LoggableStuff with stacks.TransactionalStuff = $anon$1@a927d45

scala> stuff5.doStuff
logging enter
start TX
doing real stuff
operation failed - retrying: 1
doing real stuff
operation failed - retrying: 2
doing real stuff
operation failed - retrying: 3
rollback TX
logging exit

Pretty neat, right?

That’s all for now. In the next post I will cover a bunch of ways to use Scala’s language primitives to do Dependency Injection (DI).

Clustering Scala Actors with Terracotta

2008-01-25T00:00:00+00:00

Clustering Scala Actors with Terracotta

Introduction

A month ago I wrote an introductory post about Scala Actors: HotSwap Code using Scala and Actors. For you who don’t know what it is I don’t want to start by reading the previous post let’s briefly recap what Actors are and what you can use them for.

An Actor is an abstraction that implements Message-Passing Concurrency. Actors have no shared state and are communicating by sending and receiving messages. This is a paradigm that provides a very different and much simple concurrency model than Shared-State Concurrency (the scheme adopted by C, Java, C# etc.) and is avoiding most of the latter one’s complexity and problems. This makes it possible to write code that is deterministic and side-effect-free, something that makes it easier to write, test, understand and reason about. Each Actor has a mailbox in which it receives incoming messages and normally uses pattern matching on the messages to decide if a message is interesting if action is needed.

Scala’s Actors are based on Doug Lea’s Fork/Join library and have for example been used very effectively in the excellent lift web framework to among other things to enable Comet style (push/streaming ajax) development. Actors allows us to, in a simple and uniformed way, parallelize applications using multiple threads, something that helps us take advantage of all the new dual/quad/… core or SMP machines that we are starting to get now days. But this also poses challenges; how can we make applications build on this “new” programming model highly available and how can we scale them out, if necessary. Would it not be cool if we could not only parallelize our application onto multiple threads but also onto multiple machines?

Note: Erlang, the most successful implementation of Actors to date, solves the challenges in building fault-tolerant and highly available systems in an elegant way using supervisor hierarchies. Nothing prevents an implement of this strategy in Scala Actors, all the primitives (like link, trap_exit etc.) already exists.

I have spent some time last weeks looking into if would make sense to utilize Terracotta to cluster the Scala Actors library to give a platform on which we can both scale Actors out in a distributed fashion and ensure full fault tolerance and high-availability. The result of this exercise have been successful and I’m happy to announce that they work very nice together. I will now spend the remainder of this post on walking you through a simple example in how to cluster a Scala Actor using Terracotta.

Check out the code from SVN

But before we do anything, let my point you to the SVN repository where you can fetch the Terracotta Integration Module (TIM) that I have implemented for Scala Actors. You can check it out anonymously by invoking:

svn co http://svn.terracotta.org/svn/forge/projects/labs/tim-scala-actors-2.6.1/

When that is done, step into tim-scala-actors-2.6.1/trunk and invoke mvn install (the last command requires that you have Maven installed). it’ll take a while for Maven to download all its dependencies but after a while you will have a shiny new TIM for Scala Actors installed in your local Maven repository (usually in ~/.m2). The sample that we will discuss in the next sections is available in the src/samples/scala directory with the sample configuration in the src/samples/resources directory.

Write an Actor

Now, let’s write a little Cart actor. This actor response to two different messages AddItem(item) and Tick. The former one adds an item to the Cart while the latter one triggers the Cart to print out its content (I’ll let you know why it’s called Tick in a second):

// Messages
case object Tick
case class AddItem(item: String)
  
class Cart extends Actor {
  private[this] var items: List[String] = Nil 

  def act() {
    loop {
      react {
        case AddItem(item) =>
          items = item :: items
        case Tick =>
          println("Items: " + items)
      }
    }
  }
  
  def ping = ActorPing.scheduleAtFixedRate(this, Tick, 0L, 5000L)
}

As you see the state is held by a Scala var, which holds onto a List (immutable). In react we wait for the next incoming message and if it is of type AddItem then we grab the item and append it to the list with all our items, but if the message is of type Tick we simply print the list of items out. Simple enough. But what is this method ping doing? It uses an object called ActorPing to schedule that a Tick should be sent to the Cart every 5 seconds (ActorPing is shamelessly stolen from Dave Pollak’s lift).

Configuration

In order to cluster the Cart actor we have to write two things. First a hack, a simple configuration file in which declare which actors we want to cluster. This is something that later should be put into the regular tc-config.xml file, but for now we have to live with it. So let’s create a file with one single line, stating the fully qualified name of the Cart actor;

 samples.Cart

We can either name this file clustered-scala-actors.conf and put it in root directory of the application or name it whatever we want and feed it to Terracotta using the -Dclustered.scala.actors.config=[path to the file] JVM property. Second, we have to write the regular Terracotta configuration file (tc-config.xml). Here we essentially have to define three things; the TIM for Scala Actors, locks to guard our mutable state and finally which classes should be included for bytecode instrumentation.

Starting with the TIM for Scala Actors. Here we define the version on the module as well as the URL to our Maven repository (in a short while we will put this jar in the Terracotta Maven repository and then you would not have to point out a local one).

<modules>
 <repository>file:///Users/jonas/.m2/repository</repository>
 <module name="clustered-scala-actors-2.6.1" version="2.6.0.SNAPSHOT"/>
</modules>

Now we have to define the locks, which in Terracotta, also marks the transaction boundaries. The Cart has one mutable field (the var named items) that we need to ensure is guarded correctly and has transactional semantics. For each var Scala generates a setter and a getter. The getter is named the same as the field while the getter has the name suffixed with _$eq. That gives us the following lock definition:

<locks>
  <named-lock>
    <lock-name>cart_items_write</lock-name>
    <lock-level>write</lock-level>
    <method-expression>* samples.Cart.items_$eq(..)</method-expression>
  </named-lock>
  <named-lock>
    <lock-name>cart_items_read</lock-name>
    <lock-level>read</lock-level>
    <method-expression>* samples.Cart.items()</method-expression>
  </named-lock>
</locks>

We have to define a pair like this for each mutable user defined field in a clustered actor (not the standard one’s that are common for all Scala Actors, those are automatically defined).

It important to understand the TIM automatically clusters the Actor’s mailbox, which means that no messages will ever be lost – providing full fault-tolerance.

Finally we have to define the classes that we need to include for instrumentation. This naturally includes our application classes, e.g. the classes that are using our Cart actor in one way or the other. Those are picked out by the pattern like: 'samples.*'. We also have to include all the Scala runtime and library classes that we are referencing from the message is that we send. In our case that means the classes that are used to implement the List abstraction in Scala. Here is the full listing:

<instrumented-classes>
 <include>
   <class-expression>samples.*</class-expression>
 </include>
 <include>
   <class-expression>scala.List</class-expression>
 </include>
 <include>
   <class-expression>scala.$colon$colon</class-expression>
 </include>
 <include>
   <class-expression>scala.Nil$</class-expression>
 </include>
</instrumented-classes>

I could have included these (and many more) classes in the TIM, but since Terracotta adds a tiny bit of overhead to each class that it instruments I took the decision that it would be better to let the user explicitly define the classes that needs to be instrumented and leave the other ones alone. Since you can pretty much put any valid Scala data or abstraction in an actor message, it is very likely that you will have to declare some includes, else Terracotta will throw an exception (which is expected) with a message listing the XML snippet that you have to put in the tc-config.xml file. So don’t panic if things blow up.

Enable Terracotta

Last but not least, we need to enable Terracotta in the Scala runtime (if you are planning to run the application in a Terracotta enabled application server, then you can skip this section – however I think it might still be useful to be able to try the application out in the Scala REPL). The simplest way of doing that is to do some minor changes to the scala command. First, let’s step down into the scala/bin directory and make a copy of the scala command called tc-scala, then scroll down all the way to the bottom. As you can see it is just a wrapper around the regular java command, which makes things pretty easy for us. We start by defining some environmental variables (here showing my local settings):

TC_SCALA_ACTORS_CONFIG_FILE=/Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/clustered-scala-actors.conf
TC_CONFIG_FILE=/Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/tc-config.xml
TC_INSTALL_DIR=/Users/jonas/src/java/tc/code/base/build/dist/terracotta-trunk-rev6814
TC_BOOT_JAR="$TC_INSTALL_DIR"/lib/dso-boot/dso-boot-hotspot_osx_150_13.jar
TC_TIM_SCALA_ACTORS_JAR=/Users/jonas/.m2/repository/org/terracotta/modules/clustered-scala-actors-2.6.1/2.6.0-SNAPSHOT/clustered-scala-actors-2.6.1-2.6.0-SNAPSHOT.jar

When these variables have been defined we can replace the existing invocation of java with the following:

${JAVACMD:=java} ${JAVA_OPTS:=-Xmx256M -Xms256M} \
 -Xbootclasspath/p:"$TC_BOOT_JAR" \
 -Dtc.install-root="$TC_INSTALL_DIR" \
 -Dtc.config="$TC_CONFIG_FILE" \
 -Dclustered.scala.actors.config="$TC_SCALA_ACTORS_CONFIG_FILE" \
 -Dscala.home="$SCALA_HOME" \
 -Denv.classpath="$CLASSPATH" \
 -Denv.emacs="$EMACS" \
 -cp "$BOOT_CLASSPATH":"$EXTENSION_CLASSPATH":"$TC_TIM_SCALA_ACTORS_JAR" \
 scala.tools.nsc.MainGenericRunner  "$@"

Let’s run it

Enough hacking. Now let’s try it out. I think that the best way of learning new things in Scala is to use its REPL, so let’s start that up, this time with Terracotta enabled. But before we do that we have to start up the Terracotta server by stepping into the bin directory in the Terracotta installation and invoke:

$ ./start-tc-server.sh

Note: you need to grab Terracotta from SVN trunk to get the bits that work with the Scala TIM. See instructions on how to check out the sources and how to build it.

Now, we can start up the Terracotta enabled Scala REPL:

$ tc-scala
2008-01-25 07:42:11,643 INFO - Terracotta trunk-rev6814, as of 20080124-140101 (Revision 6814 by jonas@homer from trunk)
2008-01-25 07:42:12,136 INFO - Configuration loaded from the file at '/Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/tc-config.xml'.
2008-01-25 07:42:12,325 INFO - Log file: '/Users/jonas/terracotta/client-logs/scala/actors/20080125074212303/terracotta-client.log'.
Parsing scala actors config file: /Users/jonas/src/java/tc-forge/projects/tim-scala-actors-2.6.1/trunk/src/samples/resources/clustered-scala-actors.conf
Configuring clustering for Scala Actor: samples.Cart
Welcome to Scala version 2.6.0-final.
Type in expressions to have them evaluated.
Type :help for more information.

scala>

Here we can see that it has found and connected to the Terracotta server, found our clustered-scala-actors.conf config file and configured clustering for one Scala Actor; samples.Cart.

Let’s have some fun and start up another REPL in another terminal window. In each of these we do the following; import our classes, create a new Cart (Actor) and start up the Actor.

scala> import samples._              
import samples._

scala> val cart = new Cart
cart: samples.Cart = samples.Cart@81af82

scala> cart.start
res0: scala.actors.Actor = samples.Cart@81af82

scala>

Now we have a distributed Actor just waiting to be fed with some messages. We don’t want to make it disappointed so let’s now add a bunch of bananas and apples to the Cart, and then feed it with a Tick message to make it print out the result:

scala> cart ! AddItem("bananas")

scala> cart ! AddItem("apples")

scala> cart ! Tick

scala> Items: List(apples, bananas)

scala>

Ok, so far no news. But comes the moment of truth, let’s take the other REPL and fire of a Tick:

scala> cart ! Tick

scala> Items: List(apples, bananas)

scala>

Yippee, it works. Now we can invoke the ping method to schedule a Tick (to print out status) every 5 seconds.

scala> cart.ping
res2: java.util.concurrent.ScheduledFuture = java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@3a4388

scala> Items: List(apples, bananas)

scala> Items: List(apples, bananas)

scala> cart ! AddItem("football")

scala> Items: List(football, apples, bananas)

...

How to define scope of the clustered Actor?

The Scala Actors TIM currently supports three different scopes; instance, class and custom. The scope is defined by appending a colon ‘:’ and the type of scope after the FQN of the Actor in the clustered-scala-actors.conf. If no scope is defined then the Actor is assumed to have scope instance. For example:

com.biz.Foo:custom
com.biz.Bar:class
com.biz.Baz:instance  
com.biz.Bam

The default scope named instance means that the Scala TIM is transparently intercepting the instantiation (f.e. new Cart) of all the Actors that you declare in the clustered-scala-actors.conf file. Each clustered Actor instance will have a unique identity across the cluster and each time this specific instance is created (f.e. when a new node joins the cluster) then the clustered instance with this specific identity will be handed out. The TIM distinguishes between actors of the same type but instantiated in different code paths. To take an example, let’s create one object ActorFactory with one single method create:

object ActorFactory {
  def create: Actor = new MyActor
}

If we now have two classes Foo and Bar as follows:

class Foo {
  val actor = ActorFactory.create
}

class Bar {
  val actor = ActorFactory.create
}

Then Foo and Bar will have two distinct clustered Actors each with a unique but cluster-wide identity.

The class scope lets all Actors of a the same type share Actor instance, so each time an Actor of a specific type is created the same clustered one will be handed out.

Finally we have the custom scope. Which, as it sounds, allows custom user defined scoping.

How to define custom scoped Actors?

If you want more control over scope and life-cycle of a specific Actor then you can define it to have custom scope in the clustered-scala-actors.conf file and create a factory in which you bind each Actor to whatever scope you wish. But now you have to create some data structure that is holding on to your Actors in the factory and explicitly define it to be a root in the tc-config.xml file. The factory might look something like this:

// Cart factory, allows mapping an instance to any ID
object Cart {
  
  // This instance is the custom Terracotta root
  private[this] val instances: Map[Any, Cart] = new HashMap

  def newInstance(id: Any): Cart = {
    instances.get(id) match {
      case Some(cart) => cart
      case None => 
        val cart = new Cart
        instances += (id -> cart)
        cart
    }
  }
}

This means that we have to add some more configuration elements to our Terracotta configuration. First we need to add the root samples.Cart$.instances (Cart$ is the name of Scala’s compiled Cart companion object, all companion objects compiles to a class with the name of the original class suffixed with $):

<roots>
  <root>
    <field-name>samples.Cart$.instances</field-name>
  </root>
</roots>

Then we have to add locking for the Cart.newInstance(..) method and finally a whole bunch of new include statements for all the Scala types that are referenced by the scala.collection.mutable.HashMap that we used as root:

...  
<named-lock>
  <lock-name>Cart_newInstance</lock-name>
  <lock-level>write</lock-level>
  <method-expression>* samples.Cart$.newInstance(..)</method-expression>
</named-lock>

...
          
<include>
  <class-expression>scala.collection.mutable.HashMap</class-expression>
</include>
<include>
  <class-expression>scala.runtime.BoxedAnyArray</class-expression>
</include>
<include>
  <class-expression>scala.runtime.BoxedArray</class-expression>
</include>
<include>
  <class-expression>scala.collection.mutable.DefaultEntry</class-expression>
</include>
  
...

That’s pretty much all there’s to it. Check out the code, play with it and come back with feedback, bug reports, patches etc.

Enjoy.

HotSwap Code using Scala and Actors

2007-12-19T00:00:00+00:00

HotSwap Code using Scala and Actors

Update: In this article I am showing an even more powerful way of doing hotswap in Scala:
http://jonasboner.com/2008/06/16/erlang-style-supervisor-module-for-scala-actors.html.
Se the bottom of this article for an example of how this is used to enable hotswap of arbitrary pieces of pattern matching code.

In this post I will show you how you can do code hotswap in the same fashion as in Erlang using Scala and its Actors package.

An actor is an abstraction that implements Message-Passing Concurrency. Actors have no shared state and are communicating by sending and receiving messages. This is a paradigm that provides a very different and much simpler concurrency model than Shared-State Concurrency (the scheme adopted by C, Java, C# etc.) and is avoiding all of the latter one’s problems with deadlocks, live locks, thread starvation etc. This makes it possible to write code that is deterministic and side-effect-free, something that makes easier to write, test, understand and reason about. Each actor has a mailbox in which it receives incoming messages and can use pattern matching on the messages to decide if a message is interesting and which action to take. The most well known and successful implementation of actors can be found in the Erlang language (and the OTP platform) where it has been used to implement extremely fault tolerant (99.9999999% reliability – 9 nines) and massively concurrent systems (with hundreds of thousand simultaneous actors).

Let’s start by writing a little server. We implement this in the form of a trait, which is Scala’s mixin construct. Traits allows you to build up your components using so-called mixin composition which is something that can give you a very high grade of reuse and flexibility. This trait only defines a single method named status which prints out info about the enclosing instance. Completely useless and not much for a server, but it will give you the idea. Then we subclass this mixin and define the ServerOne concrete server class (with the status method mixed in).

// servers
trait Server {
  def status = println("current server: " + this)
}
class ServerOne extends Server

Let’s instantiate the ServerOne class and see what the status method it will print out. Here we are doing it interactively through Scala’s REPL (read-eval-print-loop).

$ scala -cp .

scala> val server = new ServerOne
server: ServerOne = ServerOne@7be75d

scala> server status
current server: ServerOne@7be75d

Now, before we write the actor we have to define the messages it responds to. Here Scala is using something called case classes which are similar to normal classes but with some enhancements. First you can match on them, e.g. use pattern matching similar to the one found in Erlang. They also have some syntactic sugar, f.e. you can create them without using new, the compiler generates getters and setters for the constructor arguments, equality is not based on object id but on meaning/content (something that makes them ideal to use for value objects, but that is another story). We define two different messages; Status and HotSwap.

// triggers the status method
case object Status

// triggers hotswap - carries the new server to be hotswapped to
case class HotSwap(s: Server)

Ok, now it is time for the actual actor. Actor is a base class in the Scala library and we can choose to either extend it explicitly or to create an anonymous actor through the actor {...} construct. When we subclass the actor we have to implement the method called act which is the callback method that is invoked when the actor is started up.

Scala comes with two different implementations; one that is based on Java threads in that each actor is getting its own thread, while the other one is based on events and very lightweight allowing hundreds of thousands of actors to run simultaneously. Here we will use the event-based version (which is done by using the react method instead of the receive method for receiving messages).

The trick to do hotswap by using actors is to loop recursively and pass on the state in each recursive call. This is a very common idiom in functional programming. The beauty of it is that we do not update any mutual state but our execution is side effect free which makes it easier to test and reason about. In this case our state is the actual server. We start the loop by instantiating ServerOne. The pattern matching is happening in react statement in which we have three different cases (pattern matchers).

The first one matches our Status, when we receive this message we simply invoke the status method on our server and then taking another round in the loop passing along the server.

The second one matches our HotSwap message. It is here things are starting to get interesting. Now we can take the new replacement server (here called newServer), which is passed to us as an argument to the HotSwap message, and pass it in to the call to the loop method. Voila, we have updated our server at runtime. Now all subsequent messages will act on our new server instance.

This will work since the react method will in fact never return but infinitely recur. Infinite recursion would have been a problem in f.e. Java since each recursion would consume a new stack frame until we run out of memory. But recursion is one of the most powerful and commonly used idioms in functional programming and the Scala compiler optimizes tail-recursive algorithms and turns them into regular loops.

At the end we have also added a match-all pattern that does nothing, this is defined by the case _ => ... clause. Let’s take a look at the code.

class ServerActor extends Actor {
  def act = {
    println("starting server actor...")
    loop(new ServerOne)
  }
  
  def loop(server: Server) {
    react {
      case Status => 
        server.status
        loop(server)

      case HotSwap(newServer) => 
        println("hot swapping code...")
        loop(newServer)

      case _ => loop(server)
    }
  }
}

Finally we will follow one of Scala’s idioms and create a companion object for our ServerActor class. In this object, which is a singleton but should be seen upon as a module for functions and immutable state, we define an immutable handle to an instantiated and started actor.

Worth to note is that the val holding our actor is initialized when the enclosing object is first used, and since we are starting up the actor in the initialization block of the val, the actor will not be started until it is used for the first time.

// actor companion object
object ServerActor {
  val actor = {
    val a = new ServerActor
    a.start; a
  }
}

Let’s try to run it in the Scala REPL. The Scala function ! (pronounced bang) means “send a message”. So act ! msg means send message msg to actor act.

$ scala -cp .  

scala> import hotswap._
import hotswap._

scala> val actor = ServerActor.actor
starting actor...
actor: hotswap.ServerActor = hotswap.ServerActor@528ed7

scala> actor ! Status
current server: hotswap.ServerOne@226445

scala> class ServerTwo extends Server {
     | override def status = println("hotswapped server: " + this)
     | }
defined class ServerTwo

scala> actor ! HotSwap(new ServerTwo)
hot swapping code...

scala> actor ! Status
hotswapped server: line5$object$$iw$$iw$$iw$ServerTwo@b556

Pretty cool, right?

This would be even more cool if Scala came with an SSH server that could provide this REPL remotely (like we have in Erlang OTP). Then we could connect to our application from the outside and change its behavior, fixing bugs, upgrade the server etc. Another solution would be to make use of the remote actors in the Scala distribution, but that is something for another post.

Update:

This is a slightly simplified version of the GenericServer code (as discussed here), allowing hotswap of arbitrary pieces of pattern matching code:

// the actor's main loop
def act = loop { react { genericBase orElse actorBase } }

// should we go with the hotswapped impl or the regular server impl (body)
private def actorBase: PartialFunction[Any, Unit] = hotswap getOrElse body

// the hotswapped impl
private var hotswap: Option[PartialFunction[Any, Unit]] = None

// generic functionality
private val genericBase: PartialFunction[Any, Unit] = {
  case HotSwap(code) => hotswap = code
}

// the regular server implementation
def body: PartialFunction[Any, Unit] = {
  ...
}

This code can be used like this:

server ! HotSwap(Some({
  case Ping => 
    println("Ping")
}))

The Terracotta Book

2007-12-18T00:00:00+00:00

The Terracotta Book

The last month I have been very busy writing on The Definitive Guide to Terracotta.

It is a collaborative effort from the Terracotta team each one writing on chapters in their area of expertise. It is a very practical and will teach you how to use Terracotta with the X framework/appserver or for a Y use-case, yet thorough and deep in concepts and theory.

It will be available sometime next year and if you’re interested in getting updates on the book can subscribe to: bookupdate AT terracottatech DOT com.

Oredev 2007: BDD, LINQ, Scalability trends etc.

2007-11-17T00:00:00+00:00

Oredev 2007: BDD, LINQ, Scalability trends etc.

I had the pleasure of attending Oredev last month. This was a great conference. I have attended this conference three years in a row and it’s getting better and better every year.

This year they had a great speaker lineup and I was able to catch some very interesting talks. Among the most memorable ones were Dan North‘s keynote about why “Best Practices” in software development are neither “Best” no “Practices”. I also attended Dan’s talk on BDD (Behavior-Driven
Development). Great talk. I find BDD very interesting, it feels like the natural extension of, or complement to TDD (Test-Drived Development) in that it focuses on getting complete concept coverage in the tests instead of code coverage (as in TDD).

Other great talks were Andy Hunt‘s (Pragmatic Programmers) keynote and Erik Meijer’s talk on LINQ. The latter one was fun to watch, Erik (undeliberately it felt like) turned it more or less into a praise of Haskell; how they have stolen all the good stuff in LINQ from Haskell and that the world would be a better place if everyone just used Haskell.

My talk on Terracotta was able to attract quite a lot of attendees. One of the most interesting things was when I asked them, at the end of the talk, how many could see immediate need for something like Terracotta in their daily work roughly 80% raise their hands. I find this quite amazing and is actually something that have been consistent during last half year. I remember when I started asking this question, around 2 years ago, roughly 5-10 % raised their hands. This is quite a drastic change. Since I know that we were facing the same problems with scalability and HA a couple of years as we do now, I guess this is a sign of that the awareness of clustering, persistent and durable RAM and similar services has increased; that people have started to consider writing stateful applications with rich domain models – which implies another solution to HA and scalability than Oracle RAC and similar.

However, the best thing was that the conference had invited one of the best coffee shops in Malmo to serve all speakers unlimited amount of caffeine in the form of espresso, cafe latte, machiatto or whatever was asked for. I paid them 4-5 visits every day.

Interview with Joe Armstrong on Erlang and more...

2007-10-30T00:00:00+00:00

Interview with Joe Armstrong on Erlang and more…

I had the pleasure of attending Joe Armstrong’s fantastic presentation at JAOO some weeks ago. It was by far the best talk at the whole conference, both in terms of content and presentation. Joe showed deep knowledge in both hardware and software, good teaching skills all wrapped up in a dry twisted sense of British humor – Joe was incredibly funny, I sometimes felt like had attended a stand-up comedian show.

Anyway, for all of you that missed Joe’s talk, here is a great interview with him discussing Erlang’s (and a functional programmer’s) view of the world, the problem with OO, shared state concurrency and much more. Not as funny as the talk, but very interesting.

Clojure: a Lisp-dialect for the JVM - with focus on Functional and Concurrent Programming

2007-10-18T00:00:00+00:00

Clojure: a Lisp-dialect for the JVM – with focus on Functional and Concurrent Programming

Yesterday, Rich Hickey announced the birth of Clojure – a lisp dialect for the JVM.

After just a brief look, Clojure is perhaps the most interesting language in the (now fairly large) family of ‘dynamic languages for the JVM’. It brings the power of Lisp to the JVM but have made some design decisions that in some ways makes it more interesting than ANSI Common Lisp. Here are some of the things that I find particularly interesting:

Allows pure functional programming with immutable state (with immutable data-structures etc.) for side-effect-free code (possible in CL but hard to enforce).
- Immutable state can be freely shared across threads.
- Software Transactional Memory (STM) that allows atomic and isolated updates to mutable state (through “Refs”) with rollback and retry upon collision.
- Safe usage of mutable state through thread isolation (using “Vars”).
Full Lisp-style macro support and eval.
Compiles to JVM bytecode but still fully dynamic (sounds promising but I don’t know its actual performance).
Excellent integration with Java APIs, with type inference for static compilation of Java API calls.

Here are some tasters (from the forum).

Java integration:



(new java.util.Date)

=> Wed Oct 17 20:01:38 CEST 2007
(. (new java.util.Date) (getTime))

=> 1192644138751
(.. System out (println “This is cool!”))

This is cool!

Macros:

  

(defmacro time [form]

  `(let [t0# (. System (currentTimeMillis))

         res# ~form

         t1# (. System (currentTimeMillis))]

    (.. System out (println (strcat "Execution took "

                                    (/ (- t1# t0#) 1000.0) " s")))

    res#))
Usage:

(defn factorial [n]

   (if (< n 2)

       1

	n (factorial (- n 1)))))

(time (factorial 1000))

=> Execution took 0.012 s

     40…

It is still in beta but if you want to start playing around with it yourself, dive into the docs.

Dreaming on:
Stuff that I would like to see (in order to make it the ultimate playground) are among other things: message-passing concurrency (I don’t fully believe in STM…yet) and declarative pattern matching (from Erlang), implicit currying and laziness (as in Haskell), transparent distribution (as in Mozart/Oz and Erlang) and optional static typing. Some of these can be found in Qi, I just would love to see them on the JVM.

Interviewed by Xebia: Part 2

2007-10-10T00:00:00+00:00

Interviewed by Xebia: Part 2

The second half of an interview that Xebia did with me some months ago have been published.

In this half which we discuss Terracotta in more detail, covering Network-Attached Memory and JVM-level clustering in depth (some stuff that we cover is slightly outdated, but most of it still holds).

You can find it here.

If you missed the first part you can read more it here (which gives more of an overview).

Interviewed by Xebia: Part 1

2007-09-18T00:00:00+00:00

Interviewed by Xebia: Part 1

Xebia did an interview with me some months ago in which we discuss things like Terracotta, scale-out and high-availability for Java, JVM-level clustering, network-attached memory, distributed and concurrent programming, JEE best practices etc.

The interview is split up in two parts, the first one being more of an overview while the second one discusses things in more detail.

You can find the first part here.

Second part will be published in 2 weeks.

Article: Distributed Web Continuations with RIFE and Terracotta

2007-08-08T00:00:00+00:00

Article: Distributed Web Continuations with RIFE and Terracotta

My and Geert Bevin’s article about how to cluster RIFE’s Web Continuations with Terracotta has just been published on Artima.

Here is the abstract:

In this article, we discuss how the RIFE Web framework helps you become productive and efficient in building conversational Web applications. Productivity with RIFE is in large part due to RIFE’s unique approach to Web developmentâ€”its use of continuations for conversational logic, and complete integration of meta-programming to minimize boilerplate code.

We also introduce you to Terracotta and it’s JVM-level clustering technology, and show you how Terracotta and RIFE can work together to create an application stack that allows you to scale out and ensure high-availability for your applications, but without sacrificing simplicity and productivity. This means working with POJOs, and minimal boilerplate and infrastructure code.

It tries to not only explain but to show you in a pragmatic way how RIFE’s continuations and Terracotta is a perfect match with their common goal of power with simplicity. But don’t take my word for it, go on and read it yourself.

The Power of Sockets and Dynamic Proxies

2007-07-27T00:00:00+00:00

The Power of Sockets and Dynamic Proxies

I was going through some of the older parts of my darcs repository the other day when I stumbled upon a pretty neat and powerful little remoting library that I wrote back in 2001. It is based on dynamic proxies and plain sockets, almost legacy programming techniques nowadays in a world of BCI (bytecode instrumentation), AOP, EJBs, Terracotta etc.

Anyway, I thought that the implementation is fairly interesting (and useful) and would make good blog post.

It basically implements a remote proxy, that can either be instantiated by the client or instantiated by the server and sent to the client. In either case, when methods are invoked upon the proxy then they are executed on the server. The communication is socket-based and the server is holding a resizable thread pool that can grow and shrink based on usage. The beauty of using dynamic proxies is that once the proxy has been instantiated, the RPC is transparent, e.g. pretty much the same as with RMI but without all the stub and skeleton mess. Is a very simple library, not meant as a full RMI replacement, but does its job pretty well. I have used it among other things for:

getting a remote Hibernate Context in 5 lines of code
the remoting layer in a JNDI implementation
remote access to AspectWerkz aspects and mixins

So without further ado, let’s dive into some code. First, and most importantly, would be to take a look at how the remote proxy can be used from a client’s perspective.

This simple unit test is testing (and highlights) two basic features.

Create and use a client side remote proxy (that should create and use a matching instance on the server).
Let the server create a proxy and send it to the client which uses it.

public void testSimpleProxy() {

    // 1)
    // creates a new remote proxy for the POJOImpl1 class 
    // which maps to an instance of this class on the server
    RemoteProxy proxy1 = RemoteProxy.createClientProxy(
            new String[]{"test.POJO1"}, // interface(s)
            "test.POJOImpl1",  // implementation
            "localhost",       // server IP or hostname
            6663               // server port
    );
    // retrieves the POJOImpl1 instance
    POJO1 pojo1 = (POJO1) proxy1.getInstance();

    // 2)
    // invoke a method on the proxy (executed on the server)
    assertEquals("POJO1 here", pojo1.test());

    // 3)
    // retrieve the proxy that is created on the server
    RemoteProxy proxy2 = pojo1.getPOJO2();
    
    // retrieves the POJOImpl2 instance
    POJO2 pojo2 = (POJO2) proxy2.getInstance();

    // 4)
    // invoke a method on the proxy (executed on the server)
    assertEquals("POJO2 here", pojo2.test());

    // 5)
    // close the proxies (close() must always be called)
    proxy1.close();
    proxy2.close();
}

That was easy. So much for the client side.

How can we now create the server that serves these two proxies? The only thing we have to do is to create a RemoteProxyServer by passing in the class loader that we want to use to instantiate our proxied objects as well as an implementation of the Invoker interface (which has one single method called invoke), an interface that gives you the possibility to invoke methods on your proxied objects any way you want. This example simply shows the most basic way of doing it:

// create a remote proxy server with a simple Invoker impl
RemoteProxyServer remoteProxyServer = new RemoteProxyServer(
        classLoader,
        return new Invoker() {
            public Object invoke(String handle,
                                 String methodName,
                                 Class[] paramTypes,
                                 Object[] args,
                                 Object context) {
                Object result;
                try {
                    Object instance = RemoteProxy.getWrappedInstance(handle);
                    Method method = instance.getClass().getMethod(methodName, paramTypes);
                    result = method.invoke(instance, args);
                } catch (Exception e) {
                    throw new WrappedRuntimeException(e);
                }
                return result;
            }
        };);

// start all server threads
remoteProxyServer.start();

Let’s now dive into the implementation of the server a little bit. When we invoke remoteProxyServer.start() then the server starts up X worker threads (managed by a thread pool). The work done by of one of these thread is roughly – in pseudo code:

Get the object output and input streams
Loop:: read from input stream
- if command == CREATE: create an instance on the server and send a handle to the output stream
- else if command == INVOKE: grab the parameters, invoke the method and send the result to the output stream
- else if command == CLOSE: exit the thread

Here are some code excerpts, highlighting the algorithm:

public void run() {
    try {
        m_socket.setTcpNoDelay(true);
        m_socket.setSoTimeout(m_timeout);
        m_in = new ObjectInputStream(m_socket.getInputStream());
        m_out = new ObjectOutputStream(m_socket.getOutputStream());
    } catch (IOException e) {
        throw new WrappedRuntimeException(e);
    }
    while (m_running) {
        try {
            switch (m_in.read()) {
                case Command.CREATE:
                    handleCreateCommand();
                    break;
                case Command.INVOKE:
                    handleInvocationCommand();
                    break;
                case Command.CLOSE:
                    m_running = false;
                    break;
                default:
                    break;
            }
        } catch (Exception e) {
            close();
            throw new WrappedRuntimeException(e);
        }
    }
    close();
}

private void handleCreateCommand() 
        throws IOException, ClassNotFoundException,
        InstantiationException, IllegalAccessException {
    String className = (String) m_in.readObject();
    Class klass = Class.forName(className, false, m_loader);
    Object instance = klass.newInstance();
    // get a handle to the proxied instance
    String handle = RemoteProxy.wrapInstance(instance);
    m_out.writeObject(handle);
    m_out.flush();
}

private void handleInvocationCommand() 
        throws IOException, ClassNotFoundException {
    Object context = m_in.readObject();
    String handle = (String) m_in.readObject();
    String methodName = (String) m_in.readObject();
    Class[] paramTypes = (Class[]) m_in.readObject();
    Object[] args = (Object[]) m_in.readObject();
    Object result = null;
    try {
        result = m_invoker.invoke(handle, methodName, paramTypes, args, context);
    } catch (Exception e) {
        result = e; // pass the exception to the client
    }
    m_out.writeObject(result);
    m_out.flush();
}

If the client asks for a server created proxy, then the server would create it like this: RemoteProxy proxy = RemoteProxy.createServerProxy(myInstance, "localhost", 6663);, and write it to the object output stream – or even more simple have one of the already proxied objects create it (on the server) and return it (to the client).

This is pretty much the whole server. But if you’re still with me, I’m sure you’re eager to know what the RemoteProxy looks like. Well, here are some of the more interesting parts of its internals:

public class RemoteProxy implements InvocationHandler, Serializable {

    ... // constructors and field declarations are omitted

    /**
     * Creates a new proxy to a class. To be used on the client side to 
     * create a new proxy to an object.
     *
     * @param interfaces the name of the interfaces for the object to create the proxy for
     * @param impl       the name of the the impl class to create the proxy for
     * @param address    the address to connect to
     * @param port       the port to connect to
     * @param ctx        the context carrying the users principals and credentials
     * @param loader     the class loader to use for instantiating the proxy
     * @return the new remote proxy instance
     */
     public static RemoteProxy createClientProxy(String[] interfaces,
                                                String impl,
                                                String address,
                                                int port,
                                                Object context,
                                                ClassLoader loader) {
        return new RemoteProxy(interfaces, impl, address, port, context, loader);
    }

    ... // some factory methods are omitted

    /**
     * Look up and retrives a proxy to an object from the server.
     *
     * @return the proxy instance
     */
    public Object getInstance() {
        if (m_proxy != null) {
            return m_proxy;
        }
        if (m_loader == null) {
            m_loader = Thread.currentThread().getContextClassLoader();
        }
        try {
            m_socket = new Socket(InetAddress.getByName(m_address), m_port);
            m_socket.setTcpNoDelay(true);
            m_out = new ObjectOutputStream(m_socket.getOutputStream());
            m_in = new ObjectInputStream(m_socket.getInputStream());
        } catch (Exception e) {
            throw new WrappedRuntimeException(e);
        }
        if (m_handle == null) {
            // is a client side proxy
            if (m_targetInterfaceNames == null) {
                throw new IllegalStateException("interface class name can not be null");
            }
            if (m_targetImplName == null) {
                throw new IllegalStateException("implementation class name can not be null");
            }
            try {
                // create a new instance on the server and get the handle to it in return
                m_out.write(Command.CREATE);
                m_out.writeObject(m_targetImplName);
                m_out.flush();
                m_handle = (String) m_in.readObject();
                m_targetInterfaces = new Class[m_targetInterfaceNames.length];
                for (int i = 0; i < m_targetInterfaceNames.length; i++) {
                    try {
                        m_targetInterfaces[i] = Class.forName(
                            m_targetInterfaceNames[i], false, m_loader
                        );
                    } catch (ClassNotFoundException e) {
                        throw new WrappedRuntimeException(e);
                    }
                }
            } catch (Exception e) {
                throw new WrappedRuntimeException(e);
            }
        }

        // create and return a regular Java Dynamic Proxy
        m_proxy = Proxy.newProxyInstance(m_loader, m_targetInterfaces, this);
        return m_proxy;
    }

    /**
     * This method is invoked automatically by the proxy. Should not be called directly.
     *
     * @param proxy  the proxy instance that the method was invoked on
     * @param method the Method instance corresponding to the interface method invoked 
     *               on the proxy instance.
     * @param args   an array of objects containing the values of the arguments passed 
     *               in the method invocation on the proxy instance.
     * @return the value to return from the method invocation on the proxy instance.
     */
    public Object invoke(Object proxy, Method method, Object[] args) {
        try {
            m_out.write(Command.INVOKE);
            m_out.writeObject(m_context);
            m_out.writeObject(m_handle);
            m_out.writeObject(method.getName());
            m_out.writeObject(method.getParameterTypes());
            m_out.writeObject(args);
            m_out.flush();
            final Object response = m_in.readObject();
            if (response instanceof Exception) {
                throw (Exception) response;
            }
            return response;
        } catch (Exception e) {
            throw new WrappedRuntimeException(e);
        }
    }

    /**
     * Closes the proxy and the connection to the server.
     */
    public void close() {
        try {
            m_out.write(Command.CLOSE);
            m_out.flush();
            m_out.close();
            m_in.close();
            m_socket.close();
        } catch (IOException e) {
            throw new WrappedRuntimeException(e);
        }
    }
}

That’s all there is to it.

Ok, perhaps not as powerful and flexible as Spring Remoting, EJBs, RMI or Terracotta’s Network-Attached Memory.

But plain sockets and DPs are not so bad either. Or is it just me that’s being a bit sentimental? At least it was pretty cool stuff back in 2001 :-)

If you want to take a look at the code or are thinking of using it then you can check it out using this command (if you don’t have darcs installed you can get it here):

darcs get http://jonasboner.com/darcs/remoteproxy

Happy hacking.

Love What You Do

2007-07-04T00:00:00+00:00

Love What You Do

I was in Rome, Italy some weeks ago. After strolling around in the old town for a couple hours I felt the need to grab a bite. So I stopped at a cafÃ©, sat down and decided to order a pasta fettuccine and a glass of white.

The waiter, perhaps in his 50s, comes up to me and not only takes my order but treats me like a celebrity, like I was the only thing that mattered. It is hard to put the finger on it, but his charisma, the way he sets the table, folds the napkin, lays out the silverware, uses subtle gestures and facial expressions is close to perfection – truly a master of his craft. It a matter of minimalism and style, the way he pays attention to the tiniest detail. It really shines through that he takes pride in, and loves, his job.

We all have a lesson to learn here. If you feel stuck and trapped at work, not doing things you are passionate and care about, then I think you have two options:

Try to change your mind set. Care about your work. Set high bars, strive for perfection, pay attention to the details. Never settle — constantly try improve and challenge the way you work and think. Take pride in what you do and you will (hopefully) not only learn to love it, but people will notice and you will make a difference.
Or…quit and find something else to do.

Life is too short to spend 9-5 doing stuff you don’t love and are passionate about. Steve Jobs puts it very well in his Stanford University Commencement speech (video – transcription):

You’ve got to find what you love….for the past 33 years, I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something…almost everything – all external expectations, all pride, all fear of embarrassment or failure – these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

Love what you do.

How To Keep Your Creative Flow

2007-06-28T00:00:00+00:00

How To Keep Your Creative Flow

I recently saw an interview with Jan Guillou, one of the most successful and creative authors in Sweden. He had some interesting thoughts about creativity that I think applies to all pretty much an creative craft.

He is extremely structured and always does his writing in a predefined time box, when the time is up (triggered by an alarm clock or similar) he just stops typing, right in the middle of the sentence he was just typing.

I think there are two lessons learned here. I am myself a big fan of using time boxing to boost creativity and to force myself to eliminate the not so important stuff and focus on the essence, the things that will lead to actual progress. This holds both for writing, coding and meetings.

The second lesson is to stop right in the middle of an unfinished task. Doing that will help you to:

know exactly what you should do next (leaves no room for writer’s block or procrastination)
keep the context of what you just worked on and more easily “boot the system” and get into the creative flow that you had when you stopped

It reminds me of an advice Kent Beck gave in his book Test-Drived Development: In which he states that you should always stop coding with a failing test. This is the exact same idea; knowing what to start with when you come in to work the next morning, more easily loading in the “context into RAM” and forcing your self to become productive immediately.

Another, fairly controversial comment that I remember from the interview with Jan Guillou was:

Inspiration is for amateurs.

Although a bit arrogant, I think it is true and something that holds for most creative crafts. Inspiration is overrated, what matters is perseverance and creative talent (in that order). If you just start with whatever you are about to do, then inspiration will usually follow.

Invert Your Database Caching Dependency for Extreme Scalability

2007-06-27T00:00:00+00:00

Invert Your Database Caching Dependency for Extreme Scalability

Today most applications rely on a relational database (RDBMS) as its primary Service of Record (SoR) — the master copy of the data. But in order to minimize latencies in response time (from the database transaction roundtrips), most applications uses some sort of database cache in order to try to keep the data close to its processing context.

Database caches are most often seen deployed as the second-level cache in O/R mapping tools such as Hibernate or TopLink, but custom-built or general-purpose caches, like Ehcache and OScache, are also common. This architecture and design is proven, sound and has turned into the de facto standard way of building enterprise applications.

But does it really solve the problem? First, the cache can only help us with read-mostly data and second, we still have to struggle with the object/relational impedance mismatch.

The first step is to distinguish between temporary/intermediate/transient data and business-critical data. Where the former is the data that is needed/used in the process of doing a computation or keeping a conversation with the client etc., while the latter is the result of competition or the outcome of the client conversation (f.e. a completed order form). The latter naturally belongs in a RDBMS (for reporting, billing etc.) while the former is best kept persisted in memory (needed to for H/A) in some sort of cache (preferably backed up by Terracotta) — keeping the data close to its processing context. Unfortunately, many developers fail to do this distinction and end up shoveling everything down in the RDBMS, with a high latencies, bad throughput and more complicated and hard to maintain software as the result. So far no news.

But let me now propose an, in some ways, new and radical solution: Invert the RDBMS-Cache dependency.

Let the in-memory cache become the master SoR — which is persisted in memory using an appliances-like infrastructure service — like Terracotta’s Network-Attached Memory (NAM).
Keep a transaction log, which logs every modification to the in-memory data.
Let a low priority thread asynchronously process the transaction log every X minutes/seconds and serially execute the database transactions.
Treat the RDBMS as an “offline” data snapshot on which you can run the usual reporting and data mining tools â€“ needed for billing, weekly reports etc.
Since your SoR is now effectively persisted “on the network”, instead of in the RDBMS, you can without any further effort add as many nodes to process the data as you want, e.g. scale-out your application and to ensure high-availability.

I am not arguing that this is a general-purpose solution, and there are certainly cases where it will be very hard or impossible to implement due to either political or practical constraints (like need for real-time access to data in the RDBMS etc.). But it fits many more use-cases than you might think. Mainly requires a bit of courage and out-of-the-box thinking.

For those that have doubt; this is not vaporware but actually how some of Terracotta’s customers have used Terracotta’s NAM to solve their performance and scalability problems, and have been able to reach extreme scalability while keeping the simplicity of their POJO model intact.

Terracotta War Story:How We Clustered RIFE

2007-05-29T00:00:00+00:00

Terracotta War Story:How We Clustered RIFE

This is the story how Geert Bevin and I clustered RIFE with Terracotta.

The purpose of this blog post is to give an example of how JVM-level clustering of a nontrivial application can be done. Actually, clustering RIFE turned out to be much more challenging than we initially thought, mainly due to its extreme dynamicity, and I hope that our insights and solutions can be of value to someone trying to do a similar thing.

The first thing that we had to do in order to cluster RIFE with Terracotta was to cluster its continuations.

RIFEâ€™s continuations aims to make support for continuations in pure Java available as a general-purpose library, a library that can and is being used by other frameworks and tools. It is implementing continuations by allowing it to use regular Java methods to mark the execution flow to be suspended or resumed. It is using bytecode instrumentation (based on the ASM bytecode library) to generate code and redefine classes in order to implement this in the most effective way possible. It is not relying on Java serialization but is instead breaking down the object graph into primitives and stores the actual data on the execution stack (similar to the approach taken by Terracotta). This makes it very nonintrusive and simple to use, since you can work with POJOs with minimal interference from the continuations framework itself. The continuations are linked together in a tree structure which allows you to traverse to the different execution steps the way you want. This means that you can actually step back (and forward) in time, which is a very neat way of solving the browser back button problem – if used in the context of web applications.

Internally RIFE is storing its continuations in a regular java.util.HashMap:

private final Map mContexts = new HashMap();

This means that this map is a data structure that holds on to all the state that we want to cluster, something that makes it a perfect fit for becoming a Terracotta ‘root’, e.g. the top-level object in a shared/clustered object graph. So, we simply had to define the fully qualified name of the field that held on to this map as the ‘root’ in our Terracotta configuration:

<root>
  <field-name>
    com.uwyn.rife.continuations.ContinuationManager.mContexts
  </field-name>
  <root-name>mContexts</root-name>
</root>

That was quite simple. However, initially RIFE was designed to only access this map using a single thread, which allowed it (for performance reasons) to choose to not make it thread safe. Unfortunately, this is an assumption that does not hold when we are clustering the map with Terracotta since then you will have, not multi-threaded, but concurrent access from multiple JVMs. The promise of Terracotta is that it maintains the semantics of Java across the cluster which means that we need to guard our data correctly for concurrent access using Javaâ€™s concurrency primitives or abstractions, primitives and abstractions that Terracotta will maintain the semantics of across the cluster. In short, Terracotta requires you to write thread-safe code. What this boiled down to in practice was that we had to make the access and modifications to the map itself and all the continuations in the map guarded (using synchronized blocks). The simplest option would have been to swap the regular HashMap to a java.util.concurrent.ConcurrentHashMap, but since RIFE needs backward compatibility with Java 1.4, that was not an option. So after making the code thread-safe we could see the continuations effectively clustered by Terracotta. (Some readers might see that what we have actually done here is a simple way of cross-JVM thread migration.)

This works fine if all the clustered classes are loaded through Java’s system class loader (or the boot or ext class loaders) since that is a class loader that Terracotta knows about and can identify uniquely. But unfortunately, this is not the case if we are running in an application server since they are normally using a more or less complex hierarchy of class loaders that are specific to the application server itself. The reason why Terracotta needs to be able to uniquely define a class loader is that it needs a way of, at any point in time and on an arbitrary cluster-node, retrieve the class loader instance that has loaded a specific class in order to maintain object identity across the cluster. In the case of RIFE we had two class loaders – EngineClassLoader and TemplateClassLoader – that we had to enhance and make implement the NamedClassLoader interface in Terracotta:

public interface NamedClassLoader {
  public static final String CLASS = 
      "com/tc/object/loaders/NamedClassLoader";
  public static final String TYPE  = "L" + CLASS + ";";
  public String __tc_getClassLoaderName();
  public void __tc_setClassLoaderName(String name);
}

We also had to add code for the RIFE class loaders to register themselves in the Terracotta runtime:

public EngineClassLoader(ClassLoader parent) {
  com.tc.object.bytecode.hook.impl.ClassProcessorHelper.
      registerGlobalLoader(this);
}

Now for the biggest challenge; cluster the RIFE template engine. RIFE is relying heavily on on-the-fly class generation using bytecode instrumentation. This is extremely powerful, since it allows the user to to find what he wants to do in metadata (with heavy reliance on defaults) and then using that metadata together with templates to generate the actual classes dynamically on demand.

This extreme dynamicity imposed a lot of interesting challenges in terms of clustering. For example, if a user request comes in to a node (think application server or JVM), let’s call it Node1, and asks for for example the Order form. Then, if form does not yet exist, the template engine will do its job of introspecting the metadata and generate this class on-the-fly for us before it continues serving the user. Now imagine a scenario where Node1 crashes and the load balancer redirects the user to another node, let’s call it Node2. Then Terracotta will do its job of loading the Order class and instantiate a new Order instance before it pages in the state from that same instance on Node1. The problem is that this class is not available on Node2, it was generated at runtime on Node1. So we end up getting a ClassNotFoundException on Node2. Hmm, too bad. What to do about it?

The solution turned out to be quite simple. First we created an interface called BytecodeProvider:

public interface BytecodeProvider {
  /**
   * Returns the bytecode for a class with the name specified.
   *
   * @param className the name of the class who's bytecode 
   *             is missing
   * @return the bytecode for the class or NULL if bytecode is 
   *             not in the repository
   */
  public byte[] __tc_getBytecodeForClass(String className);
}

Then we modified RIFE’s TemplateClassLoader, which is the class that generates the templates in RIFE, to implement this interface:

â€¦
public byte[] __tc_getBytecodeForClass(final String className) {
  if (null == mBytecodeRepository) {
    return null;
  }		
  synchronized (mBytecodeRepository) {
    return mBytecodeRepository.get(getKeyFor(className));  
  }			    
}
â€¦

We also added a code snippet in the the Terracotta runtime to – in the case of a ClassNotFoundException – check if the class loader it tried to use to load a specific class implements this interface, and if it does use the __tc_getBytecodeForClass(String className) method to retrieve the bytes for the class, load it and go on from there:

â€¦
try {
  return Class.forName(className, false, loader);
} catch (ClassNotFoundException e) {
  if (loader instanceof BytecodeProvider) {
    BytecodeProvider provider = (BytecodeProvider) loader;
    byte[] bytes = provider.__tc_getBytecodeForClass(className);
    if (bytes != null && bytes.length != 0) { 
      return AsmHelper.defineClass(loader, bytes, className); 
    }
  }
  throw e;
}
â€¦

So far so good. But what about transferring the bytecode for one node to another, e.g. make it available to any node that needs it? Actually, this was fairly easily solved by using Terracotta itself. We added a HashMap in the implementor of the BytecodeProvider interface, e.g. the TemplateClassLoader, and made sure that as soon as a new class is generated on-the-fly, it is added to the map. After that, the only thing we had to do was to define this map as a shared Terracotta ‘root’ and we had a cluster wide bytecode repository ready to be used:

<root>
  <field-name>
    com.uwyn.rife.template.TemplateClassLoader.mBytecodeRepository
  </field-name>
  <root-name>mBytecodeRepository</root-name>
</root>

Ok, weâ€™re not really done yet, but close. There are some nitty-gritty details that we had to add to the configuration file in order to let Terracotta do its work. First a hint to use auto-locking (for details on lock configuration, see the official documention):

 
 <locks>
   <autolock>
     <method-expression>* *..*.*(..)</method-expression>
     <lock-level>write</lock-level>
   </autolock>
 </locks>

Then we also had to make shure that didn’t cluster more than we wanted to, e.g. that we cut the object graph at the appropriate places. This was done by declaring specific fields as ‘transient’:

<transient-fields>
  <field-name>com.uwyn.rife.continuations.ContinuationManager.mRandom</field-name>
  <field-name>com.uwyn.rife.engine.Gate.mInitException</field-name>
  <field-name>com.uwyn.rife.engine.RequestState.mResponse</field-name>
  <field-name>com.uwyn.rife.engine.RequestState.mInitConfig</field-name>
  <field-name>com.uwyn.rife.engine.ElementContext.mResponse</field-name>
  <field-name>com.uwyn.rife.engine.Site$SiteData.mResourceModificationTimes</field-name>
  <field-name>com.uwyn.rife.engine.Site$SiteData.mUrls</field-name>
  <field-name>com.uwyn.rife.servlet.RifeFilter.mClassloader</field-name>
  <field-name>com.uwyn.rife.servlet.HttpResponse.mResponse</field-name>
  <field-name>com.uwyn.rife.servlet.HttpRequest.mHttpServletRequest</field-name>
  <field-name>com.uwyn.rife.template.InternalString.mBytesValue_US_ASCII</field-name>
  <field-name>com.uwyn.rife.template.InternalString.mBytesValue_ISO_8859_1</field-name>
  <field-name>com.uwyn.rife.template.InternalString.mBytesValue_UTF_8</field-name>
  <field-name>com.uwyn.rife.template.InternalString.mBytesValue_UTF_16</field-name>
  <field-name>com.uwyn.rife.template.InternalString.mBytesValue_UTF_16BE</field-name>
  <field-name>com.uwyn.rife.template.InternalString.mBytesValue_UTF_16LE</field-name>
</transient-fields>

A bit ugly, but that is about it.

Finally, we wrapped everything up in a Terracotta Configuration Module which means that the only thing you need to do in order to cluster RIFE is to write a Terracotta configuration file that looks like this:

<tc:tc-config xmlns:tc="http://www.terracotta.org/config">
  <!-- ...system and server stuff... -->
  <clients>
    <modules>
      <module name="clustered-rife-1.6.0" version="1.0.0"/>
    </modules>
  </client>
</tc:tc-config>

That was a long story. I hoped that you learned something along the way. If not, at least try it out and enjoy the outcome of our efforts – it is actually quite a breeze to use.

Distributed Continuations for Java: RIFE and Open Terracotta

2007-04-16T00:00:00+00:00

Distributed Continuations for Java: RIFE and Open Terracotta

The last couple of years we have seen a new generation of Web frameworks with the ability to keep and maintain user specific conversational (stateful) state emerge in the enterprise. Among all these, I think that RIFE is one of the most interesting ones. It has a rich and coherent model for rapid development of Web applications. It also has its unique concept of continuations which provides a both rich, simplistic and intuitive programming model for implementing conversational workflows – a concept I think is applicable to a wide range of use-cases and technology areas, even outside Web development.

But the question is, how can we scale-out and ensure high-availability of these continuation based applications – and how can we do that while preserving its simplicity and semantics? It is here the recent collaboration between RIFE and Open Terracotta really shines. Open Terracotta does not force you to choose between simplicity and scale-out, but its JVM-level clustering allows RIFE applications to remain simple and pure POJO based while still getting all the advantages of unlimited scale-out and high-availability.

It is important to understand that RIFE Continuations is a completely stand-alone library (which can be used outside RIFE to implement all kinds of interesting stuff, from the declarative workflow used in RIFE itself to thread migration across JVMs (if used with Open Terracotta which can be used with solely the continuation library if needed). These ideas are currently being formalized into a JSR draft that have been submitted to the JCP, which – if accepted – would bring this very powerful concept into the JVM (or at least the JDK – depending on how it is implemented).

I am very excited about the work that I have had the opportunity to do with Geert Bevin in order to make this happen and think (and hope) that:

RIFE and Open Terracotta will be the number one application stack of choice for future enterprise Java web deployments.
Continuations in general will be better understood and get more traction in the Java space and help to continue to push the limits of Java.

The upcoming release of Open Terracotta will include a sample application with RIFE continuations clustered. But if you don’t want to wait you should be able to grab the latest sources from the RIFE and Open Terracotta SVN repositories build and run it yourself.

Enjoy.

Building Stateful, Scalable and Highly-Available Web Applications with Spring Web Flow and Open Terracotta

2007-04-03T00:00:00+00:00

Building Stateful, Scalable and Highly-Available Web Applications with Spring Web Flow and Open Terracotta

My and Eugene’s article on how to use Spring Web Flow together with Open Terracotta to build conversational, scalable and highly-available web applications has been published on InfoQ.

Now go ahead and read it :-)

Clustering the JVM using AOP: the Inner Workings of Terracotta DSO

2007-03-03T00:00:00+00:00

Clustering the JVM using AOP: the Inner Workings of Terracotta DSO

Our paper for AOSD 2007 has been published. It is titled ‘Clustering the Java Virtual Machine using Aspect-Oriented Programming’ and is a thorough and pragmatic discussion on how Terracotta’s JVM-level clustering technology is implemented from an AOP and bytecode weaving perspective. The discussion is driven by examples in AspectJ.

The paper is available for download here.

Clustering JRuby with Terracotta

2007-02-05T00:00:00+00:00

Clustering JRuby with Terracotta

Yesterday I was spending some time thinking about the possibilities to cluster applications written in JRuby with Terracotta.

Sounds like a crazy idea? Well, I don’t know. Perhaps it is. But thinking ahead a bit, with perhaps future deployments of Ruby on Rails applications etc. on JRuby makes it a bit more interesting.

Anyway, let’s give it a try.

Chatter sample application

First let’s start with writing a very simple chat application in JRuby.

require 'java'

class Chatter

  # set the name and create a List to hold our messages
  def initialize
    @name = ARGV[0]
    @messages = java.util.ArrayList.new
    puts "--- Hi #{@name}. Welcome to Chatter. Press Enter to refresh ---"
  end

  # takes text that the user enters
  # 1) if enter is pressed -> show the latest messages (refresh)
  # 2) if text is entered -> prepend the user name and add it to
  # the list of messages
  # 3) display the messages
  def run
    while true do
      print "Enter Text>>"
      text = STDIN.gets.chomp
      if text.length > 0 then
        @messages.add "[#{Time.now} -- #{@name}] #{text}"
        puts @messages
      else
        puts @messages
     end
    end
  end
end

Chatter.new.run

Run it

Now let’s run it.

--> jruby ./chat.rb Jonas 
                                                                                                  
--- Hi Jonas. Welcome to Chatter. Press Enter to refresh ---
Enter Text>>Hello. I am Jonas.
[[Fri Feb 02 11:57:56 CET 2007 -- Jonas] Hello. I am Jonas.
]
Enter Text>>Anybody there?
[[Fri Feb 02 11:57:56 CET 2007 -- Jonas] Hello. I am Jonas.
, [Fri Feb 02 11:58:01 CET 2007 -- Jonas] Anybody there?
]
Enter Text>>Ping...
[[Fri Feb 02 11:57:56 CET 2007 -- Jonas] Hello. I am Jonas.
, [Fri Feb 02 11:58:01 CET 2007 -- Jonas] Anybody there?
, [Fri Feb 02 11:58:25 CET 2007 -- Jonas] Ping...
]
Enter Text>>hmmm, no, seems to be just me
[[Fri Feb 02 11:57:56 CET 2007 -- Jonas] Hello. I am Jonas.
, [Fri Feb 02 11:58:01 CET 2007 -- Jonas] Anybody there?
, [Fri Feb 02 11:58:25 CET 2007 -- Jonas] Ping...
, [Fri Feb 02 11:58:59 CET 2007 -- Jonas] hmmm, no, seems to be just me
]
Enter Text>>

Of course, this application is completely useless. It is in process, single threaded and only recieves input from STDIN, which means that it can only be used by one single user at a time.

But, what if we could make a single instance of the @messages list available on the network and then run multiple instances of the application (each on its own JVM instance, even on multiple machines) and have each one of them use this shared list?

This would solve our problem and this in actually exactly what Terracotta could [conceptually] do for us. But Terracotta is a Java infrastructure service without any bindings or support for JRuby. So how can we proceed?

Terracotta for JRuby

I can see two different ways we can bridge JRuby and Terracotta:

Create a pattern language

We could hook into and extend the Terracotta pattern matching language (the language that is used to pick out the shared state and the methods modifying it) to support the Ruby syntax. This would mean allowing the user to define the patterns based on the Ruby language but then, under the hood, actually map the Ruby syntax to the real Java classes that are generated by JRuby (this assumes using the compiler and not the interpreter). The benefit here is that it would be “transparent”, in the same way as it is for regular Java applications. This is perhaps the best solution long term, but requires quite a lot of work and requires a fully working JRuby compiler. The development of the JRuby compiler has just started. When I tried it today it did not even compile the samples shipped with the distribution, so the Terracotta support for the compiler naturally has to wait until the implementation gets more complete and stable.

Create a JRuby API

The minimal set of abstractions we need in this API is:

1. State sharing: Be able to pick out the state that should be shared – e.g. the top level “root” object of a shared object graph
2. State guarding: Be able to safely update this graph within the scope of a transaction

Ok, let’s try to design this API.

Designing the JRuby API

Most people are probably not aware of that Terracotta actually has an API that can do all this (and much more) for us. It is well hidden in the SVN repository and is used internally as the API for the hooks, added to the target application during the bytecode instrumentation process, to call.

The class in question is the: ManagerUtil.

So, everything we need is in the ManagerUtil class. But before we roll up our sleeves and start hacking on the glue code, let’s take a step back and think through what we want out of the API from a user’s perspective.

First we need to be able to create a “shared root”, e.g. create a top-level instance of a shared object graph. One way of doing it would be to create some sort of factory method that can do the heavy lifting for us, similar to this:

@messages = createRoot java.util.ArrayList.new

Here we told some factory method createRoot to create a root instance of the type java.util.ArrayList. Seems reasonable I think.

The other thing we need to do is to create some sort of transactions. We want to be able to start a transaction, lock the [shared] instance being updated, update it, unlock the instance and finally commit the transaction. Here is some basic pseudo code:

lock target
    transaction begin
        modify target
    transaction commit
unlock target

All steps except ‘modify target’ is done by infrastructure code. Code that has nothing to do with your business logic, code that we want to eliminate and “untangle” as much as possible.

In Ruby, a common design pattern to accomplish this is to use a method that takes a block/closure. Using this pattern we could design the API to look something like this:

guard @messages do
  @messages.add msg
end

Here the semantics are:

the @messages list is guarded for concurrent access (both in a single JVM or in the cluster)
the ‘do’ keyword takes the lock (on @messages) and initiates the transaction (unit of work)
all updates to @messages that are done within the ‘do-end’ block are recorded in a change set (and are guaranteed to be done in isolation)
when the ‘end’ of the block is reached then the transaction is committed, the change set is replicated and the lock (on @messages) is released

Implementing the JRuby API

Now, let’s take a look at the ManagerUtil class. It has a lot of useful stuff but the methods that we are currently interested in has the following signatures:

Object lookupOrCreateRoot(String rootName, Object object);
void monitorEnter(Object obj, int lockType);
void monitorExit(Object obj);

Based on these methods we can create the following JRuby module implementing the requirements we outlined above (and let’s put it in a flle called ‘terracotta.rb’ to be able to easily include it into the applications we want) :

# Usage:
#
# # create an instance of 'foo' as a DSO root this
# # means that it will be shared across the cluster
# foo = DSO.createRoot "foo", Foo.new
#
# # update 'foo' in a guarded block, get result back
# result = DSO.guard foo, DSO::WRITE_LOCK do
#   foo.add bar
#   foo.getSum
# end

TC = com.tc.object.bytecode.ManagerUtil

module DSO

  # The different lock types
  WRITE_LOCK = com.tc.object.bytecode.Manager::LOCK_TYPE_WRITE
  READ_LOCK = com.tc.object.bytecode.Manager::LOCK_TYPE_READ
  CONCURRENT_LOCK = com.tc.object.bytecode.Manager::LOCK_TYPE_CONCURRENT

  # Creates a Terracotta shared root, 'name' is the name of the root
  # (can be anything that uniquily defines the root), 'object' is an
  # instance of the object to be shared. If the root the given name
  # already exists it simply returns it.
  def DSO.createRoot(name, object)
    guardWithNamedLock name, WRITE_LOCK do
      TC.lookupOrCreateRoot name, object
    end
  end

  # Creates a transaction and guards the object (passed in as the
  # 'object' argument) during the execution of the block passed into
  # the method. Similar to Java's synchronized(object) {...} blocks.
  # Garantuees that the critical section is maintained correctly across
  # the cluster. The type of the lock can be one of: DSO:WRITE_LOCK,
  # DSO::READ_LOCK or DSO::CONCURRENT_LOCK (default is DSO:WRITE_LOCK).
  def DSO.guard(object, type = WRITE_LOCK)
    TC.monitorEnter object, type
    begin
      yield
    ensure
      TC.monitorExit object
    end
  end

  # Creates a transaction and guards the critical section using a virtual
  # so called 'named lock. It is held during the execution of the block
  # passed into the method. Garantuees that the critical section is
  # maintained correctly across the cluster. The type of the lock can
  # be one of: DSO:WRITE_LOCK, DSO::READ_LOCK or DSO::CONCURRENT_LOCK
  # (default is DSO:WRITE_LOCK)8.
  def DSO.guardWithNamedLock(name, type = WRITE_LOCK)
    TC.beginLock name, type
    begin
      yield
    ensure
      TC.commitLock name
    end
  end

  # Dispatches a Distributed Method Call (DMI). Ensures that the
  # particular method will be invoked on all nodes in the cluster.
  def DSO.dmi(object, methodName, arguments)
    TC.distributedMethodCall object, methodName, arguments
  end
end

The ManagerUtil has a whole bunch of other useful and cool methods, such as for example optimisticBegin, optimiticCommit and deepClone for creating optimistic concurrency transactions, etc. But I’ll leave these for a later blog post.

Creating a distributed version of the Chatter application

Great. Now we have a JRuby API with all the abstractions needed to create a distributed version of our little chat application. What we have to do is simply to create the @messsages variable using the factory method for creating roots in the API. Then we also have to make sure that we guard the updating of the shared java.util.ArrayList using a guarded block.

Let’s take a look at the final version of the application.

require 'java'
load 'terracotta.rb'

class Chatter
  def initialize
    @name = ARGV[0]
    @messages = DSO.createRoot "chatter", java.util.ArrayList.new
    puts "--- Hi #{@name}. Welcome to Chatter. Press Enter to refresh ---"
  end

  def run
    while true do
      print "Enter Text>>"
      text = STDIN.gets.chomp
      if text.length > 0 then
        DSO.guard @messages do
          @messages.add "[#{Time.now} -- #{@name}] #{text}"
          puts @messages
        end
      else
        puts @messages
     end
    end
  end
end

Chatter.new.run

Pretty simple and fairly intuitive, right?

Note 1: Actually, we could have made it even more simple if we had taken a java.util.concurrent.LinkedBlockingQueue instead of a regular java.util.ArrayList as the list to hold our messages. If we would have done that then we could have skipped the DSO.guard block altogether since the Java concurrency abstractions are natively supported by Terracotta. But then I would have missed the opportunity to show you how to handle non-thread-safe data access.

Note 2: It currently only works for sharing native Java classes. In other words, you can currently not cluster native JRuby constructs since it would mean cluster the internals of the JRuby interpreter (which is a lot of work and most likely not possible without rewriting parts of the interpreter). However, one feasible approach would be to not use the JRuby interpreter but the JRuby compiler and cluster its generated Java classes – but unfortunately the compiler is not ready for general use yet (see the footnote at the bottom).

Enable Terracotta for JRuby

In order to enable Terracotta for JRuby we have to add a couple of JVM options to the startup of our application, or add them directly in the jruby.(sh|bat) script.

You have to change:

java -jar jruby.jar chat.rb

to:

java -Xbootclasspath/p:[path to terracotta boot jar] \
     -Dtc.config=path/to/your/tc-config.xml \
     -Dtc.install-root=[path to terracotta install dir] \
     -jar jruby.jar chat.rb

I know what you are thinking:

“Hey! What’s up with that tc-config.xml file? Do I have to write that? I hate XML!”

Yes, unfortunately you have to feed Terracotta with a tiny bit of XML. This can perhaps be eliminated in the future (and replaced with a couple of command line options more or a JRuby config). But for now you have to write an XML file that looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<tc:tc-config xmlns:tc="http://www.terracotta.org/config">
  <servers>
    <server name="localhost"/>
  </servers>
  <clients>
    <logs>%(user.home)/terracotta/jtable/client-logs</logs>
  </clients>
  <application>
    <dso>
      <instrumented-classes>
        <include>
          <class-expression>*..*</class-expression>
        </include>
      </instrumented-classes>
    </dso>
  </application>
</tc:tc-config>

As you can see it contains the name of the server where the Terracotta server resides, the path to the logs and a statement that says; include all classes for instrumentation. That’s it.

Now let’s run it.

Run the distributed Chatter

Here is an sample of me trying it out with my wife Sara. It shows my session window:

--> jruby ./chat.rb Jonas         

--- Hi Jonas. Welcome to Chatter. Press Enter to refresh ---
Enter Text>>Hi there. Is it working?
[[Fri Feb 02 13:07:19 CET 2007 -- Jonas] Hi there. Is it working?
]
Enter Text>>
[[Fri Feb 02 13:07:19 CET 2007 -- Jonas] Hi there. Is it working?
, [Fri Feb 02 13:08:09 CET 2007 -- Sara] I think so, I could see your message when I clicked Enter
]
Enter Text>>Awesome!! Isn't this amazingly cool? Terracotta rocks!
[[Fri Feb 02 13:07:19 CET 2007 -- Jonas] Hi there. Is it working?
, [Fri Feb 02 13:08:09 CET 2007 -- Sara]  I think so, I could see your message when I clicked Enter
, [Fri Feb 02 13:08:59 CET 2007 -- Jonas] Awesome!! Isn't this amazingly cool? Terracotta rocks!
]
Enter Text>>
[[Fri Feb 02 13:07:19 CET 2007 -- Jonas] Hi there. Is it working?
, [Fri Feb 02 13:08:09 CET 2007 -- Sara]  I think so, I could see your message when I clicked Enter
, [Fri Feb 02 13:08:59 CET 2007 -- Jonas] Awesome!! Isn't this amazingly cool? Terracotta rocks!
, [Fri Feb 02 13:10:17 CET 2007 -- Sara] What do you mean? This is it? 
]
Enter Text>>Well, yeah...
[[Fri Feb 02 13:07:19 CET 2007 -- Jonas] Hi there. Is it working?
, [Fri Feb 02 13:08:09 CET 2007 -- Sara]  I think so, I could see your message when I clicked Enter
, [Fri Feb 02 13:08:59 CET 2007 -- Jonas] Awesome!! Isn't this amazingly cool? Terracotta rocks!
, [Fri Feb 02 13:10:17 CET 2007 -- Sara] What do you mean? This is it? 
, [Fri Feb 02 13:10:36 CET 2007 -- Jonas] Well, yeah...
]
Enter Text>>

Well, I hope that you find it a bit more exciting…

Feel like helping out? Drop me a line.

And one more thing…

I also had some fun porting the JTable sample in the Terracotta distribution. It worked out nicely. I only had one problem and that was that I encountered a JRuby bug when trying to create a multi-dimensional java.lang.Object array. I was able to work around the bug by creating the array using reflection, but this unfortunately had the effect of making the final code much longer. Anyway, here is the code in case you want to try it out:

require 'java'
load 'terracotta.rb'

# need to create the object arrays using reflection
# due to a bug in JRuby
tableHeader = java.lang.Object[].new(4)
tableHeader[0] = "Time"
tableHeader[1] = "Room A"
tableHeader[2] = "Room B"
tableHeader[3] = "Room C"
dim = java.lang.reflect.Array.newInstance(java.lang.Integer::TYPE, 2)
java.lang.reflect.Array.setInt(dim, 0, 9)
java.lang.reflect.Array.setInt(dim, 1, 3)
tableData = java.lang.reflect.Array.newInstance(java.lang.Object, dim)
tableData[0][0] = "9:00"
tableData[1][0] = "10:00"
tableData[2][0] = "11:00"
tableData[3][0] = "12:00"
tableData[4][0] = "1:00"
tableData[5][0] = "2:00"
tableData[6][0] = "3:00"
tableData[7][0] = "4:00"
tableData[8][0] = "5:00"

# create the model as a DSO root
model = DSO.createRoot "jtable.model", javax.swing.table.DefaultTableModel.new(tableData, tableHeader)

table = javax.swing.JTable.new(model)
frame = javax.swing.JFrame.new "Table Demo"
frame.getContentPane().add(javax.swing.JScrollPane.new(table))
frame.setDefaultCloseOperation javax.swing.JFrame::EXIT_ON_CLOSE
frame.setSize 500, 200
frame.pack
frame.setVisible true

How to Build a POJO-based Data Grid using Terracotta

2007-01-29T00:00:00+00:00

How to Build a POJO-based Data Grid using Terracotta

Introduction

In this article, I will show you step by step how you can build a reusable POJO-based Data Grid with nothing but standard JDK *5 and then make it distributed through the use of the declarative JVM-level clustering technology provided by [Terracotta](http://terracotta.org).

The article is divided into three sections:

In the first section I will talk about the concepts of Data Grids, what they are and what they do. I will discuss some of the underlying mechanisms that are used in Data Grids and finally how one can scale out applications on a Data Grid.
The second section will walk you through how to build a naive but fully usable implementation of a POJO-based Data Grid by implementing a multi-threaded Master/Worker container and cluster it using Terracotta’s JVM-level clustering technologies.
Last, in the third section I will show you how to extend the initial implementation to handle real-world requirements such as dealing with; high volumes of data, work failure, different routing algorithms, ordering of work and worker failure.

Part 1: Data Grids – What’s behind the buzzwords?

What are Data Grids?

A Data Grid is a set of servers that together creates a mainframe-class processing service where data and operations can move seamlessly across the grid in order to optimize the performance and scalability of the computing tasks submitted to the grid. A Data Grid scales through use of Locality of Reference (see the section “How do Data Grids scale?”) and is highly-available through effective use of data duplication. It combines data management with data processing.

What are Data Grids used for?

Applications that could benefit from being run on a Data Grid are usually applications that needs to work on large data sets and/or have a need to parallelize processing of the data in order to get better throughput and performance. Examples are financial risk analysis and other simulations, searching and aggregation on large datasets as well as sales order pipeline processing.

How do Data Grids scale?

One of the main reasons why Data Grids can scale so well is that they can make intelligent choices if it should move data to its processing context or moved the processing context (the operations) to the data. Effective use of the latter means that it can make use of Locality of Reference; this means that data that is being processed on a specific node stays local to that node and will in the ideal case never have to leave that node. Instead, all operations that are working on this specific data set will always be routed to this specific node.

The immediate benefits are that it has the advantage of minimizing the latency and can in the ideal case give unlimited and linear scalability. How well it scales is of course use-case specific, and it can take both effort and skills in partitioning the data and work sets, as well as potential routing algorithms. The ultimate (and simplest) situation is when all work are what we call Embarrassingly Parallel – which means that it has no shared state and can to its working complete isolation. But it is in most cases acceptable to partition the work into work sets, in such a way that the work sets have no shared state. However, the latter solution might need some intelligent routing algorithms, something that we will take a look at later.

How do Data Grids deal with failure?

Data Grids are resilient to failure and down time by effective use of data duplication. Data Grids can be seen as an organic system of cells (nodes) that is designed to not only handle, but expect failure of individual cells (nodes). This is very different from traditional design of distributed systems in which each node is seen as an isolated unit which must always expect the worst and protect itself accordingly. See this page) for a more thorough discussion on the subject.

Part 2: Build a multi-threaded Master/Worker container and cluster it with Terracotta

What is the Master/Worker pattern?

The Master/Worker pattern is a pattern that is heavily used in Data Grids and is one of the most well-known and common patterns for parallelizing work. We will now explain the characteristics of the pattern and then go through the possible approaches for a Java implementation.

So, how does it work?

The Master/Worker pattern consists of three logical entities: a Master, a Shared Space and one or more instances of a Worker. The Master initiates the computation by creating a set of tasks, puts them in some shared space and then waits for the tasks to be picked up and completed by the Workers. The shared space is usually some sort of Shared Queue, but it can also be implemented as a Tuple Space (for example in Linda programming environments, such as JavaSpaces, where the pattern is used extensively). One of the advantages of using this pattern is that the algorithm automatically balances the load. This is possible due to the simple fact that, the work set is shared, and the workers continue to pull work from the set until there is no more work to be done. The algorithm usually has good scalability as long as the number of tasks, by far exceeds the number of workers and if the tasks take a fairly similar amount of time to complete.

Possible approaches in Java

Let’s now look at the different alternatives we have for implementing this in Java. There might be more ways of doing it, but we will focus the discussion on three different alternatives, each one with a higher abstraction level.

Using Java’s threading primitives

The most hard-core approach is to use the concurrency and threading primitives that we have in the Java Language Specification (JLS), e.g. wait/notify and the synchronized and volatile keywords. The benefits are that everything is really “under your fingers”, meaning that you could customize the solution without limitations. However, this is also its main problem, since it is both a very hard and tedious to implement this yourself, and will most likely be even worse to maintain. These low-level abstractions is not something that you want to work with on a day-to-day basis. We need to raise the abstractions level above the core primitives in the Java Memory Model and that is exactly what the data structure abstractions in the java.util.concurrent library in JDK *5 does for us.

Using the java.util.concurrent abstractions

Given that using the low-level abstractions in JLS is both tedious and hard to use, the concurrency abstractions in JDK *5 was both a very welcome and natural addition to the Java libraries. It is a very rich API that provides everything from semaphores and barriers to implementations of the Java Collections data structure interfaces highly tuned for concurrent access. It also provides an ExecutorService, which is mainly a thread pool that provides direct support for the Master/Worker pattern. This is very powerful, since you’re basically getting support from the Master/Worker pattern in a single abstraction.

It is possible to cluster the ExecutorService using Terracotta, you can read about that exercise in this article. Even though this approach would be sufficient in many situations and use-cases it has some problems:

First, it does not separate the master from the worker (since they are both part of the same abstraction). What this means in practice is that you cannot scale out that the master independently of the worker but each node will contain both a master and a worker.

Second, and perhaps even more important, is that it is lacking a layer of reliability and control. Meaning that it is no way of knowing if a specific work task has been started, completed or if it has been rejected due to some error. This means that there is no way we can detect work failure and can retry the work task on the same node or on another node. So we need a way to deal with these things in a simple and if possible standardized way.

Using the CommonJ WorkManager specification

Spawning and coordinating threads is something that have been prohibited by the EJB specification. However, there has naturally been (and still is) a common need for coordinating work in JEE (something that was partly, but not completely solved in a very verbose way with Message-Driven Beans (MDB)). This need was the main motivation why IBM and BEA decided to do a joint specification that solves this problem by providing a standardized way of executing concurrent tasks in a JEE environment. The specification is called CommonJ and has support for the Master/Worker pattern in its WorkManager API.

From BEA’s documentation about the specification:

“The Work Manager provides a simple API for application-server-supported concurrent execution of work items. This enables J2EE-based applications (including Servlets and EJBs) to schedule work items for concurrent execution, which will provide greater throughput and increased response time. After an application submits work items to a Work Manager for concurrent execution, the application can gather the results. The Work Manager provides common “join” operations, such as waiting for any or all work items to complete. The Work Manager for Application Servers specification provides an application-server-supported alternative to using lower-level threading APIs, which are inappropriate for use in managed environments such as Servlets and EJBs, as well as being too difficult to use for most applications."

What is interesting is that specification not only defines an API for submitting work and getting the result back, but it also provides functionality for tracking work status in that it allows you to register listener that will receive callback events whenever the state of the work has been changed. This makes it possible to for example not only detect work failure but also the reason why it failed, which gives us a possibility of restarting the work.

Each of the three approaches we have looked at so far have been built upon the previous one and has gradually raised the abstraction level. But even more importantly minimized and simplified the code that we as users have to write and maintain.

The most natural choice is to base our implementation on the CommonJ WorkManager specification. It is a simple and minimalistic specification and seems to provide everything that we need in order to build a reliable Master/Worker container.

Here are the interfaces in the specification:

public interface Work extends Runnable { }

public interface WorkManager {
  WorkItem schedule(Work work);
  WorkItem schedule(Work work, WorkListener listener);
  boolean waitForAll(Collection workItems, long timeout);
  Collection waitForAny(Collection workItems, long timeout);
}

public interface WorkItem {
  Work getResult();
  int getStatus();
}

public interface WorkListener {
  void workAccepted(WorkEvent we);
  void workRejected(WorkEvent we);
  void workStarted(WorkEvent we);
  void workCompleted(WorkEvent we);
}

public interface WorkEvent {
  int WORKACCEPTED  = 1;
  int WORKREJECTED  = 2;
  int WORKSTARTED   = 3;
  int WORKCOMPLETED = 4;
  public int getType();
  public WorkItem getWorkItem();
  public WorkException getException();
}

The Plan

The plan is that we will first implement the specification as a regular multi-threaded application using the java.util.concurrent abstractions (in particular the ExecutorService and the LinkedBlockingQueue classes) and then use Terracotta to declaratively (and transparently), turn it into a multi-JVM, distributed implementation.

Creating the Master (WorkManager)

We start with creating the SingleQueueWorkManager, which serves as our Master. It implements the CommonJ WorkManager interface which provides the API that the user uses to schedule the Work and wait for the Work to be completed. It has a reference to the work queue that is shared between the Master and the Workers, in this case represented by the SingleWorkQueue abstraction.

Here is how we could implement the work manager:

public class SingleQueueWorkManager implements WorkManager {

private final SingleWorkQueue m_queue;

  public SingleQueueWorkManager(final SingleWorkQueue queue) {
    m_queue = queue;
  }

  public WorkItem schedule(final Work work) throws WorkException {
    DefaultWorkItem workItem = new DefaultWorkItem(work, null);
    m_queue.put(workItem);
    return workItem;
  }

  public WorkItem schedule(final Work work, final WorkListener listener)
      throws WorkException {
    DefaultWorkItem workItem = new DefaultWorkItem(work, listener);
    m_queue.put(workItem);
    return workItem;
  }

  public boolean waitForAll(Collection workItems, long timeout) {
    long start = System.currentTimeMillis();
    do {
      boolean isAllCompleted = true;
      for (Iterator it = workItems.iterator();
           it.hasNext() && isAllCompleted;) {
        int status = ((WorkItem) it.next()).getStatus();
        isAllCompleted =
            status == WorkEvent.WORKCOMPLETED ](](
            status == WorkEvent.WORKREJECTED;
      }
      if (isAllCompleted) { return true; }
      if (timeout == IMMEDIATE) { return false; }
      if (timeout == INDEFINITE) { continue; }
    } while ((System.currentTimeMillis() - start) < timeout);
    return false;
  }

  public Collection waitForAny(Collection workItems, long timeout) {
    long start = System.currentTimeMillis();
    do {
      synchronized (this) {
        Collection completed = new ArrayList();
        for (Iterator it = workItems.iterator(); it.hasNext();) {
          WorkItem workItem = (WorkItem) it.next();
          if (workItem.getStatus() == WorkEvent.WORKCOMPLETED ](](
              workItem.getStatus() == WorkEvent.WORKREJECTED) {
            completed.add(workItem);
          }
        }
        if (!completed.isEmpty()) { return completed; }
      }
      if (timeout == IMMEDIATE) { return Collections.EMPTYLIST; }
      if (timeout == INDEFINITE) { continue; }
    } while ((System.currentTimeMillis() - start) < timeout);
    return Collections.EMPTYLIST;
  }
}

Creating the Shared Queue

The SingleQueueWorkManager schedules work by adding work to the SingleWorkQueue. The SingleWorkQueue is the artifact that has state that needs to be shared between the Master and the Workers, since it holds the queue with all the pending Work. We need to have a single instance of this queue that can be available to both the Master and all its Workers.

The work queue can be implemented like this:

public class SingleWorkQueue {

  // Terracotta Shared Root
  private final BlockingQueue m_workQueue =
      new LinkedBlockingQueue();

  public void put(final DefaultWorkItem workItem) throws WorkException {
    try {
      mworkQueue.put(workItem); // blocks if queue is full
    } catch (InterruptedException e) {
      e.printStackTrace();
      WorkRejectedException we = new WorkRejectedException(e.getMessage());
      workItem.setStatus(WorkEvent.WORKREJECTED, we);
      Thread.currentThread().interrupt();
      return we;            }
  }

  public DefaultWorkItem peek() throws WorkException {
    return m_workQueue.peek(); // returns null if queue is empty
  }

  public DefaultWorkItem take() throws WorkException {
    try {
      return m_workQueue.take(); // blocks if queue is empty
    } catch (InterruptedException e) {
      Thread.currentThread().interrupt();
      throw new WorkException(e);
    }
  }
}

As you can see, it is a simple wrapper around a java.util.concurrent.BlockingQueue queue and has three methods; take(), put() and peek() which simply delegates to the BlockingQueue but also adds error handling in that it sets the status for the Work in case of failure.

Creating the Worker

Finally, we have the Worker, in our case represented by the SingleQueueWorker abstraction. This class uses a thread pool to spawn up N number of worker threads that continuously grabs and executes Work from the SingleWorkQueue. During the processing of the Work, the status flag in the wrapping WorkItem is maintained (can be one of either ACCEPTED, STARTED, COMPLETED or REJECTED). This is needed in order for the SingleQueueWorkManager to be able to continuously monitor the status of the Work it has scheduled.

This is what a Worker implementation can look like. As you can see we choose to make use of the ExecutorService thread pool implementation in the java.util.concurrent package:

public class SingleQueueWorker implements Worker {

  protected final ExecutorService mthreadPool = Executors.newCachedThreadPool();
  protected final SingleWorkQueue mqueue;
  protected volatile boolean m_isRunning = true;

  public SingleQueueWorker(final SingleWorkQueue queue) {
    m_queue = queue;
  }

  public void start() throws WorkException {
    while (misRunning) {
      final DefaultWorkItem workItem = mqueue.take();
      final Work work = workItem.getResult();
      mthreadPool.execute(new Runnable() {
        public void run() {
          try {
            workItem.setStatus(WorkEvent.WORKSTARTED, null);
            work.run();
            workItem.setStatus(WorkEvent.WORKCOMPLETED, null);
          } catch (Throwable e) {
            workItem.setStatus(
                WorkEvent.WORKREJECTED, new WorkRejectedException(e));
          }
        }
      });
    }
  }

  public void stop() {
    misRunning = false;
    mthreadPool.shutdown();
  }
}

What about my Work?

Now we have the three main artifacts in place; the Master, the Worker and the Shared Queue. But what about this Work abstraction and which role does the DefaultWorkItem play?

Starting with the Work abstraction. It is an interface in the CommonJ WorkManager specification but is an interface that we cannot implement generically in the WorkManager “container” we are building now, but should be implemented by the user of this container since the implementation of the actual work that is supposed to be done is of course use-case specific.

The DefaultWorkItem is an implementation of the WorkItem interface in the specification. It’s purpose is simply to wrap a Work instance and provide additional information, such as status and an optional WorkListener and can look something like this:

public class DefaultWorkItem implements WorkItem {

private volatile int mstatus;
  private final Work mwork;
  private final WorkListener m_workListener;

  public DefaultWorkItem(final Work work, final WorkListener workListener) {
    mwork = work;
    mstatus = WorkEvent.WORKACCEPTED;
    mworkListener = workListener;
  }

  public Work getResult() {
    return m_work;
  }

  public synchronized void setStatus(
      final int status, final WorkException exception) {
    mstatus = status;
    if (mworkListener != null) {
      switch (status) {
        case WorkEvent.WORKACCEPTED:
          mworkListener.workAccepted(
              new DefaultWorkEvent(WorkEvent.WORKACCEPTED, this, exception));
          break;
        case WorkEvent.WORKREJECTED:
          mworkListener.workRejected(
              new DefaultWorkEvent(WorkEvent.WORKREJECTED, this, exception));
          break;
        case WorkEvent.WORKSTARTED:
          mworkListener.workStarted(
              new DefaultWorkEvent(WorkEvent.WORKSTARTED, this, exception));
          break;
        case WorkEvent.WORKCOMPLETED:
          mworkListener.workCompleted(
              new DefaultWorkEvent(WorkEvent.WORKCOMPLETED, this, exception));
          break;
      }
    }
  }

  public synchronized int getStatus() {
    return m_status;
  }
  ... // remaining methods omitted (toString() and compareTo())
}

A WorkListener is a listener that the user can register in order to track the status of the work and can upon reception of a state-changed-event take proper action (like retry upon failure etc.)

That’s it, now we now have a fully functional single-JVM, multi-threaded, implementation of the CommonJ WorkManager specification. Even thought this could be useful as is, there is no way we can scale it out with the needs of the application, since we are bound by the computing power in the single box we are using. Plus, it is not topic for the article. So, let’s make it a bit more interesting.

Introducing Terracotta

Terracotta is a product that delivers JVM-level clustering as a runtime infrastructure service. It is Open Source and available under a Mozilla-based license.

Terracotta uses bytecode instrumentation to adapt the target application at class load time. In this phase it extends the application in order to ensure that the semantics of the Java Language Specification (JLS) are correctly maintained across the cluster, including object references, thread coordination, garbage collection etc.

Another important thing to mention is that Terracotta does not use Java Serialization, which means that any POJO can be shared across the cluster. What this also means is that Terracotta is not sending the whole object graph for the POJO state to all nodes but breaks down the graph into pure data and is only sending the actual “delta” over the wire, meaning the actual changes – the data that is “stale” on the other node(s).

Terracotta is using an architecture known as hub-and-spoke, which means that it has one central L2 server and N number of L1 clients. (The L1 client is the Terracotta client JARs running inside the target JVM, while the L2 server is the central Terracotta server. L1 and L2 refers to first and second level caches.)

This might seem strange, since most clustering solutions on the market today are using peer-to-peer, but as we will see, hub-and-spoke has some advantages and makes it possible to do some very interesting optimizations. The server plays two different roles:

First it serves as the coordinator (“the traffic cop”) in the cluster. It keeps track of things like; which thread in which node is holding which lock, which nodes are referencing which part of the shared state, which objects have not been used for a specific time period and can be paged out, etc. Keeping all this knowledge in one single place is very valuable and allows for very interesting optimizations.

Second, it serves as a dedicated state Service of Record (SoR), meaning that it stores all the shared state in the cluster. The state server does not know anything about Java, but only stores the bytes of the data that has changed plus a minimal set of meta info. The L2 server itself is clusterable through a SAN-based failover mechanism. This means that it is possible to scale-out the L2 server in the same fashion as most peer-to-peer solutions but with the advantage of keeping the L2 separate from the L* This separation allows us to scale out the L1 clients and the L2 servers independently of each other, which is the way that the Internet scales.

One way of looking at Terracotta is to see it as Network Attached Memory=* Network Attached Memory (NAM) is similar to Network Attached Storage (NAS) in the sense that JVM-level (heap-level) replication is making NAM’s presence transparent just like NAS can be transparent behind a file I/O API. Getting NAM to perform and scale is similar to any I/O platform; read-ahead buffering, read/write locking optimizations etc.

Even though it is in clustering, meaning scalability and high-availability, of Web and enterprise applications, that Terracotta can bring its most immediate value, it is really a platform for solving generic distributed computing and shared memory problems in plain Java code. This is something that makes it applicable to a wide range problem domains, for example building a POJO-based Data Grid.

Let’s cluster it using Terracotta!

I know what you are thinking:
> “Clustering, hmmm… Now comes the hard part right?”

Well…no.

It turns out that in order to cluster our current WorkManager implementation, all we have to do is to create a Terracotta configuration file in which we define three things:

The fully qualified name of the top level object in the object graph that we want to share. In our case we want to share the work queue. This means that the most natural root would be the LinkedBlockingQueue in the SingleWorkQueue class, e.g. the m_workQueue field.
The classes that we want to include for instrumentation. We can include all classes for instrumentation, e.g. use a “match-all” pattern, but it is usually better to narrow down the scope of the classes that Terracotta needs to introspect.
The potential lock boundaries that we want Terracotta to introspect. These are called auto-locks and is simply a hint that Terracotta should treat the synchronized blocks in these places as transaction boundaries. (You can also define explicit locks called named-locks.) In our case we will define a “match-all” pattern for the locking, something that works fine in most cases and should be treated as the default.

...
<roots>
  <root>
    <field-name>
      org.terracotta.datagrid.workmanager.singlequeue.SingleWorkQueue.m_workQueue
    </field-name>
  </root>
</roots>
<instrumented-classes>
  <include>
    <class-expression>
      org.terracotta.datagrid.workmanager..*
    </class-expression>
    <honor-transient>true</honor-transient>
  </include>
</instrumented-classes>

<locks>
  <autolock>
    <method-expression>* ...*(..)</method-expression>
    <lock-level>write</lock-level>
  </autolock>
</locks>
...

Done!

Now we have a distributed/multi-JVM CommonJ WorkManager ready for use. But in order to call it a POJO-based Data Grid, we need extend it a bit and address some challenges that are likely to arise if we were to deploy this implementation into production.

Part 3: Getting serious – Handling real-world challenges

Now we have learned the basics of Data Grids, the Master/Worker pattern and what the CommonJ WorkManager specification is all about. We also walked you through how to implement a distributed CommonJ WorkManager by first creating a single-JVM implementation that we then cluster into a distributed multi-JVM implementation with Terracotta.

However, it was a fairly simple and in some sense naÃ¯ve implementation. This was a good exercise in terms of education and understanding, but in order to use the implementation in the real world we need to know how to address some of the challenges is that might come up. Now we will discuss some of these challenges and how we can extend the initial implementation to address them.

The challenges that we will look at, one by one, are how to handle:

Very high volumes of data?
Work failure?
Routing?
Ordering?
Worker failure?

Dealing with very high volumes of data

Our current implementation has one single queue that is shared by the master(s) and the all workers. This usually gives acceptable performance and scalability when used with a moderate work load. However, if we need to deal with very high volumes of data then it is likely that we will bottleneck on the single queue. So how can we address this in the most simple fashion?

The perhaps simplest solution is to create one queue per worker, and have the master do some more or less intelligent load-balancing. If we are able to do a good partition of the work and data, that we discussed in the previous section (“Scaling Data Grids”), then this solution is one that will:

Maximize the use of Locality of Reference – since all work that are operating on the same data set will be routed to the same queue with the same worker working on them
Minimize contention – since since there will only be one reader and one writer per queue.

If we take a look at the current code, what needs to be changed is to first change the SingleWorkQueue class to a WorkQueueManager class and swap the single LinkedBlockingQueue to a ConcurrentHashMap with entries containing a routing ID mapped to a LinkedBlockingQueue:

Swap the wrapped LinkedBlockingQueue:

public class SingleWorkQueue {
  BlockingQueue<WorkItem> m_workQueue = new LinkedBlockingQueue<WorkItem>();
}

To a ConcurrentHashMap of _LinkedBlockingQueue_’s :

public class DefaultWorkQueueManager<ID> implements WorkQueueManager {
  Map<ID , BlockingQueue<WorkItem>> m_workQueues =
      new ConcurrentHashMap<ID, BlockingQueue<WorkItem>>();
}

We also need to change the WorkManager implementation and rewrite the schedule(..) methods to use a Router abstraction and not put the work directly into the queue:

Change the schedule(..) method from:

public class DefaultWorkManager implements WorkManager {

  public WorkItem schedule(final Work work) {
    WorkItem workItem = new DefaultWorkItem(work, null);
    m_queue.put(workItem);
    return workItem;
  }
  ...
}

To redirect to the Router abstraction (more on the Router below):

public class RoutingAwareWorkManager<ID> implements WorkManager {

  public WorkItem schedule(final Work work) {
    return m_router.route(work);
  }
  ...
}

In the last code block we could see that we have introduced a new abstraction; the Router, which leads us to the topic of how to deal with different routing schemes.

Dealing with different routing schemes

By splitting up the single working queue into multiple queues each with a unique routing ID we are opening up for the possibility of providing different routing schemes that can be customized to address specific use cases.

As in the previous section, we have to make some changes to the initial single queue implementation. First we need to add a routing id to the WorkItem abstraction, we do that by adding the generic type ID and let the WorkItem implement the Routable interface:

public class RoutableWorkItem<ID> extends DefaultWorkItem implements Routable<ID> {

  protected ID m_routingID;

  public ID getRoutingID() {
    return m_routingID;
  }
  ...
}

As we saw in the previous section, we also introduce a new abstraction called Router:



public interface Router {

  RoutableWorkItem route(Work work);

  RoutableWorkItem route(Work work, WorkListener listener);

  RoutableWorkItem route(RoutableWorkItem WorkItem);

}

This abstraction can be used to implement various load-balancing algorithms, such as for example:

Round-robin – Router circles around all queues one by one
Work load sensitive balancing – Router looks at queue depth and always sends the next pending work to the shortest queue
Data affinity – “Sticky routing”, meaning that the Router sends all pending work of a specific type to a specific queue
Roll your own – to maximize Locality of Reference for your specific requirements

In our Router implementation we have three default algorithms; round-robin, load-balancing and single queue. You can find them as static inner classes in the Router interface.

Here is an example of the load-balancing router implementation that takes an array of the routing IDs that are registered and always sends the next pending work to the shortest queue:

public class LoadBalancingRouter<ID> implements Router<ID> {
    
  private final WorkQueueManager<ID> m_queueManager;

  private static class WorkQueueInfo<ID> {
    public ID routingID;
    public BlockingQueue<RoutableWorkItem<ID>> workQueue;
    public int queueLength = Integer.MAX_VALUE;
  }

  public LoadBalancingRouter(final WorkQueueManager<ID> queueManager, final ID[] routingIDs) {
    m_queueManager = queueManager;
    // create all queues upfront
    for (int i = 0; i < routingIDs.length; i++) {
      m_queueManager.getOrCreateQueueFor(routingIDs[i]);        
    }
  }
    
  public RoutableWorkItem<ID> route(final Work work) {
    return route(work, null);
  }

  public RoutableWorkItem<ID> route(final Work work, final WorkListener listener) {
    WorkQueueLength<ID> shortestQueue = getShortestWorkQueue();
    RoutableWorkItem<ID> workItem = new RoutableWorkItem<ID>(work, listener, shortestQueue.routingID);
    try {
      shortestQueue.workQueue.put(workItem);
    } catch (InterruptedException e) {
      workItem.setStatus(WorkEvent.WORK_REJECTED, new WorkException(e));
      Thread.currentThread().interrupt();
    }
    return workItem;
  }

  public RoutableWorkItem<ID> route(final RoutableWorkItem<ID> workItem) {
    WorkQueueLength<ID> shortestQueue = getShortestWorkQueue();
    synchronized (workItem) {
      workItem.setRoutingID(shortestQueue.routingID);        
    }
    try {
      shortestQueue.workQueue.put(workItem);
    } catch (InterruptedException e) {
      workItem.setStatus(WorkEvent.WORK_REJECTED, new WorkException(e));
      Thread.currentThread().interrupt();
    }
    return workItem;
  }

  private WorkQueueLength<ID> getShortestWorkQueue() {
    WorkQueueLength<ID> shortestQueue = new WorkQueueLength<ID>();
    
    int queueLengthForShortestQueue = Integer.MAX_VALUE;
    ID routingIDForShortestQueue = null;
    Map<ID, BlockingQueue<RoutableWorkItem<ID>>> queues = m_queueManager.getQueues();
    for (Map.Entry<ID, BlockingQueue<RoutableWorkItem<ID>>> entry: queues.entrySet()) {
      ID routingID = entry.getKey();
      BlockingQueue<RoutableWorkItem<ID>> queue = entry.getValue();
      int queueSize = queue.size();
      if (queueSize <= queueLengthForShortestQueue) {
        queueLengthForShortestQueue = queueSize;
        routingIDForShortestQueue = routingID;
      } 
    }
    shortestQueue.workQueue = m_queueManager.getOrCreateQueueFor(routingIDForShortestQueue);         
    shortestQueue.routingID = routingIDForShortestQueue;
    return shortestQueue;
  }
}

Dealing with work failure

As we discussed earlier in this article the CommonJ WorkManager specification provides APIs for event-based failure reporting and tracking of work status. Each Work instance is wrapped in a WorkItem instance which provides status information. It also gives us the possibility of defining an optional WorkListener through which we will get callback events whenever the status of the work has been changed.

The WorkListener interface looks like this:

public interface WorkListener {
  void workAccepted(WorkEvent we);
  void workRejected(WorkEvent we);
  void workStarted(WorkEvent we);
  void workCompleted(WorkEvent we);
}

As you can see, we can implement callbacks methods that subscribes to events triggered by work being accepted, rejected, started and completed. In this particular case we are mainly interested in doing something when receiving the work rejected event. In order to do that to we simply need to create a implementation of the WorkListener interface and add some code in the workRejected method:

public class RetryingWorkListener implemets WorkListener {

  public void workRejected(WorkEvent we) {
    Expection cause = we.getException();
    WorkItem wi = we.getWorkItem();
    Work work = wi.getResult(); // the rejected work

    ... // reroute the work onto queue X
  }

  public void workAccepted(WorkEvent event) {}
  public void workCompleted(WorkEvent event) {}
  public void workStarted(WorkEvent event) {}
}

Dealing with ordering of work

In some situations it might be important to define and maintain ordering of the work. This doesn’t seem to be a problem if we have a single instance of the master, but imagine scaling out the master; then it immediately gets worse.

So, how can we maintain ordering of the work? Since the internal implementation is based on POJOs and everything is open and customizable, it is actually very easy to implement support for ordering. All we need to do is to swap our map of LinkedBlockingQueue(s) to a map of PriorityBlockingQueue (s).

Then you can let your Work implement Comparable and create a custom Comparator that you pass it into the constructor of the PriorityBlockingQueue:

Comparator c = new Comparator<RoutableWorkItem<ID>>() {
    public int compare(
        RoutableWorkItem<ID> workItem1,
        RoutableWorkItem<ID> workItem2)
      Comparable work1 =
         (Comparable)workItem*getResult();
      Comparable work2 =
         (Comparable)workItem2.getResult();
      return work*compareTo(work2);
    }};

If you need to maintain ordering of the result then you have to do something similar with the references to the WorkItem(s) that you get when invoking schedule(..) on the WorkManager instance.

Dealing with worker failure

In a reliable distributed system it is important to be able to detect if a worker goes down. (In order to simplify the discussion, let’s define a worker as being a JVM.) There are some different ways this could be implemented and we will now discuss some of the different strategies that we can take.

Heartbeat mechanism – In this strategy each worker has an open connection to the master through which it continuously (and periodically) sends a heartbeat (some sort of “I’m-alive” event) to the master. The master can then detect if the heartbeat for a specific worker stops and can after a certain time period consider the node to be dead. This is for example the way that Google’s MapReduce implementation detects worker failure.
Work timestamp – Here we are adding a timestamp to each pending work item. The master can then periodically peek into the head of each work queue, read the timestamp and and match it to a predefined timeout interval. If it detects that a work item has timed out then it can consider the worker(s) that is polling from the specific queue to be dead.
Worker “is-alive-lock” – This strategy utilizes the cross-JVM thread coordination that Terracotta enables. The first thing that each worker does when it starts up is spawn a thread that takes a worker specific lock:

synchronized(workerLock) { 
  while (isRunning) {}; // hold the lock until worker is shut down or dies 
}

Then the the worker connects to the master which spawns up a thread that tries to take the exact same lock. Here comes the trick – the master thread will block until the lock is released, something that will only happen if the worker dies:



synchronized(workerLock) { // will block here until worker dies

  … // worker dead – take proper action

}

Terracotta Server notifications – Since detection of a node failure is such a common problem, an implementation in which the Terracotta clients can subscribe on notifications of node death from the Terracotta Server is underway and will be released in an upcoming version of Terracotta.

In all of the strategies we need to take proper action when worker failure has been detected. In our case it would (among other things) mean to reroute all non-completed work to another queue.

Rewrite the Terracotta config

As you perhaps remember from section “Very high volumes of data?”, in order to make the implementation more scalable we had to change the SingleWorkQueue class to a WorkQueueManager class and swap the single LinkedBlockingQueue to a ConcurrentHashMap with entries containing a routing ID mapped to a LinkedBlockingQueue. When we did that we also changed the name of the field and the name of class holding this field, this is something that needs to be reflected in the Terracotta configuration file:

...
<roots>
  <root>
    <field-name>org.terracotta.datagrid.workmanager.routing.DefaultWorkQueueManager.m_workQueues</field-name>
  </root>
</roots>
...

How to use the POJO Grid?

Here is an example of the usage of the WorkManager, WorkQueueManager, Router and WorkListener abstractions:

// Create the work queue manager with 'String' as routing ID type. The DefaultWorkQueueManager 
// is usually sufficient, but you can easily provide your own implementation of the 
// WorkQueueManager interface
WorkQueueManager workQueueManager = new DefaultWorkQueueManager();

// create the router - there are a bunch of default routers in the Router interface, 
// such as SingleQueueRouter, RoundRobinRouter and LoadBalancingRouter, but
// it is probably here that you need to plug in your custom implementaion 
Router router = new Router.LoadBalancingRouter(workQueueManager);   
    
// create the work manager - this implementation is very generic and most likely enough
// for you needs
WorkManager workManager = new RoutingAwareWorkManager(router);

// optionally (null is ok) create a work listener that will get a call back each time 
// the status of a WorkEvent (Work) has changed - allows you to for example take proper 
// action upon failure and retry etc. 
WorkListener workListener = null;

Set workSet = ... // create a set with the work to be done

// loop over the work set
for (Work work: workSet) {
  RoutableWorkItem workItem; // the work item, wrapping the work (result) and holds the status 
  try {
    // schedule the work, e.g. add it to the work queue and get the work item in return that can
    // be used to keep track of the pending work
    workItem = workManager.schedule(work, workListener); 
  } catch (WorkException e) {
    // handle failure
  }
}

To start up a Worker you simply have to create an instance of the Worker, pass in a reference to the DefaultWorkQueueManager and the routing id to use, and finally invoke start():

try {
  // create a work queue manager with 'String' as routing ID type
  WorkQueueManager workQueueManager = new DefaultWorkQueueManager();
     
  // create and start up a Worker implementation - the provided RoutingAwareWorker 
  // implementation is usually enough
  // we pass in the work queue manager and the routing ID for this worker
  Worker worker = new RoutingAwareWorker(workQueueManager, "ROUTING_ID_1");
  worker.start();
  
} catch (WorkException e) {
  // handle failure
}

Don’t we need a result queue?

There is no need for a result queue, since the Master is holding on to the WorkItem e.g. the pending work (the work that is in progress) including its result. Terracotta maintains Java’s pass-by-reference semantics, the regular (local) reference to the WorkItem that the Master holds, will work transparently across the cluster. This means that a Worker can update the exact same WorkItem and the Master would know about it immediately.

Enabling Terracotta

The client usage would roughly be to start up one WorkManager and N number of Workers, each one on a different JVM. Before you start up the WorkManager and Workers you have to enable the Terracotta runtime.

There are two ways you can do this:

Use Terracotta wrapper script

Terracotta ships with a script that should be used as a drop-in replacement to the regular java command. The name of the script is dso-java and can be found in the bin directory in the distribution. To use the recommended Terracotta startup script:

Find the dso-java script in the dso/bin directory.
Replace the regular invocation to java with the invocation to dso-java.

Use JVM options

You can also use additional JVM options for applications inside the web container, perform the following:

Prepend the Terracotta Boot Jar to the Java bootclasspath.
Define the path to the Terracotta configuration file.

Here is an example (assuming you are running Windows):

java -Xbootclasspath/p:<path to terracotta boot jar> \
     -Dtc.config=path/to/your/tc-config.xml \
     -Dtc.install-root=<path to terracotta install dir> \
      ... <your regular options> ...

Run it

Now we are almost done, but before you spawn up the Master and the Workers we must first start the Terracotta Server. This is done by invoking the start-tc-server script in the dso/bin directory. After you have done that then you can just start up the Master and the Workers (in any order you like).

That is all there is to it.

Benefits of implementing a POJO-based Data Grid

So let’s wrap up with a brief discussion of the most immediate benefits of building and using a POJO-based Data Grid. Here are some of the benefits that we value:

Work with POJOs – You get to work with POJOs, meaning simple and plain Java code. Any POJO can be shared across the cluster and migrated between worker nodes. There is no need for implementing Serializable or any other interface. It is as simple as Java can be.
Event-driven development – The Master/Worker (and CommonJ WorkManager) pattern leans itself towards event-driven development with no need for explicit threading and guarding. This can simplify the user code immensely compared to the use of explicit thread coordination.
Simpler development and testing – We have talked about how Terracotta allows you to develop an application for a single JVM and then simply cluster it in order to run it on multiple JVMs. This means that you can simplify the development and testing of your Data Grid application by doing the development and testing on your workstation, utilizing multiple threads instead of JVMs and then deploy the application onto multiple nodes at a later stage.
White Box container implementation – The whole grid implementation is “under your fingers”, nothing is really abstracted away from you as a developer. This gives you the freedom to design Master, Worker, routing algorithms, fail-over schemes etc. the way you need, you can customize everything as much as you want.

Resources

Checkout the distribution for the POJO-based Data Grid. It is a Maven 2 based project that includes a sample implementation of a distributed web spider. Read the readme.html for instructions on how to build and run the sample:
http://svn.terracotta.org/svn/forge – (module projects/labs/opendatagrid)
Download Terracotta’s JVM-clustering technology – Open Source:
http://terracotta.org
Tutorial that is using the implementation outlined in this article to build a parallel web spider (that is part of the pojo-grid distribution):
http://terracotta.org/confluence/display/orgsite/TutorialTerracottaDsoSpider
Article – Distributed Computing Made Easy:
http://www.theserverside.com/tt/articles/article.tss?l=DistCompute
Article – Stateful Session Clustering: Have Your Availability and Scale It Too:
http://www.devx.com/Java/Article/32603/
Documentation for Terracotta’s JVM-clustering technology:
http://terracotta.org/confluence/display/orgsite/Documentation
Author’s weblog:
http://jonasboner.com

...and the Award for Best Programming Font Goes To...

2007-01-11T00:00:00+00:00

…and the Award for Best Programming Font Goes To…

ProFont.

It is the best programming font I have seen and I use it all the time (for most stuff – not just programming), both on Windows and Mac – even though it looks slightly better on Mac. Do not antialias it and use 9 pt (else it looks awful). Before I switched to ProFont I had to use at least 12 pt (Monaco for Mac and Consolas on Win) – I am getting old I guess – but ProFont is very readable at only 9 pt.

Here is a screenshot so you can get the feel of it. For example, see how it clearly distinguishes between “0” (number zero) and “O” (capital letter O) and between “1” (number one), “l” (lowercase letter L) and “I” (capital letter I) – something many fonts (including Monaco) have a problem with. But you should really try it out yourself.

In Search For the Ultimate Cross-Platform Backup Solution

2007-01-10T00:00:00+00:00

In Search For the Ultimate Cross-Platform Backup Solution

The last year I have been spending time finding the “ultimate” backup solution for Mac. I also have the requirement that it had to work equally good on Windows, since I am running both Windows and Mac. For example, I would like to be able to commit to my local [SVN](http://subversion.tigris.org/) repository on my [MacBook](http://www.apple.com/macbookpro/), type one single command to upload the changes (only the deltas) to my backup hosting, then invoke one single command on my Windows box to retrieve the latest changes so I can build and test it on Windows – and vice versa.

The different approaches that I have been playing with the last year are:

CD-RW
External HD with USB/FireWire connection (small portable to carry around).
Running a Linux server on a spare box (openssh, rsync etc.).

Unfortunately, none of these alternatives really worked for me, each one had its problems.

I wanted the backup solution to have:

1. Zero administration time, it should just work – on Windows and Mac.2. 24/7 uptime.
2. Fast connection.
3. Secure connection.
4. No cables or other hardware to carry around.

Then I found [Amazon S3](http://aws.amazon.com/s3).

It is inexpensive:

Pay only for what you use. There is no minimum fee, and no start-up cost.
$0.15 per GB-Month of storage used.
$0.20 per GB of data transferred.

It has a fairly rich API:

Write, read, and delete objects containing from 1 byte to 5 gigabytes of data each. The number of objects you can store is unlimited.
Each object is stored and retrieved via a unique, developer-assigned key.
Authentication mechanisms are provided to ensure that data is kept secure from unauthorized access. Objects can be made private or public, and rights can be granted to specific users.
Uses standards-based REST and SOAP interfaces designed to work with any Internet-development toolkit.
Built to be flexible so that protocol or functional layers can easily be added. Default download protocol is HTTP. A BitTorrent™ protocol interface is provided to lower costs for high-scale distribution. Additional interfaces will be added in the future.

Great stuff, seemed to do what I needed. So far so good. But then the next problem – how to find a usable S3 client that:

Worked equally good on Mac an on Windows.
Could be run in command mode (so I could schedule it with cron).
Detected updated and new files – e.g. did not just shovel everything up to the server.

After X hours trying out different (bad and worse) clients I found [jetS3t](https://jets3t.dev.java.net/) – which actually seemed very usable. It is a Java based application, that has two apps in one:

[Cockpit](https://jets3t.dev.java.net/cockpit.html): a Swing GUI program that is fairly easy to configure. It supports drag and drop, detects new and updated files, keeps the original file name and path (more important than you think), compresses (gzip) files, encrypts them etc. Read the documentation for more details. It also has a Java applet that you can use if you want to download some files to a computer that does not have Cockpit installed: [http://jets3t.s3.amazonaws.com/index.html](http://jets3t.s3.amazonaws.com/index.html).

[Synchronize](https://jets3t.dev.java.net/synchronize.html): a command line tool that has the same functionality as Cockpit but runs in headless mode. This is great if you want to schedule backups (using cron or similar) or just want a simple – single command – way of synching up the data.

Good stuff. Perhaps not ultimate, but I am happy for now.

Another thing that I have found very useful in S3 is the possibility of creating public URLs or Torrents that can be made available for a specific amount of time. This is very useful if you want to share files with friends. We even use this feature at [Terracotta](http://terracotta.org/) to host the distribution of our downloads.

Thoughts? Can it be improved?

Update: [Geert Bevin](http://rifers.org/blogs) pointed me to the [js3tream](http://js3tream.sourceforge.net/) project. It plays nicely with standard shell tools such as tar, gzip, piping etc.:



tar -C / -czpO /etc | java -jar js3tream.jar -K mykey.txt \

-b mybucket:etc.tgz -i -t “An archive of my /etc directory”

According to Geert it is working fine. I have to try it out.

You're Smarter Than They Think

2007-01-09T00:00:00+00:00

You’re Smarter Than They Think

[Seth Godin](http://sethgodin.typepad.com/) has written yet an amazing and inspirational piece on [how to be remarkable](http://sethgodin.typepad.com/seths_blog/2007/01/how_to_be_remar.html). It is a short write-up of some of the ideas he has been talking and writing about for years.

Read it, be inspired and then…make something happen.

I am currently reading his new book [Small Is the New Big](http://www.amazon.com/exec/obidos/ASIN/1591841267/permissionmarket), which is a collection of the best columns, blog posts and articles he has written over the years. It’s a gem.

If you have the urge to achieve something more in life, feel stuck, don’t dare taking the leap of faith to do what you are made to do and have a creativity nerve that keeps on nagging, then read it. Please read it. It might actually change your life.

…as its back cover boldly proclaims: “you’re smarter than they think”.

Why Did We Open Source Terracotta?

2007-01-05T00:00:00+00:00

Why Did We Open Source Terracotta?

The past month I have been asked the same question over and over again: “Why did you open source Terracotta?”. It is odd, but it seems that for some people the question “why did they do it?” is much more interesting then “what does it mean – for me – for the industry?”

I will continue to spend most of my time trying to answer the latter question. But since the former one keeps coming up and is for many people still an unanswered question, I will point you to a good write up on the subject written by our CEO Amit Pandey:

Building a Sustainable Open Source Business
â€” Terracotta took a major step this month by open sourcing all of our Java clustering technology. We believe that this step will make a powerful clustering option readily available to the Java community and indeed could help make the notion of clustering itself simpler and more ubiquitous. This is an initiative that is many months in the making, and I wanted to share our thinking and motivation for it with you.

Terracotta is Open Source

2006-12-04T00:00:00+00:00

Terracotta is Open Source

Today we open sourced Terracotta and launched a new site for the Open Terracotta Project; http://terracotta.org.

Personally, I am very excited and think that Open Terracotta’s potential impact on the Java community cannot be underestimated. Even though it is in clustering, meaning scalability and high-availability, that it can bring its most immediate value to the community, it is really a platform for solving generic distributed computing and shared memory problems in plain Java code – something that makes it applicable to a wide range problem domains. I am very curious to see what the Java community – thinking out-of-the-box – can/will do with it.

Get involved. Download it, play with it, use it and then contribute.

Clustering Your Struts 2 Application With Terracotta

2006-11-27T00:00:00+00:00

Clustering Your Struts 2 Application With Terracotta

Don Brown (Struts 2 lead) and I are doing a live webinar on clustering Apache Struts 2 with Terracotta. We will discuss how to build stateful Struts 2 applications that scales like stateless ones and varying solutions to clustering Struts when running enterprise applications.

Wednesday, November 29, 2006 8:00 am Pacific Daylight Time.

Enroll here to attend.

Doom and the $3000 suite

2006-11-17T00:00:00+00:00

Doom and the $3000 suite

Doom and a $3000 suite. Two things that have nothing in common more than being the things that I remember most from the Oredev conference.

First Doom. Geert Bevin (founder of RIFE) did one of the most fun and hard-to-forget presentation openings I’ve seen. When I among the rest of the attendees, walked into the session room, Geert was right in the middle of a pretty violent first-person-shooter game (I think it was Doom) with monsters and blood all over the big movie screen behind him. He seemed very much into the game and continued to play while the audience filled the room. Eventually things got tougher and tougher, and just before he was about to die; he did ‘Save Game’, switched to his slides, introduced himself and the topic for the day: Continuations. :-)

One of the best illustrations of continuations I have seen, and one that noone will ever forget.

Second, the $3000 suite. When I arrived to my hotel to check in before going to the conference, it turned out that the Oredev staff had forgotten to reserve me a room. The hotel was fully booked apart from the top suite for $3000. So I sighed, took my stuff and went to the conference. I told the staff about my problem and asked them to solve it and after a little while they came up to me and told me they could get the suite. So I ended up sleeping in hotel room almost as big as our house. Any good? Well, I had to say that it only felt like a complete waste of money (luckily not my money), but now I at least know what people are paying for.

Other highlights.

Rickard Oberg did a very interesting talk about RDF, SPARQL and the Semantic Web. In which RDF can be used as a data model to index data from all kinds of data storages (RDBMS, OOBMDS, LDAP, flat file etc.) which can then be queried using SPARQL. It all felt both natural and very much like Tuple Spaces.

I did a talk about how Terracotta can be used as a generic distributed computing platform, that turns plain Java into a language with native and transparent distribution (something that you normally would need to use some narrow, academic and/or obscure languages to do — Erlang, Oz etc.). The talk was driven by the exercise of building a POJO-based Data Grid and how to scale it out using Locality of Reference and moving operations to the data (and not the contrary).

Back From Serbia

2006-11-15T00:00:00+00:00

Back From Serbia

I just got back from a small JUG roadshow in Serbia. I did two 2 1/2 hours talk in two days, the first one in Novi Sad and the second one in Belgrade. Both talks were well attended, ~100 attendees per session. Serbia seems to be a thriving Java community and there was a lot of interest in both Terracotta for Spring/Spring Web Flow as well as in using Terracotta DSO as a generic distributed computing platform.

During these two days I met a lot of interesting and warm hearted people, and was met with great hospitality throughout the trip. Unfortunately I did not have enough time to see much of the country, but I got a Serbia Travel Guide book as a gift so I guess I have to come back some time (and bring the family).

Finally I had a really good time (and interesting discussions) going out to lunch with Aleks Seovic, the Spring.NET lead (currently living in Belgrade), talking about Terracotta vs. Tangosol, Java vs. .NET, including more important things than geeky matters.

All in all, a great trip.

Hmm...that ain't bad

2006-11-08T00:00:00+00:00

Hmm…that ain’t bad

Linear scaling for HTTP session clustering?

I didn’t think it was possible, but the latest benchmark for Terracotta Sessions clustering Tomcat for sure looks promising:

Read this post if you want more details.

Webinar: Grid Computing Simplified Using Network-Attached Memory

2006-10-19T00:00:00+00:00

Webinar: Grid Computing Simplified Using Network-Attached Memory

Terracotta is hosting webinar on how to do grid computing using standard Java 5 code.

This session focuses on the Master/Worker pattern — one of the most useful parallel programming design patterns in use today.

You will learn about the identifying characteristics of the pattern and how best to use it in the real world.

It is a very practical, “hands-on” session in which we will present how to build the Master/Worker pattern using standard JDK 1.5, and how to turn it into a distributed grid implementation by using Network-Attached Memory. Following that, we will cover the production implications of operating and scaling a reliable work management framework.

Attendees will learn:

How to identify cases where the Master/Worker pattern is the right solution
How to build a distributed Master/Worker pattern with 100% POJO-based Java
How to cluster the JVM and effectively use Network-Attached Memory

More information about the webinar can be found here.

Interviewed by InfoQ

2006-09-25T00:00:00+00:00

Interviewed by InfoQ

InfoQ just posted their interview with me. Topics discussed are:

Features in Terracotta for Spring
What it brings to the table vs. Terracotta DSO
Clustering of JMX data
XA compliance and JEE transactions in general
How Terracotta for Spring compares to “Data Grids” and API-based clustering products

Using AOP to Cluster the JVM: Aspect Leadership Program

2006-09-22T00:00:00+00:00

Using AOP to Cluster the JVM: Aspect Leadership Program

If you are interested in knowing more about AOP and how it can be used to simplify distributed computing or want to know more about the inner workings of Terrocotta’s Distributed Shared Object (DSO) technology, then you should sign up for the Aspect Leadership Program in Vancouver, March 14 & 15 2007.

I will be giving a talk on Using AOP to Cluster the JVM and that is just one out of many talks during these two days:

In just two days, the Aspect Leadership Program (ALP) starts with an introduction to AOP, and proceeds through key points about the technology and tools, enterprise applications, case studies, refactoring existing applications, future trends and other topics.

The discussion-oriented coordinated presentations by world-leading experts make it possible to cover so much ground in just two days. Having seven of the world’s leading experts presenting means that you can get different perspectives on the key issues all in one setting.

Registration has already started. Hope to see you there.

How To Implement a Distributed CommonJ WorkManager

2006-09-14T00:00:00+00:00

How To Implement a Distributed CommonJ WorkManager

In this article I will show you how to implement a distributed version of the CommonJ WorkManager specification using Terracotta for Spring. This article is a variation of an article that I wrote for TheServerSide.com titled Distributed Computing Made Easy, an article that can be found here.

What is CommonJ WorkManager?

CommonJ is a BEA and IBM joint specification that provides a standard for executing concurrent tasks in a JEE environment. It for example has support for the Master/Worker pattern in its WorkManager API.

From BEA’s documentation about the specification:

“The Work Manager provides a simple API for application-server-supported concurrent execution of work items. This enables J2EE-based applications (including Servlets and EJBs) to schedule work items for concurrent execution, which will provide greater throughput and increased response time. After an application submits work items to a Work Manager for concurrent execution, the application can gather the results. The Work Manager provides common “join” operations, such as waiting for any or all work items to complete. The Work Manager for Application Servers specification provides an application-server-supported alternative to using lower-level threading APIs, which are inappropriate for use in managed environments such as Servlets and EJBs, as well as being too difficult to use for most applications."

What we are going to do is to first implement a the specification as a regular single node multi-threaded application, based on the Master/Worker pattern. We are also going to use the Spring Framework and implement the Master, Worker and Shared Queue entities as three different Spring beans; MyWorkManager, Worker and WorkQueue.

We will then use Terracotta for Spring* to transparently and declaratively, turn this implementation into a multi-node, distributed WorkManager.

Master (WorkManager)

MyWorkManager bean implements the CommonJ WorkManager interface which has the API that the user uses to schedule Work and wait for all Work to be completed. The MyWorkManager bean does not have any state, and can therefore be configured as a Prototype in the Spring bean config XML file.

Here is how we could implement the work manager bean:

public class MyWorkManager implements WorkManager { 

  // The Work Queue bean, is injected by Spring
  private final WorkQueue m_queue;

  public MyWorkManager(WorkQueue queue) {
    m_queue = queue;
  }

  public WorkItem schedule(final Work work) throws WorkException {
    WorkItem workItem = new MyWorkItem(work, null);
    m_queue.addWork(workItem);
    return workItem;
  }

  public WorkItem schedule(Work work, WorkListener listener) 
    throws WorkException {
    WorkItem workItem = new MyWorkItem(work, listener);
    m_queue.addWork(workItem); // adds work to the shared queue
    return workItem;
  }

  public boolean waitForAll(Collection workItems, long timeout) {
    long start = System.currentTimeMillis();
    do {
      boolean isAllCompleted = true;
      for (Iterator it = workItems.iterator(); 
           it.hasNext() && isAllCompleted;) {
        int status = ((WorkItem) it.next()).getStatus();
        isAllCompleted = 
            status == WorkEvent.WORK_COMPLETED || 
            status == WorkEvent.WORK_REJECTED;
      }
      if (isAllCompleted) { return true; }
      if (timeout == IMMEDIATE) { return false; }
      if (timeout == INDEFINITE) { continue; }
    } while ((System.currentTimeMillis() - start) < timeout);
    return false;
  }

  public Collection waitForAny(Collection workItems, long timeout) {
    long start = System.currentTimeMillis();
    do {
      synchronized (this) {
        Collection completed = new ArrayList();
        for (Iterator it = workItems.iterator(); it.hasNext();) {
          WorkItem workItem = (WorkItem) it.next();
          if (workItem.getStatus() == WorkEvent.WORK_COMPLETED || 
              workItem.getStatus() == WorkEvent.WORK_REJECTED) {
            completed.add(workItem);
          }
        }
        if (!completed.isEmpty()) { return completed; }
      }
      if (timeout == IMMEDIATE) { return Collections.EMPTY_LIST; }
      if (timeout == INDEFINITE) { continue; }
    } while ((System.currentTimeMillis() - start) < timeout);
    return Collections.EMPTY_LIST;
  }
}

Shared Queue

The MyWorkManager bean schedules work by adding work to the WorkQueue bean, which is a simple wrapper around a java.util.concurrent.BlockingQueue queue. The WorkQueue bean is the bean that has state, since it holds the queue with all the pending Work. We need to have a single instance of this queue that can be available to all workers, and we therefore define it as Singleton in the bean config XML file.

The work queue can be implemented like this:



public class WorkQueue {

  private final BlockingQueue m_workQueue;
public WorkQueue() {
m_workQueue = new LinkedBlockingQueue();
}
public WorkQueue(int capacity) {
m_workQueue = new LinkedBlockingQueue(capacity);
}
public MyWorkItem getWork() throws WorkException {
try {
return (MyWorkItem) m_workQueue.take(); // blocks if empty
} catch (InterruptedException e) {
throw new WorkException(e);
}
}
public void addWork(WorkItem workItem) throws WorkException {
try {
m_workQueue.put(workItem);
} catch (InterruptedException e) {
WorkRejectedException we =
new WorkRejectedException(e.getMessage());
((MyWorkItem)workItem).setStatus(WorkEvent.WORK_REJECTED, we);
throw we;
}
}
}

Worker

Finally, we have the Worker bean. This bean uses a thread pool to spawn up N number of worker threads that continuously grabs and executes Work from the WorkQueue. During the processing of the Work, its status flag is maintained (can be one of either Accepted, Started, Completed or Rejected), this is needed in order for the MyWorkManager bean to be able to continuously monitor the status of the Work it has scheduled. The Worker bean does not have any shared state and is configured as a Prototype in the bean config XML file.

This is what a worker bean implementation can look like. As you can see we choose to make use of the Executor thread pool implementation in the java.util.concurrent package:

public class Worker {

  private transient final WorkQueue  m_queue;
  private transient final ExecutorService m_threadPool = 
      Executors.newCachedThreadPool();
  private volatile boolean m_isRunning  = true;

  public Worker(WorkQueue queue) {
    m_queue = queue;
  }

  public void start() throws WorkException {
    while (m_isRunning) {  
      final MyWorkItem workItem = m_queue.getWork();
      m_threadPool.execute(new Runnable() {
        public void run() {
          try {
            Work work = workItem.getResult();
            workItem.setStatus(WorkEvent.WORK_STARTED, null);
            work.run();
            workItem.setStatus(WorkEvent.WORK_COMPLETED, null);
          } catch (Throwable e) {
            workItem.setStatus(
                WorkEvent.WORK_REJECTED, 
                new WorkRejectedException(e.getMessage()));
          }
        });
      }
    }
  }
}

Assembly

These three beans can now be wired up by the Spring bean config file:

&lt;beans&gt;
  &lt;!-- workManager is prototype - not shared --&gt;
  &lt;bean id="workManager"
        class="com.jonasboner.commonj.workmanager.MyWorkManager"     
        singleton="false"&gt;
    &lt;constructor-arg ref="queue"/&gt;
  &lt;/bean&gt;
    
   &lt;!-- worker is prototype - not shared --&gt;
  &lt;bean id="worker" 
        class="com.jonasboner.commonj.workmanager.Worker" 
        singleton="false"&gt;
    &lt;constructor-arg ref="queue"/&gt;
  &lt;/bean&gt;

  &lt;!-- the work queue is singleton - can be made shared by Terracotta --&gt;
  &lt;bean id="queue" 
        class="com.jonasboner.commonj.workmanager.WorkQueue"/&gt;

&lt;/beans&gt;

We now have a fully functional local, multi-threaded, implementation of the CommonJ WorkManager specification.

Making the WorkManager distributed

Now comes the hard part right? Well…no.

It turns out that in order to turn this implementation into a distributed WorkManager, all we have to do is to create a Terracotta configuration file in which we declare the Spring beans that we want to share across the cluster:

     
...
&lt;spring&gt;
  &lt;jee-application name="webAppName"&gt;
    &lt;application-contexts&gt;
      &lt;application-context&gt;
        &lt;paths&gt;
          &lt;path&gt;*/work-manager.xml&lt;/path&gt;
        &lt;/paths&gt;
        &lt;beans&gt;
          &lt;bean name="queue"/&gt;
        &lt;/beans&gt;
      &lt;/application-context&gt;
    &lt;/application-contexts&gt;
  &lt;/jee-application&gt;
&lt;/spring&gt;
...

Done!

Now we have a fully distributed, multi-JVM CommonJ WorkManager.

Client usage

Using the distributed work manager is now simply a matter of getting the bean from the application context and invoke schedule(..):

ApplicationContext ctx = 
    new ClassPathXmlApplicationContext("*/work-manager.xml");

// get the work manager from the application context
WorkManager workManager = (WorkManager) ctx.getBean("workManager");

Set pendingWork = new HashSet();
for (int i = 0; i < nrOfWork; i++) {

  // schedule work
  WorkItem workItem = workManager.schedule(new Work() {
      public void run() {
        ... // do work
      }
  });
                
  // collect the pending work
  pendingWork.add(workItem);
}

// wait for all work to be completed
workManager.waitForAll(pendingWork, WorkManager.INDEFINITE);

To start up a Worker you simply have to get the Worker bean from the application context and invoke start():



ApplicationContext ctx = 

    new ClassPathXmlApplicationContext(“*/work-manager.xml”);
// get the worker from the application context

Worker worker = (Worker) ctx.getBean(“worker”);
// starting worker

worker.start();

The usage of the distributed version would roughly be to start up one WorkManager bean and N number of Worker beans, each one on a different JVM.

That is all there is to it. Now we have a simple, distributed, reliable, high-performant and scalable CommonJ WorkManager ready for use.

Enjoy.

RC 1 of Terracotta for Spring was released some days ago (9/12/2006) and is free for production use for up to two nodes.

The Art of Minimalistic Design

2006-09-06T00:00:00+00:00

The Art of Minimalistic Design

Minimalism:

“…where the work is stripped down to its most fundamental features and core self expression”.

The world needs more minimalism.

Style has always been very important for me. When I talk about style, I mainly mean in terms of expression and art. In the last years, I’ve started to realize that, my definition of style, and what I’m really looking for, is minimalism.

Minimalism plays a very important role in art and design. It is a universal quality that can be found in any kind of art or design form. We can for example see brands from very different niches, like Apple (hardware and software), 37signals (web design), Bruno Mattsson (furniture) and Miles Davis (music), all have made a successful business out of it and have managed to create very passionate and in some cases almost religiously addicted user communities. Minimalism gets you.

It is important to understand that minimalism (and simplicity in general) is not equal to plainness. Actually, it is the contrary. My years as a jazz musician told me (the hard way) that simplicity and minimalism is actually one of the hardest thing one can achieve as an artist. One of the hardest things in the art of musical improvisation is to decide when not to play. To not fear the silence, but to use it as important building blocks in the picture, to paint a story around the silence.

Few have captured it better than Antoine de Saint-ExupÃ©ry:

“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”

Minimalistic design can perhaps be best described as QWAN, short for quality without a name, it is hard to put the finger on it, it has something to do with elegancy, it just feels good, feels right.

I have always thought of minimalistic design as a synonym for good design. But I like the term better since I think that it captures the essence of good design better, and communicates better what it should be and feel like.

The last days I have been thinking about questions like; what is really minimalistic design in the context of computer programming, what are the qualities that characterizes it, what does it feel like and how can it be achived?

Minimalistic Design in Computer Programming

I think that Ward Cunningham captures the essence of minimalistic design in his informal discussion with Kent Beck:

“So when I asked [KentBeck], “What’s the simplest thing that could possibly work,” I wasn’t even sure. I wasn’t asking, “What do you know would work?” I was asking, “What’s possible? What is the simplest thing we could say in code, so that we’ll be talking about something that’s on the screen, instead of something that’s ill-formed in our mind.” I was saying, “Once we get something on the screen, we can look at it. If it needs to be more, we can make it more.”

“The simplest thing that could possibly work”, sounds simple enough, but…what does it mean and…hmm…is it really simple?

Let’s try to break down the statement, and look at what the two parts; “The Simplest Thing” and “Possibly Work” could mean, and if they can to guide us towards minimalism.

But before we jump into that discussion, let’s define what “design” means in computer programming, both in terms of process and artifact.

What is Design?

When I talk about design in computer programming, I’m talking about the Code. I am a firm believer that The Code Is the Design.

This does not mean that UML diagrams, CRC cards or whiteboard drawings are bad, useless or unecessary. They are all part of planning and planning is essential. But while the act of planning is highly useful, the plans themself are of limited value. The planning (or design) sessions are best treated as a learning experience where the end product is not a document or a diagram, but increased knowledge and understanding.

“Do the planning but, throw out the plans.”
- Mary Poppendieck, Lean Development & the Predictability Paradox

“No plan survives contact with the enemy.”
- Field Marshall Helmuth Graf von Moltke

The documents or diagrams will be outdated in a short period of time anyway and are best thrown away as soon as possible, since they will only cause frustration when struggling to keep them in sync with the changes of reality. My advice here are, keep design sessions short, try to keep a high-level focus, see the whole and do not get buried in details, use simple tools and don’t put too much effort into the end artifact (diagram/document) – since that will make it harder to through away.

So, let’s now get back to the dissection of the “Wardism” we just chopped up. Starting with part 2.

Part 2: “Possibly Work”

First, I think that it must contain the minimal amount of functionality that solves the (customer’s) problem, nothing more and nothing less.

Another way to look at it is; customer satisfaction, which has also been described as:

“the right product, at the right time, for the right price”.

Second, if we see “Work” as the product, then the natural question is; how do we define the scope of the work, when can we consider ourselves “done”?

Ken Schwaber talks about Scrum’s definition of “done” as an;

“…increment of functionality that is complete… [that] must contain all analysis, design, coding, testing, documentation and anything else appropriate for the application”.

This would mean that “possibly work” could be defined as: an increment of functionality that is complete (in every sense) and that gives the customer satisfaction. I am sort of half satisfied with this definition, but I think it will work for now.

Now let’s take a look at part 1.

Part 1: “The Simplest Thing”

What does “The Simplest Thing” mean? How can it be achived?

As we discussed in the beginning of this article; “simple is not plain”. It is more a matter of purification and in the context of code I have found the qualities below to be some of the most important ones:

Conceptual Integrity

Conceptual Integrity is a quality in art and design, that is described by Fred Brooks, in the context of software, as a a system that is coherent and has been build with a unified vision:

“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, then to have one that contains many good but independent and uncoordinated ideas. â€¦ Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.”
- Fred Brooks, The Mythical Man-Month, p 42, 44

I believe that conceptual integrity is one of the key qualities that characterizes minimalistic design, where, as we could learn from the definition above, “the work is stripped down to its most fundamental features and core self expression”. It is not an easy thing to achive in in any art form, but especially not in software development with its highly complex nature paired with tight deadlines and customer’s ever-changing requirements.

Things that could help here are; a common vision for the project (have to be shared between developers, management and stake holders), having a small, tight, self-managed and adaptive team, steady flow of feedback from customer (short iterations etc.), refactoring and continuous refinement of the code etc.

High Cohesion

The code should have high cohesion, which means that a class should have one single and well-defined purpose. This principle was first introduced by Tom DeMarco who defined cohesion as the functional relatedness of the elements of a module. Bob Martin changed the meaning of this quality slightly when he define the Single-Responsibility Principle (SRP) which says that:

“A class should only have one reason change.”

What this means is that you should only implement one single concern (piece of functionality) in each class (or set of classes) and that all methods and attributes in this class should, one way or the other, contribute to to this specific piece of functionality – no more and no less.

Clarity

The code should be clear, easily understood and have a quality that is best described as self-documenting.

Modularity

The code should be modular in the sense that every concern in the system should, if possible, be made orthogonal to the other concerns. This will help you to minimize code tangling and code scattering, and will not only make the code more simple to write, but also to understand, maintain and reuse.

Here we can be helped by using common OO practices such as, the Single Responsibility Principle (see above), the Dependency Inversion Principle (DIP), the Open-Closed Principle (OCP) and the Liskov Substitution Principle (LSP) along with Aspect-Oriented Programming (AOP) and design patterns such as Strategy and Template Method.

One single authoritative representation of every piece in the system

Dave Thomas and Andy Hunt talks captures this in their DRY (Don’t Repeat Yourself) principle. We all know that code duplication is bad and should be eliminated, but the DRY principle takes it even further when it says that:

“…every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation.”

This ties back to both cohesion and orthogonality, since if you have a highly cohesive single representation of every concern in the system, then it is very likely that you can make these concerns orthogonal to each other and get good modularity. It is all connected.

Captures the right abstractions

The code needs to capture the right abstractions. This means that it has to be based upon a model that naturally reasons with both domain experts and developers. Maintaining a Ubiquitous Language can really help here, along with continuous refactoring and refinement of the model.

Final Thoughts

Finally, I think that the fact that, when Ward’s statement was formalized into a rule; Do The Simplest Thing That Could Possibly Work, it was prefixed with the verb “Do”, is of importance. It might sound subtle, but I think it is not. Because simplicity and minimalistic design is truly a process and not an end product.

We constantly need to challenge the way we work and the code we write, constantly strive for simplification and purification, more pragmatic and effective ways to work, continuously adapt and improve, and keep our humility for one of the most complex crafts there is.

“This complex craft will demand our continual development of the discipline, our learning to compose in larger units, our best use of new tools, our best adaptation of proven engineering management methods, liberal application of common sense, and a God-given humility to recognize our fallibility and limitations.”
- Fred Brooks, The Mythical Man-Month after 20 Years, p 289

WebEx: Cluster Your Spring Application in Less Than 30 Min

2006-08-17T00:00:00+00:00

WebEx: Cluster Your Spring Application in Less Than 30 Min

Terracotta and Interface21 will hold a joint WebEx on how to cluster an arbitrary Spring application or Spring WebFlow application transparently (no changes to existing application code) and declaratively in less than 30 minutes.

Rob Harrop and me will talk about the benefits and drawbacks with using state-of-the-art clustering technologies such as database, JMS or custom API (such as JCache etc.) and then talk about the benefits with and why we need clustering at the JVM level and how that is done in the Terracotta for Spring product.

If you are in need to scale out you Spring application or are in need for fail-over then you should call in to the WebEx.

Here is where you sign up for the WebEx.

Where and when:

Event: Transparently Clustered Spring

Date and Time:
Tuesday, September 12, 2006 8:00 am
Pacific Daylight Time (GMT -07:00, San Francisco)

Panelist(s) Info:

Jonas BonÃ©r, Sr. Software Engineer, Terracotta

Rob Harrop, core developer of the Spring Framework & consultant with Interface 21

Sreeni Iyer, Sr. Mgr for Field Engineering, Terracotta

Gary Nakamura, VP Sales, Terracotta

Duration: 1 hour

Description: Terracotta for Spring provides plug-in capacity, availability and scalability for Spring applications with absolutely no changes to existing code. Single VM Spring applications become clustered applications at load time, by simply configuring Terracotta for Spring to include the application context of your choosing.

Hope to see you there.

Distributed Computing Made Easy

2006-05-22T00:00:00+00:00

Distributed Computing Made Easy

My latest article for TheServerSide.com, titled Distributed Computing Made Easy, is published. In this article, I walk through a fairly generic but common distributed computing problem and shows how it can be simplified using Clustering at the JVM level, the Spring Framework and Java 5’s concurrency libraries.

The article can be found here.

Need to Scale-Out Your Spring Application?

2006-05-09T00:00:00+00:00

Need to Scale-Out Your Spring Application?

If you do, then you should come to my JavaOne session about Transparently Clustered Spring — A Runtime Solution for Javaâ„¢ Technology and learn how to cluster your Spring application in minutes, with zero changes to application code.

The session (TS-3217) will be held on Tuesday, 05/16/2006, 02:00 PM – 03:00 PM and has the following abstract:

How do you scale a Spring application beyond a single node? How can you guarantee high-availability, eliminate single points of failure, and make sure that you meet your customer SLAs?

Historically speaking, clustering an application is not easy: it takes a significant amount of time and usually requires you to rewrite parts of your application. It also usually perturbs your domain model and breaks object identity.

But does it have to be like that?

In this talk, Jonas BonÃ©r will walk you through how to cluster your Spring application, transparently and naturally, with no changes to your application code, using the Terracotta Spring Runtime.

The Terracotta Spring Runtime allows you to take an arbitrary Spring application, written for a single JVMâ„¢ machine, and cluster it to N nodes while preserving the exact same semantics.

For example:

â€¢ Life-cycle semantics and scope for Spring beans are preserved across the cluster – within the same logical ApplicationContext (singleton and session scoped beans).
â€¢ Spring’s local event mechanism in the ApplicationContext is turned into high-performance asynchronous, distributed and reliable events (messages), but still local within the same logical ApplicationContext.
â€¢ Clustered beans can be exported using Spring JMX support, which guarantees a single point of management and coherent view of all the JMX data in the cluster.
â€¢ Spring WebFlow’s web flows are transparently shared across the cluster.
â€¢ and more…

The session is backed up by several live demos.

See you there.

Domain-Driven Pointcut Design

2006-04-24T00:00:00+00:00

Domain-Driven Pointcut Design

What is a pointcut language?

Let’s start with some terminology and definitions. A pointcut language can be seen as a Domain Specific Language (DSL) for defining pointcuts. A pointcut is defined as the set of join points – a pointcut picks out join points, in which a jointpoint is defined as a well-defined point in the program flow.

Sounds complicated? It’s actually pretty simple.

Let’s try a little example. You have an instance of a class Foo and an instance of a class Bar. The class Bar has a method with the signature void setFoo(Foo foo) and the class Foo has some other method that is invoking this method in Bar. E.g. something like this:

class Bar {
  Foo foo;
  void setFoo(Foo f) {
    foo = f;    
  }
}

class Foo {
  Bar bar = new Bar();
  
  void doStuff() {
    bar.setFoo(this); // this is a join point 
  }
}

Then the point where setFoo(..) is invoked from the class Foo is a well defined point, e.g. a join point.

If we now want to pick out this point in order to do something with it (apply an advice or interceptor to it or something else), then we can create a pointcut using a pointcut language. In this particular case we could create a pointcut defined like this:

call(void Bar.setFoo(Foo))

Now we have created a pointcut (AspectJ style), since we have a construct that picks out join points. The only oddity here is that it only picks out one single join point.

Since just working with one join point at time is fairly useless, we need an expressive way of picking out and managing ‘sets’ of join points.

Luckily, most pointcut languages supports using patterns to write more expressive, generic or specific, pointcut expressions.

For example, you can use patterns to pick out the call to any method that starts with set in Bar using this pointcut:

call(* Bar.set*(..))

In this pointcut we do not care about the parameters to the method, the return type or its name more than it should start with set.

Generally, pointcut languages have two families of patterns (mini-languages):

Signature patterns – matches signatures (method, field etc.)
Type patterns – matches types

(For a more detailed description of the patterns and semantics that the AspectJ pointcut language supports, see the AspectJ documentation.)

The problems with using signature patterns in pointcuts

A pointcut can be seen as an implicit contract between the target code and the artifact that is using the pointcut (could be an aspect or an interceptor).

One problem with using patterns like this is that we are basing the implicit contract on implementation details, details are likely to change during the lifetime of the application. This is becoming an even bigger problem with the popularity of agile software development methodologies (like XP, Scrum, TDD etc.), with a high focus on refactoring and responsiveness to customer ever-changing requirements.

Another problem is that the use of patterns effectively removes all strong typing (can be helped with good tools like AJDT, but that will tie you to a specific working environment).

As a rule of thumb:
Your application’s implementation details will change and you should therefore, as much as possible try to avoid basing implicit contracts, e.g. your pointcuts, upon them.

So what can we do about it?

Metadata to the rescue?

When I write metadata I mean data about the target artifact, data that describes the characteristics of the artifact.

Here is a decent definition of metadata:

Metadata are structured, encoded data that describe characteristics of information-bearing entities to aid in the identification, discovery, assessment, and management of the described entities.

Note: when I write metadata I do not mean any specific kind of metadata, it can be declared in code, text file, XML, some meta model etc. But to be more specific, let’s look at Java 5 annotations.

Since metadata is raising the abstraction level over implementation details, but still captures its characteristics, it seems to be very suitable for helping us addres the issues with signature based patterns discussed above.

So, all this sounds promising, but as we will see later, you have to be aware of that not all metadata will help here and you have to define it with care.

Ramnivas Laddad has written an interesting article on metadata and pointcuts, where he views metadata as being multi-dimensional signatures. For example (from the article), a method with the following signature suffers from signature-tangling:

public void transactional_authorized_credit(float amount);

This method’s signature is tangled since it is trying to capture all its roles in it’s signature, e.g. name. In this case the use of metadata can help to untangle this signature by defining the method like this:

@Transactional 
@Authorized
public void credit(float amount);

This is definitely an improvement and the benefits are clear; more stable contract, more readable code, opens up for potential use of the metadata by tools etc. But the problem is that it doesn’t really raise the abstraction level, we still have strong implicit coupling, and the annotations suffers from the @AdviseMeHere Code Smell. I think the main problem is that we are still relying on implementation details, since we have merely restructured the signature.

He then continues with a discussion on the increased coupling, and suggests using more generic annotations that can be consumed by many different tools. For example that you should prefer using annotations like @ReadOperation rather than @ReadLock etc., which I think is an example of a step in the right direction.

The way I see it:
If an artifact F is annotated with an annotation A, then A should only describe characteristics (behaviour, role, responsibilities or properties) that F had before A was added to F.

In other words, you should try to avoid using annotations that implies explicit changes of the characteristics of the annotated artifact.

This raises the questions like, if for example the use of an @Transactional annotation (or @TransactionAttribute in EJB 3) is a bad idea? Well, yes (and no).

Generally speaking I do consider any annotation that have an Advise-Me-With-Feature-X kind of flavor, a code smell. However, I do think there is a place for these kind of annotations in well-defined and constrained environments, such as containers and frameworks – as well as when you think it works for you, stay pragmatic… :-).

I do believe that metadata still can help us, but the questions are: What is the proper abstraction level? How to make it work in reality?

Metadata and Ubiquitous Languages

I am a big fan of Domain-Driven Design (and Eric Evans book with the same name). One of the key building blocks in Domain-Driven Design is the Ubiquitous Language, and I have found that basing metadata abstractions on a Ubiquitous Language can get us a long way. More about how and why in a minute, but first, some people might be wondering what a Ubiquitous Languages is? Eric Evans defines it like this:

Definition: A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

Problem:
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design.

The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of the software project). And even the same person uses different language in speech and in writing, so that the most incisive impression of the domain often emerges in a transient form that is never captured in the code or even in writing.

Translation blunts communication and makes knowledge crunching anemic.

Yet none of these dialects can be a common language because none serves all needs.

Solution:
Use the model as a backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing and especially speech.

Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods and modules to conform to the new model. Resolve confusion over terms in conversaion, in just the way we come to agree on the meaning of ordinary words.

The Ubiquitous Languages is not only usable in the domain layer, but can, as Jimmy Nilsson has pointed out, be very useful in the service layer or in DSLs.

I have found that using the Ubiquitous Language is equally important when defining metadata. Metadata should be a first class citizen in the model and therefore has to be part of the Ubiquitous Language. This is something that is very useful by itself, but becomes even more important in the context of pointcut languages.

Bringing it all together: Domain-Driven Pointcut Design

So what is Domain-Driven Pointcut Design (more than a fancy name for a thing that can be seen as common sense, that you can make yet another buzzword-like acronym out of)? Simply a way of designing pointcuts that are anchored in the model and that are more resilient to change.

My proposal is that you should try as much as possible to to avoid the use of patterns and signature based pointcuts. What this means in practice is that you need to use match-all signature patterns (since we still have to define a pattern for signatures in the AspectJ pointcut language), e.g. '* *.*(..)' for method signatures or '* *.*' for field signatures etc. You should then instead try to constrain the pointcut language you are using to three different matching constructs:

Types – only fully qualified names, names that are part of the Ubiquitous Language your team is using.
For example,
within(com.biz.domain.Account) or
target(com.biz.domain.Customer) (AspectJ
allows you to use regular Java imports, so you can write
within(Account) etc.).
Metadata – only annotations that are part of the Ubiquitous Language your team is using.

For example,
call(@AccountStateChange * *.*(..)),
execution(@Idempotent * *.(..)),
@annotation(BillingOperation),
@this(DomainObject)
or whatever makes sense in your model.

Package patterns – should be used only for narrowing down scope.
For example
within(com.biz..)
etc. This means that
within(com.biz..) is ok, but not
within(com.*.foo.FooBar),
within(com.biz.Foo*) or
within(com.biz.*Bar)

If you manage to implement this correctly, in your team as well as in your code, then you have a high chance of being able to define extremely stable pointcuts that are a natural part of the model that both the developers and the domain experts (customers) can understand and reason about.

Finally, I do not and believe that signature based pointcuts are useless, should be banned or anything. You should of course still use signature based pointcuts when they are the best tool for the job, and when based upon standardized interfaces, classes or annotations then they can be just as stable and communicative.

Be pragmatic.

Afterword

This has not been a rant about the AspectJ pointcut langauge, which is in fact the most elegant, concise and coherent DSL I have ever worked with. But an attempt of showing a way of using it, in the context of Domain-Driven Design, that I have found useful and that addresses some of the problems with staying in sync with the model and the rest of the code throughout the lifetime of the application.

Update: Added some example pointcuts in the section titled Bringing it all together: Domain-Driven Pointcut Design

Thoughts On Parenthood In The Software Industry

2006-04-18T00:00:00+00:00

Thoughts On Parenthood In The Software Industry

I have been thinking some about parenthood in the software industry, in particular, of frameworks and technologies. Men that have been the driving force behind, invented, or founded a particular technology or framework, are often referred to as “The Father Of…”.

Is this really a fair and accurate metaphor?

The father usually gets away easy with the easy part (of just bootstrapping the whole process).

While it is the mother that:

has to carry the baby for nine months (product development)

has to do all the labor and go through all the pain in the delivery (shipping and release) process
usually has to do most of the maintenance

I would like to suggest switching to using the metaphor “The Mother Of…” (regardless of the sex of the subject).

Language Of The Year

2006-04-06T00:00:00+00:00

Language Of The Year

One, out of many great advice, coming from the book The Pragmatic Programmer (a book that has sort of been my manifesto the last years), is that you should try to learn a new programming language every year.

You should do this, not because you need to use it in your daily work (even though that is undoubtly the best way of learning a new language), but because it will widen your horizon, help you think and solve (your day-to-day) problems differently and better.

I have tried to follow this advice the last years (even though I have some gaps) and the last months my interest has been into declarative programming.

So the “Language Of The Year” 2006 is Scala along with a deeper dive into Oz.

History:

Scala and Oz
2005 – nil
2004 – nil
2003 – Groovy
2002 – AspectJ
2001 – Oz
2000 – Ruby
1999 – XML
1998 – Python and Jython
1997 – Java

(The language of 2007 is probably going to be Haskell, but let’s not get ahead of ourselves).

The Optimized Null Check Pattern

2006-04-04T00:00:00+00:00

The Optimized Null Check Pattern

A friend of mine showed me The Optimized Null Check Pattern™ yesterday (found in a piece of production code):

public static boolean isNull(Object obj) {
    boolean isNull;
    try {
        obj.toString();
        isNull = false;
    } catch (NullPointerException e) {
        isNull = true;
    }
    return isNull;
}

Then a colleague pointed out to me that a variation of the pattern (not as clean though) is actually used by Sun.

From the java.util.logging.LogRecord class:

public LogRecord(Level level, String msg) {
    // Make sure level isn't null, by calling random method.
    level.getClass();
 
    ...
}

Interview

2006-04-04T00:00:00+00:00

Interview

JayWay just published their interview of me.

Topics discussed: AOP (standardization, future, what is missing, real-world usage etc.) and transparent distributed clustering (DSO – Distributed Shared Objects).

Want To Work At Terracotta?

2006-03-24T00:00:00+00:00

Want To Work At Terracotta?

We are currently hiring developers to work in a team that is crafting an innovative container/runtime to provide transparent runtime services for Java objects (POJOs).

Requires knowledge in the following areas:

Object-Oriented Programming and design, patterns etc.
Deep understanding how Java works, including class loading, garbage collection etc.
Aspect-Oriented Programming (AOP)
Concurrent and parallel processing techniques
Knowledge of distributed programming and component models (sockets, JMS, RMI, EJB etc.)
Knowledge of the current state-of-the-art in JEE today, including standards, best-practices, patterns and anti-patterns, open source and proprietary frameworks etc.

Experience in the follow areas is considered a plus:

Bytecode manipulation and analysis
Dynamic languages such as JavaScript, Smalltalk, CLOS, Ruby, BeanShell, Groovy and Python

Culture

Must be able to express ideas clearly
Must be a team player

Does this describe you?

Do you like to write application servers instead of use them? Are you dissatisfied with the current state of JEE, with tons of incoherent XML config and thousands of APIs? Do you hate complexity when without cause? Do you believe that two heads are better than one and that ideas are what matters.

If this describes you then come and work at Terracotta (based in San Francisco).

You should have excellent programming abilities and design sense, and be capable of working closely with team members on design and implementation (XP-style).

If you think this sounds interesting, then drop me an email.

Keith Jarrett's Solo Concert At The War Memorial Opera House In San Francisco

2006-03-21T00:00:00+00:00

Keith Jarrett’s Solo Concert At The War Memorial Opera House In San Francisco

I had the privilege of sitting in the sixth row during Keith Jarrett’s solo concert at War Memorial Opera House in San Francisco yesterday evening.

It was a fantastic concert and musical experience, something I will carry with me for a long time.

Jarrett’s solo concerts are always completely improvised (meaning both themes, chords, melodies and solos) musical adventures, in which he mixes jazz, classical music, lyricsm, avant-garde and more.

He is, IMHO, the world’s most brilliant pianist and composer, and experiencing his musical brinkmanship and mastery yesterday was indeed, as one reviewer wrote, a “life-altering” experience.

The concert was recorded, so it might be available on CD in a near future.

Books That Makes You Think

2006-03-20T00:00:00+00:00

Books That Makes You Think

After my rant about the lack of computer literature that:

…makes you think and challenge the way you work.

I thought that I should provide a list of books that have made me start think about what I am doing and how I am doing it. Simply, books that have meant a lot to me.

This is by no means a complete list (I am sure I have missed a couple o gems) and the books are listed no particular order.

The Pragmatic Programmer: From Journeyman to Master
by Andrew Hunt, David Thomas

Domain Driven Design
by Eric Evans

Refactoring to Patterns
by Joshua Kerievsky

The Art of the Metaobject Protocol
by Gregor Kiczales

Effective Java
by Joshua Bloch

Refactoring: Improving the Design of Existing Code
by Martin Fowler

Concurrent Programming in Java: Design Principles and Pattern
by Doug Lea

Code Complete
by Steve McConnell

Programming Pearls
by Jon Bentley

Design Patterns: Elements of Reusable Object-Oriented Software
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Agile Software Development, Principles, Patterns, and Practices
by Robert C. Martin

Patterns Of Enterprise Application Architecture
by Martin Fowler

Extreme Programming Explained : Embrace Change
by Kent Beck

Analysis Patterns : Reusable Object Models
by Martin Fowler

I am always eager to read more good literature. What are your favourite books, which books have meant a lot to you and your career? If you have some suggestions, please comment.

Welcome Noah

2006-03-16T00:00:00+00:00

Welcome Noah

Saturday 17:45 PST, little Noah decided that it was time to come out and meet the family, seven weeks early, but very welcomed. He will have to stay in the incubator for another two to three weeks, but is getting stronger every day.

POJOs In Action

2006-03-16T00:00:00+00:00

POJOs In Action

After yesterday’s rant about the low quality in computer literature today, I felt the need to reply to myself.

One of the books I have been reading lately actually is a book that makes you think and challenge the way you work (if you are working with enterprise Java application development).

The book I am talking about is POJOs in Action by Chris Richardson, a book with a lot of depth and many dimensions.

Chris is standing on the shoulders of giants, and is basing a lot of his discussion on two recent classics in computer literature: Patterns Of Enterprise Application Architecture by Martin Fowler and Domain Driven Design by Eric Evans. POJOs In Action can be seen as a natural practical follow-up to these books.

Chris has a very pragmatic and relaxed (non-hyped) view on things and has a many interesting discussions and examples that comes from his experience in the field.

It is a practical book, which discusses, through code samples (which all are test-driven) based on both various standards as well as open source frameworks, not only patterns, design and high-level concepts, but the process of getting them to work and become a natural part in your daily work.

Highly recommended.

What Happened To Computer Literature That Makes You Think And Challenge The Way You Work?

2006-03-15T00:00:00+00:00

What Happened To Computer Literature That Makes You Think And Challenge The Way You Work?

I like books.

I enjoy spending time in libraries and bookstores, I can spend hours just browsing around and when my wife is getting bored (usually after 10 min) or when she comes back from her 3 h shopping round, she usually finds me in either the novel section, biography section or the section for computer literature.

Unfortunately, the visits to the latter one has (the last years) started to disappointment me.

Why? One of the major reasons is that the “learn-how-to-use-open-source-framework-X” type books have completely taken over the place. 90 % of the shelves are occupied by books like: ‘X in Action’, ‘Pro Y’, ‘Professional development with W’ or ‘Z: developers notebook’ etc. Phew…

It seems that everyone is writing a book (and getting it published!) now days. I guess it is not necessarily a bad thing, but it for sure makes it harder to find the real gems, the books worth spending time reading.

Generally, I have completely stopped reading the “learn-how-to-use-open-source-framework-X” type books.

Most books in this category tend to be very shallow, overly simplified, not thought through, badly written and often combined with too extensive and verbose code samples (there are of course exceptions). Most likely because they have been written under a very tight deadline – set by the publisher knowing that the topic of the book is expected to be dead in 2 years.

Books that is simply a walk-through of the APIs and ideas behind a specific framework or technology are generally useless. When I want to learn more about how to use framework X, then I can find the information I need both faster (and cheaper) on the Internet, and then in a format that is both searchable, printable and “cut-and-paste-able”. Thanks Google.

So, what is my definition of a “good book” – a book worth spending time reading?

In general, books that makes you think and challenge the way you do things, books that raises questions. I generally prefer reading about concepts, things that I do not have to worry being outdated in a year or two. Books that have a place in my library even in 10 years from now.

So, what happened to good computer literature? Well, fortunately it is still being written and published. It are just so much harder to find.

Terracotta DSO Explained

2006-02-27T00:00:00+00:00

Terracotta DSO Explained

Along with the 1.5 release of the Terracotta Server (shipped today), we have new web site along with a really good flash demo explaining our DSO (Distributed Shared Objects) technology.

It takes you through the concepts and ideas behind the technology as well as shows you a couple of live demos, definitely worth the 5 minutes it takes to watch it.

Just browse to the web site and click on [View Our Demo].

Moving To San Francisco

2006-01-13T00:00:00+00:00

Moving To San Francisco

I am writing this blog post in a total chaos of bags, boxes, skiing and outdoor gear, books, pacifiers, computers etc.

Tomorrow I am catching the plane to San Francisco, nothing special about that apart from that this time I am taking my family with me and we are planning on staying there on a permanent basis (at least for 3-4 years).

A lot of excitement and anxiety in the air, but I think that we will have a lot of fun. Living in San Francisco, closer to my collegues and friends at Terracotta, not more than 3 h from the mountains around Lake Tahoe and being able to enjoy the great California weather all year around sounds like a good start. :-)

If you live in the area and are up for a beer then drop me a line.

Highlights 2005

2005-12-31T00:00:00+00:00

Highlights 2005

2005 has been a good year, both personally and professionally.

Here is a summary of some of the highlights (in chronological order):

Family trip to Vietnam for 6 weeks. Amazing and beutiful country, friendly people, interesting culture, delicious food etc.

The merge of AspectWerkz and AspectJ is announced .

Sara and I skiing powder in Abisko (close to the pole circle) for 3 days – without kids! :-)

Family trip to California for 2 weeks.

Release of the support for AOP in the JRockit JVM.

Left BEA and joined Terracotta.

Jacob turned 2. Amazing little guy, that has gone from hardly speaking at all to someone talking so much that you hardly get anything said (or done), in just 4 months…

Our family got a US VISA (we are moving over in mid Jan 2006).

The release of AspectJ 5.

Here is a collage over the family highlights 2005, in chronological order.

Click on the image for a full-sized view.

Think AOP Is Dead? - Time To Reconsider...

2005-12-22T00:00:00+00:00

Think AOP Is Dead? – Time To Reconsider…

If you thought AOP was dead or at least dying, then it is time to reconsider.
AOP is not dead. Not even close.

After a perhaps healthy backlash, that took away some of the hype and coolness about AOP, it is steadily getting more and more adoption and traction in the enterprise space at large.

A lot is happening now. Here are only a few samples:

Yesterday the release of AspectJ 5 final was announced. This is IMO the most significant milestone in the history of AOP (so far). Finally we have a standardized language and toolkit and can, both as developers and users, try to move in the same direction and focus on building new things on top of this platform – instead of fighting over semantics, APIs and user base.

Adrian Colyer and and the Spring team has done a tremendous job unifiying AspectJ 5 and Spring. Adrian showed me some of their work during the Spring Experience conference and they have some very cool and useful things both working and in the pipeline. Stay tuned for the upcoming Spring 2.0 milestones.

I had the pleasure of attending Rod Johnson’s talk on Spring 2.0 at JavaPolis, a great talk that actually was mainly a (practical and non salesy) PR talk on AOP, in which he spent roughly half the time explaining why AspectJ is important for Spring users how they can utilize it in the upcoming 2.0 release of Spring. This is another evidence that Spring is embracing AOP and AspectJ 5 in a big way.

The future looks bright…
…but it is still mainly up to you users to make it happen.

So, go ahead and download AspectJ 5, play with it, have fun and then start use it for real…

AspectJ 5 Final Is Shipped

2005-12-22T00:00:00+00:00

AspectJ 5 Final Is Shipped

AspectJ 5 final is finally shipped.

This means that the merger with AspectWerkz is complete and that the most important chapter in the history of AOP has been completed (IMHO). Finally we have a standardized language and toolkit and can, both as developers and users, try to (finally) pull in the same direction. For more info, read Adrian Colyers’ blog announcement or the release page.

Go ahead and download the stand alone compiler or the AJDT IDE toolkit (with an embedded compiler).

Time to have some fun.

Slides From My Session On Transparently Clustered Spring @ The Spring Experience

2005-12-19T00:00:00+00:00

Slides From My Session On Transparently Clustered Spring @ The Spring Experience

Some people has asked for them, so here they are: the slides from my talk on Transparently Clustered Spring at The Spring Experience Conference.

Java Killed The Innovation Of Computer Languages

2005-12-19T00:00:00+00:00

Java Killed The Innovation Of Computer Languages

I had a very interesting discussion with Chris Richardson at the Spring Experience conference last week. Chris is an old Lisp hacker and used to write Lisp compilers and VMs before switching to Java about 10 years ago.

Here are some quotes from Chris that I find particularly interesting:

Java killed the innovation of computer languages.

AspectJ is one of the few innovations in computer languages the last years.

Some comments on these statements:

Java has had an enormous impact on enterprise application development the last 10 years and I do believe that Chris is right, it has to some extent “killed the innovation of computer languages” (considering commercially used and widely adopted languages). Sure, C# have some more or less innovative ideas (sometimes I wish I was a .NET developer) and Microsoft is doing some very cool stuff it the labs. But in general nothing has really happened the last 10 years. We have seen many new scripting languages popping up lately (Ruby, Python, Jython, groovy etc.) and even though most of them are both fun and useful – non of them are really innovating, merely reusing and sometimes reshaping old ideas (not saying that that is not enough – most of these languages has contributed tremendously on many ways).

While this is true for commercially adopted languages (for enterprise application, desktop development etc.), things are fortunately different in the academic field and in the labs. The problem here is that not enough effort is made to, wrap up the ideas in something that is (at least to some exent) easy to use, and/or to meet real-world needs of scalability, maintainability, interoperability etc. (due to lack of money or lack of interest?).

For example, one language that I have been playing with on and off the last years is the Mozart Programming System and its language Oz. Working with it is (as they say themselves) in some ways pure magic. It is an hybrid between object-oriented, functional and declarative languages which is very powerful. It supports high-performant network-transparent distribution (no difference between writing an app for one node or many) transparent sharing of classes, objects, variables, procedures etc., as well as real data-flow threads. It has build-in Separation of Concerns, allowing you to declaratively, in different modules, implement f.e. security, fault handling etc. (I should write a blog post about it later.)

But the problem is that it is so hard to use (at least for someone like me, that has been doing Java and C the last 10 years), that simply reaching the stage of being able to start playing with it for real takes more time than most people are willing to spend. However, I really encourage you to spend some time learning it.

I am biased, but I do think that AspectJ is one of the few really innovating languages that has made it out of the reseach labs into the enterprise without having to do trade-offs between innovation, power, coherent semantics and ease of use.

Some questions to chew on:

What are the requirements for a modern computer language that addresses real-world needs in the enterprise (thinking outside the box)?

What does it take to replace Java (meaning the language, not the platform)?

Is it likely to happen within the next 10 years?

Is it even necessary?

Which are the most important lessons we have learned?

Will the next generation computer languages for enterprise development be build upon the Java Platform (JVM)?

Which role [can/will/do we want] the academic research to play?

Are we willing to trade Innovation (and potential long term benefits) for Pragmatism and Ease-Of-Use (meaning short term benefits)?

JRockit: Still Way Ahead of Its Competition...

2005-12-13T00:00:00+00:00

JRockit: Still Way Ahead of Its Competition…

JRockit is still miles ahead of its competitors, both when it comes to speed and manageability/tool support.

Today, JRockit released its latest SPECjbb2000 benchmark (J2EE benchmark), in which it set a new world record, leaving Sun’s HotSpot in the dust…

It also keeps improving its excellent tool support and manageability. Please read Marcus Hirt’s new articles JRockit 5.0 The JVM at Your Fingertips and An Introduction to JRockit Mission Control as well as Staffan Larsen’s article about JRockit’s unique memory leak tool: Memory Leaks, Be Gone!.

Today, there is really only one single valid excuse for not running JRockit and that is if you are deploying on non-intel architecture, and this reason will be terminated in the upcoming releases (with ports to Sparc, HP-UX etc.).

(…and please don’t start rambling about instability again, that was an old (and then I mean really old) problem, the last releases, including the latest one, have been of very high quality – which, in my experience, have had better stability than Sun HotSpot’s comparable versions.)

JavaPolis In-N-Out

2005-12-13T00:00:00+00:00

JavaPolis In-N-Out

I am heading for JavaPolis tomorrow morning. Will be spending 24 h in Antwerp, doing two talks, hoping to hang out with some good friends, build new relations, drink the excellent Belgian Trappist Beer (favorite is Chimay) and have some fun…

Why the rush? Well, I have simply been travelling way too much lately (JavaOne Japan – 1 week, Terracotta in SF – 1 week and The Spring Experience in Miami – 1 week) and my 2 year old son is starting to be disappointed in me…

Stay Out of Jar Hell with Jar Jar Links

2005-12-09T00:00:00+00:00

Stay Out of Jar Hell with Jar Jar Links

Jar Jar Links have been part of my Java toolkit ever since we started using it in AspectWerkz a couple of years ago. It is one of these little gems that deserves more attention, and is your best way out of Jar Hell™.

Basically it is regular Ant’s Jar task on steriods, with a lot of small useful features. I will list some of them here.

Packaging

It works just like the regular Ant Jar task, e.g. you can embed other jars using the zipfileset element, so start using it is a simple matter. Just replace:

<target name="jar" depends="compile"> <jar jarfile="dist/example.jar"> <fileset dir="build/main"/>

with:
<target name="jar" depends="compile"> <taskdef name="jarjar" classname="com.tonicsystems.jarjar.JarJarTask" classpath="lib/jarjar.jar"/> <jarjar jarfile="dist/example.jar"> <fileset dir="build/main"/>

But this did not add much value, where it really starts to shine when you start using its feature of prefixing the dependencies.

Prefixing of dependencies

This is the heart of Jar Jar’s value proposition. It allows you to prefix dependencies (the actual package names) that are common and might be used by other libraries. For example in AspectWerkz we prefix the ASM library since it is very common and used in f.e. CGLIB, which can create runtime clashes.

...  <taskdef name="jarjar" classname="com.tonicsystems.jarjar.JarJarTask" classpath="${basedir}/lib/jarjar-0.3.jar"/>  <jarjar destfile="${build.dir}/aw-${version}.jar" manifest="${lib.dir}/manifest.mf"> <fileset dir="${main.classes}"> <exclude name="**/aspectwerkz/hook/**/*"/>

…

Remove unwanted dependencies

Some days ago I blogged about the problem with Commons Logging and when software depends on it. Well, using Jar Jar, it is actually a simple matter to remove any unwanted dependency altogether. It might not always be the best solution, f.e. you might actually want to have some logging in place, not just use Commons Logging. But is some cases it is very convenient. (Please note that this feature is still experimental.)

Chris Nokleberg has written more about how to use Jar Jar as a Dependency Killer.

Analysis

You can also do some simple, but useful, analysis using Jar Jar. For example finding out which dependencies a library actually has, by either just listing them or use it with graphviz to get a nice graphical view:

It can also find and print out all the strings you are using, good if you want to try to eliminate all your magic values.

Read more about these features in the articles Finding dependencies with JarJar and Dumping strings literals.

The "New Language" Is Already Installed On Your Workstation

2005-12-06T00:00:00+00:00

The “New Language” Is Already Installed On Your Workstation

Victoria Livshitz is “Envisioning a New Language”, it is an interesting read and I find this quote particulary interesting:

Give the local virtual machine (LVM) the ability to act as a container for managed application code. Create a virtual machine and distributed runtime environment that in principle subsume the functionality of the application containers and middleware. While retaining middleware from an interoperability standpoint, the basic needs of distributed applications, such as load balancing, failover, remote communications, mobility of services and their containers, quality of service, and service-level management, should be embedded into a runtime environment for the language

This is actually what we are doing at Terracotta in our Distributed Shared Objects (DSO) technology.

But instead of inventing a new languague (or introducing new APIs), we are using the APIs and bytecode instructions that we already have in Java and instead extending their semantics, in order to have Plain Java code, written for a single VM, work correctly (and scale) in a distributed environment.

So I would say that the “New Language” is already installed on your workstation…and it is called Java, it just needs to be boosted up some… ;)

Transparently Clustered Spring @ The Spring Experience

2005-12-05T00:00:00+00:00

Transparently Clustered Spring @ The Spring Experience

I am heading down to Miami and The Spring Experience conference to do a talk on Transparently Clustered Spring.

Basically it is talk about how you can use Terracotta ’s DSO technology to cluster your regular Spring applications Transparently, in order to get, better scalability, HA (High Availability), Fail-Over etc.

The talk will be demo-driven (5 demos) showing among other things:

how to make Spring Bean’s lifecycles and state mean the same thing on a cluster as on a single node (e.g. clustered, but local to the same ApplicationContext)
how to turn Spring’s ApplicationContext Events into distributed events (but still local within the same ApplicationContext)
how to avoid using regular messaging and simplify the programming model by:
- turning arbitrary method invocations into asynchronous distributed events
- use a regular java.util.List or java.util.Queue as a message queue (point-to-point or publish-subscribe)
and more…

I hope to see you there. :)

Commons Logging Has To Die

2005-11-24T00:00:00+00:00

Commons Logging Has To Die

Unfortunately, I guess it is to late to kill the beast…

But I am writing this post anyway, since it keeps on causing harm and since more enlightment around the actual problems it causes obviously is necessary.

My first contact with Commons Logging was in 2002, where it made the application is was currently working on blow up. After tracking down the problem, I solved it using AspectJ by hijacking Commons Logging and swap out the dynamic discovery mechanism to a static one (using Log4J directly), and have been fighting for a Commons-Logging-Free-World™ ever since.

If you want to know more about the actual problems it causes and why using class loader hacks to implement a dynamic discovery process is generally a bad idea, read the article Taxonomy of class loader problems encountered when using Jakarta Commons Logging.

I do understand why Commons Logging was invented, it solves a theoretical problem (I am using the word ‘theoretical’ here, since almost everyone that uses it, uses Log4J as the logging implementation anyway), it is just unfortunate that it became so popular so fast.

However, there are alternatives. If you really need to use a Logging facade (which I do not think you do), you should try out Simple Logging Facade for Java (SLF4J), which uses static (compile time) binding of the Logging implementation, e.g. avoids the above stated problems. They even have a gradual migration path from Commons Logging.

Sorry if I sound bitter, but I just had to get it out… :-)

Update:

I just remembered that Chris Nokleberg has a implemented a fancy way of getting rid of Commons Logging (and any other annoying dependency for that matter), it is part of his excellent package JarJar.

Thoughts on Harmony

2005-11-23T00:00:00+00:00

Thoughts on Harmony

Floyd Marinescu recently blogged about that the latest contribution from Intel was evidence that God (IBM?) has big plans for Harmony.

I wish I could be that optimistic, and I perhaps should, since Floyd usually does not say things that are not well backed up with facts.

I really like the idea of an open source JVM, where companies could contribute with the parts that they can do best (native ports etc.). But just some class library is basically nothing (we already have GNU Classpath, and who is using that for real…?).

What is necessary, and basically the only thing that could make the Harmony project fly is for either BEA to donate JRockit or IBM to donate J9.

Why?

First, it is practically impossible for a distributed non-full-time team to develop an enterprise class JVM within this century.

Second, these JVMs are the two single clean room implementations out there (e.g. that are not in any way derived from Sun HotSpot).

Geir, do you have any cards left to play? ;-)

I Have Found a New Place in This World

2005-11-22T00:00:00+00:00

I Have Found a New Place in This World

I have found a new place in this world.

I just posted my last post at my old blog at The Codehaus:

I decided to move my blog to jonasboner.com.

blogs.codehaus.org has served me well so far, so THANKS, but was a bit too unflexible for my needs and it felt it was time to move on.

At the same time I decided to start using Feedburner, so now you can find my feed here and only here.

So this is the last post at http://blogs.codehaus.org/people/jboner/.

Hope to see you here instead.

So, welcome to my new weblog, I promise to try to post more frequently from now on.
Stay tuned.

Learning From The Web

2005-11-02T00:00:00+00:00

Learning From The Web

Adam Bosworth has written an interesting article about what we can (or have to) learn from The Web.

He is talking about how it has teached us how to manage and distribute data and what it means for the Semantic Web and for the databases, and that standards such as Atom and RSS 2.0 will become increasingly important in the future.

Here is his conclusion (although I strongly recommend you to read the whole article):

TIME FOR DATABASE VENDORS TO STEP UP TO THE PLATE

Distributed computing has been learning and evolving in response to the lessons of the Web. Formats and protocols are arising to overcome the limitations of XMLâ€”even as XML in turn arose to overcome the limitations of CORBA and DCOM. It is time that the database vendors stepped up to the plate and started to support a native RSS 2.0/Atom protocol and wire format; a simple way to ask very general queries; a way to model data that encompasses trees and arbitrary graphs in ways that humans think about them; far more fluid schemas that donâ€™t require complex joins to model variations on a theme about anything from products to people to places; and built-in linear scaling so that the database salespeople can tell their customers, in good conscience, for this class of queries you can scale arbitrarily with regard to throughput and extremely well even with regard to latency, as long as you limit yourself to the following types of queries. Then we will know that the database vendors have joined the 21st century.

The Web is certainly changing the way we are viewing the world in many ways…

HotSwap Is A Dead End Road

2005-11-01T00:00:00+00:00

HotSwap Is A Dead End Road

There has been a lot of discussions about the need for more dynamicity in Java, including the need to support scripting languages.

Most are around the suggestion of improving the HotSwap facility in Java.

For exampe:

How badly do you want Hotswap to improve?

PLEASE VOTE: the only JVM bug you’ll ever really care about

Gaining traction: HotSwap improvements,

etc.

I have to admit that a year ago I was probably one of the guys that were swearing the most over HotSwap’s (and JVMI’s shortcomings when trying to stretch its (limited) boundries in AspectWerkz.

However, today I think that improving HotSwap and the APIs for bytecode instrumentation in general is a dead end road. It simply adds complexiety, memory overhead, performance overhead as well as introduces the multiple agents problem.

We need to raise the abstraction level and move away from bytecode instrumentation. There is a need for high level VM APIs similar to the one we have been working on in JRockit. For details on the problems with current approaches and how we solve this in a better way, read this article.

So, PLEASE, stop wasting time in discussing how to improve bytecode instrumentation (e.g. HotSwap, JVMTI etc.) and give us feedback on how to improve the high-level VM API in JRockit (the prototype is already available).

When on the subject on supporting scripting languages in Java is think that this proposal for adding a invokedynamic bytecode instruction is a step in the right direction.

Introducing HyperBeans Ã¢â¬â multi-dimensional POJOs

2005-10-25T00:00:00+00:00

Introducing HyperBeans â€“ multi-dimensional POJOs

Introduction

This article is introducing HyperBeans, a proposal for a framework for Symmetric Aspect-Oriented Software Development in plain Java (i.e. no extensions to Java is being used). These ideas are based on the work I have done in AspectWerkz and in the JVM support for AOP in JRockit and are loosely based on the work on Classpects by Kevin Sullivan and Hridesh Rajan.

If you don’t care about the research and background behind the ideas presented in this article (and want to see some code right away), then you should skip the rest of this section.

Aspect-Oriented Software Development (AOSD) in general, tries, among other things, to address the problem defined as the tyranny of dominant decomposition , in which the prominent concerns, usually the business logic, dominate the class design, especially the inheritance hierarchy (as observed in this article).

Historically there has been (and still is) two different main philosophies in AOSD, the asymmetric philosophy and the symmetric philosophy.
A detailed discussion about their semantic and philosophical differences is out of the scope for this article (read this article for a detailed discussion).

Juri Memmert has written a good introductory article on the subject in which he defines the different philosophies like this:

The asymmetric philosophy

An asymmetric approach to AOSD relies on the notion that there is a base body of code that is then augmented with aspects. There is a concept ional difference (and an implementation difference) between the base and the aspects so that an aspect can not serve as the base of another composition. Most asymmetric approaches use language extensions to declare aspects as first class entities.

The symmetric philosophy

A symmetric approach to AOSD is based on the notion that all concerns in a system are created equal and, in the asymmetric terminology, can serve as both aspect and base in different compositions. Most symmetric approaches use programming languages as-is, although there are approaches that rely on language extensions as well.

The leading implementation for asymmetric AOSD is AspectJ, while the most well-known symmetric implementation is Hyper/J (now part of the Concern Manipulation Environment (CME) project).

Asymmetric AOSD has so far been the dominant way of implementing AOSD in Java, and in the enterprise space at large. There has been, and still is, a lot of debate in the research community around whether the symmetric or the asymmetric philosophy is the best way of implementing AOSD and many papers have been written on the subject (see the reference section at the end).

When implementing the AspectWerkz AOP framework (which now has been merged with AspectJ), I have been involved in efforts trying to stretch the boundaries of asymmetric AOSD and even though I believe that the asymmetric approach is the preferable in many cases, it definitely has some shortcomings. For example, asymmetric AOSD addresses the problem of ‘the tyranny of dominant decomposition’ by allowing us to modularize all concerns, but the dominant concern, using aspects. Since the dominant concern needs to serve as “base”, the decision deciding which concern should be seen as the dominant one still needs to be taken, and this is a decision that should not be taken lightly since it is something that is usually very hard to change.

When taking a look at how a symmetric approach handles the above given problem, I find the symmetric solution very natural and appealing (at least conceptually). In which, if using Hyper/J’s terminology, a system is seen as a multi-dimensional hyperspace, which is built up using different hyperslices (dimensions). A hyperslice is the abstraction of a concern, which can be built up by many components. This gives you the possibility of viewing the hyperspace (your system) differently in regards to different hyperslices (concerns); you have the possibility of looking at the system from the point of view (concern) that you currently want.

I do not want to take any position in regards to if symmetric AOSD is a (or will be a) serious contender to asymmetric AOSD. I simply have not used the symmetric approach to solve real world problems enough yet, but I do believe that it is something worth exploring more. So, let’s take a look at the proposal.

HyperBeans â€“ multi-dimensional POJOs

There is no the distinction between classes and aspects, e.g. no need for one concern to serve as “base”, all there is is HyperBeans. HyperBeans are regular Plain Old Java Objects (POJOs), they are instantiated with new and you work with them just as with regular classes, no configuration file or similar is needed.

Similarly, there is no the distinction between methods and advice, there are just regular methods, which can be invoked explicitly (like regular methods) or implicitly (when a join point is being executed – like a regular advice).

Deployment and undeployment

HyperBeans are instantiated using the new keyword, which will call the constructor and instantiate the HyperBean just like any other POJO. However, the constructors can also control deployment of the HyperBean.

Deployment of a HyperBean means that its “blessed” methods (advice) are weaved in, while undeployment means that the woven code is removed.

You control deployment of a HyperBean by annotating (one or many of) its constructors with the @Deploy annotation. This example shows how to deploy a HyperBean as a singleton (more on other instantiation models later):

public class POJO {

    @Deploy
    public POJO() {    	
    }

    ... // remaining methods omitted 
}

Since there is no such thing as ‘destructors’ in Java, we are handling undeployment of HyperBeans by annotating a regular Java method (static or member) with the @Undeploy annotation. This means that when such a method is invoked, the HyperBean will be undeployed. It also give us the possibility of doing additional clean up (closing resources etc.) if necessary:

public class POJO {

    @Undeploy
    public void close() {
        // clean up - close resources etc.
    }

    ... // remaining methods omitted 
}

Instantiation models

You can control instantiation model (also called the deployment scope) of the HyperBean by adding a special argument to the constructor. This special argument defines the deployment scope for the HyperBean and needs to be annotated with the @Scope annotation. What this means is that the HyperBean will be deployed with the scope defined by the type of the argument.

For example, adding the argument Scope Thread scope</tt> to a constructor, (which is annotated with the <tt>Deploy annotation), will deploy the HyperBean with the scope of this particular thread.

Here are all the currently supported instantiation models:

Type annotated with @Scope	Instantiation model
`No argument with a @Scope annotation`	Singleton
`Thread`	Per Thread
`Class`	Per Type
`Instance` (but not of type `Class` or `Thread`)	Per Instance

Here are some examples:

public class POJO {

    /** Singleton deployment */
    @Deploy
    public POJO() {    	
    }

    /** Per Type deployment */
    @Deploy
    public POJO(@Scope Class scope) {    	
    }

    /** Per Instance deployment */
    @Deploy
    public POJO(@Scope SomeType scope) {    	
    }

    /** Per Thread deployment */
    @Deploy
    public POJO(@Scope Thread scope) {    	
    }

    ... // remaining methods omitted 
}

The current semantics for the @Scope annotation is that it:

Narrows the scope for the matching. For example using the Per Type instantiation model will add an implicit && within(scope) to the pointcuts defined in the HyperBean (same as in AspectJ).
Controls the life cycle. The HyperBean will have the same life cycle as the instance annotated with the @Scope annotation.
Controls state management. Tied to the life cycle.

Control flow management – no more cflow

There is no more any need for the cflow pointcut (as defined by AspectJ). Instead we suggest a simple programmatic model for control flow management of HyperBean deployment. I believe that the same functionality can be reached by a combination of the Per Thread instantiation model and the deployment/undeployment API. This approach has similarities with the work done in CaesarJ and its concept of a deploy {..} block. Here is an example:

You have a HyperBean that can be deployed on a per-thread basis:

class POJO {
    @Deploy
    public POJO(@Scope Thread scope) {    	
    }

    @Undeploy
    public void close() {
    }

    ... // remaining methods omitted 
}

Then you can use the following idiom to achieve fine grained control flow (cflow) management:

POJO hyperBean;
try {
    hyperBean = new POJO(Thread.currentThread()); // deploys the HyperBean to the current control flow ONLY
    
    ... // do stuff - the HyperBean is woven into this control flow ONLY

} finally {
    hyperBean.close(); // undeploy the HyperBean from the control flow
}

If you don’t want to have this be tangled with your application logic, you can of course put the block in an advice, (and have its HyperBean be a singleton and instantiated somewhere else):

@Around(..)
public Object cflowAdvice(InvocationContext ctx) {
    POJO hyperBean;
    Object result;
    try {
        hyperBean = new POJO(Thread.currentThread()); 
        result = ctx.proceed();
    } finally {
         hyperBean.close(); 
    }
    return result;
}

Cross-cutting methods – advice

So how do we define these “blessed” methods? They are defined using Java 5 annotations, in a similar fashion to AspectWerkz‘s and AspectJ 5’s annotation style of development, but mixed with the API defined by the JVM support for AOP in JRockit (as described in this article ).

Let’s take a look at an example:

public class POJO {
 
    @Before("call(Foo.new(..))")
    public void doSomething() {
        ... // do something before an instance of Foo is created
    }

    ... // remaining methods omitted 
}

This is a regular POJO with one “blessed” method that performs some action before an instance of Foo is created. There’s really nothing special with this class apart from that one of its method is annotated with a special annotation borrowed from the annotation style syntax in AspectJ. Now let’s take a look at a (slightly) more interesting example, one that makes use of contextual information.

public class POJO {
 
    @Before("call(@test.TraceMe * *.*(..))")
    public static void traceBefore(@CalleeMethod Method callee) {
        System.out.println("--> " + callee.toString());
    }
  
    @After("call(@test.TraceMe * *.*(..))")
    public static void traceAfter(@CalleeMethod Method callee) {
        System.out.println("< -- " + callee.toString());
    }

    ... // remaining methods omitted 
}

This is a regular POJO with two different “blessed” methods (that are tracing
invocations to all methods that are annotated with the @Trace annotation). Contextual information (like caller and callee method, caller and callee instance, parameters, return value etc.) is retrieved using annotated parameters borrowed from the JRockit API for AOP .

Here is a list of the current set of defined annotations and their meaning:

Annotation	Exposes
`@CalleeMethod`	The callee method (method, constructor, static initializer)
`@CallerMethod`	The caller method (method, constructor, static initializer)
`@Callee`	The callee instance
`@Caller`	The caller instance
`@Arguments`	The invocation arguments (wrapped in an object array)
`@Returning`	The return value (used in ‘after returning advice’)
`@Throwing`	The exception thrown from a method (used in ‘after throwing advice’)

These annotated arguments (except caller and callee method) also works as ‘filters’, the same is true for all unannotated arguments which are treated as the regular arguments to the method (or the field value about to be set etc.). The methods can be either member or static (dependent on if you want to keep state in the instance or not).

Since some people might be curious how “around advice” (i.e. ‘interception’) is handled, below is an example of how to implement the same functionality as in the class above using an “around advice”. Here we introduce the InvocationContext abstraction (similar to the ProceedingJoinPoint abstraction in AspectJ), which serves as the context on which we can invoke the proceed() method in order to continue with the execution flow.



public class POJO {
Around("call(test.TraceMe * .(..))")
public Object trace(InvocationContext ctx,
@CalleeMethod Method callee) {
System.out.println("—> " + callee.toString());
Object result = ctx.proceed();
System.out.println("< — " + callee.toString());
return result;
}
… // remaining methods omitted
}

Implementation

I have prototyped HyperBeans using the JVM support for AOP in JRockit. The implementation was actually very simple and shows the power of the JRockit API (the JRockit prototype is available now for those who wants to try it out).

I'll buy you a beer...

2005-09-13T00:00:00+00:00

I’ll buy you a beer…

I am at JavaPro Live! in San Diego doing a presentation titled: “AOP-Driven Services: Achieve Modularity and Reusability on the J2EE Platform” (the talk is 3:15 on Thursday Sept 14:th). If you are attending the conference, stop by and say hi.

I just finished rewriting the master template for the slides to follow a terra-cotta based color scheme. ;-)

This is actually my second week as a Terracotta employee and I am looking forward to the upcoming months. We are currently sketching on some very interesting new stuff, among other things, stuff tied to transparent runtime environments. More on that later.

I will, from now on, spend a lot of time in San Francisco, so if you are in the area, drop me an email and I will buy you a beer :-)

Just a warning: If it turns out that you have not tried Terracotta’s Virtualization Server and its Distributed Shared Objects (DSO), you will most likely here me rambling about that it is The way of doing distributed programming in Java (e.g. clustering and caching) and why you have to give it a try.

Thanks JRockit

2005-09-04T00:00:00+00:00

Thanks JRockit

I guess that most people have not missed that I am leaving BEA. Yesterday was actually my last day as an BEA employee.

I have had two great years at BEA. It has been a great experience to work at the Java Runtime Products Group (JRPG), (JRPG is the group that implements the JRockit JVM), not everyone gets the opportunity to work among so many extremely talented and smart people, and that is something that I am very grateful for. I have learned more in these two years that I had in my whole career.

I am also grateful for that JRPG has believed in AOP and my vision, so much and that they have allowed me to work full-time for two years to materialize them.

During this two year period we (Alexandre Vasseur and myself) have had the opportunity to participate in writing three important chapters in this story for AOP in Java:

1. The release of AspectWerkz 2.0
2. The merge of AspectWerkz and AspectJ
3. The support for AOP in the JRockit JVM (thanks to Joakim Dahlstedt)

It for sure has been a ride :-)

Thanks JRockit.

AOP Roadshow In Japan

2005-08-31T00:00:00+00:00

AOP Roadshow In Japan

Japan Tour

My Japan tour is starting to come to an end. During the past week I have been traveling in Japan, done two general sessions at BEA Tech Day 2005 conferences (Tokyo and Osaka), plus a press conference and a bunch of BEA internal training sessions.

I had never been to Japan before, but I am very interested in their culture and I love Japanese food, so this trip has in many ways been a very interesting and fun experience. I had some fears that my visit would turn out similar to the movie ‘Lost In Translation’ by Bill Murray (for those that have seen this movie), but my fears were unfounded. Most people spoke good english and I only met very generous people with a lot of heart.

Excitement around AOP

There is a lot of excitement and interest around AOP in Japan, both among developers, management and press. They are especially excited about AspectWerkz (it is actually more popular than AspectJ) and JRockit support for AOP.

It was fun to learn that they had translated every single article I have written, to Japanese. On the other hand, the problem having to translate almost every article and book is one of the biggest hurdles on the way to mass adoption of AOP.

Press conference

The press conference I did was an interesting experience, it was my first real press conference, with interviewers lined up, pounding me with questions. It was a lot of fun. The topic for the interview was JRockit and its new AOP support which they seemed very impressed about.

They have already published, two articles based on the press conference:
http://www.atmarkit.co.jp/news/200508/31/bea.html
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050830/167117/
and from what I understand, two more articles with the published.

BEA Tech Day 2005 in Tokyo

The general session I did had around 350 attendees and was simultaneously translated. Things worked out pretty well. People seem to like the talk and came up with a bunch of really good questions at the end. What was even more fun was that there were actually other speakers that talked about AspectWerkz/AspectJ in different contexts. One guy for example, talked about how to implement the transaction and dependency injection parts of the EJB 3 specification using AspectWerkz. In general, one of the main themes of the conference was AOP.

Afterwards, during the conference party, I was treated almost like a celebrity, with “fans” coming up and wanted to shake hands and have a picture taken with the mysterious AOP guru from the north pole (Sweden). :-)

Seasar framework – a Japanese Spring killer?

During lunch at the conference I had the pleasure of having interesting discussion with the founder of the dependency injection and component framework Seasar. For those that have never heard about Seasar, Seasar is a project very similar to Spring, which is more popular than Spring here in Japan. It uses plain bytecode manipulation to do the AOP part (and not proxies), and is based on the AOP Alliance interfaces. One cool thing that I found out about the project is that they are not only using but are very excited about Alex’s and my project backport175 (so much that they actually asked to contribute back some code).

BEA Tech Day 2005 in Osaka – Kyoto sightseeing

Today I am off for Osaka for my last talks at the BEA Tech Day 2005 in Osaka tomorrow. The trip will conclude with one day off, which I will spend sightseeing in Kyoto. Kyoto is the historical and cultural center in Japan, with many buildings and temples being more than 1000 years old (compared to Tokyo which is only a couple of hundred years old). So that is going to be interesting.

util.concurrent on steroids

2005-08-30T00:00:00+00:00

util.concurrent on steroids

Steve has written a nice article on how you can coordinate threads in a distributed application, transparently, and with very little effort.

He does this simply by sharing an instance of a CyclicBarrier, a class in Doug Lea’s excellent util.concurrent package(now included in JDK 5.0), across a cluster Using Distributed Shared Objects (DSO).

It really shows the power of DSO in action, by solving an extremely tricky problem in almost no time and no code.

Time to Throw Out Your Distributed HashMap?

2005-08-19T00:00:00+00:00

Time to Throw Out Your Distributed HashMap?

Patrick Calahan has written an interesting article on Distributed Shared Objects (DSO) and how they compare to traditional ways of doing caching and clustering. DSO might just as well be the death of the the distributed hashmap, e.g. JCache etc. Seems to be the only sane way of doing clustering in Java.

JVM support for AOP - part 2

2005-08-08T00:00:00+00:00

JVM support for AOP – part 2

The second part of our article series about JRockit JVM support for AOP is now published.

This article describes in more detail on how the API is used, showing some code samples and ends with a discussion in which we try to explain how we address the questions and issues (around the shortcomings of bytecode manipulation) raised in part one in the series.

The prototype will be downloadable soon, stay tuned.

Use Total Ordering of Objects to Avoid Deadlocks

2005-07-27T00:00:00+00:00

Use Total Ordering of Objects to Avoid Deadlocks

Writing multi-threaded applications in Java can as you know be quite tricky, and if not done correctly, one can easily end up with deadlock situations.

For example, take a look at this little code snippet. This piece of Java code implements a Node, which has three methods (that is of our interest):

Object get() void set(Object o) void swap(Node n)

Here’s the implementation:

public class Node { private Object value; public synchronized Object get() { return value; } public synchronized void set(Object value) { this.value = value; } public synchronized void swap(Node n) { Object tmp = get(); set(n.get()); n.set(tmp); } ... // remaining methods omitted }

This class might look okay, but it actually suffers from potential deadlock. For example what happens if, one thread T1 invokes n1.swap(n2) while an other one T2 concurrently invokes n2.swap(n1) ?

Thread T1 acquires the lock for node n1, and thread T2 acquires the lock for node n2. Thread T1 now invokes n2.get() (in the swap(..) method). This invocation now has to wait since node n2 is locked by thread T2, this while the reverse holds for thread T2 (e.g. it needs to wait for node n1 which is locked by thread T1). Which means that we have a deadlock.

This program is however easily fixed by using the technique of totally ordering all objects in the system.

public class Node { private Object value; public synchronized Object get() { return value; } public synchronized void set(Object value) { this.value = value; } private synchronized void doSwap(Node n) { Object tmp = get(); set(n.get()); n.set(tmp); } public void swap(Node n) { if (this == n) { return; } else if (System.identityHashCode(this) < System.identityHashCode(n)) { doSwap(n); } else { n.doSwap(this); } } ... // remaining methods omitted }

In this program, all locks will be acquired in increasing order, guaranteed to be the same for all threads, and thereby avoiding deadlock situations.

Semantics for a Synchronized Block Join Point

2005-07-18T00:00:00+00:00

Semantics for a Synchronized Block Join Point

As I mentioned in my previous blog entry, the synchronized block is currently not a supported join point in AspectJ 5 (or in any other AOP framework):

Currently you can for example pick out a call to a method that is declared as being synchronized and you can pick out calls to Thread:: notify()/notifyAll()/wait(). Meaning that being able to pick out synchronized blocks are the only missing piece left in order to completely control thread management and locking in Java. The actual bytecode modifications needed to make this work would be fairly simple, but capturing the correct semantics in a good language design would probably be a lot trickier.

Well, I’m not a language designer, but I think the problem is interesting so I will spend some time discussing it anyway.

In bytecode, a synchronized block is represented as a MONITOR ENTRY and a MONITOR EXIT bytecode instruction pair (however these are not required to be paired). The first natural approach would to let these two bytecode instructions be join points and treat them similar to field access and modification (PUTFIELD and GETFIELD bytecode instructions), meaning simply pick out (and intercept) this single bytecode instruction.

Just to clarify what I mean, here is an example of how the syntax for the above given semantics could look in the AspectJ pointcut expression language:
lock(Type t) && withincode(* Foo.bar(..)) && args(t)

unlock(Type t) && withincode(* Foo.bar(..)) && args(t)

Let us take a look at a synchronized block and how it would be affected:
synchronized(obj) { // body }

In bytecode to this is equivalent to (pseudo code):
MONITOR ENTRY // lock on obj // body MONITOR EXIT

If we now add around advices to these join points then we could for example get (pseude code):
try { // a call to the around advice, which calls the lock manager aroundAdvice1(obj) --> myLockManager.acquire(obj);


// body

} finally { aroundAdvice2(obj) —> myLockManager.release(obj); }

This approach would give you the possibility to completely control how locking is done in Java (including the possibility of enhancing or completely screw up the Java Memory Model (JMM)). On the other hand it does not allow you to pick out the actual code block that is synchronized (is this something that we want?) . Therefore this approach is perhaps not intuitive, since in Java source code, what we see is not lock acquisition and release but a code block that is guaranteed to be synchronized. So now let’s try to approach this problem from the perspective of source code.

Since AspectJ (and AspectWerkz) already has limited support for the synchronized keyword by allowing calls to methods declared as being synchronized to be matched, let us take a look at the semantics for this join point.

Here’s a simple method that is defined as being synchronized:
public synchronized void doStuff() { // body }

What this actually means is:
public void doStuff() { synchronized(this) { // body } }

The options we have of picking up this synchronized code block (wrapped up in the doStuff() method) is by using a

execution(synchronized void *.doStuff())

call(synchronized void *.doStuff())

pointcut.

Using the execution pointcut, the above method body would be transformed to (pseudo code):
synchronized(this) { // the advice has option of invoking the original body myAroundAdvice(this) }

I.e. only synchronized body is matched and intercepted.

If we are using the call pointcut, the same code snippet would be transformed to (pseudo code):
... // the advice has the option of invoking the original synchronized block myAroundAdvice(this) ...

I.e. the whole synchronized block, including the locking is matched (and intercepted). (This is conceptionally true, in regards to the locking, which is easy to see if you think of the doStuff() method as being inlined.)

I will not go into much detail about how these semantic differences should be expressed in the pointcut language here (this post is too long already). But for example, the last discussion would require the possibility of making a distinction between picking out a code block inclusively and exclusively (i.e. picking out the whole code block, or just the body of the code block), which could be expressed something like this:
// pick out synchronized block including the locking block-inclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t)

// pick out only the synchronized block’s body, not the locking block-exclusive(synchronized(Type t)) && withincode(* Foo.bar(..)) && args(t)

(These “block” pointcut descriptors can of course be used in any kind of block, loops, conditional statements etc., if/whenever they are supported in AspectJ.)

To sum up, the questions are: Do we want the power of intercepting the whole locking mechanism (but not the synchronized body), or is it better to follow the semantics we have for a synchronized method? Which approach addresses the use cases we want? Is the most intuitive? Is more orthogonal?

Thoughts? Comments? Ideas?

DSO: transparent clustering enabled through AOP

2005-06-07T00:00:00+00:00

DSO: transparent clustering enabled through AOP

Terracotta just recently launched a product (DSO) for clustering POJOs in a completely transparent way. What I find interesting in this product is not mainly in the clustering and caching, but how they make use of AOP and loadtime weaving to make it completely transparent.

This sounds a lot like techniques that we have been working on in AspectWerkz last years, and I was not too surprised, although very happy, to learn that they are actually using AspectWerkz. It is really great to see some of the ideas that Alex and I have been working on being used in new and interesting ways and in real-world applications.

They seem to use techniques that are fairly similar to the Unit of Work aspect library that I wrote for the AWare aspect library. Meaning: record field changes to object graphs within a transaction which can be committed/rolled back./etc. add specific methods that are defined declaratively.

However they have extended to this idea by adding semantics currently not available in AOP. For example being able to pick out synchronized blocks. This is a great idea, and when you think of it, it is in a way a hole in the current AOP implementations. Currently you can for example pick out a call to a method that is declared as being synchronized and you can pick out calls to Thread:: notify()/notifyAll()/wait(). Meaning that being able to pick out synchronized blocks are the only missing piece left in order to completely control thread management and locking in Java. The actual bytecode modifications needed to make this work would be fairly simple, but capturing the correct semantics in a good language design would probably be a lot trickier.

All and all a very interesting product that shows the beauty of AOP and loadtime weaving in action, go and check it out.

JVM support for AOP (technical session at JavaOne 2005)

2005-05-29T00:00:00+00:00

JVM support for AOP (technical session at JavaOne 2005)

If you’re interested in knowing more about what the future holds for AOP, then you should come to the technical session TS-7659 (titled “Runtime Aspects With JVM Support”) on Tuesday, June 28 at JavaOne 2005.

This will be the first time ever to show an enterprise JVM – BEA JRockit – with native AOP support. Alex Vasseur and myself have been pushing for this idea since the early days of AspectWerkz when we joined the JRockit group, and it’s finally taking shape, with now support for AspectJ 5, the de-facto standard for AOP in Java.

Credit should also go to Joakim Dahlstedt, the CTO of JRockit, who has been playing a leading role in the design and implementation.

We will talk about the current problems with bytecode based weaving (multiple agents, double bookkeeping, performance etc.) and then discuss how these problems can be solved through native JVM support. We will show a prototype of our implementation, go through the programming model and run a live demo.

Here is the abstract:

“Aspect Oriented Programming (AOP) is growing in popularity. Adding aspects at runtime, dynamic weaving, can be a very powerful technique for diagnostics, profiling, or debugging of a running system. The concept of adding aspects at runtime (dynamic weaving) is looked upon with skepticism by some. It’s also easy for multiple instrumenting agents to cause havoc for each other. We have implemented prototype changes to our Javaâ„¢ Virtual Machine (JVMâ„¢ software), BEA Weblogic JRockit, to support dynamic weaving in the JVM software in a controlled fashion. We also have modified AspectJ 5 to try out this functionality. We believe our changes to the JVM software to support dynamic weaving lessens the skepticism about runtime aspects and allows for multiple instrumenting agents to coexist.
In this session we present the changes we made to the JVM software to support this functionality and the results of this effort. In addition, we compare this approach to current approaches like JVMTI/Hotswap and Project JFluid. Finally, we provide a demonstration of various runtime advice you’ll find useful to analyze the behavior of your applications.”

Don’t miss it, see you there.

Nordev 2005: Rickard on real world use-cases for AOP etc.

2005-05-20T00:00:00+00:00

Nordev 2005: Rickard on real world use-cases for AOP etc.

I just got back from the Nordic Software Developer Summit (Nordev) 2005. Strange enough, this is the first good developer conference that we have had in Sweden.

Altogether it was a really good event with two major tracks, one Java and one .Net. The Java track had interesting talks on topics like: AOP :-), agile development, hibernate, spring, manageability of the JRockit JVM etc. (e.g. the usual suspects).

I was glad to see that AOP got a lot of focus with talks from myself and Rickard Oberg and a hands-on workshop (on AspectJ). Both sessions were packed, and people seemed enthusiastic about it.

Of all things you can be nervous about, I was nervous about speaking in Swedish (my native language). I had never spoken about AOP in Swedish so it was interesting and a good exercise :-). Everything went pretty well except that eclipse died on me when I was starting up the demo (3.1 M6). (The demo was about how to write a unit of work to achieve transparent persistence/replication/transaction management, perhaps something for an upcoming blog post…).

I enjoyed Rickard’s talk. He based the talk on examples from the CMS application and he has built, and it was interesting to see both simple and advanced usage of AOP in the real world application. He’s using a pretty extreme approach to AOP in which every single object is built up a using intertype declarations (introductions/mixins). I do not think that this model fits every project, and it for sure has drawbacks, but in their CMS application it has given them extremely high reuse and development speed.

He showed examples of client aspects, how objects can render themselves differently based on which intertype declarations it has. For example, if an object in their GUI (a page, a site, a portlet etc.) has the intertype declaration ACL applied to it then it will give you the possibility to open up a window to manage security for this object. This object can also be given the Tree intertype declaration, which will allow you to browse the object in a tree structure etc.

He also showed examples on how they do client synchronization and cluster wide replication, using the same aspect (which simply records the events triggered and then plays it back). Another interesting aspect that they have is what he calls partial object versioning, in which intertype declarations can be versioned and different versions can be used (in the same object), depending on how system is configured.

Rickard gave an example of a customer that came in with a new functional requirements very late in the release cycle, requirements that required redesign of some parts of the system, but that he managed to solve in a simple and generic way by applying an aspect.

Then he talked about the need for tools and that most problems that people are complaining about when it comes to AOP are actually not related to AOP, but to the lack of good tools. He showed one interesting tool that they are using on a daily basis, a tool for doing a diff of the system. This diff showed you which advice and or intertype declarations had been removed or added since the last time the system’s state was recorded. For example, after a regular refactoring, the diff should be zero. This is something that we should add to AJDT.

All and all a good conference, you should try to get there next year.

JRockit 5 Memory Leak Tool

2005-03-21T00:00:00+00:00

JRockit 5 Memory Leak Tool

The upcoming release of JRockit will contain a new, completely killing, tool for memory leak detection.

It allows you to (among many other things) to profile an application running in production with (almost) zero overhead (without shutting it down or any preparation whatsoever).

Bill Burke and Dion Almaer has already blogged about it.

Go and check it out. It is free (shipped with JRockit).

AOSD.05 has started

2005-03-15T00:00:00+00:00

AOSD.05 has started

AOSD 2005 has just started. I am excited, and have high expectations since last years conference was a real hit, and this year we have a separate industry track with many interesting talks coming up, f.e. Grady Booch is doing a keynote.

I will be giving a talk on AspectWerkz 2 and the road to AspectJ 5 at the AOSD 2005 conference hosted at the Intercontinental hotel in Chicago.

If you are in the area, please drop in and say hi.

If you are interested you can read the abstract etc. here

For those who can’t make it, I will make the slides available online after the conference.

Hope to see you there…

Interception Done Right

2005-01-06T00:00:00+00:00

Interception Done Right

One of the new features in the AspectWerkz 2 architecture is that it comes with a full-blown interception framework that allows per instance programmatic deployment with most of the AOP semantics preserved. You can make use of this using both the regular load-time weaving or the AW Proxy (that I blogged about here)

In short you will get:

Per instance programmatic deployment for before, around, after, after finally and after throwing advice types for call, execution, set and get pointcuts as well as the expressiveness of the AspectWerkz’ pointcut pattern language all wrapped up in a very simple and intuitive API.

    POJO pojo = new POJO();

    // adds tracing to all methods in the 'pojo' instance
    ((Advisable) pojo).aw$addAdvice(
        "* *.*(..)",
        new BeforeAdvice() {
            public Object invoke(JoinPoint jp) {
                System.out.println("Entering: " + jp.getSignature().toString());
            }
        }
    );

The Advisable interface

From a users perspective pretty much all you need to know about is in the Advisable interface. This interface is added to all the classes that you want to do per instance runtime deployment at. This interface is added to your classes by the framework, but more on that later.

The Advisable interface basically has two methods that are of interest to you:

void aw_addAdvice(String memberPattern, Advice advice) – this methods allows you to add an Advice instance to the members specified by the memberPattern argument
void aw_removeAdvice(String memberPattern, Class adviceClass) – this methods allows you to remove the last advice (that was added last) of the type specified in the adviceClass argument from from the list of aspects applied to the members specified by the memberPattern argument

The funny prefix aw_ is just to minimize method clashes since these methods are added to your classes on-the-fly.

The different Advice interfaces

The intercept framework supports all main types of advice defined in AOP today:

AroundAdvice – works like a regular interceptor and is invoked “around” or “instead-of” the target method invocation or field access/modification.

It has one method you need to implement which has the following signature:

Object invoke(JoinPoint jp)
BeforeAdvice – is invoked before the actual member invocation
It has one method you need to implement which has the following signature:
Object invoke(JoinPoint jp)
AfterAdvice – is invoked after the actual member invocation, is invoked both if the method returns normally or with an exception. E.g. can be seen as being invoked in the finally block.
jt has one method you need to implement which has the following signature:
Object invoke(JoinPoint jp)
AfterReturning – is invoked after the actual method has returned normally
It has one method you need to implement which has the following signature:
Object invoke(JoinPoint jp, Object returnValue)
AfterThrowingAdvice – is invoked after the actual method has returned with an exception
It has one method you need to implement which has the following signature:
Object invoke(JoinPoint jp, Throwable exception)

As you can see, all of these methods takes a JoinPoint instance as a parameter. This class contains f.e. contextual information bout the join point (member) we are executing before/after/around. Such as caller and callee instances and types, argument values and types etc. You can also see that some of the advice takes an optional parameter which provides direct access to the return value or the exception instance.

Preparing your application

To make this work you finally need to tell AspectWerkz which classes you want to make “advisable” and to which extent. This is done in the META-INF/aop.xml deployment descriptor in which you have to make use of the <advisable …/> element. This element has two attributes:

expresssion – here you specify the type pattern that picks out the classes that you want to make “advisable” and this is done by defining a within(<TYPE PATTERN>) pointcut expression
pointcut-type – here you defined which pointcut semantics you want the added advice to follow
Valid types are:
- call – the advice added to a method will be invoked on the caller side of the method invocation (if you think client-server then it is executing on the client side)
- execution – the advice added to a method will be invoked on the execution side of the method invocation
- set – the advice added to a field will be invoked when a field is modified
- get – the advice added to a field will be invoked when a field is accessed
- all – a combination of all the above pointcut types

Example:



    <aspectwerkz>

        <system id=“intercept-sample”>

            <advisable expression=“within(my.application.domain.*)” pointcut-type=“call|set|get”/>

        </system>

    </aspectwerkz>

Bringing it all together

So now we have talked about the Advisable interface that we can use to add the advice we want to a specific instance. We have talked about the different Advice interfaces and their differences. Finally we talked about how we tell the AspectWerkz container which classes it should make “advisable” and how it should treat them. Let’s now try to bring it all together in a small example.

In this example we are taking a regular POJO and we are adding an advice that will be applied to all methods that are annotated with the annotation @OneWay and turn the otherwise synchronous invocations into ansynchronous invocations.



    …
POJO pojo = new POJO();
((Advisable) pojo).aw_addAdvice(
“@OneWay * .(..)”,
new AroundAdvice() {
private Executor m_threadPool = Executors.newCachedThreadPool();
public Object invoke(JoinPoint jp) throws Throwable {
m_threadPool.execute(
new Runnable() {
public void run() {
try {
// proceed with the invocation in a new thread
jp.proceed();
} catch (Throwable e) {
throw new RuntimeException(e);
}
}
}
);
return null;
}
}
);
…

The META-INF/aop.xml file looks like this:



    <aspectwerkz>

        <system id=“intercept-sample”>

            <advisable expression=“within(sample.intercept.POJO)” pointcut-type=“call”/>

        </system>

    </aspectwerkz>

Resources

I have not written any specific sample application for this article but if you want you can look at and run the tests in the AspectWerkz distribution. You can download the distribution here. The tests are in ./src/test/test/intercept/* directory and you can run them (along with all the other tests) by invoking ant test when standing in the AspectWerkz distribution’s root dir.

Enjoy

Aspect hot deployment in practice: Implementing a JMX monitoring aspect

2004-12-15T00:00:00+00:00

Aspect hot deployment in practice: Implementing a JMX monitoring aspect

One of the new features in the AspectWerkz 2 architecture is the ability to deploy and undeploy aspects at runtime, e.g. to do “hot” deployment and undeployment.

The implementation is based on HotSwap class redefinition and handles ‘change sets’ which ensures that the changes to each single join point is atomic. What this means in practice is that if you for example are deploying an aspect which has one before and one after advice, both advising the same join point (method/field etc.) then either both of them will be added or none.

The API exposed to the user is very simple and straight forward to use. Everything is handled by the Deployer class, which provides the following API for runtime deployment and undeployment of aspects:

    DeploymentHandle deploy(Class aspect)
    DeploymentHandle deploy(Class aspect, ClassLoader deployLoader)
    DeploymentHandle deploy(Class aspect, DeploymentScope scope)
    DeploymentHandle deploy(Class aspect, DeploymentScope scope, ClassLoader deployLoader)
    DeploymentHandle deploy(Class aspect, String xmlDef)
    DeploymentHandle deploy(Class aspect, String xmlDef, ClassLoader deployLoader)
    DeploymentHandle deploy(Class aspect, String xmlDef, DeploymentScope scope)
    DeploymentHandle deploy(Class aspect, String xmlDef, DeploymentScope scope, ClassLoader deployLoader)
    void undeploy(Class aspect)
    void undeploy(Class aspect, ClassLoader loader)
    void undeploy(DeploymentHandle deploymentHandle)

As you can see you can for example choose to deploy an annotation defined aspect, e.g. a regular Java5 class with AspectWerkz defined annotations (or a regular Java 1.3/1.4 class with AspectWerkz defined JavaDoc annotations, compiled with AspectWerkz’s JavaDoc annotation compiler):

in the context classloader (just specify the aspect class)
in an arbitrary class loader (this option is most useful for application server vendors that can garantuee that all the dependecies can be resolved)
within a specific DeploymentScope (more about this in a minute)

You can read more about how you can use the DeploymentHandle (that is returned from each of these methods) here.

You also deploy a class without any annotation definition and pass in the definition in XML format. Here you pass in a string containing the <aspect>…</aspect> part of the regular aop.xml definition (see the online docs for details).

Use-case: Implementing a JMX monitoring aspect

Now let’s take a look at a concrete example on how to hot deploy an aspect that can do some monitoring for us, report that to an JMX MBean and then undeploy it when the monitoring is done.

Writing the aspect

So first, here is the (main parts of the) JMX monitoring aspect:



    @Aspect

    public class ResponseTimeAspect {
… // methods for registering the MBean lazily, member fields etc.
// the “invocationsToMonitor” pointcut will be defined at deployment time
// in the aop.xml file
@Around(“invocationsToMonitor”)
public Object monitor(StaticJoinPoint jp) throws Throwable {
Signature signature = jp.getSignature();
long tsStart = System.currentTimeMillis();
Object result = null;
try {
result = jp.proceed();
} finally {
// note: this code is using a JMX helper method and
// we will have one MBean per jointpoint signature (i.e. method, field, etc.)
long tsElapsed = System.currentTimeMillis() – tsStart;
ObjectInstance mbeanI = registerMBean(signature);
if (mbeanI != null) {
m_mbeanServer.invoke(
mbeanI.getObjectName(),
“update”,
new Object[]{new Long(tsElapsed)},
new String[]{long.class.getName()}
);
}
}
return result;
}
public static void enableMonitoring(String pointcut) { … }
public static void disableMonitoring() { … }
}

As you can see, this aspect is defined using Java5 annotations, but if you are using Java 1.3/1.4 you can define the annnotations using JavaDoc (just put the annotation exactly as it is in the JavaDoc for the method/class) and run AnnotationC on the class. Then the rest in this article should stay the same. You can read more about the AnnotationC compiler here.

Hot deploy and undeploy the aspect

As you can see we have added two static methods to the aspect, these will be used to enable and disable the response time aspect. E.g. deploy it and undeploy it.

First we have the enableMonitoring method, which enables monitoring in our application, e.g. deploys the monitoring aspect. This method can be invoked at any point in time, all threading issues etc. are handled by the underlying implementation. Here we make use of the XML definition to resolve the annotation definition in the aspects by defining the “abstract pointcut” that we have bound the advice to (the invocationsToMonitor pointcut).

    public static void enableMonitoring(String pointcut) {
        String xmlDef = "&lt;aspect&gt;&lt;pointcut name='invocationsToMonitor' expression='" + pointcut + "'/&gt;&lt;/aspect&gt;";
        Deployer.deploy(ResponseTimeAspect.class, xmlDef);
    }

Second we have the disableMonitoring method which disables monitoring for us, e.g. undeploys the aspect from all the join points where it had been defined (see the concept of DeploymentHandles for a more fine grained undeployment API).



    public static void disableMonitoring() {

        Deployer.undeploy(ResponseTimeAspect.class);

    }

Use the aspect to monitor JDBC SQL statements

This means that in the user code, all we need to do to enable and disabling this aspect is to invoke these two methods. Here we will monitor the executions of all JDBC statements:



    public static void trackResponseTimeOfSqlQueries() {

        ResponseTimeAspect.enableMonitoring(“call(* java.sql.Statement+.execute*(..))”);
… // wait a while to do a recording
ResponseTimeAspect.disableMonitoring();
}

What this pointcut expression (call(* java.sql.Statement+.execute*(..))) actually means is:

Pick out all method calls (call(..))
to alll methods that has a name that starts with execute (execute*)
that can have any parameter types ((..)) or return type (*)
that are in a concrete class that implements the java.sql.Statement interface (java.sql.Statement+)

By basing the pointcut expression on an interface we can be igonrant of how the actual JDBC driver is implemented (concrete subclasses etc.).

Note: we could in this specific use-case benefit from retrieving and storing the parameter value to the execute*(..) methods, since it is the actual SQL query that we are monitoring the execution time of. This could be done really easy but is out of scope for this article.

So now after doing some monitoring you should be able to easily see the data in any JMX console. For example hook in JConsole which you can read more about in this article.

Define a deployment scope

Finally, to get this to work in the general case we need to define a deployment scope which defines the set potential join points that we might want to monitor at runtime.

This construct gives you (as a application developer or vendor) control over which join points are exposed to the hot deployment API i.e. helps to prevent usage of the hot deployment facilities in specific areas of the application.

This can be done either in the META-INF/aop.xml file or using annotations in the aspect class. In this case we want to make the aspect generic so we will define it in the external XML definition:



    <aspectwerkz>

        <system id=“monitoring”>

            <deployment-scope name=“response_time” expression=“call(* sample.deployment...(..))”/>

        </system>

    </aspectwerkz>

Here we have defined a deployment scope that picks out all method calls in our sample application, which means that we can safely deploy our ResponseTimeAspect at these points. (We could have added something like AND within(package..*) to the expression if we wanted to narrow down the scope.)

In the code above we have an implicit contract that says that we can not define the aspect to be deployed outside a deployment scope. If we do not define a pointcut that is wider than this it is all fine. But we can now use this deployment scope to ensure that we only deploy the aspect at valid points. To do that we need to retrieve a handle to the scope like this (can be done at any point):



    DeploymentScope scope = SystemDefinition.getDefinitionFor(loader, systemId).getDeploymentScope(“response_time”);

Now we can use the DeploymentScope handle to make a more explicit deployment (e.g. knowing exactly the points where our aspect will be applied):



    Deployer.deploy(ResponseTimeAspect.class, xmlDef, scope);

Notes on the impact of the deployment scope preparation

The preparation made by the deployment scope construct means in practice that we are simply adding a level of indirection by adding a call to a public static final method that redirects to the target join point (method, field, constructor). This method will be inlined by all modern JVMs.

When we do undeploy of an aspect, if this aspect is the last one that affects the join point, then the class’ bytecode will be reverted to the same state it had before any aspect was deployed.

Resources

More info about the JMX ResponseTimeAspect

The code for the monitoring aspect is based on the implementation of the ResponseTimeAspect in the AWare Project. The only difference is that in this example I am defining it using Java5 annotations and I have added the two static methods for doing the deployment and undeployment. You can read more about this aspect here and the source code for it can be found here.

You can also check out the complete AWare project which has some tests for the JMX module. Info about how to check out the sources can be found here.

More info about the Deployer Module

I have not written any specific sample application for this article but if you want you can look at and run the tests for the deployer module in the AspectWerkz distribution. You can download the distribution here. The tests are in ./src/jdk15/test directory and you can run them by invoking ant test:jdk15 when standing in the AspectWerkz distribution’s root dir.

The aspectwerkz*.jar jars and the dependency jars are in the ./lib folder in the AspectWerkz distribution.

Enjoy.

CGLIB with Native Support for AspectWerkz

2004-12-13T00:00:00+00:00

CGLIB with Native Support for AspectWerkz

The idea

After implementing the AW Proxy extension to AspectWerkz I figured, why not hook into the most widely used proxy implementation out there: cglib and let AspectWerkz weave in the aspects that are around just before the proxy is returned to the user.

The solution

So, this is all that this cglib extension does: asks AspectWerkz if it has anything to say about the class that has just been proxied. If so, then let the AspectWerkz weaver do its job, e.g. weave in the aspects that are currently deployed (on the classpath), and when returns the proxy to the user.

If no AspectWerkz aspects are found that has pointcuts that matches the class being proxied then nothing happens.

All that was needed to make this work was to add 30 lines of code to one single cglib class.

How do I use it?

This means that all you need to do to make any cglib based applications, and there are many: Geronimo, dynaop, Spring AOP, Hibernate etc., become “aspectwerkz-aware” is to replace one single class in the cglib.jar jar.

Or.

If you can’t or don’t want to patch the cglib.jar jar, you can just put the class before the jar on the classpath.

What is the impact on my existing code?

If no AspectWerkz aspects are found that has pointcuts that matches the class being proxied then nothing happens.
And if AspectWerkz is not available then the whole process is skipped. So basically, there is nothing to loose, it is pay as you go (or should I rather say: gain as you go ;-) ).

How do I get it?

The single file you need can be found in the AspectWerkz RC2 distribution, which you can find here.

The cglib extension is in the ./src/cglib-ext dir (in the root of the AspectWerkz distribution). So step into this directory and type ant dist and it will compile the class and put it in a jar that is to be found in the ./src/cglib-ext/target. This jar only contains one single class file (which you either put in the cglib.jar jar or make sure that it is before the jar on the classpath).

In the ./src/cglib-ext dir you also have a sample that you can run. This sample is just a sample taken from the cglib distribution, but it has a tracing aspect on the classpath, that is weaved into the proxy. You can run this test by invoking ant samples:trace.

Enjoy.

AWProxy: Proxy on steroids

2004-12-08T00:00:00+00:00

AWProxy: Proxy on steroids

Summary

Proxies are an important piece in the J2EE puzzle. Since it offers a non-intrusive an more transparent way of weaving in advice/interceptors. However, non of the current proxy implementations utilizes all the rich semantics of AOP (as defined by AspectJ), the expressiveness of a real pointcut pattern language and has the speed of statically compiled code.

AW Proxy is here to try to narrow this gap. It makes use of the rich semantics for AOP in AspectWerkz and is very high-performant due to the use of static compilation (utilizing the AspectWerkz weaver). All wrapped up a very simple and intuitive API.

The need for proxies

The two arguments against load-time weaving that we hear the most are:

that it is complex –
which is an argument that I don’t understand, since all you need to do is to add one single VM option when starting up the VM
that the transparency of proxies is hard to beat –
which is an argument that I can fully agree on

Adding the possibility of using AspectWerkz together with proxies is something that Alex and I have been talking about for a long time but never implemented due to lack of time. Well, this weekend I took the time and it was actually more simple than I thought.

After a couple of hours coding (taking the cglib route with its “class proxy”, e.g creating a new class on-the-fly that extends the target class and which methods and constructors delegates to the base class’ methods, but with the difference that they don’t wrap the arguments but pass them on as they are, which gives a lot better performance), I had a working solution.

Introducing AW Proxy

The benefit with using the AspectWerkz Proxies compared to the regular load time weaving is that there are no VM options. You simply create your proxy and before it is returned to you it is weaved with the aspects that happens to be available on the classpath at that time.

The API is pretty straight forward. All you need is in the



    org.codehaus.aspectwerkz.proxy.Proxy

class which has the following API:



    // Returns a new proxy for the class specified

    public static Object newInstance(Class clazz);
// Returns a new proxy for the class specified, instantiates it by invoking the constructor
// with the argument list specified
public static Object newInstance(Class clazz, Class[] argumentTypes, Object[] argumentValues);
// Same as above, but with optional parameters for caching and making the proxy advisable
public static Object newInstance(Class clazz, boolean useCache, boolean makeAdvisable);
// Same as above, but with optional parameters for caching and making the proxy advisable
public static Object newInstance(Class clazz, Class[] argumentTypes, Object[] argumentValues,
boolean useCache, boolean makeAdvisable);

The makeAdvisable argument decides if the proxy instance should be advisable, e.g. be prepared for runtime programmatic deployment. More on this later in this article.
The useCache argument decides if the Proxy should try to reuse an already compiled proxy class for the specific target class. If you set this flag to true then a cached class it is returned (if found) e.g. no new proxy class is compiled. This has both benefits and drawbacks. The benefits being that if there is a new aspect that has been deployed that advises a new join point in the target class then these new join points will not be advised (but already advised join points will be redefined). However if you set this flag to false then a new proxy class will be compiled for each invocation of the method, which will make the invocation a bit slower but you will get a completely new proxy class that is advised at all matched join points.

How to use the API?

Here is a little example on how to use the Proxy API:



    // creates and instantiates a new proxy for the class Target

    Target target = (Target) Proxy.newInstance(Target.class, false);

That’s it!

This target instance have now been advised with all the aspects that have been found on the classpath that matches the members of the Target class.

Utilizing programmatic runtime deployment

As I said before, when you create your proxy it will get automatically weaved with all the matching aspects that are found (on the classpath). This is most of the time what you want and need, but there might be cases when you want to add a specific feature, at runtime, to a specfific instance only. In these cases you need programmatic runtime per instance deployment.

    POJO pojo = new POJO();

    // adds tracing to all methods in the 'pojo' instance
    ((Advisable) pojo).aw_addAdvice(
        "* *.*(..)",
        new BeforeAdvice() {
            public Object invoke(JoinPoint jp) {
                System.out.println("Entering: " + jp.getSignature().toString());
            }
        }
    );

The advice “interceptors” that are supported are:

AroundAdvice – works like a regular interceptor and is invoked “around” or “instead-of” the target method invocation or field access/modification.
BeforeAdvice – is invoked before the actual member invocation
AfterAdvice – is invoked after the actual member invocation, is invoked both if the method returns normally or with an exception. E.g. can be seen as being invoked in the finally block.
AfterReturning – is invoked after the actual method has returned normally
AfterThrowingAdvice – is invoked after the actual method has returned with an exception

Now we can combine use this feature together with the AW Proxies. All proxies that are created implements the Advisable interface which makes it really easy and straightforward to use them together:

Example

In this example we create and instantiate a new proxy for the class Target, we set it to become advisable (e.g. it will implement the Advisable interface transparently), and then we add an after returning advice to all methods that returns an instance of java.lang.String.


Advisable target = (Advisable) Proxy.newInstance(Target.class, true, true);
target.aw_addAdvice(
“String .(..)”,
new AfterReturningAdvice() {
public void invoke(JoinPoint jp, Object returnValue) {
// do some stuff
}
}
);

Benefits

Plain proxies with rich AOP semantics

The benefits are, besides a less intrusive and more transparent approach, that you can utilize the rich semantics for AOP (well, not all, see below for limitations) that are supported AspectWerkz. Such as, a rich pointcut expression language, before/after/around advice, deployment modules defined by the META-INF/aop.xml file etc.

Very high-performant

You will also get the full performance of the AspectWerkz 2 architecture.

If you are interested details of the benchmark we made (and/or run it yourself) then you can read this paper.

But in short AW Proxy is roughly:

25 times faster than Spring AOP for before and after advice
8 times faster than Spring AOP for around advice
16 times faster than dynaop for before and after advice
5 times faster than dynaop for around advice
4 times faster than straight cglib for before and after advice
1.25 times faster than straight cglib for around advice

Limitations

Since it is a proxy approach it only supports execution pointcuts and can only advise methods and constructors that is non-private and non-final. E.g not call, set, get or handler pointcuts. Advice bound to these pointcut types will simply not affect the class being proxied.

Resources

This new feature will be available in AspectWerkz 2.0 RC2 that will be available soon. Until then you can check out the sources from the CVS and build it yourself (by invoking ant dist).

There are some samples in the ./src/samples/examples/proxy dir in the distribution. These can be executed by invoking ant samples:proxy from the command line.

Enjoy.

Off to Vietnam for two months

2004-12-07T00:00:00+00:00

Off to Vietnam for two months

I am travelling with with my wife and my one year old son in Vietnam for a couple of months.

It’s been a pretty hectic fall so I am looking forward resting my mind for a while. Although I am pretty sure that travelling in Vietnam with a little kid is not all relaxing (but for sure interesting :-) ).

See you in a while.

/Jonas

Spring and AspectWerkz: A Happy Marriage v2

2004-12-06T00:00:00+00:00

Spring and AspectWerkz: A Happy Marriage v2

The AspectWerkz 2 architecture has been designed to be an Extensible Aspect Container, which can deploy and run arbitrary aspects. You can read more about the details in this article.

In this article I will show you how you can make use of this container to run Spring AOP aspects more performant plus utilize the annotation-driven AOP in AspectWerkz along with its more expressive pointcut pattern language.

In this article I am using Spring as an example but everything covered here applies to all frameworks that implements the AOP Alliance interfaces (e.g. dynaop, JoyAop, JAC etc.).

Write a regular Spring advice

First we write a regular spring advice that implements authentication:



    public class AuthenticationAdvice implements MethodBeforeAdvice {
public void before(Method m, Object[] args, Object target) throws Throwable {
// try to authenticate the user
// if not authenticated throw a SecurityException
}
}

Define the advice using Java 5 annotations

In this example we will not define this advice using the slightly verbose Spring config file. But make use of Java 5 annotations. In AspectWerkz you have a set of predefined annotations that we can use, f.e. one for each advice type. The advice we have implemented here is a before advice so we will use the @Before annotation when defining the advice:



    public class AuthenticationAdvice implements MethodBeforeAdvice {
@Before(“authenticationPoints”)
public void before(Method m, Object[] args, Object target) {
// try to authenticate the user
// if not authenticated throw a SecurityException
}
}

Here we bind the advice to the pointcut named “authenticationPoints”, this pointcut will pick out all the points where we want authentication to take place. However we do not define this pointcut yet. Since we want to make this aspect reusable, then it is better to just compile it, put it in a jar and then at deployment time resolve this definition by defining the pointcut in the external META-INF/aop.xml file.

We can of course choose to not define the pointcut in an external XML file but directly in the Before annotation like this:



    Before("call(RestrictedOperation * .(..))")

    public void before(Method m, Object[] args, Object target) {

        … 

    }

if we think that that is beneficial. (Then the META-INF/aop.xml only have to define the aspect class name, see below for details).

Define the pointcut in the external aop.xml file

Now all we need to do put this advice to work is to write the little META-INF/aop.xml file.
In this case there are two things that we need to define there:

we need to tell the AspectWerkz container that it should deploy this Spring advice as a regular AspectWerkz aspect
we need to resolve the definition by defining the “authenticationPoints” pointcut

Example:



    <aspectwerkz>

        <system id=“spring-extension-sample”>

            <aspect class=“my.application.aspects.AuthenticationAdvice”>

                <pointcut name=“authenticationPoints” expression=“call(@RestrictedOperation * .(..))” />

            </aspect>

        </system>

    </aspectwerkz>

Here we defined the pointcut to pick out all method calls to a method that is marked with the annotation @RestrictedOperation.

Note that we are using a call pointcut here, which means that this advice will execute on the client side and not the server (something that is not possible with regular spring aop which only supports execution pointcuts). This can be beneficial in many situations, it can f.e. can save us a remove call from the client to the server, or take some load off the server if the client is executing in a separate VM, etc.

Start up the application

The last thing we need to do is to add two VM options:

we need to register the Aspect Model implementation for the Spring extension in the AspectWerkz container. This is done like this:

-Daspectwerkz.extension.aspectmodels=org.codehaus.aspectwerkz.transform.spring.SpringAspectModel
we need to register the AspectWerkz weaver agent:
-javaagent:lib/aspectwerkz-jdk5-RC2.jar

You also need to put the aspectwerkz-core-RC2.jar, aspectwerkz-RC2.jar, aw-ext-spring-0.1.jar and aw-ext-aopalliance-0.1.jar plus the regular AspectWerkz dependency jars on the classpath. (You find the aspectwerkz jars in the aspectwerkz distribution and the aw-ext-*.jar jars you need to build yourself (see Resources for details).

The you can start up the application as usual using java ….

We have been thinking of providing a way of defining the spring aspect model on the application level (per META-INF/aop.xml file) and not only on the VM level (using a VM option). If there is interest in this, please get back to us and we will add support for this.

<!—p>
This means that we can start up the application like this:

set AspectWerkz version and libs dependancies
set VERSION=2.0.RC1
set DEPS=… // AspectWerkz dependancies – see bin/setEnv for the complete list

all AspectWerkz jar, and dependancies
set AW_PATH=aspectwerkz-core-$VERSION.jar:aspectwerkz-$VERSION.jar:$DEPS

-javaagent option
adapth the path to aspectwerkz-core-$VERSION.jar as required
java ~~javaagent:lib/aspectwerkz-jdk5~~$VERSION.jar -cp $AW_PATH:… \
-Daspectwerkz.extension.aspectmodels=org.codehaus.aspectwerkz.transform.spring.SpringAspectModel \
… my.application.Main

What about my Spring bean config file, dependency injection etc?

Good news is that you can still use your regular Spring bean config file and let Spring do its job, with dependency injection, bean configurations etc.

AspectWerkz has a pluggable factory mechanism for the aspect instantiation and life-cycle management. We have written a factory for the Spring framework that allows you to use Spring to configure your aspects/advice just as usual. Read more about that here.

Much better performance

Apart from allowing defining your aspects using Java5 annotations and using the semantics of the AspectWerkz pointcut language and weaver, you will also get much better performance (ranging between 1300 to 50 percent). I won’t go into detail on that here but you can read more about it in this article.

Drawbacks

Everything has tradoffs and there are of course some drawbacks in using the AspectWerkz Extensible Aspect Container as the runtime environment for your Spring aspects/advice:

You will weave the actual target classes – this is a more intrusive way of doing the weaving, which in some cases perhaps is not beneficial
You need a couple of extra VM options when you start up your application.
You need one extra XML (very tiny) config file – the META-INF/aop.xml file

Resources

I have not written any specific sample application for this article but if you want you can look at and run the tests in the AspectWerkz distribution. You can download the distribution here. The tests are in ./src/compiler-extensions/spring/src/test directory and you can run them by invoking ant test when standing in the ./src/compiler-extensions/spring directory. However these tests does not use the Java5 annotation syntax but only the XML definition to define the aspects. But you should be able to modify the tests as you like.

The aspectwerkz*.jar jars and the dependency jars are in the ./lib folder in the AspectWerkz distribution, but the aw-ext-*.jar jars you need to build yourself. This is done by stepping into the ./src/compiler-extensions/spring directory and type ant dist then the jar will be put into the ./src/compiler-extensions/spring/lib directory, use same procedure to build the AOP Alliance extension jar.

Enjoy.

Interviewed on javaHispano.org

2004-11-02T00:00:00+00:00

Interviewed on javaHispano.org

I gave an interview for the spanish Java community site javaHispano.org.

Here is the english version.

Spring and AspectWerkz - A Happy Marriage

2004-08-31T00:00:00+00:00

Spring and AspectWerkz – A Happy Marriage

The Spring Framework is a very powerful library for J2EE development. It comes with an AOP implementation (based on proxies) that is in many cases sufficient in terms of what you need to do. However, there are many situations where you need a more full-blown AOP framework (such as AspectWerkz) to do the job.

On the other hand AspectWerkz (even though it has a decent API for configuration and management) could sometimes benefit from more finegrained and expressive configuration and life-cycle management, which is one thing that Spring does very well.

In short, it is sometimes beneficial to use these two frameworks together and I will now show you a first step on how you can make that happen.

AspectWerkz has a very open architecture in regards to instantiation, configuration and management of the aspects. Here I will show you how you can make use of this to take control over your aspects using Spring. (The concepts are the same for PicoContainer, HiveMind or a home-grown IoC implementation.)

In AspectWerkz instantiation, management and configuration of aspects is handled by an “aspect container” and to make it easier for users to provide their own custom implementation it provides the abstract org.codehaus.aspectwerkz.aspect.AbstractAspectContainer
class which handles all the nitty-gritty details.

All we have to do is to extend the org.codehaus.aspectwerkz.aspect.AbstractAspectContainer class and implement the abstract Object createAspect() method.

So let us do that. Here is the implementation of our SpringAspectContainer:

 

public class SpringAspectContainer extends AbstractAspectContainer {
public static final String SPRING_ASPECT_CONTAINER_CONFIG = “spring-bean-config.xml”;
/**

	The Spring bean factory.

     */

    private XmlBeanFactory m_factory = null;

/**

	Creates a new aspect container strategy that uses the Spring framework to manage aspect instantiation and
	configuaration.

     *
	@param crossCuttingInfo the cross-cutting info

     */

    public SpringAspectContainer(final CrossCuttingInfo crossCuttingInfo) {

        super(crossCuttingInfo);

    }

/**

	Creates a new aspect instance.

     *
	@return the new aspect instance

     */

    protected Object createAspect() {

        if (m_factory == null) {

            InputStream is = null;

            try {

                is = ClassLoader.getSystemResourceAsStream(SPRING_ASPECT_CONTAINER_CONFIG);

                m_factory = new XmlBeanFactory(is);

            } finally {

                try {

                    is.close();

                } catch (Throwable e) {

                    throw new WrappedRuntimeException(e);

                }

            }

        }

// here we are letting Spring instantiate the aspect based on its name
// (the m_infoPrototype field is the CrossCuttingInfo instance passed to the base class)
return m_factory.getBean(m_infoPrototype.getAspectDefinition().getName());
}
}

This is all that is needed implementation wise. Now we only have to define which aspects should be managed by our new container and configure the aspect in the Spring bean config file.

To tell the AspectWerkz system that we want to deploy a specific aspect in our custom aspect container we have to specify that in the regular aop.xml file like this:

 
&lt;aspect class="some.package.MyAspect" container="some.other.package.SpringAspectContainer"&gt;
    ...
&lt;/aspect&gt;

For details on the aop.xml file (what it is, how it is used etc.) see the online documentation.

To configure the aspect we just configure it like any other Spring bean class:

 
&lt;?xml version="1.0" encoding="UTF-8"?&gt;

&lt;!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"&gt;

&lt;beans&gt;
    &lt;bean id="some.package.MyAspect"
          class="some.package.MyAspect"
          singleton="false"
          init-method="intialize"&gt;
        &lt;property name="someProperty"&gt;
            ...
        &lt;/property&gt;
        ...
    &lt;/bean&gt;
    ...
&lt;/beans&gt;

For details on how to define your bean classes see the Spring documentation. But here are some explainations:

id – specifies the name of the aspect if a custom name is define you that else use the class name of the aspect (which is the default name). Mandatory.
class – specifies the class name of the aspect. Mandatory.
singleton – specifies if the aspect will be instantiated using the prototype pattern or not. Mandatory.
init-method – the init-method is the method that you are using to initialize the aspect. This method will be called when all the properties have been set. Optional.
property – the metadata that you want to pass to the aspect (see the Spring documentation for details on how how to define properties). Optional.

Spring has great support for passing in expressive metadata. It for example allows you to pass in lists, maps of for example strings, primitives or custom objects, and arrange them pretty much as you like.

Here is a more interesting example on how you can configure an aspect using Spring’s properties. This aspect implements role-based security and is part of the AWare aspect library:

 
&lt;bean id="org.codehaus.aware.security.RoleBasedAccessProtocol"
    class="org.codehaus.aware.security.RoleBasedAccessProtocol"
    singleton="false"
    init-method="intialize"&gt;

    &lt;property name="type"&gt;
        &lt;value&gt;JAAS&lt;/value&gt;
    &lt;/property&gt;

    &lt;property name="roles"&gt;
        &lt;list&gt;
            &lt;value&gt;admin&lt;/value&gt;
            &lt;value&gt;jboner&lt;/value&gt;
        &lt;/list&gt;
    &lt;/property&gt;

    &lt;property name="permissions"&gt;
        &lt;list&gt;
            &lt;bean class="org.codehaus.aware.security.Permission"&gt;
                &lt;property name="role"&gt;
                    &lt;value&gt;jboner&lt;/value&gt;
                &lt;/property&gt;
                &lt;property name="className"&gt;
                    &lt;value&gt;org.codehaus.aware.security.SecurityHandlingTest&lt;/value&gt;
                &lt;/property&gt;
                &lt;property name="methodName"&gt;
                    &lt;value&gt;authorizeMe1&lt;/value&gt;
                &lt;/property&gt;
            &lt;/bean&gt;

           &lt;bean class="org.codehaus.aware.security.Permission"&gt;
                &lt;property name="role"&gt;
                    &lt;value&gt;jboner&lt;/value&gt;
                &lt;/property&gt;
                &lt;property name="className"&gt;
                    &lt;value>org.codehaus.aware.security.SecurityHandlingTest&lt;/value&gt;
                &lt;/property&gt;
                &lt;property name="methodName"&gt;
                    &lt;value&gt;authorizeMe2&lt;/value&gt;
                &lt;/property&gt;
            &lt;/bean&gt;
        &lt;/list&gt;
    &lt;/property&gt;

&lt;/bean&gt;

You can find the code for the SpringAspectContainer along with many other reusable aspects in the AWare library. Which is a community-driven OSS library for reusable aspects for AspectWerkz.

Tutorial series on how to get started with AspectWerkz

2004-06-11T00:00:00+00:00

Tutorial series on how to get started with AspectWerkz

Yesterday evening I put together a series of two introductory tutorials on AspectWerkz (a third is on its way).

Tutorial one: Hello World.

Tutorial two: Hijacking Hello World

I hope that these will help you to get started with AspectWerkz.

Enjoy.

Slides from AOSD presentations

2004-04-05T00:00:00+00:00

Slides from AOSD presentations

Just got back from the AOSD 2004 conference. Great experience. Had fun, attended many great talks, met a lot of interesting people etc.

Here are the links to the talks that I/we gave:

Invited Talk – What are the key issues for commercial AOP use – how does AspectWerkz address them?
AspectWerkz Tutorial – AspectWerkz for Dynamic Aspect-Oriented Programming

BEA sponsors AspectWerkz

2004-03-19T00:00:00+00:00

BEA sponsors AspectWerkz

The AspectWerkz project is since a a month ago sponsored by BEA Systems. Both Alexandre and I, the founders and primary contributors to
AspectWerkz, are full time BEA employees. I work with the JRockit engineering team in Stockholm, and our primary objective is to make AspectWerkz the leading AOP framework for dynamic AOP, and to ensure that the JRockit JVM is far and away the best Java platform for AOP.

We are, of course, working on a number of interesting future directions tight to the in tight coordination with the rest of the BEA products line, but the near term goals are to build deep and unprecedented support for AOP, including real-time run-time weaving into JRockit Java Virtual Machine, and to make AspectWerkz on top of JRockit the number one choice for dynamic AOP in enterprise application environments.

AspectWerkz still is and will remain open source software, licensed under LGPL and will continue being platform and vendor independent.

AspectWerkz NextGen

2004-03-19T00:00:00+00:00

AspectWerkz NextGen

Today we released the 0.10 Release Candidate 1 of AspectWerkz. Which forms the foundation for the next generation of AspectWerkz.

AspectWerkz has gone through a lot of changes, the whole core engine has for example been thrown out and replaced by a much more flexible and performant one. The join point model is much more expressive and orthogonal we have also implemented a JIT compiler that is making AspectWerkz much more performant. On top of that we have a new implementation of true runtime weaving, which allows you to redefine your aspect model including adding new pointcuts at runtime.

Presenting on dynamic AOP @ JavaOne

2004-03-03T00:00:00+00:00

Presenting on dynamic AOP @ JavaOne

I was lucky and our submission to JavaOne was accepted.

This means that Alex and I will do a presentation on “Dynamic Aspect-Oriented Programming in J2EE environments”.

See you there.

Doing a tutorial on AOP in enterprise applications at AOSD 2004

2004-02-18T00:00:00+00:00

Doing a tutorial on AOP in enterprise applications at AOSD 2004

Alex and I will do a half-day tutorial on AspectWerkz at AOSD 2004.

The tutorial will be an introduction to AOP/AOSD and AspectWerkz and to how it can be used in real-world enterprise applications.

It will include hands-on exercises and we will show you how to implement services like:

Role-based security
Declarative transaction demarcation
Transparent persistence
Asynchronous method invocations
Caching
etc.

for regular POJOs (plain old java objects).

You can read more about the tutorial here.

We are looking forward to an interesting conference.

Hope to see you there.

Role-Based Security the AOP way

2003-12-17T00:00:00+00:00

Role-Based Security the AOP way

Since the last example of the new ‘annotation-defined aspects’ model in AspectWerkz seemed to have caused a lot of confusion and made people miss the point, I will in this post try to give a more detailed explaination of the previous ‘Role-Based Security’ example.

First I just want to stress that this new model of defining the aspects will NOT in any sense make the old pure XML based and the doclet based approaches obsolete. We are here simply providing a new option. A ticket out of deployment descriptor hell.

I also would like to mention that this new model is completely user-demand driven. It solely exists due to the fact that there is a high need for it. It basically solves three problems that the users have been complaining about:

Separation of implementation and definition. The implementation and the definition are defined in one single file (in the same bytecode). The aspect definition is thus not separated from the aspect implementation
All advices and introductions needed to implement a concern can be implemented in one single class. The problem with the old approach was that you f.e. for a regular Aspect with two advices and an introduction needed four files. One for each advice and introductions as well as one for the definition. This felt like EJB all over again and the new model addresses this problem in a neat way allowing you to implement everything that is needed in one single class.
Not pure Java. Even though XML is widely used in the J2EE community and intuitive to most users, it is not Java. It suffers from problems with refactoring, maintainance, reusability etc. This new model tries to address this as well. Even thought the current implementation, based on JavaDoc tags, is not pure Java, it is closer to it and it will be pure Java when we have Java 1.5. Which is what this new model is targetting.

So lets get back to the ‘Role-Based Security’ example of ours.

The first thing we do is to implement an abstract aspect that contains all implementation for this concern (the advices). But we leave the definition of the pointcuts (where to apply the advices) for later:

    /**
     * @Aspect perThread
     */
    public abstract class AbstractRoleBasedAccessController extends Aspect {

        protected Subject m_subject = null;

        protected final SecurityManager m_securityManager = ...

        /** To be defined by the concrete aspect. */
        Pointcut authenticationPoints;

        /** To be defined by the concrete aspect. *
        Pointcut authorizationPoints;

        /** 
         * @Around authenticationPoints 
         */
        public Object authenticateUser(JoinPoint joinPoint) throws Throwable {
            if (m_subject == null) {
               // no subject => authentication required
               Context ctx = ... // get the principals and credentials
               m_subject = m_securityManager.authenticate(ctx); // throws an exception if not authenticated
            }
            Object result = Subject.doAsPrivileged(
               m_subject, new PrivilegedExceptionAction() {
                  public Object run() throws Exception {
                     return joinPoint.proceed();
                  };
               }, null
            );
            return result;
        }

        /** 
         * @Around authorizationPoints 
         */
        public Object authorizeUser(JoinPoint joinPoint) throws Throwable {
           MethodJoinPoint jp = (MethodJoinPoint)joinPoint;

           if (m_securityManager.checkPermission(
              m_subject, 
              jp.getTargetClass(), 
              jp.getMethod())) {

              // user is authorized => proceed
              return joinPoint.proceed();
           }
           else {
              throw new SecurityException(...);
           }
        }
    }

This aspect is now completely generic and reusable.

Now we can compile this aspect and package it in a library along with the implementation for the security manager etc. The aspect needs to be compiled with a custom compiler which retrieves the attributes and puts them in into the bytecode of the aspect class. This step will not be needed when we are running java 1.5 which has build in support for metadata annontations.

If we now want to use this security aspect of ours we can inherit the abstract aspect using regular class inheritance and define the pointcuts in the concrete subclass:

    /**
     * @Aspect perThread
     */
    public class RoleBasedAccessController extends AbstractRoleBasedAccessController {

       /**
        * @Execution * *..facade.*.*(..)
        */
       Pointcut authenticationPoints;

       /**
        * @Execution * *..service.*.*(..)
        */
       Pointcut authorizationPoints;
    }

The system needs to know which aspects we want to use and for this we need to write a TINY XML definition file. Here we only need to specify the names of the aspects and NO definition metadata:

    &lt;aspectwerkz&gt;
        &lt;system id="security-test"&gt;
            &lt;package name="example"&gt;
                &lt;use-aspect class="RoleBasedAccessController"&gt;
                    &lt;param name="type" value="JAAS"&gt;
                &lt;/use-aspect&gt;
            &lt;/package&gt;
        &lt;/system&gt;
    &lt;/aspectwerkz&gt;

Here we can see that I have the possibility of parameterizing the aspect. This can be very useful in some situations since it allows you to use the same aspect with different configurations in different contexts

If you think that inheritance adds too much coupling then you have the option of skipping the concrete subclass completely and define the pointcuts in the XML definition instead:

    &lt;aspectwerkz&gt;
        &lt;system id="security-test"&gt;
            &lt;package name="example"&gt;
                &lt;use-aspect class="AbstractRoleBasedAccessController"&gt;
                    &lt;pointcut-def name="authenticationPoints" type="execution" pattern="* *..facade.*.*(..)"/&gt;
                    &lt;pointcut-def name="authorizationPoints" type="execution" pattern="* *..service.*.*(..)"/&gt;
                &lt;/use-aspect&gt;
            &lt;/package&gt;
        &lt;/system&gt;
    &lt;/aspectwerkz&gt;

If you want to play with this new release (which is a release candidate) you can download it here.

Presentation on dynamic AOP in J2EE environments

2003-12-01T00:00:00+00:00

Presentation on dynamic AOP in J2EE environments

On Wednesday (December 3d) I will give a presentation on dynamic Aspect-Oriented Programming in J2EE environments using AspectWerkz at JavaPolis/BeJUG 2003

The presentation will aim at give an understanding on how AOP and AspectWerkz can be used in real-world enterprise applications and will include a couple of hands-on examples.

If you are in Antwerpen, stop by and say hi.

Annotation-defined Aspects

2003-10-27T00:00:00+00:00

Annotation-defined Aspects

The upcoming release of AspectWerkz (0.9) will have support for a new definition model in which the aspects are self-defined. This means that implementation and definition is written in the same self-contained component.

In this new definition model the aspects are regular Java classes and the advices and introductions are regular methods and inner classes in these classes. The aspects can be abstract and inheritance is used and treated like regular Java class inheritance. The meta-data (aspect definition) is defined using runtime attributes and is currently compiled in into the class on bytecode level (not needed in Java 1.5.x and above).

This new approach makes it easy to create reusable self-contained aspect components and libraries. It simplifies both the implementation, maintainance and refactorings since everything is written in one single Java class.

This is an example of a testing aspect defining a virtual mock object mixin that will be introduced (along with its interfaces) on all the classes matching the pattern foo.baz..



/*

	@Aspect perInstance

 */

public class MockObjectAspect extends Aspect {

/**

	@Introduce foo.baz.*

     */

    class MockObject extends MyBase implements Traceable, Metered {

        // implementation of the mock object

    }

}


Here is another example showing a skeleton for an aspect implementing authentication and authorization.



/**

	@Aspect perThread

 */

public class RoleBasedAccess extends Aspect {

private Subject m_subject;
/**

	@Call * ..facade..*(..)

     */

    Pointcut facadeMethods;

/**

	@Execution * ..service..*(..)

     */

    Pointcut needsAuthorization;

/**

	@Before facadeMethods

     */

    public void authenticateUser(JoinPoint joinPoint) throws Throwable {

        Context context = … // get principals and credentials

        boolean granted = SecurityManager.authenticateUser(context) // authenticate the user (f.e. using JAAS)

        if (granted) {

            m_subject = … // set the subject 

        }

        else {

            throw new SecurityException("user not authenticated: " + context);

        }

    }

/**

	@Around needsAuthorization

     */

    public Object authorizeUser(JoinPoint joinPoint) throws Throwable {

        MethodJoinPoint jp = (MethodJoinPoint)joinPoint;

	boolean granted = SecurityManager.checkPermission(m_subject, jp.getTargetClass(), jp.getMethod());

        if (granted) {

            // proceed with normal method invocation

            return joinPoint.proceed();

        }

        else {

            throw new SecurityException("access denied at " + jp.getTargetClass() + “.” + jp.getMethodName());

        }

    }

}

Currently the runtime attributes implementation is based on JavaDoc tags. These are parsed and inserted into the class on bytecode level, so no source files are needed once the classes have been compiled. This is something that will become obsolete when Java 1.5 and the JSR-175 is released, which will bring runtime attributes to the Java language. The extra compilation step needed to annotate the class files will then not be needed. This also means that pure Java refactorings of both implementation and definition in the aspects will be made possible (e.g. tool support).

The new release is scheduled to be released in the middle of end of november.

Stay tuned.

AOP for EJB made easy

2003-08-15T00:00:00+00:00

AOP for EJB made easy

Using the new 0.8 version of AspectWerkz it is now a breeze to instrument your Servlets, EJBs or WebServices at runtime.

In this example I will show how you use AspectWerkz together with WebLogic Server. Please note that AspectWerkz is not in any way tied to WLS, it is a pure generic AOP solution that works equally good inside any application server.

Even though I am fed up with using tracing as a way of demonstrating AOP, this is exactly what I am going to do. This due to simplicity and to be able focus on the important areas. Like, how to get it to work.

So now I will instrument the examplesServer application in WLS which contains all interesting parts in J2EE: SLSB, SFSB, CMP, BMP, MDB, Servlets, WebServices etc.

First I write a simple XML definition file:



<!DOCTYPE aspectwerkz PUBLIC

    “-//AspectWerkz//DTD 0.8//EN”

    “http://aspectwerkz.codehaus.org/dtd/aspectwerkz_0_8.dtd”>
<aspectwerkz id=“samples”>

    <advice-def name=“log” class=“examples.logging.LoggingAdvice” deployment-model=“perJVM”/>
<aspect name=“testWLS”>
<pointcut-def name=“allMethods” type=“method” pattern=“* examples..+.(..)”/>

<bind-advice pointcut=“allMethods”>
<advice-ref name=“log”/>
</bind-advice>
</aspect>
</aspectwerkz>

Here you can see that I define one advice that does the tracing, one pointcut matching all methods in the whole examples application and then I simply ‘bind’ the advice to the pointcut.

So now all I have to do is to start up the application server (in this case WLS) along with AspectWerkz. For this I have many options. First I can post-process my class files before deployment using the aspectwerkz -offline … compiler. Second there are some more interesting ‘online’ alternatives. For all the ‘online’ options see the AspectWerkz documentation.

For simplicity I am using the command line tool bin/aspectwerkz which is a unification of the HotSwap and the Transparent bootclasspath options (see the documention for details). This tool autodetects the version of the JVM I am using and is chosing the best option for me.

So what I have to do is to alter the startup script for WLS a little bit. You have to alter the last part in the script:



“JAVA_HOME\bin\java” JAVA_VM MEM_ARGS JAVA_OPTIONS 

	-Dweblogic.Name=%SERVER_NAME% -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE% 

	-Djava.security.policy=“WL_HOME\server\lib\weblogic.policy” weblogic.Server

So it looks like this:

set ASPECTWERKZ_HOME=C:\src\aspectwerkz
set AW_OPT=-Daspectwerkz.definition.file=C:\bea\weblogic81\mydomain\aspectwerkz.xml

ASPECTWERKZ_HOME\bin\aspectwerkz JAVA_VM MEM_ARGS JAVA_OPTIONS AW_OPT
-Dweblogic.Name=%SERVER_NAME% -Dweblogic.ProductionModeEnabled=%PRODUCTION_MODE%
-Djava.security.policy=“WL_HOME\server\lib\weblogic.policy” weblogic.Server

As you can see here I am simply setting the ASPECTWERKZ_HOME, passing the definition file to the JVM using the -Daspectwerkz.definition.file JVM option and then replacing the regular call to %JAVA_HOME%\bin\java with the call to %ASPECTWERKZ_HOME%\bin\aspectwerkz.

So now all we have to do is to start up the server and run the examples.
Running, for example, the CMP example produces the folllowing output (as you can see AspectWerkz has no problem with the ejbc generated stubs):



…

→ examples.ejb20.basic.containerManaged.containerManaged_9ufdc1_HomeImpl_WLSkel::invoke

  —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1_HomeImpl::create

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_initialize

      —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_initialize

        —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::__WL_initialize_persistent

        < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_initialize_persistent

      <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_initialize

    <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_initialize

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::setEntityContext

      → examples.ejb20.basic.containerManaged.AccountBean::setEntityContext

        —> examples.ejb20.basic.containerManaged.AccountBean::id

        < - examples.ejb20.basic.containerManaged.AccountBean::id

        → examples.ejb20.basic.containerManaged.AccountBean::log

setEntityContext called (12773520, PK = nullctx)

        < - examples.ejb20.basic.containerManaged.AccountBean::log

      <— examples.ejb20.basic.containerManaged.AccountBean::setEntityContext

    <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::setEntityContext

    → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::__WL_setEJBContext

    < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_setEJBContext

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setup

    < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setup

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setBusy

    < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setBusy

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::ejbCreate

      → examples.ejb20.basic.containerManaged.AccountBean::ejbCreate

        —> examples.ejb20.basic.containerManaged.AccountBean::log

AccountBean.ejbCreate( id = 12773520, PK = 10020, initial balance = $ 3000.0)

        < - examples.ejb20.basic.containerManaged.AccountBean::log

        → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::setAccountId

        < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::setAccountId

        → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::setBalance

        < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::setBalance

        → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::setAccountType

        < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::setAccountType

      <— examples.ejb20.basic.containerManaged.AccountBean::ejbCreate

      → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::pkCheck

      < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::pkCheck

      → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::__WL_getPrimaryKey

      < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_getPrimaryKey

    <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::ejbCreate

    → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::__WL_getEJBContext

    < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_getEJBContext

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setLoadUser

    < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setLoadUser

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::ejbPostCreate

      → examples.ejb20.basic.containerManaged.AccountBean::ejbPostCreate

        —> examples.ejb20.basic.containerManaged.AccountBean::id

          —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::__WL_getMethodState

          < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_getMethodState

          —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_getMethodState

          < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_getMethodState

        <— examples.ejb20.basic.containerManaged.AccountBean::id

        → examples.ejb20.basic.containerManaged.AccountBean::log

AccountBean.ejbPostCreate (12773520, PK = 10020)

        < - examples.ejb20.basic.containerManaged.AccountBean::log

      <— examples.ejb20.basic.containerManaged.AccountBean::ejbPostCreate

      —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_create

        —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setBeanParamsForCreateArray

        < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setBeanParamsForCreateArray

      <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_create

    <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::ejbPostCreate

    → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::__WL_setBusy

    < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_setBusy

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::ejbStore

      → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_store

        —> examples.ejb20.basic.containerManaged.AccountBean::ejbStore

          —> examples.ejb20.basic.containerManaged.AccountBean::id

            —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::__WL_getMethodState

            < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_getMethodState

            —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_getMethodState

            < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_getMethodState

          <— examples.ejb20.basic.containerManaged.AccountBean::id

          → examples.ejb20.basic.containerManaged.AccountBean::log

AccountBean.ejbStore (12773520, PK = 10020)

          < - examples.ejb20.basic.containerManaged.AccountBean::log

        <— examples.ejb20.basic.containerManaged.AccountBean::ejbStore

        —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_getMethodState

        < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_getMethodState

      <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_store

    <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::ejbStore

    → examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::__WL_isBusy

    < - examples.ejb20.basic.containerManaged.containerManaged_9ufdc1__WebLogic_CMP_RDBMS::WL_isBusy

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setLoadUser

    < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_setLoadUser

    —> examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::WL_isCreatorOfTx

    < — examples.ejb20.basic.containerManaged.containerManaged_9ufdc1WebLogic_CMP_RDBMS::__WL_isCreatorOfTx

  <— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1_HomeImpl::create

<— examples.ejb20.basic.containerManaged.containerManaged_9ufdc1_HomeImpl_WLSkel::invoke

…

You can find the AspectWerkz 0.8 distribution here.

AspectWerkz makes AOP seamless

2003-08-13T00:00:00+00:00

AspectWerkz makes AOP seamless

Today me and Alex released the 0.8 version of AspectWerkz.

This new release have been tested and verified to work for servlets and all types of EJBs under WebLogic Server 7 and 8.1 using both online and offline mode.

JMangler has been thrown out for a completely new and customized solution that apart from solving some of the shortcomings and bugs in JMangler also provides completely new and interesting possibilities. Here are the options currently supported for online mode:

HotSwap
A first JVM launchs your target application in a second JVM. The first JVM hooks AspectWerkz in the second one just before the main class (and all dependencies) gets loaded, and then connects to the stdout / stderr / stdin stream ot the second JVM to make them appear as usual thru the first JVM.
Transparent bootclasspath
For JVM or java version like 1.3 which don’t support class replacement at runtime (HotSwap), this option allows for same mechanism by putting an enhanced class loader in the target application VM bootclasspath.
Native HotSwap
A native C JVM extension running in the target application VM handles the replacement of the class loader by the enhanced one.
Remote HotSwap
The application VM is launched suspended. The replacement of the enhanced class loader is done thru a separate manual process, which can easily be scripted.
Prepared bootclasspath
The enhanced class loader is builded and packaged as a jar file in a first separate manual process, which can easily be scripted. The application VM is launched with options to use this enhanced class loader.
Auto detection of java 1.3 and java 1.4

Some of the other new features are:

JDK 1.3 compatibility.
Runtime attributes → XML compiler (no more metaData dir and meta-data compilers needed, one aspectwerkz.xml per application).
Offline compiler refactored. Now support rollback on error facility.
Released under a BSD-style license.
Non-reentrancy option for join points.
Definition validator.
Documentation updated and reorganized.

The new release can be downloaded from here.

A more detailed paper describing the new online architecture can be downloaded from here

JMangler changes its license back to LGPL

2003-06-30T00:00:00+00:00

JMangler changes its license back to LGPL

JMangler will change its license back to LGPL (for some reason they changed to GPL for the 3.x release).

The change to GPL did of course cause a lot of problems for AspectWerkz (which is licensed under LGPL and uses JMangler) and I have since then tried to persuade the JMangler team to change its license back to LGPL.

Yesterday I recieved this letter from Michael Austermann, the creator of JMangler:

Hi Jonas,

I’ve been to canda for the last weeks and was unable to read/reply any
emails. We will change the the licence of JMangler back to LGPL within the
next one or two weeks.

Michael

So for all of you who have hesitated in using AspectWerkz in a commercial application: go for it, you will love it. :-)

AspectWerkz ruthlessly refactored

2003-06-20T00:00:00+00:00

AspectWerkz ruthlessly refactored

After two weeks of Ruthless Refactoring™ I can now announce that AspectWerkz version 0.6.3 has been released.

I have among other things rewritten the whole definition and weave model implementation to support a much more powerful join point model. The join point model now have the essence of the AspectJ model.

Here are some of the features/changes:

Completely new definition model. Aspects, advices,
introductions and pointcuts are now completely orthogonal
and the model now has the essence of the AspectJ model.
See the documentation for details.
Abstract aspects definitions as well as pointcut expressions (e.g. ((pc1 OR pc2) AND !pc3) and similar).
Multiple weave models.
Multiple AspectWerkz system can run in the same JVM concurrently.
setField and getField now works for get and set java.util.* collection fields (e.g. add/get/remove/size and so on).
Advice and introduction container is now pluggable. I.e. the user can provide its own custom implementation (f.e. to enable persistence).
The transparent persistence of advices and introductions have been moved to the sandbox.
Many bug fixes.

Here is an example of the new definition:



<aspectwerkz>

    <!— ========= ->

    <!-  Define the advices                           ->

    <!- ========= —>

    <advice-def name=“log”

                advice=“advices.LoggingAdvice”

                deployment-model=“perInstance”/>
<advice-def name=“cache”
advice=“advices.CachingAdvice”
deployment-model=“perClass”/>
<advice-def name=“persistent”
advice=“advices.PersistenceAdvice”
deployment-model=“perJVM”/>
<advices-def name=“log_and_cache”>
<advice-ref name=“log”/>
<advice-ref name=“cache”/>
</advices-def>
<!— ========= —>
<!—  Define the introductions                     —>
<!— ========= —>
<introduction-def name=“serializable”
interface=“java.io.Serializable”/>
<introduction-def name=“mixin”
interface=“mixins.Mixin”
implementation=“mixins.MixinImpl”
deployment-model=“perInstance”/>
<!— ========= —>
<!—  Define the abstract aspects                  —>
<!— ========= —>
<abstract-aspect name=“MyAbstractAspect”>
<advice pointcut=“setters AND !getters”>
<advices-ref name=“log_and_cache”/>
</advice>
<advice pointcut=“persistentFields”>
<advice-ref name=“persistent”/>
</advice>
</aspect>
<!— ========= —>
<!—  Define the aspects                           —>
<!— ========= —>
<aspect name=“MyAspect” extends=“MyAbstractAspect”>
<introduction class=“domain.*”>
<introduction-ref name=“serializable”/>
<introduction-ref name=“mixin”/>
</introduction>
<pointcut-def name=“setters” type=“method” pattern=“String domain..set(..)”/>
<pointcut-def name=“getters” type=“method” pattern=“String domain..get(..)”/>
<pointcut-def name=“persistentFields” type=“setField” pattern=“* domain..”>
</aspect>
</aspectwerkz>

You can download the new release from the releases page

Enjoy.

JBoss AOP is lacking a decent join point model

2003-06-18T00:00:00+00:00

JBoss AOP is lacking a decent join point model

There has been a lot of talk about the JBoss AOP implementation (and its lack of performance) lately.

When looking at it you can see (as Rickard and many others already have pointed out) that it has soo many major flaws that it is impossible for it to perform anything but bad.

Apart from this, one of the things that first hit me was that the implementation is completely lacking a decent join point model (meaning some sort of “language” in which you can define which methods/fields etc. should be advised). They are simply advising everything and are then (at runtime) making the desicions if an advice should be invoked or not. This is really amazing, since the key to a good AOP framework lies in how expressive and rich the join point model is. Those that have used AOP for some time will agree on that it is not enough to pick out join points on class level only:



 <!— from the JBoss tutorial —>

 <interceptor-pointcut class=“com.acme.POJO.*”>

       <interceptors>

         <interceptor factory=“jboss.security.SecurityFactory”/>

         <interceptor-ref name=“Logging”/>

       </interceptors>

   </interceptor-pointcut>

but there is a need for a much more finegrained selection mechanism, or you will run into a scaling wall pretty quick.

In my world I would like to (at least) be able to pick out join points based on:

class pattern
method pattern, including return type and parameter types
field pattern, including field type
a mechanism to combine these patterns in an expression (e.g. ((pc1 || pc2) && pc3) and similar)

(Of course AspectWerkz supports all of these.)

I could not resist to implement and run the same performance tests that
Rickard
did for JBoss AOP. Here are the results using AspectWerkz (running on my Pentium 4 2.54 Mhz box):

overhead for non-advised method: 0.0 ms/call (since non-advised calls are not advised)
overhead for advised method but no advice (advice removed): 0.0003 ms/call
invoking a method with one advice that does nothing: 0.0005 ms/call
invoking a method with a chain of ten advices that does nothing: 0.0024 ms/call
overhead for a call to an introduced method: 0.0004 ms/call

AspectWerkz has moved to codehaus.org

2003-05-13T00:00:00+00:00

AspectWerkz has moved to codehaus.org

The move to codehaus.org is now completed.

The new URL is
aspectwerkz.codehaus.org.

AspectWerkz 0.5 has been released

2003-05-12T00:00:00+00:00

AspectWerkz 0.5 has been released

The AspectWerkz 0.5 release is a huge improvement compared to previous versions. Apart from many bug fixes it is also packed with new features.

You can download the new release from the releases page.

New features:

Caller side pointcuts. I.e. the possibility to advise a
method invocation (caller side) apart from method
execution (callee side).
Fine-grained pattern language for picking out pointcuts. It is now possible to pick out method pointcuts by method name, parameter types and return type as well as field pointcuts by field name and field type. All these support regular expressions.
Runtime attributes for advices (method/field/throws). I.e. add meta-data to your methods/field/classes as JavaDoc tags which are picked up by the weaver and used as rule set when doing the transformations.
Class selectors for aspects. I.e. pick out classes using regular expressions.
Advising of static fields.
Parameters to advices. The possibility to pass parameters to advices through the XML definition.
Advice stacks. The possibility to define stacks/chains of advices that can be reused throughout the XML definition.
MethodAdvice has been renamed to AroundAdvice and the FieldAdvices has been renamed to PreAdvice and PostAdvice.
Creation and registration of new advices at runtime (in previous releases you could only add/remove/reorder existing advices).
Ant task for offline post-processing.
More flexible startup and definition handling process.
Multiple pattern declarations for pointcuts.
More documentation and examples.
Many many bugfixes.

Cedric's AOP challange: a solution using caller pointcuts and decoupled advices.

2003-05-10T00:00:00+00:00

Cedric’s AOP challange: a solution using caller pointcuts and decoupled advices.

Last night I implemented caller pointcuts for AspectWerkz. I just had to, since they have been haunting me since I read Cedric’s little AOP challange.

So for what it is worth, here is my way of implementing Cedric’s caching problem using AspectWerkz and caller pointcuts.

I’ll start with the cache advice. The CachingAdvicew caches the result and if the cache is used it reports it to the CacheStatistics instance:

public class CachingAdvice extends MethodAdvice {

    protected Map m_cache = new StaticBucketMap(1000);

    public CachingAdvice() {
        super();
    }

    public Object execute(final JoinPoint joinPoint) 
        throws Throwable {
        MethodJoinPoint jp = (MethodJoinPoint)joinPoint;

        final Long hash = new Long(calculateHash(jp));
        final Object cachedResult = m_cache.get(hash);

        if (cachedResult != null) { 
            System.out.println("using cache");
            CacheStatistics.addCacheInvocation(
                jp.getMethodName(), jp.getParameterTypes());
            return cachedResult;
        }

        final Object result = joinPoint.proceed();

        m_cache.put(hash, result);
        return result;
    }

    private long calculateHash(final MethodJoinPoint jp) {
        int result = 17;
        result = 37 * result + jp.getMethodName().hashCode();
        Object[] parameters = jp.getParameters();
        for (int i = 0, j = parameters.length; i < j; i++) {
            result = 37 * result + parameters[i].hashCode();
        }
        return result;
    }
}

The second advice I had to implement was the InvocationCounterAdvice. This advice will be applied on the caller side of the method invocation and simply reports the each invocation to the CacheStatistics instance:



public class InvocationCounterAdvice extends PreAdvice {
public InvocationCounterAdvice() {
super();
}
public void execute(final JoinPoint joinPoint)
throws Throwable {
CallSideJoinPoint jp = (CallSideJoinPoint)joinPoint;
CacheStatistics.addMethodInvocation(
jp.getMethodName(), jp.getParameterTypes());
joinPoint.proceed();
}
}

The next step was to define these advices and define where they should be applied:

&lt;advice name="caching"
    class="examples.caching.CachingAdvice"
    deploymentModel="perInstance"/&gt;

&lt;advice name="invocationCounter"
    class="examples.caching.InvocationCounterAdvice"
    deploymentModel="perInstance"/&gt;

&lt;aspect class="examples.caching.Pi"&gt;
    &lt;pointcut type="method" pattern="getPiDecimal"&gt;
        &lt;advice-ref name="caching"/&gt;
    &lt;/pointcut&gt;
&lt;/aspect&gt;

&lt;aspect class=".*"&gt;
    &lt;pointcut type="callSide" pattern="examples.caching.Pi#getPiDecimal"&gt;
        &lt;advice-ref name="invocationCounter"/&gt;
    &lt;/pointcut&gt;
&lt;/aspect&gt;

In this file I first defined the advices by giving them a name, specifying the class and the deployment model (scope). The second thing was to define the aspects and the pointcuts. By setting an aspect’s class attribute to “.*” I am telling the system to apply its pointcuts to all classes. The pointcuts are defined by specifying the type (method/field/callSide etc.), the pattern (which methods should be advised) and last but not least the references to the advices that should be applied to these poincuts. The call side pointcut’s pattern consists of the target class and the target method concatenated by a “#”. (I don’t know if this is the best syntax to describe this, but it works for now.)

Last I had to implement the CacheStatistics class (code not shown here) and a client class:

public class CacheTest {
    public static void main(String[] args) {

        Pi.getPiDecimal(3);
        Pi.getPiDecimal(4);
        Pi.getPiDecimal(3);

        int methodInvocations = CacheStatistics.
            getNrOfMethodInvocationsFor(
                "getPiDecimal", new Class[]{int.class});
        int cacheInvocations = CacheStatistics.
            getNrOfCacheInvocationsFor(
                "getPiDecimal", new Class[]{int.class});

        double hitRate = methodInvocations / cacheInvocations;
        System.out.println("Hit rate: " + hitRate );
    }
}

When running the client class it produces the following output:



using method

using method

using cache

Hit rate: 3.0

The complete example can be checked out along with the aspectwerkz distribution from the AspectWerkz’s CVS repository (please note that this feature is still very much in development). You can run the example using Maven by executing: maven aspectwerkz:samples:caching

AOP standardization process started

2003-05-10T00:00:00+00:00

AOP standardization process started

Renaud Pawlak, the creator of JAC has started up a project called AOPI, which has the goal of specifying a common set of components for aspect-oriented systems.

From the homepage:

AOPI are a standard specification of a set of useful or mandatory componants for aspect-oriented systems.

The idea is to have a common set of abstract components specifications, distributed under a Public Domain licence, that will help all the projets to communicate and reuse components coming from other projects.

This is a really good idea an I’m looking forward to some interesting discussions on the mailinglist. :-)

AOP in practice: Transparent persistence for POJOs

2003-05-10T00:00:00+00:00

AOP in practice: Transparent persistence for POJOs

Using the new techniques of AOP and the
AspectWerkz framework there is actually
pretty easy to implement transparent persistence for Plain Old Java Objects (POJOs).

This example has been implemented using JISP
as persistence engine and can be checked out along with the
AspectWerkz
distribution from the CVS.
(Please note that the
documentation
is not all up to date).

First we have to write a PostAdvice similar to this one:

public final class DirtyFieldCheckAdvice extends PostAdvice {

    public DirtyFieldCheckAdvice() {
        super();
    }

    // is being executed when a field has become dirty
    public void execute(final JoinPoint joinPoint) {
        FieldJoinPoint jp = (FieldJoinPoint)joinPoint;
        try {
            PersistenceManager.store(jp.getTargetObject());
        } catch (PersistenceManagerException e) {
            throw new WrappedRuntimeException(e);
        }
    }
}

So, what did we just do? Well, we created a field advice that extended the
PostAdvice class. The PostAdvice abstract base
class guarantees that the void execute(final JoinPoint joinPoint)
will be executed after that a field has been set (modified).

The second step is to tell the
AspectWerkz
system which fields we want to monitor. This is specified in the XML definition file:

&lt;aspectwerkz>

    &lt;introduction name="persistable"
        interface="aspectwerkz.extension.persistence.Persistable"/&gt;

    &lt;advice name="makePersistent"
        class="aspectwerkz.extension.persistence.DirtyFieldCheckAdvice"
        deploymentModel="perJVM"/&gt;

    &lt;aspect class="domain.*"&gt;
        &lt;introduction-ref name="persistable"/&gt;
        &lt;pointcut type="setField" pattern=".*"&gt;
            &lt;advice-ref name="makePersistent"/&gt;
        &lt;/pointcut&gt;
    &lt;/aspect&gt;


&lt;/aspectwerkz&gt;

In this file we first define an
Introduction
for the “marker interface”
aspectwerkz.extension.persistence.Persistable (that will be used by the
persistence engine to select which objects that should be treated as persistent and
which should be treated as transient).

Next we define our
Advice
by giving it a name, mapping it to the full
class name of the advice and specifying the
deploymentModel,
(which can be seen as the “scope” for the advice). There are four different
deployment models available:

perJVM – one sole instance per Java Virtual
Machince. Basically the same thing as a singleton class.
perClass – one instance per class.
perInstance – one instance per class instance.
perThread – one instance per thread.

Then we have to specify where to apply the Introduction, i.e.
which objects we want to mark as persistable and which fields we want to monitor
using our Advice.

This is done by by defining an
Aspect
with a pattern matching the classes we want to make persistable.
In this Aspect we added a reference to our Introduction (which tells the system that it should apply this Introduction to all classes matching the pattern for the Aspect)
and defined a Pointcut for the fields we are interested in (in this case all fields in all classes matching the pattern).

The Pointcut
is defined by specifying the type of the Advice (in this
case setField since we want to know when a field has been modified), the pattern for the fields we want the monitor (as a regular expression) and last but not least a reference to to the Advices we want to apply to this Pointcut.

The only thing that is left for getting the whole thing to work is to implement the persistence manager class. This example is based on
JISP but the implementation is made pluggable so it would be a simple task to add support for RDBMS, JDO or whatever.

If you choose to check out the example, you can run it using
Maven by executing
maven aspectwerkz:samples:transparentpersistence.