Open Services for Lifecycle Collaboration and More

Reconsidering the "S" in OSLC (as it is not the same "S" in SOA)

2012-01-25T11:31:00.000-08:00

technically stands for "Services" in OSLC but what are these "Services"? In doing a little digging, the original intent of the name was to focus on REST and therefore the word "services" was introduced to represent "REST services". This has led to a number of problems with confusion over what type and kind of services are we talking about. For instance, there is a natural tendency to map the OSLC use of the word service with that of SOA (Service Oriented Architecture), which is not at all the association we want. Will this be a constant problem as OSLC expands into new domains and 3rd party adoption? I believe so.

There are a couple of things to focus on, is what we really want to achieve with OSLC and what name awareness we want. So that means, continue to focus on "OSLC" as a term and not worry too much about what each letter means without context.

I'm proposing to fix the problem with "S" standing for "Services" and instead introduce "Specifications". So try this on for size,

Open Specifications for Lifecycle Collaboration (OSLC)

I'd be interested in any reaction to this change, support or problems. I believe this is a necessary change and the right one. It captures what OSLC is really about. Yes, changing this provides a bit of short term pain but the longer we wait it will be harder to change and we'll have to continue to deal with the confusion it introduces.

Of course there are a number of logistics to consider with such a change:

Fixing names used on websites, articles, charts, etc (like the title of this Community)
Considering updating more complicated things like OSLC intro videos
Considering a better domain name

I did blog last year on The "O" in OSLC, which is still valid as "open" by the way.

Do you see this as being an issue worth addressing?
Do you have other suggestions for the letter "S"?

Be interested in hearing both support for this, as well as any concerns.

W3C Workshop on Linked Enterprise Data Patterns

2011-12-11T18:58:00.000-08:00

I attended a W3C Workshop title "Linked Enterprise Data Patterns" on December 6&7, 2011 at MIT in Cambridge, MA. It had many interesting sessions covering a wide variety of topics. The position paper by Rational presenting by Martin Nally covered what we learned in Rational and with OSLC. Responses made it clear that we weren't alone with seeing this need. This included Tim Berners-Lee and many other attendees with years of experience deploying and building Linked Data applications.

Key result of the workshop was consensus on the need for standardization, as logged in IRC:

(1:45:06 PM) sandro: RESOLVED: We want a Working Group to produce a W3C Recommendation which defines a Linked Data Platform -- something that solves IBM Rational's use case (presented yesterday). We expect this to be an enumeration of specs which constitute linked data, with some small additional specs to cover things like pagination, if necessary.

Next steps will involve evolving the IBM Developer Works publication "Towards a Basic Profile for Linked Data" into a member submission for consideration into the W3C Recommendation track.

EclipseCon Europe Trip Report and EclipseDemo Camp Raleigh

2011-11-14T07:14:00.000-08:00

I attended EclipseCon Europe Nov 2-4 in Ludwigsburg, Germany. I was on the agenda to do a 90 minute workshop on using Eclipse Lyo to enable OSLC integrations. I had a small be interested group of attendees and was good to see people already had a familiarity with OSLC (and Lyo for that matter). They were looking to see how better to apply OSLC to some specific tools and scenarios. Good to see real usage. Also good to hear that one of the attendees had plans to leverage Lyo in early 2012 as part of an offering they had.

I attended a number of interesting talks on some lessons learned and best practices for managing contributions at Eclipse. Something that has been of immediate interest as we get Lyo operational and efficient. These talks were often led or facilitated by Eclipse Mylyn committers and it was good to see they referenced OSLC in their description of Mylyn.

I also was able to see the great working going on in Eclipse Orion and see that OSLC is on their roadmap as well. Think there are some great ways that Orion can benefit from OSLC-based integrations and I'll be digging into that as well.

Enjoyed the various 10 year talks and events as well. Including keynote by former IBM-exec John Swainson as he reflected on the business decision to open source and create Eclipse. Also the look back at Eclipse's 10 year in action by John Kellerman and Kim Moir, including a nice photo album collected over the years at the IBM booth.

In conferences like this, it was great to finally put a face with a name, make some new connections and have some good one-on-one discussions. These things are often hard to do remotely.

