Overview » History » Version 23
S. Wrede, 06/15/2011 12:06 PM
1 | 1 | J. Wienke | h1. Overview |
---|---|---|---|
2 | 1 | J. Wienke | |
3 | 8 | J. Wienke | h2. Problem statement |
4 | 8 | J. Wienke | |
5 | 8 | J. Wienke | * easier integration of complex (partially) distributed systems required |
6 | 8 | J. Wienke | ** in-house (one middleware) |
7 | 8 | J. Wienke | ** adaption (combination with other middlewares) |
8 | 8 | J. Wienke | * targeting at technical architecture (only supporting functional concepts) |
9 | 8 | J. Wienke | * performance requirements |
10 | 8 | J. Wienke | * platform requirements |
11 | 9 | J. Wienke | * programming language requirements |
12 | 12 | J. Wienke | ** desired set of languages |
13 | 12 | J. Wienke | ** natural feeling in each language by using native mechanisms |
14 | 9 | J. Wienke | * basis for describing and analyzing systems required |
15 | 22 | S. Wrede | * accept heterogenity: open architecture required |
16 | 1 | J. Wienke | ** specifications for data format and transport protocols |
17 | 11 | J. Wienke | ** use of existing (and open) naming services |
18 | 8 | J. Wienke | |
19 | 7 | J. Wienke | h2. Sebastian's Aims |
20 | 1 | J. Wienke | |
21 | 10 | J. Wienke | * XCF support ends |
22 | 1 | J. Wienke | ** better solution required |
23 | 11 | J. Wienke | * limited client interface that converts to domain data as soon as possible to prevent dependency on middleware throughout the whole client code |
24 | 12 | J. Wienke | * variable dispatching mechanisms not forced by the framework |
25 | 1 | J. Wienke | |
26 | 15 | J. Wienke | h2. Lessons learned (from other frameworks, e.g. XCF, YARP, ROS, NaoQi) |
27 | 1 | J. Wienke | |
28 | 15 | J. Wienke | identified problems: |
29 | 15 | J. Wienke | |
30 | 15 | J. Wienke | * Footprint too large for embedded systems |
31 | 15 | J. Wienke | * Architectural erosion |
32 | 15 | J. Wienke | * Unmaintainable code base |
33 | 15 | J. Wienke | * important parameters and implicit assumptions should not be hidden in the code for analysis |
34 | 15 | J. Wienke | * missing introspection functionalities |
35 | 15 | J. Wienke | * bad error handling strategies, e.g. missing transparency for the client (i.e. swallowed exceptions) |
36 | 20 | J. Wienke | * sending schema-free messages was too easy |
37 | 15 | J. Wienke | |
38 | 15 | J. Wienke | lessons learned: |
39 | 15 | J. Wienke | |
40 | 15 | J. Wienke | * layered architecture with improved functional decomposition in distinct libraries, layers: |
41 | 15 | J. Wienke | ** core (bus realization across different transports) |
42 | 15 | J. Wienke | ** tools |
43 | 15 | J. Wienke | ** XML compatibility layer |
44 | 15 | J. Wienke | ** XCF API adapters |
45 | 15 | J. Wienke | * clear dependency statements: |
46 | 15 | J. Wienke | ** core must survive with the least amount of external libraries |
47 | 15 | J. Wienke | ** different language implementation should not depend on a single base implementation (reduce development and deployment complexity, increase usability of the framework) |
48 | 15 | J. Wienke | * development process |
49 | 19 | J. Wienke | ** bigger developer team > 1 experienced person |
50 | 15 | J. Wienke | ** clear testing strategies |
51 | 15 | J. Wienke | ** continuous integration |
52 | 15 | J. Wienke | * allow more flexibility through defined interfaces and protocols |
53 | 15 | J. Wienke | ** allow different transports, e.g. in-process |
54 | 15 | J. Wienke | ** encoding flexibility for user data to meet domain and performance requirements |
55 | 1 | J. Wienke | * provide additional system structures like services to aggregate coherent functionality |
56 | 19 | J. Wienke | * avoid centralized nameservice |
57 | 20 | J. Wienke | * possibility to send schema-free messages is still possible, but using well-defined schemas is much more enforced |
58 | 7 | J. Wienke | |
59 | 23 | S. Wrede | h2. What is and what it is not |
60 | 23 | S. Wrede | |
61 | 23 | S. Wrede | * Soft-RT but no hard real-time |
62 | 23 | S. Wrede | * in-process, shared-mem, ipc |
63 | 23 | S. Wrede | * no component architecture |
64 | 23 | S. Wrede | |
65 | 17 | J. Wienke | h2. Functional properties (so far): |
66 | 2 | J. Wienke | |
67 | 1 | J. Wienke | * Event-driven middleware with broadcast semantics |
68 | 17 | J. Wienke | ** Additional communication patterns implemented on top of this base functionality |
69 | 1 | J. Wienke | * logically unified bus across multiple transports |
70 | 1 | J. Wienke | ** currently a spread-based and an in-process transport are available |
71 | 4 | J. Wienke | ** extensible to other transports -> compatibility to existing frameworks |
72 | 1 | J. Wienke | * Bus is structured by hierarchical channels |
73 | 1 | J. Wienke | ** / receives all messages of sub-scopes like /a/test |
74 | 16 | J. Wienke | * Support for filtering events: |
75 | 16 | J. Wienke | ** content-based |
76 | 1 | J. Wienke | ** on meta-data |
77 | 19 | J. Wienke | * URI-based |
78 | 16 | J. Wienke | |
79 | 16 | J. Wienke | Adopted concepts (from XCF): |
80 | 16 | J. Wienke | * event-driven |
81 | 16 | J. Wienke | * broadcast semantics |
82 | 16 | J. Wienke | * content-based filtering |
83 | 16 | J. Wienke | * introspection |
84 | 2 | J. Wienke | |
85 | 17 | J. Wienke | h2. Non-functional properties (so far): |
86 | 2 | J. Wienke | |
87 | 17 | J. Wienke | * lightweight (will remain [for the core]): |
88 | 2 | J. Wienke | ** small dependency footprint for the core layer |
89 | 2 | J. Wienke | ** Targeting at embedded systems (e.g. Nao) |
90 | 2 | J. Wienke | * Languages: cpp, java, python, common lisp |
91 | 2 | J. Wienke | ** real implementations, no bindings to provide natural interfaces in each language |
92 | 2 | J. Wienke | * No single wire type like XML: |
93 | 2 | J. Wienke | ** instead arbitrary client data is serialized to different wire types using (user-installed) converters |
94 | 6 | J. Wienke | *** default set of converters exists (e.g. source:/trunk/cpp/core/src/rsb/converter/StringConverter.cpp) |
95 | 3 | J. Wienke | ** provide flexible and fast serialization mechanisms |
96 | 3 | J. Wienke | ** XML support layer as additional library |
97 | 18 | J. Wienke | * performance requirements on network-based (UDP) and in-process transport |
98 | 18 | J. Wienke | ** no hard real-time |
99 | 1 | J. Wienke | ** avoid serialization when possible |
100 | 19 | J. Wienke | * No hard dependency on name service |
101 | 3 | J. Wienke | |
102 | 3 | J. Wienke | h2. Planned functionality: |
103 | 3 | J. Wienke | |
104 | 3 | J. Wienke | * introspection tools |
105 | 1 | J. Wienke | * model-based setup |
106 | 21 | J. Wienke | * Naming, Service discovery |
107 | 21 | J. Wienke | ** Distributed (e.g. mdns, upnp, etc.) |
108 | 21 | J. Wienke | * Sychronization primitives |
109 | 21 | J. Wienke | ** E.g., AV Fusion |
110 | 21 | J. Wienke | * Tools, in particular |
111 | 21 | J. Wienke | ** Introspection |
112 | 21 | J. Wienke | ** Logging, Replay |
113 | 21 | J. Wienke | * Platforms |
114 | 21 | J. Wienke | ** Web integration (WebServices) |
115 | 21 | J. Wienke | ** XMPP |
116 | 21 | J. Wienke | ** Mobile devices |
117 | 21 | J. Wienke | ** DNLA (streaming, etc.) |
118 | 21 | J. Wienke | * Timing |
119 | 21 | J. Wienke | ** Time-informer |
120 | 21 | J. Wienke | *** Clock source |
121 | 21 | J. Wienke | *** Synchronization |
122 | 21 | J. Wienke | ** Associated Patterns |
123 | 21 | J. Wienke | *** Clock-driven behavior |
124 | 21 | J. Wienke | *** Clock-based filtering |
125 | 21 | J. Wienke | * Model Layer/Component Model |
126 | 21 | J. Wienke | ** Role of @Service@ class |
127 | 21 | J. Wienke | * Framework Interoperability |
128 | 21 | J. Wienke | * Plugin Mechanism (for C++) |
129 | 21 | J. Wienke | * Content-based filtering |
130 | 21 | J. Wienke | ** ProtocolBuffer layer |
131 | 21 | J. Wienke | ** Ideally, without unpacking |