OSLC QM Implementation Reports

Implementors of the OSLC QM specifications are encouraged to place feedback on their experience (good and bad). To add a report, simply copy and paste a section template and fill out any necessary information.

OSLC QM 2.0

This section gathers implementation reports for OSLC QM 2.0

Providers

Rational Quality Manager

Contact information:

• PaulMcMahan
• Rational Quality Manager 3.0
• Date of report: Jan 10, 2011
• Date of availability: Jun 2011

Details about support:

• Specification version supported: OSLC QM 2.0
• Implementation supported: service provider

Additional details about support: (not noted in table)

• Subset of specs supported and why:
  • spec is fully supported
• Deviations from specs and why:
  • none

Issues:

1. A common TCK would have been helpful
2. Reifications for link labels was tricky to implement

Worked well:

• Backwards compatibility with QM 1.0 spec
• RDF format can be generated well be jena library

Consumers

<2.0 template>

<Implementer> (copy and update template)

Contact information:

• Reported by...
• This capability was implemented in...
• Date of report:
• Date of availability: (indicate if estimated)

Details about support:

• Specification version supported: OSLC QM 2.0
• Implementation supported: <consumer> and/or <service provider>
• (if consumer, please add....)
  • OSLC QM 2.0 Providers tested with:
    • (list out providers)

Additional details about support: (not noted in table)

• Subset of specs supported and why:
  • ...
• Deviations from specs and why:
  • ...

Issues:

1. <issues>

Worked well:

• <good things>

OSLC QM 1.0

This section gathers implementation reports for OSLC QM 1.0

Providers

Rational Quality Manager (RQM) 2.0.1

Contact information:

• Reported by PaulMcMahan
• This capability was implemented in Rational Quality Manager (RQM) 2.0.1 to provide integration points for Requirement and Change Management applications

Details about support:

• Specification version supported: OSLC QM 1.0
• Implemenation supported: service provider

Issues:

• Support for pre-populated creation dialog was difficult to implement due to the fact that the same URL must support both POST and GET. Clients that POST are expecting a redirect and clients the GET are expecting the dialog content right away. I ended up having to provide a separate creation dialog URL for POST support since it is difficult for clients to handle the redirect without losing the window name and window hash used for messaging.
• Combining the result set of a property based query with a full text query, and then providing paging on top of that result proved to be problematic.
• Spec versioning is not supported well. For GET requests the spec version is indicated in the Accept header which is awkward and seems a bit kludgy.

Worked well:

• Simple resource XML format
• Familiar REST API pattern
• Service description documents provide needed flexibility and allows URLs to be handled opaquely by the client
• Delegated resource selection and creation for integrating across systems has many advantages over the traditional copy/synch or monolithic database approach

<Implementor> (copy and update template)

Contact information:

• Reported by...
• This capability was implemented in...

Details about support:

• Specification version supported: OSLC QM 1.0
• Implemenation supported: <consumer and/or service provider>
• Subset of specs supported and why:
  • ...
• Deviations from specs and why:
  • ...

Issues:

1. <issues>

Worked well:

• <good things>