Framework & Services

The true power of the ValueA framework lies in it’s simplicity to define services, as a developer you normally only have to worry about building the actual business logic. The framework handles the rest for you.

In the diagram on top you will find the usual flow a message will follow.

Handle requests

When a request is queued it can be picked-up by one of the ValueA broker processes currently awaiting messages, for test and develop purposes you usually have one “worker” running to ease debugging.

Note

To increase processing capabilities, start more worker processes using different (virtual) machines.

The queue listener receives the message, and will try to find a service matching the request using the header. If a service is found, the request is validated and when in order executed.

The service itself is a simple class, derived from one of the base services available in the framework. After service execution a response is returned, using standard python types (dict, list, ..), the request handler checks the request if a response is expected and sends it back to the response queue.

Data interaction

When interacting with standard relational databases (such as PostgreSQL), we’re using an object relational mapper to structure the data and the logic around it. For this purpose we use SQLAlchemy, which is for python the most used mapper.

For interaction with cassandra, we’ve supplied our own mapper, which is available in the framework components.

Logging

The ValueA framework offers detailed logging of the internals called within the system including the messages processed if needed. For larger setups it might be wise to setup a syslog server to collect all the log data from the different nodes together, by default the logging is send to file.

Because authorization is handled at the frontend of the stack, the user involed with the request is always passed with in the header of the request so in our logging we can always track the user.