About creating OSLC-based integrations

If a product is enabled as an OSLC provider or consumer, you can create your own integration. The definitions and resources described in this section provide an introduction to the task. Information on OSLC enablement can be found at http://open-services.net/resources.

Integrations built with OSLC rely on the OSLC Core specification and a domain specification. The core specification describes primary integration techniques, use of HTTP and RDF (Resource Description Framework), and identifies the common features that every OSLC service should support Domain specifications are tailored to a particular ALM area, such as change management, test management, requirements management, or architecture management. Domain specifications comply with the core specification. For example, the change management specification defines a common set of resources, formats, and RESTful services for use in change management tools (consumers) and use by provider tools. Specifications describe a set of services and formats for interacting with other lifecycle tools and do not attempt to standardize the behavior of a tool or class of tools.

For an introduction and walk through of the planning and tasks required to create an integration with OSLC, see Getting Started with OSLC (enhanced). Product-specific information on OSLC enablement status for Rational products can be found in product information centers in the section on extending your product with OSLC services. This section also provides information on supported link types and resources that you need to build an integration.

Before you begin working with OSLC specifications, it is useful to be familiar with some basic OSLC concepts and with the Eclipse Lyo editor.

Consumers, providers, and resources

OSLC service providers provide an implementation of OSLC services. A service provider offers consumers information for displaying the link to a resource and rich previews of the resource.

An OSLC consumer is a web application that uses resources provided by service provider.

In OSLC, each artifact in the lifecycle is an HTTP resource that has a URI as its name and can be manipulated with HTTP methods, such as GET, PUT, or POST. Every artifact or resource has an RDF representation that consists of a subject, a predicate, and an object. For example, if you were to link from a requirement to a test case, the RDF representation would have the requirement as its subject, the type of relationship or link type as its predicate and the test case as its object, each identified by a URI.

Eclipse Lyo: a tool kit for creating integrations

Eclipse Lyo is an SDK to help the Eclipse community to adopt OSLC (Open Services for Lifecycle Collaboration) specifications and build OSLC-compliant tools. It includes a software development toolkit focussed on Java, a test suite to help ensure your integration is OSLC compliant, and a reference application with working samples and a simple server you can use in testing. For more information about Eclipse Lyo, see http://www.eclipse.org/lyo.


Feedback