Cyber-Physical Systems - Concept, Challenges and Research Areas

Information and Software Technology 62 (2015) 2141
Contents lists available at ScienceDirect
Information and Software Technology

journal homepage: www.elsevier.com/locate/infsof
An adaptive middleware design to support the dynamic interpretation

of domain-specic models
Karl A. Morris a,, Mark Allison b, Fbio M. Costa c, Jinpeng Wei d, Peter J. Clarke d
a
Department of Computer and Information Sciences, Temple University, Philadelphia, PA 19122, USA
School of Computer Science, Engineering, and Physics, University of Michigan-Flint, Flint, MI 48502, USA
c
Instituto de Informtica, Universidade Federal de Gois, CEP 74690-815, Goinia, GO, Brazil
d
School of Computing and Information Sciences, Florida International University, Miami, FL 33199, USA
b
a r t i c l e
i n f o
Article history:
Received 7 November 2013
Received in revised form 7 February 2015
Accepted 9 February 2015
Available online 15 February 2015
Keywords:
Models at runtime
Adaptable middleware
Domain independence
Domain specic classier
a b s t r a c t
Context: As the use of Domain-Specic Modeling Languages (DSMLs) continues to gain popularity, we
have developed new ways to execute DSML models. The most popular approach is to execute code resulting from a model-to-code transformation. An alternative approach is to directly execute these models
using a semantic-rich execution engine Domain-Specic Virtual Machine (DSVM). The DSVM includes
a middleware layer responsible for the delivery of services in a given domain.
Objective: We will investigate an approach that performs the dynamic combination of constructs in the
middleware layer of DSVMs to support the delivery of domain-specic services. This middleware should
provide: (a) a model of execution (MoE) that dynamically integrates decoupled domain-specic knowledge (DSK) for service delivery, (b) runtime adaptability based on context and available resources, and
(c) the same level of operational assurance as any DSVM middleware.
Method: Our approach will involve (1) dening a framework that supports the dynamic combination of
MoE and DSK and (2) demonstrating the applicability of our framework in the DSVM middleware for
user-centric communication. We will measure the overhead of our approach and provide a cost-benet
analysis factoring in its runtime adaptability using appropriate experimentation.
Results: Our experiments show that combining the DSK and MoE for a DSVM middleware allow us to
realize efcient specialization while maintaining the required operability. We also show that the overhead introduced by adaptation is not necessarily deleterious to overall performance in a domain as it
may result in more efcient operation selection.
Conclusion: The approach dened for the DSVM middleware allows for greater exibility in service delivery while reducing the complexity of application development for the user. These benets are achieved at
the expense of increased execution times, however this increase may be negligible depending on the
domain.
2015 Elsevier B.V. All rights reserved.
1. Introduction
Model Driven Software Development (MDSD) has become a
widely used paradigm in the area of software engineering with
its growth increasing in recent years [20,43]. As a result of the
growth of MDSD there has also been much interest in DomainSpecic Modeling Languages (DSMLs), particularly, the graphical
version of DSMLs [19,26,27]. Conventional approaches to using
DSMLs focus on model transformation utilized in other areas of
Corresponding author.
E-mail addresses: karl.morris@temple.edu (K.A. Morris), markalli@umint.edu
(M. Allison), fmc@inf.ufg.br (F.M. Costa), weijp@cis.u.edu (J. Wei), clarkep@cis.u.
edu (P.J. Clarke).
http://dx.doi.org/10.1016/j.infsof.2015.02.003
0950-5849/ 2015 Elsevier B.V. All rights reserved.
software engineering, where models in one language are translated

into another language prior to execution, e.g., models created in
UML are translated into Java [31,34]. A developing trend in this
area is to remove the steps involved in conventional model translation, and to instead execute the models directly. This approach
requires a semantically rich environment which is able to interpret
models at this level of abstraction.
A class of DSMLs that supports model execution using a semantically rich execution engine is referred to as Interpreted DomainSpecic Modeling Languages (i-DSMLs) [11]. An i-DSML execution
engine is one approch that provides a facility for the direct execution of models by using a 4-layered architecture, where each layer
receives and performs operations on an increasingly granular view
of the model, before passing the transformed version of the model
22
K.A. Morris et al. / Information and Software Technology 62 (2015) 2141
to the next layer in the stack. We will refer to an i-DSML execution

engine as a Domain-Specic Virtual Machine (DSVM). The rst
DSVM to use the 4-layered architecture was the Communication
Virtual Machine (CVM), which interprets Communication Modeling
Language (CML) models in the user-centric communication domain
[15,54]. Another DSVM, currently under construction, that uses a
similar architecture is the Microgrid Virtual Machine (MGridVM),
which interprets Microgrid Modeling Language (MGridML) models
in the energy management for smart microgrid domain [13].
The four layers in the DSVM are: (1) user interface allows users
to declaratively specify models using an i-DSML; (2) synthesis
engine takes models as input at runtime and, based on the
changes between the current runtime model and new model, generates control scripts to be processed by the next layer (model synthesis); (3) middleware executes the controls scripts to manage
and coordinate the delivery of domain services; and (4)
broker provides an API to the middleware and interfaces with
the underlying platform to realize the services required.
The work presented in this article focuses on the middleware
layer of the DSVM, which has responsibility for managing and
coordinating the delivery of domain services. To achieve this objective the middleware interprets control scripts received from the
synthesis engine layer and events received from the broker layer
in the DSVM, by loading macros and executing them. These control
scripts, and more specically the commands found therein, are
tightly coupled to the domain of the instantiated DSVM and the
associated i-DSML. The initial design of the middleware for the
CVM, the rst DSVM, is presented by Deng et al. [15], however this
work provides few, if any details on the implementation of the control scripts and macros used to realize a communication scenario.
Wu et al. [53] provide additional details regarding the control
scripts and macros used in the CVM middleware.
The use of DSVMs to interpret i-DSML models has applications
in several domains, as previously mentioned, and therefore their
efcient instantiation is a desired property in order to reduce engineering time and effort, and programming errors. In order to
achieve the efcient instantiation of a DSVM in our approach, we
must (1) dene the domain-specic knowledge (DSK) and the
model of execution (MoE) for each layer of the DSVM and (2)
and efcient method of combining the DSK and MoE during instantiation of a DSVM. This approach would reduce the engineering
time required for the instantiation of a new DSVM instance by
allowing the reuse of domain-independent artifacts. More
specically in the context of our work, the DSK would include
the domain-specic commands that comprise the control scripts,
and the macros associated with each of these commands.
In this article we present a design for the middleware layer that
supports the dynamic integration of DSK and MoE to realize
domain-specic applications using a DSVM. This work builds on
previously published work by Morris et al. [33] in the following
areas: (1) design of a complete execution model for the middleware in DSVMs, (2) denition of a complete implementation of
the middleware including model generation, selection and
execution, and (3) the demonstration of the architectures applicability in the user-centric communication domain. Our major
contributions with respect to designing a DSVM middleware are
as follows:
1. A mechanism and necessary artifacts for the proper representation of the domain-specic knowledge (DSK) and model of
execution (MoE) for a given domain.
2. A method to dynamically combine domain-specic artifacts to
realize the semantics of operations within a domain.
3. A study to determine the impact on execution times of
dynamically combined functional components in the middleware layer of the CVM.
Section 2 describes background knowledge relevant to the work

presented in this article. Section 3 details the motivation for this
work and the problems we address. Section 4 presents an overview
of our approach. Section 5 denes several concepts key to the
dynamic execution of constructs to realize domain semantics.
Section 6 describes the design of the DSVM middleware. Section 7
presents our ndings based on experiments conducted using the
DSVM middleware prototype. Sections 8 and 9 contains the related
work and conclusion, respectively.
2. Background
In this section we introduce an approach to the execution of
domain-specic models that is based on changes to models at runtime. These domain-specic models capture the end-users requirements for an application using various concrete syntaxes, including
graphical models, text models, and models captured in a userfriendly interface. To execute these models a DSVM is used as an
interpreter which consists of a four-layered architecture. One of
the layers in the DSVM is the middleware which will be the focus
of this paper. After introducing the execution of domain-specic
models we will provide an overview of middleware, specically,
the adaptive nature of middleware.
2.1. Execution of domain-specic models
DSMLs allow end-users to easily generate solutions for problems
in their respective domains since the solutions are created using
abstractions closer to the problem space [19,26,27]. Conventional
approaches to realize DSML models usually requires these models
to be converted into source code in a traditional high-level language
(HLL) using a series of model-to-model and model-to-text transformations. This source code must then be compiled and executed. An
alternative approach is to execute these domain-specic models
directly using an execution engine. We refer to the languages used
to create these models as Interpreted Domain-Specic Modeling
Languages (i-DSMLs) [11] and the execution engine as a
Domain-Specic Virtual Machine (DSVM).
In our opinion, the execution engines used to interpret i-DSML
models can be considered as a virtual machine based on the taxonomy of virtual machines presented by Smith et al. [42]. DSVMs
can be classied as dynamic translators i.e., HLL VMs. Note however, we are moving to a higher level of abstraction, from HLLs to
domain-specic models. In the subsequent subsections we introduce i-DSMLs and DSVMs. As previously stated our research team
has worked on two DSVMs, the Communication Virtual Machine
(CVM) in the user-centric communication domain [15,54], and
the Microgrid Virtual Machine (MGridVM) in the energy management for smart microgrids domain [13]. In this article we will
focus on the CVM.
2.1.1. Interpreted domain-specic modeling languages
An i-DSML can be described as a ve-tuple, similar to a DSML
[8], consisting of: a concrete syntax, e.g., graphical models; abstract
syntax that denes the language syntax and integrity constraints;
semantic domain, containing the domain-specic knowledge; a
mapping that assigns syntactic constructs to elements in the
abstract syntax; and a semantic mapping that relates abstract syntactic concepts to the semantic domain. The main difference
between the traditional DSMLs and i-DSMLs is that the semantics
of traditional DSMLs describe how to transform models into source
code for a given HLL. The semantics for i-DSMLs dene how the
application captured by the model is executed to realize the intent
of the user requirements without rst transforming the model into
an HLL.
An i-DSML model may either be a control schema or a data

schema, which is based on concepts of the program and data,
respectively, as described by Plotkin [36]. The control schema species the logical conguration of some set of requirements (functional and non-functional) for an application in the domain. The
data schema contains instances of domain types and user-dened
types as specied in the control schema. We use the terms control
instance and data instance to refer to fully instantiated schemas,
similar to objects in the OO paradigm. There are three concrete
syntax notations used to represent i-DSML schemas, these include
a graphical representation, a user-friendly interface representation,
and an XML-based representation.
The following scenario from the user-centric communication
domain will be used throughout this article to illustrate various
aspects related to i-DSMLs and DSVMs, specically related to the
middleware.
Scenario: Following Dr. Burkes surgery on Baby Jane, he returns
to his ofce and contacts Dr. Monteiro, the attending physician, to
let him know the results of the surgery. During the conversation
Dr. Burke shares several aspects of the patients medical records
with him, including the post-surgery echocardiogram, images of
the patients heart captured during the surgery, and the vital signs.
Fig. 1 shows the control schema and two data schemas for the
medical scenario presented above. The control schema shown in
part (a) represents the conguration for the communication and
the media types used across the connection. The data schema
shown in part (b) initiates the audio video connection, while the
data schema in part (c) initiates the patient record to be sent as
a form. For more details on the metamodel (abstract syntax and
static semantics) for CML, see Wu et al. [54].
2.1.2. Domain-specic virtual machines
The DSVM design is based on the architecture used rst in the
CVM and then in the MGridVM. The DSVM uses a four-layered
architecture described as follows:
User Interface (UI) provides the user with an environment to
specify their domain requirements using either a graphical
model or a user friendly interface. The UI then transforms the
i-DSML model into an XML-based representation for processing.
23
Synthesis Engine (SE) synthesizes models by comparing the

