AUTHOR: GERRIT VAN BRAKEL APPLICATION ARCHITECT FRANK!FRAMEWORK
To be able to substantiate and explain the title of this article, we should take a closer look to the different phases. Starting with the aspects within the integration component, where streaming is not a part of a regular environment yet.
Firstly, a message comes in which is then immediately transformed. This transformed message is then sent in its entirety. The delay generally occurs when downloading and forwarding the complete message. These messages are received and sent through network connections. These network connections have a limited speed and have a lot of traffic.
The message that’s being downloading is built up in memory and the system waits for it to complete. After it has been built completely, the message will be transformed into or to a new message. The new message is then sent over the network connection and the system waits for it to be sent entirely. After sending, a response is given from the system.
This outlines the situation of sending and downloading over multiple network connections. The profit that can be made is entirely in the waiting times that are in the waiting times that are built up.
Instead of waiting for the entire message to be received, we will use streaming. This way we can use the possible waiting time usefully. Streaming does not immediately download the entire message, but only a part of it. This piece is immediately transformed into a new piece that is also sent immediately. After this first piece has been transformed, the next piece is downloaded, also transformed and then immediately sent. This creates the situation where you would otherwise have been waiting for the entire message to be downloaded, now that the processing and sending of a part is realized. Besides that, you make waiting times on the shipping side efficient. Instead of waiting for the entire message to be sent, the fetching and transformation of the next part is now accomplished.
The situation outlined above will become much clearer with major messages. The workload will be much more scalable, and the waiting times will decrease proportionally. With large messages, the question is if the JVM immediately has enough memory available to download the message. Often the Heap has to be cleared to accommodate it. This takes time and causes irritation to the user. In the case of the streaming option, this problem is also in the past. After all, in this workload the entire message doesn’t have to fit in the memory, since it only processes parts of the message in phases. The memory must accommodate only that small piece. When that part has been processed, as described, and sent, the space can be used for the new part of the message. Garbage collect to free up large chunks of memory is over and the toil and waiting is turned into efficiency!
Streaming provides a better user experience and puts less strain on the underlying hardware. The larger the files, the more time and hardware resources are saved.
In our latest release of the Frank!Framework (7.6) we offer streaming as standard. Would you like more information? Please contact us for a consultation.