Guaraná DSL is a Domain-Specific Language (DSL) to design Enterprise Application Integration (EAI) solutions at a high-level of abstraction.
The resulting models obtained with Guaraná DSL are platform-independent, so engineers do not need to have skills on a low-level integration technology when designing their solutions. Furthermore, this design can be re-used to automatically generate executable EAI solutions for different target technologies. This is something that can be achieved by means of Model Driven Architecture. Catch a glimpse at the Integration Stack with the abstraction levels for an integration solution and see where Guaraná DSL fits. Note that Guaraná DSL is the language you can use to design your EAI solutions. Currently we are working on a java implementation of this language, called Guaraná SDK. We kindly invite you to have a look at it, download it, try it and give us your feedback ;-)
Functionality and structure of an EAI solution are completely defined by using the language building blocks, ports, tasks, decorator, slots and integration links. Guaraná's tasks are based on the Enterprise Integration Patterns (EIP Patterns) by Gregor Hohpe and Bobby Woolf. It is possible to design the internal structure of all kinds of building blocks (wrappers and integration processes) and its communication ports (entry port, exit port, solicitor port and responder port) by using tasks; it is also possible, to create integration flows that allow applications to collaborate by connecting these building blocks by means of integration links. Applications that participate in the integration solution are documented using decorators as well as its layers being used as communication interface.
Main constructors in Guaraná DSL
Below you have a list of the main constructor of Guaraná DSL. Please, have a look at the API Documentation of Guaraná SDK for more information and other constructors as well.
Decorators: to provide visual information about the participating applications in the EAI solution and their layer(s).
Building blocks: to represent the processing constructors of the EAI solution. There are two types of building blocks in Guaraná: wrappers and processes. A wrapper communicates the EAI solution to an application, so it contains communication-specific tasks and has a port connected to a decorator. Processes model the essential services of the EAI solution, so they contain integration-specific tasks; they are connected (through ports and integration links) to each other and/or to wrappers.
Slots: are memory buffers used within building blocks for port to task and task to task internal communications.
Tasks: are message processing constructors and appear inside processes and wrappers. A task reads messages from incoming slots, processes them (e.g. enriches, translates, filters, etc.) and deposits the result in the outcome slot. Part of them are based on the enterprise integration patterns proposed by Gregor Hohpe and Bobby Woolf.
Ports: are used to communicate the internal building blocks of an EAI solution and the EAI solution with its applications.
Integration links: are channels that transport messages between building blocks. They are used to connect the entry/exit ports used by building blocks.
Currently we are working on a Java Framework for Guaraná DSL and on a Java Toolkit which implements this framework. As part of the effort to reduce costs of enterprise application integration solutions Guaraná also introduces a novel Runtime System to execute EAI solutions implemented with the Guaraná Toolkit. I invite you to learn more about this runtime system here.
More information about Guaraná DSL
Example of EAI solution designed using Guaraná DSL
Below we show an example of EAI solution designed using Guaraná DSL. To set the scene, we will use the scenario of an application integration problem under study at Unijuí, Brazil. Apart from some small modification introduced to highlight the issues of our research interest, the scenario is realistic.
Unijuí has five applications involved in a hand-crafted process whose goal is to invoice their employees of the private phone calls they make using the University's phones. Each application runs on a different platform and was designed without integration concerns in mind. There is a Call Center System (CCS) that records every call every employee makes from one of the telephones this university provides to them. Every month, an analysis is performed to find out what calls have a cost and are not related to the work activities of the employees; such calls are debited to the employees by using a Payroll System (PS). There is also a Human Resources System (HRS) that provides personal information about the employees, including their names, phone numbers, social security numbers, and so forth. There are two additional systems to send mail or SMS messages. The goal of the integration solution is to automate the invoicing of the calls that an employee makes and are not related to his or her work activities.
