Relationships

Node associations are represented by relationships. There are different types of relationships which define hierarchy, hosting, containment, ownership, manufacturer, category, versions, location, dependency, in fact, any kind of relationship required to model an IT infrastructure.
A type of relationship is represented as colon-separated strings. A relationship comprises more than the two Node endpoints, it contains the "route" between the two. This is made up in the following way:

Node:Role:RelationshipLink:Role:Node

For example the relationship from a Host Node to the Cluster Node that contains the host is shown as:

Host:ContainedHost:HostContainment:HostContainer:Cluster

The relationship from a Cluster Node to a Host Node that it contains is shown as:

Cluster:HostContainer:HostContainment:ContainedHost:Host

A relationship is a bidirectional link between two nodes. In this section, the terms "start node" and "target node" are used to describe the way that the relationship is built. However, once the relationship has been built, the terms are redundant.

The general timeline for the creation of a relationship is:

1. Create "start node".
2. Create "target node".
3. Create relationship between 1 and 2.

The individual components of the relationship are described in the following sections.

Node

The Node is any kind of node that can have a relationship, such as a Host Node. All nodes can have relationships, including relationships.

Relationship Kinds

The relationship kind describes the nature of the relationship. For example, the DeviceSubnet relationship kind describes the link between a device and the subnet that it is on, but without any directionality implied.

This section refers to Relationship Kinds as the colon-separated lists which describe how two nodes are related, the roles that each node plays in the relationship, and the Relationship Link which describes the nature of the Relationship.

A complete list of Relationship Kinds with their descriptions is provided in the table below.

Role

The role describes the part that its node plays in the relationship.
For example, where a Host Node represents a host which is running a software process:

