1. Open Services
(OSLC) and Jazz:
Working Together
Dave Johnson
Web 2.0 Architect, IBM Rational
dmjohnso@us.ibm.com
John Wiegand
Chief Architect, IBM Rational
John_Wiegand@us.ibm.com
ALM-2210B
The premiere software and product delivery event.
June 6–10 Orlando, Florida
Monday, July 18, 2011

2. Agenda
The need for OSLC
OSLC community approach
OSLC status & successes
OSLC technical approach
Jazz and OSLC
2 2
2
Monday, July 18, 2011

3. Software/product development tool landscape
3
3
Monday, July 18, 2011

4. Software/product development tool landscape
4
4
Monday, July 18, 2011

5. Traditional Tool Integration. Ouch.
 N2 possible point-to-point connections
 Limited coverage
 Closed APIs
 Vendor lock-in
 Tight Coupling
 Dependence on internal structures
 Lockstep upgrades
 Version incompatibilities
3
Monday, July 18, 2011

6. Data Integration - the old way
Traceability links Model concepts
Payment Pay Settlement Payment Cash Payment
service service service service service service
Software &
Require- Bus Proc
Ent Arch Solution Development Test
ments Model
Architecture
Payment Pay Settlement Payment Cash Payment
process process process process process process
10
Monday, July 18, 2011

7. The Business Costs of Traditional Approaches
 For tools users  For tools vendors
 Inconsistent connectivity  Limited connections = limited value
 Reduced choice  Time wasted in negotiations
 Hindrances to timely upgrades  Disputes over responsibility for bridge code
 For Integrators and Consultants
 Lack of skills transfer between projects  For Open Source projects
 Ramp-up on each new project  Lack of focus on building integrations
 Difficulty participating in commercial partnership
programs
4
Monday, July 18, 2011

8. The Potential of a Better Approach
 Good for our business
Stable interfaces to overlapping products
Dramatically reduce integration, support,
maintenance costs
Improve time-to-market
 Good for our customers
Freedom of choice
Flexibility of incremental adoption Current Course
Improved productivity
Pre-Standards
 Good for our Industry  Common standards promote interoperability
Integration M/W Revenue
 Business value of every offering rises
Interoperability
increases the value of every
offering
Spark innovation around the edges
Enable new business opportunities
 Fragmented standards maintain lock-in
Grow the whole pie  Business value limited
2004 2008 2012
5
Monday, July 18, 2011

9. The Internet – an inspiration for an architecture
 Amazingly scalable
 Integrates information on a massive scale
 Infinitely extensible
 Collaboration on unprecedented scale
 Open
 World-wide information visibility
 Unprecedented business opportunities
9
Monday, July 18, 2011

10. Data Integration – the new way – “WWW linked data”
http://acme.com/paymentProcess http://acme.com/paymentService
about about about
about
HTTP/REST
Software &
Enterprise Require- Bus Proc
Solution Development Test
Architecture ments Model
Architecture
13
Monday, July 18, 2011

11. Disentangling your data via OSLC
11
11
Monday, July 18, 2011

12. Open Services for Lifecycle Collaboration
An initiative aimed at simplifying tool integration across the product delivery lifecycle
Open Services for
Lifecycle Collaboration
 Community Driven – specified at open-
services.net
Barriers to sharing resources
and assets across the software  Specifications for ALM and PLM Interoperability
lifecycle
Multiple vendors, open source  Inspired by Internet architecture
projects and in-house tools  Loosely coupled integration with “just enough”
Private vocabularies, formats and standardization
stores  Common resource formats and services
Entanglement of tools with their
data  A different approach to industry-wide
proliferation
6
Monday, July 18, 2011

13. Open Services for Lifecycle Collaboration
An initiative aimed at simplifying tool integration across the product delivery lifecycle
Open Services for
Lifecycle Collaboration
 Community Driven – specified at open-
services.net
Barriers to sharing resources
and assets across the software  Specifications for ALM and PLM Interoperability
lifecycle
Multiple vendors, open source  Inspired by Internet architecture
projects and in-house tools  Loosely coupled integration with “just enough”
Private vocabularies, formats and standardization
stores  Common resource formats and services
Entanglement of tools with their
data  A different approach to industry-wide
proliferation
6
Monday, July 18, 2011

14. Agenda
The need for OSLC
OSLC status & successes
OSLC community approach
OSLC technical approach
Jazz and OSLC
2 13
13
Monday, July 18, 2011

15. Open Services for Lifecycle Collaboration
Community specifications for lifecycle integration
Suppose tools exposed their data in a
consistent way?
 Industry initiative proposed by IBM in
June 2008 based on things learned
from Jazz. Became operational in Dec
2008.
 Open community of individuals
