For Coordination, State Component Transitions - Radoslaw Szymanek, Simon Bliudze
Upcoming SlideShare
Loading in...5
×
 

For Coordination, State Component Transitions - Radoslaw Szymanek, Simon Bliudze

on

  • 962 views

OSGi Community Event 2013 (http://www.osgi.org/CommunityEvent2013/Schedule)

OSGi Community Event 2013 (http://www.osgi.org/CommunityEvent2013/Schedule)

Statistics

Views

Total Views
962
Views on SlideShare
962
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

For Coordination, State Component Transitions - Radoslaw Szymanek, Simon Bliudze For Coordination, State Component Transitions - Radoslaw Szymanek, Simon Bliudze Presentation Transcript

  • For Coordination, State Component Transitions Simon Bliudze Anastasia Mavridou Alina Zolotukhina Rigorous System Design Laboratory (EPFL) {firstname.surname}@epfl.ch Radoslaw Szymanek Crossing-Tech S.A. radoslaw.szymanek@crossing-tech.com With partial support from the Swiss Commission for Technology and Innovation
  • BIP background A framework and a toolset for component-based system design Developed and maintained • by Verimag and RiSD • directed by Joseph Sifakis (ACM Turing award 2007) We apply lessons learned from Embedded Systems to Java 2
  • Need for coordination Independent software entities share access to resources. Communication and data exchange can be complex. Component execution must be coordinated. 3
  • Semaphores, locks, monitors, etc. Coordination based on low-level primitives rapidly becomes unpractical. 4
  • Synchronisation Task 1: Task 2: ... free(S1); take(S2); ... ... take(S1); free(S2); ... A simple synchronisation barrier 5
  • Synchronisation Task 1: Task 2: Task 3: ... free(S1); free(S1); take(S2); take(S3); ... ... take(S1); free(S2); free(S2); take(S3); ... ... take(S1); take(S2); free(S3); free(S3); ... Three-way synchronisation barrier 6
  • Can we do worse? Yes, we can! Task 1: Task 2: initialise(x); free(S1); take(S2); sh = max(x, sh); free(S2); take(S1); x = sh; initialise(y); take(S1); free(S2); sh = max(y, sh); take(S2); free(S1); y = sh; Coordination mechanisms mixed up with computation do not scale. 7
  • Can we do worse? Yes, we can! Task 1: Task 2: initialise(x); free(S1); take(S2); sh = max(x, sh); free(S2); take(S1); x = sh; initialise(y); take(S1); free(S2); sh = max(y, sh); take(S2); free(S1); y = sh; Coordination mechanisms mixed up with computation do not scale. Code maintenance is a nightmare! 7
  • Separation of concerns: The BIP approach b1 f1 b1 r1 b2 f1 p1 p1 r1 r2 f2 f2 p2 b2 p2 r2 Coordination glue is a separate entity Component behaviour specified by Finite State Machines 8
  • Finite State Machines are everywhere http://www.uml-diagrams.org Android MediaRecorder interface http://developer.android.com/reference/ android/media/MediaRecorder.html 9
  • BIP by example: Mutual exclusion b1 f1 b2 sleep f1 f2 sleep b1 f2 work b2 work Interaction model: {b1, f1, b2, f2, b1f2, b2f1} Maximal progress: b1 < b1 f2, b2 < b2 f1 Design front-end Semantic back-end sleep sleep f1 work sleep b1 b2 b 1b 2 f1b2 b2 f2 f2 f1f2 work work b1f2 b1 f1 sleep work sleep sleep f1 work sleep b1 f1b2 f1 b2 b1f2 b1 b2 f2 f2 work work f1 sleep work sleep sleep work sleep f2 b1 f1b2 f2 b2 b1f2 work work sleep work f1 10
  • Engine-based execution 1. Components notify the Engine about enabled transitions. B E H A V I O U R Interactions Priorities 2. The Engine picks an interaction and instructs the components. 11
  • OSGi bundle states install Installed uninstall Uninstalled uninstall up da te resolve Resolved start Starting Stopping stop Active Only lifecycle state is shown. All functional states are hidden in the ‘Active’ state. 12
  • Use case: Camel Routes Many independent routes share memory • We have to control the memory usage • e.g., by limiting to only a safe number of routes simultaneously 13
  • Camel routes public class RouteBuilder(...) { from(…).routeId(…).process(…).to(…); } Camel API: suspendRoute and resumeRoute Transition types: • • Spontaneous Enforceable (can be controlled by the Engine) working off finishing off begin end end off (inform about uncontrollable external events) ready begin end suspended on on 14
  • Use case: BIP model BIP Specifications working off finishing off finished off begin off end off done end [!g] end end internal [g] wait off ready on begin end suspended on on on finished on add add 0 rm add 1 rm 2 rm BIP Monitor The Monitor component limits the number of active routes to two 15
  • Implemented architecture Spring app context bundle BIP Component Spring bean to control Notifier BIP Control Spec BIP Model Executor Interaction specification inform execute OSGi bundle BIP Component BIP Monitor Spec BIP Model Executor Behaviour specification Arrows: • Blue — API calls between model and entity • Red — OSGi-managed through published services • Green — called once at initialisation phase 16
  • BIP Specification: Ports, Initial state @bipPorts({ @bipPort(name = "end", type = "spontaneous"), @bipPort(name = "off", type = "enforceable"), … }) @bipComponentType( initial = "off", name = "org.bip.spec.switchableRoute") public class SwitchableRoute implements CamelContextAware, InitializingBean, DisposableBean { … } Behavior finished off off done end [!g] internal [g] wait on end off on on finished 17
  • BIP Specification: Transitions @bipTransition(name = "off", source = "on", target = "wait", guard = "") public void stopRoute() throws Exception { camelContext.suspendRoute(routeId); } Transition annotations provide • • • Label: a port, declared by @bipPort Source and target states Guard expression Behavior finished off off done end [!g] internal [g] wait on end off on on finished 18
  • BIP Specification: Guards @bipTransition(name = "end", source = "wait", target = "done", guard = "!isFinished") public void spontaneousEnd() throws Exception { … } @bipTransition(name = "", source = "wait", target = "done", guard = "isFinished") public void internalEnd() throws Exception { … } Behavior finished off off done end [!g] internal [g] wait on end off on on finished 19
  • BIP Specification: Guards @bipTransition(name = "end", source = "wait", target = "done", guard = "!isFinished") public void spontaneousEnd() throws Exception { … } @bipTransition(name = "", source = "wait", target = "done", guard = "isFinished") public void internalEnd() throws Exception { … } @bipGuard(name = "isFinished") Behavior public boolean isFinished() { finished CamelContext cc = camelContext; off done return end cc.getInflightRepository().size( [!g] wait cc.getRoute(routeId).getEndpoint() end ) == 0; off } on off internal [g] on on finished 19
  • BIP Component interface public interface BIPComponent extends BIPSpecification { void execute(String portID); void inform(String portID); } Interface methods: • execute — called by the Engine to • execute an enforceable transition inform — called by Notifiers to inform about spontaneous events Behavior finished off off done end [!g] internal [g] wait on end off on on finished 20
  • BIP Executor interface public interface Executor extends BIPComponent { void publish(); void unpublish(); void register(BIPEngine bipEngine); void deregister(); } Interface methods: • publish/unpublish • — collaborates with OSGi service registry register/deregister — manage connection with the BIP Engine Implements the component execution semantics 21
  • Spontaneous event notifiers new RoutePolicy() { … public void onExchangeDone( Route route, Exchange exchange) { executor.inform("end"); } } BIP Specification may also need to know it’s executor in order to set up notification mechanisms Behavior finished off off done end [!g] internal [g] wait on end off on on finished 22
  • Conclusion: Separation of concerns Coordination code depends on the execution environment No coordination code in business components Coordination code is confined to • BIP Glue specification • BIP Specification of the monitors imposing system properties 23
  • Conclusion: Developer perspective Developer provides BIP Spec as a Java class BIP Spec is reusable BIP Executor • implements the BIP semantics • interacts with the BIP Engine 24
  • Future work • Data transfer • Exception handling & transaction support • Further experimentation with real-life applications • Adding BIP coordination to the OSGi standard 25
  • ! u o y k n ? a s h n T io t s e u q y n A
  • State stability working off finishing off begin end end off suspended ready begin end on on It must be possible to postpone the treatment of spontaneous events. 27
  • working off begin end finishing finishing end begin end off ready off off on suspended suspended on end on finishing off end suspended finished done internal [g] end [!g] internal [!g] on wait wait suspended end [!g] internal [g] on internal [g] off on on wait off on off on g = isFinished() 28