This chapter carries out a critical analysis of the design. In particularly, the chapter highlights where further development on the project needs to focus. No project done by one person can find all problems and discover new features or development. For now the discussion will focus on the areas that are need of change.
At present the system does perform a compilation build across multiple computers. A test was performed using a master and one slave. The master was started, read in the makefile and then waited for slaves. Once the slave was start the master started pushing jobs to it. The slave successfully built all components sent to it. The system was composed of integrating CORBA as the communication mechanism with CODA connecting the individual slaves with the master with all components involved running in Linux. This test might sound simple but it is important to remember that the goal of this project was to create a simple yet powerful proof of concept with minimal effort through maximization of software reuse using existing technologies. The system is small and lightweight with both the master and the slave being only around 170 kilobytes in size. There is a lot of performance in a small package. The next section will introduce future improvements that can make this system more dynamic and powerful.
The idea of simple client-server architecture is not a viable solution in today's enterprise networks. The future of distributed network applications will work through various middleware application servers. The DGCC project can fit nicely into this design. The master could be placed at the head or interface into a server farm and the slave taking up the rest. All jobs would be completed by first being sent via an interface to any programming environment (i.e. Codewarrior). The master would then complete the work by sending the commands to the slaves. At the same time using a Notification Service from CORBA would update the user's environment with the compilation status.
At present the master does not provide this type of interface. There will need to be a common Notification Service that the slaves use to communicate progress (success and failures) to the master. The master could keep track of this information in a log as well as sending the information to a CORBA capable programming environment.
At present the system does not lend itself to timing experiments. The slaves must all be started after the master. In the future the opposite needs to be true for accurate timing experiments to be done. These experiments will be vital for determining problem areas (e.g. slow or improper algorithms). Also these will be necessary to determine the actual performance of the system as a whole. It might be shown that a particular service is necessary to remove bottlenecks in performance and / or provide reliability through fault tolerance.
For this change to occur there needs to be a way for the master to resolve the location of all available slaves for the project. If all slaves are registered with the Name Service then the master simply queries it for a list. At present in CORBA 2 there is no method for this. The next version of CORBA, version 3, will provide a method for query for a type of object from the Name Service.26
At present there is no simple method for capturing the output of the master and all the slaves. There needs to be a way to incorporate the normal and debugging output into a logging system. In an article from Dr. Dobb's Journal, Tarak Modi introduces a dynamic logging system that uses the CORBA Notification Service. The CORBA Notification Service will replace the Event Service at a later date. It provides more complex filtering than the Event Service.
A possible system could be developed using the Notification System. The master could run a log server that uses multiple channels for obtaining the output from the various slaves. One channel could handle normal output that is sent to the screen. Another channel could be dedicated for varying levels of debugging. Mr. Modi proposed that:
"It is always desirable to have multiple channels, dedicating
each channel to a specific type of message(s). This way each channel
has a well-defined purpose and does not get bogged down. with every
message going through the system."27
The area of transaction processing is a very popular feature of a service
system. The idea is that the whole process that a client wants to a
server to do will not be valid unless all parts are completed
successfully. In a similar fashion the master could process all jobs
through slaves in a similar fashion. A possible high-level
abstraction of this could be:
| Copy job item to be done into waiting list indexed by a hash of the job item object. |
| Send job item to slave |
| Slave notifies master via Notification Service that it completes the job successfully. |
| Verify target file exists |
| If it is there then remove job item from waiting list. |
If at any point in the process there is an error then depending on the problem the job can be reissue. Any compilation problem, like a missing header file, then the system as a whole should stop. Alternatively a failure could be an indication of a misconfigured slave in the server farm. The job could be reissued. A successful completion should allow the system to continue.
The concept of transaction processing may not work for this type of system. Further research into this area will be necessary to ensure the concept is valid and necessary for the system to be more fault tolerant.
This is one area in which this project is sorely lacking anything. At present the system can work either as root or any system user. The system in the future should be preventing a user from using the system unless they have been granted access. Typical users have access to their local system and can do a lot with it. Yet they should be severally restricted to using remote services. A security model will need to be developed that at least:
| Uses Access Control List for what users are allowed to do |
| Uses Kerberos for authentication of master and slaves. This is necessary to prevent rogue slaves or masters from being introduce into the network. |
| Encryption of communications sent between slave and masters |
| Encrypted file transfer within CODA |
These issues will have to be investigated to understand what is actually going to be required. Additionally tests will have to be made to uncover leaks in security. Also by having this project open sourced there will be many eyes reviewing the code and thereby eliminating bugs and security risks.
5.2.6 General Distributed Configuration System
This system can be abstracted to an even higher level to be a distributed configuration system. By putting the intelligence, e.g. how to compile programs, into individual modules that can be loaded at run-time or as needed by the system as it is executing a requests. Modules would interface the system through a common programming interface could be added or upgraded as users see a need. This would allow the system to be much more customized to a larger set of problems thereby increasing its usefulness to a broader set of users.
This project has potentially many areas in which it can grow. One fundamental question that needs to be answered, "Is it needed?" If this project is just reinventing the wheel then is it doing something better or different? Once the fundamental question has been satisfactorily answered that development can begin to really take shape because there exists a need to be fulfilled.
| Previous: Chapter 4 - System Components | Home | Next: Chapter 6 - Conclusions |