MMT-Logo
Sitemap | Deutsch
Home | Education | Research | People | Service | Demos
Funded by


 European Union
European Union


 European Social Funds in Saxony
European Social Funds (ESF-080951805)


 Free State of Saxony (Logo)
Free State of Saxony

Outline

EDYRA-Logo

Project Results and Prototypes

 

Overview

Based on the the concepts propsed in the research project CRUISe, EDYRA strives for the provision of methods and tools enabling end users to develop mashups independently. Essentially, end users are supported by recommendation and appropriate abstraction of technical details, in order to solve their situational problems and tasks.

The target group of EDYRA are non-programmers, domain experts without programming knowledge, who are interested in independently creating custom mashup applications. Such end-users are, amongst others, characterizable as follows.

Another core principle of EDYRA is interweaving usage and development of a mashup application, called Live Sophistication. Thereby, the mashup runtime environment directly provides all necessary means, so that end users get instant feedback on their composition steps.

Besides a purely client-side runtime environment, a distributed solution has been developed within the EDYRA project. Further, repositories of components, mashups and composition knowledge serve as back-end and offer web service interfaces for the runtime environment.

CRUISe
Figure 1: Rough overview of the CRUISe/EDYRA architecture

Semantic Component Description (SMCDL)

The basic component model complies with the one proposed by CRUISe. Thereby, components of all application layers (UI, business logic, data) are uniformly descibed as black-box with a publicly accessible interface. Component internals and implementation details are hidden this way. Components can, for instance, encapsulate or represent REST and SOAP web services, feeds, JavaScript-APIs and widgets.

For the formal description of components we utilize the Semantic Mashup Component Description Language (SMCDL). SMCDL implements the component model and extends it with semantic annotations (c.f. Figure 2). The latter allow for declaring the following dimensions of component semantics by referring to concepts in domain ontologies.

Semantic component description
Figure 2: Overview of the semantic annotations used in SMCDL

Within EDYRA, the declaration of functional semantics has been revised. Capabilities are tuples consisting of <activity, entity, requiresInteraction> and describe, which action/task is performed with/on a certain domain object. Whether or not the end user is involved in the activity, is stated by requiresInteraction. Capabilities can be specified at the level of the whole component as well as interface level. Events themselves refer the capabiltites that cause their occurrance via the attribute dependsOn.

Furthermore, requirements of components regarding their contexts can be declarativley described now (element requirements. This way, it can be stated, that a component requires the runtime environment to provide certain software and/or hardware features, in order to function correctly. It is also possible to express requirements regarding the user, for instance, that the he/she has to have credentials for successful service access. If a requirement affects specific component functionality, this can be declared by referencing corresponding capabilities (attribute capsRef). We utilize SPARQL queries to formalize requirements. During component discovery they are matched with the semantic component descriptions.

Implementation details of components, like dependencies on external JavaScript or CSS files and the constructor code, are declared in the so-called binding.

Additional ressources:

Further reading:

Mashup Composition Model (MCM)

For the declarative description of all aspects of a mashup application, EDYRA largely re-uses the concepts of the CRUISe composition model. Basically, the following application-specific aspects are covered by the composition model:

While in CRUISe the composition model is instantiated utilizing a dedicated authoring tool, and end-user-development has been no focus, the runtime environment of EDYRA provides itself features for creating and manipulating a composition model respecitively. This way, the mashup developer, in context of EDYRA the end user, is not directly confronted with the composition model.

Further reading:

Mediation Techniques for Mashups

Mediation serves for resolving incompatibilities at signature level if possible. To this end, the following mediation techniques have been defined in a diploma thesis based up on concepts presented in a earlier publication:

For each communication channel (explicit like Link etc. and implicit like drag & drop) a mapping definition exists. It declaratively describes the mediation techniques necessary for coupling two compatible signatures S1 and S2 where Si= { parameter-type+ }. Mapping definitions are part of the communication model.

Further reading:

Mashup Development Guided by Recommendations

In EDYRA, end users are guided by recommendations on composition steps like adding and substituting components or integrating whole subcompositions including several channels and components. Thereby, a hybrid recommendation approach is utilized, combining semantics-based techniques and statistical analysis of existing mashup applications to leverage the knowledge of the crowd.

The overall approach has similarities to an adaptation loop, which, separated from the application, includes continuous monitoring of the context and the application, analyzing (i. e., evaluation of trigger conditions and calculating recommendations in terms of patterns), planing (i. e., deriving an action specification), and adapting the application by executing the plan (i. e., implementation of the action specification).

Triggers are entities that start the recommendation procedure. They continuously monitor the application, context and/or user interactions and check conditions to determine whether to set off or not. There are different types of Triggers:

If a trigger fires, it delivers a data structure with all necessary information to the Recommendation Manager. The latter consolidates, filters, and priorizes triggers. Then, useful recommendations in terms of Patterns are queried and ranked for each trigger and shown to the user. Patterns are composition fragments and can be semantically reasoned or mined from existing composition models. For the pattern selected by the user, an Action Specification is derived. The latter states all steps required to integrate a pattern in the running mashup and is executed by the adaptation system.

Architecture
Figure 3: Architectural overview of the EDYRA platform focused on recommendation concepts

Further reading:

CapView

As shown in Figure 3, 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 above: tasks → capabilities and input/output → operations/events.

Exemplified overview of the CapView

Figure 4: Exemplified overview of the CapView

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

Further reading:

Try it out – Platform Prototype

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.

Publications