Mailing-List: contact users-help@ace.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@ace.apache.org
MIME-Version: 1.0
In-Reply-To: <465B610FA77BBA479D7FBE08B0B7AC94BF3EA3BB@EXC-MBX02.tsn.tno.nl>
References: <465B610FA77BBA479D7FBE08B0B7AC94BF3EA3BB@EXC-MBX02.tsn.tno.nl>
Date: Tue, 17 May 2016 16:59:42 +0200
Message-ID: <CAPhv5g9sGcLztZYE19NZSn1UWP=qTEzNwcTsm_Xqzfas0Nji4g@mail.gmail.com>
Subject: Re: Short introduction and presentation of work
From: Pepijn Noltes <pepijnnoltes@gmail.com>
To: users@ace.apache.org
Content-Type: multipart/alternative; boundary=001a11401f94b3315e05330afdca
archived-at: Tue, 17 May 2016 14:59:56 -0000

--001a11401f94b3315e05330afdca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi All,

I just would like to add that Julio and I are going demonstrate the
described solution at the software-centric system conference in Eindhoven
(Netherlands) next week (25 may) [1].
A tad late, but you are welcome visit us at the conference :)


[1]
http://softwarecentricsystems.com/session/a-demonstration-of-a-dynamic-reco=
nfigurable-software-architecture/

Greetings,
Pepijn


On Fri, May 13, 2016 at 9:40 AM, Oliveira Filho, J.A. (Julio) de <
julio.deoliveirafilho@tno.nl> wrote:

> 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 computi=
ng
> 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 specifi=
c,
> 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 requir=
ed
> amount of memory, or the required use of special hardware, such as GPUs a=
nd
> graphical boards.  A language model creates a standard for interoperabili=
ty
> 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 possib=
le
> 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, w=
e
> 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:
>
> =C2=B7         Deployments of software components in heterogeneous resour=
ce
> environments, such as the cloud, embedded or high-performance specialized
> platforms, and interoperability hardware hubs.
>
> =C2=B7         Deployments of software components in unreliable environme=
nts
> where failing resources and communication links often happen -- examples
> could be ad-hoc installations, embedded and distributed platforms
> (Internet-of-Things);
>
> =C2=B7         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 i=
n
> adopting these ideas.  We would gladly demonstrate and discuss with you
> future possibilities.  What do you guys think about the ideas above?  Wou=
ld
> they be of added value to ACE?*
>
>
>
> Last, but not least, we would like to say a few words about ourselves.
>
>
>
> Julio Oliveira, Bardo Bakker, and Maarten Ditzel are specialists on
> distributed and networked embedded systems for TNO.  TNO is involved in t=
he
> design and development of innovative software and hardware platforms, tha=
t
> 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
>
> Location <http://www.tno.nl/locaties/DHW> Den Haag
>
>
>
> <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.
>
>
>

--001a11401f94b3315e05330afdca--