The following projects all share a common theme: dynamic reconfiguration of software systems. Dynamic reconfiguration is an enabling technology for two classes of system: highly available and adaptive systems. As an example of the former consider the International Space Station. Beyond being the most complex engineering project to date, on-board software must run without interruption. Once of the roles of the software is to regulate oxygen supply to crew members. Clearly, this system must provide continuous operation. Like any software system though, the Space Station software must be maintained to correct bugs and to introduce new functionality. Dynamic reconfiguration techniques provide a means for making changes to software while it runs (i.e. without necessitating a shut down).
Dynamic reconfiguration is not restricted to advanced software systems like that of the Space Station. What about the software running on ATM machines? It would better for customers if the software in these machines was maintained and upgraded without denying customers service. What about web-based applications? Taking a web-server down for maintenance can be expensive. Unanticipated down-time costs web-based financial and trading systems (like eBay for example) millions of dollars. There are many other situations where taking a system off-line is undesirable.
Dynamic reconfiguration is also an enabler for systems that must adapt their behaviour at run-time. Imagine a robot that is configured with software for moving over smooth terrain. If the robot must cross a rougher terrain, it may need to use different control software that can be switched in at run-time. Robots often have limited on-board computing resources and s switching control software might involve unloading and loading new code on the fly. Another adaptive scenario involves a next generation lecture theatre with software controlled facilities. As you enter such a lecture theatre with your laptop, the laptop discovers the controllable facilities like lighting and heating. Your laptop then enables you to adjust the settings for these. This is an example of a system that changes at run-time in ways that weren’t anticipated during it's design – the laptop works with any new compatible device that it’s introduced to.
The following projects are suggestions for work that aims to contribute towards the vision of dynamic reconfiguration. If you are interested in a particular project please come and see me. If you’re interested in this general area and have your own ideas for a project, again, please come and discuss what you have in mind.
Please note that by taking once of these projects, there is an implicit expectation that you will write a paper to be published and presented at a conference. This is in addition to the actual work of the project, but it is valuable recognition that you have made a contribution to the field of software engineering.
Eclipse is a meta case tool – it’s a tool for developing tools. Eclipse is currently receiving much attention, both by industry and academia. The Eclipse home page (http://www.eclipse.org) describes some of the many tools that have been implemented using Eclipse.
This project is concerned with using Eclipse to develop a tool for graphical configuration programming using the OpenRec framework.
OpenRec is a framework for implementing component-based applications that are reconfigurable. An OpenRec application comprises a set of connected components that can be dynamically reconfigured. Reconfiguration actions can involve adding new components, removing components, replacing components and making changes to the connectivity structure – all at run-time. To initiate reconfiguration, users submit an XML description of the required change to the OpenRec reconfiguration management system, which then carries out the change in such a way to maintain the consistency of the application.
The idea of this project is to build a GUI-based tool, using Eclipse, to allow users to describe reconfigurations, rather than using XML, by directly interacting with a visualisation of the running system. The system could also listen for OpenRec events that describe reconfiguration actions and render these to shows the effects of reconfiguration on the executing system.
Two popular distributed system architectures include the peer-to-peer model and the client/server model. With the peer-to-peer model, nodes are not distinguished as either clients or servers, but typically play both roles. Essentially, any node can process requests as well as generate them.
In the client/server model, clients send requests to servers which process them and may send back a reply. With simple client/sever systems, a single server represents a single point of failure and a performance bottleneck. Reliability and fault tolerance can be accommodated by the client/server model using replication where several copies of the server are introduced. Replication, however, introduces consistency problems where the sate of servers has to be kept mutually consistent.
The aim of this project is to develop a model and associated implementation which enables the distributed architecture to be dynamically reconfigured. For example, a system might start off as a peer-to-peer system with 2 nodes but as more nodes are introduced, a replicated client/server architecture becomes a more scalable architecture which offers better performance.
The Pounamu case tool offers an ideal application for validating the work of this project. In particular, Pounamu has a collaborative plug-in facility where tool users can form a group and undertake a collaborative session. Since collaboration is carried out in “real-time”, collaborative actions must be handled by the tools in a timely fashion. As the group changes at run-time, the underlying distributed architecture linking the tools should likely also change to provide acceptable performance and reliability.
The OpenRec framework provides a lightweight component model where applications can be built comprising instances of components that are linked by connectors. Currently, OpenRec is not aware of different architectural styles, such as Pipe-and-Filter, Publisher-Subscriber, Explicit Invocation etc. Each such style imposes constrains on components, connectors and how they can be arranged. For example, in the Pipe-and-Filter style, components each run in a separate thread and connectors implement message queues. Each component is connected to at most one "upstream" component and at most one "downstream" component. A component receives an upstream message, processes it, and generates a message for its downstream component.
One aim of this project is to add architectural style support to OpenRec in the form of components, connectors and style rules.
It is likely that different architectural styles will be suited to different reconfiguration mechanisms. A mechanism is simply a technique for reconfiguring a component-based system that aims to do so safely (i.e. without causing the system to fail). Our initial work suggests that different mechanisms are needed for different architectural styles. Hence a second aim is to develop such mechanisms and associate them with particular styles. At run-time the OpenRec reconfiguration management system can then automatically pick the most appropriate reconfiguration mechanism(s) to manage reconfiguration.
Web services represent a natural evolutionary stage in the development of the Internet. The Internet has of course been used to host the world wide web where individuals use web browsers to request information from remote servers. In simple cases, this information takes the form of static HTML pages but in recent years a host of tools and technologies have emerged to offer dynamic generation of web pages.
With web services, users are not humans interacting through web browsers, but software components that programmatically invoke them. Web services are hosted by web servers but are typically registered with lookup services (registries). At run-time an application can access a registry to find a particular service and then invoke it. Web service applications may thus comprise a chain of web services that is established dynamically. Such applications are inherently loosely coupled and amenable to reconfiguration.
This project is tasked with investigating reconfiguration facilities for web services. Anticipated deliverables from this project include a model for reconfiguration of web services and proof-of-concept software.
(Jointly supervised with Bruce MacDonald)
The Robotics Research Group from the Electrical and Computer Engineering department has developed a service-based architecture for developing robotic applications. The architecture masks robot heterogeneity by allowing developers to publish well-defined interfaces for robots with similar capabilities. Using the architecture, developers can write control applications for any robot that conforms to these interfaces. Similarly, general services, such as robot navigation, can also be written that conform to a common (navigation) interface. This allows different implementations of a service to be accessed uniformly and the potential for interchanging them at run-time.
There is a growing demand to develop adaptive robots. An adaptive robot is one which can change its behaviour at run-time, depending on operating conditions. For example, when finding its way around an enclosed space, a robot might use a particular navigation algorithm. Once outside of this space, an alternative algorithm or a combination of algorithms might be more appropriate.
The goal of this project is to build on the service-based architecture, that has already been developed in CORBA, to add the necessary support for dynamically reconfiguring services. This includes adding, removing, migrating, and replacing services while the system is in operation. It is important to maintain integrity of the executing robot application and to introduce the reconfiguration capabilities so that they are as transparent as possible to robot application developers.
Sun’s J2EE architecture provides an infrastructure for enterprise-scale distributed computing. A key element of J2EE is the Enterprise Java Beans (EJB) component model. The EJB component model has proven commercially successful since it allows developers to build large distributed applications without having to program from the ground up aspects such as security, persistence, and distribution. These concerns are handled automatically by the EJB component model, allowing developers to focus on application concerns.
Once deployed, however, a J2EE application cannot be changed, for example, to correct bugs or to introduce new functionality. The aim of this project is to investigate how beans (components) can be changed at run-time. An Open Source implementation of the J2EE server named JBOSS is available which could be used to implement reconfigurable support.
A project with similar objectives could also be carried out using CORBA's component model as opposed to EJB.
