The circle of life(cycle)

Standardising software lifecycle tools: OSLC and Eclipse Lyo

Diana Kupfer
lyo1

We speak to the project leads for Lyo, which aims to bring open standards to the Eclipse community’s lifecycle tools.

 

Open Services for
Lifecycle Collaboration
, or OSLC for short, is a cross-industry
group aiming to define standards for compatibility of software
lifecycle tools. Its aim is to make it “easy and practical” to
integrate software used for development, deployment, and monitoring
applications.

Spearheading the efforts to bring OSLC specs to the
Eclipse community’s tools is Eclipse Lyo, which provides an
SDK, test suite and reference implementations. We spoke to Eclipse
Lyo project leads and OSLC members Michael
Fiedler
 (below left) and Steve
Speicher
 (below right) to learn more about both
projects.

JAX: What arguments would you use (or do you
use) to convince a company to join the OSLC?

Reasons for participating in OSLC differ based on what
role the tool user or organization has in lifecycle
integrations.

For a tool developer or vendor, an open integration
approaches like OSLC allows them to focus on their core
competencies by enabling them to create software using reusable and
open assets like Lyo which will interoperate with other tools both
inside and outside of their influence, providing time and cost
savings.

For a tool user, open integrations reduce the
complexity and risk of increasingly complex software
infrastructures, and improve the value of software across a broader
set of internal and external stakeholders.

System integrators can focus their energy and
resources on higher-value customizations, deliver more business
value to their clients, and increase client satisfaction.

The European CESAR project has produced an
excellent
video
describing tool integration issues in the systems
engineering space and the benefits of addressing them with a linked
data approach such as OSLC.

Overall, simple and flexible integrations with OSLC
make tools more useful and more valuable for almost everyone.

What makes the integration of lifecycle tools
so difficult?

Past approaches to integration have quite a few
shortcomings. They have relied on each individual tool providing an
API (often private and not supported) which allows its data to be
accessed, often tied to a specified technology: programming
language or platform. When trying to integrate multiple tools from
different vendors, the result is a web of fragile point-to-point
integrations. It becomes difficult to replace existing tools with
new ones. Even trying to upgrade or migrate a subset of the tools
can be impossible due to dependencies on specific versions of an
API.

There is a need to rethink the way tools interoperate.
OSLC proposes an approach similar to the way the internet works –
an approach based on uniform resource access using URLs, common
minimal data formats (while remaining extensible) and the use of
RESTful protocols which are not dependent on any particular
programming technology. Instead of copying or synchronizing data
between tools, OSLC uses linking to create a web of lifecycle data.
OSLC also defines some simple protocols for sharing Web UI
components for scenarios such as resource preview, creation and
selection.

The OSLC approach is to provide the minimal about of
specifications required to address integration scenarios developed
by the workgroups. This helps us sidestep another problem
encountered by previous interoperability efforts: over specifying
and making it burdensome to implement and support.

A year ago, we did a first interview for
Eclipse Magazin with you, Steve. Back then, you had a pretty clear
roadmap for Lyo in 2012: “an SDK for Java (and other technologies
depending on contributor interest); reference implementations of
select OSLC specifications; a test suite for OSLC implementations,
including compliance reporting; examples of enabling existing
applications for OSLC integrations (adapters for Bugzilla, Excel
and more)”. Looking back, did everything go according to plan on
your way to the 1.0 release in October?

Lyo 1.0 was able to deliver on all of those goals. We
are seeing good adoption of the Java SDK and several organizations
are using the OSLC test suite to assess their implementations. The
samples have provided a good starting point for developers new to
OSLC who are looking for some assistance in getting started.

The Bugzilla OSLC adapter has been particularly
successful as a demonstration of both the 1.0 and 1.1 features of
OSLC4J. It has been incorporated into a workshop and is the basis
for the
OSLC tutorial
.

What have been major challenges in trying to
enable the adoption of OSLC specifications in the Eclipse
community?

One challenge is the perception of many or even most in the tool
development community that the Eclipse community is only about tool
integration on the desktop around an IDE. We spend a good bit of
time explaining that Lyo is not an Eclipse IDE plugin – Lyo
provides tools for creating integrations compatible with many
different Eclipse technologies. Tool development is much more than
writing Java code and debugging it in the Eclipse desktop. Tool
development is moving to the web and the cloud and Orion, Hudson
and Lyo are great examples of Eclipse projects addressing those
environments.

How has the OSLC community changed over the past year?
Were there any significant structural changes or did it simply
continue growing?

 There have been some significant new
developments in the OSLC community over the past year.

