Overview » History » Version 14
J. Wienke, 06/10/2011 05:52 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 | 11 | J. Wienke | * 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 | 1 | J. Wienke | h2. Lessons learned (also from other frameworks) |
27 | 10 | J. Wienke | |
28 | 10 | J. Wienke | XCF: |
29 | 10 | J. Wienke | * identified problems: |
30 | 10 | J. Wienke | ** Footprint too large for embedded systems |
31 | 10 | J. Wienke | ** Architectural erosion |
32 | 10 | J. Wienke | ** Unmaintainable code base |
33 | 10 | J. Wienke | * lessons learned: |
34 | 10 | J. Wienke | ** layered architecture with improved functional decomposition in distinct libraries, layers: |
35 | 10 | J. Wienke | *** core (bus realization across different transports) |
36 | 10 | J. Wienke | *** tools |
37 | 10 | J. Wienke | *** xml compatibility layer |
38 | 10 | J. Wienke | *** XCF API adapters |
39 | 14 | J. Wienke | ** clear dependency statements: |
40 | 14 | J. Wienke | *** core must survive with the least amount of external libraries |
41 | 14 | J. Wienke | *** different language implementation should not depend on a single base implementation (reduce development and deployment complexity, increase usability of the framework) |
42 | 14 | J. Wienke | ** development process |
43 | 14 | J. Wienke | *** developer team ;) |
44 | 14 | J. Wienke | *** clear testing strategies |
45 | 14 | J. Wienke | *** continuous integration |
46 | 7 | J. Wienke | |
47 | 2 | J. Wienke | h2. Functional properties: |
48 | 2 | J. Wienke | |
49 | 1 | J. Wienke | * Event-driven middleware with broadcast semantics |
50 | 2 | J. Wienke | ** Additional patterns implemented on top of this base functionality |
51 | 1 | J. Wienke | * logically unified bus across multiple transports |
52 | 1 | J. Wienke | ** currently a spread-based and an in-process transport are available |
53 | 4 | J. Wienke | ** extensible to other transports -> compatibility to existing frameworks |
54 | 1 | J. Wienke | * Bus is structured by hierarchical channels |
55 | 1 | J. Wienke | ** / receives all messages of sub-scopes like /a/test |
56 | 2 | J. Wienke | |
57 | 2 | J. Wienke | h2. Non-functional properties: |
58 | 2 | J. Wienke | |
59 | 2 | J. Wienke | * lightweight: |
60 | 2 | J. Wienke | ** small dependency footprint for the core layer |
61 | 2 | J. Wienke | ** Targeting at embedded systems (e.g. Nao) |
62 | 2 | J. Wienke | * Languages: cpp, java, python, common lisp |
63 | 2 | J. Wienke | ** real implementations, no bindings to provide natural interfaces in each language |
64 | 2 | J. Wienke | * No single wire type like XML: |
65 | 2 | J. Wienke | ** instead arbitrary client data is serialized to different wire types using (user-installed) converters |
66 | 6 | J. Wienke | *** default set of converters exists (e.g. source:/trunk/cpp/core/src/rsb/converter/StringConverter.cpp) |
67 | 3 | J. Wienke | ** provide flexible and fast serialization mechanisms |
68 | 3 | J. Wienke | ** XML support layer as additional library |
69 | 3 | J. Wienke | |
70 | 3 | J. Wienke | h2. Planned functionality: |
71 | 3 | J. Wienke | |
72 | 3 | J. Wienke | * naming and discovery |
73 | 3 | J. Wienke | * introspection tools |
74 | 3 | J. Wienke | * model-based setup |