The circle of life(cycle)

Standardising software lifecycle tools: OSLC and Eclipse Lyo

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.

Diana Kupfer

What do you think?

JAX Magazine - 2014 - 03 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions