Software Tools on Demand

DRAFT - Not for distribution or attribution; For review purposes only.

The Webmetrics Project - Exploiting "Software Tools on Demand" ¥

Giancarlo Succi¥, Luigi Benedicenti§, Carlo Bonamico§, Tullio Vernazza§ Department of Electrical and Computer Engineering – The University of Calgary § DIST – Università di Genova

Abstract This paper presents a client/server stateless server architecture to implement collaborative data collection by means of several software tools. Each of the tools can be downloaded as needed in an “on demand” fashion. Security and accounting features are supported. An implemented example is shown based on a metric collection problem.

1 Introduction TV on demand is popular nowadays. People can select the program they want on a given TV channel and immediately (a) pay for it and (b) enjoy the program. No delay occurs. People are not committed to watch any other program in the same channel. People cannot use that channel any more if they do not pay for it. This provides high flexibility in the TV market; this flexibility is beneficial for the customers, who can select the program they like, and to the providers, who experience lower entry barriers in the market. The idea of "Software Tools on Demand" stems from the idea of TV on demand. A software company could develop tools that can be purchased on a "pay-per-use" basis by users. Internet and Java enable a full exploitation of this concept. Tools can be downloaded from the Internet, provided that the network is fast enough to cope with the desire of the purchaser. Tools can be written in Java: the tool can run on any platform, provided that the user has the suitable virtual machine / Internet browser. Webmetrics has been developed around the idea of Tools-on-Demand. It is a tool to measure software reuse metrics. Software metrics are computed by Java applications developed using JavaCC. The server is built around an ODBC-compatible database supporting authentication of access and security of transmission. This paper describes the main features of the architecture of Webmetrics and of the tool itself, and outlines the directions of future development. It is organized as follows: Section 2 presents the architecture. Section 3 addresses the security issues. Section 4 presents Webmetrics, the example implementation. Section 5 draws some conclusions and directions for future work.

2 The Webmetrics Architecture The Webmetrics architecture is shown in Figure 1. It is a three-tier architecture, involving heterogeneous communicating elements. The architecture’s main goal is to provide a flexible and interoperable environment that supports on-demand remote tool download in simultaneous connection to the server. This objective results in many advantages for the users in terms of the following: ·

¥

Version checking: neither the user nor the server must be concerned with getting the most upgraded version of the tools, because there is only one version on the server at any time, and it is the most current

Address for correspondence: Giancarlo Succi, Department of Electrical and Computer Engineering, The University of Calgary, 2500 University Drive, Calgary, Alberta, Canada T2N 1N4. E-mail: [email protected] Page 1


· ·

No local storage consumption: in theory, no local storage but some temporary storage is required for the tool to run. Caching systems will surely consume the local storage, but they are not implemented in the architecture and thus can be easily excluded The objects on which the tools have to interact can be local objects, avoiding the necessity to send them over a possibly slow and/or insecure network

Webmetrics Architecture Webmetrics Server

Client

Database

Tool

Data

Data

Source Objects

Off-Line tools Results

Report Report Result

3

Figure 1: Webmetrics architecture

The Internet plays an important role in this architecture, because it is the vehicle used for communication between the server and the client machines. The main goal is to maximize the utilization of the tools throughout the Internet in order to obtain the highest “audience” in terms of server demand. Thus, interoperability is not only a design goal, but it is really a prerequisite that can be included in the architecture. It is for this reason that from the very first design we have employed one of the most interoperable languages available: the Java language. Java allows for standard data formats, realizes an automatic marshalling of the data among different machines, and provides standard basic network I/O operations. Due to the unreliable structure of the Internet, the protocol used during the interactions between client and server has to be stateless. Stateless protocols are increasingly gaining acceptance in the Internet world. The World Wide Web itself is based on a stateless protocol: the HTTP. A stateless protocol provides many advantages over protocols that maintain state (stateful): mainly, each interaction with the server is a transaction. This may not be optimal for block file transfer or for interactive terminal sessions, but it is ideal for a tool that has to be transferred to a machine and then used locally, and relies on the completion of the transaction for displaying the results to the user. Stateless protocols allow transactions with consistency control based on the “at least once” commit approach. The modular, object-oriented structure in the architecture permits the use of any tool that imports the communication class protocol. During the design of the tools, this allows for the construction of stubs and Page 2


proxies in any language, acting as wrappers of the main Java interface class. This structure is depicted in Figure 2. LISP Tool

Wrapper

Java Interface

C Tool

Wrapper

Java Interface

C++ Tool

Wrapper

Java Interface Java Interface

Java Native Tool

Java Interface

Figure 2: Interface Class Structure

This way, the interaction between the server and the client is preserved as standard, and resists changes in the interface class that, being conceived as a lightweight class, can be easily improved. The architecture provides a basic working mechanism to the user. When remote users want to use a tool (e.g. measure some metrics/properties of some source code), they open the corresponding URL in their browser. That URL can obviously be part of a web page containing basic usage examples and/or links to other servers. When users open this page, a Java applet is downloaded to their computer. The applet performs its duty, then results are sent back to the server and stored in a RDBMS. Finally, they are shown to the users, too. Ideally, the tools can be of any kind. There is no limitation in the kind of interaction that can take place between the client and the server. The only restriction lies in the stateless nature of the underlying protocol.