The first is a change to the OSLC governance model
that rolled out in June 2012. The goals of this change were to
encourage community growth, enable the community to control its own
rules of operation and make it possible to take OSLC specifications
to standards bodies in the future. To these ends, several changes
were implemented. The first was the establishment of the OSLC
Steering Committee, an executive body consisting of representatives
from six
member organizations
. The Steering Committee is responsible for
operational decisions such as workgroup creation and specification
finalization approvals as well as business decisions around
marketing and community recruitment. Other governance changes
include new members agreements and workgroup participation
agreements with clearer flows for how intellectual property is
treated.

The OSLC Steering Committee has also recently
communicated a strategy for pursuing specification development and
standardization at OASIS. The feeling is that this is a natural
next step for OSLC and its specifications as they continue to
mature.

Finally, several OSLC workgroup members have been
active in the W3C Linked Data
Platform
working group. Concepts from the Linked Data Platform
specification will be incorporated in the next revision of the OSLC
Core specification.

Have any particularly important companies or individuals
joined the community?

In the OSLC community, we don’t consider any members
or participants to be any more or less important than others. The
full list of member organizations can be found at open-services.net/organizations
and the current list of implementers is at open-services.net/software.

In terms of Lyo, one piece of news your readers might find
interesting is that Lyo contributors have started collaborating
with the Eclipse Hudson team on implementing an OSLC Automation
provider for Hudson. Bug
398226
is tracking this work.

What features were added in the Lyo 1.1 release and
why?

Lyo 1.1 is a continuation of the work we started in 1.0. The
OSLC SDK for Java (OSLC4J) continues to evolve, and of course there
are always fixes for bugs. The most important enhancements are:

  • A new client API for developers of OSLC integrations.
    This was our most requested enhancement. The core of the API
    simplifies interactions with common OSLC resources such as Service
    Provider Catalogs and Service Providers. It also provides Java
    representations of other popular OSLC resources such as
    ChangeRequests, TestPlans and Requirements along with methods to
    serialize and de-serialize the objects to RDF.

  • A set of libraries and a web application for adding
    OAuth support to OSLC implementations. OAuth is a popular
    authentication protocol but is not always easy to implement
    correctly. The new Lyo libraries simplify the task. The provided
    web application includes some pre-built tools to help with
    delegated logins and administration of OAuth tokens.

  • An OSLC query library. This was another popular
    enhancement request. The library provides APIs for parsing and
    processing the OSLC query syntax and includes samples.

  • Test suite improvements. The OSLC test suite has been
    updated to include tests for the new OSLC Automation specification.
    Improvements also include expanded Requirements Management and
    Asset Management tests and several smaller enhancements and bug
    fixes.

In the project plan it says you want to provide SDKs for
technologies “other than Java”. Which ones in particular? You
mention Perl, and I think I read something about Python and
JavaScript…

 Perl, Python and JavaScript are three
technologies that we feel are important, particularly from an OSLC
consumer point of view. Scripting languages are a popular way to
quickly develop integrations. JavaScript is interesting because of
the growing popularity of Node.js for server side scripting. We are
trying to gauge the interest in having libraries and samples for
developing OSLC providers and consumers in Node.js. There are
certainly possibilities for other technologies as well (PHP, Ruby,
etc.) depending on community interest and participation.

The OSLC community recently announced the creation of the
OSLC4Net project at Microsoft Codeplex. Would you say that
developers of lifecycle tools have to think & work in larger –
or even global – contexts to broaden tool interoperability, beyond
the borders of software communities and ecosystems?

Absolutely. By their natures, tool integration and tool
interoperability require that developers broaden the contexts they
are working in, often forcing them out of their comfort zones. No
single ecosystem, whether commercial or open source can solve all
of these problems. Efforts such as OSLC provide technology neutral
approaches to these issues, but there is also important work going
on in communities like the W3C and OASIS. The same is true for open
source. There are linked lifecycle data projects coming out of the
open source communities at Eclipse, Apache, Codeplex, GitHub and
more. Each community has its own style of collaboration and
specific problems they are trying to address.

Another point in the project plan is “building a
community”. Can you elaborate?

Building a community means more than just increasing the raw
number of contributors and users of Eclipse Lyo. It means
increasing the diversity of the community and the quality of the
contributions and feedback. We want to see lots of downloads, new
bug reports and enhancement requests.

There are many organizations creating tools and
working towards integrations and interoperability – tool vendors,
internal development groups, universities, individuals and open
source projects to name a few. OSLC is a broader community focused
on lifecycle integrations and we see the Lyo project as the key
open-source sub-community. A project like Lyo can provide a natural
place for these groups to collaborate. Having the expertise,
experience and technical skills of a diverse set of contributors
and users benefits everyone.

A translated version of this interview was previously
published in the German-language Eclipse Magazin. Lion photo by
Tambako
the Jaguar
.

Author
Diana Kupfer
Working at S&S Media since 2011, Diana Kupfer is an editor at Eclipse Magazine, Java Magazin and JAXenter.de.
Comments
comments powered by Disqus