Level: Introductory Scott Laningham (scottla@us.ibm.com), Podcast Editor, IBM developerWorks
04 Nov 2008 John Wiegand, IBM® Distinguished Engineer and Rational® chief software architect, and Steve Abrams from the Rational CTO Team and lead architect for the Open Services for Life Cycle Collaboration talk about the OSLC Initiative. Hear about the latest with the Jazz platform, the challenges of integration, and the basics and benefits of the open services approach.
developerWorks: This is a developerWorks podcast. I'm Scott Laningham, here with John Wiegand, IBM Distinguished Engineer and Rational chief software architect; and Steve Abrams, from the Rational CTO team and lead architect for the Open Services for Lifecycle Collaboration Initiative. They're here to talk about that. Welcome to you both. Appreciate you being here.
Wiegand: Glad to be here, Scott.
Abrams: Thanks, Scott. Good to be here.
developerWorks: John, I'm wondering if it would be good if you might start us off with a bit of an update on the Jazz platform — sort of what's new and what you all have learned so far?
Wiegand: Well, we've delivered Rational Team Concert, the first product based on the Jazz technology, over the summer. And this effort of producing a highly collaborative software environment really taught us a lot of things about what it means to bring the various roles, the various practitioners together who are trying to do software delivery, whether it's people involved in the software development, the defect tracking, the project planning and the build, bringing them all together to be effective.
And our results here on the surfacing the integration needs has been really interesting for us. This new perspective of what's possible. And once we completed the first release, we sat back and we said, "Well, what more could we do and where are we at?" And we saw a range of things.
One is going for more of the life cycle — not just the software development aspects but also requirements and quality management — so filling out the life cycle more fully. But there was another realization, as well, of similar importance. And when we talk about integration, not just integration around one vendor's tools but rather, it's trying to meet the needs of the customer and which products do they have and what tools are they trying to integrate? So this need to support heterogeneous environment, where one tool comes from one place or perhaps a home-brew tool created by a customer, an open source tool.
It's really important that we can integrate all these things. And the insight that we learned from Rational Team Concert showing the quality of integration is a key input. But this other aspect we're learning now is the breadth of integration — what do we need to do and how can we succeed at that? And that's what triggered our thinking about this Open Source Initiative.
 |
