5.6 Realize Middleware Enhancements
5.6.4 Visualization
As components developed by the IAS group can be complex, a means of visualizing the internal state of components is helpful for understanding the system. Therefore I propose to develop a component specifically for visualization purposes. Such a component should provide an interface for drawing graphic primitives such as lines, circles and rectangles. Optionally, this interface could be extended for a specific project to draw higher level concepts such as graphs. The implementation of such a visualizing component is future work due to the limited time available. The component can best be implemented in Java as it provides a build in graphical library available on all required platforms.
5.6.5
Automated tests
The GNU build environment enables running all the declared test software that is developed in a project. This allows developers to automatically test the software after modifications to the source code. Test software contains user defined checks on the responses of the system and takes the form of a client component that can interact with one or more server components.
6
Results
This section evaluates the selected middleware product ICE, based on the extent in which it fulfills the identified requirements. First I evaluate in what extent the selected architectural styles can fulfill the functional requirements. Secondly, I evaluate the level of fulfillment for the non-functional requirements and the requirements for the middleware product itself.
6.1 Functional Requirements
As ICE is general purpose middleware, it can be used to realize distributed systems with any functional requirements. Additionally, section 5.2.3 shows that the selected request-reply and event based style are often used in architectures of autonomous robot and distributed sensor systems.
6.2 Non-Functional Requirements
To evaluate the level in which the non-functional requirements are fulfilled, I evaluate the level of fulfillment of the non-functional requirements as described in paragraph 5.1.2. The requirements for the middleware product to be open source and generally applicable are met by the selection of ICE.
6.2.1
Development time
By integrating ICE in a build environment and creating the IAS_Application class to hide unnecessary complexity of using the request-reply and event based style, the development time is reduced considerably. Only a short manual is required to enable developers to build distributed systems. In case of unanticipated problems with ICE, a support form is available that is used by an active user community and by the developers of ICE. Integrating existing software into a distributed system is possible by wrapping it in a desired interface. The possibility of architectural mismatches is reduced by providing both the request-reply and event based style.
6.2.2
Interoperability
By using ICE, developers are able to build distributed application consisting of components written in the desired languages C++, Java and others. As C code can be used in a C++ program it also provides support for the C language. At this time the build environment is available on Linux and Unix platforms but it will be made available on Windows shortly. ICE offers a facility to deal with firewalls and to access components that reside in a different network and only have a local IP address as described in chapter 39 of the ICE manual [46].
Components that use ICE as middleware can only interoperate with other components that use the ICE middleware. Interoperability with other middleware products needs to be realized by developing a bridge to other specific middleware products.
6.2.3
Modifiability
By providing both the request-reply and the event based style, developers are able to make a tradeoff between a tightly coupled system with control over other components and a loosely coupled system that can more easily be modified.
When using the event based style, removing a component that publishes data has no direct effect on the remaining components other then stopping the receiving of data. Removing a component that is subscribed to specific data has no influence on other components at all. With the event based style, components do not automatically reconnect to any replacement components.
When using the request-reply style, removing a server component will block all client components which will try to reconnect to any replacement server component with the same name. When after 30 seconds (the default set in the build environment) no new connection can be established, the client components time out and stop with an error message. Removing a client component does not affect the remaining components other then to reduce the load of the server component that is was calling.
6.2.4
Performance
Although ICE does not provide any filtering mechanism or a means to prioritize different types of data for the event based style, it still provides a good performance due to the efficient communication between components. This is possible because ICE, as a single product, defines its own language and platform independent representation of data which is optimized for speed. This representation is hidden from developers. Other solutions where several products are used to support different languages and platforms, often suffer from a more complex representation that reduces performance.
6.2.5
Testability
The testability of components is positively affected by the request-reply style that allows error messages to be returned to the component causing the error. Additionally the build environment allows for test software to be easily added to the automatic test suite and the logging facility provides an awareness of the state of the system as a whole.
However, several shortcomings can be identified based on the testability requirements. One of these is the inability to automatically visualize all the active components and interaction between them. As a result a developer does not have a good intuitive overview on what the system as a whole is doing. A second shortcoming is that with the current state of ICE and the enhancements, there is no way to automatically fix the order of interaction between components running in parallel although the interactions using the request-reply style are partially fixed. This makes error reproduction more difficult when a specific order of interactions is causing the error.
6.3 Conclusion
By choosing ICE, the functional requirements and most of the non-functional requirements are sufficiently satisfied so that the chosen solution is suitable for use in the IAS group. The biggest problem identified is that of the limited testability properties resulting from not being able to visualize all components and interaction and fix the order of interactions. Due to the limited time available for this work, no good solution could be provided for this shortcoming.
A middleware product that uses a central architecture, such as the shared resource in the event based style, would be able to automatically visualize all components and interactions. However, the request-reply style does not communicate via a central point but interacts directly with other components. Modifications to the ICE middleware product are required to automatically notify a visualization component of this type of direct
At this time I am not aware of any middleware product that allows to automatically fix the order of interactions between different concurrent components. This is a difficult problem as the order in which data is send is not necessarily the order in which data is received. I do not see how, in the short term, ICE can be adjusted to fix the order of all interactions for at least the request-reply and event based style.
7
Evaluation
After completion of this work I am satisfied by the chosen middleware selection strategy as described in section 4. Especially the central role of the identified requirements has allowed me to evaluate different middleware approaches without focusing on aspects that have little effect on the requirements of the IAS group. A middleware selection process, like any other design decision, must focus on both fulfilling the functional requirements and finding the optimal tradeoff between the non-functional requirements.
The middleware induced architectural styles are identified as the aspect of middleware the most influence on the requirements and therefore plays a central role in this work. By defining these architectural styles using the identified communication properties, the otherwise abstract architectural styles could be evaluated based on their effects on the requirements.
It could be argued that this selection approach results in a merely subjective and possibly biased selection of a middleware product. However, this is a result of the nature of the selection problem and not of the approach that was taken. The subjective nature of the middleware selection problem is caused by the large variety and complexity of middleware products, by the complex relation of the middleware induced styles on the requirements, and by the fact that only general requirements can be identified for future projects. As a result no objective weights can be assigned to the different requirements or to the effects different middleware products have on these requirements. In this work different weights are implicitly assigned by the rational that is given for the different decisions that are made.
Other middleware selection approaches have a stronger focus on the different tools that the middleware product supplies. These include tools for starting and stopping components, tools for runtime configuration of the connections between components, and tools for automatic distribution of new versions of components. The reason that there was little focus on such tools in this work was that these tools only had a small effect on the identified requirements. With different requirements these tools might have played an important role in the selection process.
Yet other middleware selection approaches focus on the interoperability with other systems that are already in use such as databases systems or other special purpose middleware products. The reason that there was no focus on these interoperability issues is that the IAS group does not use such system at this time and thus there were no requirements to do so. The only systems the middleware is required to interact with are the unknown middleware products used by future partners in future projects. As described in paragraph 5.5.1, interoperability between middleware remains a problem due to the lack of standardization. Therefore, interoperability between different middleware products is generally realized on an ad hoc basis by developing special-purpose conversion components that realize a bridge between the products.
Yet other middleware selection approaches focus on the software-development methodology and the support that different middleware products offer for a particular methodology. This work does not focus on this aspect as the IAS group has no standard methodology for software development, presumably because of the overhead of using methodologies for developing experimental prototype systems with a relatively short lifetime. Therefore, this aspect did not appear in the requirements and is thus ignored.
As concluded in the section 6, the selected middleware product ICE and the enhancements, sufficiently satisfy the identified requirements. Future projects, in which distributed systems are developed, will validate if the right requirements are identified or that important aspects were not discussed in the interviews that resulted in the current set of requirements. Judging from the previous projects undertaking by the IAS group, I belief that no
8
References
Books
[1]
Len Bass, Paul Clements, Rick Kazman. Software Architecture in Practice, Second Edition.
April 2003, 560 pages, ISBN 0-321-15495-9.
[2]
Chris Britton, Peter Bye. IT Architectures and Middleware: Strategies for Building Large,
Integrated Systems. 2nd edition, May 2004, 337 pages, ISBN 0-321-24694-2.
[3]
Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software
Architectures. Doctoral dissertation, University of California, Irvine, 2000, ISBN 0-599-87118-0.
Papers[4]
J.S. Albus, H.G. McCain, and R. Lumia. NASA/NBS standard reference model for telerobot
control system architecture (NASREM). Technical Report 1235, NBS, 1987.
[5]
R.A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and
Automation, April 1986.
[6]
A. W. Brown. Mastering the Middleware Muddle. IEEE Software, vol. 16, no. 4, pp. 18--21,
July 1999.
[7]
Patrick Th. Eugster and Pascal A. Felber and Rachid Guerraoui and Anne-Marie Kermarrec. The
many faces of publish/subscribe. ACM Computing Surveys, pages 114--131, 2003.
[8]
S. Fleury, M.Herrb, and R. Chatila. Genom: A Tool for the Specification and the
Implementation of Operating Modules in a Distributed Robot Architecture. In Proc. of the
IEEE/RSJ International Conference on Intelligent Robots & Systems (IROS), pages 842--848,
Grenoble, France, September 1997.
[9]
D. Garlan and M. Shaw, An introduction to software architecture, in: V. Ambriola and G.
Tortora, editors, Advances in Software Engineering and Knowledge Engineering, World Scientific
Publishing Company, pp. 1--39, 1993
[10]
David Garlan, Robert Allen, and John Ockerbloom. Architectural Mismatch or, Why it's hard
to build systems out of existing parts. Proceedings of the 17th International Conference on
Software Engineering (ICSE-17), April 1995.
[11]
Michael Goedicke, Uwe Zdun. A Key Technology Evaluation Case Study: Applying a New
Middleware Architecture on the Enterprise Scale. In Proc. of 2nd Int. Workshop on
Engineering Distributed Objects (EDO 2000), Davis, USA, Nov 2-3, 2000.
[12]
Barbara Hayes-Roth and Karl Pfleger and Philippe Lalanda and Philippe Morignot and Marko
Balabanovic. A Domain-Specific Software Architecture for Adaptive Intelligent Systems.
IEEE Trans. Softw. Eng., 1995.
[13]
M. Kleinehagenbrock, J. Fritsch, and G. Sagerer. Supporting advanced interaction capabilities
on a mobile robot with a flexible control system. In Proc. IEEE/RSJ Int. Conf. on Intelligent
Robots and Systems, volume 3, pages 3649--3655, Sendai, Japan, September/October 2004.
[14]
Alexei Makarenko, Alex Brooks, Stefan Williams, Hugh Durrant-Whyte. A Decentralized
Architecture for Active Sensor Networks. IEEE International Conference on Robotics and
Automation (ICRA'04) April 26 - May 1, New Orleans, LA, USA, 2004.
[15]
Elisabetta Di Nitto, David, S. Rosenblum. On the role of style in Selecting Middleware and
Underwear. In Proc. of Engineering Distributed Object 99, ICSE 99 workshop, pages 78--83, Los
Angeles, May 17-18, 1999.
[16]
G. Pavlin, M. Maris, and J. Nunnink. An Agent-Based Approach to Distributed Data and
Information Fusion. In IEEE/WIC/ACM Joint Conference on Intelligent Agent Technology,
Beijing, 2004.
[17]
N. Pryce and S. Crane. Component Interaction in Concurrent and Distributed Systems. In
Proc. Fourth International Conference on Configurable Distributed Systems, Anapolis, MD, USA.
IEEE Computer Society. May 4-6 1998.
[18]
E. Di Nitto, D.S. Rosenblum. Exploiting ADLs to Specify Architectural Styles Induced by
Middleware Infrastructures. In Proc. 21st Int. Conference on Software Engineering, Los
Angeles, CA, May 1999.
[19]
Douglas C. Schmidt and Carlos O'Ryan. Patterns and Performance of Distributed Real-time
and Embedded Publisher/Subscriber Architectures. Journal of Systems and Software, Special
Issue on Software Architecture -- Engineering Quality Attributes, 2002.
[20]
R.G. Simmons. Structured control for autonomous robots. IEEE Transactions on Robotics and
Automation, pages 34--43, 1994.
[21]
Jess Thompson. Avoiding a Middleware Muddle. IEEE Software, vol. 14, no. 6, pages 92--98,
1997.
Webpages
[22]
http://www.science.uva.nl/research/ias/
[24]
http://www.thales-naval.com/newsroom/naval-press-clips/29-oct-2004.htm
[25]
http://staff.science.uva.nl/~jellekok/software/
[26]
http://staff.science.uva.nl/~jellekok/robocup/2003/
[27]
http://www-iri.upc.es/people/porta/ambience/
[28]
http://www.cogniron.org/
[29]
http://aipc1.techfak.uni-bielefeld.de/projects/xcf/
[30]
http://combined.decis.nl/
[31]
http://combined.decis.nl/tiki-index.php?page=Distributed%20perception%20networks
[32]
http://www.cougaar.org/
[33]
http://staff.science.uva.nl/~wzajdel/project/
[34]
http://dictionary.reference.com/search?q=paradigm
[35]
http://www.theaceorb.com/
[36]
http://www.cs.wustl.edu/~schmidt/ACE.html
[37]
http://www.omg.org/gettingstarted/corbafaq.htm
[38]
http://www.zeroc.com/
[39]
http://www.w3.org/TR/soap/
[40]
http://www.soapware.org/directory/4/implementations
[41]
http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html
[42]
http://groups-beta.google.com/group/comp.object.corba/browse_frm/thread/55cd6ee5a7010ee8
[43]
http://www.zeroc.com/iceVsCorba.html
[44]
http://sources.redhat.com/autobook/
[45]
http://www.cygwin.com/
[46]
http://www.zeroc.com/download.html#doc
[47]
http://www.zeroc.com/performance/
Appendix A
Prioritized utility tree
Utility Tree W. Zajdel N. Vlassis J. Kok
Quality Attributes Attribute Refinements Scenarios grades grades grades
Interoperability Language A developer can choose to use C, C++ or Java to develop a component of the
distributed system. 10 5 10
A developer can choose C# to develop a
component. 5 1 2
A developer can choose Matlab to develop a
component. 5 2 7
Platform A developer can choose to develop a component on the Windows, Linux or Unix
operating system. 10 2 10
A developer can choose to develop a
component on a PDA or Palmtop. 5 5 0
Middleware It should be easy to develop a bridge for communication with other middleware products (e.g. when cooperating with other organizations).
1 8 5
Network It should be possible to easily connect components that reside in different local networks (where their IP addresses have only local meaning).
3 8 3
Modifiability Component changes Changes to a component should have a minimal effect on other components with
which it communicates. 4 5 7
Runtime changes The system continues normal operations after a temporarily unavailable component reappears (e.g. in the event of temporal network failure).
0 9 5
Data that is send to a temporarily unavailable component is stored and resend to the component after it reappears. This way the system behaves as if the component has always been available.
0 5 3
Modularity A component should have minimal dependencies with the rest of the system
enabling efficient reuse of components. 5 7 7
Open source Middleware The middleware itself should be open source and simple to understand so that it can be
extended and modified when required. 5 10 7
The middleware should have an active user community which can give advice in the
event of problems. 5 4 7
Performance Network latencies The overhead of the middleware should result in no more then 100% increase in
network latency. 5 5 10
Priorities settings A high priority can be set to the communication of a specific type of information which requires fast network throughput.
M. Maris M. Spaan G. Pavlin O. Booij B.Terwijn Mean STD
Grades grades grades grades Grades grades grades
9 9 10 4 9 8.25 2.37546988 4 1 5 1 4 2.875 1.80772153 8 9 10 5 7 6.625 2.55999442 8 9 10 5 9 7.875 2.90012315 3 3 5 2 2 3.125 1.80772153 6 7 7 5 6 5.625 2.13390989 8 8 10 3 7 6.25 2.81577191 9 6 10 4 8 6.625 2.26384628 6 7 10 4 6 5.875 3.09088522 6 7 7 3 4 4.375 2.38671921 9 6 10 9 8 7.625 1.68501802 9 9 10 8 8 8.25 1.66904592 8 8 7 10 7 7 1.8516402 6 6 5 2 5 5.5 2.20389266 8 6 7 2 5 5.375 2.06587927
Testability Exception handling Errors and exceptions within a component should be communicated to the component
causing the exception. 9 8 10
Test generation Development time of test software (that tests interacting with one or more components) should be minimized. For example by partial code generation that takes the interfaces of components as input.
8 8 8
Visualization Visualization of the distributed components and their interaction should provide a high level overview of an otherwise inherently illusive distributed system.
0 10 8
The visualization should be able to pause the
distributed system, run it in slow motion, inspect interaction data and should allow runtime interaction with the system.
0 7 5
Debugging Debugging facilities should be available to
analyze the distributed system at runtime possibly in combination with the high level visualization.
7 8 7
Logging Logging facilities should be available to
analyze the past activities of the distributed
system. 7 8 10
Log messages of all the distributed
components should end up in a single file with guarantees on the relation between the order of the messages in the log file and the order in which the messages were produced.
7 8 5
Error reproduction It should be possible to (partially) fix the order of interactions between the components
when debugging. 0 8 5
It should be possible to record the states and
interaction of the components so that it can be repeated on demand for error reproduction when debugging.
0 6 5
Development time Familiarity time The time needed for a developer to familiarize with the development of quality
components is 1 week at maximum. 0 8 5
Simple example application should help
shorten the time to learn how to use the
middleware. 7 9 3
Development As much of the complexity of the
middleware as possible should be hidden from the developer to enable better overview and faster development. For example by providing a default component where all other components are derived from.
7 7 3
Complex features should be hidden until a