current runtime model with a new user-dened model. Based
on the changes between the models and the current state of
the SE, control scripts are generated to be executed by the
middleware.
Middleware (M) executes the commands in the control scripts
in order to manage and coordinate the delivery of domain services. During the execution of these scripts user-dened policies
may be applied to the delivery of services.
Broker (B) provides an independent API to the middleware
that hides the heterogeneity of the underlying services provided
by frameworks and controllers. The broker also interprets
underlying events from the frameworks and controllers and
generates events to be handled by the upper layers in the
DSVM.
Based on the domain, the layers of the DSVM are specialized to
service that specic domain. Fig. 2 shows the specialized layers of
the CVM. The CVM middleware (User-Centric Communication Middleware UCM) is responsible for interpreting control scripts for
the user-centric communication domain, resulting in the delivery
and management of communication services. These services may
include sending les to all parties in a connection, encrypting/decrypting les, starting/stopping audiovideo streams and applying
communication polices. The UCM realizes the delivery of services
by making calls to the Network Communication Broker API. A list
of the methods available in the Network Communication Broker
API is shown in Table A.7 in Appendix A.
The MGridVM middleware (Microgrid Control Middleware
MCM) interprets control scripts in the energy management
domain, resulting in the delivery and management of energy management services for microgrids. These services may include mapping groups of physical devices to logical controllers, executing
energy management algorithms, and applying policies to various
device congurations [11]. Note that we described the functionality of the MCM to demonstrate ongoing research in the applicability of the DSVM middleware in a domain other than usercentric communication. However, our focus in this paper will be
on the middleware in the CVM, the user-centric communication
middleware (UCM).
Fig. 1. CML Models for the scenario. (a) Control schema. (b) Data schema-1. (c) Data Schema-2.
24
Fig. 2. Layered architecture of the Communication Virtual Machine (CVM).
Fig. 3. EBNF-like structure of the CVM control scripts.
Fig. 3 shows the structure of the control scripts generated during model synthesis using EBNF-like notation. The rules of the control scripts are shown using an attributed grammar, where the
keywords are shown in bold and the attributes are denoted by a
subscript. For example, Rule 1 states that a control script may contain one or more script commands and Rule 2 shows the various
commands. Rule 5 states that the addParticipantCmd consists of

the keyword addParticipant and takes two parameters: a connection id and a list of one or more participant ids.
The table in Fig. 4 shows an example of the control scripts
generated during the synthesis of the CML instances show in
Fig. 1. CIn and DIn represent the nth instance of the model used
25
Fig. 4. Control scripts generated during the synthesis of the CML instances in Fig. 1. CIn represents the nth control instance being synthesized. Similarly for the data instances.
during synthesis. The initial instance with subscript 0 is referred to

as the null model and is the initial runtime model. For each pair of
models, the one with the higher subscript is the new user model
received by the synthesis engine to be processed.
The control script generated in row 1, column 2 of the table represents the scripts to establish a connection with the other participant in the communication. That is, a request is made to
create a connection, then the control schema is sent to the other
participant to be negotiated on. For more details on the synthesis
process we refer the reader to the work by Wu et al. [54].
based on system context allows it to change based on the availability of new information and/or resources. This feature is useful
for systems to provide guarantees on their operation. One obvious
concern of adaptable systems is the general overhead intrinsic to
the monitoring and adaptation process when compared to
non-adaptable systems [9]. This concern must continuously be
addressed and new research in adaptable systems must balance
the granularity of adaptation with the required responsiveness of
the system.
3. Motivation
2.2. Adaptive middleware

Recently there has been a plethora of research on the design of
middleware for emerging paradigms and technologies, including
pervasive computing [39], internet of things [4], and ubiquitous
computing [46], among others. This research has resulted in various approaches to develop middleware, including middleware
with various execution models, adaptive middleware, various patterns and frameworks for middleware design, and different reference models for the middleware. In this section we will
introduce the characteristics of middleware that are relevant to
our work.
There are many denitions and types of middleware described
in the literature [6,51], we use a more generic denition which
states that middleware is any software that allows other software
to interact [12]. Any middleware should provide services to the
interacting software. Vinoski [51] identies these services as:
directory, transaction, security, management, event, persistence,
load balancing, and conguration. In addition to the services
provided by the middleware, Schmidt et al. [41] identify several
characteristics that a successful middleware should have, these
include: affordability, extensibility, exibility, and reliability.
Our work will focus mainly on adaptive middleware and the
services it provides. Adaptive middleware, as with adaptive systems in general, allows for the monitoring and reconguring of
its structure and/or behavior at runtime [18]. This is achieved
through various introspection mechanisms such as those
employed during reection. Adaptability is a desired property in
many systems and one that is inherent to DSVMs. Adaptable middleware is a cornerstone of many of todays complex systems that
require interoperability and context awareness.
Sadjadi [40] presents a taxonomy of various adaptable middleware approaches, and provides a detailed comparison of each.
Examples of such domains and systems include multimedia
[24,52], communication [30,38,47] and generally systems that
incorporate distributed architectures or have deadlines and require
end-to-end quality of service [22,44]. The ability to adapt a system
The middleware design we are proposing for DSVMs should

provide most of the services identied by Vinoski [51], and yet
be structurally similar to that presented by Schmidt et al. [41]. This
subset of Vinoskis features provided by our middleware is necessitated by the design of the DSVM, which has migrated some functionality, such as interacting with hardware devices, to other layers
within the stack. The middleware design presented by Schmidt
et al. shows how services are organized into contextual layers,
these layers are as follows:
Domain-specic services provides services tailored to the
requirements of specic domains, e.g., telecom, microgrid, and
health care, among others.
Communication services provides the application layer with
the code required to develop distributed applications using
the lower-level middleware.
Distribution services provides a higher-level distribution programming model to the communication services layer.
Host infrastructure services encapsulates and enhances native
OS mechanisms, e.g., interprocess communication, concurrency,
and synchronizations of objects among others.
Since our middleware will be used in a cross-section of
domains, the composition of services provided by the middleware
will vary depending on the domain. For example, in the CVM there
is a need for many of the services associated with a distributed
environment, while in the MGridVM this is not the case, since
the current MGridVM design is mainly centralized. Fig. 5 [11] illustrates the need for a highly congurable middleware design that
can be easily composed during the instantiation of the DSVM.
In addition to having a highly congurable middleware, there is
also a need for the individual middleware services in a given layer
to be adaptable. As an i-DSML is a declarative language, it states
non-functional requirements without specifying how these
constraints should be applied to the functional requirements at
runtime. Due to this limitation, our middleware design must have
26
Fig. 5. DSVM specialization during instantiation.
the capability of dynamically determining the operational semantics of a command to be executed based on the system context and
policies that are in place.
Based on our work on the design of the middleware for DSVMs
the following features are necessary for the interpretation of iDSML models at runtime.
Variable Operation Multiple ways of realizing user intent. For
example, operation to send a le may be done with or without
encryption based on the users intent. This allows our middleware to provide higher assurance of its functionality by being
able to realize the users intent through varying execution
paths.
Formal Validation A mechanism for the middleware to formally validate that the operation complies with predened constraints. We have developed an approach that uses rst order
logic to validate models, representing the users intent, to
ensure they conform to user policies [32]. By validating operations of the middleware we are able to ensure that a set of
operations will not violate any active policies in the system
while attempting to realize the users intent.
Dynamic Composition The ability to dynamically build functional constructs to realize delivery of services, which is part
of the structural adaptation process [46]. This allows the full
enumeration of potential execution paths by allowing the middleware to determine at runtime what operations can be
executed based on available resources.
Functional Augmentation The ability to dynamically change
domain-specic behavior of the middleware at runtime. Our
current design allows new procedures to be added to or
removed from the DSVM middleware at runtime.
Programming Model Refers to the ability of the middleware to

use its own programming model during the realization of the
middleware services. This program model focuses on
dynamically building call chains of procedures to be executed,
type checking of procedures based on descriptors, managing
state, and so on. The programming model is used by procedure
designers to build their functionality.
Table 1 shows a summary of the middleware features in seven
middleware designs and the one presented in this paper for the
DSVM. Raychoudhury et al. [39] does a comprehensive comparison
for common middleware for pervasive computing across three
dimensions, including programming abstractions, system architecture, and system services and runtime support. Tigli et al. [46] also
presents a comparison of several middleware used in ubiquitous
computing, using features such as structural adaptation, behavioral
adaptation, heterogeneity, and extensibility, among others. The criteria we use are different to those used by Raychoudhury et al. [39]
and Tigli et al. [46] due to the design and responsibilities of the various layers of the DSVM. One architecture in particular (OpenCOM
[13]) is discussed and compared in detail in Section 7 due to the
notable similarities in design and capabilities. The remainder are
discussed in more detail in Section 8.
One other characteristic mentioned by Schmidt et al. [41] is
affordability. As a DSVM is created for a new domain it is would
not be cost-effective to build the middleware for that DSVM from
the ground up using a stove-pipe approach. To mitigate the cost
to develop a DSVM middleware, our middleware design should
separate the Domain-Specic Knowledge (DSK) from the Model of
Execution (MoE), thereby making the MoE reusable. In addition, if
the DSK is separated from the MoE, it may be possible to capture
27

Table 1
Middleware feature comparison.
Middleware
Features
Variable oper.
Kramer et al. [28]

Zachariadis et al. [55]
Bellur et al. [5]
Madl et al. [29]
Verssimo et al. [50]
UCM Ver. 1 [56,53]
OpenCOM ReMMoC [14]
DSVM
Formal valid.
Dynamic compos.
Funct. aug.
Prog. model
U
U
U
U
U
U
the domain knowledge during feature analysis [25] of the domain.

