Re: [viatra-dev] MWE-based transformation chain workflow

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx>]

Hi all,

first of all, thanks for the various feedback. We had a detailed discussion with Ábel and Péter, and found that the problematic syntactical/semantic issues were caused by the merging of two different use cases:

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.

The original implementation was motivated by an incremental model transformation chain, but a combined solution was created with problematic issues (e.g.  whether communication is synchronous or asynchronous, or different naming conventions). Considering the feature set of MWE, the second use case be supported easily, while the first one requires more control to support correctly.

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.
 * 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.
 * 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.

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.

If anyone has any question or remark, feel free to share them. We are planning to implement this approach in July; in the meantime possible alternatives (and issues) can be discussed.

Cheers,
Zoli

-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

> On 19 Jun 2015, at 22:30, István Ráth <rath@xxxxxxxxxx> wrote:
> 
> An important note: the confusion isn’t necessarily just a naming issue. It might very well be the case that all the different Event notions should be unified even on the API level - after all, EVM is supposed to be a generic execution infrastructure and as such I would expect it to be perfectly capable of executing a transformation chain.
> 
> On 19 Jun 2015 at 22:27:10, Lunk Péter (lunkpeter@xxxxxxxxxxx) wrote:
> 
>> Hello,
>> 
>> Firstly, I'd like to thank you all for the useful advice and suggestions. During the course of the next week,  Zoli and I will take a closer look at the naming conventions based on the aforementioned comments.
>> 
>> Also many thanks for noting the errors in the documentation, I'll correct them ASAP.
>> 
>> Regards,
>> Peter Lunk
>> _______________________________________________ 
>> viatra-dev mailing list 
>> viatra-dev@xxxxxxxxxxx 
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit 
>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
> -- 
> 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
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/viatra-dev