• A Software Instance has been created which represents the process running on the host.
• The Host Node is acting in the role of Host; the host for some running software.
• The Software Instance is acting in the role of RunningSoftware; software which is running on a host.
  Roles are required because a node can play one of many parts in a relationship, and clarification is needed; the role clarifies the part that the nodes are playing in the relationship.
  A complete alphabetical list of Role Kinds in the default taxonomy with their descriptions is provided in the table below.

  Role Kind	Description
  AssociatedConnection	Connection associated with an integration point.
  Associate	Associate inference.
  AttachmentContainer	Node containing an attachment.
  Attachment	Attachment.
  BusinessOwner	Business owner of an element.
  Category	Category of elements.
  Child	Child in hierarchy.
  Client	Client.
  Component	A component that makes up an item.
  ContainedHost	Host contained in another host.
  ContainedItem	An item contained in a basket.
  ContainedLocation	A location inside another location.
  ContainedSoftware	Piece of software contained inside other software.
  Contained	An element contained in another.
  Container	An element containing others.
  Contributor	Contributor inference.
  DefaultConnection	Default connection for an integration point.
  Dependant	Entity that depends upon another.
  DependedUpon	Entity depended upon by another.
  Detail	A detail belonging to an element.
  DeviceOnSubnet	IP device belonging to a subnet.
  DeviceWithInterface	A device with an interface, e.g. a network interface.
  DiscoveryAccess	Discovery access.
  DiscoveryResult	Discovery result.
  ElementInCategory	Element belonging to a category.
  ElementInLocation	Element in a location.
  ElementUsingFile	Element using a file.
  ElementWithDetail	Element with associated details.
  ElementWithStatus	Element with an associated status.
  Element	Element.
  Employee	Employee.
  Error	An ECAError related to a pattern.
  Favorite	A favorite item for a user.
  FibreChannelDeviceWithNode	A Fibre Channel HBA with a WWNN.
  FibreChannelNodeWithPort	A Fibre Channel WWNN with a WWPN.
  FibreChannelNode	A Fibre Channel WWNN for a HBA.
  FibreChannelPort	A Fibre Channel WWPN.
  File	A File.
  FoundationUser	A User.
  HardwareDetail	Support Detail Data is for Hardware.
  Hardware	Physical host to which hardware reference data will be related.
  HomeLocation	Home location of an element.
  HostContainer	Host containing other hosts.
  HostedFile	A File on a Host.
  Host	Host for software instances.
  ITOwner	IT owner of an element.
  InferredElement	Inferred element.
  InferredRelationship	Inferred relationship.
  InstalledSoftware	Installed software.
  IntegrationAccess	Integration access.
  IntegrationConnection	Connection which is available under an integration point.
  IntegrationPoint	Integration point for a connection or query.
  IntegrationProvider	Integration provider for an integration point.
  IntegrationQuery	Query associated with an integration point.
  IntegrationResult	Integration result.
  InterfaceOfDevice	Interface of an IP device.
  List	List.
  LocationContainer	A location containing other locations.
  Location	Current location of an element.
  Manager	Manager.
  ManufacturedItem	Manufactured item.
  Manufacturer	Manufacturer of an item.
  Member	Member of a list.
  MountedFileSystem	Mounted file system.
  Mounter	Mounter of a file system.
  NetworkConnection	Network connection.
  NetworkEndpoint	One end of a network connection.
  NetworkInterface	Network interface end of a network link.
  New	A pattern that is deprecating another.
  Next	Next node in sequence.
  OSDetail	Support Detail Data is for Operating System.
  Old	A pattern that has been deprecated by another.
  OperatingSystem	Operating system of a host.
  Overridden	A pattern that is overridden by another.
  Overrider	A pattern that is overriding another.
  OwnedItem	Item owned by someone or something.
  Owner	Owner of an item.
  Parent	Parent in hierarchy.
  PatternConfiguration	Pattern configuration.
  PatternConfirmed	Confirmed node.
  PatternCreated	Created node.
  PatternDefine	Pattern definitions function.
  PatternDefinitions	Pattern definitions.
  PatternDestroyed	Destroyed node.
  PatternExecution	Pattern execution.
  PatternModified	Modified node.
  PatternModule	Pattern module.
  PatternPackage	Pattern package.
  PatternTrigger	Pattern trigger.
  PatternWithError	A pattern with ECAErrors.
  Pattern	Pattern.
  Peer	Peer.
  Person	A person.
  PortInterface	Switch port end of a network link.
  Previous	Previous node in sequence.
  Primary	Primary inference.
  ReferenceData	Holds hardware reference data.
  ResourceUser	User of resource.
  Resource	Resource being used.
  RunningSoftware	Software running on a host.
  Server	Server.
  ServiceProvider	Provider of a service.
  Service	Service being provided.
  Set	A set.
  SoftwareContainer	Piece of software containing other software.
  SoftwareDetail	Support Detail Data is for Software.
  Status	Status.
  Subnet	Subnet of an IP device.
  SupportOwner	Person or group responsible for supporting an element.

Provenance

By linking data items and their attributes to the evidence for them, BMC Atrium Discovery enables its data to be easily verified; a prerequisite for trusting it. This feature is called Provenance.
Provenance Data is created by the Reasoning Engine and consists of relationships between Directly Discovered Data items and entities inferred from them - a relationship back to the source from the inferred entity. For example, there is a provenance relationship between each Software Instance (SI) and the data that caused the SI to be inferred - typically one or more processes, files, or the like.

Provenance information is meta-information describing how the other information came to exist. It is generated as Reasoning builds and maintains the model. Provenance information is stored on relationships in the model.

• Inference Types
  • Primary – indicate that the existence of the evidence node is the reason that the inferred node was created.
  • Contributor – indicate that the evidence node provided information used in building the inferred node.
  • Associate – indicate that BMC Atrium Discovery knows there is a relationship between the evidence node and the inferred node.
  • Relationship – indicate that BMC Atrium Discovery knows that a relationship exists because of the evidence node.
  • Deletion – indicate that the removal of the inferred node was due to withdrawal of the evidence node.