Immediately when I returned, I co-presented Eclipse Lyo with Michael Fiedler (fellow IBM'r and Lyo committer) at Eclipse DemoCamp Raleigh. It was a packed room and a good time.

OSLC Implementations

2011-10-03T08:59:00.000-07:00

We are working on putting together a catalog of OSLC implementations on the OSLC website and starting to jot down some ideas on how best to present this. It is quite common for many specification efforts to list a number of implementers of those specs. The intent of this list is not to be a validated by some 3rd party to be "good OSLC" implementations. Instead just simply to be a way to pull together OSLC implementations onto a single consumable page and be redirected to details about that.

Here's my attempt at building such an implementation list for OSLC with full disclaimer that no guarantees on the OSLC-ness of these. Please comment or contact me with anything missing or not represented properly.

Take 2: I decided to "keep it simple". Have the spec details supported will be a nice future enhancement that I don't plan to do soon.

OSLC Providers

CURRENTLY UNDER HEAVY CONSTRUCTION

Tool	Summary
IBM Rational Team Concert	Supports CM 1.0 and 2.0 specifications for its Work Item component.
IBM Rational Quality Manager	Supports QM and CM specifications
IBM Rational Requirements Composer	Exposes requirements according to RM specifications
IBM Rational DOORS	Support for RM specification, facilitating greater and simpler integration possibilities
IBM Rational Software Architect Design Manager IBM Rational Rhapsody Design Manager	Trace from designs to other lifecycle artifacts using Open Services for Lifecycle Collaboration (OSLC) based linking
IBM Rational ClearQuest	Exposes all records according to CM specification
IBM Rational Asset Manager	Expose resources per AssetMgmt specification
FusionForge Tracker	Support CM V2 specifications in order to implement a REST based API
Rational OSLC Adapter for Atlassian® JIRA®	Support CM V2 specifications and tested with Rational CLM Solution

OSLC Consumers

CURRENTLY UNDER HEAVY CONSTRUCTION

Tool	Summary
IBM Rational Team Concert	Can connect to CM, RM, QM and AM providers
IBM Rational Quality Manager	Can connect to CM, RM, QM and AM providers
IBM Rational Requirements Composer	Can connect to CM, RM, QM and AM providers
IBM Rational DOORS	Support for CM, QM specifications, facilitating greater and simpler integration possibilities
IBM Rational Software Architect Design Manager IBM Rational Rhapsody Design Manager	Trace from designs to other lifecycle artifacts using Open Services for Lifecycle Collaboration (OSLC) based linking
IBM Rational ClearQuest	Can connect to CM, RM and QM providers
IBM Rational Asset Manager	Can connect to CM, RM, QM and AM providers
Jenkins Plugin	Connects to different remote bug trackers via the OSLC protocol
IBM Tivoli Service Request Manager	Connects to bug trackers (dev teams) via OSLC

Common References

OSLC CM Implementation Report

Using HTTP REST to handle long running jobs / requests

2011-07-25T13:55:00.000-07:00

At OSLC we haven't dug into how best to handle long running requests, something a server may take a fairly long time to generate a response to. Take for example a submission to a build engine to execute a build, the execution may take hours. Of course, you don't want to initiate a request and have to leave the connection open to wait to receive a response. I'd expect the Automation(Build/Deploy) working group to work on evolving a proposed solution to this. Though there is precedence on solutions for this, as indicated in a blog post by fellow IBMer / OSLCer Bill Higgins.

I'd be interested in hearing any feedback on experience with HTTP REST-based solutions to handling long-running requests.

Innovate 2011: Trip report and OSLC feedback

2011-06-14T07:51:00.000-07:00

My Innovate conference again was filled with OSLC discussions. I found it tough to get to many sessions this year, which was rather unfortunate due to the large number of high quality content. My schedule consisted of a mix of presenting, customer meetings and exhibit hall duties (probably sounds familiar to most attendees).

Monday June 6th:

Opening Keynote - inclusion of content about Eclipse Lyo (OSLC SDK) project proposal, which was good to hear.

I was off to the new "Jazz Interopability Center" feature OSLC where I was setting up the shared local network, along with CLM, JIRA (early prototype), Bugzilla (adapter from OSLC tutorial work) and ClearQuest servers. There was a strong push to get this out and working, it was great to see it all come together with minor interruptions. There was a lot of hard work to make this a success and they deserve the credit.

I presented "ISM-1071 Improve Collaboration between Support and Development Using Open Services for Lifecycle Collaboration" with John Arwe from Tivoli. About 30 people in attendance and good questions about how the integration works. We'll have to wait to see what he survey says.

Due to some networking the night before at the reception, the Tivoli SRM and ClearQuest OSLC-based integration was working (early prototype) just in time for exhibit hall opening.

Then I was off to the Interop Center for final setup and opening. Of course, there were some problems but was able to recover just in the nick of time. There was a slow start to the traffic as attendees made their way to the back (and past the food and bar). Feedback from the ped staff across the board stated that they were very pleased with the amount of traffic and discussions on-going.

Tuesday June 7th:

Early day discussions and breakfast with a customer and their integrations. This was mostly focused on adoption of RTC and how to co-exist with CC/CQ setup. Though some discussion on Siemens integration was brought up.

Late morning I ran the workshop "TW-1161 OSLC enable your tool in a day" (based on OSLC Tutorial Part 2) which was wait-listed but only had about 35 out of 50 capacity actual show. Throughout the week I had many people ask if the workshop was going to be run a second time during the week, something to consider in the future. The workshop went really well in my mind. A good number of students were able to get through all the labs in the amount of time given. I was able to get into some great discussions from some of the attendees. I gave many copies of the material to IBMer's who said that it was exactly what their account teams and colleagues needed and were going to share with them. Some of the attendees had 3rd party providers already in plan and had good design discussions about how to approach. Great feedback from these attendees on the value of the workshop for them and on this effort.

I was able to attend some of John Arwe's session titled "Extending OSLC" which was a very full session. John talked about how OSLC approach (both community and technical) can be applied to integrated service management (ISM).

Presented TJI-1072 Keys to Building and Consuming Open Services for Lifecycle Collaboration Providers in Support of Open Lifecycle Integrations" just as the exhibit hall is about to open. There was a good mix of attendees here, some familiar faces and none I have seen before (IBM and not). There were some good questions throughout (people trying to jump ahead).

Ran back over to the Interop Center for more good interaction with attendees.

After exhibit hall closed we held "BOF-2319A Lifecycle Integration: Open Services for Lifecycle Collaboration" which had great participation from Rational technical leaders, AIM, Tivoli, Siemens, Tasktop and more. Discussion was started by reviewing progress on recent "2.0-based" specs such as Core, CM, RM, QM and AM. Other community topics including open-source, alignment with other standards efforts (W3C linked data/semantic web) and need to continue as an independent community. Some observations were that OSLC is now part of Rational's "fabric" (as Martin Nally says) and part of every integration discussion.

Wednesday June 8th:

Was fortunate enough to make it back to the keynote to catch IBM Watson and IBM Fellow Grady Booch. I thought it was great to see Grady using the Rational tools to describe the internals of Watson. My only "criticisms" were:

it was near impossible to read/understand the diagrams
there was no connection to DeepQA and how it uses Linked Data / Semantic Web technologies, the same that OSLC and the Jazz Platform are based on. Thought it would have been a very powerful connection
it would also have been insightful to get Grady's thoughts on how this technology will influence the "tools" that we Rational are building. The last chart had something about areas IBM is exploring: healthcare, helpdesk, etc but not "development intelligence"

Interop Center again! Final session we thought was going to be slow to start, it was the opposite, started strong and finished a little slow. We held a retrospective after the exhibit hall closed. One thing that made it clear to me that the ped staff, even though they just finished a tough few days, were energized by the reaction they got and had many great ideas on how to improve/enhance it in the future.

Met with a customer who has both Rational and Tivoli products. It was good to see that our strategy and solutions really resonated with them, they were pleased with our direction and looking to deploy it this year.

Thursday June 9th:

I attended "CS-1651A Leveraging Open Services for Lifecycle Collaboration for Project Management Information Using Excel to Improve Software Delivery" presented by our colleagues from IBM Japan, NEC and Fujitsu. This was very well attended, especially with the Japanese attendees. This was a very interesting presentation on the differences in how projects are run in Japan and the tools used. It provided an interesting approach using OSLC-enabled Excel to connect to and from tools like RTC. I look forward to seeing their progress.

In Summary:

I found very few people who didn't know what OSLC was at a high-level but when presenting during my sessions some of the feedback I got was that I had cleared some misconceptions that they had. Also the message is clear that customers would like to see more participation in OSLC by key ALM/PLM tool vendors and ways for it to continue to operate as an independent entity. Many were encouraged to hear about the Eclipse Lyo project proposal and the continued contributions to open source. It was great to meet some colleagues for the first time in person, catch up with others and make new connections. I look forward to the continued collaboration and reach of OSLC.

OSLC at Innovate 2011 Conference

2011-05-27T05:21:00.000-07:00

OSLC will be all over this year's IBM Rational Innovate conference June 5 - 9 in Orlando, FL. I've included some of the many OSLC-related sessions below in the embedded calender. The OSLC community has put together a list of a sessions and known attendees as well.

I specifically wanted to mention a new addition to this years conference around OSLC and that is the "Jazz Interoperability Center". This will be available during exhibit hall hours and will highlight OSLC-based integrations from a mix of participants including: Rational, Tivoli, Siemens, Tasktop, iTKO, BSD Group and more. Look for this area when you arrive at the exhibit hall.

The other interesting thing to note, is that OSLC is not just showing up at the IBM Rational conference but has been, or will be, showing up in a number of other conferences as well. It is good to see that a larger community is seeing and getting the value out of OSLC that IBM is.
Other conferences with OSLC presence:

"OSLC in action :: agile meets enterprise reality" June 12 at Jazoon http://jazoon.com/Conference/Tuesday-21-June/Thorsten-Gau
“OSLC : open standard for interoperability of open source #ALM tools” May 11 at SolutionsLinux (Paris) http://ur1.ca/43c1s

Determining how best to participate in OSLC service discovery

2011-03-18T11:09:00.000-07:00

OSLC specifications are often written with the intent to solve some basic integration scenario. Sometimes it is not obvious the best way to apply the specifications to some specific tools. I'll take a look at a couple of bug trackers (Change Management Providers) and see how one might use oslc:ServiceProvider and oslc:ServiceProviderCatalog with them to allow for service discovery.

Let's take a look at a couple of specific installations of Bugzilla: one at Eclipse and the other for Mozilla (Firefox). The typical partitioning of bugs within Bugzilla is by product. Eclipse has them grouped by common areas (Classification) as these shown below:

Let's say from this list I want to open a bug against EMF. I'm presented with either a guided or traditional web page for filling out this form. From there I pick a Component and provide additional fields needed to complete the form.

So the organization of bugs within Bugzilla are:

With OSLC, we have the possible structure of mapping to any number of oslc:ServiceProvider and oslc:ServiceProviderCatalog. So what makes the most sense? We need to look at how our resources are grouped together and restrictions put on that grouping. A oslc:ServiceProvider contains the URIs to various capabilities a provider has to offer like: resource creation by POST, query, delegated web UIs for creation and selection of resources. This grouping is usually driven by certain constraints put on these resources. For example it could be all resources in a given project or product. The access rights and rules on creations are often isolated to a given project or product area. From this criteria, the Bugzilla "Product" seems like a good fit for oslc:ServiceProvider. From here, it would seem natural to have one oslc:ServiceProviderCatalog per Classification. This would allow someone to get a catalog for a specific Classification and it would lists all the Products associated with it. So this would give us a picture like this:

The next question one might ask is: how do I know what all the Classifications are? Since oslc:ServiceProviderCatalogs can reference also other oslc:ServiceProviderCatalogs we can introduce another catalog as the "root" of all these pieces of information. So the picture would now look like:

So one may be thinking now: what about Component? Looking at its usage within Bugzilla instances it is more of a "common required property" than what was described before as criteria for selecting a oslc:ServiceProvider.
Some other options could have been done as well. Not having intermediate oslc:ServiceProviderCatalog but instead list all oslc:ServiceProviders (Products) in a single oslc:ServiceProviderCatalog. This may have worked fine and depending on how you server partitions its resources, an organization list this could make sense.

Next let's take a look at Google Code's Issue Tracker. There is only one instance of this server of this code base and it is at http://code.google.com. Let's look at some of the qualities of the projects there and organizational structure. As I type this, there are 5,681 projects. These projects can be tagged to make them easier to find. Each project has its own issues URL, which can be used to get feeds on issues and POST to it to create a new issue. As you could imagine, a common way to find projects and issues within projects is by using Google's free-text search. So given this, it seems like a project would be represented as an oslc:ServiceProvider. Though it makes me think how many of our existing clients are prepared to deal with an implementation that has an oslc:ServiceProviderCatalog with 5,681 entries. Within OSLC there is a general-purpose resource paging solution that could help this, which is what I'd recommend. It may be some time before Google Code's Issue Tracker becomes OSLC-compliant but it may be that someone can easily put an OSLC fascade onto using one of API's that are available.

To be clear, this is only exploring how any some tools may expose their capabilities. It does not imply that oslc:ServiceProvider represents a product or a projects. Clients should only interpret these constructs as a way a tool has exposed a path to the oslc:ServiceProvider. Often the client is driven by a end user who will be presented with choices to select the appropriate one based on their understanding of the current application and with which they are integrating.

The "O" in OSLC

2011-02-23T18:08:00.000-08:00

is for Open, I think we all know that. Though what is really unique and special about OSLC is the many ways it is open. Not just that fact it is on a public website for people to see or that the integration style opens up your data, it covers many dimensions. Let's take a close look how OSLC is open:

Open participation model
Anyone who wants to join in can do so and contributions are made under the Creative Common Attribution License.

Open and free use of specifications
Each of the working groups adheres to an intellectual property covenant, allowing implementers the ability to freely implement the specifications without fear of licensing fees.

Open community
If you are motivated to make a change and have the time, you are encouraged to join the community. Contributions to improve lifecycle tools interoperability can be accomplished in many ways: scenario development and review, specification development, researching solutions, reviewing specifications, doing implementations, providing implementation reports and on and on.

Open collaboration
Collaboration occurs in the open at http://open-services.net in the form of updates to wiki pages, mailing lists and regular conference calls. If you can't make a meeting, minutes are posted (as good as they are taken) and community members can review at their leisure. When the communications and collaborations don't work for a given working group, changes are proposed and enacted.

Open services
After all that is what the S stands for. Though there is more to it than putting the two words "open" and "services" together. Its about defining consistent patterns, guidance and specifications for achieving the common goal of interoperability between lifecycle tools. The architectural principles for these services is based on HTTP REST and user interface patterns supporting loosely coupled integrations. Since these services don't rely on any particular programming language or frameworks, it allows greater possibility for all tool vendors to implement.

Opening up data
...and their relationships. As important is the lifecycle data is the relationships (links) defined in that data. This has been the foundation and basis for most scenarios that drive our efforts. Therefore it is natural that a way to expose this data and their relationships (links), that follows in the approach outlined by W3C and Tim Berners-Lee as "Linked Data". As we continue to open up the data traditionally closed in lifecycle tools, we see that we can achieve new levels of interoperability using linked lifecycle data.

Open possibilities
We continue to find new and innovative ways to leverage the open linked lifecycle data. We see this in the evolving work done to support scenarios in: PLM/ALM, DevOps, model management, to name a few. It clear though that OSLC is real, adoption continues to grow and end-users (who may not even know they are using OSLC) are getting real value: this will continue for years to come.

OSLC Change Management 2.0 Specification is now Final!

2010-11-23T07:41:00.000-08:00

Looking back, I see that I blogged on June 19, 2009 that the CM 1.0 Specification has reached finalization. A lot of good hard work has occurred between now and then. There has been a strong focus on alignment across the various domains and applying what has been done and learned in 1.0 specification to define what is now know was OSLC Change Management 2.0 Specification.

First I want to say thanks to the many contributors of the 2.0 CM specification, obviously without their dedication and work to this effort I would not be able to announce it today. Contribution comes in many forms: scenario development, feedback, specification writing, contributions to specification text, implementation feedback, spec issue tracking and on and on.

So, what's new about CM 2.0? I will only summarize some of the key items and will provide a more detailed writeup later.

Alignment - now all domain specification are based off the same OSLC Core specification. Most of these areas have enhancements over CM 1.0.
This covers areas such as:

Service discovery
RESTful resource interactions
Simple query syntax
UI Delegation
Resource formats

UI Preview - the ability for getting a minimal rendering of a resource that can be displayed as a tooltip or hover.
Expanded ChangeRequest resource definition - many new properties defined, supporting new scenarios as well as commonly used across most CM providers
Resource Shapes -For creation, for query and for update.
Depreciation of resource-specific content types - focus more on leveraging standard content types

I look forward to more CM 2.0 implementation reports and what lies next for CM domain.

OSLC Open Source Proposal

2010-11-17T05:26:00.000-08:00

Some OSLC community members are drafting a proposal for a companion open source project in support of the OSLC specification efforts occurring at http://open-services.net.

The OSLC Open Source Project is planned to be hosted at SourceForge.net and possibly include:

test suites for testing OSLC service provider implementations *** initial contribution planned by IBM
reference implementations of OSLC core and domain services for use in testing OSLC clients *** contribution planned by IBM
sample code and applications *** contribution planned by IBM
tools, models, pictures, etc. used in the specification process
specification artifacts that need to be under version control (e.g. namespace documents)

The proposal and project are going to defined and maintained by a core set of committers as defined in the proposal.

This project will look to align with other appropriate open source projects such as Eclipse, Apache, etc if and when needed. The focus of this OSLC open source project is narrowly on specification and implementation validation.

Please respond to this email thread or reply to this posting.

Getting into Shapes: OSLC 3 step program

2010-10-12T12:31:00.000-07:00

There have been many scenarios since the inception of OSLC that have hinted at various needs around the ability to describe resources either that exist or don't, or if you do exist, there are many of them that are similar. So looks take a look at what drove OSLC specification to create the concept of Resource Shapes to support these scenarios and what these Shapes look like.

Creation
Perhaps the most commonly requested scenario that supports the need for Shapes. Resource creation can also be accomplished by leveraging delegated Web UIs that hide the complexity of rules for submission for a successful resource creation. This supports programmatic creation of resources driven by processes that run and create resources, like monitoring applications and finding problems, then automatically logging them.
Shape location: within service provider definition of the creation factory.

Query
Often is the case that we need to find something. We can always navigate from a hierarchy of folders into subfolders or using tags, though this only gets us so far. Many of the services that are exposed have differing data models and these need to be exposed to support a meaningful query. Intelligent query builders can be written and used, select what the criteria to search on and to define what resources and properties to deliver in the response.
Shape location: within service provider definition of the query capability.

Modify
For any resource in hand (or the URI for the resource and a representation of it), we'd like to know what are the allowed properties and property values. Though in open systems, the shape associated with a given resource could change over time, depend on some values of properties or even based on which user is currently accessing the resource and its shape.
Shape location: property oslc:instanceShape on subject resource.

If you look hard in other places, you see Shapes referenced from Shapes and you can see Shapes also can be useful for some other purposes. For example, the Shape associated with the Modify scenario could be used to build a simple resource viewer based on value types and number of occurrences of some properties.

The current model for Resource Shapes continues down the model we've been follow at OSLC, just enough specification to support our scenarios. The shapes provide some key capabilities for describing resources: allow properties, the number of them, any range restrictions, required-ness, readonly-ness, allow values and so on. Implementations are started to surface that support these scenarios and we look forward to getting feedback on this support.

Resource creation: keep it simple for integrations sake

2010-07-22T05:46:00.000-07:00

Often the case when working with tool providers in exposing their capabilities via OSLC, the discussion always ends up on how to deal with all the complexities of that system. There are rules for what is a valid change request properties needed for submissions like: required headline, required found in component (which in turn may require additional fields), etc, etc, etc. My advice is for exposing these constraints and rules, especially from an integration interface protocol like OSLC, is to shield these complexities. I am not advocating that these tool provider relax these submission rules or come up with a new way to create change requests from integration APIs (well maybe I am in a way). In OSLC, there is a concept of creation factories which provide consumers with a URI in which to POST some content to create a new resource. These factories could be based on a concept such as a creation template or a reference change request. A creation template would be basically a blueprint or sample of what to pre-fill all the properties in a change request if the POST request has some missing pieces. A reference change request would be an existing change request in the change management tool that is duplicated (aka copied) into a new change request and properties from the POST will override the copied fields. Most common CM tools have both these capabilities but have not seen too many of them leverage these for a more simplified creation factory to make the job a little easier for integrating clients to not have to learn more about the CM tools submission constraints. Be interested to hear if anyone has explored these options and their findings.

To add to this, when service providers advertise their support for creation factories they can associate additional meaning to them and there can be multiple creation factories per configuration context (service provider resource). For example, a service provider could indicate which factory is the default one to use, define the rdf:type of resource created from the factory, link to an associated shape definition and other informative pieces such as the intended usage (defects, comments, etc).

Think Link, not Sync when doing tool integrations

2010-06-24T05:52:00.000-07:00

Often when working with ALM tool development teams, partners and customers there is a need to go through an evolutionary re-thinking of how tool interoperability should work. Often the time when discussing how OSLC can help them, it often starts as a discussion how they can throw out their current 10's of product specific connectors to have a single OSLC API to synchronize data with their tool. Though there are cases where pulling data, not bi-directional synchronization, has value for purposes of efficient data warehouse access for reporting solutions. I challenge these tool integrators and vendors to re-think their integrations to instead provide "just enough" information about the other tool being integrated with. This "just enough" could be as simple as two things: 1) a link to resource owned by another tool and 2) knowing the semantics of that link (OSLC).

There are many advantages of leaving the data within that tool that owns it and providing a link to it:

The tool that owns it knows best the rules to govern changes to it, including auditing support
The tool that owns it, knows best how to control access to data. By copying the data, often access controls needs to be replicated as well (as best possible)
State-models of resources across tools often don't align
There are ways to expose this data in other tools, without replicating it

It is sometimes convenient to have a cloned/cached copy of data in a local tool, OSLC does not prohibit it this and can support this.

Update: Also see interesting and related IBM DeveloperWorks article "Stop copying, start linking"

OSLC reference implementations and test suites

2010-06-16T05:46:00.000-07:00

There have been a number of implementation efforts underway for various OSLC specifications.
I've heard many requirements including...

for Service Providers:

A hosted reference implementation that can react to client consumer requests, to ensure consistent behavior across implementations
Make the source code available for download
Allow contributions to the source
The language it is written in is less important, though some tend towards JEE based
A client testsuite that can give level
Samples that highlight key integration scenarios
A framework in which to quickly enable new implementations

for Consumers:

A hosted reference implementation that can react to client consumer requests
A reference service provider that can provide feedback on consumer implementations (testsuite)
Provide a variety of samples
Java client samples and/or SDK
Command-line or Perl based samples and/or SDK
HTML/Javascript samples and/or SDK

Some current efforts underway:

Some thoughts on technology basis for service provider reference implementation:

Apache Wink - REST framework
Jena
- RDF/XML, Turtle parsers and generators
- Apply custom rules for RDF/XML and Turtle
- Add JSON support
- Simple storage
- Extended to support ResourceShapes
- Query - mapping of query syntax - oslc.where/select
- Resource subsets - oslc.properties
OAuth - Provider only
(need good consumer example)
Service Discovery
- Various models combinations of Catalogs and ServiceProviders
Web UI
- Simple example/demo HTML/JS
- Prefill
- Via a draft resource creation
- Via direct prefill and redirect
- UI Preview

Dave Johnson posted some thoughts as well here. Which are fairly close to this as well.

Feedback and additional requirements as needed.

CM 1.0 Simple Query Syntax, how we got here

2010-02-03T05:32:00.001-08:00

Often I get asked about what how it was decided what was included into the CM 1.0 Simple Query Syntax, so I figured I'd take a couple of minutes to summarize some key points. The goals for the 1.0 were quite simple: produce a simple syntax that supports our scenarios and that will work with SQL and SPARQL based back-ends. One of the most obvious omissions from the query syntax is the "or " operator, or UNION if you are from SPARQL. This was intentional since the CM WG realized that all scenarios could be accomplished by having support for the "in" operator. By doing this, we avoided the complexity of having to support grouping of terms with parenthesis.

The type of query we saw as being key to support in 1.0 were queries such as: Show me all open change requests assigned to a specific user
?oslc_cm.query= owner="bob" and status in ["submitted","working"]

Beyond that, most other operators are quite common. Another primary scenario was the ability to retrieve a set of change requests that have been modified since a given date. Which is supported by both having the Dublin Core usage of dc:modified and comparison operators such as:
?oslc_cm.query=dc:modified>="12-02-2008T18:42:30"

This has been proven to be very powerful and easy to map to service provider search capabilities. At some point there may need to be support for a full query syntax service, which could be a unique URL end point to post a query to. We'll have to wait and see how this plays out over time.

Using Selective Properties (aka Partial Fetch)

2010-02-01T04:40:00.000-08:00

Often is an issue when working with retrieving resources and their properties is getting the desired information efficiently. By definition of the CM 1.0 specification, when requesting a change request resource without any parameters to refine the list of properties you should retrieve ALL properties that resource has. Take for example this simple request:

GET http://example.com/bugs/2314
Accept: application/x-oslc-cm-change-request+xml

This will result in the change request identified by the URL to be retrieved:


<oslc_cm:ChangeRequest 
  rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
  dc="http://purl.org/dc/terms/" 
  oslc_cm="http://open-services.net/xmlns/cm/1.0/"
  xmlns="http://myserver/xmlns"
  about="http://example.com/bugs/2314">

  <dc:title> Provide import </dc:title>
  <dc:identifier> 2314 </dc:identifier>
  <dc:type> http://myserver/mycmapp/types/Enhancement </dc:type>
  <dc:description>
    Implement the system's import capabilities.
  </dc:description>
  <dc:subject> import, blocker </dc:subject>
  <dc:creator resource="http://example.com/users/aadams" />
  <dc:modified> 2008-09-16T08:42:11.265Z </dc:modified>
  <owner resource="http://example.com/users/john">
  <priority>High</priority>
  <severity>High</severity>
  <status>Working</status>
</oslc_cm:ChangeRequest>

This is useful when a consumer doesn't know which properties to request but can provide more information than is needed (both that the provider needs to generate and the consumer needs to process). To limit the amount of properties returned, the concept of selective properties can be used. If the consumer is only interested in the owner and the status, the request could be formulated such as:

GET http://example.com/bugs/2314?oslc_cm.properties=owner,status
Accept: application/x-oslc-cm-change-request+xml

Resulting in:


<oslc_cm:ChangeRequest 
  dc="http://purl.org/dc/terms/"
  oslc_cm="http://open-services.net/xmlns/cm/1.0/"
  xmlns="http://myserver/xmlns"
  about="http://example.com/bugs/2314">

  <owner resource="http://example.com/users/john" />
  <status>Working</status>
</oslc_cm:ChangeRequest>

Perhaps we are interested in the owner's name and email address, we can expand the owner entry and select only those properties to be returned such as:

GET http://example.com/bugs/2314?oslc_cm.properties=owner{fullname,email},status
Accept: application/x-oslc-cm-change-request+xml

Resulting in:


<oslc_cm:ChangeRequest 
  rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
  dc="http://purl.org/dc/terms/"
  oslc_cm="http://open-services.net/xmlns/cm/1.0/"
  xmlns="http://myserver/xmlns"
  about="http://example.com/bugs/2314">

  <owner>
    <User rdf:about="http://example.com/users/john">
      <fullname>John Doe</fullname>
      <email>jdoe@myco</email>
    </User>
  <status>Working</status>
</oslc_cm:ChangeRequest>

This technique is used in CM 1.0 not only for selective retrieval of properties on a change request resource, it is used for partial updates of resources as well as controlling the content on query responses.

OSLC in the wild

2009-10-22T08:40:00.000-07:00

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

2009-09-11T08:24:00.000-07:00

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

2009-08-24T12:47:00.001-07:00

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

2009-07-13T05:39:00.000-07:00

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

2009-06-26T11:42:00.000-07:00

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:

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

2009-06-22T16:44:00.001-07:00

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

2009-06-19T05:39:00.000-07:00

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

2009-06-18T13:44:00.000-07:00

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