Assuming the MoE can be successfully applied in multiple DSVMs
then it can be classied as a generic model of execution (GMoE).
Our focus in this paper will be to develop a DSVM middleware
design that is congurable during instantiation, provides adaptation at runtime, and separates the DSK from MoE. We will show
how this design will be applied to the CVM middleware. Our future
work will show how the generic model of execution can be applied
in multiple domains.
4. Overview of approach
In general the middleware of a DSVM achieves service delivery
through the execution of a control script received from the Synthesis Engine and through the processing of events received from the
Broker layer. Upon receipt of a control script, the middleware parses and extracts the scripts individual commands and executes these commands in the context of the current state of the middleware.
As a result of the execution of these commands, calls are made to
the Broker layer, the lowest layer in the DSVM, or events are sent to
the Synthesis Engine layer to be processed. Similarly, upon receipt
of an event the middleware parses the event and either passes it to
the Synthesis Engine or executes the command that this event
maps to.
The current design of the middleware used in the rst version of
the CVM [15] was not originally created to be used in other DSVMs
as there was a strong mapping between the functionality of the
middleware and the rst class operations of the domain. However,
Allison et al. [2,3] show that the four layered design of the CVM can
be applied to a DSVM for energy management in smart microgrids
(MGridVM). As previously stated in Section 3, to achieve the effective and affordable instantiation of DSVMs for different domains, it
is necessary to separate the domain-specic knowledge (DSK) from
the model of execution (MoE) of the platform.
The objective of this article is to present a generic design for the
middleware layer of DSVMs, depicted by the ovals in Fig. 5, that
supports the dynamic integration of the DSK and MoE to achieve
service delivery. More specically, we focus on a design of the middleware for a DSVM that supports the (1) separation of the DSK
from the MoE and (2) dynamic integration of the DSK and MoE
at runtime for the user-centric communication domain. In this section we introduce the MoE, shown as a workow, representing the
interactions between the main processes for a DSVM middleware.
Fig. 6 shows an overview of the workow for the execution of
control scripts and events in a DSVM middleware, based on the
dynamic combination of the DSK and MoE. Each stage of the process is explained as follows:
1. Parsing. Processes the control scripts and events entering the
middleware. The control scripts shown in Fig. 3 are represented
as a string and the event as an event object.
U
U
U
U
U
U
U
U
U
2. Command Classication. Matches a command to a domain specic classier (DSC) in order to begin the IM generation process.
DSCs and their relationship with commands is discussed further
in Section 5.1.
3. Candidate Model Generation. Based on the DSCs received, candidate IMs are generated to perform the required domain-specic
functionality. These candidate IMs are generated using the
appropriate procedure descriptors for the procedures available
in the repository. Procedures are discussed in Section 5.2 and
the IM generation process is described in Section 5.4.
4. Model Validation and Selection. Using the IMs generated in Step
3, a subset of available IMs is selected that conforms to system
or user-dened policies. The resulting IMs are then passed to a
cost function which selects the best model based on some predened analysis and the current middleware state.
5. Model Execution. The selected IM is executed by dynamically
loading procedures from the repository based on the DSCs
and procedure descriptors contained in the IM. This process is
discussed further in Section 6.1.2.
The repository shown in Fig. 6 stores the static DSK in the form
of procedure descriptors and procedures that would be dened
during instantiation of a DSVM for a given domain.
We will use the scenario described in Section 2.1.1 to illustrate
how the middleware for the CVM achieves service delivery using
the workow for execution shown in Fig. 6.
5. Intent model design
In this section we describe the structure of intent models (IMs)
and the relationships between their components. First we describe
the IM components including domain specic classiers (DSC),
procedures and execution units, then present the concept of an
IM. Briey stated, a DSC is used to catalog the domain-specic
knowledge (DSK) in terms of attributes and operations used by
the middleware; an execution unit is a set of instructions that
accomplishes a single task; and a procedure is a structure that integrates one or more execution units and binds it to a DSC.
5.1. Domain specic classiers
Domain specic classiers (DSCs) form a taxonomy that catalogs the attributes and operations used by the middleware to realize the commands in a control script. These attributes and
operations capture the DSK and are manually created based on
the services to be delivered in the given domain. DSCs provide a
common point of reasoning for the commands in the control
scripts and the policies governing the behavior of the middleware.
For the proper instantiation of the middleware in a particular
domain, a set of DSCs must be provided that capture all rst-class
domain-specic operations and attributes.
28
2. Command
Classification
DSCs
Commands
Control
Script or
Event
1. Parsing
3. Candidate Model
Generation
Matching
Models
4. Model Validation
and Selection
Intent Models
Procedure Descriptors
Repository
Procedures
Callback Model
5. Model
Execution
API Calls and Events
Fig. 6. Model of execution workow for a DSVM middleware.
A Domain Specic Classier (DSC) is dened as a 4-tuple

N; NS; P; K where:

N a name is a string that is unique in a given namespace (NS).

NS a namespace denes the scope for a given name.
P a list of parameters expressed as DSCs.
K a kind, such that K 2 {ATTR, OPER}, ATTR represents an attribute and OPER an operation.
DSCs have a one-to-one mapping to the commands a middleware can respond to, that is, for each command that may appear
in a control script there is one associated DSC. On the other hand
DSCs have a one-to-many mapping to procedures used to realize
actions in the middleware, where a given DSC may have several
implementations that realize a command in the control script.
The selection of the appropriate procedure is based on user-dened preferences and the current state of the middleware. We provide additional details on the selection process later.
The procedures associated with DSCs must inherently possess
semantics relevant to a domain and should therefore be composed
through a feature analysis [25] of said domain. For example, in the
user-centric communication domain the DSCs map to commands
that are required to perform tasks such as (1) establish a connection, (2) add participant to a connection, and (3) send a le to users
in a connection. There may be several procedures associated with a
DSC and are able to carry out the task the DSC describes, for
example, the DSC to send a le may have the procedures (1)
SendBasic send le as is and (2) SendSecure where the le is
encrypted to ensure secure transmission.
DSCs that describe operations may, as a part of their denition,
state parameters that are required for the completion of those
operations. These parameters are themselves DSCs. For example,
the DSC which describes sending a le, Send, would include a
DSC for the name and path of the le to be sent, FileURI. Therefore,
any procedure which conforms to the Send DSC must expect and
handle the FileURI parameter.
Table 2 shows a set of DSCs for the user-centric communication
domain. These DSCs are used in the middleware for the Communication Virtual Machine (CVM). The table consists of four columns
representing the name, namespace, parameters and kind, used in
the denition of a DSC. The top ve rows show DSCs that are attributes and the bottom four rows show DSCs classied as operations.
5.2. Procedures
The procedure is the key entity used to capture the DSK for a
given domain, specically the semantics associated with the
various domain-specic actions. Procedures are the operational
constructs that undertake the domain-specic operations
Table 2
A set of DSCs from the user-centric communication domain.
Name
Namespace
cml-Model
leURI
plainTextFileURI
encryptedFileURI
homeNetwork
send
receive
encrypt
user_comm
user_comm
user_comm
user_comm
user_comm
user_comm.nonstream
user_comm.nonstream
user_comm.nonstream
decrypt
user_comm.nonstream
Parameters
leURI
leURI
plainTextFileURI,
encryptedFileURI
encryptedFileURI,
plainTextFileURI
Kind
ATTR
ATTR
ATTR
ATTR
ATTR
OPER
OPER
OPER
OPER
described by the DSCs of a particular domain, and must be provided along with DSCs for the middlewares instantiation.
A Procedure (P) is dened as a 6-tuple I; N; C; EU; EU 0 ; D where:
I the unique identier for P
N the human readable name of P
C a classier for the procedures function, where C 2 fDSCg,
and fDSCg is the set of all domain specic classiers for a given
domain
EU the set of execution units contained in P
EU 0 is the starting execution unit where EU 0 2 EU
D is a list of dependencies in P expressed as DSCs, where
D fDSCg and 8d 2 D; d P:C; P:C refers to the DSC that classies procedure P.
From an implementation perspective, we may view a procedure
as an ordered collection of executable units, along with a list of
DSCs on which it depends to perform its task. The procedure is thus
comprised of two parts:
1. The descriptor, which provides the necessary meta-data for the
procedure including: name (N), the unique identier (I), DSC
(C), starting execution unit (EU 0 ), and dependencies (D).
2. The set of executable units (EU) which undertake the operations
of the procedure including manipulating state information,
making API calls, and invoking other execution units and
procedures.
The dependencies (D) of a given procedure P are a proper subset
of the set of DSCs and does not contain the DSC stated in P. This is
because our initial design does not allow recursion (direct or indirect) of procedures.
An execution unit (EU) is a set of instructions that are executed
as an atomic unit and performs some group of operations to
achieve the objective of its parent procedure. An EU may perform
any number of allowed system operations; however it is limited to

making a single API call to an interface external to the middleware.
This constraint facilitates greater management of event responses
and provides ne granularity of operations within a procedure.
An execution unit may be triggered as the initial step of a procedure, by another EU within the same procedure, or in response to
internal or external events, such as a timer or a message from a
remote middleware instance respectively.
5.3. Intent models
An intent model (IM) is a tree where the nodes are procedures,
and the children of a procedure, if any, are generated based on
the list of DSC dependencies contained in that procedure. The root
of an intent model is a procedure whose DSC matches that of the
control script command that triggered the intent models generation. Fig. 7 shows the process of composing IMs starting from
the manual creation of the execution units and DSCs on the left
of the gure. The execution units are shown as small circles and
the DSCs represented as small squares. The execution units and
DSCs are composed to create procedures, shown as the large
squares in the center of the gure. Each procedure contains a
DSC that is uniquely associated with the procedure, shown at the
top of the procedure; the execution units, in the center; and the
ordered list of DSCs, shown at the bottom of the procedure, with
an arrow signifying the dependencies between the DSCs.
During execution of a control script command, the middleware
generates IMs using the available procedures, the environment
state, and the user-dened preferences. The IMs generated are
shown on the right side of Fig. 7, with the links between the DSCs
in each procedure also shown. The generation of an IM is discussed
further in Section 5.4. To reduce complexity, we dene a well
formed intent model as meeting the following criteria:
Singly classied This prevents a node from having multiple
parents.
Unique procedural dependence A model must have only one
dependence of a given type. As such, we speak of the set of
dependencies to indicate the nonexistence of duplicates.
Fig. 8 is an UML class diagram showing the structural relationships between IMs, procedures, DSCs and execution units. An IM is
an aggregate of procedures hence the relationship procedureList. There is a unique mapping between a DSC and a procedure through which the procedure is classied, and a procedure
has an ordered dependency list of DSCs. Each procedure also owns
one or more execution units. Recall a DSC may be classied as an
attribute or an operation, which is consistent with the denition
of DSCs.
5.4. IM generation
As previously described, an IM is a tree that contains procedures
as nodes, with the initial executing procedure as the root of that
tree (see right side of Fig. 7). A procedure with stated dependencies
forms the root of its subtree, and its children are procedures that
match said dependencies. The leaves of the tree are procedures
that have no stated dependencies. An IM is built by matching the
DSC of a command to the DSC of all available procedures. For a
given procedure, we recursively walk its dependencies until no
additional dependencies are required. If any dependency cannot
be met, that model is eliminated from consideration. This might
occur if the repertoire of procedures provided to the middleware
is incomplete, or if meeting a stated dependency would introduce
a cycle. An exception is raised and passed to the Synthesis Engine
29
of the DSVM if the middleware is unable to generate a valid intent

model for an executing command.
Algorithm 1. Intent model (IM) generation.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
function generateIMs(initDSC, procList)

/ initDSC DSC associated with the control script
command being executed
procList list of procedures in middleware repository/
matchingIMs
null / Collection of IMs that will be
returned /
matchingProcs
procList.getMatchingProcs(initDSC)
/ Get procedures for
current DSC /
if matchingProcs.isEmpty() then
return null;
end if
for all proc 2 matchingProcs do
tempMatchingIMs
null /Temporary collection of
IMs for current level /
dependDSC_List
proc.getDependency()
if dependDSC_List.isEmpty() then
/If no dependencies, return IM with current
procedure /
matchingIMs.add(new IM(proc))
else
subIMs
null /Stores the sub IMs returned from
the recursive call /

countDSC
0
for all dependDSC 2 dependDSC_List do
countDSC
countDSC + 1
/Recursive call to generate new IMs for each DSC
in the dependency list /
subIMs
generateIMs(dependDSC, procList)
if subIMs null then
if countDSCs 1 then
/For the rst DSC in the list create a new
IM /
singleIM.add(new IM(proc))
/Merge the new single IM with the
sub-IMs /
tempMatchingIMs
mergeIMs(singleIM,
subIMs)
else
/Merge the temporary matching IMs with
the sub-IMs /
tempMatchingIMs
mergeIMs(tempMatchingIMs, subIMs)
end if
else
tempMatchingIMs.clear();
end if
end for
matchingIMs.addAll(tempMatchingIMs)
end if
end for
return matchingIMs
end function
Algorithm 1 shows the generateModels() function that builds

