Topic Based Data Distribution in GSpace SACC Software Architecture = Component + Coordination Giovanni Russello Department of Mathematics and Computing Science, Eindhoven University of Technology

Implementation Domain Overview SACC project Separate functional and non-functional specification Weaving them into a component-based model via a correctness preserving transformation/refinement Specification Domain Implementation Domain Functionality Platform C Components Sound Transformation Coordination Platform Information Timing Constraints Observing the implementation and providing feedback / hardware-related info Implementing the component-based model, managing distribution of process/data, distributed scheduling

The Gamma basic data structure: the Multiset Set with multiple occurrence of the same element Absence of any constraint or hierarchy imposition between its elements Supports/enables chaotic model of execution

Gamma Multiset Graphical Representation

The Gamma reaction structure max : x, y  y  x  y R: condition A: action

A possible approach: Space-Based System The Space acts like a repository to store and retrieve data All the same characteristics as the Multiset A natural parallel and distributed programming style Uncoupled communication in space and time - CBD benefits from minimizing dependencies

A Space-Based Java implementation : JavaSpaces Java programming language extension Portability Free code availability

JavaSpace examples: entry: objects present in the space write: to insert an entry in the space take: to retrieve and withdraw an entry from the space read: to retrieve a copy of an entry present in the space

Mapping the Gamma model onto JavaSpaces An Example x = take(xTemplate); y = take(yTemplate); if( x  y ) write(y); else write(x); fi max : x, y  y  x  y

The JavaSpaces drawbacks It is not distributed It is not Real Time It is expensive in terms of resources

Single Space Implementation Space Server C 1 C 2 C 4 C 3 Network

Distributed Space Implementation Advantages: Scalability: built into the architecture Reliability: no single point of failure Space Middleware C 1 Space Middleware C2 Space Middleware Cn ... Distributed Space Network

Our approach: GSpace Research hypothesis Efficiency Higher efficiency through differentiated distribution policies Adaptability through Separation of concerns Independence between system functionality and data distribution joint work with Maarten van Steen

Initial Experiment Separate distribution policies from storage mechanism Compare differentiated distribution policies vs. single policy Compare distributed storage vs. centralized storage

GSpace Overview GSpace C1 Host1 Storage GSpace C3 Host2 Storage GSpace Network

GSpace Conceptual

GSpace APIs: put to insert an element in the space get to obtain an element from the space producer to declare that a component produces an element type consumer to declare that a component needs such a type of element

How to Map Distribution Policy with Datatype Distribution Policies: Unreliable/Reliable & Push/Pull Associate a Distribution Policy with a datatype Distribute policy to each host (before system starts) Controller incorporates Policies into its local PolicyTable

Collaboration Diagram: Unreliable Push Model Policy - Put Producer Component JavaSpace 8: overwrite(message) PolicyTable 2: getPolicy(messageType) Controller 1: put(message) UnrPushPolicyManager 7: processing(message) UnrPushPolicyManager 3: put(message) AddressTable 4: getAddresses(messageType) PolicyTable 6: getPolicy(messageType) Communicator 5: sendUdp(message, addresses) UdpReceiver Flush the message over the network

Collaboration Diagram: Unreliable Push Model Policy - Get Consumer Component PolicyTable 2: getPolicy(messageType) Controller 1: get(messageTemplate) UnrPushPolicyManager 3: get(messageTemplate) JavaSpace 4: take(messageTemplate)

Collaboration Diagram: Reliable Pull Model Policy - Put Producer Component PolicyTable 2: getPolicy(messageType) Controller 1: put(message) RelPullPolicyManager 3: put(message) JavaSpace 4: overwrite(message)

Collaboration Diagram: Reliable Pull Model Policy - Get Consumer Component JavaSpace 8: take(messageTemplate) Controller 1: get(messageTemplate) PolicyTable 2: getPolicy(messageType) RelPullPolicyManager 7: processing(messageTemplate) RelPullPolicyManager 3: get(messageTemplate) AddressTable 4: getAddresses(messageType) PolicyTable 6: getPolicy(messageType) Communicator 5: sendReceiveTcp(messageTemplate, addresses) 9: sendBack(message) TcpReceiver Send the message over the network

A Case Study: Traffic Management Framework Overview Aggregator Computation Unit Display Road Sensors

A Case Study: Traffic Management Framework Implementation in GSpace

A Case Study: Traffic Management Framework Implementation in JavaSpace

Case Study Result: GSpace Policy Setting1 Signal Aggregator Computation Unit Display 1sec Reliable Push Reliable Push Reliable Push Average Time: 103 millisec

Case Study Graphic: GSpace Policy Setting1

Case Study Result : GSpace Policy Setting2 Signal Aggregator Computation Unit Display 1sec Reliable Pull Reliable Push Reliable Push Average Time: 75.5 millisec

Case Study Graphic: GSpace Policy Setting2

Case Study Result: JavaSpace Signal JavaSpace Aggregator Computation Unit Display 1sec Average Time: 140 millisec

Case Study Graphic: JavaSpace

Result and comparison: GSpace vs. JavaSpace GSpace performs well against JavaSpace despite the fact that is in a prototype stage It is distributed It offers support for different distribution policies

Concluding Remarks & Future Work A platform for experimentation with different distribution policies is available The early results are encouraging Mechanisms for providing timeliness guarantees Integrating the scheduling & timing constraints Mechanisms for feedback performance information