On Software Architecture, Programming Languages, Engineering Management, and Systems Thinking

Not All Commands Are Equal (And Neither Are Events)

2024-11-30T00:00:00+00:00

Usually, in an event-driven architecture, events are emitted by one service and listened to by many (1:n). But what if it’s the other way around? If one service needs to listen to events from many other services?

When we talk about communication between services, we distinguish between commands, queries and events.
For events and queries, let’s say we agree on these attributes:

Queries, Events
Type	Event	Query
Describes..	An event that has happened in the past	A request for information about the current state of one or many objects
Expected Response	None	The requested information
Communication Pattern	Fire-and-Forget	Request-Response

I don’t expect controversy here. For a query, you want a response. And on the other hand it’s well established that events describe facts. And that events are emitted, with no knowledge required what’s listening to the event and reacting to it. And certainly no response is expected.

But what about commands?

Commands
Type	Command
Describes..	An intention to perform an operation or change a state
Expected Response	???
Communication Pattern	???

Let’s agree that a command expresses intent, it’s a request to do something. An example could be a request to cancel an order (trigger e.g. by a request from a user). This can fail, in multiple ways: The referenced order might not exist, it might be already fulfilled and no longer cancelable, or the user might not be authorized to cancel it. That’s why a command typically yields a response: An acknowledgment that is has been executed successfully, or an error message. Consequently, the communication pattern is request-response. The caller will need the response to decide on the next action.

This is the kind of command I usually mean when I talk about commands (which I do a lot, even publicly). But while doing so, I learned that a lot of people disagree with the association command = request - response. So let’s differentiate, and call commands that expect a response “ask commands”.

"Ask" - Commands
Type	"Ask" - Command
Describes..	An intention to perform an operation or change a state
Expected Response	A confirmation that the command has been executed, or an error message
Communication Pattern	Request-Response

Again, this used to be the only type of command I cared about, so that’s how I defined it e.g. here.

It has been brought to my attention though, that there are cases were there’s no interest in the response. Possible scenarios are:

The sender doesn’t care if the command is successfully executed or not, or
the receiver guarantees that the command will be handled, and it will take care of any error handling itself, or
executing the command will result in an event that indicates how the command processing went, that can be listened to by anyone interested.

An example for a command that doesn’t yield a response could be sending notifications. Imagine you have many subdomains that emit events that users are interested in, and should be informed via some sort of message (text message, e-mail,..). Using events from the originating domains, the notification service would need to understand a large number of different event types and make sense of them. Any additional service that also triggers user messages will require an extension of the notification service as well.
To avoid this, just one command type could be defined. Although the processing could fail, the sender would never be interested in this. The notification service itself would take care of any error handling, this would not go back to the originating domain.

So instead of asking another service to do something (which it can reject), we are telling another service “take care of this, you handle it, I don’t want to hear about it again”.

Let’s call this type of commands “tell commands”:

"Tell" - Commands
Type	"Tell" - Command
Describes..	An intention to perform an operation or change a state
Expected Response	None
Communication Pattern	Fire-and-Forget

An Extended View of Commands

Let’s review what we talked about so far:

Events and Commands with extended criteria
Type	Event	"Tell" - Command	"Ask" - Command
Describes..	An event that has happened in the past	An intention to perform an operation or change a state	An intention to perform an operation or change a state
Expected Response	None	None	A confirmation that the command has been executed, or an error message
Communication Pattern	Fire-and-Forget	Fire-and-Forget	Request-Response

So in terms of the overall flow, in terms of the structure of communication, “tell” has more in common with events than with an “ask”.
To solely rely on the naming to separate them is questionable. It’s easy to take “asks”, expect a response, but just name both requests and responses like events - this is what Martin Fowler calls “using events as passive-aggressive commands”. Just like those events should really be commands, maybe “tell” commands should really be events?

People who use and like “tell” commands will suggest other categories for distinction:

1:n vs. n:1
Suggested criterion: Events have one sender, and any number of receivers. Commands have one receiver, and any number of senders.

Model ownership
Suggested criterion: The schema of an event is defined by the sending service, the schema of a command by the receiving service.

We can extend our table to incorporate these criteria, if we want to show that “tell” commands and events are not the same:

Events and Commands with extended criteria
Type	Event	"Tell" - Command	"Ask" - Command
Describes..	An event that has happened in the past	An intention to perform an operation or change a state	An intention to perform an operation or change a state
Sender:Receiver	1:n	n:1	n:1
Schema Owner	Sender	Receiver	Receiver
Expected Response	None	None	A confirmation that the command has been executed, or an error message
Communication Pattern	Fire-and-Forget	Fire-and-Forget	Request-Response

But - who says that for events always have to have the schema defined by the sender, and sender/receiver is 1:n? Let’s explore further.

Events vs. Tell-Commands - different approaches compared

Let’s come back to our notification example. A possible approach would be for the notification service to listen to events from domain services and make sense of all of them:

The notification service needs to understand all sorts of events.

This is nice and event-driven. But as mentioned above, this requires the notification service to be aware of all sorts of domain events and handle them, and to be extended if more are added.
To avoid this, let’s consider “tell” commands as an alternative:

The notification service understands commands.

You could argue (as I tend to do) that these are not “real” commands, because they are treated like events, i.e. there is no way of indicating success or failure to the sender (i.e. if you consider “ask” commands to be the real commands). And moving from “tell” commands to events is just a change of perspective. The problem caused by the domain events, that the notification service needs to understand all event types, can be remedied by introducing a new, shared schema that all notification events need to implement, so they all adhere to a given interface required by the recipient.

The notification service understands one type of events.

Given we divided commands into two sub-categories, it’s only fair to do the same to events as well. Let’s call our original events, where the schema is owned by the source, “supplier events”. The other kind, where the events conform to a schema provided from the outside, would then be “conformist events”. So the final version of our comparison table is this:

Events and Commands with extended criteria
Type	"Supplier" - Event	"Conformist" - Event	"Tell" - Command	"Ask" - Command
Describes..	An event that has happened in the past	An event that has happened in the past	An intention to perform an operation or change a state	An intention to perform an operation or change a state
Sender:Receiver	1:n	n:1	n:1	n:1
Schema Owner	Sender	Receiver	Receiver	Receiver
Expected Response	None	None	None	A confirmation that the command has been executed, or an error message
Communication Pattern	Fire-and-Forget	Fire-and-Forget	Fire-and-Forget	Request-Response

So what to use?

Commands, Events — while you’d think the boundaries are clear, the classification is quite coarse-grained. E.g. using commands can lead to quite different outcomes, depending on if they require a reponse or not.

So in the n:1 case, if one service needs to listen to events from many other services, what should we use? For commands an n:1 relationship is the common case. And we saw above that you can have commands without responses, giving you many of the advantages events have. So should you prefer “tell” commands or “conformist” events?

My personal preference is on conformist events. To me only “ask” commands are really commands, and “tell” commands are just events in a confusing disguise. I don’t think the schema ownership or sender/receiver ratio should force you to think in commands instead of events. I want my systems to be event-driven, want to reason about things that happened, use event storming to figure out what to do.

But I’m still learning (and hopefully always will be). Until recently, tell commands weren’t even on my radar. So I’m looking forward to learning more about the readers’ approaches, and to writing further blog posts sharing new insights in the future.

P.S. I help companies adopt event-driven architecture, from getting message semantics right — knowing when to use events, tell commands, or ask commands — to designing clear contract and schema ownership boundaries between services. Whether you’re working through these design decisions for the first time or refining an existing system, I offer architecture consulting and training on exactly these topics. Feel free to get in touch.

The Dual Nature of Events in Event-Driven Architecture

2024-10-31T00:00:00+00:00

Given that events play such a central role in event-driven architecture, there’s an astonishing lack of agreement on what should be contained in an event. This may be rooted in the fact that, depending on your perspective, events fulfill different purposes.

In a system that follows event-driven architecture in its contemporary style, microservices collaborate by emitting and subscribing to events.
(Please note this article only talks about events that are “published” from one domain for others to subscribe to. Not about internal events that are used for example if your approach to persistence is event sourcing.)

In these event-driven systems, events that travel between services have a dual role: They trigger actions and carry data.

In principle events emitted from a service can be anywhere on the spectrum shown in the picture below.

Events are usually both trigger and carrier of data - varying in the amount of data included.

The left end would be “pure trigger”, where all the information is contained in the event type alone. On the right end of the spectrum, all properties of the changed entity/aggregate would be included in the event.

By the way, not only is there no consensus on how much data should usually be included in an event - it’s not even clear what to call the data-heavy events on the right end of the spectrum. Having been taught this term by a colleague of mine, I call them wide events.
But elsewhere on the internet, you’ll also find them referred to as fat events, god events, RESTful events, or state events.

The “software engineer/architect with DDD background” view

As a developer working on event-driven microservices, the primary concern is implementing a business process as an event flow.

You think of events as triggers, and you want to have different types of events for different triggers. This allows you to look at a sequence of events and understand what’s going on.

Having different types of events also matches design processes such as event storming. The stickies contain what happened (the type of event), you don’t write the data on them.

Using different, properly named types for events means applying the ubiquitous language. Looking at the technical events, even a business person understands what’s going on.

The processes you implement are stories, and events are the smallest unit of a story.

If you had only one type of event, e.g. BookingUpdated, you’d have to figure out what’s going on by looking at what data has changed. Guesswork.

Let’s say your process is buying a cinema ticket. If you look at the sequence of events, what do you want to see?

SeatSelected → PaymentReceived → TicketIssued or
BookingUpdated → BookingUpdated → BookingUpdated

After all, it’s about collaboration between services - event-driven is not data replication.

Taking this perspective, for any entity you emit different types of events, with the event type clearly indicating what has happened. In terms of data contained in the event, it would be only the properties related to the event (the ones that have changed in the context of the event).

If you use Kafka, you publish all the different events relating to the same class of entity to one topic. (To read the events relating to the same entity in order, they must be on the same partition. Being on the same topic is a prerequisite for being on the same partition.) If you use a schema registry, you use the RecordNameStrategy or the TopicRecordNameStrategy.

This is totally legitimate and will work. But there’s a different perspective you should also consider.

The “data engineer” view

As a data engineer, it’s just data. Instead of in a table, it’s in a stream, but in the end, it represents the state of things.

Having data in too small units just creates more work for the data team to eventually create usable tables to represent the state of the represented entities.

That works best if you have just one type of event in the stream, so all events on a topic share the same schema. This gives you the “table-stream duality”. Also, it makes it easy to ingest the stream into a database, or into some headless data format (such as Iceberg).

From a data point of view, if you could query the stream like a DB, you’d be happy with a stream that just retains the latest state forever. In fact, instead of having both a streaming infrastructure and a database, you’d actually prefer to just have one.
(I think streaming databases address this, but haven’t really looked into this yet. And there are new streaming products such as Tektite, which lets you, I quote: “Query the data in any stream or table as if it were a database table”.)

If you use Kafka, you publish only one type of event per topic. If you use a schema registry, you use the TopicNameStrategy.

So what to do?

If you focus on only one of these purposes in the design of your events and neglect the other, you might make your life harder down the line.

If you only follow the data perspective, you’ll lose vital information about the reason for the event. Don’t reduce event collaboration to data replication.

Having said that, you’ll probably come across cases where it really is just data replication, and where you want wide events. This includes

Using events to populate your data warehouse or data lake.
Bootstrapping new services that are added to your system later, that need the full event history to start off with the up-to-date data.
Cases where other services hold a local projection of the data that needs to be updated (but the update itself doesn’t trigger an action).

If you focus only on the triggering nature of events, and these use cases come up later in your product’s lifecycle, you might have to introduce wide events as additional events. That adds effort you can avoid if you have the data aspect in mind early on.

So, based on all this, what should be in an event?

My take is:

It’s an absolute must that the event contains its reason, i.e. the business event that it represents.
It must contain at least the data that was changed in this event.
A fair amount of additional data doesn’t hurt. If your entity can be serialized into an event that’s still small enough, include a complete snapshot of its state and make your (and your data’s consumers) life easier.

“Include a complete snapshot” requires further qualification. Still be mindful of the data you include of your events. Not only because, from a technical perspective, events should be small, so they can be replicated quickly e.g. between the multiple nodes of your distributed message broker. But even more importantly: Your event stream is an API. You need to design the events just as carefully as you would design JSON objects for a RESTful HTTP API. What goes in there is hard to remove, and you want to be able to change your domain model internally to some extent without affecting the event payload.

So my standard approach is to use carefully designed, wide events and include the reason in the event (or alternatively as a header). While I want to see the reasons, and get the story from looking at the sequence of events, it doesn’t necessarily have to be encoded as the event type.

A sequence would then be something like

BookingUpdated(Reason: SeatSelected) → BookingUpdated(Reason: PaymentReceived) → BookingUpdated(Reason: TicketIssued)

To me this embraces the dual nature, it’s a “best of both worlds” practice for me. What’s your approach? Let me know what you think in the comments.

P.S. I help companies adopt event-driven architecture, from designing event schemas that balance the needs of software engineers and data teams to defining strategies for event granularity, versioning, and schema evolution. Whether you’re designing a new event-driven system or improving an existing one, I offer architecture consulting and training on exactly these topics. Feel free to get in touch.

Five Common Misconceptions About Event-Driven Architecture

2024-09-30T00:00:00+00:00

An opportunity for everyone to do a little self-test. Do you believe any of these five statements? If so, don’t worry, you’re not the only one, I’ve come across them many times. I’m very convinced they’re untrue, though. This is my humble attempt to improve our shared understanding of some properties of event-driven architecture.

EDA means Event Sourcing

Well, it doesn’t. Event sourcing is an approach to persisting data within a service. Instead of writing the current state to the database, and updating that stored data when the state changes, you store an event for every state change. The state can then be restored by replaying the events.
Event-driven architecture is about communication between services. A service publishes any changes in its subdomain it deems potentially interesting for others, and other services subscribe to these updates. These events are carriers of state and triggers of actions on the subscriber side.

While these two patterns complement each other well, you can have either without the other.

You can have an event-driven architecture consisting of multiple microservices, where none of them uses event sourcing. Maybe they all use CRUD operations on their relational database to persist state. They might still use e.g. a transactional outbox and publish all changes as events, for other services to subscribe to. An architecture that makes a lot of sense, if you want to get the benefits of event-driven architecture, but for some reason don’t think you’d profit from event sourcing, or feel you’re not ready for it.

Conversely, wherever you persist application state to a data store, you can do it with event sourcing. In a monolithic application, on in a single service in your microservices system. Or in all of them, but that’s a per-service decision - if you do it in one, it does not affect the others.

EDA and using Kafka are equivalent