IMs using DSCs and procedures. The function generateModels()
takes two parameters, initDSC the DSC associated with the control script command, and procList the list of all the procedures
for the specied domain. The variable matchingIMs stores the IMs
30
Intent Models
Procedures
Execution Units
and DSCs
Automatic
Manual
Legend
DSC
Procedure
Execution Unit
Fig. 7. Generation of intent models.
1
DSC
-name : String
-kind : Kind
-namespace : String
Algorithm 2. Merging parent intent models and children intent

models.
0..*
initialProc
procedureList
enumeration
Kind
+ATTR
+OPER
dependencyList
0..*
Before another procedure in the current list of matching procedures is processed, the variable holding the temporary IMs is
added to the matching IMs, line 38, which is then returned by
the generateModels() function, line 40.
parameters
IntentModel
-id : UUID
-name : String
Procedure
-id : String
-name : String
maps_to
ExecutionUnit
-id : String
-body : String
owns
1
1:
2:
3:
4:
5:
6:
0..*
initialEU
7:
8:
Fig. 8. Class diagram for an intent model.
created during the current invocation of the function generateModels(). Line 5 of the algorithm identies the procedures
that form the roots of the subtrees, these procedures are stored in
the variable matchingProcs. Lines 7 through 9 check to see if
the matching procedures list is empty and if so, the null value is
returned. The loop shown between lines 10 and 39 builds all the
IMs for the initial DSC. Line 12 assigns the list of DSCs for the current procedure being processed into dependDSC_List. If this list
is empty then a single-procedure IM is created from the current
procedure and added to the current IMs (see line 15).
If the DSC dependency list is not empty then the list is traversed
(see loop between lines 19 and 35), and sub IMs are created and
added as children to the current IM being created. For each DSC
in the dependency list, dependDSC_List, a recursive call, line
22, is made to generateModels() with parameters, dependentDSC the DSC being processed in the current loop iteration,
and procList the list of all procedures. The IMs returned from
generateModels() are assigned to the variable subIMs.
If the sub-IMs container, subIMs, returned is not empty, line 23,
and the loop is processing the rst DSC in the container, line 24,
then a single IM is created using the procedure being processed,
line 26. This single IM is then merged with the other sub-IMs by
invoking the mergeIMs function and the returning container is
assigned to tempMatchingIMs. If the DSC being processed in the
loop between lines 19 and 35 is not the rst DSC, then the IMs in
tempMatchingIMs are merged with the sub-IMs, line 31, and
assigned to tempMatchingIMs. If the sub-IMs container is empty
then the temporary variable tempMatchingIMs is cleared, since
no IMs are returned from the recursive call.
9:
10:
11:
12:
13:
14:
15:
16:
function mergeIMs(parentIM_List, subIM_List)

/ parentIM_List list of parent IMs
subIM_List list of intent models for the children /
newIM_List
null / Collection of IMs that will be
returned /
for all parentIM 2 parentIM_List do
/ Loops through subIM list and creates a new IM for
each subIM /
for all subIM 2 subIM_List do
/ Performs a deep clone of the parent IM to
the new IM /
newIM
deepClone(parentIM)
/ Adds the subIM procedure list to the root of
newIM/
newIM.addSubtree(subIM)
newIM_List.add(newIM)
end for
end for
return newIM_List
end function
The mergeIMs function, shown in Algorithm 2, takes two parameters, a parent IM list and a sub-IM list. The sub-IMs represent a
set of IMs where the root of each IM is a child of a parent IMs. The
merge function replicates the parent IM for each of the IMs in the
sub-IM list. For example, given a list of 3 parent IMs and a list of 4
sub-IMs the merge returns a list with 12 IMs, representing the new
parent list in the calling function.
A consequence of our method of dening and dynamically composing models based on types is model space explosion. In theory,
an idealized set of procedures may produce an excessively large
number of intent models that match a particular command. The
issue arises due to the Maximum Product Partition problem [16],
where for a given set of procedures P, there exists a partitioning
based on DSCs that creates a maximal number of models. While
this may not prove to be a limiting factor in practice, as a typical
command may only relate to a small subset of the available procedures, it is still a motivating factor for addressing optimization
concerns in the design and implementation of the various facets
of the middleware, and will be addressed in future work.
31
6. DSVM middleware design

The DSVM middleware design describes the main artifacts of
the MoE that are needed to interpret a control script command,
including IM generation and selection, and the execution of the
IM to realize the management and delivery of services in a specic
domain. We start by presenting the structural design of the middleware which includes a package diagram of the components of
the middleware, followed by other class diagrams showing the
renement of the interpreter component. We end by describing
the behavioral design for the interpreter component, focusing on
IM generation and selection, and its subsequent execution.
6.1. Structural design

The DSVM middleware consists of ve main components as
shown in Fig. 9. These components include: (1) m_manager
coordinates the activities of the middleware; (2) m_interpreter
responsible for interpreting control scripts from the DSVM synthesis engine and the events from the broker; (3) m_repository
contains the DSCs, procedures and the execution units; (4)
m_events handles events from the DSVM broker and generates
events to be handled by the synthesis engine; and (5)
m_exceptions processes local exceptions for the middleware
and converts the exceptions to be handled by the synthesis engine
into events. Fig. 9 shows the dependencies between the ve main
components in the middleware.
There are three classes shown in Fig. 9 including (1)
M_SE_Interface exposes the interface to the synthesis engine
that receives control scripts; (2) Broker::Broker_M_Interface
exposes the API of the broker to the middleware, the operations
in this API are invoked by the middleware interpreter; and (3)
SE::SE_EventHandler is the synthesis engine handler for
events raised in the middleware. In this section we will focus
mainly on the generation, selection and execution of IMs which
is done in the m_interpreter.
Fig. 10 shows the structure of the middleware interpreter.

The activities of the interpreter are coordinated by the
Interpreter_Controller, and it processes calls from the controllers in the middleware manger package, m_manager:: Mng_
Controller, and events package, m_events::Evt_Controller,
respectively. The two main functions of the interpreter are to (1)
generate and select IMs in the im_generator package and (2)
execute the selected IMs in the im_executor package. The
im_generator package depends on the m_repository package
since the denitions for the procedures, DSCs and execution units
are stored in the repository.
For each control script command the im_generator package is
responsible for generating a set of applicable intent models and
selecting a single IM which is stored in the Interpreter_
Controller. The im_executor package executes the IM in order
to realize the users intent specied in the control script command
being processed.
6.1.1. IM generator
Fig. 11 shows the components used in the generation, selection
and validation of IMs. The Generator class is responsible for generating the IM to be used by the im_executor in the interpreter.
As previously described, IMs are generated using Algorithms 1
and 2 presented in Section 5.4. The Generator class accesses
Selector
+getBestModel()
+generateIMs()
+mergeIMs()
m_repository
m_exceptions
se::SE_EventHandler
broker::Broker_M_Interface
m_events
Fig. 9. Package diagram showing the main components in the DSVM middleware.
m_manager::Mng_Contoller
Interpreter_Controller
im_executor
Fig. 11. Class diagram for im_generator package.
M_SE_Interface
m_manager
+validateModels()
m_intentModel
m_repository
m_interpreter
Validator
Generator
m_events::Evt_Controller
im_generator
m_repository
m_intentModel
Fig. 10. Class diagram for the m_interpreter package in the DSVM middleware.
32
the list of persistent DSCs, procedures and execution units from the
middleware repository, and uses the package m_intentModel to
build the IMs. After all the IMs have been built the Generator
class invokes the Validator class to ensure that each IM satises
the constraints placed on the IM by user-dened or system policies. Currently, our approach to IM validation involves walking
the graph of the IM to determine the presence or absence of a procedure classied by a specied DSC. We plan to develop a more
robust method of validation in future work.
After building the set of IMs based on the control script command received by the middleware, the Selector class identies
the most appropriate IM for execution through a domain-specic
cost analysis mechanism. For example, in our prototype we dene
the function f IM such that
f IM
n1
X
costIMi
to perform dynamic compilation and loading of source code; the

StateManager which stores the current runtime state of the
executor as a list of States; and the Call type which represents
the several types of calls, as shown in the inheritance relation on
the left of the gure.
The DSVM middleware structural design presented in this section, and shown in Figs. 912, is one with very low coupling
between domain-specic (DSK) and domain-independent (MoE)
entities. There are two types of domain-specic entities in the
DSVM middleware, these are: (1) entities related to the creation
of IMs, which are DSCs, procedures and execution units, and they
are all located in the package m_repository; and (2) the
domain-specic events and exceptions in packages m_events
and m_exceptions. A description for the IM components was previously presented showing how the domain-specic aspects were
separated from the MoE.
i0
where n is the number of procedural nodes in the model and cost

takes a procedure IMi and returns a deterministic cost associated
with it.
6.1.2. IM executor
The im_executor package is one of the main packages in the
DSVM middleware interpreter (see the interpreter package diagram in Fig. 10). The im_executor is responsible for executing
either the IM generated by the im_generator package or processing an event callback from a previous IM execution. The classes for
the im_executor package, shown in Fig. 12, are described as follows. The Executor class is responsible for coordinating the
execution of IMs and event call backs. The Executor class is
dependent on: the broker_M_Interface class, which exposes
the API for the broker layer; the EventRegister class, which registers events that the interpreter expects to process in the future;
and the EventCallBack class, which contains the data for the
IM, procedure and execution units to be triggered when a specic
event is raised from the broker layer following an EventWaitCall
by a previously executing model This is described in more detail in
Section 6.2.
The other classes and packages associated with the Executor
class are: the m_intentModel package which contains all the
classes associated with the structure of an intent model, see
Fig. 8; the org.compiler.library package that supplies a library
State
-name : String
-value : Object
1..*
6.2. Behavioral design

In this section we describe two state machines that show the
behavior of the middleware interpreter and the execution of an
IM. We have already described the process to generate IMs in Section 5.4 and will not repeat it here. The state machine for processing a command or an event in the middleware interpreter is shown
in Fig. 13. The state machine consists of 2 simple states Ready and
PreambleExecuted, and 4 submachine states ProcessCmd,
ProcessEvt, GenerateIM, and ExecueModel. After the middleware
interpreter is created it enters the Ready state. Upon receipt of a
control script command it enters the submachine ProcessCmd and
the command is processed. If an event is received the state
machine enters submachine ProcessEvt and the event is processed.
After processing the command in ProcessCmd the generateIM
method is invoked and the submachine GenerateIM is activated.
Submachine GenerateIM is dened by Algorithms 1 and 2. If there
is a special precondition that needs to be satised before the model
can be executed then a preamble is executed and a transition is
made to state PreambleExecuted if there is a successful result.
Otherwise the model is not executed. An example of a preamble
may be negotiating with the middleware in other DSVMs in a
distributed environment prior to the execution of the IM, e.g.,
distributing a key for an encryption algorithm prior to sending
an encrypted le. After the preamble is successfully executed or
singleton
StateManager
-manager : StateManager
+persistState(in obj : Object)
EUCall
1
DSCCall
-dsc : DSC
EventWaitCall
-eventId : String
Call
-eUId : String
* 1
Executor
-model : IntentModel
-currentProcedure : Procedure
+executeIM(in im : IntentModel)
+executeProc(in p : Procedure)
+executeEU(in eu : ExecutionUnit)
+loadProc(in p : Procedure)
+reenterProc(in callingP : Procedure)
org.compiler.library
m_intentModel
Fig. 12. Class diagram for im_executor package.
m_events::EventRegister
* m_events::EventCallBack
-modelId : String
-callbackProcDSC : DSC
-eUId : String
33
/ generateIMs(initlDSC, procList)
2.ProcessCmd
im_Generated [preExecCond] / executePreamble()

