Planning out a partial implementation of OSLC-CM

Our integration use cases that we want to add to Bugzilla require only a partial implementation of the OSLC Change Management specification:

• Service Provider and Catalogs: These resources describe the services offered and make it possible for consumers of the OSLC CM service to find the ones they need. In Part 2, you will use these to help implement Automated Bug Creation so that the Testing team’s build scripts can use Service Provider documents to locate a URL.
• OSLC representations for bugs: This means making each Bug available at a stable URI as an OSLC-CM Change Request resource, with RDF/XML and UI Preview representations via content negotiation. In Part 2, these RDF/XML representations will help automate customer notifications.
• Delegated UI for Creation & Selection: Enables users of other systems to create and select bugs in Bugzilla without leaving the web UI of those other systems. You’ll use these dialogs in Part 2’s to make it easy to link a customer incident to a Bugzilla bug.
• Creation Factories for bugs: Enables creation of new bugs by HTTP posting RDF/XML bug representations to the server. We also used this feature in Part 2 for Automated Bug Creation.

Although this leaves out some seemingly critical parts of OSLC (including UPDATE and DELETE via HTTP and OSLC Query), that’s OK.

First, though, we need to decide how we’ll add OSLC support to the existing applications.

Different approaches to implementing OSLC support

There are (broadly) three different approaches to implementing an OSLC-CM provider for Bugzilla (or any other software):

• The Native Support approach is to add OSLC-CM support directly into Bugzilla, modifying whatever code is necessary to implement the OSLC-CM specification.
• The Plugin approach is add OSLC-CM support to Bugzilla by developing code that plugs-in to Bugzilla and uses its add-on API.
• The Adapter approach is to create new web application that acts as an OSLC Adapter, runs along-side of Bugzilla, provides OSLC-CM support and “under the hood” makes calls to the Bugzilla web APIs to create, retrieve, update and delete resources.

Although any of these approaches are valid approaches for an OSLC implementation, here are some of the pros and cons of each:

In short, the Native approach is the right approach for tool vendor who wants to add OSLC support to the products that they understand well. The Plugin and Adapter approaches are best for when you want to add OSLC support to a tool that you’ve bought from a tool vendor or obtained from an open source project. If the tool has a good Plugin API and you like the language/platform that it requires, then try the Plugin approach. If not, then an Adapter approach is probably best.

In our case, building an adapter makes the most sense.

Architecture for the adapter

Download the OSLC4J Bugzilla adapter. We’ll be exploring the adapter instead of writing one from scratch.

The OSLC4J Bugzilla adapter is a RESTful web application built on Java EE with JAX-RS. It has the following additional dependencies:

• OSLC4J: part of Eclipse Lyo, OSLC4J is a Java toolkit that simplifies building OSLC applications
• J2Bugzilla: Java wrapper classes for Bugzilla’s XML-RPC based web services interface

In addition, it uses the following helper classes (in the utils directory):

• BugzillaHttpClient: helper classes for doing HTTP GET requests against a Bugzilla server
• HttpUtils: helper classes for working with HTTP requests and responses
• StringUtils: helper classes for dealing with strings
• XmlUtils: helper classes for XML processing

Finally, the JAX-RS resource definitions are in org.eclipse.lyo.oslc4j.bugzilla.services.