We are happy that you came to this page to gather more information about the novel runtime system for enterprise application integration solutions we are working. This runtime system is a very important part of the ongoing Guaraná SDK implementation. In this page we provide a brief overview on why EAI solutions need a new runtime system.
A typical approach in the design of solutions is the use of a database to store inbound messages coming from individual applications to the process, until all the messages needed to start the process arrive. Thus, the runtime system assigns one thread exclusively to the process and this thread starts to execute synchronously all internal tasks of the process. We refer to this model as process-based execution model. In this case, if in some point a task makes a request, the assigned thread remains blocked until this task receives the response.
In the context of EAI it is common that messages from solutions are handled with a low priority by its integrated applications, so as not to disturb the application. There are cases in which a message received by the application requires the intervention of a person; in other cases, the application can represent another integration solution already deployed. Therefore, the response for a certain request is not instantaneous, but may take a time, i.e., minutes, hours or even days [Hagen00] Thus, the problem with the process–based execution model is that the thread remains blocked and inactive for a long time, which amounts to in these cases wasting system resources.
Some techniques have been proposed to ease this limitation introduced by the process-based execution model, namely: dehydration and rehydration[Wright09, Dunphy06]. Roughly speaking, the execution context of the process is serialised (dehydration) in a persistent data store while waiting the response, thus releasing the current thread. When the response comes, the runtime system recovers the context of the process (rehydration), and, when there is a free thread it is assigned to the process so that its execution remains. Current process support systems, such as Microsoft BizTalk Server, Open ESB, Apache Camel, Mule ESB, Spring Integration and those based on BPEL, have their runtime system based on the process-based execution model.
A technique to address this limitation is to use a task-based execution model. In this model, threads are assigned by the runtime system to tasks, instead of processes. This lower level of granularity allows tasks to be executed as soon as there is a message available to them, without having to wait for all the messages needed to start the process. In the task-based execution model, the correlation of messages that must be processed together is done inside the process by a specific task, which allows to use system resources more efficiently[Hadjicostis99, Li08].
[Hagen00] Exception Handling in Workflow Management Systems Claus Hagen, Gustavo Alonso IEEE Trans. Software Eng., 26(10):943-958, 2000.
[Wright09] Oracle SOA Suite Developer’s Guide. M. Wright, A. Reynolds. Packt Publishing. 2009.
[Dunphy06] Pro BizTalk 2006. G. Dunphy, A. Metwally. Apress. 2006.
[Hadjicostis99] Monitoring Discrete Event Systems Using Petri Net Embeddings. Christoforos N. Hadjicostis, George C. Verghese. ICATPN, 188-207. 1999.
[Li08] Designs of Bisimilar Petri Net Controllers With Fault Tolerance Capabilities. Lingxi Li, Christoforos N. Hadjicostis, R. S. Sreenivas. IEEE Transactions on Systems, Man, and Cybernetics, Part A, 38(1):207-217. 2008.