Hi, On 25 Jun 2015 at 13:28:34, Ujhelyi Zoltán (ujhelyiz@xxxxxxxxxx) wrote: 1. Event-driven transformation: in this case, the various components are mainly connected via data flow, control flow is very limited (or non-existent). Event-driven transformation steps can be integrated natively, while batch transformations need to be repackaged.
2. Incremental model transformation chain: in this case, the components are connected mainly via an external controller, using explicit control flow. Batch transformation steps can be included clearly, while event-driven transformations needs to be wrapped: when they get control, they have to process all events, and handle them: this way, an incremental transformation can be created.
I think that “event driven” and “incremental” are completely orthogonal aspects. Hence, “incrementality” does not imply anything about control flow, and an “incremental transformation chain” can be event driven or not event driven at all.
Our suggestion is the following:
* We define a common interface for transformation steps, that can be reused between the two approaches. In order to support reusability, the semantics for data exchange is the following: if a step receives an event, it is allowed to process it. In case of a transformation chain, the step must not receive the events before it has control; the semantics for event-driven transformations requires further work.
What is an “event” here and how does it relate to already existing notions in EVM and VIATRA-CEP?
* We replace our existing syntax with explicitly modelled control structures: sequence, decision, loop (and optionally parallelism), and additional data flow can be done using a publish-subscribe model. This would remove most channels from the existing version.
Are these structures already defined in MWE or are we inventing a new script language?
* Event-driven transformations will not be supported at all by this approach; however, the elementary transformation steps might be reused in an event-driven environment (e.g. one that is based on an EVM-based controller). This case will require future research, e.g. to select the correct semantics.
If event-driven transformations are not supported, then why use the “event” terminology?
This approach would handle most issues mentioned either in this thread or in person: the explicit control flow makes it easy to understand, avoids the need for various control channels between the components, and its execution semantics is simple. The most important drawback is that this approach cannot support event-driven transformations, and parallelisation support needs to be added on a language level (if needed). However, I believe, for our current needs this approach would useful, and also allows reusing components for other approaches if we can provide them.
So, in short, if I understand it correctly, we are now using MWE to provide a batch scripting environment where data flow can be orchestrated between transformation steps and control flow is defined using explicit scripting-style structures such as ifs and loops. If this is the case, I’m all for it (as long as we eliminate any mention of “event” from these features), and I believe this was the original idea. cheers --
István Ráth
Research Fellow Fault Tolerant Systems Research Group Budapest University of Technology and Economics http://inf.mit.bme.hu/en/members/rath rath@xxxxxxxxxx |
