Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
In the microservices world, we receive messages from different sources like JMS, AMQP, EventBus and try to process them as quickly as possible. Multithreading with Thread Pool can help us to do that.
But if we want to treat messages of the same categories (same users, same products...) in the order we receive them, it could get more complicated.
One of the corollaries of embracing microservices is the increased need to aggregate information from multiple remote sources. In turn, exploiting every opportunity to execute such operations in parallel becomes more important and managing the resulting complexities becomes more central to the organization of your code. There are several core Java language and library options available to achieve this, but their generality makes them relatively low-level for this purpose: they lack a task abstraction.
A task in this context is a class that performs a non-trivial, track-worthy unit of work in an execution graph, potentially comprised of many such tasks. Tasks are important because interacting with an external system or database often involves details that are best encapsulated in a separate class. Done well, this separation of concerns facilitates refactoring at a logical level without impedance from the particular complexities involved with any external interaction. Such refactoring is to be expected as business goals evolve – which is one of the reasons for embracing microservices in the first place.
As we said in our introductory post, we’re going to do several posts about Zoomdata microservices. This one covers a brief overview of microservices and the Zoomdata web application.
The Zoomdata platform is architected as a set of loosely-coupled Java microservices. Unlike traditional BI, which is deployed as a monolithic application (or possibly entwined in an old-school enterprise service bus), a microservices architecture allows for: