OSLC in the wild

Figured I'd take a moment to highlight some recent public references and press around OSLC involvement (thanks to Scott Bosworth, I "borrowed" most of this material from him)

White paper (The Case for Open Services), John Wiegand

Podcast (OSLC Bears First Fruits), Steve Abrams, Carl Zetie, along with Mik Kersten

Presentation: (ALM Integration in a Web 2.0 World), Steve Abrams

Presentation: (Restful Work Items: Opening up Collaborative ALM), Steve Speicher with Mik Kersten

Blog (Let's Try Something Different), Carl Zetie

eBook (Scaling Agile with C/ALM), Carolyn Pampino, Erich Gamma, John Wiegand

Interview (Slashdot: Jazz Technical Lead Erich Gamma answers your questions), Erich Gamma

Website (open-services.net), Scott Bosworth

Jazz.net blog (OSLC and Rational Team Concert), Patrick Streule

Jazz.net article (How to consume the Rational Team Concert change management services), Martin Aeschlimann

IDC, Melinda Ballou (IBM Implements Open ALM Spec), John Wiegand, Scott Bosworth

Release (IBM, OSLC Promote Interoperability Across the Software Lifecycle), Scott Bosworth, Robyn Gold, Martin Nally, Mik Kersten, Mary Rose Greenough

Application Development Trends, John Waters (IBM Implements Open ALM Spec), Scott Bosworth

Information Week, Charles Babcock (IBM Sharpens Rational Tools), Scott Bosworth

InfoWorld, Paul Krill (IBM Hails ALM Standards Participation), Scott Bosworth, Steve Abrams

Software Development Times, David Rubenstein (IBM Suppor ts Open CM Initiative in Tools), Scott Bosworth, Steve Abrams

InternetNews.com, Alex Goldman (IBM Rational supports Open Services with new software), Scott Bosworth, Martin Nally, Mik Kersten

PC Week Russia (IBM Rational tools support the specification OSLC), original article

Delegated Resource Creation and Form Factories

One of the most debated topics during the development of the OSLC-CM 1.0 specifications was around resource creation. Many different approaches were discussed. First there were some traditional methods, where the consumer learns about what properties are needed, their types, constraints, etc and then appropriately builds a request body to POST to a given resource factory URI. Another approach is to agree on what a simple resource should look like, then have a resource factory URI that will accept these and in most cases will respond with a 201-Created and a URI for the new resource.

One of the most powerful features of the OSLC-CM 1.0 spec is the ability to delegate UIs for certain functions. Most (if not all) CM applications have a complex Web UI form used to collect all the required, dependent and typed fields; apply some validation, then commit the changes to its repository. We can leverage that already working fine Web UI form, apply some rules to it and then leverage it within other contexts. Applying these rules, or techniques, we can communicate across web applications that run within web browsers to communicate when the resource is created.

One other challenge to this approach it how to prefill a form, a key aspect of scenarios in CM integrations. It is not feasible to do more URL path building, which is fragile and has size limits. So we created a discoverable URL for posting some resource data and the result would be a URL to a prefilled form. This follows the some model as creating resources in REST, though in this case the resource is a form.

RESTful authentication, some more thinking

Unfortunately, I haven't had too much time to dedicate to this but have had a few discussions and a bit more time to think about it.

It seems to me that form-based auth for RESTful web services should be forbidden. There are clear standards on how to deal with authentication programmatically over HTTP: basic, digest, OAuth. Since the cost to implement basic-auth and utilize https is relatively small, it seems that adding more options (beyond basic, digest and oauth) will only further compound interoperability issues with client consumers.

More discussions and research should be done, though my current thinking would only be to add a statement to the OSLC-CM 1.0 specs stating that form-based auth is NOT recommended.

Presentations from Rational Software Conference

Last month in Orlando was the Rational Software Conference where I co-presented on OSLC CM with Mik Kersten from Tasktop and Eclipse Mylyn. We presented on our experience with developing the OSLC CM 1.0 set of specifications, background on the needs for these loosely couple REST services and more details about what is in OSLC CM 1.0.

RESTful Work Items: Opening up Collaborative ALM

View more documents from oslc.

Also Steve Abrams from the Rational CTO Team presented on OSLC: giving background, business value and current state.
ALM Integration in a Web 2.0 World

Be sure to check them out if you weren't able to attend the June conference. I'm sure we'll be talking about it more at next year's conference.

RESTful authentication and dealing with form-based auth

Early experiences with OSLC CM 1.0 indicate that discovery of authentication model of some service providers is needed, especially if form-based authentication is used. I'm doing some searching, research and analysis of various approaches to solving this problem in a consistent manner.
Some options include:

1. Prohibit the use of form-based authentication
   This involves requiring at a minimum Basic or Digest authentication schemes. This may have some implications to some applications as they may not be well suited to make this change.
   
2. Standardize the use of form-based authentication
   Since HTTP's WWW-Authenticate header is extensible, it could be possible to indicate the needed meta data either in the header and/or response body for the consumer to perform the authentication.

I'm curious if anyone has any experience with these and prefered approaches or drawbacks of other approaches.

A short pause, now on to 2.0

After recently finalizing the OSLC CM 1.0 specifications, a call for participation is out for the next wave of CM specifications (calling CM 2.0). We hope to have this group fired up soon and specifications nailed down by the end of 2009. If you are interested in contributing to the working group, please let me know.

Again, the specifications will be driven by the working group's determination of scope based on supported scenarios. Some work has already gone into key aspects of scenarios needed to support integrations with applications like Mylyn. These scenarios appear to raise the need for schema information in order to drive Mylyn's task editor and off-line support. Ease of adding attachments also comes out of these scenarios.

Some other areas that we'd like to tackle are (in no order, details will come later):

• alignment with other standards
  
• Better handling of differing authenication models
• saved/pre-defined queries
• various presentation modes: dialog vs full window

Hopefully we'll be able to accomplish these but again it depends on the priorities as defined by the members of the WG.

Some things that would most definitely fall outside the scope of the 2.0 work would be things like communicating state model and dependencies, standard link types, to name a couple.

Time to make it happen.

Change Management 1.0 specs complete - thanks team

On May 28, 2009 the OSLC CM Working Group completed the 1.0 round of specifications. I wanted to just quickly recognize the great work that was done by this team and their extended teams.

First off from IBM, Steve Abrams (Rational CTO Team, OSLC Lead Architect), Andre Weinand (Jazz WorkItem Component Lead) and I spent many hours together per week hashing out technical challenges and coming up with solutions that fit within the spirit of the loosley coupled approach to interoperability and the 1.0 specs. Also Scott Bosworth (Rational CTO Team) provided help in any way to ensure the group was successful. There are many others that supported us in this effort: Samit Mehta, Joe Toomey, ....

From Tasktop, Mik Kersten (Founder, CTO) and Robert Elves provided great feedback and background based on their experiences with many change management systems and vairous API implementations. They also provided direct feedback as an implementer (consumer) of the specs.

Lastly from Accenture, Randy Vogel and Gary Dang who provided great input and feedback from their experiences providing enterprise class integrated tools solutions.

A little bit about me and OSLC

Open Services for Lifecycle Collaboration (or just OSLC) was first introduced at the June 2008 Rational Software Developer's Conference in Orlando. It was launched in part with various activities around the Jazz initiative and started with a set of sample specifications and reference implementation.

I started my role as Change Management domain lead in October 2008. I was given the mission to coordinate, facilate and participate in a working group that would define a set of OSLC specifications that solved some specific integration scenarios (more on that another day).

My day job was also to produce a service provider implementation for Rational ClearQuest and assist in the one for Rational Team Concert, which both will be available in the next week.
I have a fairly diverse background as development leads for various change management tools, as well as have worked in many standardization efforts.

I plan to use this blog for various items. To post what is going on in OSLC in more than 140 characters, what has happened and how we got there as well as current topics in the works (and hopefully getting some additional feedback).