History   View   Links to this page 2012 August 29 | 02:21 pm

Contents

Automation Type Issue

This wiki is to discuss the potential requirement for an automation type or sub-domain attribute. The requirement revolves around the need for consumers to be able to determine a the type of automation a provider exposes services for. Possible types or sub-domains currently being discussed are build, test and deploy. This wiki presents two scenarios as well as two proposed approaches.

Scenarios

Consumer choice of Delegated UIs

A test management tool is a consumer of both build automation and deployment automation. The tool allows a build to be chosen from a build provider using a delegated selection dialog and then allows creation of an automation request for a build provider using a delegated creation dialg to set up a test environment using the chosen build. To present the correct selection/dialogs in the correct contexts in the test tools requires some knowledge of which service providers can show build results and which service providers accept deployment requests.

Administrative association of an automation service provider

A tool is only interested in consuming a particular type of automation (e.g. build). Configuring it to be a consumer of any other type of automation is not useful to the consumer. The consumer needs the service provider description to contain an indication of what type of automation it provides to avoid an invalid or un-useful configuration.

Proposals

The following proposals involve the use of some new URIs defined in the automation specification to identify automation subdomains. Proposed URIs are

  • http://open-services.net/ns/auto#Build: Indicates that the related service provider or services provide build automation capabilities - the process of converting source code artifacts into software artifacts such as executables, libraries and documentation.
  • http://open-services.net/ns/auto#Test: Indicates that the related service provider or services provide test automation capabilities - the process of executing tests on a system under test and comparing the results of the tests to pass/fail conditions.
  • http://open-services.net/ns/auto#Deploy: Indicates that the related service provider or services provide deployment capabilities - the process of executing processes and procedures to ready systems and software for use.

Proposal 1: Use oslc:usage in the service descriptions

oslc:usage is a zero-or-many attribute on Creation Factories, Query Capabilities and Selection/Creation Dialogs. It is intended for domains to use to identify services and how they are to be used. In this proposal service providers for particular sub-domains could identify the types of services provided by including oslc:usage in the service descriptor. Example:

<ServiceProviderCatalog>

  <oslc:serviceProvider>
      <oslc:ServiceProvider>
         <service>
           <Service>
               <creationFactory rdf:resource="..."/>
                  <oslc:CreationFactory>
                     <oslc:usage rdf:resource="http://open-services.net/ns/core#default" />
                     <oslc:usage rdf:resource="http://open-services.net/ns/auto#Build" />
                     ...
                  </oslcCreationFactory>
               </oslc:creationFactory>
               <queryCapability rdf:resource="..."/>      with oslc:usage as above
               <selectionDialog rdf:resource="..."/>       with oslc:usage as above
               <creationDialog rdf:resource="..."/>        with oslc:usage as above
           </Service>
         </service>
         <service>
           <Service>
               <creationFactory rdf:resource="..."/>
                  <oslc:CreationFactory>
                     <oslc:usage rdf:resource="http://open-services.net/ns/core#default" />
                     <oslc:usage rdf:resource="http://open-services.net/ns/auto#Depoloy" />
                     ...
                  </oslcCreationFactory>
               </oslc:creationFactory>
               <queryCapability rdf:resource="..."/>      with oslc:usage as above
               <selectionDialog rdf:resource="..."/>       with oslc:usage as above
               <creationDialog rdf:resource="..."/>        with oslc:usage as above
           </Service>
         </service>
      </oslc:ServiceProvider>
  <oslc:serviceProvider>

</ServiceProviderCatalog>

Proposal 2: Extend oslc:domain with sub-domain URIs

This proposal also uses the URIs defined above, but uses the oslc:domain attribute on the Service Provider Catalog and Service resources to identify the provider type or sub-domain. The description of oslc:domain is flexible enough to allow this, but this usage would be novel. Example:

<ServiceProviderCatalog>

  <oslc:domain rdf:resource="http://open-services.net/ns/auto#Test" />
  <oslc:domain rdf:resource="http://open-services.net/ns/auto#Deploy" />

  <oslc:serviceProvider>
    <oslc:ServiceProvider>
      <service>
        <Service>
            <oslc:domain rdf:resource="http://open-services.net/ns/auto#Test" />
            <creationFactory rdf:resource="..."/>
            <queryCapability rdf:resource="..."/>
            <selectionDialog rdf:resource="..."/>
            <creationDialog rdf:resource="..."/>
        </Service>
      </service>
      <service>
        <Service>
            <oslc:domain rdf:resource="http://open-services.net/ns/auto#Deploy" />
            <creationFactory rdf:resource="..."/>
            <queryCapability rdf:resource="..."/>
            <selectionDialog rdf:resource="..."/>
            <creationDialog rdf:resource="..."/>
        </Service>
      </service>
    </oslc:ServiceProvider>
  <oslc:serviceProvider>

</ServiceProviderCatalog>

Proposal 3: Use dcterms:subject with sub-domain URIs

This proposal also uses the URIs defined above, but uses the dcterms:subject attribute on the Service Provider Catalog and Service resources to identify the provider type or sub-domain. The description of dcterms:subject is flexible enough to allow this, and this usage is very much in line with the property’s intent. It can, in fact, be used alongside either or both of the first two proposals.

Example:

<ServiceProviderCatalog>

  <dcterms:subject rdf:resource="http://open-services.net/ns/auto#Test" />
  <dcterms:subject rdf:resource="http://open-services.net/ns/auto#Deploy" />
  <oslc:domain rdf:resource="http://open-services.net/ns/auto" />
  <oslc:domain rdf:resource="http://open-services.net/ns/auto" />

  <oslc:serviceProvider>
    <oslc:ServiceProvider>
       <service>
         <Service>
             <oslc:domain rdf:resource="http://open-services.net/ns/auto" />
             <dcterms:subject rdf:resource="http://open-services.net/ns/auto#Test" />
             <creationFactory rdf:resource="..."/>
             <queryCapability rdf:resource="..."/>
             <selectionDialog rdf:resource="..."/>
             <creationDialog rdf:resource="..."/>
         </Service>
       </service>
       <service>
         <Service>
             <oslc:domain rdf:resource="http://open-services.net/ns/auto" />
             <dcterms:subject rdf:resource="http://open-services.net/ns/auto#Deploy" />
             <creationFactory rdf:resource="..."/>
             <queryCapability rdf:resource="..."/>
             <selectionDialog rdf:resource="..."/>
             <creationDialog rdf:resource="..."/>
         </Service>
       </service>
    </oslc:ServiceProvider>
  <oslc:serviceProvider>

</ServiceProviderCatalog>