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

Outline
•  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 ViewUser 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
(manipulatesatrun-time)
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

Outline
•  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
concrete level
abstract level
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
map
piechart
Transformation
Regeneration
map3
piechart1
map2
twitter4
time
histogram
twitter
twitter4
histogram1
concrete level
abstract level
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
map
piechart
Transformation
Regeneration
map3
piechart1
map2
twitter4
time
Initial User Interface Adapted User Interface
histogram
twitter
twitter4
histogram1
concrete level
abstract level

17
Regeneration
Heuristics for
evaluating the
configurations
Concrete
Component
Repositorymap
piechart
histogram
twitter
map3
piechart1twitter4
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
map3
piechart1twitter4
histogram1
R1
R2
R3
RN
Heuristics for
evaluating the
configurations
Concrete
Component
Repository
abstract
architecture
concrete
architecture
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
map3
piechart1twitter4
histogram1
semantic matching
of components
at runtime
abstract
architecture
concrete
architecture
distributed
repositories of
components
R1
R2
R3
RN
Heuristics for
evaluating the
configurations
Concrete
Component
Repository
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
•  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
(to be solved)
A
C
B
D
A3
C4
B1
D1
(solution)
Regeneration
Trader
Concrete
Component
Repository
Exporter
(Component
developers)
Repository of real
components
Importer
(Calculation of
configurations)
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
(to be solved)
A
C
B
D
A3
C4
B1
D1
(solution)
Regeneration
Trader
Importer
(Calculation of
configurations)
models
(Model-Driven Engineering perspective)
Concrete
Component
Repository

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

Outline
•  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 < G1Subset 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.
abstract architecture
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.method1
Response
a.method1
a.method1
Response c.method1
c.method1
b.method1
b.method1
Response
b.method1
b.method1
Response
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.comCase Study
REDIAM: Environmental Information Network of Andalusia (Spain)

39
Case Study
REDIAM: Environmental Information Network of Andalusia (Spain)
http://enia.dreamhosters.comCase Study
The GUI
constitutes a
mashup interface
made up of OCG
components; in
this case by five
components.

40
Background & ContextBehind the UI a collection of external OGC services repositories exists. Sets of
wrappers involve the funtionality of OGC services.
Case Study

41
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 & ContextMain 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
•  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-6114TIN2013-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
luis.iribarne@ual.es
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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

Similar to Semantic Matching of Components at Run-Time in Distributed Environments

Similar to Semantic Matching of Components at Run-Time in Distributed Environments (20)

More from Applied Computing Group

More from Applied Computing Group (20)

Recently uploaded

Recently uploaded (20)

Semantic Matching of Components at Run-Time in Distributed Environments