CRCE Architecture Overview

256 views

Published on

Presentation about CRCE (Component Repository supporting Compatibility Evaluation) from Euromicro 2012

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
256
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

CRCE Architecture Overview

  1. 1. Premek BradaDepartment of Computer Science and EngineeringUniversity of West Bohemia, Pilsen, CZ Euromicro 2012, 5.-8.September, Cesme, Turkey
  2. 2. > Motivation  Issues, scenarios> Overall Approach> CRCE Repository  Architecture, Extensible design  Meta-data  Use> Conclusion 2
  3. 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. 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. 5. > Offload consistency verification from client> Store verification results for later reuse client verification tools component meta-data=> Pre-verified repositories Components 5
  6. 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. 7. > Goal: plug-in different contract verification methods> OSGi based 7
  8. 8. > 2 stages> Load  component structure checks  indexers  fast verification> Storage  long-running verification  queries 8
  9. 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. 10. > Core, subtype compatibility, web UI> Simulation verification for interaction and EFP contracts in active research and development 10
  11. 11. http://www.kiv.zcu.cz/research/groups/dss/ 11

×