Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [viatra-dev] MWE-based transformation chain workflow
The word “Event” is by far the most problematic. EVM uses Events, CEP uses Events, and now our MWE workflow engine uses Events… confusion to the max.

OK, the name of the classes related to the “Event” notion might be slightly different (e.g. EventAtom in EVM vs. IEvent in MWE), but still this should be avoided.

cheers
Istvan

On 19 Jun 2015 at 16:02:31, David, Istvan (davidi@xxxxxxxxxxxxxx) wrote:

Hi,

First of all, the definition of IEventFactory and IEventProcessor is the same: https://wiki.eclipse.org/VIATRA/Transformation_API/MWE2_Integration#Library_Classes. This is clearly by mistake.

>I suggest that we should unify our terminology before others start extensively using this technology
I agree, but this is a more elaborate task as now we have three separate modules (EVM, vCEP and now this) reusing event-based concepts. Also: I would suggest considering the unification of the type system of these components, but this is a future work. (Maybe the EVM-level integration we've been talking about lately will be a solution though, I don't know.)

Regarding the terminology, I found these overlaps between this work's and the one used in CEP. (This is just my take on the topic, feel free to comment.)
-Channel vs Stream - These terms are often used interchangeably. Sure, I never heard about "channel processing" as opposed to "stream processing" - this may have to do something with the volume of data sent through that link between two entities. In CEP, we process a high volume of data, but in this case, the processor has to process sporadic control flows, so "channel" may be a good term after all.
-Event processor vs Event processing engine - Event processors are nodes in a processing workflow, with the possibility to use an event processing engine to address their task. I think we use these terms correctly as we address different levels of abstraction with them.


Cheers,
Istvan



2015-06-17 18:17 GMT+02:00 <varro@xxxxxxxxxx>:
Hi All,

I suggest that we should unify our terminology before others start extensively using this technology - e.g.
I suspect that the VIATRA CEP engine uses quite related terminology (events, streams, etc.).

Dani




From:        Bergmann Gábor <bergmann@xxxxxxxxxx>
To:        "Viatra project developer discussions" <viatra-dev@xxxxxxxxxxx>
Date:        2015.06.17 17:55
Subject:        Re: [viatra-dev] MWE-based transformation chain workflow
Sent by:        viatra-dev-bounces@xxxxxxxxxxx



Hi,

1. I'm trying to understand the Hello World Example based on the wiki page.

BatchTransformationStep.java and EventDrivenTransformationStep.java appear
to be almost the same - how is one of them event driven, while the other
not?
I don't understand the difference between them, as they both process and
send out events.

Also, what does EventDrivenChannel do? Where is the other endpoint?


2. Some of the comments seem inconsistent, e.g.:
               //Create a serializer transformation step
               //Define both m2MChannel as target channel
       transformationStep = ModelModifierStep{
           modifierChannel = MWE2ListeningChannel{channel =
ModifierChannel}
           m2MChannel = MWE2TargetChannel{channel = M2MChannel}
       }


3. The code looks very boilerplaty, and sometimes a bit dizzying to read,
especially the parts like these:

 m2MChannel = MWE2ListeningChannel{channel = M2MChannel}
 changeMonitorChannel = MWE2TargetChannel{channel = ChangeMonitorChannel}

Each of these lines correspond to a single channel, yet has 3 diffent things
called a 'channel'.
Is it possible to rename the classes MWE2ListeningChannel and
MWE2TargetChannel to something more readable, more intuitive, and most of
all, not "*Channel" (which makes them easy to confuse with the actual
channels)?
How about, for instance, these names:

 m2MChannel = ListenTo {channel = M2MChannel}
 changeMonitorChannel = AnnounceOn {channel = ChangeMonitorChannel}

To take a sample from the more complex example as well:

m2TChannel = ListenTo {channel = M2TChannel processor =
ChangeDeltaEventProcessor{}}
serializerChannel = AnnounceOn {channel = SerializerChannel factory =
M2TOutputEventFactory{}}

Seems to work out...
Can be SubscribeTo instead of ListenTo, and PublishTo instead of AnnounceOn,
if we want to stick with standard terminology.

Or, if we are allowed to change the port names as well, we can maybe even
have something like these:

 activateWhen = ListenTo {channel = M2MChannel}
 whenDone = AnnounceOn {channel = ChangeMonitorChannel}

But I'm not sure this style would work on the CPS example - maybe someone
with a better understanding of the domain can siggest meaningful names for
the ports.

Cheers,
Gaben

-----Original Message-----
From: Ujhelyi Zoltán
Sent: Wednesday, June 17, 2015 2:29 PM
To: Viatra project developer discussions
Subject: [viatra-dev] MWE-based transformation chain workflow

Hi all,

Péter Lunk has finished an MWE-based transformation integration workflow,
that supports creating transformation chains from batch and incremental
transformations both, and also created an example and documentation to
illustrate its usage. I have already demoed its earlier version at a
developer meeting, and the feedback from there was useful (and hopefully
included).

As now the implementation seems to work, I would like to ask for another
round of review, and if no further issue comes forth, we plan to include
this feature early in the 0.8 development timeframe.

Links:
* Gerrit change request: https://git.eclipse.org/r/#/c/50176/
* Documentation:
 https://wiki.eclipse.org/VIATRA/Transformation_API/MWE2_Integration
* CPS example implementation:
 https://github.com/lunkpeter/incquery-examples-cps/tree/MWE/addons/org.eclipse.incquery.examples.cps.mwe2integration.example/src/org/eclipse/incquery/examples/cps/integration

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

_______________________________________________
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


_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

Back to the top