As shown in Figure 1, there are several views on a mashup composition in EDYRA. The LiveView merely visualizes UI representations of components according to their layout. Further views may overlap the LiveView and thus reveal details of the underlying composition logic, suitable for experience and skills of the end user. The ProfessionalView shows all interface details, allows the creation and manipulation of communication channels and offers limited testing facilities. However, no abstraction of terminology of the composition model takes place, so that understanding of technical concepts, data structures and so on is mandatory. This is an issue when targeting non-programmers, of course. In order to overcome this, the CapView provides a task/activity-oriented abstraction of the composition model.
Thereby, the following use cases are facilitated with the help of the CapView. A non-programmer wants to...
Our basic assumption is, that components serve to solve tasks, and that a composition of components can fulfil more complex tasks accordingly. For this purpose, components may require inputs and provide outputs, respectively. That can easily be transfered to the model defined previously: tasks → capabilities and input/output → operations/events.
The CapView is a functionally abstracting view on a Mashup in use or under development (in EDYRA, there is no real distiction in this regard). Basic characteristics of the CapView are (c.f. Figure 2):
After activating the CapView, the end user can see all representations, which overlay the corresponding component and whose labels are in base configuration (c.f. below). In addition, established connections are shown. The end user can select a representation or a particular port, denoted r0 from now on. The set of all connectable representations of r0 is defined as L0 and may be further divided in set S0 ⊆ L0 (representations provding input for r0) and T0 ⊆ L0 (representations consuming output of r0).
After the selection of r0 ...
On of the core concepts of the CapView is the automatic generation of labels. To this end, a Label Generator is employed (c.f. Figure 1), which utilizes a generic rule set mainly based on ontology knowledge as well as a dictionary.
In the simple case of no active selection, a base configuration is derived.
Otherwise, i.e., as soon as a selection exists, context-sensitive label generation takes effect. It has to be noted, that not r0 changes, but all r ∈ L0. Short sentences are created spanning the affected labels in order to clarify cause and effect. To achieve this, dots are appended or prepended, and rj ∈ T0 and ri ∈ S0 are treated differently. Depending on the constellation of the interface parts (either capabilities or properties) represented by the involved r there are basic rules. Additionally, special rules exist taking the semantic relationship of entities und parameters into consideration. For instance, they apply in case of unambiguous mapping definition of output and input parameters (see section Reconfiguration and Figure 5 for examples) or if mediation techniques are necessary (lower example in Figure 4, where a semantic split Event → Location takes place indicated by "location of").
Assumed there is an active user selection, connections to all highlighted suitable representations can be created, established connections can be manipulated and deleted.
In case multiple parameters and/or multiple options the mapping of the latter, the end user has to define the parameter assignment. Thereby, the assignment proposed by the recommendation can be kept or adapted as desired. The example illustrates, that the output parameter of type "Event" is not completely used for searching flights, but only the time and the location of the event (marked by individual input ports in Figure 5). Moreover, the flight search requires several input parameters (point in time, start and target location). That is why there are multiple options to map the event location (indicated by a combo box with two entries in the label of the first input port). If clustering has been applied, the runtime environment is responsible to infer the matching operations or events.
Connections are established via drag&drop or single clicks on ports. In principle, both directions are supported by the CapView (source ↔ target).
The runtime then ensures that all the necessary details according to the composition model are correctly instantiated, so that the connection is functional at the implementation level and therefore in the LiveView.
Here you can find further reading on the CapView, including evaluation results and the formal rules for label generation.
We are continuously elaborating our live demonstrator in order to test and validate the developed concepts.
Although we are working hard on it, please keep in mind that this is a research prototype, i.e, bugs are not unlikely. Therefore, access is currently restricted. Please contact one of the project members if you want to try the demo.
