Innovate 2010-oslc-jazz

The premiere software and product delivery event.June 6–10 Orlando, Florida

Open Services (OSLC) and Jazz: Working Together

Dave JohnsonWeb 2.0 Architect, IBM [email protected]

John WiegandChief Architect, IBM [email protected]

ALM-2210B

Monday, July 18, 2011

mailto:[email protected]




22

AgendaThe need for OSLCOSLC community approachOSLC status & successesOSLC technical approachJazz and OSLC

2


3

Software/product development tool landscape

3


4

Software/product development tool landscape

4


3

Traditional Tool Integration. Ouch.

N2 possible point-to-point connectionsLimited coverage Closed APIsVendor lock-in Tight CouplingDependence on internal structures Lockstep upgradesVersion incompatibilities


10

Bus Proc Model

Software & Solution

ArchitectureDevelopmentEnt Arch Require-

ments

Paymentprocess

Paymentservice

Payservice

Settlementservice

Paymentservice

Cashservice

Test

Paymentservice

Payprocess

Settlementprocess

Paymentprocess

Cashprocess

Paymentprocess

Traceability links Model concepts

Data Integration - the old way


4

The Business Costs of Traditional Approaches

For tools users Inconsistent connectivity Reduced choice Hindrances to timely upgrades

For Integrators and Consultants Lack of skills transfer between projects Ramp-up on each new project

For tools vendors Limited connections = limited value Time wasted in negotiations Disputes over responsibility for bridge code

For Open Source projects Lack of focus on building integrations Difficulty participating in commercial partnership

programs


5

The Potential of a Better Approach Good for our businessStable interfaces to overlapping productsDramatically reduce integration, support, maintenance costsImprove time-to-market

Good for our customersFreedom of choiceFlexibility of incremental adoptionImproved productivity

Good for our IndustryInteroperability increases the value of every offeringSpark innovation around the edgesEnable new business opportunitiesGrow the whole pie

2004 20122008

Current Course

Pre-Standards

Fragmented standards maintain lock-in Business value limited

Common standards promote interoperability Business value of every offering rises

Inte

grat

ion

M/W

Rev

enue


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


13

Bus Proc Model

Software & Solution

ArchitectureDevelopmentEnterprise

ArchitectureRequire-

ments Test

http://acme.com/paymentService

Data Integration – the new way – “WWW linked data”

http://acme.com/paymentProcess

about

aboutabout about

HTTP/REST


11

Disentangling your data via OSLC

11


6

Open Services for Lifecycle Collaboration

Community Driven – specified at open-services.net

Specifications for ALM and PLM Interoperability

Inspired by Internet architecture Loosely coupled integration with “just enough”

standardization Common resource formats and services

A different approach to industry-wide proliferation


Barriers to sharing resources and assets across the software lifecycleMultiple vendors, open source projects and in-house toolsPrivate vocabularies, formats and storesEntanglement of tools with their data

An initiative aimed at simplifying tool integration across the product delivery lifecycle


6


Community Driven – specified at open-services.net

Specifications for ALM and PLM Interoperability

Inspired by Internet architecture Loosely coupled integration with “just enough”

standardization Common resource formats and services

A different approach to industry-wide proliferation


Barriers to sharing resources and assets across the software lifecycleMultiple vendors, open source projects and in-house toolsPrivate vocabularies, formats and storesEntanglement of tools with their data

An initiative aimed at simplifying tool integration across the product delivery lifecycle


132

AgendaThe need for OSLCOSLC status & successesOSLC community approachOSLC technical approachJazz and OSLC

13


22

Open Services for Lifecycle CollaborationCommunity 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.


15

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)

Identify Scenarios

Iterate on working drafts

Call it a spec

Gain technical consensus, collect non-

assert statements


15

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)

Identify Scenarios

Iterate on working drafts

Call it a spec

Gain technical consensus, collect non-

assert statements


25

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


172


17


18

OSLC by the numbers

11 active work groups

30 companies represented

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

AccentureAPGBigLeverBlack DuckBoeingBSD GroupCitigroupEADSEmphasys GroupEricssonFokus FraunhoferGalorathGeneral MotorsHealth Care Services CorpIBMInstitut TELECOMIntegrate Systems