interested in improving lifecycle
integration. Goals:
1. Make life better for software and product
delivery teams by easing the way tools can
be used in combination
2. Reduce the complexity and cost for tool
providers in integrating tools together
3. Open up new possibilities in the marketplace
by opening up the way lifecycle tools and
data can be used in ALM, PLM and outside
 Creating open, public specifications
that describe resources and interfaces
for sharing the things that software and
product delivery teams rely on.
22
Monday, July 18, 2011

16. Agile Specification Writing: Oxymoronic?
 Minimalist/additive approach
 Not a “complete” definition for a given area
 Scenario driven scope
 Co-evolve spec and implementations
 Open participation, but active core group
(topic lead is driver)
Iterate on
Identify
working drafts
Scenarios
Gain technical
Call it a consensus,
spec collect non-
assert
statements
15
Monday, July 18, 2011

17. Agile Specification Writing: Oxymoronic?
 Minimalist/additive approach
 Not a “complete” definition for a given area
 Scenario driven scope
 Co-evolve spec and implementations
 Open participation, but active core group
(topic lead is driver)
Iterate on
Identify
working drafts
Scenarios
Gain technical
Call it a consensus,
spec collect non-
assert
statements
15
Monday, July 18, 2011

18. What does it mean to participate in a workgroup?
 Workgroup phases (time-boxed to 4-6 month cycles)
 Scenarios and scope
 Spec authoring
 Convergence (polish and IP)
 Done!
 Ways to contribute
 Authoring/reviewing integration scenarios, helping to decide the scope for a spec iteration.
 Authoring/reviewing the technical specifications for resources and services needed to support the
scenarios.
 Implementing the services -- either as a service provider or a service consumer -- to validate the spec and
to achieve the desired integrations
 Operationally
 Open-services.net wiki and mailing lists
 Twice-a-month 1 hour workgroup meetings – telecon and web conferencing
 Off-line work activities
 Legal/IP
 Terms of participation documented on http://open-services.net/html/Terms.html
 Contributions
− Scenarios and specifications – Creative Commons copyright license
− Patent non-assert, for things necessary to implement the spec
25
Monday, July 18, 2011

19. Agenda
The need for OSLC
OSLC community approach
OSLC status & successes
OSLC technical approach
Jazz and OSLC
2 17
17
Monday, July 18, 2011

20. OSLC by the numbers Accenture
APG
Lender Processing Services
Northrop Grumman
BigLever Oracle
Black Duck QSM
Boeing Rally Software
BSD Group Ravenflow
Citigroup Shell
EADS Siemens
 11 active work groups Emphasys Group
Ericsson
Sogeti
SourceGear/Teamprise
Fokus Fraunhofer State Street
Galorath Tasktop (Eclipse Mylyn)
General Motors Tieto
 30 companies represented Health Care Services Corp
IBM
TOPIC Embedded Systems
UrbanCode
Institut TELECOM WebLayers
Integrate Systems
 280 registered community members
 4 finalized version 1.0 specifications
 4 version 2.0 specifications in progress
 1 new Core specification finalizing May 26, 2010
18
18
Monday, July 18, 2011

21. Status across the eleven OSLC workgroups
19
19
Monday, July 18, 2011

22. Agenda
The need for OSLC
OSLC community approach
OSLC status & successes
OSLC technical approach
Jazz and OSLC
2 20
20
Monday, July 18, 2011

23. Architectural Assumptions
 You cannot get all the data in a single database/repository
But you do have to cross-link all the data wherever it is
And you have to be able to query the data wherever it is
 You cannot design a Grand Unifying data model
Individual teams customize
Communities can’t agree
 Frameworks are a two-edged sword. Powerful for some, but ….
Constrain language and execution environments
Barrier to adoption
Difficult to mature and evolve
Tend to tightly couple components
 Customers demand choice
Monday, July 18, 2011

24. Integration Must Avoid Premature Restrictions
Traditional tool-to-tool integrations Aggregation of disparate data sources Process automation
 Replace n² point-to-point integrations with n  Individual sources can be local, in the cloud,  Enables creation of custom workflows and
interfaces or any combination automated processes
 Reduce version-specific brittleness  Supports both consolidated data warehouse  Individual tools/services can be local or in
 Eliminate dependency on vendor-to-vendor or “reference in place” models the cloud
cooperation  Enables customers to use their choice of  Customers can freely choose workflow
 Ideal for tools that need to integrate widely, portal or console, including vendor products, engines and process monitoring consoles
e.g. build mgmt; policy and quality inspection; open-source, or home-brew solutions
project mgmt and status
Insight: Integration is about connecting unlike tools, not exchanging data between like tools
OSLC philosophy: understand usage scenarios to drive data formats, not vice versa
8
Monday, July 18, 2011

