This new platform represents my vision for software development from years ago. I have taken a few side tracks along the way. Previously I felt that I would be better off trying to contribute my vision to heavily funded efforts that have multiple teams, those that would easily out perform me alone. That was a big risk for me to take. Still, I was true to my choice, and I contributed heavily to the extent that the way was open to me. While I am grateful for the opportunities that this provided, ultimately I failed to meet my vision in various ways. Sometimes I wonder if I guided too gently.
Still, I see what I see, and I need to say what I need to say. By doing so I won’t sit years from now wondering whether I could have made a difference in how software platforms are designed, developed, and used.
What Is XOOM?
As I stated, some years ago I began an effort that was the formulation of my vision. Of course this vision involves Domain-Driven Design (DDD). I want the use of DDD to continue to increase. Note that DDD can be expressed in different ways, including as object models and as functional models. Expect that XOOM will support both.
Given that my pivot point is DDD, you probably understand the “lingo” part of the name. Using DDD means that you and your team are developing a language, a Ubiquitous Language. So, underlying everything in XOOM is in support of expressing the Ubiquitous Languages of your Bounded Contexts in software models. Still, ultimately XOOM is a fun name, at least in English, and the name was available on the io top-level domain 🙂
It’s been popular to say that there is no possibility of a DDD framework or platform. Why bother swimming against the tide of popular DDD opinion? Note that XOOM supports many of the ways that DDD is contemporarily expressed, but I don’t consider XOOM to be a DDD framework, necessarily. Since every Bounded Context with its Ubiquitous Language is different, how would you create a framework that supports it?
Well, XOOM makes using contemporary DDD tools, as well as the surrounding architectures and patterns, vastly easier to deliver successfully. Over the years I have been told many times that if I were to produce a “DDD framework” that it would be heavily used; their teams need implementation guidance. I kept saying “no.” Yet, now I am providing XOOM to make the DDD approach easier to deliver with success. Is it a DDD framework? Not really, but that is an opinion that is yours to form. If it makes it easier to get you started using DDD, and delivery successfully, I really don’t care what you call it.
Our initial release of the XOOM/PLATFORM showcases its foundation, XOOM/ACTORS.
XOOM/ACTORS
I have been focused on working with the Actor Model of computation for a considerable time now. In the year 1973, Dr. Carl Hewitt and his colleagues formulated the Actor Model. In recent years, the inventor of object orientation, Alan Kay, has stated that the Actor Model retained more of what he thought were the important object ideas. So, when you think of the Actor Model, think of objects done right.
The XOOM/ACTORS toolkit is an implementation of the Actor Model. The ideas behind the Actor Model are pretty simple, and these points show how XOOM/ACTORS implement it.
- The basic unit of computation is expressed through actors. Actors are basically objects, but their behaviors are requested by sending/receiving messages asynchronously rather than through directly invoking their methods. This enables all communication between actors to be performed through asynchronous messaging passing.
- Actors can create other actors. As Carl Hewitt is known to say, “One actor is no actors. Actors come in systems.” Thus, your applications should use not just some actors, but many actors. Understand that once you start down the road of asynchronous behaviors, you are all in. You know, you don’t kind of go swimming.
- Each actor can designate the behavior it will exhibit for the next message it receives. This is roughly the State pattern. What is most unique about the XOOM/ACTORS implementation is type safety, and the simplicity. All that a programmer needs to understand is interfaces and implementation classes, and they get the asynchrony for free.
- Most other actor implementations use a receive method or code block that takes Object (or Any) as a parameter. Thus, the receive needs to determine which messages to accept and which ones are not permitted; this may be especially necessary when the actor designates its next behavior. Also what is unique about XOOM/ACTORS is that the current designated behavior can be based on a different interface that is implemented by the actor. In other words, any one actor can implement multiple interfaces and receive messages for any given interface when it chooses to.
- Most modern actor model implementations use mailboxes to deliver messages. Each actor has a mailbox where messages are received into a FIFO queue, and each message is processed one at a time on an available thread.
- You can tune your actor’s world and stage to support any number of threads, but it’s best to limit this number according to the available number of processor hyper-threaded cores, or a bit more. Fundamentally, you can’t run more threads simultaneously than there are available cores, e.g. Runtime.getRuntime().availableProcessors()
Using objects in a typical fashion, such as with Java or C#, we have become accustomed, even addicted, to a blocking paradigm.
Here a Client object invokes a method on a Server object. Understand that this is an in-process (in-VM) invocation, not a remote client and a remote server. The point is, when a method invocation occurs, the Client is blocked until the Server returns from the method invocation. In contrast, the Actor Model works differently.
When the Sender actor wants another actor to provide a service, it sends that actor a message. The message is sent to the Receiver actor and handled asynchronously, but not until a thread is available. The Sender continues moving forward with its current activities, and when completed returns from its own message handling.
As I previously stated, with various Actor Model implementations, messages are not always required to be strongly typed. Yet, with XOOM/ACTORS type-safe messages are the fundamental building block, not an experimental afterthought. This is why I think that a strongly-typed Actor Model implementation is important at this time.
- Actor uptake is slow because most implementations are available in languages that are not being widely used: Scala, Erlang, Elixir. Currently Scala has been most successful, but it may be in decline. Some of the greatest proponents of the Scala language seem to have shifted focus more toward the Java platform and much less on the Scala language.
- It’s difficult to get contributors when the language is not mainstream, nor one of the most popular mainstream languages.
- Given all its downsides, Java is here to stay.
- The Java community wants to use actors as close to POJO as possible. Using XOOM/ACTORS makes using the Actor Model very natural to Java programmers.
The XOOM/ACTORS project is really the bedrock on which other tools are implemented. The next tool that is ready for release is XOOM/CLUSTER, which is a level up in the platform. It will be available within a few days of the writing of this blog post.
There is way too much complexity in the industry. The overarching vision for the XOOM/PLATFORM puts extreme emphasis on simplicity. With the XOOM/PLATFORM you should be able to download it and have the whole platform running in five minutes or less, fully configured for common use cases. You should be productive within minutes, not an untold number of weeks or months. Even so, you may never program directly against XOOM/ACTORS unless you are a platform contributing developer.
If you would like to try out the XOOM/PLATFORM, you can find it here: http://github.com/vlingo
There is so much more on the way. I hope you are as excited about the prospects as I am!
