The DevOps paradigm - the evolution of IT professionals and opensource toolkit
Introduction to OSLC and Linked Data
1. An Introduction to OSLC and Linked Data
OSLC: Lifecycle integration inspired by the web
2. Objectives and Pre-requisites
Objectives:
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:
1. http://www.linkeddatatools.com/introducing-rdf
2. http://3roundstones.com/linked-data-101/linked-data-tu
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
Monocultures Maintenance, management,
Integrations
lock you in and change costs go up over time
don’t scale
Ongoing and unexpected
costs drain resources
End-user productivity suffers:
End-user productivity suffers:
Either stuck with the wrong tool,
Either stuck with the wrong tool,
stuck doing manual integration;
stuck doing manual integration;
often stuck doing both
often stuck doing both
Creating new Past choices
integrations is restrict present Integrations consume more of the IT budget:
Integrations consume more of the IT budget:
unpredictable action and integration failures are the top 2 causes
integration failures are the top 2 causes
future vision of software project delays*
of software project delays*
More limited ability to respond to change
More limited ability to respond to change
Constrained by exhausted IT budget and lower productivity
Constrained by exhausted IT budget and lower productivity * Commissioned study conducted by
Forrester Consulting on behalf of IBM.
4
5. OSLC and Open Community: open collaboration, better integration
Identify Iterate on
Scenarios working
drafts
Call it a Gain technical
specification consensus,
http://open-services.net
5
6. The Basics: What is OSLC, and why should I care?
OSLC is an open community building practical
specifications for integrating software
OSLC is beneficial to many stakeholders
6
7. OSLC’s Simple Solution
Users can work seamlessly across their tools
Architecture of the Web Standard Interfaces
Automation
Linked Data “Just Enough” integration
Increased reuse Increased traceability
Monitoring
Decreased maintenance costs Better visibility
OSLC is an open and scalable approach to lifecycle integration.
It simplifies key integration scenarios across heterogeneous tools
7
8. OSLC’s Big Picture
Tests, Libraries, Samples, Examples,
The Resource Reference Implementations
for OSLC
Implementers
FFuu
ut tu
rr
OSLL eeHoome
OS C H me o
CSpp
S eec off
c De
Dev
v
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 Generally applicable: specs available for many
domains covering ALM, DevOps, ISM, and PLM
Inspired by the web Free to use and share Changing the industry
OSLC: Proven Open Innovative
8
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.
http://eclipse.org/lyo
9
10. What’s next
The OSLC community
Linked data and RDF
An example
The OSLC specifications
10
11. OSLC turns data into...
Requirements Validation Tests Design Implementation
T1
R1 D1 I1
R2 D2 I2
T2
Tool A Tool B Tool C Tool D
11
12. ...connected information...
Requirements Validation Tests Design Implementation
T1
validates validates
R1 D1 I1
satisfy implements
satisfy implements
R2 D2 I2
validates
validates
T2
Tool A Tool B Tool C Tool D
Which requirements for
Which requirements for
Does every requirement
Does every requirement the UI are related to test
the UI are related to test
have aatest to validate it?
have test to validate it? cases that failed on their
cases that failed on their
last run?
last run?
12
13. ...that can facilitate applied knowledge
Requirements Validation Tests Design Implementation
User Interface
T1
validates validates
R1 D1 I1
satisfy implements
Release
satisfy implements
R2 D2 I2
validates
validates
T2 Processing Engine
Tool A Tool B Tool C Tool D
Why is the number of
Why is the number of How much faster is work
How much faster is work
failed test cases for the UI
failed test cases for the UI progressing on the UI
progressing on the UI
increasing in each
increasing in each versus the Processing
versus the Processing
iteration?
iteration? Engine?
Engine?
13
15. Linked Data and RDF
Tim Berners-Lee’s four principles for linking data:
1. Use URIs as names for things
2. Use HTTP URIs so that people can look up those names
3. When someone looks up a URI, provide useful information
using the standards (RDF, SPARQL)
4. 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: http://open-services.net/bin/view/Main/ OslcCoreSpecification
15
16. RDF Concepts
OSLC applies some RDF key concepts:
1. Graph data model
2. URI-based vocabulary
3. Format - Serialization syntaxes (RDF/XML, Turtle,
JSON)
4. Datatypes
5. Literals
6. Expression of simple facts
7. Entailment
We’ll briefly look at some of them.
16
17. 1. OSLC uses an RDF graph data model
Predicate
Subject Object
owns
Amanda Car
validates
Test Case 1 Requirement 1
The predicate provides the property or relationship
between the subject and object.
Adapted from:
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-data-model
17
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
<http://...Test Case 1> <http://...validates> <http://...Requirement 1>
OSLC Core URI Naming Guidance:
http://open-services.net/wiki/core/OSLC-Core-URI-Naming-Guidance/
18
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:
http://open-services.net/bin/view/Main/OslcCoreSpecification
19
21. What’s next
The OSLC community
Linked data and RDF
An example
The OSLC specifications
This example is adapted from http://3roundstones.com/linked-
data-101/linked-data-tutorial/ [David Wood, 3RoundStonesInc.
November2011]
21
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
22
23. Let’s look at the requirements domain
Requirement 28465 Improve Remote
Steering
owner release Lunar Rover 3.1
Bob
priority
High
owned by
Iris
created on
November 24,
release to
2011
orbit date
September 20,
state 2014
Implemented
23
24. The same information as before, in tabular form
Requirement Owner Priority Created on State Release
Requirement 28464 Linda Low October 18, New Lunar Rover
Add rear FIDO mast 2012 3.1
Requirement 28465 Bob High November 24, Implemented Lunar Rover
Improve Remote 2011 3.1
Steering
Requirement 28466 Tanuj Medium September 9, Reviewed Lunar Rover
Rebuild wheels for soil 2012 3.1
excavation
Rover Release Owned by Release to orbit
date
Lunar Rover 3.0 Cheng August 16, 2011
Lunar Rover 3.1 Iris Sept 14, 2014
24
25. Let’s look at the quality domain
Test Case 35645: Test Steering
owner release Lunar Rover 3.1
Janet
priority
High
owned by
Iris
created on
December 7, release to
2011 orbit date
September 20,
state 2014
Executed
result
pass
25
26. Let’s add more relationships
validated by
Test Case 35645: Test
Steering
release
Requirement 28465
Improve Remote Steering
owner
Janet
release Lunar Rover
owner
Bob 3.1 priority
High
priority
High created on
owner December
Iris 7, 2011
created on
November 24,
2011 state
release to Executed
orbit date September
20, 2014
state
Implemented
result pass
26
27. The same information as before, in tabular form
Requirement Owner Priority Created State Release Validated by
on
Requirement Linda Low October 18, New Lunar
28464 Add rear 2012 Rover 3.1
FIDO mast
Requirement Bob High November Implemented Lunar Test Case
28465 Improve 24, 2011 Rover 3.1 35645: Test
Remote Steering Steering
Requirement Tanuj Medium September Reviewed Lunar Lunar Rover 3.1
28466 Rebuild 9, 2012 Rover 3.1
wheels for soil
excavation
Rover Owner Release to Test Case Owner Priority ...
Release orbit date
Lunar Cheng August 16, 2011 Test Case 35645 Janet High ...
Rover 3.0 Test Steering
Lunar Iris Sept 14, 2014 Lunar Rover 3.1 Iris ...
Rover 3.1
27
28. RDF triple (subject-predicate-object)
Triple
Subject = Resource Predicate = Object = Could be a
= always a URI Relationship or URI (which could refer
property = Always a to a resource) or a
URI literal value (value to
work with and show
users)
Requirement validated by Test Case
28465 Improve 35645: Test
Remote Steering Steering
priority
High
28
29. RDF triple (subject-predicate-object)
Triple
Subject = Resource Predicate = Object = Could be a
= always a URI Relationship or URI (which could refer
property = Always a to a resource) or a
URI literal value (value to
work with and show
users)
<http://...require <http://...validatedby> <http://...testcas
ment28465_ e35645_test_ste
improve_remote ering>
steering>
<http://...priority>
“High”
29
30. Let’s add more relationships
Work Item
38759
implements validated by Test Case 35645: Test
Steering
release
Requirement 28465
Improve Remote Steering
owner
Janet
owner release
Bob Lunar Rover 3.1 priority
High
priority
High owner created on
December
Iris
7, 2011
created on
November 24, state
2011 release to
orbit date Executed
September
20, 2014
state
Implemented result
pass
30
31. There is a web of URIs around a development effort
<http://.../build>
<http://.../testresult
> <http://.../change
<http://.../build>
request>
<http://.../build>
<http://.../test <http://.../workitem <http://.../testresult
<http://.../req> case> >
>
<http://.../test
case>
<http://.../bug>
<http://.../workitem
>
<http://.../build> <http://.../req> <http://.../change
request>
<http://.../workitem
<http://.../test <http://.../bug> >
<http://.../release> <http://.../req>
case>
<http://.../build>
<http://.../bug>
validate
<http://.../build>
<http://.../workitem <http://.../test
<http://.../req> > case>
<http://.../workitem <http://.../build>
<http://.../change <http://.../test >
request> case>
<http://.../change <http://.../change
<http://.../req> request> request> <http://.../testresult
>
<http://.../testresult
>
<http://.../testresult
>
<http://.../change
request>
31
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.
32
33. What’s next
The OSLC community
Linked data and RDF
An example
The OSLC specifications
33
34. Anatomy of a specification
Core: Specifies the primary integration
OSLC Core Specification techniques for integrating lifecycle tools
– the standard rules and patterns for
using HTTP and RDF that all the domain
How workgroups must adopt in their
specifications
Domain: Defines integration scenarios
OSLC Change Mgt for a given lifecycle topic and specifies a
Specification
common vocabulary for the lifecycle
artifacts needed to support the
scenarios.
OSLC Requirements Example: The Core specification
Specification describes Delegated UIs and Creation
Factories and states that OSLC service
providers MAY provide them. The
Change Management specification
OSLC Domain X states that CM service providers MUST
Specification provide them.
http://open-services.net/bin/view/Main/OslcCoreSpecification
34
35. OSLC defines the following technical areas:
1. Discovery of 2. HTTP C.R.U.D. for
capabilities resources
6. UI Previews for 3. Standard resource
Resource Links representations
5. Delegated UI for 4. Querying for
Create and Select resources
35
36. First, some terminology (before we get to #1)
OSLC Service These catalogs are used in the discovery of
Provider catalog OSLC service providers. They help to simplify
the configuration of tools that will integrate
provides with providers of OSLC-defined services.
example: IBM Rational Team
Concert
OSLC Service A product or online service offering that
Provider provides an implementation of one or more
OSLC Services, which may themselves
provides an implement different OSLC Domain example: IBM Rational Team
implementation of specifications Concert project area
Set of capabilities that enable a web client to
OSLC Service create, retrieve, update and delete resources
managed by an ALM or PLM product or online
service offering and associated with one example: Change Management
OSLC Domain capability
manages
Managed by an OSLC Service, may have
properties and may link to other resources
including those provided by other OSLC
OSLC Resource example: work item (bug,
Services.
defect, enhancement request)
36
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
37
38. 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
38
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
Accept: application/json, application/xml
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 http://bugs/123
Get Defect 123 (just title and status)
GET http://bugs/123?oslc.properties=dcterms:title,oslc_cm:status
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
http://tools.ietf.org/html/rfc5789
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
42
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
Turtle format for a bug resource (abbreviated)
<http://example.com/bugs/2314>
a oslc_cm:ChangeRequest ;
dcterms:relation
<http://server/app/bugs/1235> ;
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
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
http://open-services.net/bin/view/Main/OSLCCoreSpecQuery
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
'in' operator:
< test less-than
Test for equality to any of the
values in a list. The list is a > test greater-than
comma-separated sequence <= test less-than or equal
of values, enclosed in square >= test greater-than or equal
brackets: in [“high”,”critical”]
46
47. Query syntax example
Find high severity bugs created after April fools day
http://example.com/bugs?oslc.where=
cm:severity="high" and dcterms:created>"2010-04-01"
Find bugs related to test case 31459
http://example.com/bugs?oslc.prefix=qm=
<http://qm.example.com/ns>&
oslc.where=qm:testcase=<http://example.com/tests/31459>
Find all bugs created by John Smith
http://example.com/bugs?oslc.where=
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 2. iframe's src
Rational Team Concert Work Item search set to delegated
dialog being rendered in an OSLC Quality UI's URL
Management application.
1. Click to
launch
delegated UI
4. Click OK.
Sends message 3. Selection
(link+label) to made
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
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
53. Get Connected with OSLC
Learn more at
http://open-services.net
http://eclipse.org/lyo
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
Open Services for Lifecycle Collaboration
Lifecycle integration inspired by the web
53
54. Resources
OSLC Web Site
http://open-services.net
OSLC Primer
http://open-services.net/primer
OSLC Tutorial
http://open-services.net/tutorial
OSLC Core and Domain specifications
http://open-services.net/specifications/
Eclipse Lyo
http://www.eclipse.org/lyo/
Even more OSLC resources
http://open-services.net/resources/
54
56. Need better integration approaches
Past integration approaches have provided limited choice and coverage.
Single repository Point-to-point integrations
“Can I really expect one vendor “How can I ever upgrade one
to provide all the functionality I tool without breaking
need? And what about my everything else?”
existing tools?”
Past integration approaches have been disruptive and slow to emerge.
Universal metadata standard Standard implementations
“How did I ever think all those “Did I really believe that every
vendors would be able to vendor would rewrite their
agree?” tools on a single framework?”
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
No open process for others to join in
product APIs
Limits solution to particular use cases
Solution focuses on two tools in
and technologies
hand
Solution design goals and approach Restrictive licenses and intellectual property
No consensus driven approach
License fees
No external review
Fear of giving up IP
No visibility into solution
Forces alternative solutions
57
58. OSLC community
Vendors, end users, industry consortia
Wide range of
40+ organizations have had employees participate in
interests, specification development efforts
expertise, 100s of developers have used assets from Lyo
participation Collaborating on solutions for ALM, DevOps, ISM, PLM
Implementations from IBM Rational, Oracle, IBM Tivoli
and open source
Growing list of 3rd party adapters from IBM, Kovair, Tasktop, and open
implementations source
Dozens of end users enabling homegrown tools
Change Management, Quality Management,
Requirements Management, Asset Management,
Specifications for Architecture Management, Automation
many domains Product Lifecycle Management, Configuration
Management
Performance Monitoring, Reconciliation
58
After reading this presentation, you’ll gain an understanding of the OSLC community, of linked data concepts, and of the OSLC specification itself.
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 t raditional 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! For IBM: 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 3 rd -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.
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.
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)
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 c currently 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 1 st 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
- 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
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.
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.
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 http://www.w3.org/RDF/
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.
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).
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)
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.
The Work Item is from the Change Management domain.
Now let’s look at how Tim Berners-Lee’s four principles apply to OSLC.
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
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
RTC project area maps to
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 http://stevespeicher.blogspot.com/2011/03/determining-how-best-to-participate-in.html
Small and large previews provided for. Hover “gesture” an implementation detail, i.e. you can activate/retrieve the preview whenever it makes sense.
… and there is no reason for them not to cover more! Contribute scenarios and propose new domain workgroups.
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
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.
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.
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.
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.