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

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: http://www.linkeddatatools.com/introducing-rdf http://3roundstones.com/linked-data-101/linked-data-tutorial/ After reading this presentation, you’ll gain an understanding of the OSLC community, of linked data concepts, and of the OSLC specification itself. 2

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

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.

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. http://open-services.net 5

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 http://open-services.net/wiki/communications/Why-should-you-care-about-OSLC/  OSLC is beneficial to many stakeholders

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

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:

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 http://eclipse.org/lyo

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

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

...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?

...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?

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.

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: http://open-services.net/bin/view/Main/ 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 http://www.w3.org/RDF/

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.

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: http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-data-model

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/

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

Examples of different OSLC notations <http://...Test Case 1> <http://...validates> <http://...Requirement 1> Subject Predicate Object <http://example.com/TestCases/1> a oslc_qm:TestCase ; oslc_qm:validatesRequirement <http://example.com/Requirements/1> Turtle { "rdf:about": "http:\/\/example.com\/TestCases\/1", "rdf:type": [ { "rdf:resource": "http:\/\/open-services.net\/ns\/qm#TestPlan" } ], "oslc_qm:validatesRequirement": { "rdf:resource": "http:\/\/example.com\/Requirements\/1" } 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="http://example.com/TestCases/1"> <oslc_qm:validatesRequirement rdf:resource="http://example.com/Requirements/1"/> </oslc_qm:TestCase> RDF/XML

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]

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

Let’s look at the requirements domain Requirement 28465 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

The same information as before, in tabular form Requirement Owner Priority Created on State Release Requirement 28464 Add rear FIDO mast Linda Low October 18, 2012 New Lunar Rover 3.1 Requirement 28465 Improve Remote Steering Bob High November 24, 2011 Implemented Requirement 28466 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

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

Let’s add more relationships validated by Test Case 35645: Test Steering release Requirement 28465 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

The same information as before, in tabular form Requirement Owner Priority Created on State Release Validated by Requirement 28464 Add rear FIDO mast Linda Low October 18, 2012 New Lunar Rover 3.1 Requirement 28465 Improve Remote Steering Bob High November 24, 2011 Implemented Test Case 35645: Test Steering Requirement 28466 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 35645 Test Steering Janet High Lunar Rover 3.1 Iris

RDF triple (subject-predicate-object) validated by Triple Requirement 28465 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)

RDF triple (subject-predicate-object) <http://...validatedby> Triple <http://...requirement28465_ improve_remote steering> <http://...testcase35645_test_steering> <http://...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) 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.

Let’s add more relationships Work Item 38759 implements Test Case 35645: Test Steering validated by release Requirement 28465 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

There is a web of URIs around a development effort <http://.../test case> <http://.../req> <http://.../workitem> <http://.../release> <http://.../bug> <http://.../change request> <http://.../build> <http://.../testresult> validate

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.

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

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 http://open-services.net/bin/view/Main/OslcCoreSpecification

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

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)

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 http://stevespeicher.blogspot.com/2011/03/determining-how-best-to-participate-in.html

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

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

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 http://bugs/123 GET http://bugs/123?oslc.properties=dcterms:title,oslc_cm:status 40

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

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

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

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) <http://example.com/bugs/2314> a oslc_cm:ChangeRequest ; dcterms:relation <http://server/app/bugs/1235> ; http://open-services.net/bin/view/Main/OslcCoreSpecAppendixLinks 44

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

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

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 http://example.com/bugs?oslc.where= cm:severity="high" and dcterms:created>"2010-04-01" http://example.com/bugs?oslc.prefix=qm= <http://qm.example.com/ns>& oslc.where=qm:testcase=<http://example.com/tests/31459> http://example.com/bugs?oslc.where= dcterms:creator{ foaf:givenName="John" and foaf:familyName="Smith"} 47

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

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

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

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

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.

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 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

Resources OSLC Web Site OSLC Primer OSLC Tutorial 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

Backup

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

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

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

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