OSLC at Innovate 2011 Conference

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

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

 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!

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

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

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

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