0
●0 ●1 ●3
How much coding effort needed if migrating from RFA7.7 to RTT EMA
Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.
Thanks,
-AHS
25.3k
●87 ●12 ●25
Hi @aftab
I noticed you asked a similar question for migrating from RFA 7.7 to RFA 8.x
Assuming you are using the legacy MarketData/SSLED interface with RFA 7.7, as explained in my other post, moving from RFA 7.7 to EMA will be considerably less effort than moving to the RFA 8.x OMM interface.
If you compare the legacy RFA 7.7 consumer example RFASTTicker (C++) or the most basic MDSubDemo (Java) with a similar EMA consumer example such as 200_MP_Streaming - you will note that the EMA examples use a fraction of the code to achieve the same functionality compared their RFA equivalents.
This is because EMA is a high-level ease of use layer API which defaults much of the most commonly performed operations e.g.
// C++ OmmConsumer consumer( OmmConsumerConfig().host( "ads1:14002" ).username( "user" ) );
OR
// Java
OmmConsumerConfig config = EmaFactory.createOmmConsumerConfig();
consumer = EmaFactory.createOmmConsumer(config.host("ads1:14002").username("lpcuser2"));
Executing the above lines of code performs the following (behind the scenes)
- Establish a session (connect to a server)
- login to the server with user name,
- download the data dictionary
- download the source directory
Achieving the above with the RFA OMM interface would require 100+ lines of code.
Hi @aftab
I should also like to highlight other key benefits of EMA over RFA:
Benefits of EMA over RFA
EMA has Cloud-native support – organisations wanting to cut datacentre costs
- The same EMA application can consume data from Deployed RTDS server & RTO Cloud endpoint.
- Easily switch from RTDS to RTO as and when required - Identical data formats
Future-proofing - longer-term OS and Compiler support for new APIs, older APIs will be deprecated (RFA is 19 years old, SFC/SSL even older).
EMA is an Open Source API
Improved performance:
- higher /throughput compared to RFA SSL
- lower latency, lower bandwidth usage compared to RFA SSL
Newer features
Views (field filtering), Pause & Resume data streams, Tunnelling, Service Discovery, Domains, Private Streams, Horizontal Scaling, Batch requests
Easier to learn for existing & new developers
- Ease of Use layers, Less code to write, Easier to maintain
- Improved resources - training, tutorials, examples, articles, use cases
Richer data payloads - Increased flexibility & efficiency of data distribution + processing, Binary encoded format
Hi @aftab
Just a follow-up post to see how you are getting on with your Migration decision/efforts?
I am currently working on some material around migration from RFA to EMA. So, would be interested to hear about your experience.
Likewise, if you have any questions/concerns about this topic, I could make some time for a Teams session to try and answer any of these questions/concerns.
I am based in the UK and would be able to make some time between 10am-4pm on most days of the week (allowing for any existing meetings etc).
Let me know if you are interested in the above and I will email you directly.
