1 Introduction

Big companies need to quickly react to changes and new rules in order to keep their operational and analytical processes up to date. Software systems that implement these processes need to be flexible, susceptible for structural changes, and capable of providing mechanisms that simplify the incorporation of new rules and minimize their maintenance cost. In this text, we will adopt the term Process-Aware Information Systems (PAIS) [16] to refer the entire software systems infrastructure for Business Process Management (BPM) [4], Scientific Processes [7], Workflows [23] and similar applications.

To meet the demand for more dynamic and flexible approaches, several alternative models for modeling and implementation of PAIS have been proposed in the last decades. A common characteristic of every process-based system is the production of data resulting from interprocess relationships. Although neglected by most approaches, projects that integrate data requirements into the modeling phase of PAIS are intrinsically more flexible. With the support of data requirements, it is possible to capture the behavior of the processes in much more detail and accuracy, not only simplifying the incorporation of structural modifications into the system, but also reducing the complexity of fault detection. In this context, [17] presents an alternative approach for modeling and implementation of PAIS called WED-flow. This approach introduces the concept of data states as the driving force of process management. There are three fundamental concepts that can be identified in PAIS: workflow; event flow; data flow. The WED-flow approach considers that these three concepts are equally relevant and the combination of them is an efficient strategy for building sufficiently flexible models that are able to cover the need of the current PAIS. In this approach, the workflow is designed by triggers that capture events and enable the execution of processes. Events are parameterized as data states, which in turn are the only way of communication between processes.

The formal definitions and mathematical properties of the WED-flow approach allow the construction of PAIS that contain the structural flexibility required by modern applications. Using mathematical notation based on Set Theory, the elements of the WED-flow approach can be seen as a Domain Specific Language (DSL) [19]. However, even though this language is an adequate modeling tool, the development of an implementation environment for WED-flow executions is mandatory. Thus, in order to provide an efficient implementation of WED-flow models that supports incremental evolution and takes advantage from the transactional properties available in Relational Database Management Systems (RDBMS), this work proposes an intermediate language called WED-SQL: a SQL-like declarative language, built to represent WED-flow abstractions supported by transactional execution environments. Therefore, we aim to spread the WED-flow approach as an alternative for the development of robust, flexible and reliable PAIS to support contemporary business and scientific processes.

The remainder of this paper is organized as follows: in Sect. 2, we present the related works. The need for an intermediate language between WED-flow and SQL is presented in Sect. 3. The WED-SQL intermediate language is presented in Sect. 4. In Sect. 5, we present a modeling and implementation case study. In Sect. 6 we have the conclusion.

2 Related Work

PAIS are traditionally constructed according to control flow approaches (workflows) [4, 14, 16, 21, 23, 36], event-driven approaches [6, 11, 13, 15], or data-oriented approaches [24, 26].

Widely adopted in companies, the WS-BPEL [28] process execution language emerged as a tool for implementing process-oriented systems. Structurally represented in XML, it is a procedural nature language developed to orchestrate the execution of business processes implemented through web services. As in imperative programming languages, WS-BPEL supports variables, control-flow structures and primitives to specify the main workflow patterns identified in [2]. Alternatively, the language YAWL [18] is a workflow execution language based on Petri Net in which, despite its graphic nature, it is formally well-defined and implements the main workflow patterns.

In [10], the authors propose a methodology to translate WS-BPEL processes for YAWL workflows and make feasible the formal verification of WS-BPEL processes. Another prominent language in this context is BPMN [29]. By offering a simple and intuitive notation, it has become a popular language for business process modeling by the ability to communicate among business experts, programmers and customers. However, BPMN does not have formal specification, as well as an implementation structure that makes it unfeasible as a complete solution for the development of PAIS. Commonly, BPMN projects are mapped to the WS-BPEL execution language, even though there is no direct match between the two languages [35].

