Innovate 2010-oslc-jazz
Upcoming SlideShare
Loading in...5
×
 

Innovate 2010-oslc-jazz

on

  • 1,638 views

 

Statistics

Views

Total Views
1,638
Views on SlideShare
1,636
Embed Views
2

Actions

Likes
0
Downloads
38
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Innovate 2010-oslc-jazz Innovate 2010-oslc-jazz Presentation Transcript

  • 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, FloridaMonday, July 18, 2011
  • Agenda The need for OSLC OSLC community approach OSLC status & successes OSLC technical approach Jazz and OSLC 2 2 2Monday, July 18, 2011
  • Software/product development tool landscape 3 3Monday, July 18, 2011
  • Software/product development tool landscape 4 4Monday, July 18, 2011
  • 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 3Monday, July 18, 2011
  • 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 10Monday, July 18, 2011
  • 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 4Monday, July 18, 2011
  • 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 5Monday, July 18, 2011
  • 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 9Monday, July 18, 2011
  • 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 13Monday, July 18, 2011
  • Disentangling your data via OSLC 11 11Monday, July 18, 2011
  • 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 6Monday, July 18, 2011
  • 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 6Monday, July 18, 2011
  • Agenda The need for OSLC OSLC status & successes OSLC community approach OSLC technical approach Jazz and OSLC 2 13 13Monday, July 18, 2011
  • 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. 22Monday, July 18, 2011
  • 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 15Monday, July 18, 2011
  • 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 15Monday, July 18, 2011
  • 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 25Monday, July 18, 2011
  • Agenda The need for OSLC OSLC community approach OSLC status & successes OSLC technical approach Jazz and OSLC 2 17 17Monday, July 18, 2011
  • 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 18Monday, July 18, 2011
  • Status across the eleven OSLC workgroups 19 19Monday, July 18, 2011
  • Agenda The need for OSLC OSLC community approach OSLC status & successes OSLC technical approach Jazz and OSLC 2 20 20Monday, July 18, 2011
  • 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 choiceMonday, July 18, 2011
  • 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 8Monday, July 18, 2011
  • 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 23Monday, July 18, 2011
  • 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 24Monday, July 18, 2011
  • 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 25Monday, July 18, 2011
  • 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 26Monday, July 18, 2011
  • 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 27Monday, July 18, 2011
  • 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 28Monday, July 18, 2011
  • 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 29Monday, July 18, 2011
  • 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 29Monday, July 18, 2011
  • 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 7Monday, July 18, 2011
  • Agenda The need for OSLC OSLC community approach OSLC status & successes OSLC technical approach Jazz and OSLC 2 31 31Monday, July 18, 2011
  • 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, licensingMonday, July 18, 2011
  • Driving integrations through C/ALM scenarioMonday, July 18, 2011
  • 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 17Monday, July 18, 2011
  • 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 EvolvableMonday, July 18, 2011
  • 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 36Monday, July 18, 2011
  • Jazz Dashboard with contributions from several Applications RQM User RTC Viewlets RQM Viewlets RRC ViewletsMonday, July 18, 2011
  • 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 ServicesMonday, July 18, 2011
  • A Shared Objective Bringing together the tools and processes of the software delivery lifecycle 21Monday, July 18, 2011
  • 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 implementationMonday, July 18, 2011
  • 41 41Monday, July 18, 2011
  • 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 42Monday, July 18, 2011
  • 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 havethe 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 referencedin 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 futureproduct or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and servicesare 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 43Monday, July 18, 2011