1. An Introduction to OSLC and Linked Data
OSLC: Lifecycle integration inspired by the web

2. Objectives and Pre-requisites
You will gain an understanding of the OSLC community, linked data, and the OSLC specifications
OSLC = Open Services for Lifecycle Collaboration
Pre-requisites:
none
Recommended reading:
After reading this presentation, you’ll gain an understanding of the OSLC community, of linked data concepts, and of the OSLC specification itself. 2

3. What’s next The OSLC community Linked data and RDF An example
The OSLC specifications 3

4. The Integration Problem
Point-to-point
Integrations
don’t scale
Monocultures
lock you in
Maintenance, management,
and change costs go up over time
Ongoing and unexpected
costs drain resources
End-user productivity suffers:
Either stuck with the wrong tool,
stuck doing manual integration;
often stuck doing both
Creating new
integrations is
unpredictable
What we have been illustrating, we can call “the integration problem.”
The integration problem has been around since the first user wanted two programs to work together. It has only got worse since software got more capable (and more complex), since groups of users wanted to work together across the different tools, and since businesses became more dependent on software.
1. (blues)
Traditional (point-to-point) integrations are based on proprietary APIs.
This places burdens:
On all vendors to invent their own good API (re-inventing the wheel each time), and
On all integrators (whether they be vendors, IT administrators, or end users themselves) to understand at least two APIs to create any integration.
Experience has shown these integrations to be brittle and difficult to maintain.
For IBM:
Our traditional assumption: 12 months, 6 developers; prototype in 2-3 months
A starting point like that indicates quite a bit of uncertainty about the effort.
2. (blues)
Software monocultures and the “hub-and-spokes” integration pattern, emerged as a way to minimize the negatives associated with traditional integration techniques.
Unfortunately, many ecosystem users then suffer from:
The inability to use the tools they prefer from within the ecosystem, and
The high cost of quitting that ecosystem all together.
In the long run, the ecosystem can become a burden to the dominate vendor as they bend to customer pressure to make sure dozens of external integrations work too.
Whatever software choices we’ve made in the past, integrations have been yet another proprietary data format that has locked us in.
3. (blues)
As time goes by, it isn’t only the visible costs of maintenance, management, and migration that go up:
Users also get frustrated, affecting morale and productivity, and
The lack of agility can result in lost business opportunities.
The costs of supporting these integrations can be near-fatal too!
Integration PMRs are difficult to diagnose (let alone solve!), consuming resources from new initiatives, and making our clients shoulder the burden of investments that are not showing returns.
Customers with low trust that our own products will integrate with each other, let alone 3rd-party tools
Cost (“Integrations consume …”) (see backup slide for stat details):
Special skills required to maintain the integrations
Risky to change any part of the system
Frustrating for IT staff who work to keep the system running for the present instead of innovating for the future
Copy and synchronization problems can be difficult to diagnose
Productivity Better software either unavailable because it isn’t integrated, or used without being integrated
May result in missed business opportunity
Copy and synchronization problems can effect business decisions
Change
The strength that was an integrated software system can become a weakness in the face of smaller, younger, competitors who don’t have to support dozens of special case integrations.
Today’s, and tomorrow’s, profits and competiveness are reduced by the effects on IT spending and user productivity.
Past choices
restrict present
action and
future vision
Integrations consume more of the IT budget:
integration failures are the top 2 causes
of software project delays*
More limited ability to respond to change
Constrained by exhausted IT budget and lower productivity
* Commissioned study conducted by
Forrester Consulting on behalf of IBM.

5. OSLC and Open Community: open collaboration, better integration
Identify Scenarios
Iterate on working drafts
Call it a specification
Gain technical consensus,
OSLC and its community try to learn from those past integration approach mistakes.
OSLC uses a minimalist approach. It does not try to give a complete definition for a given area, and it has a scenario driven scope.
The OSLC community co-evolves specifications and implementations, and uses open participation around active core groups. 5