Lender Processing ServicesNorthrop GrummanOracleQSMRally SoftwareRavenflowShellSiemensSogetiSourceGear/TeampriseState StreetTasktop (Eclipse Mylyn)TietoTOPIC Embedded SystemsUrbanCodeWebLayers


19

Status across the eleven OSLC workgroups

19


202


20


Architectural Assumptions

You cannot get all the data in a single database/repositoryBut you do have to cross-link all the data wherever it isAnd you have to be able to query the data wherever it is

You cannot design a Grand Unifying data modelIndividual teams customizeCommunities can’t agree

Frameworks are a two-edged sword. Powerful for some, but ….Constrain language and execution environments Barrier to adoptionDifficult to mature and evolveTend to tightly couple components

Customers demand choice


8

Integration Must Avoid Premature Restrictions

Traditional tool-to-tool integrations

Replace n² point-to-point integrations with n interfaces Reduce version-specific brittleness Eliminate dependency on vendor-to-vendor cooperation Ideal for tools that need to integrate widely, e.g. build mgmt; policy and quality inspection; project mgmt and status

Aggregation of disparate data sources

Individual sources can be local, in the cloud, or any combination Supports both consolidated data warehouse or “reference in place” models Enables customers to use their choice of portal or console, including vendor products, open-source, or home-brew solutions

Process automation

Enables creation of custom workflows and automated processes Individual tools/services can be local or in the cloud Customers can freely choose workflow engines and process monitoring consoles

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


23

Technical approach

Build on the architecture of the WWW and RESTFocus on resources, uniform interface of HTTP and stable/opaque URIs

Build on the simple/powerful Resource Description Framework (RDF) data modelDefine resources and the properties allowed and required for each

Balance tension between consistency & flexibilityWant consistency but not at the cost of innovation

Keep it simpleMinimize new concepts introduced & specifications referenced

Please wide variety of consumersProvide JSON, XML, Atom and other representations

23


24

The OSLC Core Specification - motivation

In the first year of OSLC we saw workgroups do some redundant workSpecifying how HTTP operations work for each type of resourceSpecifying the details of how to create XML, JSON and Atom representations

Specifications were similar, but inconsistent in small ways

24

OSLC domain spec

RESTful protocol

Representations

Domain spec

OSLC domain spec

RESTful protocol

Representations

Domain spec

OSLC domain spec

RESTful protocol

Representations

Domain spec

OSLC domain spec

RESTful protocol

Representations

Domain spec

OSLC domain spec

RESTful protocol

Representations

Domain specOSLC

domain spec

RESTful protocol

Representations

Domain spec

OSLC domain spec

RESTful protocol

Representations

Domain spec

OSLC domain spec

RESTful protocol

Representations

Domain spec

OSLC domain spec

RESTful protocol

Representations

Domain spec


25

OSLC Core Specification - approach

To keep the domain specifications consistent And to maintain the architectural integrity We developed the OSLC Core Specification Specifies how to describe and represent resources

Domain specification extend the CoreFocus on domain-specific issues

Defining resources Specifying operations Specifying which parts of Core are required

25

OSLC Core spec

RESTful protocol

Representations

OSLC domain spec

Domain specOSLC domain spec

Domain specOSLC domain spec

Domain spec

OSLC domain spec

Domain spec

OSLC domain spec

Domain spec

OSLC domain spec

Domain spec

OSLC domain spec

Domain spec

OSLC domain spec

Domain spec

OSLC domain spec

Domain spec


26

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 HTTPFor resource create, retrieve, update and delete

How to represent OSLC resources in RDF/XML, JSON, Atom and TurtleRules for generating representations

How to offer a Query CapabilityAnd specifies a Query Syntax

How to offer services to clientsVia a Service Provider resource

How to offer Delegated UI See next slide

Core specification defines the HOW, domain specifications define the WHAT

26


27

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 schemaThe 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 APIThe easiest or best way to select a resource in Service A is via Service A’s UI

27


28

OSLC Core spec vs Domain specs

28

