ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliveira Filho, J.A. (Julio) de" <julio.deoliveirafi...@tno.nl>
Subject Short introduction and presentation of work
Date Fri, 22 Apr 2016 14:28:34 GMT
Dear APACHE ACE team,

Last years, our teams at TNO and Thales have been working on technologies for dynamic composition
of software modules and adaptive deployment of software architectures. The functionalities
we developed allow systems to  define -- at runtime -- which software components should be
deployed and in which computing resources.  System design and deployment decisions are based
on the current goal of the  system, the actual availability of resources, and the desired
computing performance. This allows us for example, to build systems that react to failing
machines by re-deploying  software modules in healthy resources.  It also allows to dynamically
share, bind, and re-deploy software modules when new functionality is introduced in the system.
 All that taking into consideration the computing resources available and for example, how
their load will be after the system deployment.

We believe many of the technologies we developed could also be of value for the APACHE community,
and in special the APACHE ACE community.  Moreover, this would help us to possibly get a broader
user base and development incentive. For this reason, we get in contact with you.
We summarize our innovations in two aspects that we believe add value for the APACHE ACE community:

1.       We extend the requirement-capability model of OSGI (used in ACE) to go beyond dependencies
between software modules (bundles).  In specific, we introduced simple but effective concepts
in this model that enable software designers to:
a.       describe dependencies of software modules to physical computing resources.  For example,
it is possible to explicitly describe the required amount of memory, or the required use of
special hardware, such as GPUs and graphical boards.  A language model creates a standard
for interoperability and semantic understanding.
b.      describe virtual software modules representing higher abstraction levels of composition.
 For example, it is possible to describe a signal processing chain as composed by a sampler
module, a filtering module, and a detection module.  At this level, the dependencies in the
chain are resolved based on what they do and their performance level (accuracy, resolution,
etc.), but not yet on implementation details, such as their interface.  High abstract modules
are resolved hierarchically into possible concrete implementations, which in turn provide
the more specific dependency aspects such as the interface and the required physical resources.

2.       We extend the functionality of the OSGi Resolver  with the following features :
a.       we resolve requirement-capability constraints that takes into consideration the physical
resources available.  At our system,  software requirements to computing resources (memory,
cpu, special hardware) are resolved against special bundles/models that represent the (current)
capabilities of the available hardware;  In these cases, we not only produce a resolved module
composition, but we guarantee that it can be deployed in the currently available hardware.
b.      we consider the physical allocation of software components to computing resources
as part of the resolution process.  In other words, we extended the resolution role to also
determine where each software component should be deployed.
c.       we consider many possible solutions from the resolver at the same time, instead of
the default behavior of the OSGI resolver that returns only the first feasible resolved solution
back (or fail).  The fittest solution is chosen among the several produced according to a
customizable goal function -- for example, which system has the best response-time.
d.      the resolution step can optimize the physical deployment of software components based
on a customizable goal function -- for example, by prioritizing deployments that balance the
load among the available resources against deployments that overload a single machine.

We believe the features above are an added value in the following situations:
*         Deployments of software components in heterogeneous resource environments, such
as the cloud, embedded or high-performance specialized platforms, and interoperability hardware
hubs.
*         Deployments of software components in unreliable environments where failing resources
and communication links often happen -- examples could be ad-hoc installations, embedded and
distributed platforms (Internet-of-Things);
*         Gradual deployments of software components, where functionalities are included on
demand, but with risk of overloading the computing resources;

We are curious to know if the APACHE ACE community would be interested in adopting these ideas.
 We would gladly demonstrate and discuss with you future possibilities.  What do you guys
think about the ideas above?  Would they be of added value to ACE?

Last, but not least, we would like to say a few words about ourselves.

Julio Oliveira, Maarten Ditzel and Bardo Bakker are specialists on distributed and networked
embedded systems for TNO.  TNO is involved in the design and development of innovative software
and hardware platforms, that use dynamic reconfiguration to improve their reliability, power
consumption, or efficiency.  Within this work TNO co-designed and co-implemented the mechanisms
for dynamic functional composition and resource allocation.

Pepijn Noltes, Rene van Hees, and Hans Schurer are software architects at Thales Nederland
and have been involved in different research projects oriented around dynamic reconfigurable
systems. The Thales team has a special interest in software evolution and time-critical systems.
Pepijn Noltes himself is already a committer for the Apache Celix project.

We look forward for hearing from you how we can continue this discussion.

Sincerely,

Julio A. de Oliveira Filho




Dr.Rer.Nat. J.A. (Julio) de Oliveira Filho
Innovator
DSS/Technical Sciences

T +31 (0)88 866 31 23
M +31 (0)64 684 73 73
E julio.deoliveirafilho@tno.nl<mailto:julio.deoliveirafilho@tno.nl>

Location<http://www.tno.nl/locaties/DHW> Den Haag



[cid:image001.gif@01D19CB3.7319E150]<http://www.tno.nl/>

This message may contain information that is not intended for you. If you are not the addressee
or if this message was sent to you by mistake, you are requested to inform the sender and
delete the message. TNO accepts no liability for the content of this e-mail, for the manner
in which you use it and for damage of any kind resulting from the risks inherent to the electronic
transmission of messages.



Please note when visiting TNO Waalsdorperweg:
In compliance with the strict security regulations for this location, the security staff will
ask you to leave your smartphones with camera in the lockers available at the reception desk.


Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message