Although popular, these languages were not designed to achieve the level of flexibility required by modern PAIS. The high dynamism present in today’s business models demands systems capable of incorporating high rates of change with agility and efficiency. The imperative nature of the languages presented above restricts them to the development of static PAIS in which often fall short of the requirements of contemporary applications. In [1], the authors discuss how a declarative approach based on the concept of constraints could demand for more flexibility. For this, they propose the use of a framework called DECLARE [31] that uses the YAWL language for the execution of processes and the languages based on restrictions DecSerFlow [3] and ConDec [22] for specification and modeling.

In [12], the authors present the XCHANGE language, an ECA rule-based language for Web services composition. These approaches have established widely disseminated strategies for modeling and implementing events in PAIS. In the XCHANGE language, events are represented as XML data structures, while business processes are implemented by web services. Control flow is expressed by ECA rules that define the behavior of the system. In others words, the execution flow of an instance is determined at runtime according to the occurrence of a sequence of events. This language also simplifies the handling of exceptions, since they can be conveniently represented as events using ECA rules. Nevertheless, capturing and representing events are not enough to provide appropriate support for complex tasks in PAIS.

The concept of business artifacts [8, 20, 25, 27] was introduced in order to provide atomic units that group self contained and indivisible data from processes in complex lifecycle models. In [9], a formal model is presented to validate the properties of a life cycle. Nevertheless, despite its results, the life cycle concept cannot explicitly represent data states.

Briefly, the three approaches presented and their respective languages produced significant practical and theoretical results for the development of PAIS. However, all these classic approaches have deficiencies related to dependency management in complex application as a consequence of the lack of integration of their basic concepts. To address this problem, the WED-flow approach assumes that data, events and processes are equally important for the development of complex PAIS. In addition, in WED-flow, PAIS is treated as an advanced transactional model [34]. This aspect, overlooked in other approaches, makes the WED-flow approach extremely robust and versatile in exception handling, making it conveniently effective for implementing sophisticated recovery strategies [17], and adaptation [33]. By integrating the orientation paradigms into processes, events, data flow and transactions, the WED-flow approach not only fills this gap left by traditional approaches but also simplifies the modeling and implementation of intrinsically sophisticated business processes.

A WED-flow model is a set of WED-attributes, WED-states, WED-conditions, WED-transitions and WED-triggers. WED-states are attribute values that represent data events and lead workflow execution. A WED-condition is a predicate defined over a specific set of WED-states. WED-condition captures data events and enables triggering of WED-transitions. A WED-transition is a step of WED-flow execution that transforms an input (WED-state) into an output (WED-state). A WED-trigger binds a WED-condition to a WED-transition. Every time the WED-condition of a WED-trigger is satisfied, the associated WED-transition is fired.

The language of the WED-flow approach [17] uses mathematical notation of Set Theory to express their elements. Thus, a WED-flow \(\mathcal {W}\) is a tuple \(\langle \mathcal {G}, c_s, c_f \rangle \) such that:

  • \(\mathcal {A}\) is a set of WED-attributes;

  • \(\mathcal {C}\) is a set of WED-conditions, where each \(c_i \in \mathcal {C}\) is defined on \(\mathcal {A}\);

  • \(\mathcal {T}\) is a set of WED-transitions;

  • \(\mathcal {G}\) is a set of WED-triggers, where each \(g_i=(c_i,t_i) \in \mathcal {G}\) and \(c_i \in \mathcal {C}\) and \(t_i \in \mathcal {T}\);

  • \(c_s,c_f \in \mathcal {C}\) are respectively initial and final WED-conditions.

Despite the clarity and efficiency of the WED-flow language representation, it is necessary to create an intermediate language that bridges the gap between the WED-flow approach and the classical transactional environments that use SQL to implement PAIS. The WED-SQL language fills this gap and will be presented next.

3 WED-SQL: From WED-Flow to SQL

The adoption of a programming language that supports and represents abstractions in a natural and convenient way is fundamental for implementing abstract models efficiently in the software system development.

Although a proper modeling is the cornerstone of a well-designed, robust, scalable, maintainable, and easy-to-extend system, the development through an unsuitable programming language can make the task arduous and complex. The WED-flow approach has its own modeling language that allows expressing its elements in a simple and concise way. Thus, the language of the WED-flow approach is considered for PAIS a Domain Specific Language (DSL).

