Overview
The Enterprise Message API (EMA) is often presented as an Ease of Use API, which is a very appealing trait for an API, isn’t it? Indeed, the simplicity of an API has a direct impact on the time you spend to learn it as well as the effort required to develop and maintain your application. For this reason, the ease of use is an important criterion when choosing an API.
The simplicity of an API, or its ease of use, is a concept that we obviously all understand. However, different developers may have different perceptions on how simple an API is. This appreciation is very subjective and often depends on the experience and skills of the developer. So, when we say that EMA is an ease of use API, what does it mean exactly? For what developer audience and for what kind of use case is it easy to use? Couldn’t it be even easier?
This is the kind of question I asked myself when I first discovered EMA. In this article I would like to share my thoughts on this subject and try to answer these few questions. I also would like to start shaping a layer of value add objects that would simplify even more Refinitiv Real-Time content access with EMA. It would be implemented as an example library – built on top of EMA – and used to simplify and factorize the code of some of the example applications written for the Refinitiv Developer Community.
About the Enterprise Message API
EMA is one of the two APIs exposed by the Refinitiv Real-Time SDK. The other API is the Enterprise Transport API (ETA) that is a lower level API than EMA. These two APIs allow developers to build applications that consume data from Refinitiv Real-Time Optimized and Refinitiv Real-Time Distribution System (RTDS, formerly TREP). and also publish data on RTDS.
It’s important to note that EMA is the Refinitiv strategic API that replaced another API called the Robust Foundation API (RFA) and that is now "Feature complete". Meaning that it is in care & maintenance phase and that no new feature will be developed for this API."
EMA compared to RFA
When organization's development teams decided to replace RFA by a new API called EMA, they took special care of the ease of use. This came in response to a general feedback about the relative complexity of RFA. Indeed, RFA is effective and robust but it’s also a complex API that is not that easy to learn and to use. The real challenge for the organization's teams was to create a simple to use new API, but without adversely affecting the performance.
A good example of what they achieved is given by the picture below that visually compares the source code of a simple consumer application written with RFA (the three java files on the left side) with the source code of the equivalent application written with EMA (the single java file on the right side).
As you can see, the EMA example is only a fraction of the size of the RFA example. It is true that the number of lines of codes alone is not a sufficient indicator to evaluate the simplicity of an API. But in this case, you may not even feel the need to read the source code to decide if EMA is simpler than RFA. I let you be the judge. If you also consider that EMA outperforms RFA, then you may come to the conclusion that this new API is a good move forward.
I think that the simplicity of EMA compared to RFA is the main reason why Refinitiv claims that EMA is an ease of use API. This point of view is equally shared by the many customers who migrated from RFA to EMA.
But what if you do not have any prior knowledge of Refinitiv's real time platforms and RFA, and must now learn EMA. How easy will that be?
EMA from the perspective of new developers
I believe that two major strengths of this API make it easy to learn and use, even for a first experience:
- EMA is a fluent API: The fluent aspect of EMA used in conjunction with the Intelligent Code Completion of modern Integrated Development Environments (IDEs) really makes code writing dead easy. Once you understood the basic concepts related to the real time platforms and once you know the entry point of the API, methods and parameters really fall under your fingers. Watch this video article for a demonstration of the fluentness of EMA coding.
- EMA relies on convention over configuration: This simplifies the configuration of your applications to such an extent that you can even get rid of the EMA configuration file at the cost of a single additional line of code. This relieves developers from tedious configuration phases that sometimes block their learning process.
So, EMA is really simple, right?
Well, I think it’s overly simplistic to say it that way. I would like to add some nuance to this statement. It is true that once the basic concepts related to Refinitiv's real time platforms are understood, any experienced Java or C++ developer should find it easy to learn EMA.
It is also important to note that EMA has been intentionally designed to be a flexible API that is able to answer a wide variety of use cases. Because of that and because of the fine-grained control it gives you, EMA is a relatively low level API. It involves advanced development techniques that may not be obvious for less experimented developers. For example:
- EMA is a messaging oriented API: This means that your application cannot just get the data it needs from objects like Market Prices or Order Books. It must first subscribe to items, then extract the data from messages sent by the platform and optionally build internal representations of the items and their values.
- EMA is an asynchronous event driven API: This means that your application must implement callback objects with methods that will be called asynchronously by the API when messages are sent by the platform.
- EMA requires an event loop or thread safety: Depending on the EMA operation model you chose (USER_DISPATCH or API_DISPATCH), your application must either implement an event loop to dispatch EMA events or to be thread safe to be protected against concurrent calls from the EMA thread.
These techniques bring some complexity. This is only to a small degree that has nothing to do with the complexity of RFA. EMA and RFA are indeed two different worlds. Nonetheless, less experienced developers may be puzzled and find these techniques overly complicated when they simply want to get the latest price for a couple of shares.
Can’t it be even easier? I just want to grab some market data
There is no doubt that some applications are highly demanding and, for example, need streaming data delivered at a high throughput, with a very low latency and for a large universe of instruments. EMA is definitely the perfect fit for that. But sometimes, applications just need to retrieve the latest values of a small number of instruments within a reasonable delay. For these use cases, the EMA mechanisms described in the section above are a bit of an overkill. Developers would probably prefer calling a couple of methods that just return the data they need.
In my experience most applications built for Refinitiv's real time platforms do not really need the high level of performance EMA offers. Obviously, he who can do more can do less. However, less performing but simpler objects with a higher level of abstraction would definitely help more developers build applications for these platforms.
For example, wouldn’t it be great to retrieve market prices that way:
MarketPrice euro = new MarketPrice("EUR=");
euro.open();
double bid = euro.getField("BID").value();
double ask = euro.getField("ASK").value();
How can we make it simpler?
As I described earlier, EMA is a fairly low level API. It requires your application to implement features you could expect from a real time API. For example, a real time API could provide:
- Objects, like MarketPrices or Order Books that cache (retain) in memory the latest values sent by the platform so that your application can randomly get this data anytime and from any thread.
- A synchronous mode so that you do not have to implement an event loop and callback objects if you do not want to be notified of items’ updates in real time.
- Helpers to dispatch events until some specific conditions happen.
- An easy to use Service Directory object as well as a simple way to retrieve the state of the connection to the real time platform.
- Objects that automatically expand chains.
- Objects that automatically recompose compound pages.
- …
This list could be even longer. The objects and features described above would really help to factorize the code we commonly implement in Refinitiv real time applications. It would also provide many developers with a simpler and better coding experience.
A journey to an even better ease of use
As a Refinitiv Developer Advocate I often build example applications that demonstrate and promote RTDS (formerly TREP) and Refinitiv Real-Time APIs. They are typical applications that would greatly benefit from a higher level of abstraction. All of them need several of the features listed above. So, instead of duplicating the code, why not factorize this functionality in a set of reusable objects that would be shared among these example applications? Just for the sake of source code readability, simplicity and ease of maintenance, it completely makes sense to do it. These objects would also be helpful to the Developer Community who would find there good implementation examples.
Here is the plan
In parallel with the articles and example applications I write to explain real time applications concepts, I will implement a set of value add objects that demonstrate these concepts. These objects will be shared in a GitHub repository and reused by the example applications to demonstrate them and also factorize source code. The idea of these value add objects is not to re-invent the wheel but to rely as much as possible on the existing Refinitiv Real-Time SDK and the EMA API. That way, they provide a higher level of abstraction and elegantly complement EMA. As EMA objects and interfaces will be extensively reused by the value add objects, example applications will use them in conjunction with EMA.
I will add new value add objects as I write new articles for the Developer Community. The set of value add objects for EMA will grow that way, incrementally.
Initial version
The initial version of these value add objects for EMA is already available as I write this article. It provides the following features that are based on my previous articles:
- MarketPrice objects with in memory data cache that retains the latest values of the subscribed items and provides a random access to the fields and their descriptions. Subscription by field (Views) is also included.
- Chain objects that automatically expand chains and recursive chains. In memory cache, random access to chain elements and optimized expansion are also included.
- Synchronous and asynchronous subscription modes.
- Helpers to dispatch events until some specific conditions happen.
Work in Progress - Stay tuned!
The ValueAddObjectsForEMA GitHub project is available here. This is the list of articles that drove the current implementation:
I will update this list as I write new articles. More to come… Stay tuned!
Disclaimer
It is important to note that the ValueAddObjectsForEMA project has been written by Refinitiv for the only purpose of illustrating a series of articles published on the Refinitiv Developer Community. This project has not been tested for a usage in production environments. Refinitiv cannot be held responsible for any issues that may happen if the ValueAddObjectsForEMA project or the related source code is used in production or any other client environment.
Final thoughts
I think that the perception of simplicity developers may have about a specific API depends on multiple factors like their experience, their technical skills, the use case they are implementing, the learning materials provided with the API, etc. As a Platform Company it is important that Refinitiv provides APIs that are easy to learn and to use for a large variety of developers – from the newbies who build their first "Hello world" example, to experts who fine tune their applications to get the optimal level of performance. Providing an ease of use API like EMA was a major step in this direction but a single API can hardly meet the expectations of all developers in terms of ease of use and use cases. A messaging oriented API like EMA covers a large part of them but it sometimes needs to be completed by features that must be implemented by the application. Explaining these features and proposing an example of implementation is the purpose of the ValueAddObjectsForEMA project and related articles. I hope you will enjoy them and find them useful for your future developments.
Leave your feedback
Your feedback is warmly welcome and can certainly help me to improve. Don’t hesitate to leave a message below or "Like" this article if you liked it.
My other articles
If you liked this article, you may be interested in reading my other articles:
- Introduction to the "Refinitiv API Samples" Github group
- 10 important things you need to know before you write an Refinitiv Real Time application
- The EMA ease of use in action (Video article)
- A simple MarketPrice object for EMA
- Simple Chain objects for EMA