Contents
This document records Implementation Reports for providers and consumers of the OSLC Automation 2.0 specification.
Providers
Rational Quality Manager 4.0.1
Contact information:
- Contacts: PramodChandoria, PaulMcMahan
- 4.0.1
Details about support:
- OSLC Automation 2.0
- Provides a OSLC Service Provider for the Test Automation subdomain
- Full CRUD, Query, and Resource Shape support
- No UI Preview or Creation / Selection Dialog support at this time
Table of supported capabilities: See Google SpreadSheet
Additional details about support: (not noted in table)
- Supports delegation of Automation Request handling to external consumers
Issues:
- RQM has an existing test execution framework that supports advanced scenarios where test execution is delegated to external agents (aka “execution adapters”). In order to provide a minimal implementation of the Automation V1 specification that can coexist with this existing framework RQM needed to define a provisional type of resource called an AutomationAdapter that is not discussed (at least directly) in the V1 specification. The workgroup might decide to discuss these additional scenarios in a subsequent version of the specification.
Worked well:
- Alignment of the test, build, and deploy scenarios into a common set of resources and state transitions worked out surprisingly well. As more implementations of the V1 spec start to surface it will be interesting to see what other types of scenarios can fit into this pattern as well.
- The specification’s close binding with OSLC Core and the many similarities to the concepts in other domains such as CM, QM, and RM helped implementation go smoothly.
- The availability of open source tooling in Eclipse Lyo was a tremendous help and sped up implementation.
JazzSM
Contact information:
- Contacts: Joe Ross, John Arwe
- 1.1 (GA planned for Q1 2013)
Details about support:
- OSLC Automation 2.0
- Automation provider for synchronous operations on the JazzSM Registry
- Only a creation factory for POST of synchronous Automation Requests is supported. Automation Results are included in the response to the POST. Neither Requests nor Results are persisted, so there is no query capability to retrieve them. Automation Plans are not supported as retrievable resources, they are just URIs used to identify the type of request that is being made.
Table of supported capabilities: See Google SpreadSheet
Additional details about support: (not noted in table)
Issues:
- No significant issues that were not addressed by the spec.
Worked well:
- We were basically looking for an OSLC way to implement remote procedure call, and this fit the bill.
Eclipse Lyo Reference Implementation
Contact information:
- Contacts: Eclipse Lyo (lyo-dev@eclipse.org)
- Product version: N/A - the Lyo OSLC samples are continuously improved and added to.
Details about support:
- OSLC Automation 2.0
- Supports synchronous and asynchronous automation styles
- Includes delegated UIs for selection of Automation Plans and creation of Automation Requests
- Includes HTML representations of resources
- Uses OSLC4J
- Does not currently support OSLC Query
Table of supported capabilities: See Google SpreadSheet
Additional details about support: (not noted in table)
Issues:
- No major issues. This was a “green field” implementation and OSLC4J was well-suited to its development. If anything, OSLC4J is currently lacking in samples and APIs to help build delegated UIs.
Worked well:
- Defining the Java resources for the Automation artifacts was straighforward
- Building the GET, POST, PUT, etc services was simple - follow the examples of other OSLC4J samples
- The provider also acts as a consumer in some cases (resource linking and link validation). The OSLC4J client API was well suited to this.
Tivoli Workload Scheduler
Contact information:
- Contacts: Umberto Caselli, Arcangelo Di Balsamo
- 9.1 (GA scheduled for June 2013)
Details about support:
- OSLC Automation 2.0
- Provides a OSLC Service Provider to schedule the execution of workflows (job streams)
- CRUD and query support
- Provides selection and creation dialogs
- No UI Preview support at this time
Table of supported capabilities: See Google SpreadSheet
Additional details about support: (not noted in table)
- Supports fabrication dialogs (not yet included in the specifications)
Issues:
- None
Worked well:
- The OSLC automation resources have clear mapping to existing Tivoli Workload Scheduler resources.
- The availability of open source tooling in Eclipse Lyo was a tremendous help and sped up implementation.
Rational Test Control Panel / Rational Test Virtualization Server
Contact information:
- Contacts: MartinPain, StephenRowles
- 8.5.0 (June 2013)
Details about support:
- OSLC Automation 2.0
- Provides a OSLC Service Provider for the Deployment Automation subdomain
- Creation dialogs for Automation Requests; selection dialog for Plans and Results; UI preview for Plans and Results.
Table of supported capabilities: See Google SpreadSheet
Additional details about support: (not noted in table)
- Automation Plan query capability returns all Plans - the oslc.where parameter is ignored.
- There is no query capability for Automation Requests.
- Automation Result query capability only supports querying by the oslc_auto:producedByAutomationRequest and oslc_auto:state properties.
- Pre-fill mechanism on Automation Result selection dialog is used to filter which results can be selected. This filter cannot be changed by the user in the UI.
- Single-selection dialogs are identified by an oslc:usage property of value “http://open-services.net/ns/core#Zero-or-one”. Multi-selection dialogs are identified by oslc:usage values of “http://open-services.net/ns/core#Zero-or-many” and “http://open-services.net/ns/auto#list”. In this implementation “http://open-services.net/ns/core#default” is only used on multi-selection dialogs.
- We use an oslc:usage property with value “http://jazz.net/ns/qm/rtcp#ServiceVirtualization” on the oslc:Service or oslc:ServiceProvider resources to indicate that the service provides deployment of Virtual Services. (This is in addition to the “http://open-services.net/ns/auto#Deploy” value on the service.)
Issues:
- [Auto] We needed a way to tear down the virtual services that had been deployed. As OSLC automation v2 has no explicit way to support this, the only way this is achieved in our 8.5.0 implementation is a “stop” button on the UI preview of any running service. (They can also be stopped through our non-OSLC REST interface.)
- [Lyo] Our existing REST implementation (non-OSLC) used the Spring Framework’s web libraries and rest service controllers. It was not trivial to plug OSLC4J into this. The way we achieved this was using a Spring plug-in to bridge with Wink/Jena, writing our own Application class, and writing our own Spring Rest Service Controllers.
- [Core] The OSLC core v2 spec does not state whether selection dialogs should be single-selection or multi-selection. Our reading of the spec was that consumers could reasonably expect multi-selection to be the default. The spec does not include a way to distinguish between the two. While we did not like the idea of writing the implementation for a single consumer, due to time constraints we only provided a single-selection Plan selection dialog and a multi-selection Result selection dialog, as these were what the RQM consumer wanted. Eclipse Lyo had a non-standard http://open-services.net/ns/auto#list oslc:usage value to indicate multi-selection, but as we considered that to be the default, we wanted an explicit single-selection oslc:usage value. So after discussion with the RQM team, we used the core’s Zero-or-one URI as the oslc:usage value on the single-selection dialog, and the Zero-or-many URI as the usage on the multi-selection dialog (along with both http://open-services.net/ns/auto#list and http://open-services.net/ns/auto#list - however, that means that the dialog has multiple oslc:usage properties. While this is in line with the “zero-or-many” ‘occurs’ value for that property in the core spec, consumers may not be expecting it). Raised on oslc-core.
- [Core] There is no explicit support in the OSLC v2 spec for programatically specifying a filter on selection dialogs. e.g, on Automation Request dialogs the consumer may only want them to display the Requests for a given Plans, or on Automation Result dialogs only those for a given request. We applied the pre-fill mechanism from the creation dialogs to the appropriate selection dialogs, but with the changed semantics that this is a filter that the user cannot change, rather than an initial value for a field that the user can change as in the case of creation dialogs.
- [Core] Query capability issues:
- Core spec does not say what error providers should return if it does not support the parameter(s) that were specified (e.g. oslc.where)
- Core spec does not say whether services that accept an oslc.where parameter MUST accept the entire syntax, or MAY return an error for certain parts of the syntax
- Core spec does not say explicitly how to use the oslc:properties parameter for querying
- [Core] When used with the RQM consumer, we ended up with dialog titles being displayed twice - once by the consumer, and once by the provider. There was no guidance on which side was expected to provide the dialog titles.
- [Auto] The OSLC Automation terms “Plans”, “Requests” and “Results” were not suitable for display to users, as they would not be aware of their OSLC meanings. There is no guidance on what wording to use when presenting these to users. The separate sub-domains might have different terminology that is appropriate.
- [Core] When using postMessage protocol for delegated UIs, the RQM consumer was checking the source of the event against iframe.contentWindow. However, I believe our code was executing inside an iframe within our own page (as GWT commonly does), so the source would have been that iframe’s contentWindow. I do not know if there is an easy way to check if the source is the “child of” the consumer’s iframe or not. It might be worth noting this as a potential pain point in the spec.
- Our workaround was to put a method in our top-level window that contained the postmessage call, and have this called by our sub-iframe.
- However, in IE8 we needed to use a setTimeout(…, 0) to make sure the source was set correctly, as is mentioned here: http://www.felocity.com/article/window_postmessage_problems_and_workarounds_for_ie8/
Worked well:
- The use of Jena from Eclipse Lyo/OSLC4J avoided the need for us to write our own de/serialisation mechanism, which was useful.
Consumers
Eclipse Lyo Automation Test Suite
Contact information:
- Contacts: Eclipse Lyo (lyo-dev@eclipse.org)
- Product version: N/A - the Lyo OSLC samples are continuously improved and added to.
Details about support:
- OSLC Automation 2.0
- Tests OSLC V2 Core and Automation MUST requirements
- Tests RDF/XML, XML and JSON representations of:
- ServiceProviderCatalog
- ServiceProvider
- AutomationPlan
- AutomationRequest
- AutomationResult
- Not all Automation MUSTs are covered yet. Development is continuing
Table of supported capabilities: See Google SpreadSheet
Additional details about support: (not noted in table)
Issues:
- No major issues
Worked well:
- Using existing OSLC domain suites as a basis for the new Automation artifacts
- Core tests were automatically covered once Automation was added to DynamicSuiteBuilder.java
Tivoli Workload Scheduler: OSLC Automation job type
Contact information:
- Contacts: Umberto Caselli, Arcangelo Di Balsamo
- 9.1 (GA scheduled for June 2013)
Details about support:
- Supports OSLC Automation v2 providers
Table of supported capabilities: See Google SpreadSheet
Additional details about support: (not noted in table)
- There is a requirement for the fabrication dialog on the provider
Issues:
- No major issues
Worked well:
- The implementation using lyo was very easy.
