Event Processor Networks (EPN) are defined in a JSON representation which currently has to be manually specified by the user.

This article discusses the proposed tool for defining Event Processor Networks (EPN) via a web based UI. At this stage we won't be discussing the actual visual representation (graphical or form based) but instead focus on the functionality of the tools.

Graph Editor

This 'editor' will enable an EPN to be built node by node, establishing relationships between the nodes as appropriate.

When focusing on a particular node, it will be possible to select from a range of supported event processors, and define appropriate properties based on the selected implementation. As well as supporting a set of standard predicate and event processors, it should also be possible to "plug in" custom implementations.

IMPL NOTE: Through a suitable abstraction, it should be possible to retrieve definitions for supported event processors and predicates from SRAMP. This would enable users to add custom event processors and predicates by deploying their definition to SRAMP.

When configuring the subjects (e.g. source of events), use subjects defined in existing networks as a potential list of interest. Although would still need to allow the user to define new names.

QUESTION: Issue is how to handle this from a validation perspective? It may only be an error if attempting to deploy into an environment where that subject does not exist. But even then, it may be an ordering issue?

Therefore, when editing a network or node, we need to understand the context and provide an appropriate set of existing subjects that can be used as sources and destinations - which also means catering for predefined subjects.

It should also be possible to use this editor to create templates (see next section) - however the EPN would need to be created as a template, to be able to get access to the additional features only relevant for templates - e.g. definition of a templated scope with parameter definitions etc.

During the definition of a node, it may be necessary to add other artifacts relevant for the selected event processor or predicate (e.g. mvel/drools files, Java dependencies, etc). The editor should provide the means to upload and where appropriate edit those artifacts. Java dependencies should be included as maven GAV details.

Once an EPN has been defined, it should be possible to generate the deployable artifact after performing any appropriate validation. Part of this process will be selecting the target environment (e.g. JEE, OSGI).

IMPL NOTE: possibly the target definition could be defined in such a way that it could be automated to support packaging for new target environments without code change.

FUTURE: It would be good to consider how 'unit tests' could be defined for an EPN - applied to the binary before it is deployed into the target environment (e.g. SRAMP).

EPN Template Instantiator

In some cases, a common template can be used to create the EPN, based on providing parameters to instantiate various nodes within a predefined network. Sometimes these templates may be more complicated, allowing for multiple instances of the same node (or sub-graph of nodes) to be instantiated with an array of parameters. We need to explore some usecases to see how complex it could become, and what level of support we wish to offer.

A template will be very similar to an Event Processor Network. The main difference is that the regions that need to be instantiated would be wrapped in a 'template' construct that would define information about the inputs expected from a user, and then where those parameters would be used. This may also extend to using parameters within the referenced artifacts (e.g. rules/scripts).

Templates can be stored in a repository (e.g. SRAMP) and presented to the user in a list (i.e. name and description). When they select the template, they will be presented with the ability to define values for the required parameters. Once completed, then the EPN can be instantiated.

* Parameters need to be named. If the template represents a repeating group, then those parameters within that group need to be accepted as a set of potentially repeating parameters. We should probably only allow a single level of repetition at the moment, otherwise the UI could become complex.

* Parameter types - each parameter should have a type to help constrain the user input (e.g. string, numeric, boolean, etc).

* Parameter validation - for some parameter types, we may also want to offer additional validation capabilitilies, e.g. integer range, etc.

To guide the user in selecting information, some parameter types can map onto information sources, configured to supply information of the requested type. For example, 'service' may be a defined type - with SRAMP being configured as an information source that can supply information about 'services'. So if an EPN template specifies a field of type 'service', then the user will be given the option to select the information returned from SRAMP (and any other source that identified its support for that information).

To enable instantiated EPNs to be edited and regenerated, the user input should be stored in a separate representation that is linked to the template. When performing the EPN generation from the template, validation would be performed to ensure that all relevant information has been provided. This also means that if the template has been changed in the meantime, any mismatch in the previously provided user input and the updated template can be detected.

Feedback welcome.