Apache Kafka is a log-based message broker that’s very popular in event-driven systems. Log-based message brokers are a good architectural fit for event-driven architecture.

But for Kafka, whatever you send is just a “record”. A byte array. If you use it to publish events, commands, queries, or some other type of message no one has even thought of yet - Kafka doesn’t care. In this regard, the labeling on its home page, “Kafka is an open-source distributed event streaming platform”, is a bit misleading. That’s certainly the intended usage (and it should probably make you think if you use it in another way), but nothing is preventing you from using it differently. Trekking gear is made for hiking, but nothing stops you from wearing it in the office (physically, I mean, not accounting for dress codes).

Just as you can use Kafka without being event-driven, you can build an event-driven architecture without Kafka. And I’m not only talking about “Kafka replacements”, i.e. other log-based message brokers. I don’t know why you’d want to, but you could use a store-and-forward message queue (like ActiveMQ or RabbitMQ) for your eventing. You could even do it without any messaging infrastructure at all, e.g. by implementing HTTP feeds.

Just because you could, doesn’t mean you should! A log-based message broker is most likely the best approach for you, too, if you want an event-driven architecture. But it’s not the tool that makes it event-driven. It’s the semantics of your messages, and the flow of them through your system - see the next point.

EDA is only about the message naming/semantics

What makes a message an event? That it describes a fact, something that happened. E.g. “ShipItem” is a command. “OrderConfirmed” is an event.
This is true, but if you only focus on the semantics of your individual messages, without looking at the overall flow, you might fool yourself.

Look at the image below. Technically, all these messages are events. But each of the events has exactly one subscriber, and that subscriber will in turn emit an event that the original publisher subscribes to.

Commands and responses, disguised as events.

This is really a request-response flow. For example, the order service commands the inventory service to reserve an item. The fact that it phrases its question differently, as a statement, doesn’t make the system event-driven. For these messages, that look like events but really expect a specific recipient to carry out an action, Martin Fowler coined the term “passive-agressive commands”.

If you want to explore this further, I encourage you to watch my recent talk “The Unreasonable Effectiveness of Events” (Video, Slides), where I speak about this in detail.

EDA only makes sense when everything is event-based

Your application provides a REST API for the frontend? Surely that’s not event-driven. But that doesn’t mean you can’t build an event-driven architecture in the backend. If your backend system consists of multiple services, you can still leverage event-driven architecture to achieve better scalability and resilience (as being event-driven will remove any runtime dependency between your services).

In fact, it’s very common to build systems where only the inter-service communication within the system is completely event-driven, while communication with the “outside” world uses other patterns. This can be for the user interface, or for the integration of third-party systems, where you have to make do with whatever interfaces they offer, and those might not be event-driven. But don’t let this deter you from designing the communication between the services you implement in an event-driven way.

(You can read more about this in last month’s blog post “Event-Driven Core, Request-Response Shell”).

Event-Driven Core, Request-Response Shell.

EDA is inherently complex

Ok, it’s more complex than a small, non-distributed application (a small monolith, if you will).
But so are microservices. Once you enter microservices land, to support autonomous development and operations across multiple teams, you have the added challenge of dealing with the distributed nature.

So the question shouldn’t be, do things exist in this world that are less complex than event-driven architecture? (Of course there are.)
Instead, the question is: If I build a microservices architecture, is event-driven architecture more complex than an architecture that is based on REST or RPC calls? There my answer would clearly be no.

Don’t mistake “unfamiliar” with complex. Calling methods or functions is what we do in coding all the time. Making an HTTP request or gRPC call feels much closer to that than emitting (or consuming) an event. But just because something is different doesn’t mean it’s more complex.

Yes, it might be a bit mind-bending at first. But there’s nothing inherently complex in event-driven architecture. In fact, the separation of roles and responsibilities is even clearer than in a command-based system. Commands can fail, so when you issue a command, the caller has to think about what to do when things go wrong. This blurs responsibility - as the client of a service, you’re not necessarily in the best position to deal with its errors.

If you emit an event, you signal that you’re done, and you don’t want to hear back from any of the subscribers. Dealing with the event is their task now. When done right, event-driven architecture can have a beautiful simplicity to it.

P.S. I help companies adopt event-driven architecture, from building a solid foundational understanding within your team to guiding the architectural decisions that make event-driven systems succeed in practice. Whether you’re just starting to explore EDA or trying to get everyone aligned on what it actually means, I offer architecture consulting and training on exactly these topics. Feel free to get in touch.

Event-Driven Core, Request-Response Shell

2024-08-31T00:00:00+00:00

There’s much uncertainty and doubt (and maybe even fear?) around event-driven architecture. One example is the belief that it’s irrelevant for REST APIs, as using HTTP verbs is quite clearly not event-driven. But behold - you don’t always have to go all-in to win.

Most modern applications provide an HTTP-based API on the server side, usually - more or less - following REST principles. The front end will instruct the backend to do something via a command, and get some response back.

An event-driven architecture, in contrast, is based on systems publishing things that have already happened. Facts. OrderSubmitted. PaymentReceived.

So let’s get that out of the way: For end-user interaction, being purely event-driven is not the right approach. After all, as a user, I want to tell the system to do something. Not give it a notification about what I have done.

The outside view of a typical such system is something like: A service that gets requests via HTTP, does some processing, and manages persistent state with the help of a database.

But: In the case of bigger applications, developed by multiple teams, the service the users communicate with via HTTP will most likely not be alone. Other services are going to be involved. So how do these services interact? This can be designed in different ways. They can send requests and expect responses, be it via HTTP, gRPC, or asynchronous messaging.
Or, better: They can emit and listen to events. This is where the event-driven architecture comes into play for web applications and APIs: In the form of event collaboration between the backend services.

Don't do this: Request-Response between services.

By using events between the services, you remove a very critical type of coupling: Runtime coupling, sometimes called temporal coupling. In the request-response case, the system A (that the user interacts with) relies on systems B and C to be available and to have the capacity to handle that request at that time. If system B fails, this failure will propagate to system A and it will in turn also be unable to serve requests.

In this case, the goal of the event-driven architecture isn’t that everything is event-driven. It’s that any service that’s exposed to requests that demand a response can handle them on its own. At runtime, it’s not dependent on other services. Any request to it won’t cascade to services it depends on.

Do this instead: Event-Driven Communication.

In a request-response system, the availability of a service is the product of the availability of all services in the call chain. If service A depends (directly or transitively) on four other services, and itself and the four others provide a 99% availability each, the system availability observed from the outside will be 99% to the power of 5, i.e. 95%. If service A has no runtime dependencies, the availability observed from the outside will be that of service A, i.e. in our example 99%.

Core And Shell

If you’ve looked into functional programming, you might have come across the phrase “functional core, imperative shell”.

I’m not sure where this originated - maybe from Gary Bernhardt’s “Boundaries” talk from 2012. What’s this pattern about?

Pure functional code is very pleasant to reason about. It allows you to apply a mathematical mindset. It’s referentially transparent, each function application can be replaced with its result, which is beautiful. Being pure means having no side effects, you only have arguments going in and the result of function application.

As wonderful as freedom from side effects is - creating output or changing the state of data in the database, these are side effects. But these are also things you probably want your program to do. People need to interact with it, and you want to persist state. As Simon Peyton Jones once said, a purely functional program is useless. But instead of giving up on functional programming completely, you can still benefit from it. Just introduce some segregation into your program, into a purely functional core, and a shell that manages the interaction, between that core and the stateful outside world.

Functional Core, Imperative Shell. Image by Mario Bittencourt.

Do you see how this translates to event-driven architecture? Go ahead, and have services with request-response interfaces for the users, and for third-party systems that require it. But in between your services, stay “pure”, and stay event-driven.

Bring the data to the process

You’ve probably heard about the troika “command, query, event” when it comes to communication between services. If not, here’s a quick reminder:

Reminder: Commands, Queries, Events
Pattern	Event	Command	Query
Describes..	An event that has happened in the past	An intention to perform an operation or change a state	A request for information about the current state of one or many objects
Expected Response	None	A confirmation that the command has been executed, or an error message	The requested information

I once heard someone say, and it stuck with me: “Queries are for front-ends”. That makes sense. A service should usually not query another service. It should subscribe to its event stream. We can extend this: Between the services you control, use events. Queries and commands are for the front-end, and for 3rd party and legacy systems that aren’t event-driven.

Event-Driven Core, Request-Response Shell.

Summary

Event-Driven Architecture doesn’t mean every aspect of the system has to be event-driven. In the shell of the system, where it interfaces with users, or with legacy or third-party systems, you can still cater to the reality of request-response driven communication if you have to.
But put events at the core of your system, when it comes to communication between your services. This way, you achieve, among other things, temporal decoupling, increasing the availability of your overall system. There’s still a lot of value in being event-driven, even if it’s restricted to the core.

P.S. I help companies adopt event-driven architecture, from identifying the right boundaries between event-driven and request-response communication to designing a pragmatic migration path that delivers value without requiring a big-bang rewrite. Whether you’re evaluating EDA for a new project or introducing it into an existing system, I offer architecture consulting and training on exactly these topics. Feel free to get in touch.

What Kind of Asynchronous is Right For You?

2023-06-15T00:00:00+00:00

There are a few ways for (micro-)services to communicate with other (micro-)services that can be rightfully classified as asynchronous¹. But they have very different characteristics. Let’s have a look at them and their impact on the overall system structure.

Asynchronous Option 1: Non-blocking network calls (e.g. HTTP, gRPC)

On a low technical level, the term asynchronous is used to mean “not blocking the thread of execution”. If you call an asynchronous method, that method will be executed concurrently. Usually, control will return to the caller immediately and the method will be executed on another thread.

In languages like Java, where operating system threads are the standard concurrency model, if the asynchronous method returns something, you’ll have to provide a callback. Or it’ll return a Future that will complete at some later point in time, like the HttpClient in the Java standard library (since Java 11). sendAsync doesn’t return the HttpResponse, but a CompletableFuture<HttpResponse>.

Other languages have other mechanisms to avoid blocking. In Go, for example, you can wrap the call in a goroutine that is executed asynchronously. The actual remote call will look like a synchronous (blocking) call, but only the goroutine that contains the call will be blocked. As goroutines are managed by the internal Go scheduler, this won’t block the worker thread that executes it.

Either way (with futures or co-/goroutines), as the operating system thread will be freed for other work while waiting for the network I/O to complete, these non-blocking calls are very efficient. The maximum number won’t depend on the number of OS threads that can be handled reasonably. Only by other OS limitations such as maximum file handles and TCP port range, and that should only kick in somewhere beyond 10k.

So it’s a lightweight approach, also in the sense that it’s very direct, you don’t need any middleware. HTTP/gRPC client to HTTP/gRPC server, nothing is needed in between. There might be, such as CDN nodes, API gateways, (reverse) proxies, load balancers, and sidecars, but that’s all optional: None of it’s needed to make the fundamental communication work.

Asynchronous Option 2: Messaging

HTTP (or gRPC) calls can be asynchronous in the sense of non-blocking. But if you were to draw an architecture diagram of the services communicating, you’d probably draw them as synchronous calls. Viewed from the outside, the caller sends a request and waits for the response to continue its work. It’s just not “busy waiting”, but waiting more efficiently.

Another form of asynchronous communication (and one which would be visible as such in architecture diagrams) is messaging. Here the caller becomes a sender and uses a message bus to send a message to one or multiple recipients. Again there’s no blocking: As soon as the message bus has accepted the message, the sender will go on to do other things.

As opposed to the HTTP or gRPC call, this will even work if the recipient is unreachable at the time the message is sent.

Based on this, you could say this approach removes a runtime coupling between sender and receiver - they aren’t required to be up at the same time. This would then lead to more robust systems, as a failure of one service does not cascade and degrade the functionality of all other services using it.

However, in practice, the actual decoupling is very limited if you use messaging in a request-response way. If the sender instructs the recipient to do something (i.e. the request is a command), it’ll need to know if the operation succeeded (the response will be a message indicating success or error). The runtime coupling is still there then, as the overall process is stuck until the response is received. The same is true if the sender asks for information (i.e. the request is a query, the response is the requested data) that it needs to continue.

So while technically the introduction of the message bus decouples the two systems, if the communication follows a request-response pattern, the sender is still blocked from proceeding until the response is received.

Asynchronous Option 3: Event-driven Communication

To achieve real runtime decoupling, we must look at the semantics of our messages. In addition to the commands and queries mentioned above, there’s the third option of emitting an event.

Table 1: Commands, Queries, Events
Message Type	Command	Query	Event
Describes..	An intention to perform an operation or change a state	A request for information about the current state of one or many objects	A fact, something that undisputedly happened in the past
Expected Response	A confirmation that the command has been executed, or an error message	The requested information	None
Communication Pattern	Request-Response	Request-Response	Fire-And-Forget

An event describes a fact. As opposed to commands or queries it’s not directed at a receiver. If you ask another service to do something, or request information, your message goes to that specific service. But if you just tell “the world” that something happened, any service that this information is relevant to can pick it up. Thus the sender becomes a publisher, and other services can become subscribers to the information.

Emitting events, as opposed to sending commands, will lead to a fundamentally different design of your services. Think of a simple order process. Part of it may be collecting the payment and blocking the inventory. In a request-response case, one service (or maybe a workflow engine) would take care of the overall process, send messages to the payment service and the inventory service, and wait for the responses.

With events, the service taking the order would simply publish the information that the order has been deemed valid and accepted. The other services would then observe the event and would be responsible to take appropriate action. It’d be up to them to handle any errors or raise any alerts - there’s no back channel to the publisher.

This is the highest level of runtime decoupling. Just like in the other cases, there’s no blocking, and in addition to that, there’s no waiting for any response.

Real Life Analogies

The different patterns and their impact on the overall flow may not be intuitive. Maybe it helps to think about how this would work with people communicating, instead of services. Assume you want to order a pizza.

The approach that resembles the (HTTP/gRPC) network call most closely is a phone call². You call the pizza place and will get an immediate response.

Maybe they also take orders by e-mail or text message. This would be equivalent to the messaging option. Once you sent your message, you’re not blocked. But the order may fail - maybe they’re missing a topping you ordered, or you sent the message outside of their business hours. You won’t know when (and if) they’re going to deliver the pizza until you get a response message.

For the event-driven option, you’ll have to imagine you’re not a customer, but a waiter in a pizza restaurant. You receive an order, put it on a piece of paper, and stick the paper into the kitchen order system (“tab grabber”). At this point, you forget about it. You know a chef will pick up the order, make that pizza, put it in the service hatch, and ring a bell when it’s ready. Maybe your shift has ended by then - it’ll still be delivered to the table by some other waiter. The overall workflow is now divided into completely decoupled sub-processes (order taking, food preparation, food delivery) The order sub-process is completed once you posted that piece of paper. You don’t wait for a chef to confirm that they’ll actually prepare the food.

