OSLC CM Implementation Reports
Implementors of the OSLC CM 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.
Contact information:
Details about support:
- Specification version supported: OSLC CM 1.0
- Implemenation supported: service provider
- Detailed information: ClearQuest REST API
- Subset of specs supported and why:
- prefill of submission dialog not supported, fix planned
- exploratory support of "ChangeRequest" resource. CQ has a very flexible model and no transformation framework. We provided an experimental XSL backend that allows this to work
- Deviations from specs and why:
- don't fully support oslc_cm:collref as spec'd: missed during testing, will fix in upcoming fixpack
Issues:
- Consumers had issues with relative paths in service description document
Worked well:
- Consistent JSON/XML formats
- Consumers have found inlined properties to be very useful to limit the number of requests they need to make
- Service Discovery
- Delegated Web UIs work very well. Supporting the window.name IFrame protocol is tricky, but necessary for older browser support. Maybe we need a consumable Javascript library (that doesn't require Dojo) which hides some of the messy details from OSLC consumers.
- Sample application showing the integration early on worked well
Contact information:
Details about support:
- Specification version supported: OSLC CM 1.0
- Implemenation supported: consumer of ClearQuest? OSLC api
- ...
Issues:
- Need ServiceDescriptor? to contain additional element describing the request path for a change request given its identifier. This could eliminate problems when the repository location changes domains. I.e. if the domain changes, clients only need to update info from the service descriptor without need to update stale data in cached change requests themselves.
- Need clarification on rdf:about vs rdf:resource attribute usage in ChangeRequest? (which is correct?)
- Example response documents for a Simple Query would be useful
Worked well:
- Service discovery to easily guide user through repository selection
- Service discovery of available services for programatic access
- OSLC simple query support
- ...
Contact information:
Details about support:
Issues:
- ATOM format for result sets questionable. It is expensive to generate because it requires additional information that is not automatically part of the result set (and in most cases is not needed by clients anyway). Most of our clients clearly prefer the simple xml and json formats.
Worked well:
- Selective and inlined properties: you can get exactly what you need.
- Support for simple to use JSON format.
Contact information:
Details about support:
- Specification version supported: OSLC CM 1.0
- Implemenation supported: consumer
Issues:
- No recommended or suggested specification for establishing back link
Worked well:
Well, this is not yet a real OSLC-CM server, as it's only a protoype and lacks many features, but we hope it could be covering the whole of OSLC-CM V1 some day (when its 1.0 version will be released).
Still, it may help test client tools. More details at :
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web
Sorry, not following the template, as it's not really a real implementation so far. --
OlivierBerger - 02 Dec 2009
Contact information:
Details about support:
- Target Specification version to be supported: OSLC CM 1.0
- Implemenation supported: provider
Issues:
- Not yet complete OSLC-CM V1 : work in progress
Worked well:
Contact information:
Details about support:
- Target Specification version to be supported: OSLC CM 1.0
- Implemenation supported: provider
Issues:
- So many namespaces!
- So many ways to get a URL (rdf:about, oslc_cm:resource, atom links).
- Unlike a more traditional, procedural API, it's hard to know what OSLC even does from the spec, which is about REST style resources more than operations. A quick high-level summary of all the supported operations (ad-hoc query, modify CR, etc.) and pointers to the relevant details in the spec could make it faster to understand
- Multiple return formats (JSON, XML) were easy enough to implement, but make for somewhat tedious testing. I can see how both formats are useful to different consumers though. Not a big deal.
- No standard test suite means I don't really know if my implementation is "done" or correct. I essentially used RQM as a client as the de facto test suite, though it doesn't provide complete coverage of everything in OSLC. This was my biggest issue.
- URLs seem awfully fragile since they capture the hostname and port of the Change server at the time the request was made. Customers often upgrade and rename hardware, meaning any URLs stored in, say, RQM will go rancid on us.
- Lots of missing stuff (obviously): getting a list of possible properties, required properties, handling attachments, etc.
Worked well:
- Basic-auth made for an easy authentication scheme.
- Atom doesn't seem like a very convenient wrapper format, but it's nice that IE and Firefox both know how to display. It's easier to debug a query that way or explain OSLC to someone when there's something a little more tangible to see than just XML.
- OSLC happened to map pretty closely to how Change already works. Coincidence or an artifact of careful planning and a relatively small set of operations in 1.0?
<Implementor> (copy and update template)
Contact information:
- Reported by...
- This capability was implemented in...
Details about support:
- Specification version supported: OSLC CM 1.0
- Implemenation supported: <consumer and/or service provider>
- Subset of specs supported and why:
- Deviations from specs and why:
Issues:
- <issues>
Worked well: