JBoss Community Archive (Read Only)

RHQ 4.9

Relationship services

RHQ currently has a strictly hierarchical parent-child relationship model. This design is to enhance this model to allow additional types of inventory relationships to be stored and modeled. These relationships will be specific to the resources implementing them and therefore need to be customizable, but there are some higher level relationship concepts that this system should allow the developer to adhere to for potential abstract coordination. Additionally, some dependencies will be between resources from different plugins and those would need to be of a more abstract form.

E.g. JMS Queues can utilized Datasource resources as their persistence system. A specific dependency type can be built that combines the types and the dependency into a three part system, source, dependency types and destination. This example would be "JMS Queue X" "Persists Via" "Datasource Y". This defines a specific dependency that can go from one type to another with some attached metadata.

Requirements

  • Relationships types defined by plugin developers

  • Relationships between resources may be defined during the discovery process and/or added/updated later by plugin component

  • Relationships may be alterable by server-side APIs for informational relationships

  • Permissions system for relationships respects basic resource RBAC

High Level Design

Dependency Definition:

  • Source Type

  • Source Cardinality

  • Name

  • Type (enum { dependency, composition, association, generalization })

  • Target Type

  • Target Cardinality

Some relationships, especially those within a single plugin would be quite feasibly discovered by the plugin though it may be somewhat complex for that information to be easily exposed to the core inventory model. Other types of dependencies would be higher or system dependencies created and managed through the UI or APIs.

Entities:

Table: RHQ_RELATIONSHIP_DEF

Column

Type

FK

Notes

Changable?

ID

number

 

surrogate key

No

PLUGIN

varchar 100

 

Composite key along with name. Unique per plugin.

No

NAME

varchar 255

 

Composite key

Yes

CARDINALITY

number

 

enum {one:one, one:many, many:many}

Yes

SOURCE_TYPE_ID

number

rhq_resource_type:id

The unique ID of the source resource type

No

TARGET_TYPE_ID

number

rhq_resource_type:id

The unique ID of the target resource type

No

SOURCE_CONSTRAINT

number

 

enum { CASCADE_DELETE, NONE }

Yes

TYPE

VARCHAR 50

 

Relationship concept type: { dependency, composition, association, generalization }

Yes

USER_EDITABLE

boolean

 

Whether the relationships of this type can be edited by the user

Yes

Table: RHQ_RELATIONSHIP_ASSIGN

Column

Type

FK

RELATIONSHIP_TYPE_ID

number

rhq_relationship_def:id

SOURCE_RESOURCE_ID

number

rhq_resource:id

TARGET_RESOURCE_ID

number

rhq_resource:id

CTIME

number

 

MTIME

number

 

Table: RHQ_REL_ASSIGN_HISTORY

Column

Type

FK

RELATIONSHIP_TYPE_ID

number

rhq_relationship_def:id

SOURCE_RESOURCE_ID

number

rhq_resource:id

TARGET_RESOURCE_ID

number

rhq_resource:id

START_TIME

number

 

END_TIME

number

 

Cascading

  • When a relationship definition is deleted, all relationship assignments of the deleted definition should be deleted.

  • When a resource is deleted, all assignments for the deleted resource(both as source or target) should be deleted.

Modifying a Relationship Definition

Modifying a relationship definition is possible but restricted for critical changes such as the resource type IDs,

Allowing changes to the resource type IDs will result orphan relaitonship assignments and other difficulties,

Please see the column "changeable?" on the "RHQ_RELATIONSHIP_DEF" table above whether each column can be modified or not.

This is relevant for both plugin descriptor relationship definitions and API definitions.

[TODO: Describe what happens in case CARDINALITY/TYPE properties change]

Relationship History

  • Any new created relationship assignment will be audited in the relationship history with an assignment start time.

  • Any modified relationship assignment will be audited with the new assignment values, an 'end time' assignment will be modified to the current
    relationship assignment entry.

[TODO: Define how to audit a removed assignment]

Security

The user must be authorized to load resources on both sides of the relationship otherwise an Access denied exception should occur,

The user must have the 'relationship' permission to add/modify relationships.

Authorization process should be applied to any API calls.

Deployment

Relationships will /not/ be fail-fast.

If one plugin or a resource type is missing for some relationship definition then deployment process will continue and plugins will still be deployed but the failed relationship will not be be available creation.  

An error should be reported in case of a wrong relationship definition recognition.

Example Plugin XML

Intra-plugin relationship

<relationships>
  <relationship name="Persists On">
    <source type="JMQ JMS Queue" cardinality="one" unique="true"/>
    <target type="Datasource" cardinality="one"/>
  </relationship>
<relationships>

Inter-plugin relationship

<relationships>
  <relationship name="Utilizes" userEditable="true">
    <source type="Stateless Session Bean" plugin="JBossAS" cardinality="one" unique="true"/>
    <target type="*" cardinality="many"/>
  </relationship>
<relationships>

Defining relationships definitions via API calls

Sometimes it is required to define new relationships via API calls, in cases where the relationships are not known ahead,

This might happen in situations when a relationship definition is based on some logic and should be defined during an evlauation of a process.

The relationship service exposes all the APIs to define and manage relationship definitions. (Please see "APIs" section below)

API:

Relationship APIs

Well modeled dependencies would allow for modeling failure scenarios (e.g. App X depends on web service Y so when that web service goes down we can alert that a dependency is broken and probably App X is not fully working).

Additionally this relationship information can be used to track important business information. For example, a cluster in staging is related to the production cluster for the same application. Tying them together could make it easier to know that they should be compared during production pushes.

Method

Description

Set<Relationship> findRelationshipsByResource(Subject, Resource)

Look up the currently known relationships for a resource

Set<Relationship> findRelationshipsByResources(Subject, Resource, Resource)

Look up the currently known relationships between two resources

Set<Relationship> findRelationshipsByCriteria(Subject, RelationshipCriteria)

Find relationships by search criteria

void addRelationship(Subject, Relationship)

 

void removeRelationship(Subject, Relationship)

 

void updateRelationship(Subject, Relationship)

 

Relationship Definitions APIs

Method

Description

RelationshipDefinition findRelationshipDefinitionById (Subject, Long resourceDefinitionId)

Find a relationship definition by Id

RelationshipDefinition findRelationshipDefinitionByName (Subject, String name)

Find a relationship definition by name

Set<RelationshipDefinition> findRelationshipDefinitionsByCriteria(Subject, RelationshipDefinitionsCriteria)

Find relationship definitions by search criteria

void addRelationshipDefinition(Subject, RelationshipDefinition)

Persist a new relationship definition

void modifyRelationshipDefinition(Subject, RelationshipDefinition)

Update a relationship definition, an exception occurs in case restricted properties are modified.

void removeRelationshipDefinition(Subject, RelationshipDefinition)

Remove a relationship definition including all relationship assignments of the deleted relationship definition

Use cases

Plugin Modeling of Dependencies

  • Can detect local (single agent) resource relationships

  • (Possible to detect between plugins?) Probably don't have the inventory APIs necessary

  • Perhaps limit to parent-child hierarchy?

User Modeling of Dependencies

  • A user wants to declare that this app is dependent on a database on another box. As a dependency-type relationship, if the database is down, the app will show up as degraded in the UI.

ServerSide Plugin Modeling of Dependencies

  • Could be used to create and maintain general resource relationships. Listen for resource inventory events and track changes. Use server-side logic to model network relationships.

  • Could be specific to a plugin type... e.g. tracking and modeling app server "clusters" across agents

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-13 08:15:10 UTC, last content change 2013-09-18 19:41:10 UTC.