3 Managing Security and Permissions Because of the needs of real-world intranet and internet operations, strong security is an important requirement for a distributed application like Webmetrics. It is also important to allow future upgrades of security mechanism and policies, in case present protocols becomes no more secure with time. Webmetrics address those problems with 3 core features: authentication, permissions, and secure transport.

3.1 Authentication To make a sound analysis of database content, it is important to know where the collected metrics come from. Client authentication is also important, to distinguish between users and administrators, and as a base for accounting and permission-based access to the tools. Webmetrics supports authentication by encapsulating all relevant information in a Token object that is transmitted to the server along with the metric packet. Upgrades are easily performed by changing the Token with a newer one. In present version, the Token contains only username and password, which are verified at the server by matching them against those stored in a simple Microsoft Access database queried using JDBC. Page 3


3.2 Permissions Different tools, including the administration applet, have different audiences, also because in a commercial implementation of Webmetrics their use could be differently billed. So the server checks if the operation requested by the client is one marked as allowed in a permissions database, queried with JDBC. Only the administrator can change permissions, though a hierarchy of administrators could be implemented in the future to fulfill the needs of different workgroups using the same server. The permissions database also contains information regarding the number of times, or the number of days for which each user is granted access to each tool, to allow for different billing policies. That information is used by the server’s authentication module when it is to decide whether to allow a specific operation.

3.3 Secure transport Different ready to use libraries implementing SSL and other security protocols are being evaluated for integration with Webmetrics. At the moment, the transport interface includes stubs for secure transport, but they are not yet enabled.

4 Webmetrics Implemented 4.1 Overview

Webmetrics Implementation Webmetrics Server

Client

Database

Parser

Metrics

Metrics

Source Code

Query & analysis tool Report

Report Report Report

3

Figure 3: Webmetrics is built around a three-tiers architecture

The three-tier general Webmetrics architecture specializes in a metrics-oriented, client-server Java application couple. The client is a Java 1.1 applet, and the server a Java 1.1 application, to ensure portability across different platforms, but support for external, non Java, tools is being added. Page 4


Because of present Java applet security constraints, the Webmetrics server must run on the same server the applet was downloaded from. This means that the same machine that hosts the Webmetrics server must also host a web (WWW) server. Eventually, integration of the two may occur.

4.2 Client features The clients are Java 1.1 applets and run inside a web browser. A single server can handle different client applets, each providing a specific service to the user. By now, applets that parse and measure Cobol, Java, RPG source code have been developed. There is also an Administration applet, to allow remote control of the server. A protocol to invoke external Java and native tools, and to execute SQL statements on the database created by the server is being implemented, so that remote users will be able to use complex statistical and querying tools on Webmetrics database. All applets send packets of data to the server. At present, only one packet per TCP connection can be sent. Multiple simultaneous connections between the same applet and the server can be active at any given time, though. Webmetrics exploits Java 1.1 serialization mechanism to transmit those packets: they are in fact plain Java objects, containing data in member variables, which are serialized (converted to an ASCII stream) and sent to the server in the TCP connection. The default port number is set to 8888, but that can be changed. Each packet contains the following information: · Timestamp of the packet · Owners (user, group and software house) · Payload, consisting of either · a MetricPayload containing one or more Metrics ( Tuples) · or a ControlCommand () · a security token, used to verify data origin and control database access permissions To ease design and implementation of such client applets, a special wrapper class has been developed, which encapsulates packet creation and transmission to the server using the right protocol. This way, the transmission protocol can be changed (e.g. TCP vs. UDP) without affecting client code. All developers have to do is to import the package webmetrics in their classes, and talk to an object of class WebmetricsClient using simple methods. This class has been designed to be lightweight, being downloaded every time the tool is used.

4.3 Server features The server is a multithreaded Java application, which can talk to many clients at a time. It handles data authentication and permission-based access control, data collection, communication with the RDBMS, and logging.

4.3.1

Remote maintenance

The server is administered by way of a special applet which, using secure authentication and transport protocols, can be used to enable or disable the server, and to manage the database (e.g. by adding tables and columns for a new client type), or even to perform a shutdown/restart. Protocol SERVER

Command Parameter Meaning String String Shutdown stop the server and exit Java VM On the server will accept Metric packets Off the server will accept only control commands Page 5


and not metric data executes a SQL statement over a specified a statement database and returns the result

DATABASE SQL EXTERNAL

Command parameters execute an external, possibly non-Java, tool name Figure 4: Format of control commands

4.3.2

Logging

To help identifying problems, and to verify the correct functioning during any period of time in order to ensure accountability, the server logs significant events to a log file. Sun Sun Sun Sun Sun Sun Sun Sun Sun Sun

Feb Feb Feb Feb Feb Feb Feb Feb Feb Feb