A kitchen order system or "tab grabber". Image by ThinkStock

The Different Options Compared

The table below summarizes the main characteristics of the three different asynchronous options.

Table 2: Types of Asynchronous. "No" is better!
	The thread of execution on the caller/sender side is blocked	The server/recipient has to be available	The client/sender expects a response
Async Network Call	No	Yes	Yes
Messaging (request-response)	No	No	Yes
Event-driven	No	No	No

Using events removes the runtime coupling entirely. It does mean you have to build your system event-driven, though. If you’re used to building everything using HTTP or gRPC calls (which many of us are, as they’re relatively similar to local function calls), this may be a bit mind-bending. But not doing so, to quote Confluent’s “command” pattern page, is a missed opportunity:

in moving from a function call within a monolith to a system that posts a specific command to a specific recipient, we’ve decoupled the function call without decoupling the underlying concepts.

Fortunately, many people start their system design with events nowadays, applying discovery and modeling techniques such as event storming, domain storytelling, or event modeling³. If you think in events from the start, you’re much more likely to be successful in building an event-driven system.

Even in an event-driven architecture, there might still be someplace where you need a response to proceed. An HTTP (or gRPC) call is a straightforward option for this. This is what the front end uses to communicate with services, this is probably what you use in your authentication mechanism - so there’s a very good chance you’re using it in your application already.

So where does this leave option 2, messaging, then? It doesn’t give you the runtime decoupling you get from being event-driven. If you send a command or query, even if it’s via a message bus, there’ll be a response you’re interested in and that you have to wait for. Neither does it give you the simple directness of a network call:

You need additional middleware (message bus) to make it work.
You have to correlate responses with their requests. That usually means you need to store request information in persistent storage under some key (request id or correlation id) and make sure to include that key in both request and response, so you can associate the response with the request
You need to deal with timeouts, i.e. requests that don’t get a response in the expected time.

All this makes option 1, the HTTP/gRPC call, much more attractive for the command and query (i.e. request-response) cases. There’s no extra middleware. And the response is handled in the same place in your code where the request is sent. A lot of complexity of messaging arises from the fact that the response may be received by another node, not the one who sent the message. In an HTTP call, you don’t worry about correlating the response to the request. As all the handling will happen locally in the same process, it can be done “under the hood”, making the developer’s life simpler. Timeouts can be handled by a circuit breaker, which is available as a library or as sidecar functionality.

Messaging creates the illusion of being more robust or reliable, and of somehow increasing the decoupling. But don’t be fooled. It adds a lot of complexity, without giving you the benefits of real events. Look at the semantics of your communication. If the communication is request-response, what value does messaging add over network calls? There’s no shame in using HTTP or gRPC if you need a response.

Just like it doesn’t make anything more robust, neither does it make anything faster or more scalable. If a service isn’t able to handle n HTTP/gRPC calls in a given time, it’ll be equally unable to handle n messages in that time. How great it would be if the choice of communication channel had such an effect!

An argument I heard for request-response messaging is, that there are cases with a very long time between requests and responses. You send a request and want a response, but only eventually, maybe only the next day. I find this to be an odd design. If you don’t need the response to give some feedback to your caller, your system can, and should, be changed to not need the response at all. This seems to be a case of the “[decoupling] the function call without decoupling the underlying concepts” mentioned above. Better redesign the process to use proper events.

Still, request-response messaging won’t disappear completely. It’s a valid option for integration with third-party or legacy systems. Some commercial off-the-shelf software may not offer alternative modes of communication. But if you control both ends of the communication, it seems a very unattractive proposal.

Which Type of Asynchronous to Choose?

Event-driven systems provide a high level of runtime decoupling. In an event-driven system, services will be able to serve requests without invoking other services.

Choose event-driven communication wherever you can. When designing a new system, start with events⁴.

If you need a response, use an HTTP or gRPC call. In those situations, where you choose to use commands or queries, i.e. apply a request-response pattern of communication, keep it simple. Just make sure the libraries and methods you use are non-blocking, to keep it efficient.

Avoid the added complexity of doing request-response with messaging: the need for a message bus, to correlate messages, and to deal with timeouts. Reserve request-response messaging for places where you have no choice: The integration of third-party or legacy systems.

P.S. I help companies adopt event-driven architecture, from evaluating the right asynchronous communication patterns for their specific situation to avoiding the common pitfall of adding messaging complexity without getting the real benefits of event-driven decoupling. Whether you’re designing a new system or untangling an existing one, I offer architecture consulting and training on exactly these topics. Feel free to get in touch.

For a deep dive into the possible meanings of asynchronous, you can watch this talk by Sam Newman ↩
This doesn’t really account for the asynchronous nature of modern network call libraries as described above, but from the outside, a synchronous and asynchronous call will look the same anyway. For the async part, you could imagine while the phone is ringing at the pizza place, you do other things, and you phone notifies you the moment the other side picks up. ↩
Disclaimer: Of these, I’ve only ever used event storming in a professional context. I mention the techniques only to illustrate that there are several popular movements that support event-driven architecture. Before choosing an approach to analyze your domain and model your systems, please do additional research. ↩
A good article on “events first” by Russ Miles. ↩

Flix For Java Programmers

2022-06-24T00:00:00+00:00

The Java Virtual Machine isn’t limited to running programs written in the Java programming language. Many other compilers output Java bytecode. Some of these languages have so far remained exotic. Others have found a large following, for example Groovy, Clojure, Scala, and Kotlin. Now Flix, another language that brings some fresh approaches to the JVM, has entered the scene.

Apart from the JVM bytecode as compiler output, Flix doesn’t have much in common with Java. It’s a functional programming language, without the inheritance known from object-orientation. The idea of Flix is not to be a “better Java” that makes it easy for Java developers to switch. Rather, it’s about offering new tools that have not yet found their way into mainstream programming languages.

Explicit Side Effects

One such new element is the effect system. As a reminder, in programming, we distinguish between pure functions and those with side effects. A pure function returns only a value, and this value depends on nothing else than the arguments passed to the function (so-called referential transparency). A pure function is independent of any data anywhere outside of itself, and also doesn’t change the environment around it. This has very convenient practical implications. The evaluation of a pure function can be done by substitution: Each occurrence of a variable can be replaced by the expression it references. Also, we know that for the same arguments, a pure function will always yield the same result. Since it’s independent of any external context, this is true at any point in the program, at any time.

// Example: Flix Effect System

// 1. pure functions with no side effects
def isEven(x: Int32): Bool & Pure = x mod 2 == 0
def double(x: Int32): Int32 & Pure = x * 2


// 2. a function that only has a side effect. If you wonder about the
// type of the argument: it accepts everything that can be converted
// to a string (more formally: for which an instance of the type class
// "ToString" exists.
def write(s: t): Unit & Impure with ToString[t]= println(s)


def main(): Int32 & Impure =
    let list = (1 :: 2 :: 3 :: 4 :: Nil);

    // 3. List.count requires the argument to be a pure function
    let noOfEvens = List.count(isEven, list);
    write(noOfEvens);

    // 4. Foreach is about executing a side effect on every element.
    // Thus, it requires an impure function as argument.
    List.foreach(write, list);

    // 5. List.map demonstrates effect polymorphism. If the passed 
    // function is pure, so is map,if the passed function is 
    //impure, map is impure.
    let doubled = List.map(double, list);
    List.map(write, doubled);
    0 // exit code

Listing 1

Pure and non-pure functions exist not only in Flix, but in every programming language. But only in very few programming languages can you distinguish them without analyzing the function’s implementation. Of course, in Java there’s the “void” return type, which says that the method has only side effects and no return value. But the reverse doesn’t exist: there’s no way to express in the signature that a method has no side effects / is a pure function.

Why Learn Flix?

If someone has a good command of Java but wants to expand their horizon and learn another programming language - which one should they choose? The Hamburg computer science professor Friedrich Esser has given a short and crisp answer to this: "It shouldn't be a step backward, the new language simply has to offer more than the old one." In this spirit, the article doesn't attempt to give a complete overview of Flix (such an overview would certainly fill an entire book), but to present a few selected features that make it stand out from Java.

In Flix, there is: Here the type system is extended with the effect types Pure and Impure. Listing 1 above shows a simple example. Arithmetic operations like modulo or multiplication are pure, so functions that use them are also pure. Output to the console is a side effect and, accordingly, not pure. It gets more interesting with functions that have other functions as parameters (higher-order functions). Here the implementation can restrict which functions are allowed as arguments. For example, counting the elements of a list that satisfy a certain predicate requires the predicate to be pure. The counterexample is foreach: it doesn’t return anything, but is used to perform a side effect for each element of a list. Passing a pure function here would be meaningless - the return value would be discarded, so nothing would happen at all. It’s implicitly clear that only a function with a side effect makes sense. An effect system like Flix’s allows to make the implicit explicit: The signature of foreach enforces that the function applied to each element is not pure.

But there’s also the possibility to allow both. In this case, Flix talks about functions with polymorphic effects - they work with different effect types. List.map is an example of this. It inherits the effect from the passed-in function, so map itself can be pure or non-pure, depending on the function it applies to each element. However, the effect of the passed function is known at compile-time, so even with polymorphic effects, the compiler can check whether the effect is allowed or not.

Logical Programming With Datalog

Another feature of Flix is the integration of the logical description and query language Datalog. This allows predicate logical expressions to be defined and evaluated directly in a Flix program. Listing 2 shows how a simple knowledge base of facts and rules can be built. With a simple statement Father("Zeus", "Kronos") (1.) we tell the system that Kronos is the father of Zeus. The rules to be applied to this (2.) can be recursive, with no restriction on the depth of recursion. Thus, our ancestor rule AncestorOf states: Ancestor of X is any Y who is a parent of X. But so is any Z if it holds that Y is an ancestor of X, and Z is an ancestor of Y. This way we express the transitivity of the ancestor relationship.

// 1. The relationships we're interested in.
rel Father(child: String, father: String)
rel Mother(child: String, mother: String)
rel ParentOf(child: String, parent: String)
rel Child(parent: String, child: String)
rel AncestorOf(person: String, ancestor: String)

// 2. The direct relationships as facts
def getFacts(): #{ Father, Mother, ParentOf, Child, AncestorOf } = #{
    Father("Zeus", "Kronos").
    Mother("Zeus", "Rhea").
    Father("Ares", "Zeus").
    Mother("Ares", "Hera").
    Father("Apollo", "Zeus").
    Mother("Apollo", "Leto").
}

// 3. relationships that can be deduced
def getRules(): #{ Father, Mother, ParentOf, Child, AncestorOf } = #{
    ParentOf(x, y) :- Father(x, y). 
    ParentOf(x, y) :- Mother(x, y).
    Child(x, y) :- ParentOf(y, x). 
    AncestorOf(x, y) :- ParentOf(x, y).
    AncestorOf(x, z) :- AncestorOf(x, y), AncestorOf(y, z).
}

// 4. Now we can query the knowledge base, e.g.
// who are the children of Zeus?
def main(): Int32 & Impure =
    let a = query getFacts(), getRules() select (x) from Child("Zeus", x);
    let b = query getFacts(), getRules() select (y) from AncestorOf("Apollo", y);
    println("Children of Zeus = ${a}");
    println("Ancestors of Apollo = ${b}");
    0 // exit code

Listing 2

The syntax and semantics of Datalog borrow from Prolog. It’s a subset of Prolog, but not a full-fledged (Turing-complete) programming language itself. Embedded in another programming language this is of course no problem - Datalog can be used within a Flix program to describe facts and logical rules declaratively, while for everything else Flix itself is available.

Concurrency With Channels And Processes

While Java developers wait for Project Loom to get lightweight concurrency as a language feature, Flix relies on the approach also taken by Clojure and Go: Channels and coroutines. In Flix, the latter are named processes. This approach to concurrency is also called “CSP style” because it takes elements from the concept of Communicating Sequential Processes by Tony Hoare.

The spawn keyword is used to execute a method in the background without starting a new native thread. Sometimes referred to as “green threads”, these routines are managed internally by Flix and executed on native threads as needed. It’s forbidden for different processes to communicate by accessing shared variables - which is good because in any programming language, code with shared mutable state is difficult to reason about and debug. Instead, Flix provides channels for communication between processes. A channel is a kind of lightweight queue, located in local memory, into which (one or more) senders put messages and (one or more) receivers read them. They come in two flavors: Buffering channels have a buffer size that determines how many items the channel can hold. Non-buffering channels have no capacity themselves. In this case, the channel is blocked until a receiver can hold a value, and vice versa. A small example can be found in Listing 3.

// a function that simulates latency
def doSomething(c: Channel[Int32], x: Int32, gen: Random.Random): Unit & Impure = {
    let delay = abs(Random.nextInt64(gen)) mod 2000i64;
    <- Timer.milliseconds(delay);
    c <- x;
    ()
}

// Listens to a channel and outputs messages. If nothing 
// arrives for 5 seconds, it terminates.
def printResults(c: Channel[Int32]): Unit & Impure = {
    select {
        case x <- c => println(x); printResults(c)
        case _ <- Timer.seconds(5i64) => println("done")
    };
    ()
}

def abs(i: Int64): Int64 & Pure = if (i < 0i64) Neg.neg(i) else i

/// Spawn a process for send and wait, and print the result.
def main(_args: Array[String]): Int32 & Impure = {
    let gen = Random.new();
    let results = chan Int32 100;
    let l = List.range(0,100);
    spawn printResults(results);
    List.foreach(x -> spawn doSomething(results, x, gen), l);
    <- Timer.seconds(10i64);
    0
}

Listing 3

This type of communication is intended to avoid the race conditions that can occur with shared memory access. Flix follows the Go mantra: “Do not communicate by sharing memory; instead, share memory by communicating”.

Recursion Without Regret

Anyone who has tried to program functionally in Java will certainly have implemented a recursive algorithm sooner or later. Or rather, they will have failed in doing so, because Java severely restricts the use of recursion. The Java compiler doesn’t detect tail calls and consequently doesn’t perform any optimization on them. An example is shown in listing 4. If we try to recursively add all numbers up to 25000, but we’ll never get the expected result (312512500), instead we’ll get a StackOverflowError.

class Tailcalls {

    static int sumup(int n) {
        return tailsum(0, n);
    }

    static int tailsum(int m, int n) {
        if (n == 0) {
            return m;
        } else {
            return tailsum(m +n, n - 1);
        }
    }

    // Gibt einen StackOverflowError
    public static void main(String[] args) {
        System.out.println(sumup(25000));
    }
}

Listing 4