25. Technical approach
 Build on the architecture of the WWW and REST
 Focus on resources, uniform interface of HTTP and stable/opaque URIs
 Build on the simple/powerful Resource Description Framework (RDF) data model
 Define resources and the properties allowed and required for each
 Balance tension between consistency & flexibility
 Want consistency but not at the cost of innovation
 Keep it simple
 Minimize new concepts introduced & specifications referenced
 Please wide variety of consumers
 Provide JSON, XML, Atom and other representations
23
23
Monday, July 18, 2011

26. The OSLC Core Specification - motivation
 In the first year of OSLC we saw workgroups do some redundant work
 Specifying how HTTP operations work for each type of resource
 Specifying the details of how to create XML, JSON and Atom representations
 Specifications were similar, but inconsistent in small ways
OSLC OSLC OSLC
OSLC domain spec domain spec OSLC domain spec
domain spec domain spec
OSLC
OSLC Domain spec domain spec
Domain spec OSLC Domain spec
domain
Domain spec spec OSLC Domain spec domain spec
RESTful protocol Domain spec
RESTful protocol domain spec RESTful protocol
Domain spec
RESTful protocol RESTful protocol Domain spec
Representations
RESTful protocol
Representations Domain spec Representations
Representations
RESTful protocol Representations RESTful protocol
Representations RESTful protocol
Representations Representations
Representations
24
24
Monday, July 18, 2011

27. OSLC Core Specification - approach OSLC
Core spec
 To keep the domain specifications consistent
RESTful protocol
 And to maintain the architectural integrity
 We developed the OSLC Core Specification Representations
 Specifies how to describe and represent resources
 Domain specification extend the Core
 Focus on domain-specific issues OSLC
domain spec OSLC
 Defining resources domain spec
 Specifying operations Domain spec
 Specifying which parts of Core are required OSLC Domain spec
domain spec
OSLC OSLC OSLC Domain spec
OSLC
domain spec domain spec domain spec domain spec
OSLC OSLC
Domain spec
domain spec Domain spec
domain spec
Domain spec Domain spec
Domain spec Domain spec
2
25
Monday, July 18, 2011

28. The OSLC Core Specification
 How to define an OSLC resource (in a specification)
 Name, namespace and allowed / required properties
 How to define an OSLC resource (in a machine readable form)
 In the form of a Resource Shape resource
 How to operate on OSLC resources via HTTP
 For resource create, retrieve, update and delete
 How to represent OSLC resources in RDF/XML, JSON, Atom and Turtle
 Rules for generating representations
 How to offer a Query Capability
 And specifies a Query Syntax
 How to offer services to clients
 Via a Service Provider resource
 How to offer Delegated UI
 See next slide
 Core specification defines the HOW, domain specifications define the WHAT
26
26
Monday, July 18, 2011

29. Delegated UI Dialogs - motivation
 Core specification defines a way for one OSLC service to embed a part of another
OSLC Service’s user interface (UI)
 This is important for resource creation because sometimes:
 Requirements for resource creation are too complex to express in a schema
 The easiest or best way to create a resource in Service A is via Service A’s UI
 And for resource selection because in some cases:
 Selecting a resource from an OSLC Service is difficult via REST API
 The easiest or best way to select a resource in Service A is via Service A’s UI
27
27
Monday, July 18, 2011

30. OSLC Core spec vs Domain specs
Core spec Domain specs
defines the how define the what
OSLC Core Specification OSLC Domain Specification
How to define OSLC resources Defines OSLC Resources
How to offer services Offers services
How to inform clients of resource shapes May offer resource shapes
How to offer delegated UIs May offer delegated UIs
How to offer query capabilities
May offer query capabilities
How to offer resource creation
What authentication is allowed May offer resource creation
How specification versioning works Provides examples of representations
How to represent OSLC defined resources
28
28
Monday, July 18, 2011

31. Delegated UI Dialogs
For resource creation and selection
The UI Consumer The UI Provider
1
A examines B’s Service Provider
resource to determine the URIs of any
Delegated UIs offered by B
OSLC Web Browser OSLC
Service Provider A’s
Web UI
Service B informs A Service
of user
Provider A 4 response Provider B
<iframe>
Service Provider B
Delegated UI
</iframe>
2 A embeds a Delegated UI from B 3 Delegated UI from B allows user to
in its web UI via an <iframe> perform creation or selection
29
29
Monday, July 18, 2011

32. Delegated UI Dialogs
For resource creation and selection
The UI Consumer The UI Provider
1
A examines B’s Service Provider
resource to determine the URIs of any
Delegated UIs offered by B
OSLC Web Browser OSLC
Service Provider A’s
Web UI
Service B informs A Service
of user
Provider A 4 response Provider B
<iframe>
Service Provider B
Delegated UI
</iframe>
2 A embeds a Delegated UI from B 3 Delegated UI from B allows user to
in its web UI via an <iframe> perform creation or selection
29
29
Monday, July 18, 2011