6. The Basics: What is OSLC, and why should I care?
OSLC is an open community building practical specifications for integrating software
Tool Maker
create software using reusable and open assets that will interoperate with other tools both inside and outside your influence providing time and cost savings
Tool Manager
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
Tool User
choose the best tools for your job and have them interact seamlessly to achieve traceability and visibility with the rest of your organization
Systems Integrator
focus energy and resources on higher-value customizations, deliver more business value to your clients, and increase client satisfaction
OSLC is beneficial to many stakeholders

7. OSLC’s Simple Solution
Users can work seamlessly across their tools
Automation
Monitoring
Architecture of the Web
Standard Interfaces
Linked Data
“Just Enough” integration
Increased reuse
Increased traceability
You do this everyday! Web browser example. + single web page, data sourced from many places … ads, videos, pictures, tweets, comments, content, more links
Linking to application lifecycle data where it is created, instead of copying and synchronizing between tools, is the key insight of OSLC.
Doing so using standard interfaces, on top of a proven architecture, has helped many realize the value of OSLC already.
With OSLC, instead of worrying about integrating specific tools, we focus on composing a set of capabilities.
Animations (OSLC is …):
Approach to integrations
Philosophy of specification development
Set of specifications that tell you what and how to integrate various capabilities
It is also the open community where all this happens
4. Read
This has benefits to professional users (5), business leaders (6) and creators of integrations (7)
Decreased maintenance costs
Better visibility
OSLC is an open and scalable approach to lifecycle integration.
It simplifies key integration scenarios across heterogeneous tools

8. OSLC’s Big Picture Proven Open Innovative OSLC:
The Resource for OSLC Implementers
Tests, Libraries, Samples, Examples,
Reference Implementations
Future Home of OSLC Spec Dev
LINKED DATA PLATFORM WORKING GROUP
Open Services for Lifecycle Collaboration
Lifecycle integration inspired by the web
Scenario-driven & Solution-oriented
Leading choice for strategic integration technology
lets take a high-level look at OSLC and its place in the industry
OSLC
[click] Leading choice …: both for many of our clients who are choosing to use OSLC to integrate their homegrown tools with OSLC-enabled tools and demanding that vendors provide OSLC-based integrations; but also in public interoperability projects such as CESAR and iFEST in Europe, and PROMIS in Japan.
There are over 40 publically available tools that can be integrated using OSLC today.
[click] Generally applicable: OSLC ‘s original focus was ALM and the IT industry, but just as domain and industry faces similar integration challenges, a solution based on the principles of OSLC can be applied to all of them (and has already been to many)
“Simpler and flexible integrations with OSLC make software more useful and valuable for everyone.”
[click] Scenario-driven …: Specifications are written to enable high-priority scenarios, and are not complete until they have been implemented. Think of it as “Agile specification development”.
Eclipse Lyo (“Lee-o”)
[click] Started in 2011, the Eclipse Lyo project exists to provide an SDK for OSLC developers (NOT an Eclipse plugin)
Includes Java and Perl libraries for creating integrations based on OSLC specifications
.Net libraries available through the CodePlex project OSLC4Net
Libraries (and examples) for consuming OSLC data and for authentication using OAuth are included in the 1.1 (Feb 2013) release
Test Suites simplify validation of existing OSLC providers, and enable test-driven development for new ones
Reference Implementations for OSLC specifications are (being made) available through Lyo too
W3C
[click] OSLC has always been based on the “architecture of the web” and Linked Data, as described by Tim Berners-Lee
[click] In 2012, IBM, DERI, EMC, Oracle, Red Hat, SemanticWeb.com, and Tasktop submitted parts of the OSLC Core specification to W3C
The Linked Data Platform (LDP) Working Group ccurrently has 49 participants (all in good standing) representing 30 organizations
LDP will serve as the basis for future OSLC specifications
A reference implementation of LDP is being developed in Eclipse Lyo
OASIS migration
[click] On February 20, 2013, the OSLC Steering Committee (with members from Accenture, Creative Intellect, EADS, Siemens, Tasktop, and IBM) announced its intention to migrate OSLC specification development to the OASIS standardization track.
Targeting submission (and acceptance) at the May 1st OASIS Board meeting
OASIS Member Section construct allows the OSLC community to continue working the same way and maintain the relationships between domain specifications and the Core spec, while targeting formal standardization too
The larger OSLC community continues to center itself at open-services.net; think of OASIS as the subcontractor for specification development and standardization
[click]
Proven … Open … Innovative
Built on proven technology, used in production systems
Participation and use open to anyone, everywhere OSLC, Lyo, W3C, and OASIS)
As you can hear from developers and users, as you can see with LDP, OSLC brings real innovation to a challenging
Generally applicable: specs available for many domains covering ALM, DevOps, ISM, and PLM
Inspired by the web
Proven
Free to use and share
Open
Changing the industry
Innovative
OSLC:

9. Eclipse Lyo
Eclipse project created with the goal of providing tools to enable adoption of OSLC specifications.
Content includes
Code libraries (Java, Perl, others under development)
Give developers tools to ease OSLC implementations
Reference implementations of specifications
Provide a starting point for new integrations
Test suites and test reporting. Covers OSLC Core, CM, QM, RM and Asset today.
Accelerate and assess development
Samples, tutorials and documentation
Working samples of OSLC integrations with Bugzilla, Excel, Jazz tools and more.
- project started June 2011
NOT an Eclipse plugin – not related to the Eclipse IDE
Standalone set of tools (SDKs, sample, test suites)
Eclipse chosen has home for mature governance model, friendly IP policies
Lyo 1.0 going through Eclipse approval process now
OSLC4J 1.0 (Java SDK) – used in IBM and non-IBM products with OSLC integrations
OSLC Test suites
Community participation welcome and encouraged

10. What’s next The OSLC community Linked data and RDF An example
The OSLC specifications

11. OSLC turns data into... R1 R2 T1 T2 D1 D2 I1 I2 Requirements
Validation Tests
Design
Implementation
Tool A
Tool B
Tool D R1 R2 T1 T2 D1 D2 I1 I2
Tool C

12. ...connected information...
Requirements
Validation Tests
Design
Implementation
Tool A
Tool B
Tool D R1 R2 T1 T2 D1 D2 I1 I2
Tool C
validates
implements
validates
satisfy
Does every requirement have a test to validate it?
Which requirements for the UI are related to test cases that failed on their last run?

13. ...that can facilitate applied knowledge
Requirements
Validation Tests
Design
Implementation
Release
User Interface T1
validates
satisfy
implements R1 D1 I1
Processing Engine R2 D2 I2 T2
Note that in an OSLC context where lifecycle data is linked together, you can then use other tools to perform complex queries of data and analyze trends.
Tool A
Tool B
Tool C
Tool D
Why is the number of failed test cases for the UI increasing in each iteration?
How much faster is work progressing on the UI versus the Processing Engine?

14. OSLC links lifecycle data
Now let’s look at OSLC in a little more detail. OSLC is inspired by Internet principles and implemented with Internet technologies.
It uses simple interfaces for the exchange of resources.
Everything is loosely coupled as a a “resource” linked together with URLs
It is technology neutral and treats all implementations equally
It is minimalist and defines no more than necessary for exchange of resources
It is incremental. It delivers value now and adds more value over time
It is an openly published standard. It is free to implement and irrevocable
OSLC uses the architecture of the internet.
All data are resources with HTTP URIs
Use open standards; use loose coupling; be technology neutral; be scalable; be extensible
The data is the thing
Use resources and relationships
Tools operate on the data
Tools execute the process
Tools expose their data in a common way (REST)
Lifecycle integration = tracing, indexing, analyzing the web of lifecycle data where it lives.

15. Linked Data and RDF
Tim Berners-Lee’s four principles for linking data:
Use URIs as names for things
Use HTTP URIs so that people can look up those names
When someone looks up a URI, provide useful information using the standards (RDF, SPARQL)
Include links to other URIs so that they can discover more things
“Instead of defining a new data model, OSLC’s resource and property-value approach is based on industry standard Resource Description Framework (RDF) data model.”
Adapted from: OslcCoreSpecification
OSLC applies Tim Berners-Lee’s four principles for linking data, and is based on the industry standard Resource Description Framework (RDF) model.
RDF is:
a simple, powerful data model
used to define relationships between things
designed to work with the architecture of the web
the data model for the Web of Data
For more information, see