Other JVM languages that have a stronger focus on functional programming, such as Scala, Kotlin, and Clojure, transform this code. The resulting bytecode is then as memory efficient as an iterative implementation.

def sumup(n: Int): Int = tailsum(0, n)

def tailsum(m: Int, n:Int): Int = {
    match n {
        case 0 => m
        case _ => tailsum(m + n, n - 1)
    }
}

// Gibt keinen Stack Overflow!!
def main(_args: Array[String]): Int32 & Impure =
    println(sumup(25000));
    0

Listing 5

Flix even goes a step further. It not only detects and eliminates tail-end recursion - the snippet in listing 5 calculates the sum for large values without any problems. The Flix compiler even detects “mutual” recursion, where two functions call each other at the end position. Listing 6 shows a textbook example of this in Java. It recursively determines whether a number is even or odd - but not for large numbers, due to lack of optimization. The equivalent code in Flix in listing 7, on the other hand, digests large values without complaint, since here the stack consumption is constant and does not grow with the value passed.

class MutualRecursion {

    static boolean isOdd(int n) {
        return (n == 0) ? false : isEven(n - 1);
    }

    static boolean isEven(int n) {
        return (n == 0) ? true : isOdd(n - 1);
    }

    // Gibt einen StackOverflowError
    public static void main(String[] args) {
        System.out.println(isEven(25000));
    }
}

Listing 6

def isOdd(n: Int32): Bool =
    if (n == 0) false else isEven(n - 1)

def isEven(n: Int32): Bool =
    if (n == 0) true else isOdd(n - 1)

// Gibt keinen Stack Overflow!!
def main(_args: Array[String]): Int32 & Impure =
    println(isEven(25000));
    0

Listing 7

All The Rest

If you’ve taken a look at the listings, you’ll have noticed that the four “big” features described above are by far not all that distinguish Flix from Java. A complete list of all differences would go beyond the scope of this article, but here are some examples:

Flix doesn’t know a value null. The idea that a reference can also be null has since been called a mistake by its inventor, and many programmers have felt despair facing a NullPointerException. Other JVM languages, such as Kotlin and Scala, have introduced mechanisms to get by without null. Flix adopts the Option type, which has now also moved into Java, to indicate the possible absence of a value.

The Flix compiler is strict. If something is declared, be it a function or a local variable, it must be used. An identifier used in the environment can’t also be used locally, so there’s no “shadowing”. Even in Java all this isn’t considered good style and is often marked as a warning in the IDE. But Flix doesn’t have any warnings! It’s binary in this regard: Either it’s an error, and then compilation fails. Or it’s not, in which case there’s no warning.

Flix is typed, but the types don’t usually have to be specified. Instead, the compiler determines them using type inference. Although this would also be possible for function declarations, the Flix developers have decided to require them there: Both argument and return type must be specified, as to enforce minimal documentation.

As a functional programming language, Flix knows no classes or inheritance. Namespaces are used to structure the code base. Abstraction over different types is made possible by type classes, as they are used e.g. also in Haskell. A type class describes behavior on an abstract level that can be implemented by different types. You see the use of the type class ToString in the sample code. If there’s a definition of how to convert a type into a string representation, it’s said that there is a type class instance of ToString for this type. Functions can then refer to this type class. That is, for example, a function can be defined to accept all argument types for which there is a ToString instance (like our little write function).

Support for unit tests is built directly into the compiler in Flix. The language has the annotation “@test”. If the compiler is called with the argument “test”, all correspondingly annotated functions are executed and the results are output.

Java Interoperability

The great advantage of a language that runs on the JVM is that it can draw on existing Java libraries. So from day one, a huge ecosystem of libraries, including clients for any databases and middleware, is available. And all the work that has already gone into custom Java libraries has not been in vain, as they can continue to be used.

def main(_args: Array[String]): Int32 & Impure =
    import new java.io.File(String) as newFile;
    import java.io.File.exists();
    let f = newFile("HelloWorld.txt");
    println(exists(f));
    0

Listing 8

To use Java classes, Flix provides the import keyword (it is not needed internally in Flix, the keyword for importing identifiers from another namespace is use). However, the import is quite fine-grained. It is not enough to import a class, each method must be imported separately. With as the name can be replaced by an alias for use in Flix. Constructors can be made visible with import new, fields with import get. Listing 8 shows a minimal usage of java.io.

An exciting language in its infancy

Flix is a very young language and still far from production maturity. It’s currently not a serious alternative to Java or the other established JVM languages mentioned at the start. What makes it special, however, is the ambitious vision. It goes far beyond cosmetic improvements or porting an existing language to the JVM. With the effect system and the Datalog integration, Flix offers real innovation. In other parts, it’s done plenty of smart cherry-picking from other languages (e.g. type classes). It’ll be exciting to see how Flix will evolve in the next few years, and also which Flix features will be adopted by established languages sooner or later.

The source code examples for this article are available on Codeberg.

Java Concurrency: An Introduction to Project Loom

2022-06-17T00:00:00+00:00

Project Loom is an experimental version of the JDK. It extends Java with virtual threads that allow lightweight concurrency. Preview releases are available and show what’ll be possible.

Server-side Java applications should be able to process a large number of requests in parallel. But the model that’s still most widely used in server-side Java programming today is thread-per-request. An incoming request is assigned a thread, and everything that needs to be done to produce a suitable response is processed on this thread. However, this severely limits the maximum number of requests that can be processed concurrently. Java threads, each of which uses a native operating system thread, aren’t exactly lightweight. Neither in terms of memory consumption: Each thread takes up more than one megabyte of memory by default. Nor in terms of the cost of switching between threads (context switch).

What are the others doing?
Virtual threads may be new to Java, but they aren't new to the JVM. Those who know Clojure or Kotlin probably feel reminded of "coroutines" (and if you've heard of Flix, you might think of "processes"). Those are technically very similar and address the same problem. However, there's at least one small but interesting difference from a developer's perspective. For coroutines, there are special keywords in the respective languages (in Clojure a macro for a "go block", in Kotlin the "suspend" keyword). The virtual threads in Loom come without additional syntax. The same method can be executed unmodified by a virtual thread, or directly by a native thread.

In response to these drawbacks, many asynchronous libraries have emerged in recent years, for example using CompletableFuture. As have entire reactive frameworks, such as RxJava, Reactor, or Akka Streams. While they all make far more effective use of resources, developers need to adapt to a somewhat different programming model. Many developers perceive the different style as “cognitive ballast”. Instead of dealing with callbacks, observables, or flows, they would rather stick to a sequential list of instructions.

Is it possible to combine some desirable characteristics of the two worlds? Be as effective as asynchronous or reactive programming, but in a way that one can program in the familiar, sequential command sequence? Oracle’s Project Loom aims to explore exactly this option with a modified JDK. It brings a new lightweight construct for concurrency, named virtual threads. And a modified standard library based on them.

Virtual Threads

Does anyone remember multithreading in Java 1.1? At that time Java only knew the so-called “Green Threads”. The possibility to use multiple operating system threads wasn’t used. Threads were only emulated within the JVM. Only from Java 1.2 onwards, a native operating system thread was used for each Java thread. And now, some 20 years later, the “Green Threads” are celebrating a revival! Albeit in a significantly changed, modernized form. On paper, virtual threads aren’t that different: they’re threads that are managed within the JVM. However, they’re now no longer a replacement for the native threads, but a supplement. A (relatively small) set of native threads is used as “carrier threads” to process an (almost arbitrarily large) number of virtual threads. The overhead of the virtual threads is so little that the programmer doesn’t need to worry about how many of them to start.