• Maintaining Pattern – the pattern maintaining a node.

If you need to access the data in your model you should access the UI functions provided in BMC Atrium Discovery that enable this. Apart from specialist purposes, you should not need to understand the provenance implementation details in BMC Atrium Discovery. However, an overview is provided below.

Provenance Implementation Details

To represent provenance information, attributes can be stored on the Inference relationships. The keys attribute contains a list of the attribute keys that were set or confirmed on the inferred node as a result of the inference. The rule attribute contains the name of the reasoning rule that decided upon the inference. Provenance information is only created and is not updated.

Inferred Nodes are related to DDD Nodes using 'Creation Inference' relationships. The Inferred Node has the role InferredElement; the DDD Node has the role Primary, Contributor or Associate as appropriate. To support the full lifecycle of inferred nodes there are complimentary Removal Inference relationships. Destruction is the complimentary role to Primary, and Withdrawal is the complimentary role to Contributor.

The method of linking of discovered information to inferred information means that in general, each inferred node will have relationships to many discovery data nodes, representing multiple discoveries of the entity over time.

The Reasoning Engine maintains this provenance information and this can be accessed using functions in the BMC Atrium Discovery Search Service named Provenance and Provenance Details.

Relationships between Relationships

Relationships are technically a sub-class of nodes and they have the same basic characteristics. Relationships can have attributes stored in them and can have relationships to other nodes in the same way that nodes can.

A relationship connects two nodes between their role, however a relationship can also act in a role in a relationship. Therefore, you can have relationships between nodes and relationships or relationships between relationships.

Relationships between Inferred Nodes

Using patterns, the reasoning engine can construct a number of relationships between inferred nodes, as follows:

Links an SI to the Host it is running on.

SoftwareInstance:HostedSoftware:HostedSoftware:Host:Host

A client-server relationship between SIs. This can be inferred based on the presence of network connections between processes. It can also be based on other evidence such as configuration files or directly querying the endpoints.

SoftwareInstance:Client:Communication:Server:SoftwareInstance

Equivalent to the client-server case, but where the endpoints in a communication are peers, rather than client and server.

SoftwareInstance:Peer:Communication:Peer:SoftwareInstance

A dependency between SIs, other than a communication link. Attributes on the relationship can indicate the kind of dependency.

SoftwareInstance:Dependant:Dependency:DependedUpon:SoftwareInstance

Represents SIs that logically contain other SIs.

SoftwareInstance:SoftwareContainer:SoftwareContainment:ContainedSoftware:SoftwareInstance

Links a virtual host to the SoftwareInstance that implements it.

SoftwareInstance:HostContainer:HostContainment:ContainedHost:Host

Links a configuration file to a SoftwareInstance.

SoftwareInstance:ElementUsingFile:FileUse:ConfigurationFile:File

Represents the SIs that make up a BAI.

BusinessApplicationInstance:SoftwareContainer:SoftwareContainment:ContainedSoftware:SoftwareInstance

Represents BAIs that logically contain other BAIs.

BusinessApplicationInstance:SoftwareContainer:SoftwareContainment:ContainedSoftware:BusinessApplicationInstance

A dependency between BAIs.

BusinessApplicationInstance:Dependant:Dependency:DependedUpon:BusinessApplicationInstance

Indicates the Hosts which form a cluster.

Cluster:HostContainer:HostContainment:ContainedHost:Host

Indicates the SIs that provide clustering services for a cluster.

Cluster:Service:SoftwareService:ServiceProvider:SoftwareInstance

Represents the relationship between logical hosts and their container for Sun E15Ks and similar.

HostContainer:HostContainer:HostContainment:ContainedHost:Host

Represents the relationship between network interfaces and the subnets they are connected to.

Subnet:Subnet:DeviceSubnet:DeviceOnSubnet:NetworkInterface

In addition to these relationships, the reasoning engine also constructs relationships to the Pattern Management Nodes, for example, patterns.