According to [19], a Domain-Specific Language (DSL) is a programming language of limited expressiveness and focused on a particular domain. DSLs are powerful modeling tools that help to express the model in terms of code by providing developers to use an appropriate abstraction level to the application domain in the system specification. Thus, developers can produce a more expressive and lean code reducing the propensity for errors. A DSL that rigorously captures the semantics of the model increases the communicability of the system code, improving the understanding of business requirements by experts who are not necessarily programmers. In addition, according to [32], a fairly consistent result from error-pattern studies in software development is that the ratio of programming errors to hundreds of lines of executable code has little variation from language to language. Therefore, concise codes are expected to contain fewer programming errors.

Although the mathematical notation of sets employed in the WED-flow approach language is appropriate to represent its abstractions, its direct implementation may not be intuitive and efficient. The conceptual aspects of WED-flow approach can be mapped to the Classical Relational Model. These concepts are supported in the development of execution environment for WED-flows on PostgreSQL DBMS. As a consequence a WED-flow can be not only declared to execute in this environment but also managed through the SQL language.

The WED-flow is an advanced transaction model for the modeling and implementation of PAIS. However, the SQL language does not provide an adequate abstraction level for developers to explore the WED-flow approach in a natural and intuitive way, requiring specific knowledge of SQL to construct extensive and hard-to-understand code queries. A complex query example is described in Code 1.1 in which a WED-SQL expression (in line 2) to list running WED-transitions for a given instance is translated to SQL (lines 3 to 13).

This work proposes a programming language named WED-SQL as an additional feature to the execution environment for specification and management of WED-flows. The WED-SQL is a declarative language with syntax similar to SQL that captures the semantics of the WED-flow model in a simple and direct way. Indeed, WED-SQL works as an intermediate language between the abstract specification of a WED-flow model and its executable implementation, in which the designer declares the model elements in WED-SQL and executes the output code in the relational database execution environment. Upon receiving as input a WED-SQL code, the execution environment will translate it to executable SQL code.

figure a

4 WED-SQL: Formal Description

The WED-SQL language is formally generated from Context-Free Grammar (CFG) described in Code 1.3. In this grammar, the lowercase words are non-terminal symbols, the uppercase words are the tokens and the words in single quotation marks are literal, that is, words that are in their final form. A production rule is composed, in that order, by a non-terminal symbol followed by the character ":" and by a sequence of other terminal and non-terminal symbols that define the valid substitutions to expand the rule. The character "|" indicates alternation, i.e., that the rule can be expanded by more than one valid substitution sequence.

Lines 1 to 4 of Code 1.3 define that a program in WED-SQL (symbol wsql) is a list of statements separated by ";". In turn, a statement (symbol stmt in line 6) is one of the operations defined on the structure of a WED-flow model. The production rules for all valid declarations in WED-SQL are described between the lines 25 and 99. In lines 100–112, the valid formats for the tokens defined by this grammar are described through regular expressions. For example, the token VALID_NAME describes that a valid name for a WED-transition must be a non-empty string that may contain uppercase or lowercase letters, numbers (from 0 to 9) and the character "_".

Except for the WED-SQL commands CREATE WED-FLOW... and REMOVE WED-FLOW... which operate on data meta-structures and control structures of the execution environment, the other WED-SQL commands are translated into SQL code. Thus, the CFG for WED-SQL does not need to specify some structures that are common in both languages because the SQL interpreter of the RDBMS will handle them. For example, the token SQL_STMT used for the creation of a WED-condition does not define a valid predicate because it is analogous to a valid expression of a clause WHERE in SQL. Another example is the token TIME_INTERVAL_STRING that represents the valid formats for time intervals accepted by the RDBMS.

Code 1.2 describes the WED-SQL command syntax to declare a WED-condition. This command is derived from the production rule create_cond_stmt (line 10 in Code 1.3). A complete description of all commands defined in WED-SQL can be found in [5].

figure b
figure c

5 Modeling and Implementation