Guest: John Wiegand
John Wiegand is a Distinguished Engineer at IBM Rational's Beaverton lab and Rational chief architect. He is responsible for defining the architectural and implementation aspects of Jazz as a platform for use in products across the software life cycle. Prior to his current assignment, he was the technical lead for the Jazz project. He was the principal architect for the Eclipse Platform infrastructure and played a central role in the development of VA/Java™, VA/Micro Edition, and Eclipse. He is a former member of the Eclipse Foundation Board, and played a key leadership role in establishing Eclipse as a successful open source project. He strives to enable teams to deliver high-quality products on time — pioneering, with Erich Gamma and others, an approach to software development called "The Eclipse Way." His interests are in the areas of performance, scalability, compilers, and more.
|
|
developerWorks: That certainly leads into the subject today of the OSLC initiative. I'm wondering now maybe talk a bit about what that is and what you all are trying to achieve. And Steve, jump in whenever you want. We don't want to exclude you here.
Abrams: Sure. Why don't I start off, in fact? So the open services for life-cycle services is an initiative that IBM announced at the Rational Software Developers Conference, which is aimed at bringing together multiple vendors and business partners and customers in the software delivery life cycle and encourage them to participate in the development of a set of standards and specifications that will make it easier for us to integrate the tools together.
As John mentioned, [the] typical customer has a variety of tools coming from multiple vendors, and at times, we've had to work really hard to build essentially brittle point-to-point connections amongst these tools to provide an integrated experience for the customer. And these brittle point-to-point integrations don't survive well through migrations of data or through upgrades of individual pieces of the puzzle, and the whole thing is sort of precariously balanced.
So the thought is that through this set of restful standards, leveraging what we've learned in building the Internet, we can build a set of standards and specifications that allow loosely coupled tools from multiple vendors to collaborate with one another to provide a seamless experience for the user across the software development life cycle, from requirements through defect tracking, project planning, delivery, build, testing — the whole nine yards.
|
Guest: Steve Abrams
Steve Abrams is Lead architect for the Open Services for Life Cycle Collaboration Initiative and a member of the Rational CTO Team.
|
|
developerWorks: What's the discussion like when you all are pondering these things and looking for these solutions? And I mean, how do you draw inspiration for these steps forward like this?
Abrams: I think the initial inspiration for the architecture of open services is from the Internet itself. So the Internet has achieved, of course, tremendous scale — on an unprecedented scale, in fact — distributed across the globe. There's no one place to go to wonder whether or not the Internet is up or down. The Internet is reliable. It's extensible. And it's made possible by a set of relatively simple protocols. You know there's the HTTP ... 90 percent of the Internet is HTTP get with a little bit of post thrown in. There's also [put to lead] and a few other things. But the scalability of the Internet has come about by exchanging well understood data through a fairly simple protocol.
And that's really the inspiration for the Open Services Initiative: focus on the data because the data is probably going to outlast any particular tool, if it's worth anything. And focus on a very simple set of HTTP protocols for passing the data around to enable a sort of live application use of the data.
developerWorks: So are those like the three basic elements of what you're talking about here? I mean the URLs, the data formats and exposing the data, that's kind of, in a nutshell, what we're talking about?
Wiegand: That's exactly it, Scott. And these simple principles have this value of being a proven approach. This is the way the Internet works, and it's proven to have these scalability and reliability extensibility characteristics.
And so by building on those notions, the part that's innovative here is we're applying what we consider as best practices in the Internet to the area here of software life-cycle tools. So by applying these notions and saying, "What we're going to do is require that all of the resources that we talk about have a URL, that they're all addressable."
We're going to encourage resources to be defined in XML and very extensible and flexible XML that one can augment it with additional elements as appropriate, a least-common denominator solution, rather than extensible and flexible solution. And then understanding the protocol — the behavior of the resources is also a key aspect. So these three come together, and those are the aspects we're talking about when we discuss open services.
developerWorks: Now, you're already talking about benefits there. But I'm wondering if you guys might expand on that a little bit, the benefits of the open services approach and also the different communities that benefit from it in this process.
Abrams: I think one of the real benefits of the open services approach is that a vendor who wants to participate has a range of options. It's not an all-or-nothing choice for the vendor if they want to participate. So if they want to at least allow their resources to be linked in as part of an ALM solution, step one for them, all they need to do is provide URLs for addressing their data.
So a defect-tracking system, for example — one might choose as their first step to provide a URL for each record in the defect-tracking system. That makes it easy for, say, requirements to link to those defects or test cases to link to those defects even though the defect-tracking system itself isn't any more deeply involved in the rest of the open services system.
I think the second choice that you might take or the second option you might take to get a little more deeply involved in open services is to begin to adopt some of these shared resource formats that we're starting to define. And this has benefits in that it allows other tool vendors to understand your data — not just point to it because it has URL but also understand it. So, for example, a requirement that has the URL that is in an open services format can not only be linked to from a work item, but the work item editor might decide to show some summary information that it gleans from the underlying data format.
And then the third choice you might make is to understand the services that are provided by OSLC-compliant tools. So not just pointing to the data and understanding it when you read it but now understanding how, for example, you might submit a requirement into the approval process that's offered by a vendor in their open services-compliant tool.
So, it's not an all or nothing story. One of the benefits you get to pick how deeply you want to play in this game and take an incremental approach to adopting the OSLC.
Wiegand: Also appear in the open source community and your building tools that you can tap into the resource designs that are being worked on as part of the Open Services Initiative. It's not a vendor-exclusive relationship, but rather, anyone can implement these interfaces on their own. So it provides the openness for anyone to do this with no specific lock in.
Similarly, for perhaps system integrators or others, when they see tools that they would like to see integrated that they didn't write, they can layer these interfaces on top of an existing implementation that provides more tools that have this characteristic, which brings us back to the customer, the place we should really start, which is we now have as a customer the ability to bring in tools from a wide range of sources. We can actually address our goal here of being able to integrate tools from a range of sources that end up with a life-cycle solution that meets my specific need.
developerWorks: I'm wondering what are some of the issues in evangelizing this and getting adoption in the broader community? What are some of the challenges that you all deal with, the topics that come up?
Abrams: I think one of the issues that always comes up is "When do we get started?" "How do we get started with one of these specifications?" There's a range of vendors and partners that would like to participate, and everyone has some set of legacy products that they've built over time. So getting started with a common set of concepts and a common understanding of even the mission and the approach of open services is one of the first sets of challenges that we have to deal with.
Wiegand: One of the things I like to notice is how this conversation is different than many of the ones we've had in the past about this. Often, the starting point is focusing on the framework that I'm building with and we say, "We're enabling the construction of Java™ language tools," we'll say, in particular: "Here, we have a specific framework built in Java that you can expand and leverage."
And what we're doing with this initiative, what we're enabling is agreement around the protocol, agreement around the resource format. But then the freedom for each of us participating in it to implement in the language of our choice using the toolkit of our choice and the frameworks of our choice or not. And so this gives us the ability to end up with this high-fidelity integration, high possibility of integration, great range of integration, but no constraint about how we got there. So it's not a start-over kind of story, but it's a — let's focus on the interface and find ways to do integration.
So the promise here is great but the getting started as Steve alluded is still a challenge: Where do I want to go first? And what are the pieces I have to work with? How do I get my feet wet?
Abrams: So, one of the things that is critical for getting the community to participate has been establishing policies around intellectual property that encourage the kind of innovation that we want. So what we've set up is a mechanism by which people who participate in the Open Services Initiative are contributing materials under a creative commons attribution license, which means that anybody can freely use any of the information or derivative materials from anything that they post, which is really important for getting people to participate. And in order to get something into one of these specifications, participants are going to need to provide a covenant not to hold anyone beholden to their patent rights that they might have.
So this is really important for getting an initiative like this started. People can feel free to contribute, not be concerned that there are patent traps being set for them, and that any of the information that's provided under this sort of umbrella is going to be free for anyone to use for these purposes.
developerWorks: So how would you gauge the overall receptivity then to the initiative?
Abrams: It's been very encouraging. We've been out talking to lots of partners and independent vendors and integrators and open source projects, and everyone recognizes that this integration problem is a killer problem when you're trying to build these integrated life-cycle solutions. And a more open sort of loosely coupled approach like we're advocating here through open services is what's critically needed. So we're really seeing a lot of interest from all the key players out in the industry on this.
developerWorks: That's great. Now let's talk about community involvement. Where do people get started with this? How do you see the community developing around this?
Wiegand: So we've set up an entry point at Jazz.net for people to learn more about what's out there. It's a place where we've got the conversation started. We have an overview description from typical resources, some prototypes of how we would go about the resource design and actually a sample server showing it in action, and also guidance about the principles behind the design itself to encourage others along the route. But initially getting started materials are available at Jazz.net.
Abrams: And moreover, the actual Web site where the community is going to come together to have conversations about the specs and evolve the specs has just been announced it's at open services.net. It's a combination of wiki and mailing list and a place where we'll actually evolve the specifications in the open and public, so people can come there, see what's happening, join in a conversation, share their thoughts and ideas on how these resources and specs ought to evolve.
developerWorks: Excellent. And I'll make sure we have those links in the show notes for the podcast so listeners can find them. I wonder if we could maybe wrap up with everybody's got to wonder, too, what about IBM adoption of the open services approach? What can you tell us about that?
Wiegand: Well, we're not just talking about this and soliciting interest, but a key aspect of our approach and the architecture of our products moving forward. We're applying it to integrations between some of our existing products, first of all, and that's seeded some of the initial contribution from IBM in the Open Services Initiative. But it's also an underpinning of our Jazz integration architecture. With the Jazz integration architecture, we start off with open services to define the resources that one interacts with.
But in addition, when one's building an application, there's a set of shared services that are provided for use — for example, administrative services, process services, query services, storage services — and these provide the ability to get an even greater degree of integration and provide an even more collaborative environment.
Providing common licensing and user administration, for example. Or, a shared process across multiple tools. These kinds of things will become possible over time as we flesh out what we call the Jazz foundational services.
developerWorks: This has been great. And we certainly look forward to following how this unfolds and maybe checking back in with you all at some point and getting an update on how things are going. IBM's John Wiegand and Steve Abrams, thank you both for making time for this. We really appreciate it.
Abrams: Thanks a lot Scott.
Wiegand: Take care, Scott.
developerWorks: This has been a developerWorks podcast. developerWorks is IBM's premiere technical resource for software developers with tools, code and education on IBM products and open standards technology. I'm Scott Laningham. Talk to you next time.
Resources
About the author | 
| | Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician. |
Rate this page
| 
