Revision as of 11:19, 18 May 2009

Resource Handler to check for installed products

This is the design document for bugzilla 275731.

Change History

Workload Estimation

'* - includes other committer work (e.g. check-in, contribution tracking)

Purpose

This enhancement will provide a basic resource handler that can discover if an application as described by the SDD is installed on the system the runtime is interacting with.

Requirements

• The InstalledProductHandler must implement the IResourceHandler from the org.eclipse.cosmos.me.sdd.cr bundle.
  • The IResourceHandler class is an interface that the runtime uses to load and run bundles dynamically. The IResourceHandler uses the CIM QName as defined by the component.xml data for the implemented handler as the way the ResourceHandler will discover and run the bundle.
• The InstalledProductHandler will discover products installed on both Windows and Linux platform types.
• Based on the current CIM profile, the InstalledProductHandler will recognize the following types as defined in the CIM_InstalledProduct schema:
  • CIM_InstalledProduct.ProductName
  • CIM_InstalledProduct.ProductVersion
  • CIM_InstalledProduct.ProductVendor

Design details

• InstalledProductHandler
  • The InstalledProductHandler will be introduced into the "org.eclipse.cosmos.me.sdd.cim.profile" project in eclipse CVS.

 package org.eclipse.cosmos.me.sdd.advisor;
 
 public interface IAdvisor{
 	public Integer requestParameter(IntegerParameterType ipt);
        public String requestParameter(StringParameterType spt);
        public Boolean requestParameter(BooleanParameterType bpt);
        public URI requestParameter(URIParameterType upt);
 
        public String displayMessage(String message);
 }

• • The implementation of the four requestParameter(<>ParameterType parameter) methods will query for the values set for id, value, required, sensitive, defaultValue, and operation as defined by the BaseParameterType and determine what to display to the user. It will then read from System.in and wait for the user to interact with the tool, using return to terminate the input stream. The implementation will then return the value as entered by the user to the calling method, in the object form as defined by the calling method.
  • The implementation of displayMessage will allow other services to call the method in order to provide messages such as status or details about the operation(s) being performed.
  • Validation of ParameterTypes must be handled is handled by the implementation of the requestParameter methods.
  • The first phase of implementation will focus on integrating the CLI into the Orchestrator through method calls in an attempt to flesh out the CLI methods and functions.
  • The second phase of implementation will introduce the concepts of an event bus or listener model that will allow the Orchestrator and the Advisor interfaces to be married in a more dynamic approach.

Impacts of this enhancement

• The SDD runtime will be able to interact with the user via the CLI interface for ParameterType information as defined by the SDD. In response to the user, the runtime will perform resolution with the provided data in order to successfully resolve and operate on a SDD succcessfully. Also, feedback of the resolution and the operation(s) that are performed will be provided to the CLI.

Open Issues/Questions