Table 3 shows the lines of code comparison and Table 4 shows the message count for the three technologies. Consistently, the number of lines of code for NetPebbles is small compared to the others. The NetPebbles program sizes varies from 19% to 42% of Java RMI and Aglets implementations. Even though the lines of code is not an ideal measure of complexity by any stretch of imagination, we use it in the absence of any other reasonable metric we could find. Our experience in coding these examples - a thoroughly subjective measure but certainly a better measure than the number of lines - also suggests a very similar trend.
Table 3: This table compares the number of lines of code to implement the
three examples.
Table 4: This table shows the message count for the
three examples.
The small code size and simplicity of NetPebbles implementations is a result of the scripting approach and the fact that the runtime hides the details of remote component access and script mobility. First, the scripting language does not require the developer to worry about importing packages, declaring types of the variables, or handling exceptions. We believe that this allows the developer to focus primarily on thinking about the application logic. Second, as much as possible, the complexities of the distributed system should be handled by the system. This is the approach we take in NetPebbles.
Using an agent technology, such as Aglets, requires the developer to be aware of the mobility aspects of the application. The program has to be aware of the location where it is executing so that it can do the right thing. In NetPebbles, mobility is transparent to the program - the script transparently moves to the location where components are available. From the programmers perspective, all component invocations appear as local calls. Additionally, Aglets do not support persistence of component instances naturally. It has to be simulated by use of slave agents. This further complicates programming for now the developer has to write code to handle messages exchanged between agents.
The Java/RMI approach requires that the programmer be aware of importing correct packages, types, and handling exceptions. The programmer has to ensure that the appropriate application binds to the correct stubs for accessing remote services, and application-specific ``Impl'' servers are running on all the machines that the application needs to get service from. This adds to the deployment complexity of the RMI based applications. Under NetPebbles, the runtime creates component instances on demand, i.e. when the script needs to use them.
With respect to the message count, the NetPebbles approach typically exhibits fewer number of messages when compared to either Java/RMI and Aglets. This is because the script moves to the site where the component is located - subsequent invocations on the component do not require sending new messages. Applications that rely on agent mobility generate fewer messages under Aglets (as in the Lunch application). However, when persistence of components is needed Aglet-based solutions generate messages that are comparable to the Java/RMI approach. The Java/RMI based approach would typically generate the maximum number of messages as each method invocation on a component requires a new message on the network. Note that in the current implementation of NetPebbles, during component creation a message is always sent to the component catalog to resolve component names and locations. These messages can be easily avoided by using intelligent caching strategies.
Clearly, the trend seen here may not extend to large applications. Furthermore, we do not imply that RMI (and all the classic client/server techniques) and Aglets are irrelevant or inherently inferior. These approaches are valid when an application developer wants to use the full power of a systems programming language, and therefore he or she is willing to invest in the necessary development costs. But when the developer can satisfy the application requirements largely by reusing components, the NetPebbles approach simplifies program development and deployment.