4.GenerateIM
cmdReceived / processCmd(Cmd)
/ generateIMs(initDSC, procList)
5.PreambleExecuted
im_Generated [!preExecCond] / executeIM(im)
1.Ready
[preambleSatisfied] / executeIM(im)
3. ProcessEvt
evtReceived / processEvt(Evt)
[!preambleSatisfied] / exception
6.ExecuteModel
[callBack] / executeIM(im)
1.Ready
Fig. 13. State machine for processing a command or event in the middleware interpreter.
if there is no precondition then the IM is executed using the

submachine ExecuteModel.
A similar path is followed to that of the command when
processing an event in Fig. 13. The salient difference is that if the
event is a callback event, then there is no need to generate an IM
as one would have been previously created and stored in the interpreter state. If the event is a callback then the IM is loaded to the
submachine ExecuteModel where execution resumes. After the IM
has been executed the interpreter returns to Ready.
Fig. 14 shows the state machine for executing an IM, and it contains 5 states. The machine starts and goes into the Ready state and
when a model is received it transitions into the ModelReceived
state. At this stage the initial procedure is loaded and moves to
the ProcedureLoaded state. If the IM is not associated with a
callback event, then the initial execution unit is invoked and a transition is made to the EUExecuted state. If the IM to be executed is
associated with a call back event then the execution unit for the
callback IM is invoked. The machine remains in the EUExecuted
state if the execution unit being processed makes a call to a
subsequent execution unit within the same procedure.
Alternatively, an execution unit may make one of three transition calls: (1) a null call, which is made when the current procedure
completes execution, and the calling procedure is re-entered,
transitioning to the ProcedureLoaded state; (2) a DSC call, where
execution descends to a dependent procedure in the IM, also transitioning to the ProcedureLoaded state; or (3) an event wait call,
where the IM and associated state is made persistent, transitioning
to the ModelPersisted state, awaiting the receipt of the specied
event. After the model and sate are made persistent the machine
goes into the Ready state.
7. Experimental study
In this section we describe experiments to evaluate the efciency and efcacy of a prototype implementation of our DSVM
middleware using the design described in Section 6. We compare
the results of the user-centric middleware (UCM) using both the
new design, in our prototype, against the previous implementation of the UCM using the design presented in Deng et al. [15]
and summarized in Section 8.3. In order to perform the experiments needed to evaluate the two implementations a set of procedures and appropriate DSCs were created for scenarios in the
user-centric communication domain that allowed us to use the
new UCM prototype. Additionally, we compared our new prototype to the performance of another architecture OpenCOM
[14] that employs dynamic component composition in its
execution. Following are the objectives of our experimental
study:
1. Determine the execution time overhead for the intent model
(IM) generation process in our middleware for a standard
domain deployment.
2. Compare operation execution times between the previous
implementation of the UCM using a domain-coupled design
and the new design that decouples the domain-specic knowledge (DSK) from the model of execution (MoE).
2.ModelReceived
[typeOf(DSCCall)] / loadProc(proc)
[typeOf(EUCall)] / executeEU(eu)
/ loadProc(initProc)
[return && !initProc] / reenterCallingProc(P)

[typeOf(EventWaitCall)] / persistState()
4.EUExecuted
3.ProcedureLoaded
1.Ready
5.ModelPersisted
[!callback] / executeEU(initEU)
[return && initProc]
[callback] / executeEU(callbackEU)
Fig. 14. State machine for executing an IM.
1.Ready
34
3. Compare and contrast the operational times of our architecture

to another platform that incorporates similar execution and
architectural semantics.
Our experimental study consists of three experiments two
performed wholly in a lab setting, and a third that relied on a comparison to published results each addressing the objectives previously mentioned. For each experiment we describe the method,
the setup that was used, the results obtained, and comment on
the effectiveness of the study including threats to its validity.
7.1. Experiment I
7.1.1. Objective
The objective of the rst experiment is to determine the execution time overhead for the IM generation process in our middleware for a standard domain deployment.
7.1.2. Method
We designed this experiment to measure the runtime overhead
of our IM generation process in a realistic scenario. To do this, we
curated a test environment where we initialized a prototype with
a set of 100 procedures to simulate a typical middleware layer
implementation based on our analysis of the user-centric communication domain. This analysis was performed by Wu et al. [54]
and details the operations of the communication domain. Of the
provided procedures, 10 were designed to either match the operation of the test command, or meet a dependency such that they
would realize the maximum partition sum bound [16]. The other
90 procedures simply added to the middewares workload to
ensure the system would analyze a large set of procedures while
only selecting a subset, as would be expected during normal operation. This meant we would generate the largest possible set of wellformed IMs from this set of 10 procedures. Based on Wu et al. [54],
we claim that this workload supersedes the basic requirements of
the communication domain, and therefore provides a valid analysis
of the expected overhead generated by our approach.
The entire process was performed using procedure descriptors
(meta-data) which can be loaded independently of the execution
units. These descriptors contain information on the classication
of procedures, as well as their dependencies.
7.1.3. Setup
Experiments were performed on a 64-bit Fedora Linux based
machine with 4.00 GB of memory and a quad core Intel i7 4-core
CPU clocked at 1.8 GHz per core. Our system ran the OpenJDK
JRE version 1.7.
7.1.4. Process
As detailed in Listing 1, we rst created a set of 10 procedures
and associated DSCs from the communication domain that would
result in the desired set of generated intent models.
Listing 1. Scenario artifacts.
35
In Listing 2 we generated a set of dummy procedures to simulate the existence of resources not associated with the current
command being executed.
Finally, in Listing 3 we perform the model generation, validation
and selection steps detailed in Section 6.1.1:
7.1.5. Results
Our set of 100 procedures resulted in the generation of 36 IMs
(3 3 2 2) which are detailed below. We validated our model
against a DSC known to be present in all IMs, therefore ensuring
that no models were eliminated from the candidate list, and
passing all 36 models to the model selection phase. Finally our prototype selected a model for execution based on procedure count,
this selection was done using our naive cost analysis implementation that uses the number of procedures as the cost factor. The
evaluation results are presented in Table 3.
7.1.6. Discussion
The values in Table 3 provide us some guidance on the expected
execution times involved in generating, validating and selecting
IMs in response to commands and events. We perform one round
of model generation steps (generation, validation and selection)
for each cycle. The increase in cycles was performed to measure
the middlewares response under consistent requests, and was
chosen to exceed the expected workload of the domains currently
being investigated.
Recall we used the procedure descriptors to generate the IMs
that can be loaded independently of the execution units. This
reduces the overall memory footprint of a procedure to the bare
minimum required for the generation of an IM. Execution units
need only be fetched into memory at the time of execution. As
the results of our prototype evaluation show, we are able to perform the full generation, validation and selection process in the
order of micro seconds. We believe that these results demonstrate
the appropriateness of our architecture for many domains, even
those that may have a very high responsiveness requirement such
as smart electrical grid management [2].
As depicted in Table 3 and illustrated in Fig. 15, we are not only
able to generate intent models within the requirements of highresponse domains [3], but we are also able to generate these intent
models with increasing efciency as we increase cycles. This is due
Table 3
Model generation timing.
Generation cycles
1
10
100
1000
10,000
100,000
Model generation time (ms)

Min
Max
Average
Total
114
10
3
1
1
1
144
105
108
111
112
118
114
36
8
2
1
1
114
366
817
2205
13,632
125,899
Fig. 15. Minimum, maximum and average model generation times.
in part to our implementation that can more efciently manage

procedures that are already resident in memory.
7.1.7. Threats to validity
Although the results in Table 3 provide us an estimate of the
cost of generating, validating and selecting IMs in a given domain,
we acknowledge that the operating times depend heavily on the
denition of domain operations and the resulting granularity of
procedures and DSCs. The time complexity of model generation
is on the order of N 2 , where N is the number of available
procedures, and model execution time increases proportionally
with the granularity of procedures and execution units. The space
Listing 2. Dummy artifacts.
Listing 3. Scenario execution.
complexity of our model generation process is also ON 2 , which is

salient in our analysis as it may have a measurable effect on memory access times for a non-trivial amount of procedures. Additionally, our prototyping environment did not incorporate changing
system or environmental contexts, which could result in reduced
operational time, or incur additional memory requirements.
We attempted to normalize the inherent non-determinacy of
Javas JIT as presented by Georges et al. [21] through large sets of
cycles to determine timing, as well as presenting various statistical
measures. However, we acknowledge that some aspects of achieving full analysis of the Java Virtual Machine remain unaddressed.
7.2. Experiment II
7.2.1. Objective
The objective of the second experiment is to compare development artifacts and operation execution times between the previous
implementation of the UCM using a domain-coupled design and
the new design that separates the DSK form the MoE.
7.2.2. Method
This experiment consisted of three parts; the rst will analyze
the source code of both platforms, while the second two are
intended to compare the execution times of a real world scenario
that involves transferring a single 10 megabyte (Mb) le in both
an encrypted and non-encrypted form. This scenario was introduced in Section 2.1.1. The le transfer was performed on the rst
version of the UCM (version 1) that is context-unaware, and on the
new prototype of the UCM (version 2) that is context-aware.
First we perform a static analysis of the source code of both
platforms. Table 4 shows the static metrics for the two versions
of the UCM. Note that number of packages and classes in the
UCM version 2 is greater than in version 1. This is expected as
our implementation: (1) incorporates the additional functionality
entailed in the model generation process; (2) facilitates event handling, which is a requirement of distributed execution of middleware procedures; and (3) must facilitate generic operations of a
DSVM middleware, and not only the identied operations of the
communication domain. The UCM version 1 implementation possesses more lines of code than our implementation. This is attributed to the fact that UCM version 1 incorporates the domain-specic
code in its implementation, e.g., the ability to encrypt and decrypt
les, while UCM version 2 ofoads all domain-specic code to procedures and their execution units.
For the runtime analysis component of the experiment, the
measurements are broken down into 3 areas:
1. The time to generate an IM (if needed) including access to the
repository to load the necessary meta-data.
2. The time to load the needed components for adaptation.
3. The time to perform domain-specic tasks that are external to
the middlewares core operations, if required, such as encryption a data le.
This section of the experiment compares the total times
required to transfer the le using both the naive approach, performed on UCM version 1, and the context-aware approach, performed on UCM version 2.
Table 4
Static metrics for the two versions of the UCM.
UCM version 1 [15]

UCM version 2
Packages
Classes
Methods
LoC
5
14
26
33
103
117
1402
1176
This experiment was performed using an unoptimized

