Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "COSMOS Design 224166"
Line 61: | Line 61: | ||
|MDR | |MDR | ||
|Management Data Repository | |Management Data Repository | ||
− | } | + | |} |
== Purpose == | == Purpose == |
Revision as of 17:37, 21 May 2008
Contents
Improve the Graph Response Viewer
Change History
Name: | Date: | Revised Sections: |
---|---|---|
Ali Mehregani | 05/21/2008 |
|
Workload Estimation
Process | Sizing | Names of people doing the work |
---|---|---|
Design | .5 | Ali Mehregani |
Code | 3.5 | Ali Mehregani |
Test | .5 | Ali Mehregani |
Documentation | 0 | |
Build and infrastructure | 0 | |
Code review, etc.* | 0 | |
TOTAL | 4.5 |
Terminologies/Acronyms
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term regarding how it is used in this document:
Term | Definition |
---|---|
MDR | Management Data Repository |
Purpose
This enhancement is associated with bugzilla 224166.
The purpose of this enhancement is to improve the graph response view displayed when querying an MDR. The view is currently convoluted and difficult to interpret by a novice user. This design document lists a number of changes to improve usability and overall structure of the view.
The image below indicates a number of usability issues with the current view: <p>
</p>
Implementation Detail
This section outlines an alternative layout to address the issues displayed above. The new layout will consist of two parts:
- A graphical view to display a visual overview of the response
- A logical tree structure to traverse through the elements of the response
The layout will consist of three sections, indicated in the image below:
Graphical View
The top most section of the view will consist of a graphical representation of the response. The section will leverage dojox.gfx APIs along with atomic shapes to render a graph. The APIs use SVG in FireFox and VML in IE to render the individual shapes. The end result is a static diagram with cross-browser support.
The image below shows a sample of what the graph will look like:
File:Graph response visual.png
The graph layout algorithm renders adjacent nodes closer to each other. This will visually indicate entities that are closer together in relation. The radius of each node is determined by its order (i.e. outgoing edges from the node). The color scheme is dependent on the template a node belongs to. A legend is displayed at the bottom of the diagram.
Registration
CMDBf specifies a registration service by which MDRs register items and relationships with the federating CMDB. The process for registration involves an XML-based transaction, similar to how the query service works. This enhancement will provide a transformer to convert a registration request from XML to a POJO graph structure, and will also provide the reverse of that transformation. In addition, it will provide another transformer that will convert a registration response output by the MDR from a POJO graph structure to the XML-based syntax expected by the CMDBf spec, and will again provide a reverse of that transformation. The reverse transformations are needed by some clients of the registration service, and also are useful in unit testing of the implementation.
The following new classes will provide these transformations:
org.eclipse.cosmos.dc.cmdbf.services.provisional.registration.transform.RegistrationInputTransformer org.eclipse.cosmos.dc.cmdbf.services.provisional.registration.transform.RegistrationOutputTransformer
The following are the transformation APIs on the RegistrationInputTransformer class:
static public RegisterRequest transform(InputStream) static public InputStream transform(RegisterRequest)
The following are the transformation APIs on the RegistrationOutputTransformer class:
static public RegisterResponse transform(InputStream) static public InputStream transform(RegisterResponse)
RegisterRequest and RegisterResponse POJOs will consist of APIs and classes that match or closely mirror the corresponding element names in the CMDBf data model. RegisterRequest will reside in the org.eclipse.cosmos.dc.cmdbf.services.provisional.registration.transform.input.artifacts package and RegisterResponse will live in the org.eclipse.cosmos.dc.cmdbf.services.provisional.registration.transform.response.artifacts package.
Here is a simple example that illustrates the incoming registration input transformation:
InputStream inputStream = new ByteArrayInputStream(example1().getBytes());
RegisterRequest registerRequest = RegistrationInputTransformer.transform(inputStream);
Assume that example1() returns a String containing the XML syntax for a <registerRequest> as specified in the CMDBf spec.
Services
Query
The class diagram below displays the interfaces and default implementations that will be included for the query service. All that a contributor is required to do is to register the classes that will be used as handlers for the selectors. The default implementation of the CMDBf query operation will look up the appropriate handlers and will invoke them accordingly.
The following is a snippet of code that illustrates how a contributor can register a set of selector handlers with the default implementation of ISelectorHandlerFactory
.:
SelectorHandlerFactory.getInstance().addHandlers
(
new URI ("http://cosmos.org/mdrId"),
ISelectorHandlerFactory.ITEM_TEMPLATE,
new String[]
{
"org.eclipse.cosmos.sample.handlers.InstanceIdHandler",
"org.eclipse.cosmos.sample.handlers.RecordTypeHandler",
"org.eclipse.cosmos.sample.handlers.PropertyValueHandler",
"org.eclipse.cosmos.sample.handlers.XPath1Handler"
}
);
Once the selectors are registered a client can make use of the CMDBf query service using the default implementation of ICMDBfQueryOperation
. The argument passed into the initialize
method represents a data provider that will be passed to each of the selector handlers. The selector handlers can cast the argument to a specific type that can process native queries that is understandable by a specific data provider. The following snippet of code illustrates how the query operation can be invoked:
// Create a CMDBf query operation object and have it initialized CMDBfQueryOperation cmdbfQueryOperation = new CMDBfQueryOperation(); cmdbfQueryOperation.initialize(new SampleDataProvider()); // Execute the query Query query = retrieveQuery(); cmdbfQueryOperation.execute(query);
Assuming retrieveQuery()
will return a POJO representation of a CMDBf query.
Registration
The diagram below shows the relationship between the classes of the registration service. The APIs are very symmetric to the ones provided for the query service. An adopter will need to subscribe register handlers for specific MDR IDs. The subscribed register handlers will be invoked if the MDR ID of the registration request matches that of the ID associated with the handler.
The snippet of code below shows how a client can subscribe a registration handler. CustomRegistrationHandler
is expected to be an implementation of IRegisterHandler
.
RegisterHandlerSubscription.getInstance().addHandler ( new URI("http://cosmos.org/mdrId"), new CustomRegistrationHandler() );
The default implementation of ICMDBfRegistrationOperation
can be used to process a registration request. The snippet below shows how a client can use the operation:
// Perform the initialization CMDBfRegistrationOperation registrationOperation = new CMDBfRegistrationOperation(); registrationOperation.initialize(new SampleDataProvider()); // Execute the operation Registration registration = retrieveRegistration(); registrationOperation.execute(registration);
Assuming retrieveRegistration()
will return a POJO representation of a CMDBf registration request.
Test Coverage
Unit tests will need to perform the following tests:
- Transform a RegisterRequest POJO to XML and back to a POJO, and compare the start and end POJOs
- Transform a RegisterResponse POJO to XML and back to a POJO, and compare the start and end POJOs
- Process an empty query
- Processing a query with just one item
- Processing a query with a relationship and no items
- Processing a query with matching items and an unmatched relationship
- Processing a query with matching items and a matched relationship
- Processing a query with a relationship that has cardinality
- Processing a query with unregistered selector handlers
- Processing an empty registration request
- Processing a registration request with one item
- Processing a registration request with matched items and missing relationship
- Processing a registration request with matched items and a relationship
- Processing a registration request with a relationship and no items
- Processing a registration request with missing registration handlers
Task Breakdown
The following section includes the tasks required to complete this enhancement .
- Refactor plugin, package and class names in cmdbf.query plugin to represent the 5 different jar configurations
- Refactor the JUnits for the query transformation
- Create graph representation of registration request and response
- Create the registration input transformer
- Create the registration output transformer
- Add in JUnits for the registration transformer
- Add in the APIs for processing a CMDBf query
- Implement a generic implementation of the CMDBf query processor
- Add in JUnits for the CMDBf query APIs
- Modify the SML repository to make use of the new API set
- Add in the APIs for processing a CMDBf registration request
- Implement a generic implementation of the CMDBf registration processor
- Add in JUnits for the registration APIs
Open Issues/Questions
All reviewer feedback should go in the Talk page for 204959.