Motivation

At first sight, the value of the synthesis of the WikiWikiWeb, Semantic Web and advanced cryptography for version control is not too obvious. They are dis- tinct from one another even though they are used in the same application space: PKI-based cryptography is used to secure HTTP sessions with the Secure Sockets Layer (SSL); the WikiWikiWeb is used for dynamic collaboration on the WWW; the Semantic Web aims to make the WWW into a Web of Knowledge. Our mo- tivation for using the WikiWikiWeb is based upon a WWW-based collaborative environment that is scalable and relatively easy to use. In Chapter3we discussed

the needs of our case studies, which included the attribution and enforcement of IPR. In Section 4.1 we described how this could work with our DP If we have a PKI to validate users, then the same mechanism can be used for authorship. The third part of the puzzle, the Semantic Web, is important not only for technolo- gies such as RDF and OWL, but the logic it is based upon, namely Description Logic. The vast majority of version control systems use a relational database which is formal and static; such systems are difficult to change. DL languages, for example, OWL DL are built upon RDF which is much better suited to knowledge federation than an RDBMS. This means the underlying structure of a version con- trol system that uses Semantic Web technology is relatively expressive and highly extensible. Coupled with this extensibility is another key advantage; the DL’s inference capability, which provides effective tools for the distributed management of the software engineering process.

4.6.2

Architecture

Figure 4.11: Online Collaborative Tool Architecture

Figure 4.11 shows the top level architecture of our online collaborative tool. Our architecture is split into three main portions: the client browser, the Jakarta Tomcat application server, and the RDBMS and WebDAV server.

Both on the client and server side, we use the Jena 2 Semantic Web frame- work [Carroll et al. (2004)] and its Named Graph extension library, NG4J16_{. We}

use NG4J extensively to manipulate RDF, Named Graphs and RDF digital sig- natures. Cryptographic support comes from the Bouncy Castle17 _{JCE provider}

16_{http://www.wiwiss.fu-berlin.de/suhl/bizer/ng4j/.} 17_{http://www.bouncycastle.org/.}

and the digital signing of Named Graphs allows us to track IPR attribution and enforce non-repudiation, suitable for our two use cases.

4.6.2.1 Client Side

The client side uses any standard web browser capable of executing a JavaTM ap- plet. Developers select their source code to upload; the applet’s job is to generate metadata based on those files and cryptographically sign it. Note that in this architecture, the integrity of the repository is vested in the trusted metadata de- scribed in Section 4.4; the repository contents may freely be duplicated to protect against loss of the primary site and core trust is vested only in individual authors, not in the repository itself.

The browser interface allows developers not only to check-in and update new source code but also to actively collaborate with other developers using the Wiki as an online development journal: design issues can potentially be tracked and additional information such as UML diagrams or collaborative “whiteboard” sketches for each class can be attached in the Wikipage or linked from the WebDAV repository as appropriate. Figure 4.12 shows the main Wikipage for our online collaboration tool. Developers can navigate through package and class hierarchies since each is represented by its own Wikipage.

4.6.2.2 Server Side

The server side is a generic servlet-based web application that hosts an enhanced instance of JSPWiki. JSPWiki handles all portions of the interface based on a template system similar to, but simpler than, Struts18_{. Wiki content is stored in}

an MySQL RDBMS as a Named Graph quad store19_{, in contrast to JSPWiki’s}

flat file persistent storage. Source code is stored separately from its metadata, in a WebDAV repository which can either be co-located with the Wiki or run on a different remote host.

To support external access to the Named Graph quad store, we have developed a web service interface that enables distributed knowledge federation. This function- ality will become critical when we consider new information that can be brought into the system by federating external sources (see Chapter 4.7).

Commit Process When the server processes requests from the client it ver- ifies the attached signature and endorses the commit with its own signature if successful. The additional signature adds a timestamp that confirms receipt of the commit and that the client’s Certificate Authority is known and trusted by the server. All signed metadata, once verified, is persisted in the quad store for later retrieval.

Wikipages Wikipages are stored as plaintext files, which give developers the op- portunity to discuss design issues, post news, link diagrams, and make announce- ments. JSPWiki has several plugins that make it easy to add UML [Jacobson et al.

(1998)] diagrams to wikipages. It is essential to complement the non-repudiable foundations of the repository (signed metadata) with this soft interface.

As an additional benefit besides the adherence to the Model View Controller (MVC) [Buschmann et al. (1996)] pattern, keeping the quad store and document storage mechanism separate from the Wiki means we can easily provide alternative access to the source codebase using Web or Grid Services [Atkinson et al.(2005)]. These can be used to support automatic build and installation of named releases onto Grid hosts.

Our online tool utilises Jena 2’s forward RETE rule engine for inference support. We have written various rules that match triple patterns to create new relations

18_{http://struts.apache.org/.}

which we can then query with an RDF query language like RDQL [Miller et al.

(2002)]. While our DL implementation is based around Named Graphs, it is com- patible with Jena 2, so we can take full advantage without any problems. Indeed, we have also used Jena 2’s OWL reasoner to check periodically the consistency of the quad store based on our ontology.