16. RDF Concepts OSLC applies some RDF key concepts: Graph data model
URI-based vocabulary
Format - Serialization syntaxes (RDF/XML, Turtle, JSON)
Datatypes
Literals
Expression of simple facts
Entailment
We’ll briefly look at some of them.

17. 1. OSLC uses an RDF graph data model
Subject
Object
Predicate
Test Case 1
Requirement 1
Amanda
Car
owns
validates
The predicate provides the property or relationship between the subject and object.
The underlying structure of any expression in RDF is a triple, consisting of a subject, a predicate and an object.
Each triple represents a statement of a relationship between the things denoted by the nodes that it links. Each triple has three parts:
a subject,
an object, and
a predicate (also called a property) that denotes a relationship.
The assertion of an RDF triple says that some relationship, indicated by the predicate, holds between the things denoted by subject and object of the triple.
A set of such triples is called an RDF graph. This can be illustrated by a node and directed-arc diagram, in which each triple is represented as a node-arc-node link (hence the term "graph").
The direction of the arc is significant: it always points toward the object. The nodes of an RDF graph are its subjects and objects.
The assertion of an RDF graph amounts to asserting all the triples in it, so the meaning of an RDF graph is the conjunction (logical AND) of the statements corresponding to all the triples it contains.
Adapted from:

18. 2. OSLC uses a URI-based vocabulary
When there is a need to identify anything in OSLC, use a URI (there are a few exceptions).
Using URIs allows everything to be linked together. It also allows common agreed-upon meaning for relationships and for resource types
< Case 1>
<
< 1>
OSLC Core URI Naming Guidance:

19. 3. OSLC allows different RDF formats
The RDF model provides for describing RDF triples. There are various supported formats. Some are specialized for RDF (Turtle) and others are derived from existing formats (XML, JSON). These formats can be exchanged between different applications (tools).
OSLC allows different types of format:
RDF/XML
Turtle
JSON
OSLC Core Specification:

