Axon as a bridge between a web app and a WebSocket server cloud?


I work with a “mature” Java servlet-based web app that stores its state in-memory as something like an event store with serialized Java objects. We have existing web clients that connect directly to this Java application, and they are not going away anytime soon. We also have a cloud-based app for streaming JSON messages to WebSocket clients that will need to have the web app state streamed to them. So we need to convert the serialized Java objects from the web app to JSON and then send them to the cloud-based app so it can stream them to the clients. This smells like CQRS/Event Sourcing, with the command handling and event store responsibilities already being done in the web app (though not at all conforming to the command/handler domain model pattern), and a need to do conversion to a JSON read-side model suitable for streaming to clients. I’m looking for critique on the options I’m considering.

  1. The simplest thing I can think of would be to push the events from the web app into a shared cache based on something like Hazelcast. Then I can create a consumer app that gets notified when an event is added, converts the serialized POJO to JSON, and stores the JSON to a read-side model. Another consumer app would notice the read-side model changes and send them to the streaming app. This would of course become problematic when we eventually try to distribute the web app across multiple nodes, since we’d have to implement all the troublesome event store concurrency behaviors in the shared cache.
  2. I’m also considering using Axon between the web app and the streaming app. Since I’d love to move the entire web app to Axon eventually, this would put key pieces in place for future phases. Does this seem crazy? Too much extra work compared to option 1?
  3. I could create a simplified domain that just turns each web app in-memory event type into a command with aggregates that naively accept each command by generating an event. Then I’d have a real event store and could project the events onto a JSON read-side model. Would this be a good stepping stone to allow moving the web-app domain piece by piece to more robust commands and aggregates in the future?
  4. I could also just publish the web app in-memory events to the Axon event bus directly. So I’d still have the event store and projections to the read-side, but wouldn’t need to implement commands and aggregates. Would this be a quicker alternative, then work on the domain stuff later? I’m not sure how much I’d really save in the and, and I have a feeling I’d be stepping into trouble trying to use just half of Axon.
    Having played around a bit with event stores, I found a lot of pitfalls. Then I found Axon and breathed a sigh of relief. I’m really hoping to take advantage of this awesome framework.


Hi Kevin

I think it would be an overkill to bridge your apps with Axon if only what you need is the event sourcing pattern. On the other hand you should evaluate your domain model complexity before attempting the migration of the web app to Axon.
I would go for a simpler solution. In a distributed ecosystem you will need to deal with eventual consistency. I don’t know about Hazelcast, but Redis has a pretty configurable read/ write quorum settings and a built-in pub/sub system. If the stale
data is not an option in your infrastructure, you can guarantee strong consistency setting up a considerable read quorum.




option 2 sounds like a pretty overkill situation. Although it might seem as an advantage to have Axon in there as a preparation to migrate towards Axon, I doubt it will actually help you.
I would start emitting events (e.g. over an Axon event bus) to the other components. Then, step by step, you can replace the existing web application components to aggregates that emit those same events as part of their state changes.



Hi Allard,

OK, that sounds like my option 2.2, but I see now that it would not involve using the Axon repositories. Since starting with the Axon event bus seems sensible, I’m going to start looking into that approach.