[KIEKER-1007] Improve analysis pipes and filters API

[rju]

JIRA Issue: KIEKER-1007 Improve analysis pipes and filters API Original Reporter: Nils Christian Ehmke

---

One should think about improving the current pipes and filters API for Kieker's analysis. The current implementation is not very object-oriented. It is also difficult to add additional mechanisms within the pipes due to the fact that the pipes are not implemented as first class entities.
E.g., in my Master's thesis I have to add additional logic between some filters. To perform this I have to intercept the data in the deliver method. We also intercept some records (meta records) in this method. Both could rather be done with some kind of chain of responsibility or a decorator pattern in my opinion.
Apart from that, we are also working with a lot of maps in 'AbstractPlugin' which use the name of the ports as key. Each lookup requires the hashing of the key.

How should the connecting work instead? A suggestion:

final IProjectContext ac = new AnalysisController();

final TimeReader timeReader = new TimeReader(new Configuration(), ac);
final TeeFilter teeFilter = new TeeFilter(new Configuration(), ac);

timeReader.getRecordsOutputPort().connect(teeFilter.getEventsInputPort());

And the delivering:

this.getRecordsOutputPort().deliver(object);

Advantages:
- The pipes can be implemented as "real" first class entities
- The code would be easier to read
- We avoid working with a lot of strings (e.g., we don't need the input/output port name constants)
- The connecting is object-oriented

Disadvantages:
- We would have to change the API

[rju]

author nils-christian -- Mon, 17 Jun 2013 14:51:09 +0200

In above post I meant of course that the ports are first class entities. The pipes, however, would still not be entities (although this would be possible).

[rju]

author Jan Waller -- Mon, 17 Jun 2013 17:13:53 +0200

Evaluate this in a branch

[rju]

author nils-christian -- Mon, 17 Jun 2013 22:53:41 +0200

I added with 062fa658143c537cdf76f3b9f9f7347242a5a692 a branch (improved-pipes-and-filters-API-KIEK-1007) and "implemented" the CountingFilter with an experimental API. It is not runnable, but it should show how the new API could work.

[rju]

author nils-christian -- Thu, 18 Jul 2013 15:13:20 +0200

As discussed: The approach is not perfect and contains several other problems. Maybe we work on that later again.

The branch has been removed. A tag (improved-pipes-and-filters-API) has been added.

[rju]

author nils-christian -- Thu, 18 Jul 2013 15:24:27 +0200

Renamed improved-pipes-and-filters-API to 1.7-improved-pipes-and-filters-API.