OSLC Core Specification

How to define OSLC resourcesHow to offer servicesHow to inform clients of resource shapesHow to offer delegated UIsHow to offer query capabilitiesHow to offer resource creationWhat authentication is allowedHow specification versioning worksHow to represent OSLC defined resources

OSLC Domain Specification

Defines OSLC ResourcesOffers servicesMay offer resource shapesMay offer delegated UIsMay offer query capabilitiesMay offer resource creationProvides examples of representations

Core spec defines the how

Domain specs define the what


2929

Web BrowserService Provider A’s

Web UI

OSLC

Service Provider A

<iframe>Service Provider B

Delegated UI</iframe>

OSLC

Service Provider B

A examines B’s Service Provider resource to determine the URIs of any Delegated UIs offered by B

The UI Consumer The UI Provider

A embeds a Delegated UI from B in its web UI via an <iframe>

Delegated UI from B allows user to perform creation or selection

B informs A of user response

1

2 3

4

Delegated UI DialogsFor resource creation and selection


2929

Web BrowserService Provider A’s

Web UI

OSLC

Service Provider A

<iframe>Service Provider B

Delegated UI</iframe>

OSLC

Service Provider B

A examines B’s Service Provider resource to determine the URIs of any Delegated UIs offered by B

The UI Consumer The UI Provider

A embeds a Delegated UI from B in its web UI via an <iframe>

Delegated UI from B allows user to perform creation or selection

B informs A of user response

1

2 3

4

Delegated UI DialogsFor resource creation and selection


7

What Makes the OSLC Approach Better?

Traditional Approach Brittle integrations, version-specific APIs

Monolithic repository or import/export

“Boil the ocean” meta-model design

Forced migration to a common code base

Premature architectural decisions

A vendor-led “partners” program

OSLC Approach Loosely-coupled

URLs

Minimalist

Technology-neutral

Incremental

Open


312


31


Further detangling – Building with Jazz

The Jazz Integration Architecture enables tools to go beyond OSLC

Tools can discover additional capabilities beyond the core OSLC specsAdvanced query, Process enactment, customization details

The Jazz Foundation provides services which can be used to extend tools which may be closedJazz Storage Service for additional data about tool resources, such as traceability links

between two un-integrated toolsJazz 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 issuesOne answer for authentication, identity, scaling, deployment, admin, licensing


Driving integrations through C/ALM scenario


17

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


Surprise!

Expected Tradeoffs

Deg

ree

of C

oupl

ing

Seamlessness of Interactions

High

LowClunky Slick

Import/Export

Traditional Library/API

Framework

REST API

Delegated UI via REST API

Robustly Evolvable


3636

Jazz Architecture Enables

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 cost of ownership

Jazz Delivers Additional Value as Tooling Middleware

c

Collaboration Automation Reporting

Jazz is a software delivery platform for transforming how people work together to deliver greater value &

performance from software investments.


Jazz Dashboard with contributions from several Applications

RQM User

RQM Viewlets

RTC Viewlets

RRC Viewlets


Example JFS Application - RRC

2010+ JFS Application Architecture Example

Requirements Management

Architecture (R

SA

, Cool S

chool)

Testing (RQ

M,

…)

Jazz Foundation Services

Building Blocks

Shared Services

Visual Validation

Simulations & prototypes

Business Processes

Business Objectives

others

Story-boards

Use-casesglossaries

•Textual Requirements•Requirements queries•Requirements dashboards

•Requirement documents•Requirements doc templates•CALM integrations

Resource Management

Collaboration Integration and Impact Analysis Governance

•Resource storage with revisions•Tags and discussion•Feeds

•Process authoring and enactment•Review and approval•Task management•Dashboards

•Linking•Basic online baselining•Search and Query

Query Security AdminStorage

Architecture (R

SA

, Cool S

chool)

Testing (RQ

M, ..)

Others...


21

A Shared ObjectiveBringing together the tools and processes of the software delivery lifecycle


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


http://www.jazz.net/

http://www.jazz.net/

4141


4242

Daily iPod Touch giveaway

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!

SPONSORED BY


4343

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

www.ibm/software/rational
