semantic matching of components at run-time in distributed environments

Sixth International Workshop on Information Systems in Distributed Environment (ISDE’2015) Rhodes, Greece, 26–30 October 2015

Semantic Matching of Components at Run-Time in Distributed Environments

Javier Criado, Luis Iribarne, Nicolás Padilla, Rosa Ayala

Applied Computing Group, University of Almería, Spain

Sixth International Workshop on Information Systems in Distributed Environment (ISDE’2015)

Rhodes, Greece, 26–30 October 2015

TIN2013-41576-R P10-TIC-6114 “Evolving Dynamic Systems in the Cloud”


Outline •  Background and context •  Adaptation: regeneration process •  COTS-based Architectures and Trading Services

•  Semantic Matching of the Trading Service –  Select the Candidates –  Calculate the Configurations –  Apply a Heuristic Function for Evaluating Configurations –  Closure and Calculation of Compliant Configurations –  Build the Concrete Architecture

•  Conclusions

2

•  Introduction –  Component




•  Conclusions

3



4

Main goal: Dynamic composition of self-adaptive user interfaces

User(s) interactions produce changes in the graphical user interface view.

Background & Context

The behavior interaction between the user and its interface can vary (can be different) depending on the actions each role can do.

In many situations, GUI should be adapted to the user’s needs (not easy).

Pro-active GUI

interaction Roles (user profiles)


5

Mashup interfaces -  Components -  Third party -  Repositories -  Customizable Main problems: -  No self-adaptive -  No self-dependency

(e.g., Netvibes Framework)


Main goal: Dynamic composition of self-adaptive user interfaces


6

Component repositories (appstores)

Organization (own rep)

External (thirds)

The UI is made up of chunks (or pieces) of small components working all together as a unique UI.



7

User (client side) System (Server side) The graphical user interface is considered as an abstraction, that is, a component-based view.

The component-based view represents the architecture of the GUI. The architecture is considered by the system as a model, and it is manipulated by means of Model-Driven Techniques.

This abstraction allow us to manage the GUI.


Architecture View User View


8

(execute)

User (client side) System (server side)

(abstract)

Adaptation process: -  Analyze Context Information -  Analyze User Interaction -  Model Driven Engineering (MDE) -  Model Transformation Engine -  Computational Intelligence

(manipulates at run-tim

e)

J. Criado, D. Rodriguez-Gracia, L. Iribarne and N. Padilla (2015) “Towards the Adaptation of Component-based Architectures by Model Transformation: Behind Smart User Interfaces”. Software: Practice & Experience, Volume 45, Issue 12, pages 1677–1718, December 2015. DOI: 10.1002/spe.2306.


Components Repository (appstores)

External (Third Pary)

From the Organization




•  Conclusions

9



10

Mashup = Component-Based User Interface

These interfaces are made up of coarse-grained components with the aim of building more complex applications from the combination of pieces.

Adaptation: the regeneration approach


11

component 1

component 2 (layers of geographic info)

component 3

component 5

component 4

Mashup = Component-Based User Interface

Five components: a header; a map; a bar chart; a pie chart; and a twitter



12

Adaptation

Software Architecture (initial)

Software Architecture (adapted)

User Interfaces are described and managed as software architectures, and the adaptation process is oriented to change the structure of such architectures by adding, removing, replacing components, or modifying their relationships.


•  changes in the environment •  user interaction •  system pro-activity

Platform Specific View

Abstract View

arises


13

map twitter

map2 twitter4

concrete level abstract level

Initial User Interface Methodology uses two main architectural levels to represent the UI: concrete and abstract level.

The concrete level, identifies the concrete components that form part of the UI.

The abstract level contains the corresponding component types of the UI (an abstraction of all the possible concrete components to be used).



14

map twitter

map piechart Transformation

map2 twitter4

time

histogram twitter


Initial User Interface The methodology uses a Transformation process to be executed under the abstract level at run-time, adapting the UI abstract architecture definition.


1


15

map twitter


Regeneration

map3 piechart1

map2 twitter4

time

histogram twitter

twitter4 histogram1


Initial User Interface Adapted User Interface


1

2

Regeneration process selects the most appropriate concrete components from the abstract definition and builds the new UI.


16

map twitter


Regeneration

map3 piechart1

map2 twitter4

time

Initial User Interface Adapted User Interface

histogram twitter

twitter4 histogram1




17

Regeneration

Heuristics for evaluating the configurations

Concrete Component Repository map

piechart histogram

twitter

map3 piechart1 twitter4

histogram1

abstract architecture

concrete architecture

The proposed regeneration process is intended to build concrete architectures of the User Interface starting from abstract architectures.


Configuration = concrete arch. solution


18

Regeneration

map piechart

histogram twitter


histogram1 R1

R2

R3

RN


Concrete Component Repository



could belong to the same company or from third-

party developers


The construction of the component repository is aimed to be performed from different locations, i.e., different repositories.

Distributed repositories are used to build the new Mashup UI.


19

Regeneration

map piechart

histogram twitter


histogram1