20. Examples of different OSLC notations
< Case 1>
<
< 1>
Subject
Predicate
Object
< a oslc_qm:TestCase ;
oslc_qm:validatesRequirement <
Turtle {
"rdf:about": "
"rdf:type": [ {
"rdf:resource": "
} ],
"oslc_qm:validatesRequirement": {
"rdf:resource": " }
JSON
This slide shows the same subject-predicate-object triple example of test case 1 validates requirement 1 represented in different OSLC formats (Turtle, JSON and RDF/XML).
<oslc_qm:TestCase rdf:about="
<oslc_qm:validatesRequirement rdf:resource="
</oslc_qm:TestCase>
RDF/XML

21. What’s next The OSLC community Linked data and RDF An example
The OSLC specifications
This example is adapted from [David Wood, 3RoundStonesInc. November2011]

22. Here’s a fictional project
Existing product: Lunar Rover 3.0
New Release: Lunar Rover 3.1
Main goal is to improve remote steering
Release to orbit date: September 20, 2014

23. Let’s look at the requirements domain
Requirement Improve Remote Steering
Bob
owner
Lunar Rover 3.1
release
High
priority
owned by
Iris
created on
November 24, 2011
September 20, 2014
release to orbit date
Implemented
state

24. The same information as before, in tabular form
Requirement
Owner
Priority
Created on
State
Release
Requirement Add rear FIDO mast
Linda
Low
October 18, 2012
New
Lunar Rover 3.1
Requirement Improve Remote Steering
Bob
High
November 24, 2011
Implemented
Requirement Rebuild wheels for soil excavation
Tanuj
Medium
September 9, 2012
Reviewed
Rover Release
Owned by
Release to orbit date
Lunar Rover 3.0
Cheng
August 16, 2011
Lunar Rover 3.1
Iris
Sept 14, 2014

25. Let’s look at the quality domain
Test Case 35645: Test Steering
Janet
owner
Lunar Rover 3.1
release
High
priority
owned by
Iris
created on
December 7, 2011
September 20, 2014
release to orbit date
Executed
state
pass
result

26. Let’s add more relationships
validated by
Test Case 35645: Test Steering
release
Requirement Improve Remote Steering
owner
Janet
release
Lunar Rover 3.1
owner
Bob
priority
High
priority
High
created on
owner
December 7, 2011
Iris
created on
November 24, 2011
state
release to orbit date
Executed
September 20, 2014
state
Implemented
result
pass

27. The same information as before, in tabular form
Requirement
Owner
Priority
Created on
State
Release
Validated by
Requirement Add rear FIDO mast
Linda
Low
October 18, 2012
New
Lunar Rover 3.1
Requirement Improve Remote Steering
Bob
High
November 24, 2011
Implemented
Test Case 35645: Test Steering
Requirement Rebuild wheels for soil excavation
Tanuj
Medium
September 9, 2012
Reviewed
Rover Release
Owner
Release to orbit date
Lunar Rover 3.0
Cheng
August 16, 2011
Lunar Rover 3.1
Iris
Sept 14, 2014
Test Case
Owner
Priority
...
Test Case Test Steering
Janet
High
Lunar Rover 3.1
Iris

28. RDF triple (subject-predicate-object)
validated by
Triple
Requirement Improve Remote Steering
Test Case 35645: Test Steering
priority
High
Subject = Resource = always a URI
Predicate = Relationship or property = Always a URI
Object = Could be a URI (which could refer to a resource) or a literal value (value to work with and show users)
Resources:
Can represent things on the web, like web pages. These resources are information resources
Can represent things not on the web, like people and places. These resources are non-information resources
Can represent anything at all
Are usually named using URIs
May not have a name. May be a blank node.
Literal Values:
Are values to work with and show users
Can be just a string of text. These literals are plain literals
Can have a language assigned to them using ISO codes
Can have a specific datatype assigned to them. These literals are typed literals
Predicates:
Are relationships between resources or properties of a resource
Are named using URIs
Are described in Schema (or vocabularies,or ontologies)

29. RDF triple (subject-predicate-object)
<
Triple
< improve_remote steering>
<
<
“High”
Subject = Resource = always a URI
Predicate = Relationship or property = Always a URI
Object = Could be a URI (which could refer to a resource) or a literal value (value to work with and show users)
Here is a look at it with URI’s in place.
OSLC specifications define the “shape” of resources and objects and the meaning of predicates.

30. Let’s add more relationships
Work Item 38759
implements
Test Case 35645: Test Steering
validated by
release
Requirement Improve Remote Steering
owner
Janet
owner
release
Lunar Rover 3.1
Bob
priority
High
priority
High
owner
created on
The Work Item is from the Change Management domain.
December 7, 2011
Iris
created on
November 24, 2011
state
release to orbit date
Executed
September 20, 2014
state
Implemented
result
pass

31. There is a web of URIs around a development effort
< case>
<
<
<
<
< request>
<
<
validate

32. OSLC principles Tim Berners-Lee’s four principles applied to OSLC:
Use URIs as names for things
In OSLC, each artifact in the lifecycle (for example, requirements, change requests, test cases...) is identified by a URI.
Use HTTP URIs so that people can look up those names.
In OSLC, each artifact in the lifecycle is an HTTP resource. Standard HTTP methods (GET, PUT, POST, DELETE) are used to interact with them.
When someone looks up a URI, provide useful information using the standards (RDF*, SPARQL)
Each OSLC resource has an RDF representation. OSLC resources can be queried using SPARQL.
Include links to other URIs so that they can discover more things.
OSLC lifecycle artifacts are linked by relationships (for example, validatesRequirement or testedByTestCase) which are defined by URIs.
Now let’s look at how Tim Berners-Lee’s four principles apply to OSLC.

33. What’s next The OSLC community Linked data and RDF An example
The OSLC specifications

34. Anatomy of a specification
Core: Specifies the primary integration techniques for integrating lifecycle tools – the standard rules and patterns for using HTTP and RDF that all the domain workgroups must adopt in their specifications
OSLC Core Specification
How
What
OSLC Change Mgt Specification
Domain: Defines integration scenarios for a given lifecycle topic and specifies a common vocabulary for the lifecycle artifacts needed to support the scenarios.
Example: The Core specification describes Delegated UIs and Creation Factories and states that OSLC service providers MAY provide them. The Change Management specification states that CM service providers MUST provide them.
OSLC Requirements Specification
OSLC core specification defines:
How to use HTTP and RDF
How to define resources and services
OSLC domain specifications (Change Management, Requirements, etc.) define:
What resources and services are required in the domain
Resource types, properties and relationships
Service providers, creation factories, query capabilities, operations
OSLC Domain X Specification

35. OSLC defines the following technical areas:
1. Discovery of capabilities
2. HTTP C.R.U.D. for resources
6. UI Previews for Resource Links
3. Standard resource representations
The technical components of the specification are:
the discovery of capabilities
HTTP CRUD for resources
standard resource representations
querying for resources
a delegated UI for Create and Select
UI previews for resource links
5. Delegated UI for Create and Select
4. Querying for resources

36. First, some terminology (before we get to #1)
These catalogs are used in the discovery of OSLC service providers. They help to simplify the configuration of tools that will integrate with providers of OSLC-defined services.
OSLC Service Provider catalog
provides
example: IBM Rational Team Concert
OSLC Service Provider
A product or online service offering that provides an implementation of one or more OSLC Services, which may themselves implement different OSLC Domain specifications
provides an implementation of
example: IBM Rational Team Concert project area
Set of capabilities that enable a web client to create, retrieve, update and delete resources managed by an ALM or PLM product or online service offering and associated with one OSLC Domain
OSLC Service
RTC project area maps to
example: Change Management capability
manages
Managed by an OSLC Service, may have properties and may link to other resources including those provided by other OSLC Services.
OSLC Resource
example: work item (bug, defect, enhancement request)

37. 1. Discovery of capabilities
Starting from the catalog you can discover services and their capabilities. This is a common pattern in OSLC.
OSLC capabilities:
Delegated UI Dialog allows you to create or find resources using a UI provided by the OSLC tool
Creation Factory allows you to create resources programmatically
Query Capability allows you to query for resources
E.g.
Service Provider Catalog = RTC
Service Provider = RTC Project Area
Service = CM capability
Resource = Work Item
For an example of OSLC service discovery, see

38. Create = POST Request = GET Update = PUT Delete = DELETE
2. HTTP C.R.U.D
OSLC allows manipulation of resources using standard HTTP C.R.U.D
Create = POST
Request = GET
Update = PUT
Delete = DELETE

39. Resource Creation (Create)
Create a resource using HTTP POST, with the resource body in format of choice
URI for doing the POST is defined in the oslc:ServiceProvider in the oslc:creationFactory service
Response is a 201-Created with Location HTTP header indicating URI for resource
Request may be rejected for any number of reasons
Insufficient permissions
Missing required values
Invalid data choices
...and … and ...
Valid resource formats for creation are defined by:
domain specifications
service provider may define its own resources and formats
optionally, by resource shape associated with creation factory 39

40. Resource Retrieval (Request)
Use HTTP GET and standard HTTP content negotiation
Client uses HTTP Accept request header to specify desired resource formats
Use standard content(MIME) types
Partial representations can be requested via HTTP URL key=value pair as ?oslc.properties=
Allows for minimal retrieval of properties
Get Defect 123 (all properties)
Get Defect 123 (just title and status)
Accept: application/json, application/xml
GET
GET 40

41. Resource Modification (Update)
Use HTTP GET to get resource properties to be updated
You’ll get an ETag back
Change only the property values you need to change
Clients must preserve unknown content
Use HTTP PUT to send updated resource
Use If-Match HTTP request header with ETag, services may reject your request without it
HTTP PUT will completely replace the resource representation
We are moving towards PATCH – new HTTP verb
It is possible to update only selected properties 41

42. Resource Deletion (Delete)
Use HTTP DELETE on the resource identifier
May not be allowed
Response usually:
200-OK
204-No-Content
400-Bad-Request
403-Forbidden

43. 3. Resource representations
OSLC services should handle any type of resource
Not just those defined by OSLC
Resources defined by OSLC use RDF data model
therefore are simply defined by their set of properties
OSLC services MUST produce and consume RDF/XML representations
Clients and services MUST NOT assume any subset of RDF/XML
Other representations are allowed such as:
XML: OSLC defined format that allows for consistent formats and is RDF/XML valid
JSON: Rules for representing namespaces and QName properties
Turtle: No constraints, use as is (may be preferred by future specs)
Atom Syndication Format: <atom:content> SHOULD be RDF/XML 43

44. A few words on Resource Linking
Links are properties where the property values are URIs
Don't make assumptions about the target of links
OSLC supports an open model
Needed to achieve goal of “loosely coupled” integrations
Clients need to be flexible and expect anything
Sometimes we need to provide additional data about links: label, owners, and so on.
Special cases where links need more representation
Turtle format for a bug resource (abbreviated)
<
a oslc_cm:ChangeRequest ;
dcterms:relation < ; 44

45. 4. Querying for resources
Query capability has base URI
Clients form query URI and HTTP GET the results
OSLC services MAY support OSLC Query Syntax 45

46. Query syntax overview
Filter results by appending “oslc.where=” with query clause to query base URI
Only boolean operation allowed is “and” which represents conjunction
“or” for disjunction is not defined in the interests of keeping the syntax simple.
Retrieve just what you want with “oslc.select=”
Defined ordering using “oslc.orderBy=”
Full-text search via “oslc.searchTerms=”
Comparison Operators
= test for equality
!= test for inequality
< test less-than
> test greater-than
<= test less-than or equal
>= test greater-than or equal
'in' operator:
Test for equality to any of the values in a list. The list is a comma-separated sequence of values, enclosed in square brackets: in [“high”,”critical”] 46

47. Query syntax example
Find high severity bugs created after April fools day
Find bugs related to test case 31459
Find all bugs created by John Smith
cm:severity="high" and dcterms:created>" "
<
oslc.where=qm:testcase=<
dcterms:creator{
foaf:givenName="John" and foaf:familyName="Smith"} 47

48. 5. Delegated UI renders the source app UI in the target app
A delegated UI renders the source application UI in the target application. This example shows the contributed/delegated Rational Team Concert Work Item search dialog being rendered in an OSLC Quality Management application.
2. iframe's src set to delegated UI's URL
1. Click to launch delegated UI
3. Selection made
Contributed/delegated RTC Work Item search dialog
4. Click OK. Sends message (link+label) to parent window 48

49. Delegated UI key points
Delegated UIs support both creation and selection of resources
Two communication protocols are supported for iframes:
HTML5 postMessage() ← preferred method
Supported in most modern browers
Window object's window.name
Supported in older browsers and Eclipse embedded web widget
Consumer selects which protocol to use, informs provider via fragment identifier
Tremendous value for resource creation
Traditionally most service logic was communicated to client and new dialog built
Now the rules for creation and dialog change as needed
Prefilling of creation dialog done by “creating” a dialog resource
HTTP POST of resource format to creation dialog URL, response is URL of dialog prefilled 49

50. 6. UI Preview
Scenario supported: hover over link to get in context preview of resource
Simple resource format defined and retrieved using HTTP content negotiation
Hover over link
Small and large previews provided for. Hover “gesture” an implementation detail, i.e. you can activate/retrieve the preview whenever it makes sense. 50

51. OSLC specifications also include
Common property and resource definitions covering
Resource shapes
Resource typical properties: title, description, identification, …
Leveraging Dublin Core and FOAF
Discussion/comments
OSLC services MAY offer OAuth 1.0a
Three legged OAuth for webapp to webapp authentication
Two legged OAuth for client to webapp authentication
OSLC services MAY offer HTTP BASIC Auth
User name and password sent “in the clear” with Base64 encoding
Should be done via HTTPS only 51

52. OSLC Specifications Cover Many Domains
Core & Common
Core, Configuration Management, Reporting
Application Lifecycle Management (ALM)
Change Management, Quality Management, Requirements Management, Asset Management, Architecture Management, Automation
(Software) Project Management
Estimation and Reporting
Product Lifecycle Management (PLM)
ALM-PLM Interoperability
Integrated Service Management (ISM)
Performance Monitoring, Reconciliation
… and there is no reason for them not to cover more!
Contribute scenarios and propose new domain workgroups.

53. Get Connected with OSLC
Learn more at
Get started with your OSLC “Hello World!” with Eclipse Lyo and existing specs
Join the community and contribute scenarios
Jump in and create specifications that matter to you
Some stats
OSLC specifications are referenced online 1000s of times everyday
Eclipse Lyo assets are used by 100s of developers from around the world
Dozens of publically available tools can be integrated using OSLC today, including software from the top 4 ALM vendors (by revenue) and popular Open Source.
Participants from over 40 organizations have contributed to OSLC, and 100s of organizations are using and benefiting from OSLC.
Lead: demonstrate your leadership in your company and across the industry
Influence: affect the outcomes of the work groups by your input; affect your vendors’ evaluation of your request that they implement OSLC
Simplify: the software integrations you build and use
Open Services for Lifecycle Collaboration
Lifecycle integration inspired by the web

54. Resources OSLC Web Site OSLC Primer OSLC Tutorial
OSLC Primer
OSLC Tutorial
OSLC Core and Domain specifications
Eclipse Lyo
Even more OSLC resources 54

55. Backup

56. Need better integration approaches
Past integration approaches have provided limited choice and coverage.
Universal metadata standard
“How did I ever think all those vendors would be able to agree?”
Point-to-point integrations
“How can I ever upgrade one tool without breaking everything else?”
Standard implementations
“Did I really believe that every vendor would rewrite their tools on a single framework?”
Single repository
“Can I really expect one vendor to provide all the functionality I need? And what about my existing tools?”
Past integration approaches have been disruptive and slow to emerge.
In the past, integration approaches have also fallen short because of limited choice and coverage, the slowness for the integration approach to emerge, and the disruptiveness of adopting the integration approach. 56

57. Need open collaboration on solutions
Past collaborations have fallen short because of limited and restrictive participation.
Limited to small set of business partners
Point-to-point integrations
Built after the fact with limited product APIs
Solution focuses on two tools in hand
No open process for others to join in
Limits solution to particular use cases and technologies
Restrictive licenses and intellectual property
Solution design goals and approach
No consensus driven approach
No external review
No visibility into solution
Collaborations in the past have fallen short because of limited and restrictive participation.
Participation has been limited to small sets of business partners, and solutions ended up focusing on the few tools in hand. Many times, there’s no consensus to the approach, no external reviews, and the end result has restrictive licenses or license fees.
License fees
Fear of giving up IP
Forces alternative solutions 57

58. OSLC community Wide range of interests, expertise, participation
Vendors, end users, industry consortia
40+ organizations have had employees participate in specification development efforts
100s of developers have used assets from Lyo
Collaborating on solutions for ALM, DevOps, ISM, PLM
Growing list of implementations
Implementations from IBM Rational, Oracle, IBM Tivoli and open source
3rd party adapters from IBM, Kovair, Tasktop, and open source
Dozens of end users enabling homegrown tools
The OSLC community collaborates to manage all activity around OSLC. Participants provide a wide range of interests, expertise and participation. They have a growing list of OSLC implementations from IBM and other companies. They have completed specifications for many different domains.
Specifications for many domains
Change Management, Quality Management, Requirements Management, Asset Management, Architecture Management, Automation
Product Lifecycle Management, Configuration Management
Performance Monitoring, Reconciliation 58

59. OSLC website at http://open-services.net
The OSLC website at open-services.net is your one stop location for learning, adopting and participating in OSLC.
You’ll find tools, tutorials and references to help you adopt the specifications, you can browse the current specifications and see available software. You can catch up with what’s new in the community, and you can get involved in writing, reviewing and implementing specifications through the workgroups.
Register
Participate
Browse
Learn
Adopt 59