OSLC CM Architectural Direction

Working document - supporting specification development

The purpose of this page is to collect the architectional direction as driven by scenario priorities for the next version of CM specifications (V2). It also contains various 1.0 issues to be addressed in the next version.

Items for consideration for post-1.0

Better handling of differing authenication models
We've run into some issues when clients don't always know when and how to handle form auth, like when using a batch-mode RESTful interface (feed readers, etc).

Alignment of related standards:

• VTODO - need to consider aligning with task management tools?
• OpenSocial - need to evolve our delegated UIs to a widget spec when it is available?
• WSDL 2.0 - RESTful service description

Presentation requirements for resources
Some implementations have assumed different models for what HTML should be returned when requested: should it be contained in an IFrame with just dialog for change request viewing and editing? should it be its own page, with application banner and navigation bar?

Reverse service discovery
Since resources are URL-addressable, they often get pasted into tools without going through service discovery.

A possible solution would be to support requesting the service discovery document an the change request resource URI:

• Performing a HEAD operation on the URI could return at least the CR and service document content types, then consumer would know that the URI is an OSLC one.
• Performing a GET operation on the URI with Accept header being x-oslc-cm-service-description+xml would return the service description document, not the chang request

or by embedding the service discovery doc URL in the change request resource definition

Named/Pre-defined Queries
Most, if not all, CM systems have the ability for a user to create a named query to be accessed later for execution. We could fairly rapidly provide at least read-only access to these and execution of queries.

Delegated Service Discovery
- better handling of configuration data
- better scaling

Reportable REST

Linking issues:
- no good way in C/ALM 1.0 to remove the back link