semantic matching of components

at runtime



distributed repositories of components

R1

R2

R3

RN



The regeneration process executes a semantic matching between the abstract definition (the target architecture) and the concrete components available in the repository. In addition, this matchmaking process is performed at run-time.


matching

Run-time


Outline

•  Background and context •  Adaptation: regeneration process •  COTS-based Architectures and Trading Services


•  Conclusions

20



21

Abstract Architecture (to be solved)

A C

B D

A3 C4

B1 D1

Concrete Architecture (solution)

Regeneration

Trader Concrete Component Repository

Exporter (Component developers)

Repository of real components

Importer (Calculation of configurations)

The main part of the regeneration process is a mediation object (i.e., trader). This trader is based on the OMG Trading Object Service specification, and it plays the role as a middleware object between exporter and importer objects.

COTS & Trading


22


A C

B D

A3 C4

B1 D1


Regeneration

Trader Concrete Component Repository

Exporter (Component developers)

Repository of real components


COTS & Trading

Calendar

For instance

Trader matches (C,R)

R

R

C

Let’s suppose the component C is a Calendar component required at abstract level. The concrete component repository (R) holds many different sort of calendar implementations. The trader matches the abstract calendar specification and all those concrete calendar specifications.

etc.


23

The methodology uses a general MDE approach in which both components and architectures of the user interface are managed by means of models.

Mainly models are used in the transformation process but also in regeneration.

COTS & Trading


A C

B D

A3 C4

B1 D1


Regeneration

Trader


models

(Model-Driven Engineering perspective)



24

In order that a trader object can use a common component specification, we developed a (MDE) component metamodel description based on the concept of a COTS component (Commercial Off-The-Shelf), i.e., third-party components.

COTS & Trading


25

Extra-Functional Functional Packaging Marketing

Interfaces: -  Provided -  Required

Properties: -  non-functional attributes -  quality of service features

Information about the implementation and the location of a component

Information about the company

COTS & Trading

F NF

P M

In order that a trader object can use a common component specification, we developed a (MDE) component metamodel description based on the concept of a COTS component (Commercial Off-The-Shelf), i.e., third-party components.




•  Conclusions

26



27

Semantic information used in the matching of the trading process:

•  Heuristics for searching the best configurations.

•  Definition of input and output types for describing the functional interfaces of the components.

–  Set of complex types which contain the structure of data (used as an input or as an output) and imply the description of the behavior of the corresponding operations (functional subtyping).

–  For example, these two interfaces are equivalent because both have two operations matching the input and the output types.

Semantics Trading

Semantic Matching


28

For the construction of the architectural solution (i.e., the architecture of the final user interface), the regeneration process executes a search algorithm, which is based on an A* search algorithm.

(Step) Semantic Matching Algorithm In: Architecture (A) & Repository (R)

#1 Selection of candidates C(R) #2 Calculation of configurations (G1) #3 Application of the heuristics (G2) (if it is a possible solution) #4 Closure of configuration (G3) Compliant configuration (when final solution) #5 Build the concrete architecture (G)

Candidates Configs. Heuristics Closure Compliant Regenerate

Semantics Trading

C(R) < R

Candidates C(R) subset of Repository R G[1,2,3] are subsets of configurations

A < G1 Subset of G2 < G1

C(R) G1 G2 G3 G

G3 < G2 Card(G)=1

Alias


29

A3 B1 D1

A3 A3 B1

In this graph-based search algorithm, each node represents a configuration of concrete components. A configuration is a possible architecture solution.


Semantics Trading

(Step) Semantic Matching Algorithm In: Architecture (A) & Repository (R)

#1 Selection of candidates C(R) #2 Calculation of configurations (G1) #3 Application of the heuristics (G2) (if it is a possible solution) #4 Closure of configuration (G3) Compliant configuration (when final solution) #5 Build the concrete architecture (G)


30

Step 1. Select the Candidates

The selection of candidates is performed by using the abstract architecture and the repository of concrete components.


concrete component repository

A C

B D

A1 A2 A3 B1 B2 C1 C2 C3 C4 D1 D2 …

Sets (clusters) of candidates

Semantic Trader

Matching with operations of A

Matching with operations of B

Matching with operations of C

Matching with operations of D

A1 A2 A3 B2 D1


Semantics Trading

1 2

C(R)

R

architecture repository


31

Step 1. Select the Candidates


concrete component repository

A C

B D

A1 A2 A3 B1 B2 C1 C2 C3 C4 D1 D2 …

Sets (clusters) of candidates

Semantic Trader

Matching with operations of A

Matching with operations of B

Matching with operations of C

Matching with operations of D

A1 A2 A3 B2 D1

Candidate components are grouped in clusters by using the component functional information. A concrete component will be a candidate if it provides at least, one operation (o more) described in some component of the abstract architecture.

1 2


Semantics Trading

architecture repository


32

Step 2. Calculate the Configurations

Search algorithm (characteristics):

−  State: a combination of concrete components (i.e., one configuration).

−  Initial state: empty set.

−  State space: all the possible combinations of concrete components.

−  Successor: adding a new concrete component to the state.

−  Goal: evaluate the concrete architectural model.


Semantics Trading

Set of #a configurations

Configurations: List of concrete architectures fulfilling the requirements of the abstract architecture.


33

A possible solution is one that matches at least with the functional part, although the other parts of the component specifications don’t.

In lines 13 and 31, we can observe this auxiliary storage, when the value of heuristics function of a state is equal to zero.

Due to the run-time nature of the regeneration process, we store a reference to the last possible solution (even if it is not the final solution).

When h = 0 then matches (distance function)


Semantics Trading

NF P M F

solution

Search Algorithm


34

Step 3. Apply Heuristic Function for Evaluating the Configurations


A C

B D

A3 B1 D1

calculated configuration #i ~a

~b ~d ~c ~d

~a ~b a a

configuration a a

~a ~b ~d abstract

architecture a a

~a ~b ~c

~d comparison union union

h = 1 − matchmaking(A,B) = 0 to 100% (a distance)

A B (target architecture) (candidate architecture)


Semantics Trading


packaging

functional

extra-functional marketing

The comparison is made for each component of the configuration. The matching takes into account all parts of the component specifications. matching = [0,1] 0 no match, 1 full mat. CC3 is the concrete component that best meets the requirements fixed by the abstract specification. CC1 seems to be better than CC2: the size the matching score area is bigger.

35

Step 3. Apply Heuristic Function for Evaluating the Configurations


Semantics Trading

matching scores (accuracy of the matching)


36

•  A new evaluation of the matching between the abstract architecture and the current configuration is performed.

•  From this new matching, it is possible to check if the configuration is closed and if the configuration complies with the abstract definition.

•  It is also possible to check if a minimum matching of the extra-functional, packaging and marketing parts is accomplished.

Step 4. Closure and Calculation of Compliant Configurations


Semantics Trading


connector

dependency

provided

required

output port

input port

A3 B5

C2

~a ~d

~b ~c

d.method1 a.method1

a.method1Response

a.method1

a.method1Response c.method1

c.method1

b.method1

b.method1Response

b.method1

b.method1Response

b.method2

A3 B5

C2

A3 B5

C2

~a ~d

~b ~c

Concrete Architecture (view of interfaces) Concrete Architecture (view of ports)

c

b

a

Step 5. Build the concrete architecture Final solution

(configuration of components)

37

Once the final solution has been “found” and checked, the regeneration process builds the concrete architecture (architecture rebuilding). Relationships between interfaces are established, and an equivalent representation using communication ports is defined.


Semantics Trading


38

Prototype ENIA (ENvironmental Information Agent)

Concrete components have been implemented following the OGC standard. OGC = Open Geospatial Consortium

Case Study

http://enia.dreamhosters.com Case Study

REDIAM: Environmental Information Network of Andalusia (Spain)


39

Case Study

Prototype ENIA (ENvironmental Information Agent) REDIAM: Environmental Information Network of Andalusia (Spain)

http://enia.dreamhosters.com Case Study

The GUI constitutes a mashup interface made up of OCG components; in this case by five components.


40

Background & Context Behind the UI a collection of external OGC services repositories exists. Sets of wrappers involve the funtionality of OGC services.

Case Study


41

Prototype ENIA (ENvironmental Information Agent)

Not only OGC services can be included in the user interface as components, but also independent or final applications. Even external components (developed by a third party) are integrated in our system.

Case Study


42

Background & Context Main problem: how to store and analyze the user interaction, which is provided, in many cases, by different kinds of users.

Open research line: Hot topic on big data & machine learning in which we are involved

Case Study


Outline

•  Background and context •  Adaptation: regeneration process •  COTS-based Architectures and Trading Services


•  Conclusions

43



Conclusions “Behind a Smart User Interface Model”

−  A proposal for matching COTS component specifications at run-time.

−  A proposal of Semantic Trader as an extension of the traditional OMG trading function to dynamically rebuild mashup architectures.

−  A proposal for the calculation of the best architectural solutions (concrete level) starting from the corresponding architectural definitions (i.e., the abstract level): bottom-up solution.

−  Semantic Matching (search algorithm) implements a distance function between architectures (comparison of the component specifications) using semantic info.

44

Conclusions


45

P10-TIC-6114 TIN2013-41567-R

Semantic Matching of Components at Run-Time in Distributed Environments

Javier Criado, Luis Iribarne, Nicolás Padilla, Rosa Ayala

Applied Computing Group, University of Almería, Spain

[email protected] http://acg.ual.es

http://enia.dreamhosters.com


46

Contraportada


•  Future work

–  Extend the matching information calculated from the comparison of components and architectures.

–  Evaluate alternative search algorithms for building architectures at run-time.

–  Improve the performance of the matching process and the complete search algorithm.

–  Develop tools for managing (CRUD operations) the information of component specifications and their matchmaking results (i.e., matching scores).

57

Conclusions

Conclusions

semantic matching of components at run-time in distributed environments

Education