approach where components were not preloaded into memory prior to IM generation. This was done to (1) present a less than ideal
case to demonstrate that our approach still performed reasonably
well despite the added overhead, and (2) we found that when optimization strategies were applied, Java did not provide us with the
necessary timing resolution to make any conclusive claim about
the differences.
For our adaptive system (UCM version 2), we curated similar
environment to the previous experiment where a set of 10 procedures were used to generate 36 models that were able to perform
the requested operation. We again added populated the runtime
procedure list with the meta-data of 90 dummy procedures for a
total of 100. This far outnumbers the required procedure set for
the average instance of the two domains we have investigated so
far, namely the user-centric communication and microgrid energy
management.
7.2.3. Setup
The two UCMs used for both parts of the experiment were
executed on Java version 1.6 using Eclipse Helios Service Release
2 [17]. Both UCMs incorporated the Janino Java compiler [49] for
runtime class loading on a Windows 7 Enterprise based machine
with 4.00 GB of memory and a dual core Intel CPU clocked at
2.40 GHz per core.
7.2.4. Results
The results for the rst part of the runtime analysis experiment
are shown in Fig. 16, which consists of a bar chart where each bar
shows the execution time for a different type of le transfer. From
left to right the chart shows the bars for an unencrypted le, a context-aware unencrypted le, an encrypted le, and a contextaware encrypted le. The context-aware le transfer requires the
use of IM generation to determine the type of le transfer required
(UCM version 2). Note that in the context-aware le transfer the
overhead for IM generation is less than 11% when compared to
loading the components that are used in both versions of the
UCM. The two bars on the right of Fig. 16 show a comparison of
the time taken when a 10 Mb le is encrypted before sending. In
this scenario the IM generation for the context-aware system is
2% of the total time used to process the le transfer request.
The results for part two of the runtime analysis experiment are
shown in Fig. 17. The gure contains a graph showing two lines
representing the execution times for a context-unaware le transfer and a context aware le transfer respectively. The line representing the context-unaware le transfer is for the UCM version
1 and the line for the context-aware le transfer is for the UCM
version 2 that supports runtime adaptation. Note that we assume
that UCM version 1 always encrypts les to be transferred. This
choice was made since most of the communication scenarios used
Model generation
Time (ms)
36
Component loading
Encryption (10 MB)
5000
4500
4000
3500
3000
2500
2000
1500
1000
500
0
Unencrypted
Context-aware
unencrypted
Encrypted
Context-aware
encrypted
Fig. 16. Execution times (in ms) for the variable le transfer operation.
37

Context-unaware transfer
Context-aware transfer
50
45
40
Time (s)
35
30
25
20
15
10
5
0
100% Encrypted
50/50
100% Unencrypted
Fig. 17. Execution times (in s) for the simulated transfer of 10 les.
for the CVM, containing UCM version 1, were taken from the
healthcare domain, which has strict security constraints. Alternatively, the le transfer operations could have been done without
encrypting the les and the execution time would be a horizontal
line lying between 10 and 15 s. Note however, this would be a
violation of the healthcare privacy law [48].
7.2.5. Discussion
As both systems incorporate Java language reection through
runtime code compilation and loading, they both experience
degraded performance compared to direct execution of an operation in a non-adaptable system. However, as UCM version 1 does
not incorporate any context-aware adaptation, and because it does
not compose its operational facilities from multiple components, it
has a slight advantage in arriving at the point of execution a little
faster compared to our proposed solution. Acknowledging this disparity, we make the following observations:
1. Although slower on arriving at an execution plan due to IM generation, UCM version 2 can achieve much lower execution times
by composing its IMs from more efcient procedures based on
system context. As an example, consider the case of removing
the requirement of including an encryption procedure when
performing a le transfer if the current connection or network
is already secure.
2. Due to the lack of policy awareness within the UCM version 1,
the CVM must expose operational variability at the language
level. This will invariably: (1) increase the complexity of designing a CML model as there are more elements in the language
and (2) decrease the level of assurance in the execution of an
operation as a CML model may incorporate elements which
do not comply with current system policies.
3. To reduce the number of cases of CML models not meeting
needed business policies (such as HIPAA [48]), and to mitigate
the necessity of modifying those CML models by users that
may lack the necessary technical knowledge, CML models
designed for UCM version 1 may choose the most strict operations (such as encrypted le transfers in place of unencrypted).
This design choice, which addresses the issues listed, may result
in longer execution times than is required as the current system
context may not, for instance, require that a le be encrypted
prior to transfer.
management domain [1,2] currently viewed as a centralized

domain. These domains may not be representative of how the
UCM would be used in DSVMs for other domains. In addition, the
preliminary design of the DSVM UCM for the microgrid energy
management domain (MGridVM) is missing functionality related
to forecasting energy use over some time period, or optimizing
the use of energy in islanding mode.
One other threat to the results presented in the second experiment is that we compared the behavior of our architecture (UCM
version 2) to the approach used in UCM version 1 (naive approach,
which is context-unaware), when there are other solutions that
could have been used. We believe this is a necessary comparison
as it gives a clear picture of the trade-offs of incurring model generation overhead to achieve context aware functional adaptation.
In the next experiment, we compare our architecture to another
dynamic framework to better gauge the performance of our design.
7.3. Experiment III
7.3.1. Background
ReMMoC is an OpenCOM-based mobile middleware platform
for the communication domain that is able to dynamically modify
its operating parameters based on the availability of communication standards [23]. OpenCOM is a framework to facilitate runtime
adaptation of systems using reection [14]. It contains many similarities to our own architecture both in terms of design and operational facilities. An non-exhaustive list of the similarities is
presented in Table 5.
As mentioned earlier, OpenCOM undertakes its runtime adaptation through reection, which allows it to augment its execution
based on current context. The authors argue that this method of
runtime interjection places negligible overhead on the operation
of their middleware during normal operation, and their results
are presented in [13]. In giving a comparison of the methods used
for runtime operational augmentation in the authors and our
approach, we would rst like to highlight some of the major differences in the design of both frameworks. The authors of OpenCOM
describe a component model that is formally dened using OMG
IDL. Through a dened interface, the framework allows the matching of interfaces (performed action) to receptacles (dependencies).
The framework is not comprised of a formal method to validate its
augmentation steps. This would seem unnecessary as the system
does not purport to automate the process of augmenting its function as is the goal of the DSVM middleware. As a result, unlike the
DSVM, there is no enumeration of potential execution paths during
its augmentation process. A capsule is augmented simply by a
component that is deemed acceptable based on the frameworks
metamodel. This matching is left to the Component Framework, a
course-grained system structure initially dened by Szyperski
and Clemens [45].
7.3.2. Objective
The objective of the third experiment is to compare execution
times for rst-class operations of the redesigned DSVM middleware to the operations of the similar OpenCOM framework.
Table 5
DSVM vs. OpenCOM.
Framework artifacts

The main threat to the results obtained is generalizing the overhead of generating the IM for a majority of domains in which our
UCM design will be used. So far we have done preliminary feature
analyses in two domains, the user-centric communication domain
which is inherently distributed [54], and the microgrid energy
DSVM
OpenCOM
Intent Model
Procedure
DSC Interface denition
DSC Dependency
DSC Action
Capsule
Component
Interface
Receptacle
API
38
7.3.3. Method
We compared the operating time of our middleware architecture to an extrapolation of published results for OpenCOM. We
then analyzed variables that could potentially lead to the differences in performance.
7.3.4. Setup
We refer to the previously stated results in experiment 1 for the
operating time of our middleware to generate, validate, and select
a model for execution. These are compared to the published results
for OpenCOM [13], where the experiment undertaken involved the
reconguration of a capsule that switched one component for
another. In both experiments, all operations were rst class, with
no domain specic execution. The results only demonstrate the
time taken for the reconguration of the executing artifact in the
case of OpenCOM, or for the regeneration, validation and selection
of an intent model in the case of the DSVM middleware. Both systems were evaluated with varying hardware and software proles.
One of the more salient variables in the experiment is the age of
the original study. To address this issue, we approximate the relative execution speed-up of OpenCOM based on studies of CPU
improvements for single-threaded workloads [35,37]. The potential effects of this threat are detailed in the discussion in subsequent subsections, Discussion and Threats to Validity. Additionally,
the results published in [13] were presented as a line graph in lieu
of tabular data. As a result, we present their measurements as
approximations instead of absolute values.
7.3.5. Results
Table 6 shows the time taken for the reconguration of components in OpenCOM and the regeneration, validation and selection
of intent models in DSVM. The leftmost column shows the number
of cycles, the center column the time in millisecond for DSVM, and
the rightmost column the approximate times for OpenCOM. The
results are also shown as a line graph in Fig. 18, the x-axis represents the number of cycles and the y-axis the time in milliseconds.
7.3.6. Discussion
As depicted in Table 6 and Fig. 18, the execution times for the
DSVM middleware are slightly lower than those of OpenCOM for
workloads of 100 cycles or fewer. This nding was based on reports
of CPU speeds for single-threaded systems by Patterson et al. [35]
and Preshing [37], which stated that computing power had
increased approximately 20% for each of the 10 years prior to
2012. With this, we extrapolated the approximate execution times
for OpenCOM on comparable hardware to that used to perform
DSVM experiments. We concluded that the DSVM approach is at
least equally as fast as OpenCOM for small workloads, i.e., up to
100 cycles, while for larger workloads up to 10,000 cycles in
our experiments OpenCOM outperforms our architecture by just
under 5 to 1.
We stress again that there are more high level steps involved in
the generation and selection of an intent model as compered to
swapping a single component in a capsule. We believe this
Table 6
Middleware operations execution times.
Cycles
1
10
100
1000
10,000
Fig. 18. Execution time for multiple augmentation cycles.
illustrates that our platform carries with it acceptable overhead

for small workloads in our identied domains, as compared to
similar approaches.
As mentioned above, the OpenCOM platform is able to achieve
its augmentation through the unbinding and rebinding of components in a capsule, while the DSVM middleware generates, validates, and selects a new model for execution. The nature of our
middleware necessitates these steps, and therefore makes a completely equivalent side-by-side comparison difcult. Considering
this, however, it is our belief that the requirement of automating
the selection of a valid component within OpenCOM for inclusion
in a capsule would necessitate the evaluation of additional components for their suitability. This would result in a marked increase in
the execution time of an OpenCOM-based platform.
The main threat to validity relating to the use of published time
measurements is clearly the power and capability of the varying
hardware and software platforms used to run the experiments.
This carries a direct impact on any time measurement, and is very
difcult to simulate the precise environment to create comparable
results. Note that we attempt to mitigate this threat, as stated in
the discussion section. Additionally, details of both implementations may lend more insight as to their performance. For instance,
a system built to run on Java, as is the case with our prototype, will
have a different performance prole than a system built using
C(++), as appears to be the case with OpenCOMs ReMMoC.
8. Related work
As stated in Section 2.2 there has been several middleware
designs proposed for emerging paradigms and technologies,
including pervasive computing [39], internet of things [4], and
ubiquitous computing [46]. In this section, we review the literature
on similar approaches to our own in the areas of model-driven
adaptable middleware and middleware execution models. We
compare and contrast their approaches, paying attention to where
their methods were ill-t for our problem domain. We also highlight certain shortcomings present in the previous User-Centric
Communication Middleware in realizing its role of service delivery,
and show how our approach addresses those issues.
Execution time (ms)

DSVM
OpenCOM
114
366
817
2205
13,632
920
960
1000
1200
2880
8.1. Adaptive middleware

In the work of Kramer et al. [28], the authors present an
approach to developing self-managing systems which utilize selfconguring components. Their work focuses at the architectural
level, where components are automatically aligned in order to
39
achieve system goals. This approach does not present a mechanism