In this section, we present a concise example of how to model and implement a PAIS using the WED-SQL language and its tools. This example illustrates in a simple manner the operational business model of a travel agency that sells vacation packages containing any combination of flight tickets reservation, hotel room reservation and car rental reservation. We will show in details how the composition of the WED-flow approach elements is able to precisely capture the behavior of processes and to describe their interactions. These interactions are the main guide that conducts the development of an executable model using the WED-SQL language.

5.1 Example: Travel Agency

The travel agency in this example offers three types of reservation services: flight ticket reservation, hotel room reservation and car rental reservation. These services are sold to its clients bundled in vacation packages. The clients are free to assemble a vacation package containing any combination of the offered services. Therefore, a client initiates the acquisition of a new package by informing the agency about his destination, which reservations should be included and the traveling dates. In turn, upon receiving a new order the agency will contact its partner companies and perform the requested reservations. Thereafter, if all the requested reservations were successfully performed, the client can make a payment, receive the confirmation documents and the instance will be finalized. This is an example adapted from [17] taking into consideration the car rental reservation service. Thus, the travel agency model will be described though WED-SQL language because there is a semantic equivalence between the WED-flow mathematical notation and the WED-SQL language (Fig. 1).

Fig. 1.
figure 1

A concise example illustrating the business process of a travel agency

Full size image

Code 1.4 presents the WED-flow description that implements the travel agency example in WED-SQL. In line 1, the command "CREATE WED-FLOW travel_agency" is responsible for instantiate the data meta-structure that will store the elements of this WED-flow declared between lines 4 and 35. This instantiation is required whenever a new WED-flow needs to be created. Once the execution engine manages multiple WED-flows, the command "\cw" in line 2 can be used to select in which WED-flow the remaining statements should be stored.

It is worth to mention that the command CREATE WED-TRANSITION \({<}trans{>}\) is used only to inform the execution engine about a given WED-transition. WED-transitions are responsible for executing self-contained and well-defined tasks. Currently, they are encapsulated by auxiliary services managed by the WED-SQL execution engine as discussed in [30]. Each WED-transition is identified by a unique name used by the execution engine to identify which auxiliary service must be activated in the presence of triggering data events.

figure d

5.2 Execution and Analysis

Once the WED-flow for the travel agency has been defined, it can be instantiated through the WED-SQL command interpreter shell [30]. WED-SQL commands can either be loaded from a file containing the statements or be typing directly into the interpreter prompt. However, before the WED-flow starts, those auxiliary services that implement the WED-transitions must be ready to perform them. This pre-initialization step is crucial to ensure that every data event captured by the execution engine is served as quick as possible. As discussed in [30], the auxiliary services that implement WED-transitions consume very little computational resource when idling, i.e. when they are not performing a WED-transition.

In order to verify that the conceived model works as intended, after the WED-flow has been initialized and the WED-transitions have been properly implemented, we are going to create two instances, \(\alpha \) and \(\beta \), and analyze their execution histories. The instance \(\alpha \) simulates a request for a package including all three reservation services, while the instance \(\beta \) simulates a request that includes only the flight tickets and hotel room reservations. On the WED-SQL command interpreter, \(\alpha \) e \(\beta \) are initialized respectively through the following WED-SQL commands:

figure e

Whenever an instance is created, the execution engine assigns it an execution history. An instance execution history is an incremental log composed of a timely ordered sequence of records containing the data states produced during the life cycle of the instance, along with information describing the execution of WED-transitions and activation of WED-triggers. In that sense, each record describes a data event and has the following structure:

  • wid: instance unique identifier;

  • trw: WED-transition that produced the data state indicated by state;

  • trf: WED-transitions fired following the occurrence of the data state (data event) indicated by state;

  • status: Indicates the instance status where:

    • R stands for regular execution so far (as predicted during the modeling phase);

    • E indicates interrupted execution due to exceptional data event (not captured by any WED-trigger);

    • F indicates that the data state referenced by state satisfies the stop condition (final data state).

  • tstmp: Data event timestamp;

  • state: Data state that represents this data event.

