# ProSA: Introducing Worldline First Rust Open Source library

# ProSA: Introducing Worldline First Rust Open Source library
Jeremy Hergault | 6 Min To Read | 26 Nov, 2024 | #Development and programming, #Software engineering, #Open source and collaboration
=> https://blog.worldline.tech/2024/11/26/prosa.html Article on Worldline Tech Blog

We’re thrilled to announce ProSA, our first Worldline Open Source library in Rust, released on GitHub . ProSA stands for **Pro**tocol **S**ervice **A**daptor. It was designed to provide a simple and lightweight protocol service adaptor for service-oriented architectures and to offer a flexible and scalable platform for developing and deploying microservices. This allow developers to focus on writing business logic while ProSA takes care of the underlying infrastructure concerns.
=> https://github.com/worldline/ProSA GitHub

ProSA was developed from concepts of frameworks written internally in the company in Cobol, C++, and Java, as well as from our experience in transaction processing. Our goal was to refine these concepts to create an open-source product that can benefit everyone.

This post will explain our motivation for creating ProSA and its key features.

## What’s ProSA ?
In our domain we process transactions in real time. It implies real time constraints and a variety of protocols. When we started to process payment transactions (since 1980), we adopted several good principles/practices:

* SOA (Service-Oriented Architecture): with all the endpoints we need to deal with, this approach gives us flexibility in routing and clear interface specifications.
* Internal bus messaging using an integer key/value format with a dictionary that describes every field:
To be as effective as possible, the integer key is lighter than a string one.
The key/value format allows us to care only for data we need; you don’t need to serialize/deserialize fields you won’t manipulate.
Having a dictionary is beneficial for a clear interface specification.
* Configurable: In our case, we need to handle many protocols, but you want an application configured to handle only the protocols you need, not a bloated one.
Also with production in mind, you don’t want a hardcoded configuration. When you need to make changes, you want your application to be flexible and support dynamic configuration (especially with the Cloud).
* Observable: Observability is a cornerstone. Technical monitoring is mandatory to pilot your application, and business dashboards are also really useful for tracking business activities.
* Protocol agnostic: This is the main reason for creating a framework - to process payment protocols as generically as possible.
* Secure: Payment transaction processing is heavily regulated. We need to conform to several security certifications (PCI-DSS, etc.) and also respect data protection (GDPR, etc.).
Therefore, a clear development process and verification are in place for all of these requirements.

These are the main pilars of our framework solutions, and ProSA is no exception.

Thus, we have arrived at an architecture with:

=> https://blog.worldline.tech/images/post/prosa/tvf.svg TVF [image]
**TVF** (**T**ag **V**alue **F**ormat) which is the trait for the internal message format as an integer key/value.

=> https://blog.worldline.tech/images/post/prosa/main.svg Main [image]
The **Main** task to orchestrate everything.

=> https://blog.worldline.tech/images/post/prosa/proc.svg Processor [image]
The **Processor** task to handle a protocol or a specific function.

=> https://blog.worldline.tech/images/post/prosa/adaptor.svg Adaptor [image]
An **Adaptor** to adapt an internal message to an external protocol (related to a processor) and vice versa.

=> https://blog.worldline.tech/images/post/prosa/settings.svg Settings [image]
**Settings** used by the application.

They are organized like this:

## Deployment
Developers often dread the deployment process. When your solution is observable and manageable, the underlying platform shouldn’t be a concern. In today’s cloud-driven landscape, the focus is on building applications that thrive in the cloud.

To meet these needs, we created a cargo integrated command: cargo-prosa .
=> https://github.com/worldline/ProSA/tree/main/cargo-prosa cargo-prosa

This allows to create your ProSA with any processor/adaptor you want and with the package type you need.

From that, you can generate:

* A single executable
* System packages (deb, rpm)
* Docker images

And more deployment methods are on the way.

## Performance
When we began the project, our main concern was to make ProSA faster or at least as fast as what we already have with our equivalent Java framework.

In our case, finding an example that would be meaningful to everyone reading this post would have been complicated. That’s why we’ll present a comparison between our Java and Rust applications (both using the same concepts discussed earlier).

### Message passing
For the first test, we used the application as a message router, so it only had to route messages through defined services.

The TPS flow rate is not high, but it’s intentional. We used a single-scale backend application to handle that load. The goal is to see if ProSA could manage a regular load.

With both ProSA and the Java application, we had a flow like this:

=> https://blog.worldline.tech/images/post/prosa/bench_messages.webp Bench messages [image]

```
| Applicative | %CPU | RAM |
| ----------- | ----- | ------ |
| ProSA | 11% | 2 Mo |
| Java | 18,5% | 390 Mo |
```

As we can see, ProSA appears to consume slightly less CPU than the Java application and significantly less RAM. Based on this, ProSA is a viable alternative for our needs, especially from a RAM usage perspective.

### JSON Web Tokens (JWT)
The second benchmark we conducted to compare our Java and Rust frameworks involved a JWT application.

To provide authenticated access to specific services, we use JSON Web Tokens (JWT). These tokens store the application name, and the services it needs to access.

Up until now, we implemented this functionality in a Java JWT application to forge, check these tokens, and proxy service accesses according to the JWT. We encountered a performance issue related to the JWT verification latency. The Java library we used seemed to be the bottleneck.

At that time, ProSA was in its early stages, so we sought a non-disruptive solution to try it out. JWT verification was initially done locally by the Java application, so we simply added an external service call to check the JWTs. If the service is not available, the check is done locally as before.

All components ran on the same machine.

During the benchmark we injected a continuous flow of JWT checks, and in the middle of the test, we turned off the ProSA JWT service. Thanks to the service approach, when ProSA is turned off, the verification is done locally instead of calling the external service.

This yielded the following results:

=> https://blog.worldline.tech/images/post/prosa/bench_jwt.webp Bench JWT [image]

With ProSA JWT processing, as you can see on the upper graph, we achieved more than a thousand requests per second with a latency of less than 20 milliseconds.

When ProSA was shut down during the test, the TPS dropped to 500 requests per second, with a latency of 100 milliseconds corresponding to the internal Java check.

Thanks to this solution, we had a concrete use case to test ProSA and improve performance without taking any risk. If anything goes wrong, the check could still be done locally without ProSA.

## Wrapping up
ProSA is a groundbreaking change for us. It will shift our solutions from C++/Java to Rust. Moreover, by sharing our work, we are further moving Worldline towards open source software development, where the contributions of developers around the world are greatly valued.

We are incredibly excited to bring ProSA to the open-source community. And we look forward to sharing each step with you on this fantastic journey.