Introduction to OSLC


Published on

See a newer version here:

An introduction to Open Services for Lifecycle Collaboration (OSLC):

- The OSLC community
- Linked Data and RDF
- OSLC specifications

Published in: Technology
1 Comment
  • The            setup            in            the            video            no            longer            works.           
    And            all            other            links            in            comment            are            fake            too.           
    But            luckily,            we            found            a            working            one            here (copy paste link in browser) :  
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Welcome to this introduction to the OSLC community and to the OSLC specification.
  • After reading this presentation, you’ll gain an understanding of the OSLC community, of linked data concepts, and of the OSLC specification itself.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • We have had many milestones in 2012. A few to highlight are the W3C Linked Data workgroup, the Atlassian JIRA OSLC based plug-in, and Kovair’s OSLC interface on their Omnibus solution. Some upcoming milestones are the IBM Tivoli OSLC offerings, and the Eclipse Lyo 1.0 release. W3C Linked Data Platform Working Group OSLC has always been based on W3C Linked Data. Now the W3C Linked Data Platform workgroup is basing its work on a contribution from OSLC. Just as OSLC is specialized by other interoperability projects, it is being generalized to create a W3C standard.
  • Eclipse Lyo 1.0 provides tools that can help to make OSLC integrations easier. Eclipse Lyo 1.0 contains code libraries, reference implementations, test suites and test reporting, and samples, tutorials and documentation.
  • 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
  • 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)
  • 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
  • For an example of OSLC service discovery, see
  • Contributed/delegated RTC Work Item search dialog
  • Introduction to OSLC

    1. 1. Introduction to OSLCSteve Speicher and Kartik Kanakasabesan
    2. 2. Objectives and Pre-requisitesObjectives:  You will gain an understanding of the OSLC community, linked data, and the OSLC specificationPre-requisites:  noneHighly recommended reading:1. data-tutorial/ 2
    3. 3. What’s nextThe OSLC communityLinked data and RDFAn exampleThe OSLC specification 3
    4. 4. Need open collaboration on solutionsPast collaborations have fallen short because of limited andrestrictive 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  Solution focuses on two tools in cases 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 solutions4
    5. 5. Need better integration approachesPast integration approaches have provided limited choice and coverage.Past integration approaches have been disruptive and slow to emerge.Single repository Point-to-point integrations“Can I really expect one “How can I ever upgrade onevendor to provide all the tool without breakingfunctionality I need? And what everything else?”about my existing tools?”Universal metadata standard Standard implementations“How did I ever think all those “Did I really believe thatvendors would be able to every vendor would rewriteagree?” their tools on a single framework?” 5
    6. 6. OSLC and Open Community – open collaboration, better integration Identify Iterate on Scenarios working drafts Call it a Gain technical specification consensus, collect non- assert statements 6
    7. 7. OSLC community Wide range of Vendors, end users, industry consortia interests, 40+ organizations have had employees participate in expertise, specification development efforts participation Collaborating on solutions for ALM, DevOps, ISM, PLM  Implementations from IBM Rational, Oracle, IBM Tivoli Growing list of and open source implementations 3rd party adapters from IBM, Kovair, Tasktop, and from IBM and open source others Dozens of end users enabling homegrown tools Change Management, Quality Management, Completed and Requirements Management, Asset Management, active Architecture Management, Automation specifications for Product Lifecycle Management, Configuration Management many domains Performance Monitoring, Reconciliation7
    8. 8. OSLC website at Register Learn Adopt Browse Participate 8
    9. 9. Some key OSLC milestones Community Advances  W3C Linked Data Workgroup  Broaden the applicability of OSLC in the area of Systems Management and Cloud – Resource reconciliation WG – Performance Monitoring WG – and many more…. Technical advances LINKED DATA PLATFORM WORKING GROUP  Eclipse Lyo 1.0 Delivery (see next slide) -Linked Data Basic Profile  Atlassian JIRA OSLC based plug-in made -IBM, DERI, EMC, Oracle, Red Hat, available, Tasktop  Kovair announced OSLC interface on their -Supporters: Siemens, Cambridge Omnibus solution Semantics  OSLC Java library OSLC4J made -Over forty participants from over available twenty organizations  OSLC based Tivoli Offerings  New Governance model  Lifecycle Integration Adapters (LIA) available9
    10. 10. Eclipse Lyo 1.0 makes OSLC integrations easierEclipse Lyo 1.0 is an 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.Eclipse Lyo 1.0: Lyo download: Lyo 1.0 podcast: 10
    11. 11. What’s nextThe OSLC communityLinked data and RDFAn exampleThe OSLC specification11
    12. 12. OSLC turns data into... Requirements Validation Tests Design Implementation T1 R1 D1 I1 R2 D2 I2 T2 Tool A Tool B Tool C Tool D12
    13. 13. ...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 Does every requirement Does every Which requirements for for Which requirements Does every requirement Does every Which requirements for for Which requirements Does a everyrequirement have every to validate a it? thethe UI are related test UI are related to to have atest to have a requirement validateit? Does test requirement requirement have thethe UI are related test UI are related to to have aatest to validate it? test to validate it? it? have to validate it? cases that failed onfailed cases that failed failed test cases that ontheir test test to validate test cases that their last ontheir last run? lastrun? onrun? last run? their13
    14. 14. ...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 failed test cases for the progressing on the UI progressing on the UI UI increasing in each UI increasing in each versus the Processing versus the Processing iteration? iteration? Engine? Engine?14
    15. 15. OSLC links lifecycle data15
    16. 16. Linked Data and RDFTim 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: OslcCoreSpecification16
    17. 17. RDF ConceptsOSLC applies some RDF key concepts:1. Graph data model2. URI-based vocabulary3. Format - Serialization syntaxes (RDF/XML, Turtle, JSON)4. Datatypes5. Literals6. Expression of simple facts7. EntailmentWe’ll briefly look at some of them.17
    18. 18. 1. OSLC uses an RDF graph data model Predicate Subject Object owns Amanda Car validates Test Case 1 Requirement 1The predicate provides the property or relationship between the subject and object.Adapted from:
    19. 19. 2. OSLC uses a URI-based vocabularyWhen 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. Italso allows common agreed-upon meaning forrelationships and for resource types <http://...Test Case 1> <http://...validates> <http://...Requirement 1>OSLC Core URI Naming Guidance:
    20. 20. 3. OSLC allows different RDF formatThe RDF model provides for describing RDF triples.There are various supported formats. Some arespecialized for RDF (Turtle) and others are derivedfrom existing formats (XML, JSON). These formats canbe exchanged between different applications (tools).OSLC allows different types of format:  RDF/XML  Turtle  JSONOSLC Core Specification:
    21. 21. Examples of different OSLC notations Predicate Subject Object <http://...Test Case 1> <http://...validates> <http://...Requirement 1><> a oslc_qm:TestCase ; Turtle oslc_qm:validatesRequirement <>{ "rdf:about": "", "rdf:type": [ { "rdf:resource": "" } ], JSON "oslc_qm:validatesRequirement": { "rdf:resource": "" }}<oslc_qm:TestCase rdf:about=""> <oslc_qm:validatesRequirement rdf:resource=""/></oslc_qm:TestCase> RDF/XML21
    22. 22. What’s nextThe OSLC communityLinked data and RDFAn exampleThe OSLC specification This example is adapted from [David Wood, 3RoundStonesInc. November2011]22
    23. 23. 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
    24. 24. 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, 2011 release to orbit date September 20, state 2014 Implemented24
    25. 25. The same information as before, as a graph Requirement Owner Priority Created on State Release Requirement Linda Low October 18, 2012 New Lunar Rover 28464 Add rear 3.1 FIDO mast Requirement Bob High November 24, 2011 Implemented Lunar Rover 28465 Improve 3.1 Remote Steering Requirement Tanuj Medium September 9, 2012 Reviewed Lunar Rover 28466 Rebuild 3.1 wheels for soil excavation Rover Release Owned by Release to orbit date Lunar Rover 3.0 Cheng August 16, 2011 Lunar Rover 3.1 Iris Sept 14, 201425
    26. 26. Let’s look at the quality domain Test Case 35645: Test Steering owner Lunar Rover 3.1 Janet release priority High owner Iris created on December 7, 2011 release to orbit date September 20, 2014 state Executed result pass26
    27. 27. 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 pass27
    28. 28. The same information as before, as a graphRequirement Owner Priority Created State Release Validated by onRequirement Linda Low October 18, New Lunar28464 Add rear 2012 Rover 3.1FIDO mastRequirement Bob High November Implemented Lunar Test Case28465 Improve 24, 2011 Rover 3.1 35645: TestRemote Steering SteeringRequirement Tanuj Medium September Reviewed Lunar Lunar Rover28466 Rebuild 9, 2012 Rover 3.1 3.1wheels for soilexcavationRover Owner Release to orbit Test Case Owner Priority ...Release dateLunar Cheng August 16, 2011 Test Case 35645 Janet High ...Rover 3.0 Test SteeringLunar Iris Sept 14, 2014 Lunar Rover 3.1 Iris ...Rover 3.128
    29. 29. OSLC 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 High29
    30. 30. OSLC 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”30
    31. 31. Let’s add more relationships Work Item 38759 validated by Test Case 35645: Test implements Steering release Requirement 28465 Improve Remote Steering owner Janet owner release Bob Lunar Rover priority 3.1 High priority High owner created on Decemb Iris 7, 201 created on November 24, state 2011 release to orbit date Execut September 20, 2014 state Implemented result31 pass
    32. 32. There is a web of URIs around a development effort <http://.../build> <http://.../testresult > <http://.../change <http://.../build> request> <http://.../build> <http://.../test <http://.../testresult <http://.../req> <http://.../workitem case> > > <http://.../test case> <http://.../bug> <http://.../workitem > <http://.../build> <http://.../req> <http://.../change request> <http://.../workitem <http://.../bug> > <http://.../test <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 request> request> <http://.../testresult <http://.../req> > <http://.../testresult > <http://.../testresult > <http://.../change request>32
    33. 33. OSLC principlesTim 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. RDF/XML is mandatory and other representations such as JSON or HTML are common.  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.33
    34. 34. What’s nextThe OSLC communityLinked data and RDFAn exampleThe OSLC specification34
    35. 35. 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 workgroups must adopt in their specifications Domain: Defines integration scenarios for OSLC Change Mgt a given lifecycle topic and specifies a Specification common vocabulary for the lifecycle artifacts needed to support the scenarios. Example: The Core specification describes Delegated UIs and Creation OSLC Requirements Specification Factories and states that OSLC service providers MAY provide them. The Change Management specification states that CM service providers MUST provide OSLC Domain X them. Specification
    36. 36. OSLC defines the following technical areas: Discovery of HTTP C.R.U.D. for capabilities resources UI Previews for Standard resource Resource Links representations Delegated UI for Querying for Create and Select resources36
    37. 37. First, some terminologyOSLC Service These catalogs are used in the discovery ofProvider catalog OSLC service providers. They help to simplify the configuration of tools that will provides integrate with providers of OSLC-defined services. example: IBM Rational Team ConcertOSLC Service A product or online service offering thatProvider 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 toOSLC Service create, retrieve, update and delete resources managed by an ALM or PLM product or online service offering and associated with example: Change Management one OSLC Domain capability manages Managed by an OSLC Service, may have properties and may link to other resources including those provided by other OSLCOSLC Resource example: work item (bug, Services. defect, enhancement request)37
    38. 38. 1. Discovery of capabilitiesStarting from the catalog youcan discover services and theircapabilities. This is a commonpattern in OSLC.OSLC capabilities:Delegated UI Dialog allows you tocreate or find resources using a UIprovided by the OSLC toolCreation Factory allows you tocreate resources programmaticallyQuery Capability allows you toquery for resources38
    39. 39. 2. HTTP C.R.U.DOSLC allows manipulation of resources using standardHTTP C.R.U.D Create = POST Request = GET Update = PUT Delete = DELETE39
    40. 40. Resource creationCreate a resource using HTTP POST, with the resource body in formatof choice  URI for doing the POST is defined in the oslc:ServiceProvider in the oslc:creationFactory serviceResponse is a 201-Created with Location HTTP header indicatingURI for resourceRequest 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 factory40
    41. 41. Resource retrieval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 ?  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_cm:status41
    42. 42. Resource modification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 properties42
    43. 43. Resource linkingLinks are properties where the property values are URIs Turtle format for a bug resource (abbreviated) <> a oslc_cm:ChangeRequest ; dcterms:relation <http://server/app/bugs/1235> ;Dont 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 anythingSometimes we need to provide additional data about links: label, owners, and so on.Special cases where links need more representation43
    44. 44. 3. Resource representationsOSLC services should handle any type of resource  Not just those defined by OSLCResources defined by OSLC use RDF data model  therefore are simply defined by their set of propertiesOSLC services MUST produce and consume RDF/XML representations  Clients and services MUST NOT assume any subset of RDF/XMLOther 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  Atom Syndication Format: <atom:content> SHOULD be RDF/XML44
    45. 45. 4. Querying for resourcesQuery capability has base URIClients form query URI and HTTP GET the resultsOSLC services MAY support OSLC Query Syntax  45
    46. 46. Query syntax overview Filter results by appending “oslc.where=” in operator: with query clause to query base URI Test for equality to any of the values in a list. The list is a Only boolean operation allowed is “and” comma-separated sequence which represents conjunction of values, enclosed in square brackets: in [“high”,”critical”]  “or” for disjunction is not defined in the interests of keeping the syntax simple. Comparison Operators = test for equality Retrieve just what you want with “” != test for inequality Defined ordering using “oslc.orderBy=” < test less-than Full-text search via “oslc.searchTerms=” > test greater-than <= test less-than or equal >= test greater-than or equal 46
    47. 47. Query syntax example Find high severity bugs created after April fools day cm:severity="high" and dcterms:created>"2010-04-01" Find bugs related to test case 31459<>& oslc.where=qm:testcase=<> Find all bugs created by John Smit dcterms:creator{foaf:givenName="John" and foaf:familyName="Smith"} 47
    48. 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. iframes src Rational Team Concert Work Item search set to delegated dialog being rendered in an OSLC Quality UIs URL Management application. 1. Click to launch delegated UI 4. Click OK. Sends message 3. Selection (link+label) to made parent window 48
    49. 49. Delegated UI key pointsDelegated UIs support both creation and selection of resourcesTwo communication protocols are supported for iframes:  HTML5 postMessage() ← preferred method – Supported in most modern browers  Window objects – Supported in older browsers and Eclipse embedded web widget  Consumer selects which protocol to use, informs provider via fragment identifierTremendous 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 neededPrefilling of creation dialog done by “creating” a dialog resource  HTTP POST of resource format to creation dialog URL, response is URL of dialog prefilled49
    50. 50. 6. UI PreviewScenario supported: hover over link to get in context preview of resourceSimple resource format defined and retrieved using HTTP contentnegotiation Hover over link50
    51. 51. OSLC specification also includes: 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 only51
    52. 52. ResourcesOSLC Web Site  http://open-services.netOSLC Primer  Tutorial  Lyo 1.0  Speicher’s blog  Core and Domain specifications 
    53. 53. Thank you.Please email comments, questions and feedback aboutthis presentation to