Since the execution history of an instance is built in a iterative manner, the data events are chronologically ordered. As a consequence, the execution of an instance can be observed in real time. In other words, it is possible to promptly notice when an instance finalizes, whether its execution was interrupted by an exception or it reached the final data state, or just to check if everything is being carried out as planned. Every instance receives an unique identifier named wid at the moment its creation. This identifier suffices to retrieve the execution history of a instance, which can be accomplished by the following WED-SQL command:

figure f

Figure 2 shows data events occurred during the life cycle of instance \(\alpha \). This table associates data states with the activation of WED-triggers and, consequently, the firing of WED-transitions. The WED-transition "init_request" is fired when the initial data state s0 is generated by an external event and captured by WED-trigger TGi. Following, the data state s1, generated by the execution of "init_request", is inserted into \(\alpha \) which leads to the simultaneous activation of WED-triggers TGv, TGh and TGa. These triggers fire WED-transitions "reserve_flight", "reserve_hotel", and "reserve_car". Observe that these WED-transitions will execute in parallel and may finish in any order. In particular example, the WED-transition "reserve_flight" ends first, generating the data state s2. Next, the WED-transition "reserve_car" produces the data state s3. Finally, the WED-transition "reserve_hotel" generates the data state s4. The data state s4 aggregates the execution results of the three previous WED-transitions. Since in the particular example the three wed-transitions were successful., s4 is captured by WED-trigger TGf and that fires "fin_request", the last WED-transition. The last data state of \(\alpha \), s5, produced by "fin_request", satisfies the stop condition and the instance is finalized.

Fig. 2.
figure 2

WED-triggers activation sequence for instance \(\alpha \)

Full size image
Fig. 3.
figure 3

WED-triggers activation sequence for instance \(\beta \)

Full size image

The execution history of instance \(\beta \) is presented in Fig. 3. The main difference between instances \(\alpha \) and \(\beta \) is that the vacation package bought in instance \(\beta \) does not include the car rental reservation. Indeed, Fig. 3 shows that the initial data state s0 is captured by WED-trigger TGi and WED-transition "init_request" is fired. However, in contrast to instance \(\alpha \), data state s1 resulting from the execution of "init_request" has the value ‘ignore’ for the WED-attribute "res_car". As consequence, s1 will only activate WED-triggers TGv and TGh, which in turn fire WED-transitions "reserve_flight" and "reserve_hotel", respectively, while WED-transition "reserve_car" will not be executed. The data state s3 represents a successful execution of both "reserve_flight" and "reserve_hotel", implying on the activation of WED-trigger TGf and the firing of WED-transition "fin_request" (see WED-condition Cf in Code 1.4). At last, "fin_request" produces the data state s4, which satisfies the stop condition, and \(\beta \) is finalized.

6 Conclusion

A proper domain modeling is crucial for the development of a robust, flexible computational system, and for the effective solution of a problem. The need to model a system in terms of abstractions became increasingly evident with the increasing complexity of computational systems. These abstractions increase the expressiveness of a model and help not only developers but also business experts to understand the problem, resulting in a more appropriate system design. However, a programming language that provides adequate support for the model abstraction level is fundamental to explore the abstraction power in the system development. A new approach such as WED-flow, which proposes an alternative computation model, requires a programming language designed especially for its application domain and that represents its abstractions in a natural way. Although the mathematical language of the WED-flow approach can be seen as a DSL, its high-level abstraction creates difficulties for implementation in PAIS. In this context, the WED-SQL language has been carefully designed to be the programming language of the WED-FLOW approach. Its main goal is to simplify the implementation of WED-flow models in a transactional execution environment and to ensure that designers, business experts and other collaborators can understand and use all expressiveness power and tools of the WED-flow approach. In this way, we enable the use of the WED-flow approach as a complete modeling and implementation solution for a new generation of dynamic and flexible PAIS. Our ongoing works include the optimization and generalization of the code generation process from WED-SQL to SQL and the use of WED-SQL features in very large automated parallelization processes of PAIS.