I have seen many newbies and aspirant Front Arena (FA) developers struggle to get hang of things especially when they land the sea of information available in knowledge base (https://kbase.frontarena.com). To be honest, kbase has been very well organized, but it is intended to be a “complete source of information” rather than a beginner’s guide. I thought of writing this article to help these targeted set of audience.
Prime, ADS and ADM
At a bare minimum, you need Prime, ADS and ADM to start using Front Arena.
- Prime is the main GUI client that lets you interact with the system.
- ADS which stands for Arena Data Server, provides controlled access to the database. It also acts an on ORM layer that encapsulates the underlying data model.
- ADM which stands for Arena Data Model is the data store.
Together they form the typical three-layered architecture which can be visually represented as:
Arena Task Server (ATS)
Once you get familiar with the system, you would want to automate certain tasks that you usually do from the GUI. So you would need a component that encapsulates the business logic but without the overhead of the GUI. ATS is that component. You can assume it to be GUI less Prime.
It can connect (login) to ADS and help you automate tasks like generating reports, performing data maintenance, etc. You can scale the performance of these tasks by adding as many ATSes as you want. Each of these components will spawn their own process thus giving benefits of multi-processing.
Arena Message Broker (AMB)
Like any other enterprise grade application, when the complexity increases, you would want the components to be loosely coupled, yet work as a cohesive set in delivering the system functionality. A message bus is an obvious solution.
Arena Message Bus provides the typical Publish-Subscribe model for communicating between the components. It helps in scaling the system without creating a tight coupling. It works in conjunction with Arena Message Broker Adapter (AMBA) in publishing the events. AMBA can also subscribe to events in AMB and have them passed to ADS that are eventually recorded in the ADM. Like ATS, you can add as many AMBAs you want to have a modular system.
Conclusion
Once you familiarize yourself with the configuration and responsibilities of these components, you are pretty much on your way to explore and understand more complex Front Arena setup that would see in a production. You will often see multiple instances of these components doing specific tasks. Example could be supporting post trade services like generating confirmations and settlements. I hope this article has given you a basic idea of what are the building blocks of Front Arena system. Equipped with this knowledge, you can delve into Front Arena knowledge base and get an in depth understanding of each component.
Great information, thanks.