to select among various components which achieve the same end,
but instead relies on the presence of a specic component which
undertakes predened tasks. This is an expected limitation in the
authors work as there is no notion of an operation taxonomy as
is present in our approach. As our work focuses on the service
delivery layer of our DSVM, we are divorced from the physical
mechanisms that effect actions within our environment. Instead,
we focus on determining the best way to realize intent (or goals)
by employing potentially numerous procedures which perform
the needed function. Additionally, Kramer et al. state that planning
and verication are performed off-line, which they state is sufcient if all possible system states can be addressed. Our architecture must be able to perform all planning operations at runtime
as (1) the combination of relevant state information is determined
by policies in place at the time of command execution and (2) the
set of available procedures can be altered at runtime.
Zachariadis et al. [55] demonstrate an adaptable mobile middleware, SATIN, that can augment its functionality based on functional
component availability. While interesting, this work does not
address having variability in components which meet the needs
of the system. Additionally, this approach provides no consideration of policies nor does it provide a single dialect with which
to analyze component capabilities against system policies. Our
architecture facilitates adaptation with a minimal resource footprint due to the use of execution units. Additionally, we provide
a mechanism to analyze models when more than one are able to
execute an operation. This can have a direct impact on the middlewares operational speed by allowing the selection of a more efcient execution when context and resources allow.
8.2. Middleware execution models
Bellur et al. [5] present an approach to dynamically bind middleware components for execution based on user intent and context. Their work is similar to our own in that it treats the
platform as a base for execution in a programmatic way. Our work
differs in the granularity of operations as their components are
analogous to our procedures. As procedures are further broken
down into executable units, we are able to achieve ner grain
execution and adaptation. Additionally, in the authors work the
variation points at which dependencies are dened do not specify
any direct cost analysis mechanism for deciding on the most efcient option for selection. Our approach is also inherently distributed, as the platforms event registration service allows
procedures to be distributed across multiple remote instances of
the middleware.
Madl et al. [29] describe a method to perform verication of distributed real-time properties via model checking. This, in principle,
is similar to our proposed approach of utilizing model checking
techniques to validate a proposed system transformation via the
execution of an intent model. Both approaches apply formal methods to ensure the middleware behaves as expected. Their results
show that model checking techniques can effectively verify
event-driven behavior of a component based middleware. Our
approach differs fundamentally in that our validation process takes
place at runtime upon receipt of an event, instead of at design time
as in the case of the cited work. Additionally, our validation is performed against Event Condition Action-type (ECA) policies, which
requires the existence of a common communication dialect, as well
as a mechanism for transforming these policies into logical formulas to check for satisability.
Verssimo et al. [50] describe a middleware, CORTEX, that presents a programming model and architecture for creating ubiquitous, autonomous applications that address concerns such as
safety, responsiveness, and mobility. The architectures enumerated
list of rst-class concerns facilitates easy development of applications that possess these characteristics. While this programming
model is desirable in many instances, it may limit the applicability
of the architecture in some domains, or increase the complexity of
development as the model may not be apropos for the task at hand.
As a result of the domain independence of our approach, our architecture does not enumerate any potential concerns and therefore
provide fewer high level abstractions that would aid in addressing
them. This helps to limit the presence of superuous functionality
of our middleware once it has been specialized for a specic
domain as all rst-class operations relate solely to the middlewares internal operations and are not directly accessible via the
programming model.
8.3. User-centric communication middleware
The User-centric Communication Middleware (UCM) is the layer of the CVM charged with ensuring the delivery of services resulting from the synthesis of a communication model by the Synthesis
Engine (SE) [56,53]. Upon completion of the model synthesis process, the SE packages and delivers a control script, which is an
ordered set of commands, to the UCM. The list of control script
commands used in the CVM is shown in Fig. 3. It is the job of the
UCM to realize the intent of the user by performing the necessary
operations described by the commands found in the control script
while adhering to the non-functional requirements of the system
based on available state information. This may require the UCM
to determine at runtime what the semantics of a particular command should be based on the current system context.
The current implementation of the UCM proposed by Deng et al.
[15], whose design is shown in Fig. 19, performs its functions
through runtime adaptation of its operations using structural
reection [10]. However it is not policy aware, and is therefore
unable to incorporate context into its adaptation requirements.
In its current incarnation, the DSML of the CVM must expose variability of its operations in the language and places the burden of
complying with business rules and policies on the creator of the
CML schema. While the CVM as a whole does incorporate the use
of policies in specic layers [7], the UCM is not party to any policy
knowledge. Our implementation of the DSVM middleware layer
UCM
UCM-SE Interface
UCM Manager
Exception
Handler
Loader
UCM Interpreter
Local
Respoistory
(macros, logging
facility)
NCB-specific
commands
Event Handler
UCM-NCB Interface
Fig. 19. UCM architecture used in the rst version of the CVM [15].
40
Table A.7
Network communication broker API available to the user-centric communication middleware.
Returns
Signature
Comments
Void
Void
UserProle
Void
Void
NCB_M_Facade
Boolean
UserObject
Void
Void
Void
Void
UserSchema
Boolean
Boolean
Boolean
Boolean
addParty(String, String)
createSession(String)
createUserProle(UserObject, Object)
disableMedium(String, String)
enableMedium(String, String)
getInstance()
isCreatedSession(String)
login(String, String)
logout(String)
mapConnToSession(String, String)
removeParty(String, String)
resetNCB()
retrieveSchemas(String, String)
saveSchema(Object)
sendMedia(String, String, String)
sendSchema(String, String, String, String)
sendSchema(String, String, String, String, String)
Adds a participant to the specic session.

creates a session with the specied session ID
Generates a user prole for a user
Stops sending medium to all the participants in a session
Starts sending medium to all the participants in a session
returns NCB facade object
Checks if session was created
Attempts to log in user with userid and password
Logs the user out
Maps a connection to a session
Removes participant from a session.
Resets the NCB instance
Returns the schemas for the given user
Saves schema to a temporary location
Sends the specied medium to all the participants in a session
Sends the control schema to all participants in the specied session
Sends the control and data schemas to all participants in the specied session
will address these issues by allowing variability in operations to be

handled internally instead of passing the decision to the user. This
stands to reduce complexity to the user and provide assurance in
functionality by ensuring compliance with system policies.
Acknowledgment
This work was supported in part by a GAANN Fellowship from
the US Department of Education under P200A090061. Fbio M.
Costa would like to thank CAPES, Brazil, Proc. No. BEX 0759/11-2,
for the support received during his sabbatical at FIU.
9. Conclusions
Appendix A. Network communication broker API
In this article we presented an adaptive middleware design for
domain-specic virtual machines (DSVM). This design dynamically
integrates decoupled domain-specic knowledge (DSK) and a
model of execution (MoE) to support the delivery of domain-specic services. The DSK is captured through the use of procedures
which perform operations relevant to the domain, and a set of
domain specic classiers that categorize them. The MoE provides
a platform where procedures and classiers are dynamically loaded and executed based on the context in which a request is made
by the layers surrounding the DSVM middleware. Experiments
were performed to determine the overhead required by the proposed design and the results show that the increased execution
times are acceptable given the functionality of the middleware.
Our approach to dynamically composing intent models result in
quadratic space and time complexity, which, for the domains
under analysis and supported by experiments, result in manageable overhead in the model generation process when compared
to the operations of the original middleware design. Our approach
also provides benets in overall operation execution time due to its
ability to determine at runtime the optimum execution path.
Our work on the DSVM middleware has identied several questions that require further investigation in order to fully realize the
true potential of our middleware design. Some of these questions
focus on optimization of the MoE, such as, the pre-generation of
models representing the procedures and domain-specic classiers, and a caching mechanism that provides a smarter approach
to generating models. Other questions will focus on the selection
of the most appropriate model when multiple models apply based
on the context of the request. We have recently developed an
approach to formally validate dynamic models, representing the
users intent, to ensure they conform to user policies; however,
we still need to perform a comprehensive set of experiments to
validate our approach. Finally, we intend to expand on the current
naive approach to intent model validation by investigating formal
model checking and associated approaches to provide a more
robust mechanism for evaluating the adequacy of executing a
model given current system context.
Table A.7.
References
[1] M. Allison, A.A. Allen, Z. Yang, P.J. Clarke, A software engineering approach to
user-driven control of the microgrid, in: Proceedings of the Twenty-Third
International Conference on Software Engineering and Knowledge Engineering
(SEKE 2011), Knowledge Systems Institute, 2011, pp. 5964.
[2] M. Allison, K. Morris, Z. Yang, P. Clarke, F. Costa, Towards reliable smart
microgrid behavior using runtime model synthesis, in: 2012 IEEE 14th
International Symposium on High-Assurance Systems Engineering (HASE),
2012, pp. 185192.
[3] M. Allison, K.A. Morris, F.M. Costa, P.J. Clarke, Synthesizing interpreted
domain-specic models to manage smart microgrids, J. Syst. Softw. 96 (0)
(2014)
172193.
<http://www.sciencedirect.com/science/article/pii/
S0164121214001435>.
[4] S. Bandyopadhyay, M. Sengupta, S. Maiti, S. Dutta, A survey of middleware for
internet of things, in: A. zcan, J. Zizka, D. Nagamalai (Eds.), Recent Trends in
Wireless and Mobile Networks, Communications in Computer and Information
Science, vol. 162, Springer, Berlin Heidelberg, 2011, pp. 288296. http://dx.doi.
org/10.1007/978-3-642-21937-5_27.
[5] U. Bellur, N. Narendra, Towards a programming model and middleware
architecture for self-conguring systems, in: First International Conference on
Communication System Software and Middleware, 2006, Comsware 2006,
2006, pp. 16.
[6] P.A. Bernstein, Middleware: a model for distributed system services, Commun.
ACM 39 (2) (1996) 8698. http://doi.acm.org/10.1145/230798.230809.
[7] P. Boettner, M. Gupta, Y. Wu, A.A. Allen, Towards policy driven selfconguration of user-centric communication, in: Proceedings of the 47th
Annual Southeast Regional Conference, ACM-SE 47, ACM, New York, NY, USA,
2009, pp. 35:135:6. http://doi.acm.org/10.1145/1566445.1566493.
[8] K. Chen, J. Sztipanovits, S. Abdelwalhed, E. Jackson, Semantic anchoring with
model transformations, in: Model Driven ArchitectureFoundations and
Applications, Springer, 2005, pp. 115129.
[9] B.H. Cheng, R. Lemos, H. Giese, P. Inverardi, J. Magee, J. Andersson, B. Becker, N.
Bencomo, Y. Brun, B. Cukic, G. Marzo Serugendo, S. Dustdar, A. Finkelstein, C.
Gacek, K. Geihs, V. Grassi, G. Karsai, H.M. Kienle, J. Kramer, M. Litoiu, S. Malek,
R. Mirandola, H.A. Mller, S. Park, M. Shaw, M. Tichy, M. Tivoli, D. Weyns, J.
Whittle, Software engineering for self-adaptive systems: a research roadmap,
in: B.H. Cheng, R. Lemos, H. Giese, P. Inverardi, J. Magee (Eds.), Software
Engineering for Self-Adaptive Systems, Springer-Verlag, Berlin, Heidelberg,
2009, pp. 126.
[10] S. Chiba, Load-time structural reection in java, in: ECOOP 2000 ObjectOriented Programming, Springer, 2000, pp. 313336.
[11] P.J. Clarke, Y. Wu, A.A. Allen, F. Hernandez, M. Allison, R. France, Towards
dynamic semantics for synthesizing domain-specic models, in: M. Mernik
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
(Ed.), Formal and Practical Aspects of Domain-Specic Languages: Recent