08 08 08 08 08 08 08 08 08 08

11:24:38 11:24:40 11:25:35 11:25:36 11:25:37 11:25:37 11:25:37 11:25:37 11:25:37 11:25:37

GMT+01:00 GMT+01:00 GMT+01:00 GMT+01:00 GMT+01:00 GMT+01:00 GMT+01:00 GMT+01:00 GMT+01:00 GMT+01:00

1998new Webmetrics Server created - port=8888 1998Webmetrics server started on port 8888 1998Connection accepted from 194.247.0.13 1998A packet was received from 194.247.0.13 1998Connection accepted from 194.247.0.13 1998A packet was received from 194.247.0.13 1998Connection accepted from 194.247.0.13 1998A packet was received from 194.247.0.13 1998Server shutdown 1998Server is no more active

Figure 5: Example of a logfile

Each log message is one line long. It begins with a string representation of a GMT timestamp, followed by a string describing the event. If the same event can be generated by different threads, remote host IP address is also appended. The log flushes every line, so that, if the server crashes, all messages before the problem are saved. Logged events include startup and shutdown of the server, network errors and security violations.

4.4 Database features The server stores received metrics in a RDBMS. This also improves scalability and allows the use of off-theshelf querying and analysis tools.

4.4.1

Interfacing to the database

The server uses Java 1.1 JDBC libraries to access database resources. So it can use any database having suitable JDBC drivers. This is also needed to make the server truly portable. Using a JDBC- ODBC bridge (like Sun's sun.jdbc.odbc.JdbcOdbcDriver, which is present in standard Java Runtime Environment 1.1 distribution, or Microsoft's com.ms.jdbc.odbc.JdbcOdbcDriver which is present in SDK for Java 2.0), any ODBC data source can be used, including the popular Microsoft Access. Building of SQL statements from received data is confined in a specific class, so that the server can easily modified to exploit more efficient SQL constructs.

4.4.2

Database structure

This version of the server requires the following structure for the webmetrics ODBC source: A table for each business, named after the software house name. Each table must contain at least the following columns: · filename · fileversion Page 6


· groupid · user · tstamp · notes and optionally, one or more group of Metric columns · metricname (String)|(integer)|(float) · metricnameversion At the moment responsibility for the match between metric name on the server and the client is left to the client. Automatic administration of metric names will be added, through the use of special tables in the database. Since the server only performs updates to the database, it does not consider semantic of table name, user and group fields. It is possible to establish a hierarchy in the received data, representing different workgroups or projects in the software house, or different firms, by properly setting up the client and the data retrieval tool (Microsoft Access during the tests), although the server will not be aware of this hierarchy in current version. For each file, a version number is also stored, so that evolution of source code properties over time can be tracked. For each metric, a metricversion number is also received from the client and stored, to ensure data validity and integrity in case a bug is found in one of the parsers that calculate the metrics. Version number for the metrics is thus useful to distinguish data coming from buggy and valid clients. It can also improve quality of statistics data derived from the database, when different parsers produce slightly different result on the same source code.

5 Conclusions and Further Directions of Research The Webmetrics approach introduces a real-time, on-demand flexible shared tool system that presents its users with a self-consistent toolset. The toolset is easily expandable and upgradeable by the service provider without intervention from the users. Webmetrics has been implemented in a software metric collection tool. Its goal is to collect a large amount of data regarding software metrics, in order to conduct statistical analyses of the software development process at various sites with different characteristics. All the metrics data are sent over a general purpose, non-secure network, e.g. the Internet. Webmetrics has been implemented as a group of separate tools, downloadable on demand, which interact with a central server. We plan to continue the development of Webmetrics with special attention to: · extending the control protocol, to make remote management of the server simpler and more effective; · improving authentication (from username and password to challenge-response and certificates); · using of SSL or another secure transport to protect transmitted data; · improving client-side checking of packet validity · integration with other LIPS projects: Egidio, Gertrude, Pescarenico and other Software Engineering tools, to offer unified interface · implementing server support for real-time tools (chat, audio and video conferencing, whiteboarding, document sharing, source code review) by offering an extensible interface to external modules;

References [1] T. Berners-Lee, R. Cailliau, A. Loutonen, H. F. Nielsen, and A. Secret. The World-Wide Web. Communications of the ACM, 37(8), August 1994. Page 7


[2] T. Berners-Lee and D. Connolly. Hypertext Markup Language - 2.0. World Wide Web Consortium, June 1995. http://www.w3.org/hypertext/WWW/MarkUp/html-spec/html-spec_toc.html. [3] D. Eichmann, T. McGregor, and D. Danley. Integrating Structured Databases Into the Web: The MORE System. First International Conference on the World-Wide Web (CERN, Geneva, May 25-27 1994). Published as Computer Networks and ISDN Systems, 27(2):281-8, 1994. http://www1.cern.ch/PapersWWW94/more.ps. [4] World Wide Web Consortium. Hypertext Transfer Protocol (HTTP), 1995. http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTTP2.html.

Page 8