The document discusses the development and architecture of a component update system for software applications, emphasizing the management of dynamic architectures and the need for consistent updates. It outlines scenarios for updating components, the complexity of compatibility across devices, and the importance of offloading consistency verification from client devices. The goal is to create a repository that allows for efficient verification and management of component metadata, ensuring that updates are compatible and verified before deployment.

1. Premek Brada
Department of Computer Science and Engineering
University of West Bohemia, Pilsen, CZ
Euromicro 2012, 5.-8.September, Cesme, Turkey

2. > Motivation
 Issues, scenarios
> Overall Approach
> CRCE Repository
 Architecture, Extensible design
 Meta-data
 Use
> Conclusion
2

3. > Need for consistency preserving updates
> Scenarios
 Can I update this component, there is a new version?
 Is there a new application configuration for update?
 This app configuration does not work well, is there an
alternative configuration?
> Avoid repetitive verification
 Small devices
 Many installations
3

4. > Applications consist of 100s of components
 Dynamically evolving architectures
 Step-wise vs Application subset updates
 Horizontal and vertical compatibility
> Contract levels => complexity
 Signature
 Semantics (pre/post-conditions)
 Interaction (protocols, simulation)
 Extra-functional
> Any client device resource constrained
4

5. > Offload consistency verification from client
> Store verification results for later reuse
client verification
tools
component meta-data
=> Pre-verified repositories
Components
5

6. verifier
client CRCE
<>
provider
provider
provider
> Managed resources
 components, meta-data, verification results
> Repository as initiator of verification
 synchronous / asynchronous operation
 have compatibility data ready when asked for
6

7. > Goal: plug-in
different
contract
verification
methods
> OSGi based
7

8. > 2 stages
> Load
 component
structure checks
 indexers
 fast verification
> Storage
 long-running
verification
 queries
8

9. <resource id="cz.zcu.kiv.Gate/1.2.1">
...
<capability name="package">
<p n="package" v="cz.zcu.kiv.gate" />
<p n="version" t="version" v="1.1.0" />
<p n=“replaces" base="1.0.0" v=“true" />
> Capability/Requirements <p n=“replaces" base="2.0.0" v=“false" />
</capability>
model, extended …
<capability name="memory">
<p n=“level” v=“extra-functional” />
> Per-component <p n="memory" t="int" v="30" />
<p n="unit" t="string" v="MB" />
 Structural information </capability>
 Compatibility data ...
<diff base=“1.0.0" type=“subtype”
(M:N comparison) level=“signature” value=“spec” >
<part name="package" id="fq.pkg.name"
> Aggregated diff=“none” >
<based-on result-id=“res1024823” />
</part>
...
</diff>
…
</resource>
9

10. > Core, subtype compatibility, web UI
> Simulation verification for interaction and EFP
contracts in active research and development
10

11. http://www.kiv.zcu.cz/research/groups/dss/
11