33. What Makes the OSLC Approach Better?
Traditional Approach OSLC Approach
 Brittle integrations, version-specific APIs  Loosely-coupled
 Monolithic repository or import/export  URLs
 “Boil the ocean” meta-model design  Minimalist
 Forced migration to a common code base  Technology-neutral
 Premature architectural decisions  Incremental
 A vendor-led “partners” program  Open
7
Monday, July 18, 2011

34. Agenda
The need for OSLC
OSLC community approach
OSLC status & successes
OSLC technical approach
Jazz and OSLC
2 31
31
Monday, July 18, 2011

35. Further detangling – Building with Jazz
 The Jazz Integration Architecture enables tools to go beyond OSLC
 Tools can discover additional capabilities beyond the core OSLC specs
 Advanced query, Process enactment, customization details
 The Jazz Foundation provides services which can be used to extend tools which
may be closed
 Jazz Storage Service for additional data about tool resources, such as traceability links
between two un-integrated tools
 Jazz Query Service and Text Search service for query and search across resources
 Jazz Dashboards can mash-up new and existing content into a powerful overview
 Common Jazz Team Server can address TCO and deployment issues
 One answer for authentication, identity, scaling, deployment, admin, licensing
Monday, July 18, 2011

36. Driving integrations through C/ALM scenario
Monday, July 18, 2011

37. Jazz: An Architecture for Application Integration
 Jazz tools implement the Open Services for
Life-cycle Collaboration (OSLC)
specifications.
 Jazz Integration Architecture (JIA) extends
OSLC to integrate tools further
 JIA defines Jazz Foundation Services
 Storage, Administration, Composite user
interface, Query, …
 Jazz architecture may be adopted
selectively and incrementally
 Jazz Team Server – An implementation of
Jazz Foundation Services
17
Monday, July 18, 2011

38. High Framework
Traditional Library/API
Degree of Coupling
s
e off
rad
te dT
c
pe
Ex
REST API
Import/Export
Surprise!
Delegated UI
via REST API
Low
Clunky Slick
Seamlessness of Interactions
Robustly Evolvable
Monday, July 18, 2011

39. Jazz Delivers Additional Value as Tooling Middleware
Jazz Architecture Enables
c
Collaboration Automation Reporting A scalable, extensible team
collaboration platform
Shared user and project admin
Enforceable process workflows
Dashboards with content from
any application
Cross-application query and
reporting
Shared infrastructure to reduce
Jazz is a software delivery platform for transforming howcost of ownership
people work together to deliver greater value &
performance from software investments.
36
36
Monday, July 18, 2011

40. Jazz Dashboard with contributions from several Applications
RQM User
RTC Viewlets
RQM Viewlets
RRC Viewlets
Monday, July 18, 2011

41. 2010+ JFS Application Architecture Example
Testing (RQM, ..)(RQM,
Architecture (RSA, Cool School)
Others...
Architecture (RSA, Cool School)
Example JFS Application - RRC
…)
Testing
Business Business Simulations &
Story-boards
Processes Objectives prototypes
Visual others
glossaries Use-cases
Validation
•Requirement documents •Textual Requirements
•Requirements doc templates •Requirements queries
•CALM integrations •Requirements dashboards
Requirements Management
Integration and Impact
Building
Collaboration Governance Blocks
Analysis
•Resource storage with •Linking •Process authoring and enactment
revisions •Basic online baselining •Review and approval
•Tags and discussion •Search and Query •Task management
•Feeds •Dashboards
Resource Management
Storage Query Security Admin
Shared
Jazz Foundation Services Services
Monday, July 18, 2011

42. A Shared Objective
Bringing together the tools and processes of the software delivery lifecycle
21
Monday, July 18, 2011

43. www.jazz.net - Transparent development visibility
Suppose we did our development
out on the Internet?
 A transparent software
delivery laboratory where you
can...
 Communicate with the
development team
 Track the progress of builds
and milestones
 Get the latest product trials
and betas
 Submit defect and
enhancement requests
 You can build Jazz
applications
 Jazz Foundation provides an
SDK, with optional toolkits to
aid implementation
Monday, July 18, 2011

44. 41
41
Monday, July 18, 2011

45. Daily iPod Touch giveaway
SPONSORED BY
 Complete your session surveys online each day
at a conference kiosk or on your Innovate 2010 Portal!
 Each day that you complete all of that day’s session
surveys, your name will be entered to win the daily
IPOD touch!
 On Wednesday be sure to complete your full conference evaluation
to receive your free conference t-shirt!
42
42
Monday, July 18, 2011

46. www.ibm/software/rational
© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.
References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced
in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future
product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services
are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product,
or service names may be trademarks or service marks of others.
43
43
Monday, July 18, 2011