Developments. IGI Global, 2012, pp. 242269 (Ch. 9).
G. Coulson, What is reective middleware, IEEE Distrib. Syst. Online 2 (8)
(2001) 165169.
G. Coulson, G. Blair, P. Grace, On the performance of reective systems
software, in: IEEE International Conference on Performance, Computing, and
Communications, 2004, IEEE, 2004, pp. 763769.
G. Coulson, G. Blair, P. Grace, A. Joolia, K. Lee, J. Ueyama, A component model
for building systems software, in: Proceedings of the IASTED Software
Engineering and Applications (SEA04), 2004, p. 205.
Y. Deng, S.M. Sadjadi, P.J. Clarke, V. Hristidis, R. Rangaswami, Y. Wang, Cvm a
communication virtual machine, J. Syst. Softw. 81 (10) (2008) 16401662.
<http://www.sciencedirect.com/science/article/pii/S016412120800037X>.
T. Dolic, Maximum product over partitions into distinct parts, J. Integ. Seq. 8
(05.5.8) (2005).
Eclipse Team, Eclipse Helios, October 2013 <http://www.eclipse.
org/downloads/packages/release/helios/sr2>.
F. Eliassen, A. Andersen, G. Blair, F. Costa, G. Coulson, V. Goebel, O. Hansen, T.
Kristensen, T. Plagemann, H. Rafaelsen, K. Saikoski, W. Yu, Next generation
middleware: requirements, architecture, and prototypes, in: Proceedings of
the 7th IEEE Workshop on Future Trends of Distributed Computing Systems,
1999, 1999, pp. 6065.
M. Fowler, Domain Specic Languages, rst ed., Addison-Wesley Professional,
2010.
R. France, B. Rumpe, Model-driven development of complex software: a
research roadmap, in: Future of Software Engineering, 2007, FOSE 07, May
2007, pp. 3754.
A. Georges, D. Buytaert, L. Eeckhout, Statistically rigorous java performance
evaluation, SIGPLAN Not. 42 (10) (2007) 5776. http://doi.acm.org/10.1145/
1297105.1297033.
A. Ghosh, S. Wei Li, C. Chiang, R. Chadha, K. Moeltner, S. Ali, Y. Kumar, R. Bauer,
Qos-aware adaptive middleware (qam) for tactical manet applications, in:
Military Communications Conference, 2010 MILCOM 2010, 2010, pp. 178
183.
P. Grace, G.S. Blair, S. Samuel, Remmoc: a reective middleware to support
mobile client interoperability, in: On The Move to Meaningful Internet
Systems 2003: CoopIS, DOA, and ODBASE, Springer, 2003, pp. 11701187.
V.H. Hieu, H.D. Hai, An application-aware adaptive middleware architecture
for distributed multimedia systems, in: First International Conference on
Communications and Electronics, 2006, ICCE 06, 2006, pp. 141146.
K.C. Kang, S.G. Cohen, J.A. Hess, W.E. Novak, A.S. Peterson, Feature-Oriented
Domain Analysis, Tech. Rep. CMU/SEI-90-TR-21, CMU, November 1990.
S. Kelly, J.-P. Tolvanen, Domain-Specic Modeling: Enabling Full Code
Generation, Wiley-IEEE Computer Society Pr, 2008.
A. Kleppe, Software Language Engineering: Creating Domain-Specic
Languages Using Metamodels, rst ed., Addison-Wesley Professional, 2008.
J. Kramer, J. Magee, Self-managed systems: an architectural challenge, in:
Future of Software Engineering, 2007, FOSE 07, May 2007, pp. 259268.
G. Madl, S. Abdelwahed, D. Schmidt, Verifying distributed real-time properties
of embedded systems via graph transformations and model checking, RealTime Syst. 33 (13) (2006) 77100.
P. McKinley, F. Samimi, J. Shapiro, C. Tang, Service clouds: a distributed
infrastructure for constructing autonomic communication services, in: 2nd
IEEE International Symposium on Dependable, Autonomic and Secure
Computing, 2006, pp. 341348.
S.J. Mellor, M.J. Balcer, Executable UML: A Foundation for Model-Driven
Architecture, Addison-Wesley Professional, 2002.
K. Morris, A Middleware to Support Services Delivery in a Domain-Specic
Virtual Machine, Ph.D. thesis, Florida International University, July 2014.
K. Morris, J. Wei, P. Clarke, F. Costa, Towards adaptable middleware to support
service delivery validation in i-dsml execution engines, in: 2012 IEEE 14th
International Symposium on High-Assurance Systems Engineering (HASE),
October 2012, pp. 8289.
I.A. Niaz, J. Tanaka, An object-oriented approach to generate java code from
UML statecharts, Int. J. Comp. Inf. Sci. 6 (2) (2005) 315321.
41
[35] D.A. Patterson, J.L. Hennessy, Computer Organization and Design, fth ed., The
Hardware/Software Interface, Morgan Kaufmann Publishers Inc., San
Francisco, CA, USA, 2013.
[36] G.D. Plotkin, A structural approach to operational semantics, J. Log. Algebr.
Program. 6061 (2004) 17139.
[37] J. Preshing, A look back at single-threaded cpu performance, Blog Preshing on
Programming, February 2012 <http://preshing.com/20120208/a-look-back-atsingle-threaded-cpu-performance/> (February 2015).
[38] S. Ramanathan, I. Rodriguez, K. Drira, Adaptive middleware architecture for
group communication activities, in: 11th Annual International Conference on
New Technologies of Distributed Systems (NOTERE), 2011, 2011, pp. 17.
[39] V. Raychoudhury, J. Cao, M. Kumar, D. Zhang, Middleware for pervasive
computing: a survey, Pervasive Mob. Comput. 9 (2) (2013) 177200. http://
dx.doi.org/10.1016/j.pmcj.2012.08.006.
[40] S.M. Sadjadi, A Survey of Adaptive Middleware, Tech. Rep. MSU-CSE-03-35,
Michigan State University, 2003.
[41] D.C. Schmidt, F. Buschmann, Patterns, frameworks, and middleware: their
synergistic relationships, in: Proceedings of the 25th International Conference
on Software Engineering, ICSE 03, IEEE Computer Society, Washington, DC,
USA, 2003, pp. 694704. <http://dl.acm.org/citation.cfm?id=776816.776917>.
[42] J. Smith, R. Nair, The architecture of virtual machines, Computer 38 (5) (2005)
3238.
[43] T. Stahl, M. Voelter, J. Bettin, A. Haase, S. Helsen, K. Czarnecki, Model-Driven
Software Development: Technology, Engineering, Management, rst ed., John
Wiley & Sons, 2006.
[44] S.W. Suthon, G.M. Ong, H. Pung, An adaptive end-to-end qos management
with dynamic protocol congurations, in: 10th IEEE International Conference
on Networks, 2002, ICON 2002, 2002, pp. 106111.
[45] C. Szyperski, Component Software: Beyond Object-Oriented Programming,
Pearson Education, 2002.
[46] J.-Y. Tigli, S. Lavirotte, G. Rey, V. Hourdin, D. Cheung-Foo-Wo, E. Callegari, M.
Riveill, Wcomp middleware for ubiquitous computing: aspects and composite
event-based web services, Ann. Telecommun. Ann. Tlcommun. 64 (34)
(2009) 197214. http://dx.doi.org/10.1007/s12243-008-0081-y.
[47] A. Tsutsui, H. Maeomiti, R. Kawamura, K. Yata, An adaptive communication
middleware for network service coordination, in: First IEEE Consumer
Communications and Networking Conference, 2004, CCNC 2004, 2004, pp.
406411.
[48] United States Congress, Health Insurance Portability and Accountability Act,
US Department of Health & Human Services, 1996.
[49] A. Unkrig, M. Fowles, Janino, October 2013 <http://docs.codehaus.org/display/
JANINO/Home>.
[50] P. Verssimo, V. Cahill, A. Casimiro, K. Cheverst, A. Friday, J. Kaiser, Cortex:
towards supporting autonomous and cooperating sentient entities, in:
Proceedings of European Wireless 2002, Florence, Italy, February 2002, pp.
595601.
[51] S. Vinoski, An overview of middleware, in: A. Llamos, A. Strohmeier (Eds.),
Reliable Software Technologies Ada-Europe 2004, Lecture Notes in Computer
Science, vol. 3063, Springer, Berlin Heidelberg, 2004, pp. 3551.
[52] X. Wang, M. Chen, H.-M. Huang, V. Subramonian, C. Lu, C. Gill, Control-based
adaptive middleware for real-time image transmission over bandwidthconstrained networks, IEEE Trans. Paral. Distrib. Syst. 19 (6) (2008) 779793.
[53] Y. Wu, A. Allan, Y. Wang, F. Hernandez, P.J. Clarke, Y. Deng, A user-centric
communication middleware for CVM, Softw. Eng. Appl. (2008).
[54] Y. Wu, A.A. Allen, F. Hernandez, R. France, P.J. Clarke, A domain-specic
modeling approach to realizing user-centric communication, Softw.: Pract.
Exper. 42 (3) (2012) 357390. http://dx.doi.org/10.1002/spe.1081.
[55] S. Zachariadis, C. Mascolo, W. Emmerich, The SATIN component system-a
metamodel for engineering adaptable mobile systems, IEEE Trans. Softw. Eng.
32 (11) (2006) 910927.
[56] C. Zhang, S.M. Sadjadi, W. Sun, R. Rangaswami, Y. Deng, User-Centric
Communication Middleware, Tech. Rep. FIU-SCIS-2005-11-01, Florida
International University, 2005.

Cyber-Physical Systems - Concept, Challenges and Research Areas

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Cyber-Physical Systems - Concept, Challenges and Research Areas

Hochgeladen von

Copyright:

Verfügbare Formate

Information and Software Technology 62 (2015) 2141

Contents lists available at ScienceDirect

Information and Software Technology

An adaptive middleware design to support the dynamic interpretation

software engineering, where models in one language are translated

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

to the next layer in the stack. We will refer to an i-DSML execution

Section 2 describes background knowledge relevant to the work

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

An i-DSML model may either be a control schema or a data

Synthesis Engine (SE) synthesizes models by comparing the

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

Fig. 2. Layered architecture of the Communication Virtual Machine (CVM).

Fig. 3. EBNF-like structure of the CVM control scripts.

commands. Rule 5 states that the addParticipantCmd consists of

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

during synthesis. The initial instance with subscript 0 is referred to

2.2. Adaptive middleware

The middleware design we are proposing for DSVMs should

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

Fig. 5. DSVM specialization during instantiation.

Programming Model Refers to the ability of the middleware to

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

Kramer et al. [28]

the domain knowledge during feature analysis [25] of the domain.

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

API Calls and Events

Fig. 6. Model of execution workow for a DSVM middleware.

A Domain Specic Classier (DSC) is dened as a 4-tuple

N a name is a string that is unique in a given namespace (NS).

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

any number of allowed system operations; however it is limited to

of the DSVM if the middleware is unable to generate a valid intent

function generateIMs(initDSC, procList)

the recursive call /

Algorithm 1 shows the generateModels() function that builds

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

Fig. 7. Generation of intent models.

Algorithm 2. Merging parent intent models and children intent

Fig. 8. Class diagram for an intent model.

function mergeIMs(parentIM_List, subIM_List)

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

6. DSVM middleware design

6.1. Structural design

Fig. 10 shows the structure of the middleware interpreter.

Fig. 11. Class diagram for im_generator package.

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

to perform dynamic compilation and loading of source code; the

where n is the number of procedural nodes in the model and cost

6.2. Behavioral design

Fig. 12. Class diagram for im_executor package.

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

im_Generated [preExecCond] / executePreamble()

if there is no precondition then the IM is executed using the

[return && !initProc] / reenterCallingProc(P)

Fig. 14. State machine for executing an IM.

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

3. Compare and contrast the operational times of our architecture

Listing 1. Scenario artifacts.

K.A. Morris et al. / Information and Software Technology 62 (2015) 2141

Model generation time (ms)

Fig. 15. Minimum, maximum and average model generation times.

in part to our implementation that can more efciently manage

Listing 2. Dummy artifacts.