A native thread in a 64-bit JVM with default settings reserves one megabyte alone for the call stack (the “thread stack size”, which can also be set explicitly with the -Xss option). On top of that, there’s some metadata. And if the memory isn’t the limit, the operating system will stop at a few thousand.

   // Attention, can freeze computer...
   void platformThreads() throws InterruptedException {
        ThreadFactory factory = Thread.ofPlatform().factory();
        ExecutorService executor = Executors.newFixedThreadPool(10000, factory);
        IntStream.range(0, 10000).forEach((num) -> {
            executor.submit(() -> {
                try {
                    out.println(num);
                    // We wait a bit, so that the threads really all
                    // run simultaneously
                    Thread.sleep(10000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        });
        executor.shutdown();
        executor.awaitTermination(Integer.MAX_VALUE, TimeUnit.SECONDS);
    }

Listing 1

The attempt in listing 1 to start 10,000 threads will bring most computers to their knees (or crash the JVM). Attention - possibly the program reaches the thread limit of your operating system, and your computer might actually “freeze”. Or, more likely, the program will crash with an error message like the one below.

Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 4k, detached.
[2,459s][warning][os,thread] Failed to start the native thread for java.lang.Thread "Thread-8163"
Exception in thread "main" java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached

With virtual threads on the other hand it’s no problem to start a whole million threads. Listing 2 will run on the Project Loom JVM without any problems.

    void virtualThreads() throws InterruptedException {
        // Virtual Threads Factory
        ThreadFactory factory = Thread.ofVirtual().factory();
        ExecutorService executor = Executors.newFixedThreadPool(1000000, factory);
        IntStream.range(0, 1000000).forEach((num) -> {
            executor.submit(() -> {
                try {
                    out.println(num);
                    // Thread.sleep sends only the virtual thread to sleep here
                    Thread.sleep(10000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        });
        executor.shutdown();
        executor.awaitTermination(Integer.MAX_VALUE, TimeUnit.SECONDS);
    }

Listing 2

JDK APIs

So now we can start a million threads at the same time. This may be a nice effect to show off, but is probably of little value for the programs we need to write.

When are threads coming for everyone?
Project Loom is keeping a very low profile when it comes to in which Java release the features will be included. At the moment everything is still experimental and APIs may still change. However, if you want to try it out, you can either check out the source code from Loom Github and build the JDK yourself, or download an early access build. The source code in this article was run on build 19-loom+6-625.

Things become interesting when all these virtual threads only use the CPU for a short time. Most server-side applications aren’t CPU-bound, but I/O-bound. There might be some input validation, but then it’s mostly fetching (or writing) data over the network, for example from the database, or over HTTP from another service.

In the thread-per-request model with synchronous I/O, this results in the thread being “blocked” for the duration of the I/O operation. The operating system recognizes that the thread is waiting for I/O, and the scheduler switches directly to the next one. This might not seem like a big deal, as the blocked thread doesn’t occupy the CPU. However, each context switch between threads involves an overhead. By the way, this effect has become relatively worse with modern, complex CPU architectures with multiple cache layers (“non-uniform memory access”, NUMA for short).

To utilize the CPU effectively, the number of context switches should be minimized. From the CPU’s point of view, it would be perfect if exactly one thread ran permanently on each core and was never replaced. We won’t usually be able to achieve this state, since there are other processes running on the server besides the JVM. But “the more, the merrier” doesn’t apply for native threads - you can definitely overdo it.

To be able to execute many parallel requests with few native threads, the virtual thread introduced in Project Loom voluntarily hands over control when waiting for I/O and pauses. However, it doesn’t block the underlying native thread, which executes the virtual thread as a “worker”. Rather, the virtual thread signals that it can’t do anything right now, and the native thread can grab the next virtual thread, without CPU context switching. But how can this be done without using asynchronous I/O APIs? After all, Project Loom is determined to save programmers from “callback hell”.

This is where the advantage of providing the new functionality in the form of a new JDK version becomes apparent. A third-party library for a current JDK is dependent on using an asynchronous programming model. Project Loom, on the other hand, comes with a modified standard library instead. Many I/O libraries have been rewritten to use virtual threads internally (see box below). A familiar network call is - without any change to the program code - suddenly no longer “blocking I/O”. Only the virtual thread pauses. This trick means that existing programs also benefit from the virtual threads without the need for any adaptations. The following classes in the standard library have been modified so that blocking calls in them no longer block the native thread, but only the virtual thread:

java.net.Socket
java.net.ServerSocket
java.net.DatagramSocket/MulticastSocket
java.nio.channels.SocketChannel
java.nio.channels.ServerSocketChannel
java.nio.channels.DatagramChannel
java.nio.channels.Pipe.SourceChannel
java.nio.channels.Pipe.SinkChannel
java.net.InetAddress

Standard Library Classes Modified to Use Virtual Threads

Continuations

The concept that forms the basis for the implementation of virtual threads is called “delimited continuations”. Most of you will have used a debugger before to set a breakpoint in the code. When this point is reached, the execution is stopped and the current state of the program is displayed in the debugger. It would now be conceivable to “freeze” this exact state. This is the basic idea of a continuation: stop at a point in the flow, take the state (of the current thread, i.e. the call stack, the current position in the code, etc.) and convert it into a function, the “pick up where you left off” function. This can then be called at some later point in time and the process that was started can be resumed. This is exactly what’s needed for virtual threads: The ability to stop a program at any point in time and resume it later, in the remembered state.

Continuations have a justification beyond virtual threads and are a powerful construct to influence the flow of a program. Project Loom includes an API for working with continuations, but it’s not meant for application development and is locked away in the jdk.internal.vm package. It’s the low-level construct that makes virtual threads possible. However, those who want to experiment with it have the option, see listing 3.

    void continuations() {
    // The scope is a tool for creating nested continuations.
    // to enable.
        ContinuationScope scope = new ContinuationScope("demo");
        Continuation a = new Continuation(scope, () -> {
            out.print("To be");
    // the function is "frozen" here
    // and gives control to the caller.
            Continuation.yield(scope);
            out.println("continued!");
        });
        a.run();
        out.print(" ... ");
    // the continuation can be moved from where it was stopped,
    // be continued.
        a.run();
    // ...
    }

Listing 3

It’s worth mentioning that virtual threads are a form of “cooperative multitasking”. Native threads are kicked off the CPU by the operating system, regardless of what they’re doing (preemptive multitasking). Even an infinite loop will not block the CPU core this way, others will still get their turn. On the virtual thread level, however, there’s no such scheduler - the virtual thread itself must return control to the native thread.

Beyond virtual threads

Wasn't there something about "fibers"?
If you've already heard of Project Loom a while ago, you might have come across the term fibers. In the first versions of Project Loom, fiber was the name for the virtual thread. It goes back to a previous project of the current Loom project leader Ron Pressler, the Quasar Fibers. However, the name fiber was discarded at the end of 2019, as was the alternative coroutine, and virtual thread prevailed.

The problems with threads described at the beginning refer to efficiency alone. A completely different challenge hasn’t been considered yet: the communication between threads. Programming with the current Java mechanisms isn’t easy and consequently error-prone. Threads communicate via shared variables (“shared mutable state”). To avoid race conditions, these must be protected by synchronized or explicit locks. If errors occur here, they’re particularly difficult to find at runtime due to the non-determinism. And even if everything has been done correctly, these locks often represent a “point of contention”, a bottleneck in execution. This is because potentially many threads have to wait for the one who is currently holding the lock.

There are alternative models. In the context of virtual threads, “channels” are particularly worth mentioning here. Kotlin and Clojure offer these as the preferred communication model for their coroutines. Instead of shared, mutable state, they rely on immutable messages that are written (preferably asynchronously) to a channel and received from there by the receiver. Whether channels will become part of Project Loom, however, is still open. Then again, it may not be necessary for Project Loom to solve all problems - any gaps will certainly be filled by new third-party libraries that provide solutions at a higher level of abstraction using virtual threads as a basis. For example, the experimental “Fibry” is an actor library for Loom.

The Unique Selling Point of Project Loom

A "classic" to learn about concurrency in Java pre "Project Loom" is "Java Concurrency in Practice"

There’s already an established solution for the problem that Project Loom solves: asynchronous I/O, either through callbacks or through reactive frameworks. However, using these means getting involved in a different programming model. Not all developers find it easy to switch to an asynchronous way of thinking. There’s also a partial lack of support in common libraries - everything that stores data in “ThreadLocal” becomes suddenly unusable. And in tooling - debugging asynchronous code often results in several “aha”-experiences in the sense that the code to be examined isn’t executed on the very thread you just let the debugger go through in single steps.

The special sauce of Project Loom is that it makes the changes at the JDK level, so the program code can remain unchanged. A program that is inefficient today, consuming a native thread for each HTTP connection, could run unchanged on the Project Loom JDK and suddenly be efficient and scalable. Thanks to the changed java.net/java.io libraries, which are then using virtual threads.

The source code examples for this article are available on Codeberg

Event Collaboration And Event Sourcing

2022-06-09T00:00:00+00:00

“Events! Events everywhere!” - or so it seems. This isn’t a bad thing, not at all: Event-driven Architecture can help to make microservices architectures scalable and resilient. But there are different patterns at play that we need to distinguish. And not everything is an event. An attempt for clarification.

The term event is omnipresent in software architecture today. We hear about Event Sourcing and Event Streaming. In workshops with the subject matter experts, we do Event Storming. While events are truly everywhere, the growth in popularity seems to lead to a loss of precision in terminology. Apache Kafka becomes an “event bus”, all asynchronous messages are declared events, and consuming an event stream is declared Event Sourcing. Blurring the different concepts like this isn’t helpful for architectural discussions.

The terms Event Sourcing, Event Streaming, and Event Collaboration deserve closer examination and differentiation. Before we address them, let’s sketch the context in which we’re operating. This article is about applications that implement business processes and consist of various subsystems or services. Let’s look at an example from a presentation by Allard Bujze in figure 1. An application takes orders for goods and arranges for them to be shipped, provided that payment is made (note it’s merely an illustration - not based on any real application, and in no way intended to serve as a model for one).

Fig. 1: Services that communicate via events

Communication takes place via a bus over which messages are sent asynchronously. A very specific form of messages, in fact. The names already indicate it: Each of these messages describes something that has already taken place. We refer to these, and only these, messages as events.

👉 Definition: Event
An event is a fact. It describes something that has happened in the past.

This simple insight already has a profound impact on the software architecture. For example: There’s no arguing about an event. When I receive an event, there’s no point in validating it, I can’t doubt it: What it describes has already happened. If the receiver of an event doesn’t like it, or can’t process it, it’s always the receiver’s problem, never the sender’s.

(In practice, I’ve seen systems where the publisher of an event attempts to track the successful processing on the receiver side, and can even take further actions itself in case of an error. There were probably good intentions behind this, but it’s based on a fundamental misunderstanding of event semantics. An important motivation for using event-driven communication is to avoid such complexity!)

The above definition of the event term is very general. In the context of communication between (micro-) services, it can lead to misunderstanding, because it would also include UI events (MouseClicked, ButtonPressed), log events, or IoT data. In the context of business systems architecture, we should be a bit more specific and limit ourselves to “interesting” events related to our business domains. Let’s call these “Domain Events”.

👉 Definition: Domain Event
A Domain Event describes an interesting fact that occurred in the past and has an impact within the domain.

The Domain Event doesn’t lose its factual character at all, the more general event definition above still applies.

Event Streaming

Where do Domain Events originate? In a service, the state of a business object changes. The service persists this state change internally. If it deems the state change relevant beyond its internal context, it informs the interested outside world that the change has occurred. For this purpose, an event is published on a message bus. The technology that has become established for this is called “Log-based Message Broker”, the best-known representative being Apache Kafka. During operation, this results in a continuous stream of events to which other services can subscribe. The architecture pattern in which communication is based on publishing and subscribing to these streams is accordingly called “Event Streaming”.

👉 Definition: Event Streaming
Publishing events to a channel that other services can subscribe to.

Just like the term event itself, this is a very broad term, and Event Streaming is also used for the examples of logging and IoT data mentioned above. For the more specific case that the individual services of a business application communicate with each other via event streams, the term Event Collaboration has become established (see for example Ben Stopford’s book “Designing Event-Driven Systems”, O’Reilly 2018).

👉 Definition: Event Collaboration
Multiple components communicate using Event Streaming of Domain Events.

When a service subscribes to an event stream from another, it can use this to generate an internal representation of the sender’s business objects. Let’s take the PaymentService from our simple example. It subscribes to OrderCreated events and can internally store the interesting parts of the orders. This way it can remember for each payment which goods are to be paid for with it. In case of a query, the PaymentService can provide additional information about the payment, without depending on the OrderService at runtime.

As long as the events that the data was generated from are still available on the bus, the local representation could be discarded and re-created from the events. For readers who have already encountered Event Sourcing, this will sound familiar. But while this shares some aspects of it (deriving data from a series of events), we should not call this alone Event Sourcing. We need to distinguish two separate perspectives: the inner and outer worlds of a service. Let’s take a step back and look at the basics of Event Sourcing.

Event Sourcing

We’ve looked at the communication between the services so far. Now let’s direct our attention to the inside of a service. Let’s stay with the PaymentService, and assume that the service receives a command from the outside (in figure 2: PaymentCommand). A payment is to be marked as received. The command is subject to a check (this could be: Does the claim to which the success message refers exist?). In the picture, this is done by the CommandHandler. In the happy path, when the service can process the command, we want to record the new state. There are several ways to do this. In a typical CRUD application, perhaps an UPDATE would be made to the payment table, and the success noted in the appropriate column. This is where Event Sourcing comes into play. Instead of changing the current state directly, the CommandHandler creates an event. The service has received the information that the payment has been made, and has been able to process it and assign it to the correct payment. So now an interesting event has occurred - the money has arrived. For this, a PaymentReceived event is created. This event is stored in the Event Journal. To query the current state of a payment later, all events that refer to this payment are read and processed sequentially. This is what’s called Event Sourcing: Writing to, and retrieving the state from, a journal of events. All of this takes place within the PaymentService: Not at the level of collaboration between services, but the level of the service’s internal data store.

👉 Definition: Event Sourcing
Instead of storing the current state, a sequence of events leading to that state is stored.

Event Sourcing is usually combined with additional views in the form of “command-query responsibility segregation”, or CQRS for short. Here, the data models for reading and writing data are separated. In the combination of CQRS with Event Sourcing, the event journal acts as the write side. With each update on the write side, one or more projections are also made into other formats. This can be, for example, a relational model, which then allows us to easily retrieve data accumulated over all payments - a typical query model. Another projection could also be to generate an event for the outside world for this update, and publish it on the bus (see figure 2). The event for the outside world doesn’t have to be identical to the internal one (for a good discussion on this, see Domain Events vs. Event Sourcing.

Fig. 2: Event Sourcing and CQRS

The projection of the internal events to the event stream going out is the bridge between Event Sourcing and Event Collaboration. An internal state change within a service results in a Domain Event of interest to the outside world. It’s distributed to interested consumers via Event Streaming. However, Event Sourcing and Event Collaboration are independent of each other, as Twitter knows:

Periodic reminders: #cqrs is about separating read from write in a (sub)system ,having optimised read models and optimised write model.
It plays well with #eventsourcing .#eventsourcing is inside a (sub)system while #eventstreaming is between (sub)systems.
— ylorph (@ylorph) September 10, 2021

It seems ironic that so many people looking to implement CQRS are keen to conflate the concepts of event-driven collab with event sourcing 🙄
— Sam Newman (@samnewman) October 20, 2021

A service that uses Event Sourcing internally doesn’t have to produce events externally. Conversely, services that don’t use Event Sourcing internally (but instead use CRUD, for example) can still act as a subscriber, and even as a publisher, in Event Collaboration. In other words: Event Sourcing is a micro-architecture pattern, it takes place within a service, and for each service within a larger system, it can be decided individually whether it’s used or not. Event Collaboration (based on Event Streaming) is a macro-architecture pattern. It relates to communication between services and there are always multiple services involved.

Table 1: Event Sourcing vs. Event Collaboration
Pattern	Event Sourcing	Event Collaboration
Implemented using	Event Journal	Event Streaming
Description	Instead of storing the current state, store the events that lead to this state	Publish Domain Events on a channel that others can subscribe
Scope	Micro-architecture, inside of a service	Macro-architecture, between services
Typical implementation technology	Any database (RDBMS or noSQL), or specialized, e.g. EventStoreDB. (A log-based message broker could be used, if it has the additional capability to efficiently query by key.)	Log-based message broker, e.g. Apache Kafka, AWS Kinesis, Azure EventHub

(Don’t) Listen to Your Own Events

When looking at the overall picture, with the internal event journal and the event stream to the outside, one could ask if one of the two couldn’t be omitted. Both provide events from which state can be derived. A service could just read the external event stream and do without the internal event journal. In this case, the CommandHandler would publish each event to the external bus, and the service would subscribe to the stream itself and then produce the required internal state from the external events, as shown in figure 3. Indeed this pattern is encountered in practice. It’s sometimes referred to as “Data Inside Out”, and more often as “Listen to Your Own Events.”

Fig. 3: Listen to Your Own Events?

Before this approach is taken, the implications, both technical and conceptual, should be well considered.

Technically, Event Sourcing and Event Streaming tend to use different technologies. In Event Streaming, each event is usually read only once by each subscriber. A log-based message broker is ideal for this. In Event Sourcing, on the other hand, the state of a particular object must be efficiently recovered from the events at any time! It’s necessary to determine all events for a specific key with a simple query. Databases (both SQL and noSQL) are often a good choice for the event journal. If a log-based message broker is to be used for this purpose, only products that offer additional functions (such as virtual tables) that allow such queries can be considered.

Conceptually, consider that when the service relies on the external event stream, it gives up sovereignty over its internal data model. Instead of a model that is encapsulated within a service and isolated from the outside world, we now rely on a global data model in the external stream that is used by many. If we were developing decoupled services without events using a relational database, we probably wouldn’t come up with the idea that all services use a common database, where a data model is shared by all. Why would this suddenly be a good idea in the case of Event Sourcing?

Admitted, by definition, “Listen to Your Own Events” is also a type of Event Sourcing. From an architectural perspective, however, this particular variant of Event Sourcing has far-reaching implications that present significant challenges. If you encounter articles or blog posts describing how the authors failed with Event Sourcing, it’s worth taking a close look: Is it “classic” Event Sourcing that takes place entirely within a service, or is it the “inside out” variety that they struggle with?

Addendum 1: Types of Events

The different uses of events (for internal data management with Event Sourcing on the one hand, and Event Collaboration between services based on Event Streaming on the other hand) have caused Martin Fowler, among others, to classify different types of events. In his article on the topic he talks about three categories: event-sourcing events, notification events, and event-carried state transfer.

Event Sourcing events should take a special position here. As described above, these aren’t relevant for Event Collaboration, but internal persistence within a service. Event Sourcing events are the events that allow the state of an object to be completely recreated from a series of events.

In the collaboration area, Fowler distinguishes between event notifications (which themselves contain no data except a reference to the changed object) and event-carried state transfers.

The standard case in Event Collaboration should be event-carried state transfer. Here, the relevant data related to the event is supplied in the event. In the case of a change in the payment method, to remain in the payment area, this would be, for example, the bank details that were specified as the new payment method.

A notification event, on the other hand, only says that something has been changed. To get the associated data, the current state of the affected object must be queried from the service that published the event. This has at least two disadvantages:

Firstly, the link between the event and the data is lost if the reference sent along refers to a mutable object. It’s conceivable that at the time the event is processed at the receiver, another change has already taken place. Perhaps an order was changed but canceled shortly thereafter. Later, when the notification event has been received and the state is queried, the result would be an unexpected state (or even an error message).

Furthermore, the necessity of querying destroys a major advantage of the event-driven architecture. We want to improve the reliability of our system by reducing runtime dependencies. At runtime, the PaymentService shouldn’t depend on the OrderService to answer any requests.

Notification events should only be used in selected cases. For example, if the payload of the event would be so large that it wouldn’t make technical sense to publish it on a bus. The reference in a notification event should always refer to an immutable object. A useful use case is the generation of documents. Once the generation of a document is complete, a notification is published with the URL to a static file.

Coming back to event-carried state transfer - here it’s the developer’s or architect’s job to determine what data should be included in a meaningful way. Only actual changed data? Or the complete object that was changed? Or anything in between? Interesting thoughts on this can be found in this post by Mathias Verraes.

Addendum 2: Not Every Message is an Event

Last but not least, an article about events should probably also mention messages that aren’t events. In the architecture of service communication, we distinguish between three message types: events, commands, and queries.

Table 2: Commands, Queries, Events
Pattern	Event	Command	Query
Describes..	An event that has happened in the past	An intention to perform an operation or change a state	A request for information about the current state of one or many objects
Expected Response	None	A confirmation that the command has been executed, or an error message	The requested information

This brings us back to the beginning of the article. Don’t forget: A message doesn’t become an event just because it’s transmitted asynchronously or published on a Kafka bus! An event is an event because of its specific semantics, not because of the means of transport.

Caveat Lector!

If you work your way through articles on the internet on the topics discussed here, you’ll encounter a very liberal use of the terms. This ranges from nonsensical combinations such as “command events”, to the “Listen to Your Own Events” (anti-) pattern being presented as the only true form of Event Sourcing.
Another example for a misnomer seems to be the article Don’t Let the Internet Dupe You, Event Sourcing is Hard. While it says event sourcing in the title, here the concepts of event sourcing and event collaboration seem to be completely conflated. Don’t do that.
So before you engage in any architectural discussion about Event-driven Architecture, make sure the parties involved share the same understanding of the relevant terms. Maybe this article can help.

P.S. I help companies adopt event-driven architecture, from cutting through the terminology confusion around Event Sourcing, Event Streaming, and Event Collaboration to establishing a shared understanding across development teams and stakeholders. Whether you’re just getting started or trying to bring clarity to an existing system, I offer architecture consulting and training on exactly these topics. Feel free to get in touch.

Don't Use Await.result!

2019-02-19T00:00:00+00:00

Almost regularly I see Scala code where people program in a sequential, synchronous style and integrate an asynchronous I/O call by waiting for its completion with Await.result. But you really shouldn’t.

Let me start with a quote from Viktor Klang, the author of the Scala Futures library:

Some find it bad that Await.result is *outside* of Future. I find it bad that I added Await at all. #retrospective
— Lgd. Viktor Klang (@viktorklang) November 9, 2015

Why is Await.result bad?

If you call Await.result, you invoke a blocking operation to wait for a non-blocking one. From an efficiency point of view, this is – madness.

It’s as if Alice makes a phone call to Bob to get some information. Bob needs to get the information from Charlie and sends him a text message. While Bob continues with his daily business until he gets a message from Charlie back, Alice stays on the phone the whole time, just waiting until Bob has received the message and passes the information on to her. Obviously this is a waste of Alice’s time. For an unnecessarily long period, it keeps her from doing something meaningful.

What should I do instead?

Stay „inside“ the Future! If you call a method that returns a Future, also return a Future from your method. Execute the code you want to execute after Await.result on completion of the Future (using one of the many combinators, e.g. foreach / map / flatMap / onComplete / transform). From Akka actors, use pipeTo.

To quote Roland Kuhn: „consider every Await.result() to be a bug unless carefully justified“.

The Twitter Scala School (unfortunately) uses Await.result in their example code, but read what they write just underneath:

“In practice, you won’t write code that sends a request and then calls Await.result() a few statements later. A Future has methods to register callbacks to invoke when the value becomes available.”

“When you use Futures in real code, you normally don’t call Await.result(); you use callback functions instead.”

But I need to make sure the operation completes in n milliseconds?

Await.result has a timeout parameter (atMost), which seems a convenient way of imposing a maximum waiting time for an asynchronous operation to complete. But you should look for different ways to enforce a timeout. Outgoing calls should be wrapped in circuit breakers. You can then set the timeout on the circuit breaker. Even without circuit breakers, e.g. Finagle client lets you set a timeout, as does Play WS Client, as does akka.ask, etc. If you use Akka, use the scheduler to send a message after a given time, or use akka.pattern.after.

If it’s not a call to another system, and you don’t use Akka, you can start another Future that sleeps for a while before throwing an exception, and use Future.firstCompletedOf. This is not great, but still preferable to Await.result, as at least you don’t block the calling thread, which may be one of a limited pool for dispatching HTTP requests or the like. And from a type perspective, as you’ll still have a Future as the result of your operation.
If you need this often, you might want to implement a TimeoutScheduler (I haven’t used it myself, but will try it next time I need to timeout Futures).
I’d love to hear other suggestions, what do you use in your code to enforce timeouts?

So maybe I should just not use async clients for HTTP calls, DB access etc. at all, just use blocking ones, to keep my code simple?

No! No no no! Asynchronous I/O is the way to go, for scalability and efficient resource usage. Blocking I/O is a waste of resources. Never block! Async all the things! Seriously. See for example the presentation Need for Async: Hot pursuit for scalable applications.
To add to that, instead of „wrapping“ a non-blocking call in a blocking one (which you should really never do), you should do the opposite! If you have an intrinsically blocking call (e.g. JDBC), you should wrap it in a Future. This way, you can make sure it’s executed in a controlled environment, by providing a separate ExecutionContext dedicated to blocking I/O operations.

But my use case is much more complicated..

The observations I made so far in my customers’ codebases where just async calls to external systems, wrapped in Await.result to make them appear synchronous. You may have different scenarios, where you have a mix of synchronous and asynchronous operations, and some state you need to track, and the need to spawn many Futures to do things concurrently, etc. In this case you might want to move to a different abstraction altogether, possibly Akka actors. If you feel you really must use Await.result in your code, you should post an example in Scala Users and get some feedback there - I’m quite sure people will come up with better alternatives.

There is no rule without exceptions.

I can think of only two legitimate use cases of Await.result:

In tests

That’s ok, although for example with ScalaTest 3 or later you shouldn’t even have to use it there.

If you need to override a method of a superclass or a trait you must implement (and consequently must provide the required return type).

Then you don’t really have a choice, do you? But before falling back to Await.result you should double-check if there isn’t a better way.

If you have control over the superclass/trait, change the signature to return a Future.
If you don’t, do you really have to implement that particular method, or is there an alternative (e.g. in Spring MVC change to returning a DeferredResult)?

If there is a need to go from asynchronous to synchronous, there is a mismatch between framework philosophies. You should attempt to replace the synchronous / blocking framework with an asynchronous / non-blocking one.

When you really have to, for example because you have to run on a pre-3.0 Servlet container that doesn’t provide any asynchronous support, make sure to make an explicit choice where and why you call Await.result. In this synchronous, thread-per-request servlet scenario, pass the Future all the way up to the controller and call Await.result only in the very end to return the response from the controller method. This way it becomes clear what demands the blocking, and so you can easily and quickly refactor it when you update to a better HTTP layer.

If you'd like to learn Scala and learning from a book is what works for you, I recommend to get one of these two:

	Programming in Scala by Martin Odersky et al.
	Programming Scala by Dean Wampler

Java, Scala, Kotlin and .. Skiing

2017-05-21T00:00:00+00:00

This is not actually about winter sports. Bear with me.

Many years ago, when I was at Edinburgh University, a fellow student convinced me to go on a weekend trip with him to the Cairngorms, for snowboarding. I had never been snowboarding before in my life, and in many ways it was a frustrating experience. Most of the weekend I spent sitting at the side of the slopes, waiting for the pain to go away. But there were some moments, some great turns I managed, some beautiful, easy slopes where I felt there could actually be something to it, and I got hooked.

So next winter, I went to Switzerland to learn snowboarding properly. It was a university organized trip, with some skiers and two groups of snowboarders: beginners and advanced. I joined the beginners group. My one weekend of previous experience had already given me a head start over the ones that had never even had a snowboard on their feet before. So I felt impatient and always looked out for the ones from the other group, and tried to imitate what they were doing. I mostly failed, though, so quickly I grew somewhat annoyed about the whole thing. Turned out I was not the only one. There were some experienced skiers in my group, who were curious about the snowboarding alternative. But some of them, after only one or two days, regretted their decision and just went back to skiing.

So what does all this have to do with programming? We’ll come to this in a second, just one more thing. So when I tried, with only two days of experience, to copy the relaxed, seemingly effortless riding style and jumps from the “pros”, I fell a lot. A lot. It hurt. I blamed it on the snowboard, the mountains, and not least on the teacher, and basically told him that this whole course was shit and snowboarding probably not for me. He listened to me, calmly, and said: “The guys you’re looking at have been riding for years. Because you tried to ride like that once and it didn’t work out, doesn’t mean it never will. What did you expect? That you don’t have to practice, don’t have to learn, just get on the board and do immediately what took them a long time to achieve? I can see you have talent, but you’re too impatient. It’s a journey, not a flip of a switch. Give it time.”

I followed his advice, and went on to be a somewhat solid boarder. I had a couple of deep powder snow rides in my life that were so amazing, my body still releases endorphins when I think of them today.

But on to the real topic of this post:

Scala is snowboarding. If you try it out, give it some time. If you look at the source code of some library you use and don’t understand it, don’t get frustrated. The people who wrote it are no more or less smart than you. It probably took them a lot of practice to get there. If you keep at it, your understanding will grow and you will see a lot of things under the surface, that you didn’t notice at first sight.

Java is skiing. The experienced skiers that try snowboarding are especially prone to frustration, because it makes them feel stupid. You already know how to get down the mountain, probably very fast, too. Maybe you even go down black slopes with ease. But on a snowboard, you are set back to beginner level. A slope that would be no challenge to you at all on skis, suddenly becomes a struggle. It feels like the snowboard is just trying to humiliate you. It isn’t. You have to let go. You have to unlearn some things you learned, because snowboarding is different from skiing. Don’t try to force your skiing moves on the snowboard. Its patience will outlast yours.

A skier trying to snowboard is like an experienced Java programmer looking into Scala. You think you know how to do it all, after all you’re a skillfull software engineer. But all the things you thought you knew don’t work as you want them to in Scala. If you don’t get into a Scala mindset, and just keep trying to use your ifs, fors and returns as in Java, the easiest things become ridiculously hard, and suddenly you’re not able to write a simple class anymore. Give it time. Be prepared to unlearn. Embrace the snowboard’s unique characteristics, don’t fight them.

Kotlin is carving skis. Much more modern that the old straight ones, and you can carve like a snowboarder. On the slopes, it might be just as well. But if it goes into deep powder, you still have to jump at every turn like a skier, you don’t have the amazing gliding experience of the board rider that seems to fly over it.

Deep powder snow is Functional Programming.

Skiing has been around much longer than snowboarding, and will probably never go away. Maybe a snowboarder will always be a bit of an outsider. But when he’s gliding on top of the deep powder snow, he just smiles, being happy that he didn’t miss out on this, and he never wants to go back to skiing.

Clojure looks weird, but sometimes also very elegant. Based on Lisp, it has really old roots. Clearly it’s Telemark skiing.

Google/Android is the International Ski Federation. They never quite warmed up to snowboarding, but happily embraced carving skis.

If you'd like to learn Scala and learning from a book is what works for you, I recommend to get one of these two:

	Programming in Scala by Martin Odersky et al.
	Programming Scala by Dean Wampler

10 More Scala Features Most* Java Developers Love

2017-02-07T00:00:00+00:00

(*) Please don’t take the title too seriously. I have no empirical evidence that it is actually the case (that most Java developers love these features). I know some do, me included. Well, honestly, I just kind of liked the title of the first blog post when I wrote it, and decided to stick with the “love” theme.

In my first blog post, 10 Scala Features Most Java Developers Love, I assembled a top 10 list of Scala features I wouldn’t want to miss, and that I found more or less universally liked in conversations with other Java developers. There were a few items back then that would have deserved to also be on the list, and some more that have been pointed out to me after the post was published. So I decided to do this sequel.

11. The REPL

Scala comes with a Read-Eval-Print-Loop, short REPL. You can quickly start an interactive Scala shell on the command line and try out any code snippet you like. If you need additional libraries, sbt console will give you a REPL that will have all the library dependencies of your sbt project readily available.

You can even try the Scala REPL online, with https://scastie.scala-lang.org or https://scalafiddle.io.

Update: Java 9 will also have a REPL called JShell, see https://openjdk.java.net/jeps/222.

12. Imports

Scala’s imports have some additional flexibility compared to Java’s. Firstly, you don’t have to put all imports at the beginning of the file, you can import something right before you use it. Why is this useful? Because now you can limit the scope of the import - it will only be imported within the current block, and not pollute any larger namespace.

You can rename classes on import, which will be loved by anyone who’s used java.sql.Date and java.util.Date in the same file:

import java.sql.{Date => SDate}

As * is a valid identifier in Scala, it can’t be used as a wildcard. Use the underscore to import all classes of a package:

import java.sql._

You can combine the wildcard and renaming to import all classes of a package except one:

import java.sql.{Date => _, _}

13. Tail Call Optimization

Java does not have any sort of compiler optimization for tail recursion, which is quite the drawback if you want to program in a functional style. A textbook example for a recursive function is calculating the factorial of a natural number:

def factorial(i: Int): Long = {
  @tailrec
  def fact(i: Int, accumulator: Int): Long = {
    if (i <= 1) accumulator
    else fact(i - 1, i * accumulator)
  }

  fact(i, 1)
}

In Java, this implementation will quickly lead to a StackOverflowError as you try it with bigger numbers. The Scala compiler however will, just like FP language compilers do, convert it to a simple loop, it will run just as efficiently as a for loop in Java. The optional @tailrec annotation tells the compiler that you believe it is in fact tail recursive, so the compiler will warn you if it can’t do any tail call optimization.

Again, to me this is a major drawback in Java. It’s quite the mystery to me why the Java compiler doesn’t optimize tail recursive calls. How can you live without?

14. Compile to JavaScript

Yes, you can compile Scala to JavaScript and run it in any web browser. This is provided by a compiler plugin maintained by the ScalaJS project. It’s absolutely awesome, try it out!

15. “Operators”

In Scala, you can use pretty much any symbol in method names - so that thing that looks like an operator (defined in the language specification) to you is probably just a method (defined by some library developer in a regular Scala class).

For example Ordered, mentioned about in the section about traits. It’s just methods:

trait Ordered[A] {
  def < (that: A): Boolean = ...
  def > (that: A): Boolean = ...
  def <= (that: A): Boolean = ...
  def >= (that: A): Boolean = ...

Scala has a simple convention: If a method has one parameter, you can omit the dot and parentheses - so you get a nice infix notation:

1.+(2)   // 1 + 2
1.<(2)   // 1 < 2

Another example is to use the method ! to send a message to an actor in Akka. Which translates to tell in the Java API - but does travelAgent ! BookFlight not read 10x better than travelAgent.tell(BookFlight, self())? With the added bonus that you can use ? for the ask method. C++ programmers will look at Scala code and say, “sure, operator overloading”, but it really isn’t - it’s just methods, and you name them any way you see fit.

16. Tuples

While the collections are for elements of the same type, tuples are sequences of fixed length, of values of possibly different types. This is such a basic concept and it feels so natural to group values in this way, once you’ve gotten used to it, it’s rather puzzling how Java developers can live without it, and how a number of proposals to include them in the language have been rejected.

To create a tuple, just write the values in parentheses.

scala> val tup = ("intAndDouble", 1, 1.9)
tup: (String, Int, Double) = (intAndDouble,1,1.9)
scala> tup._1
res0: String = intAndDouble
scala> tup._3
res1: Double = 1.9

17. Nested Methods

You can define a method within a method, and thus make it private to the enclosing method.

A classic example is a Fibonacci function, that could look something like this:

def fib(n: Int): Int = {
  def innerfib(a: Int, b: Int, n: Int): Int =  if (n > 0) innerfib(b, a+b, n-1) else a
  innerfib(0, 1, n)
}

18. Named and Default Arguments

In Scala, every method argument can be referred to by its name by the caller. And for every argument, you can provide a default value, thus making the argument optional.

case class Time(hours:Int = 0, minutes:Int = 0)
scala> Time()
Time(0,0)
scala> Time(9)
Time(9,0)
scala> Time(minutes = 15)
Time(0,15)
scala> Time(hours= 10, minutes = 15)
Time(10,15)

So instead of overloading methods or constructors with all possible permutations of the argument list, just have one and provide defaults, and the caller can decide which ones to override.

19. Multiline String Literals

In Scala, you can easily create a multiline string by using a “triplequote”, i.e. """. For example:

val s = """This is
           a multiline
           String"""

This is already great, but as this takes your input very literally, the indentation tabs or spaces on the left will be part of your quoted string. So it gets even better: You can use |and stripMargin to get a nicely formatted multiline string:

val query = """SELECT *
              |FROM MYTABLE
              |WHERE id = 781""".stripMargin

I’m not the only person missing this feature, see for example http://blog.jooq.org/2015/12/29/please-java-do-finally-support-multiline-strings/.

Update: It seems we’ve been heard, and it’s going to be in Java 12: https://openjdk.java.net/jeps/326.

20. No Checked Exceptions

This is a bit of the odd one out, as it’s about a “feature” that Scala doesn’t have: In Scala, there are no checked exceptions. I’m not going to discuss the reasons why checked exceptions aren’t great here, as it has been done at many other places (e.g. http://wiki.c2.com/?TheProblemWithCheckedExceptions). If you’ve done some programming with higher order functions, you’ve probably already discovered for yourself that checked exceptions are not the solution.

Fin

This is it, or rather, I’ll leave it at that, 20 is a good number. Of course there are many other things I personally find extremely valuable in Scala, but not all of them might be as accessible and obvious to the outsider as the twenty listed here.

Unfortunately discussions about Java vs. Scala often quickly escalate into flame wars about Object-Oriented vs. Functional Programming, sbt vs. Maven vs. Gradle, Haskell vs. Go, and the importance of Category Theory.

I hope, and that’s the spirit these two posts have been written in, that people are able to see this whole other side to it, that often gets buried in the more dogmatic exchanges: If you are - like me - used to developing in Java, there are so many little things in Scala that just make your everyday day life easier. By saving you from typing boilerplate, providing a powerful API, or giving you that little extra flexibility.

If you'd like to learn Scala and learning from a book is what works for you, I recommend to get one of these two:

	Programming in Scala by Martin Odersky et al.
	Programming Scala by Dean Wampler

Things I Wish I Knew When I Started Building Reactive Systems

2017-01-31T00:00:00+00:00

This is a summary of the talk „A Pragmatic View of Reactive“ on ScalaDays Amsterdam. If you prefer watching a video, there’s a recording on YouTube. Or if you prefer German, there’s an even longer German version of this on Jaxenter.

The term reactive (as in reactive systems, or reactive architecture) is defined in the Reactive Manifesto. It describes systems that are so elastic and resilient that they are always responsive, and they achieve this through asynchronous message passing. Now this is a fine definition, but as manifestos go, it’s not a pragmatic guide for developers. When you attempt to build reactive systems coming from the world of Java web and enterprise development, you’ll stumble across some fundamental differences and might wish someone had told you earlier. Unless you read this blog post, of course, because I’m going to let you in on four things you should know.

1. You’ll be using a different concurrency model.

On the JVM, our basic concurrency model is the Thread. Why? We run on multi-threaded environments, and the JVM threads map to native threads, and that, at the time people came up with this, seemed a pretty good idea. Before multi-threading, there was multiple processes. But starting a new process for anything you want to do concurrently is rather heavyweight, plus you need Inter-Process Communication to exchange data between those processes. Threads were introduced as “light-weight processes” that have access to the same memory space, for easy data exchange. There are some problems with this, though.

First of all they are not that light-weight after all. Each thread you start will take 1MB of memory (that’s the default thread stack size on a 64 bit JVM). The maximum number of threads is limited by the operating system and may be your scalability bottleneck, for example if you need to handle thousands of HTTP requests concurrently. And the cost of switching between threads, the context switch, has become relatively high in modern multi-core CPUs with non-uniform memory access, compared to just executing the code of a running thread.

If this wasn’t enough, the shared memory programming model is also not exactly ideal. Concurrent programs with shared mutual state are prone to race conditions, which are notoriously hard to debug. Avoiding this by locking and synchronization can lead to deadlocks, or at least to contention that will hurt performance.

(Slide from John Rose’s presentation JVM Challenges)

So, as JVM architect John Rose said on JFokus 2014 - Threads are passé. Not that they are going away, but as an API for us developers, we need something else, something that gives us sub-thread level concurrency.

Examples for this are the Play web framework, the vert.x framework, the Akka actor toolkit, Project Reactor, and Lagom. All of these have in common that they multiplex tasks (depending on the framework named actions, verticles, actors..) on just a few threads, and thus get by with much fewer context switches. Akka also eliminates shared mutual state, by encapsulating state in actors that only communicate with immutable messages.

In contrast to this, the Servlet API from JEE is based on the thread-per-request model, where each request will grab a thread exclusively while being processed.

The reactive, sub-thread-concurrency of course scales much, much better - see for example “Why is Play so fast” for more background on this.

But just be aware of a pitfall: Some things you might be used to actually rely on thread-per-request. Everything that uses a ThreadLocal to store its data. ThreadLocal in reactive applications is definitely an anti-pattern, as every thread is shared by many tasks (actors, verticles..). slf4j’s MappedDiagnosticContext is an example for ThreadLocal usage, as are Spring Security or Hibernate. All this may not behave as you expect, so you need to let go of it and embrace truly reactive tools, or build workarounds.

You are going to use sub-thread level concurrency. Understand and embrace this.

2. You’ll be using asynchronous I/O (or if you keep using synchronous I/O, it’ll need special treatment).

What’s worse than using too many threads? Blocking threads by using synchronous I/O. In the JavaScript world asynchronous I/O is the standard. node.js showed how you can build efficient server applications running on just a single thread with purely asynchronous I/O. It makes use of the capabilities of modern hardware and operating systems, where I/O is handled by the respective controllers and does not need to use CPU threads.

You’re probably used to doing blocking I/O, using java.io.File, or some synchronous HTTP client. What happens there? While waiting for the result of the operation, the thread will be blocked. As explained in the previous section, a thread is a valuable resource, though. It could continue and do something else, instead of making the CPU switch to another thread. This is particularly bad when you are using a reactive architecture, which relies on the tasks to yield control after a short period of time, in order to achieve the desired effect that few threads handle many, many tasks. You certainly don’t want to block one of those threads - you’ll exhaust your thread pool quickly. So just use asynchronous I/O for everything.

Everything? Well, there are certain cases where you might not be able to. JDBC is an example for that. Non-blocking JDBC is pretty far in the future, so for now, you’re stuck with blocking JDBC. The only way you can integrate this properly into a reactive system is to keep it away from the rest. You need to define a separate thread pool for synchronous I/O, so that your threads for CPU bound work, which process the tasks, are not affected. All reactive frameworks have some facility for this. In Play and Akka you can define separate dispatchers, in vert.x you have worker verticles, etc.

You don’t want to use blocking I/O. Use non-blocking I/O, and if you really can’t (e.g. if you need to use JDBC), then isolate blocking calls by using a separate thread pool.

3. There’s no Two-Phase-Commit

This is something that could easily fill multiple blog-posts alone, so we can only touch the surface of this.

What if we don’t only have a database access, a JDBC call where we do a select as in the previous example? Look at this little code snippet:

public class GreetingService {
  @Inject
  private JmsTemplate jmsTemplate;
  @PersistenceContext
  private EntityManager entityManager;

  @Transactional
  public void createGreeting(String name) {
    Greeting greeting = new Greeting(name);
    this.entityManager.persist(greeting);
    this.jmsTemplate.convertAndSend("greetings", greeting);
    // ...
  }
}

Here, we have two transactional systems, a message queue and a database, within one transaction. In this case (this is some Spring Framework example code) that’s really easy: I have to define a transaction manager somewhere. If I have a transaction manager that’s capable of handling distributed transactions, this code is all I have write to get the “all-or-nothing” logic.

How could I achieve this in an asynchronous system, where I even want avoid blocking I/O? The answer is: You don’t want to.

(Slide from Pat Helland’s presentation Life Beyond Distributed Transactions)

If you can, avoid it. Think of the reactive traits - we want to be elastic and resilient. The whole concept of a synchronous 2-phase-commit is not made for that. In the Oracle Transaction Manager documentation it says: “the commit point should be a system with low latency and always available“. Because it will easily break if one of the involved parties isn’t. It doesn’t account for the ability of the systems to fail. And the unavoidable latency will hold you back as well. It’s a natural point of contention and failure. If you look at existing highly scalable systems, people don’t use distributed transactions.

I’ve seen things like the above snippet, a message queue and database access, in real world projects. It’s not the worst use case for a distributed transaction, but also an example for a two-phase commit that could be avoided. The goal of the transactional bracket is to provide “all-or-nothing” - you want either both things to complete successfully, or none of them. But here, you don’t have any control over the receiving end of the queue. The processing of the message at the receiving end might still fail. This example is really about system reconciliation - you want the system state at the other end of the queue to catch up with your database eventually. But this could be handled in a completely asynchronous fashion, without the need for any 2-phase-commit.

If you encounter a requirement for a distributed transaction, the first step should be to challenge it. Actually, the second and third step, too. Try to avoid it. Challenge the requirement: Is the “all-or-nothing” really necessary, or did someone just think it’s easy to do? The best solution is to define the business processes so that distributed transactions are not required. Often, this is not even about changing the business process, but about discovering that it’s not really a business requirement and only got in there because some assumptions were made, e.g. that a central, relational database would be used.

Still, I can’t rule out completely that you might encounter a situation where you genuinely need the “all-or-nothing” semantics. But you can still avoid a 2-phase-commit. The basic idea behind this is that you can achieve the same effect with asynchronous messaging. A principal explanation of this is given in the paper “Life Beyond Distributed Transactions” by Pat Helland. (A really good paper, by the way. Quote: “Grown-Ups Don’t Use Distributed Transactions”. And “Distributed transactions don’t scale, don’t even try to argue with that, just believe that.”).

It’s not trivial, though. You need “at-least-once delivery” for your messages (btw. that’s not the standard if you use plain Akka, which only gives you “at-most-once delivery”. But extensions to provide “at-least-once” are available). Also, as you can’t guarantee message order, you need idempotent messages, or some way to handle out-of-order messages and multiple deliveries. And lastly, you have to have some “compensation ability”. I.e. you have to have an idea of a tentative operation. Think of a hotel reservation which you either have to confirm (possibly by payment) within a certain time, or it’s cancelled. The reservation is the tentative operation, and it’s either committed or rolled back. So there’s no mechanical rewriting of 2-phase-commits into asynchronous messaging - it will affect your modeling. You’ll have to think about the messaging you do, and about your process. But it should be possible.

An application of this general approach is the Compensating Transaction Pattern, or Saga Pattern. In this pattern, you start a Saga, and each of the steps has a counterpart that will reverse the operation.

(Slide from Caitie McCaffrey’s presentation Applying The Saga Pattern)

So the transaction will be to book the hotel, and the compensating action would be to cancel the hotel. You book the car, you cancel the car, you book the flight, you cancel the flight.

Again, implementing this is not trivial. This is not “built-in” in for example Akka. You need to implement a Saga Coordinator which takes care of recording these actions, and makes sure that either the whole Saga is successfully completed, or the appropriate compensations are executed. It’s needs a durable log, the Saga Log. And again you need “at-least-once-delivery”. You must guarantee that the compensating message will be delivered at least once, otherwise you can’t guarantee the all-or-nothing rule.

There is much more to be said about this, but we’ll stop here. The bottom line is: Distributed transactions are a source of contention and of failure, you should definitely avoid them. Local transactions are fine, and the Compensating Transaction Pattern is a pragmatic solution for having an “all-or-nothing” approach in a distributed world.

Another article I recommend on this topic as a whole is “Distributed Transactions: The Icebergs of Microservices”.

Don’t use distributed transactions.

4. There’s no Application Server

Reactive applications don’t use application servers. Reactive applications are deployed as standalone applications. (I used to call this “containerless”, because of servlet containers. But now if I say containerless, people think I argue against Docker. It’s not about containerization and Docker (which are fine), it’s about servlet containers and application servers (which are not)).

So what’s the issue with application servers? From a technical point of view, if you use a Java EE application server (or servlet container - I use the terms interchangeably in this section, as the criticism applies equally to both), you’re going to use the Servlet API. This API is - barring some recent additions that haven’t really become popular so far - a synchronous API. The Servlet API is built for the thread-per-request model, which puts unnecessary limits on the scalability (see the first section above).

In case you missed the memo... App Servers / Service Containers are dead. OS Containers + Container-less Apps are the future.
— James Ward (@_JamesWard) September 12, 2014

Another reason is the lack of benefit we get from an application server. It adds complexity and costs. I have to buy it, I have to install it, I have to operate it. What does it give me? Some APIs.

The original idea was to have a container where I can put in a number of services - I put in a couple of .wars or .ears for different applications. Many people don’t use them that way. The value of isolation (of isolating your applications so that a crash of, or high load on one, will not affect others) is higher than the value of being able to deploy a couple of applications on one server.

What people do is, they run exactly one application per application server instance. You’d rather start a couple of Tomcats with one application in it, than one Tomcat with ten applications in it. If you only deploy one application per server - then, what the server really becomes is just a library that you add to your application! Different is only the packaging. Instead of delivering a .war, you could just bundle the “server” with your application and deliver a .jar. (This is what Spring Boot does. Spring Boot just gives you a standalone .jar that you can run, and it just puts the Tomcat (or the Jetty, or the Undertow) in there). Some good reading on this is “Java Application Servers Are Dead”: Part1, Part2, Presentation.

So, if it’s just a library, instead of bundling what used to be the server as a dependency, you could just as well use any other library that handles HTTP. That’s what Play does, it relies on the asynchronous netty library, skipping the Servlet API altogether.

Application servers have a lot of tooling built around them, and operations people tend to like that. But there are other tools nowadays that you can use to conveniently deploy small services and operate them, service orchestration tools such as Kubernetes, Docker Swarm, or ConductR.

tl;dr When you build a Reactive System

You’re going to use sub-thread level concurrency
You want to use asynchronous I/O. If you can’t, at least isolate any synchronous I/O (JDBC) from the rest.
You don’t want to use distributed transactions, they’re fragile, they’re points of contention.
You don’t want to use an application server.

10 Scala Features Most* Java Developers Love

2015-11-22T00:00:00+00:00

(*) “Most” in this case meaning: Of those I have met and have talked to about this. I’m not actually aware of an empirical study supporting this. But I still think it’s a fair claim. 😉

Some Java developers seem to be intimidated by Scala. They get hung up on some possibly rather obscure feature, and from that conclude that the language must be a complicated maze you can only get lost in. There are so many features in Scala, though, that are so easily accessible, and that really just make the developer’s life easier. This is my list of 10 features that are easy to understand and use, yet very powerful. I presented it to some groups of Java developers throughout 2014, and have been wanting to convert it into a blog post ever since. Now, with some delay, here it is, I hope you enjoy reading it.

1. Functions

This is about Scala features, not about the functional programming paradigm in general, so I’m not going to dive into which benefits the functional approach has in this post. Things you might want to look out for are how referential transparency makes it easier to reason about the correctness of programs, and how immutable data structures help you to stay sane when developing concurrent software.

A function in Scala is a “first-class value”. Like any other value, it can be passed as a parameter or returned as a result.

A value can be of a function type
Functions can be passed as arguments
Functions can be returned as results

(Functions which take other functions as parameters or return them as results are called higher-order functions.)

Generally, a function is a mapping from values of one domain to another. You can write them as function literals:

val f = (x:String) => x.length – the type of f is String => Int.

val sum = (x:Int, y:Int) => x + y – the type of sum is (Int, Int) => Int.

Or you can use methods as functions.

Let’s look at an example for the usefulness of functions. I found this one in a PDF of a draft edition of “Programming in Scala” on the internet. I think it never made it into the printed edition, so hopefully the authors don’t mind me stealing it. So let’s say we have the following definitions (written in Scala method syntax for readability, so don’t be irritated they look slightly different from the function literals above):

A function to sum integers between a and b

def sumInts(a: Int, b: Int): Int = if (a > b) 0 else a + sumInts(a + 1, b)

A function to sum the squares of integers between a and b:

def square(x: Int): Int = x * x
def sumSquares(a: Int, b: Int): Int =
if (a > b) 0 else square(a) + sumSquares(a + 1, b)

And a function to sum the powers of 2 of integers between a and b:

def powerOfTwo(x: Int): Int = if (x == 0) 1 else 2 * powerOfTwo(x - 1)
def sumPowersOfTwo(a: Int, b: Int): Int = if (a > b) 0 else powerOfTwo(a) + sumPowersOfTwo(a + 1, b)

These functions are variants of sum of f(x) for different values of f! We can extract the common code by defining a function sum:

def sum(f: Int => Int, a: Int, b: Int): Int =
if (a > b) 0 else f(a) + sum(f, a + 1, b)

The type Int => Int is the type of functions that take an argument of type Int and return results of type Int. So sum is a function which takes another function as a parameter.

Using sum, we can now rewrite our three summing functions:

def sumInts(a: Int, b: Int): Int = sum(id, a, b)
def sumSquares(a: Int, b: Int): Int = sum(square, a, b)
def sumPowersOfTwo(a: Int, b: Int): Int = sum(powerOfTwo, a, b)

2. The Collections Library

Scala offers Sequences, Sets and Maps in different flavors. Immutable collections are the default! Modifications are not applied in place, but a new collections is created (using structural sharing).

Scala collections have a huge number of higher-order functions already built-in, so you can do powerful transformations in a few lines of code.

map – apply a function to each element of the collection
foldLeft/foldRight – repeatedly apply a function to the next element and the result accumulated so far
filter – remove the elements that do not match the predicate
take/drop – take or drop a number of elements
takeWhile/dropWhile – take or drop elements until a condition is met
contains – check if the collection contains an element
zip – combine two sequences to a sequence of pairs
slide – divide a collection using a sliding window
groupBy – create a map grouping values by keys

And of course mkString – format the collection to a String, separating the elements with a given separator. I have needed this (and programmed it myself) in Java countless times..

$ List(1,2,3,4,5).mkString(", ")
1, 2, 3, 4, 5

As the use of immutable collections (also sometimes referred to as persistent collections) is encouraged, you might wonder how to add or remove elements. It’s simple – the methods for this will give you a new collection, leaving the original one unchanged:

$ val v1 = Vector(1,2,3)
Vector(1, 2, 3)

$ v1 :+ 4
Vector(1, 2, 3, 4)

$ v1
Vector(1, 2, 3)

3. Traits

Just like in Java, any Scala class has exactly one superclass. And like a Java class can implement multiple interfaces, a Scala class can implement multiple traits. But as opposed to Java interfaces, traits can also contain implementations and state! A typical use case for this is the use as mix-ins for cross-cutting concerns. Supposed I need to inherit from Observable to implement a cross-cutting concern..

class MySpecificModel extends Observable {
  ...
}

.. but I also want to inherit within my domain model

class MySpecificModel extends MyGeneralModel {
  ...
}

How to adhere to both? In Java, interface inheritance is of course the solution (or would be, if Observable was an interface):

class MySpecificModel extends MyGeneralModel implements Observable {
  ...
}

But now we would have to implement addObserver, notifyObservers, .. over and over again. What about “Don’t Repeat Yourself”?

In Scala, we can mix-in traits, including implementation:

trait Observable {
  def addObserver = { .. implementation ..}
  def notifyObservers = { .. implementation ..}
}

class MySpecificModel extends MyGeneralModel with Observable {
  ...
}

Another great use case for traits with implementation is to provide “rich interfaces”. The trait Ordered for example defines the methods <, >, <=, >=.

If it were a Java interface, the programmer would have to provide implementations for all four of them. In Scala, implementations for these are provided in the trait itself, and you only need to implement a single method (compare).

4. Type Inference

In Scala, if you don’t state the type of a value or function, the compiler will attempt to infer it. This does not work everywhere, you still have to state the types for method parameters and some other places, but even so, it saves you a tremendous amount of typing. And more importantly, it frees your source code from a lot of boilerplate and makes it much more readable. Without sacrificing strong typing and compile-time type checking.

object Inference {
  val x = 1 + 2 * 3
  // the type of x is Int
  val y = x.toString()
  // the type of y is String
  def succ(x: Int) = x + 1
  // method succ returns Int values
}

5. Optional

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.. (Tony Hoare)

In Java there is no way to tell from the API if a method might return null or not. This leads to excessive null checking – or NullPointerExceptions. In Scala, you can state explicitly that a result may not always be provided.

scala> val m = Map(0 -> false, 1 -> true)
scala> m.get(0)
res0: Option[Boolean] = Some(false)
scala> m.get(5)
res1: Option[Boolean] = None

This gives you the opportunity to nicely compose calls, even if you might encounter missing values. You can chain calls that return optional values by applying higher-order functions.

  scala> val m2 = Map(false -> "n", true -> "y")
  scala> m2.get(true).map(x => x.toUpperCase)

6. Better Value Objects With Case Classes

Value objects are objects that serve as a structured value, to encapsulate domain data (a.k.a. data transfer object, record, …).

What you want in every Java class that’s used in that way is equals(), hashCode() and toString() methods based exclusively on all of the fields’ values. Of course you need a way to set the values (ideally only once, in the constructor, to create an immutable object), and a way to read them. So a typical Java class for an immutable value object might look like this:

public class Product implements java.io.Serializable {

  private static final long serialVersionUID = 5120302881189308206L;

  private final String name;

  public Product(final String name) {
    this.name = name;
  }

  public String getName() {
    return name;
  }

  @Override
  public boolean equals(final Object other) {
    if (other == null) {
      return false;
    }
    if (this == other) {
      return true;
    }
    if (!(other instanceof Product)) {
      return false;
    }
    final Product otherProduct = (Product) other;
    return new EqualsBuilder().append(name, other.name).isEquals();
  }

  @Override
  public int hashCode() {
    return new HashCodeBuilder(177, 47).append(name).toHashCode();
  }

  @Override
  public String toString() {
    return new ToStringBuilder(this).append("name", name).toString();
  }
}

At some point during the development, you realize that you’d like to capture more information then just the name. So you add another field. No problem, all you have to do is:

Add the new field to list of instance variables
Add the new parameter to the constructor arguments
Assign the constructor argument to the instance variable
Create a “getter” method for the new field
Add the new field to the equals() method
Add the new field to the hashCode() method
Add the new field to the toString() method

In Scala however, the same class would be written like this:

case class Product(name: String)

Yes, that’s all. To add another field to it, you have to follow these steps:

Add the new field to the parameter list

No, I didn’t forget any. It’s really just one. The case keyword indicates that this is meant to be a value object, and the compiler will take care of the methods we need, and generate them to use the field values. By making working with immutable value objects convenient and easy, Scala encourages a functional programming style that relies on immutable values – which is good!

By the way, as a little bonus, you also get a copy method…

case class Customer(name: String, address: String, city: String)

val customer1 = Customer("Hans Meier", "Lehmweg 12", "Hamburg")
val customer2 = customer1.copy(name = "Ida Meier")

… and you can use them in pattern matching (see below)!

customer match {
  case Customer(_, _, "Hamburg") => local
  case _ => guest
}

So with case classes you have much less code to maintain, you don’t have to remember to make fields final, and you no longer need Apache Commons or Guava libraries for EqualsBuilder, HashCodeBuilder and ToStringBuilder.

7. Pattern Matching

In Java, you have switch statements:

int month = 10;
switch (month) {
    case 1:  return "January";
    case 2:  return "February";
    case 3:  return "March";
    case 4:  return "April";
    ...

In its simplest form, a Scala pattern match will look pretty much the same, only it will yield a value:

val month = 10;
 month match {
   case 1 => "January"
   case 2 => "February"
   case 3 => "March"
   case 4 => "April"
   ...
}

Plus, you can also match on types…

something match {
       case a: Int => "It's an int"
       case b: String => "It's a string"
       case _ => "It's neither an int nor a string"
}

… and sequences …

someSeq match {
       case head +: tail => "more than one"
       case head +: Nil => "one"
       case Nil => "empty"
}

… and case classes (see above) …

customer match {
       case Customer(_, _, "Hamburg") => local
       case _ => guest
   }

… and bind variables in matches …

customer match {
       case Customer(name, _, "Hamburg") => s"$name is a local"
       case Customer(name, _, city) => s"$name is a visitor from $city"
}

… and match alternatives …

month match {
       case 3 | 4 | 5 => "Spring"
       case 6 | 7 | 8 => "Summer"
       ...
}

… and use guards in matches …

case class Day(month: Int, day: Int)
   d match {
       case Day(3,x) if x > 20 => “Spring”
       case _ => "..."
   }

… and match regular expressions.

val date = """(\d\d\d\d)-(\d\d)-(\d\d)""".r<

To extract the capturing groups when a Regex is matched, use it as an extractor in a pattern match:

"2015-11-23" match {
      case date(year, month, day) => s”The year is $year."
    }

To check only whether the Regex matches, ignoring any groups, use a sequence wildcard:

"2015-11-23" match {
     case date(_*) => "It's a date!"
   }

So, pattern matching is a bit like switch statements… just infinitely more powerful!

8. Java Interoperability

You’ll not be missing any third party library that you so heavily relied on in Java – you can use any Java class in Scala:

val url = new java.net.URL("http://scala-lang.org")
val uuid = java.util.UUID.randomUUID().toString

You can even use Scala to implement Java interfaces…

class MyRunnable extends Runnable {
  def run(): Unit = println("i am a runnable")
}

new Thread(new MyRunnable).start()

… and extend Java classes:

class MyThread extends Thread {
  override def run(): Unit = println("i am a thread")
}

(new MyThread).run()

And Scala comes with a set of converters to turn Java collections into Scala collections – and vice versa:

val javaList = new java.util.ArrayList[String]()
javaList.add("hello")
javaList.add("world")

import scala.collection.JavaConverters._
val scalaList: scala.collection.mutable.Buffer[String] = javaList.asScala.map(_.toUpperCase)
println(s"scalaList = $scalaList")
val newJavaList: java.util.List[String] = scalaList.asJava
println(s"newJavaList = $newJavaList")

9. For-Expressions

Scala’s for expressions have nothing to do with a Java for loop. The ingredients of Scala’s for expressions are generators and filters:

// generator
scala> for (n <- 1 to 10 if n % 2 == 0) println(n)

And they can yield a value!

// collect result
val ns = for (n <- 1 to 10 if n % 2 == 0) yield n
ns = Vector(2, 4, 6, 8, 10)

You can have nicely readable nested loops, by using multiple generators:

for {
  m <- 1 to 10
  n <- 1 to 10
} yield (m * n)

And they don’t only work on collections.. remember Option (see above):

val m1 = Map(...)
for {
  a <- m1.get(0)
  b <- m2.get(a)
} yield b

And also for Try, Future… but that we’ll look at some other time.

10. Everything is an Expression

Programming languages distinguish between statements and expressions. Statements do not return results and are executed solely for their side effects, while expressions always return a result and often do not have side effects at all.

A statement-oriented, side-effecting style would look like this:

order.calculateTaxes()

order.updatePrices()

While these are expressions, yielding a value:

val tax = calculateTax(order)

val price = calculatePrice(order)

Functional languages are usually expression-oriented, and Scala is, too, so whenever you write a line or block of code in Scala, it will evaluate to something. This is true even for places where you might not expect this if you come from a statement-oriented, imperative language like Java, such as for-expressions or pattern matches:

val result1 = for {
  m <- 1 to 10
  n <- 1 to 10
} yield (m * n)

val month = m match {
  case 1 => "January"
  case 2 => "February"
  case 3 => "March"
  case _ => "Other"
}

Ten Features FTW

If you haven’t developed in Scala so far, and have read through this little Top Ten list above – does it give you the impression Scala is a complicated language?

I went through this list with groups of Java developers on several occassions, some of which had previously been put off by Scala’s reputation of being somewhat difficult.

Well, Scala is a big toolbox, and there is a lot to learn if you’re interested, but the moral of this post is:

If you switch from Java to Scala, and you only use the 10 features listed above, you’ve already made a huge step towards writing better programs, and having more fun while doing so.

So why not start with that? Move to Scala for just a few of its powerful features, that are easy to comprehend and already give you great benefit. From there, you move on, and explore the rest of the Scala world based on a solid foundation.

Java 8 Update

The list was written quite a while before Java 8 became mainstream. Java 8, after a long wait, brought some features to the Java language that narrow the gap a little, namely the introduction of Lambdas and Optional.

I decided to leave the list as it is, anyway, as for me personally the arguments still hold – the support for functional programming in Scala just feels much more refined and complete as it does in Java. If you think differently, just ignore items 1 and 5, and you’ll still be left with eight good reasons to make the move to Scala. For those who really need it to be ten – of course there are many more features in the Scala language that could be listed..

And Even More

I have a couple more features in the same “simple, but powerful” category that didn’t make it into the list. And after I published this post, some readers pointed out some of their favorite Scala features to me. So I’ll try to follow this up soon with another post: “10 More Scala Features Java Developers Love”. Stay tuned.

If you'd like to learn Scala and learning from a book is what works for you, I recommend to get one of these two:

	Programming in Scala by Martin Odersky et al.
	Programming Scala by Dean Wampler