WO2013185166A1 - System management tool - Google Patents

System management tool Download PDF

Info

Publication number
WO2013185166A1
WO2013185166A1 PCT/AU2013/000547 AU2013000547W WO2013185166A1 WO 2013185166 A1 WO2013185166 A1 WO 2013185166A1 AU 2013000547 W AU2013000547 W AU 2013000547W WO 2013185166 A1 WO2013185166 A1 WO 2013185166A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
objects
type
node
components
Prior art date
Application number
PCT/AU2013/000547
Other languages
French (fr)
Inventor
Evan LINWOOD
Original Assignee
Linwood Evan
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2012902487A external-priority patent/AU2012902487A0/en
Application filed by Linwood Evan filed Critical Linwood Evan
Publication of WO2013185166A1 publication Critical patent/WO2013185166A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/10—Geometric CAD
    • G06F30/18—Network design, e.g. design based on topological or interconnect aspects of utility systems, piping, heating ventilation air conditioning [HVAC] or cabling

Definitions

  • the present invention relates to tools for management of computer equipment, applications and networks or other complex equipment systems configured from a plurality of components where complex physical and logical relationships can exist.
  • management tools are required that support high-fidelity representation of containment relationships and connection associations that exist between these objects in terms of both the physical and multiple logical layers of networking, computing, and application elements concerned.
  • computing and application logical 'technology categories' or 'domains' mentioned in this document include (but are not restricted to) elements in the following domains: Networking, Operating system, Database
  • SDOs Standards Development Organizations
  • ITU International Telecommunication Union
  • TMF Tele Management Forum
  • DMTF Distributed Management Task Force
  • IETF Internet Engineering Task Force
  • MEF Metro Ethernet Forum
  • 3GPP 3rd Generation Partnership Project
  • Figure 1 is a block diagram of an embodiment of the present invention.
  • Figure 2 is an example of the graph structure used in embodiment of the present invention.
  • Figure 3A is an example of a simple system and Figures 3B and 3C are examples of how the example of Figure 3A can be described using the graph structure of embodiments of the present invention.
  • Figure 4A shows a simplified example of model objects according to a first
  • Figure 4B shows a simplified example of model objects according to a second embodiment of the present invention.
  • Figure 5 shows a specification class model according to the first embodiment.
  • Figure 6 shows a complementary inventory class model to the class model of Figure 5.
  • Figure 7 illustrates a unified catalog environment.
  • Figure 7 A shows an example of a resource specification structure and corresponding inventory objects.
  • Figure 8 shows a simple example of a layered resource inventory structure.
  • Figure 9 shows the example of figure 8 represented using SID class model items.
  • Figure 10 shows the example of figure 8 represented using the class model of the first embodiment of the present invention.
  • Figure 1 1 shows an example product specification structure for the first embodiment of the invention.
  • Figure 12 shows an example product specification structure for a Windows Standard installation package in accordance with the first embodiment of the invention.
  • Figure 12A shows an example product specification structure for a Windows 2008 Group in accordance with the first embodiment of the invention.
  • Figure 12B shows an example resource inventory structure for a Windows 2008 Group in accordance with the first embodiment of the invention.
  • Figure 12C shows an example product specification structure for a 'BroadCom
  • Ethernet NIC NetXtreme Device Driver' in accordance with the first embodiment of the invention.
  • Figure 12D shows an example product specification structure for a link connectivity item in accordance with the first embodiment of the invention.
  • Figure 13 shows an example product specification structure for an SQL Server 2008 Net Connection Point in accordance with the first embodiment of the invention.
  • Figure 13A shows an example product specification structure for an SQL Server 2008
  • Figure 14 shows an example product specification structure defining an access point relationship in accordance with the first embodiment of the invention.
  • Figure 15 shows another example product specification structure defining an access point relationship in accordance with the first embodiment of the invention.
  • Figure 16 shows an example of a management display region of an embodiment of a user interface.
  • Figure 17 shows an object model of a physical drive enclosure in accordance with the first embodiment of the present invention and an example of a corresponding Ul representation from a physical front elevation viewpoint.
  • Figure 18 is an example of a representation of the object model of Figure 17 from a storage group viewpoint.
  • Figure 19 is an example of a Ul representation from a logical volume manager viewpoint.
  • Figure 20 is an example of a Ul representation from an Operating System to Volume viewpoint for a specific host system.
  • Figure 21 is an example of a Ul representation of a Connection point viewpoint corresponding to Figure 20 for a specific host system.
  • Figure 22 is an example of a Ul representation of a connection point viewpoint in the network layer with some elements in an unfolded state.
  • Figure 23 shows the example of Figure 22 with some elements folded and another element unfolded.
  • Figure 24 shows a simple example of model elements beside a representation of these elements as represented by a user interface.
  • Figure 25 shows another simple example of model elements beside a representation of these elements as represented by a user interface.
  • Figure 26 is an example of a pre-state Ul representation and corresponding object model prior to creation of new physical link.
  • Figure 27 is an example of a post-state Ul representation and corresponding object model to Figure 26.
  • Figure 28 shows an example of a pre-state Ul representation.
  • Figure 29 is an alternative representation of Figure 28 showing corresponding model objects relevant to a Logical Volume Manager viewpoint.
  • Figure 30 shows an alternative representation of Figure 29 from a Security Zone Manager viewpoint.
  • Figure 31 is a post state example of Figure 29 showing a Logical Volume Manager viewpoint.
  • Figure 32 is an alternative representation of Figure 31 from a Security Zone Manager viewpoint.
  • Figure 33 is an example of class types relevant to logical partitioning in accordance with the first embodiment of the invention.
  • Figure 34 shows the example of Figure 10 with some objects assigned to a local partition.
  • Figure 34A shows an example of an alternative view of the architecture of Figure 34, displaying a structural path traced through related fault/alarm indications as part of a root cause analysis exercise.
  • Figure 35 shows an example of a Plan elevation.
  • Figure 36 shows an example of a Ul representation of the externally visible areas of a server chassis and corresponding resource inventory hierarchy.
  • Figure 37 shows an example of a Ul representation of specifying an external geometry reference point and corresponding resource model.
  • Figure 38 shows an example of product component item definition for a Riser Card.
  • Figure 39 shows a specification class model according to the second embodiment.
  • Figure 40 shows a complementary inventory class model to the model of Figure 39.
  • Figure 41 shows an example of resource inventory items allocated to logical partitions.
  • a system management tool 100 which comprises a configuration module 110 and a graphical user interface 120.
  • the configuration module employs a framework 130 to define system components and interaction relationships between system components in terms of a graph based structure. Interaction relationships define connectivity associations and containment relationships between system components.
  • the graphical user interface is adapted to enable a user to select a functional perspective from which to manage or view a defined system architecture, and render for display a graphical representation of one or more defined system components and interaction relationships therebetween, selected for display by the GUI based on the graph based structure and the functional perspective selected by the user.
  • the configuration module 110 is used to define system architecture.
  • the configuration module can be implemented as a software module executable on a processor using any suitable software platform or architecture.
  • the graphical user interface 120 can also be implemented as a software module and can be implemented using the same or a different software language than the configuration module. Although in many embodiments a common software platform will be used to implement both the configuration module and graphical user interface, different languages may be used for different modules, provided the resulting compiled modules execute compatibly. A number of examples of tool implementations are outlined later in this document.
  • Embodiments of the tool can also include business logic modules for implementing business logic for system management functions.
  • the tool may be used simply for defining system architecture which is accessed for system management by a different system management system. It should be appreciated that system architecture defined using embodiments of the present invention can be compatible with business logic of existing system management systems.
  • the configuration module 1 10 employs a framework to define system architecture in terms of graph based structures.
  • the framework is based on the concept that resource interactions can be defined in a common manner based on a simple graph structure using nodes, vertexes and edges as shown in Figure 2. Nodes
  • Vertexes 210 may have one or more Vertexes 210 associated with them.
  • Edges 220 may connect two Vertexes together (thereby linking two Nodes together).
  • Nodes 200 may be connected to multiple other Nodes, or the same Node more than once, by the configuration of associated Vertexes 210 and Edges 220.
  • Embodiments of the framework described herein enable abstraction of system component representations based on the graph structure which can be utilised by business logic for specification network management functions.
  • the framework can be used for defining system architecture to be managed using embodiments of the tool.
  • the framework can also be used for abstract representation of system architecture defined using known information models with, some transformation, in a manner that enables the original system architecture information model definition to be retained.
  • Each system component in a system architecture can be assigned as a node vertex or edge based on the generalised functional role of the system component.
  • Node is used for a physical or logical resource.
  • Vertex is used for a termination for a connection to a physical or logical resource.
  • Edge is used for a connection between two vertices.
  • Each node component can be associated with one or more vertex components, each vertex component being associated with a single node component.
  • Each edge component can be associated with two or more vertex components to thereby define links between terminations for connection of physical or logical resources.
  • a node component can be associated with another node component thereby defining a containment relationship between the associated node components.
  • association In this framework the associations between node components, vertex components and edge components represent interaction relationships and each association is defined as a connectivity association or a containment relationship. Typically connectivity associations and containment relationships will be defined separately but combined definition of connectivity and containment relationships or relationship structures can also be supported.
  • an edge component can be limited to being associated with only two vertex components, to thereby define a link between two terminals for connection of physical or logical resources.
  • an edge component can be associated with two or more vertex components. Each vertex component associated with a single edge component can be designated a specific role defining the purpose of the vertex component in context of the association with the edge component.
  • This framework enabling definition of system components in terms of a graph based structure can be implemented using object oriented models.
  • the framework uses a single abstract information model structure across all containment relationships and connectivity associations across all resource classes.
  • this framework can also be referred to as a common model element.
  • This information model can be an object oriented model which includes in classes for defining resources an abstraction type attribute whereby a resource is defined as a node, vertex or edge.
  • Resource class specifications have abstraction types node, vertex or edge.
  • This abstraction tvoe attribute is added into the resource class specifications based on generalised functional role so by virtue of inheritance each instance will carry the appropriate node, vertex or edge attribute.
  • An interaction specification class is introduced to define containment and connectivity relationships between associated resource objects.
  • This information model structure enables business logic to traverse resource objects based on the three abstraction types (node, vertex and edge) rather than resource object type. Containment and connectivity relationships can also be clearly defined.
  • FIG. 3A An example is shown in Figure 3A where two personal computers 301 , 302 each having a network card 310, 320 are connected together using a physical cable 350.
  • Each network card 310, 320 has a physical port 330, 340 for connection of the physical cable 350.
  • Figure 3B is a simple example of how the framework of the present invention can be used to define the physical architecture of the connection between the two network cards 310, 320.
  • the two network cards 310, 320 are defined as physical resources using resource objects 310', 320' having the abstraction attribute type NODE 315, 325.
  • the physical ports 330, 340 are defined as physical resources using resource objects 330', 340' having the abstraction attribute type VERTEX 335, 345, as the physical ports provide the connection for the physical cable 350.
  • the physical cable 350 is defined as a physical resource using a resource object 350' having abstraction attribute type EDGE 355, as the physical cable 350 is what provides the connection between the two network cards 310, 320.
  • Some embodiments of the framework of the present invention facilitate clear definition of connectivity and containment relationships using Contain Connect Interaction Specifications.
  • Interaction specifications can be used to define connectivity and containment relationships between associated objects of NODE,
  • Interaction associations between objects can be defined in terms of any one of:
  • Containment relationships can also be defined in terms of containment importance and multiplicity.
  • containment can be defined using a component (COMPNT) attribute type for a relationship between objects in the same layer and using a support (SUPPT) attribute type for a relationship between objects in different layers.
  • a component type relationship exists between an operating system and its logical volumes and software packages executing in the operating system
  • SUPPT support
  • Connectivity relationships can be defined using a connection (CONNECT) attribute type for connectivity relationships within the same layer, where a single endpoint object is situated at each end of the connection, for example, with respect to relationships between physical links and physical ports.
  • CONNECT connection
  • ACCESSPT access point connectivity attribute type
  • connectivity relationships between resources in different layers is not used in common information technology or networking architectures.
  • embodiments of this invention can be used for defining such architectures.
  • connectivity relationships between resource objects in different layers can be defined using one or more interlayer connectivity attribute types.
  • the framework of the present invention can accommodate such new architectures simply by adding appropriate connectivity attribute types to the interaction specification.
  • the framework of the present invention can be used for defining complex system architectures other than IT and networking architectures, for example engineering or medical system architectures where interlayer connectivity may be used. A special case does exist and is described whereby objects existing at different lifecycle states need to support what may be regarded as being interlayer connectivity associations.
  • layers of the architecture can be flexibly defined in any manner suitable for the architecture.
  • Layer definitions are not restricted to known layer structures, such as within the OSI model.
  • a layer can be defined for any group of resources that have a horizontal management relationship, and can be referred to as a management plane.
  • application, transport, compute and physical layers can be defined as well as layers such as storage, memory, database etc.
  • Layers can be defined for management planes in any manner that makes sense to those building and managing the system architecture. This enables any type of system to be defined using a layer structure. Interaction specifications are used to define containment and connectivity relationships within the layer structure.
  • a Management Plane in the field of network engineering normally exists within the networking layer, and usually represents a path through a networking topology that only privileged users have access to for the purpose of managing the relevant network devices themselves.
  • a Management Plane can be used to create the distinction of a horizontal layer that represents any technology type, not just the commonly understood technology/layer type combinations as is described in various industry standards, such as the OSI, G.800 series standards, etc. Management Planes can be stacked, similar to layers in layered network models.
  • each physical port 330, 340 is provided on a network card 310, 320, therefore a component containment relationship exists.
  • Figure 3C shows an extension of the object oriented architecture definition of Figure 3B to include interaction objects to clearly define the containment relationships between the physical ports 330, 340 and network cards 310, 320.
  • An interaction object 360 of attribute type COMPNT 365 defines the component containment relationship between the NODE attribute object 310' defining the network card 310 and the VERTEX attribute object 330' defining the physical port 330.
  • interaction object 370 of attribute type COMPNT 375 defines the component containment relationship between the NODE attribute object 320' defining the network card 320 and the VERTEX attribute object 340' defining the physical port 340.
  • Interaction objects 380, 390 having attributes CONNECT 385, 395 are used to define the connection relationship between the physical cable EDGE type object 350'and the physical port VERTEX type objects 330', 340' respectively.
  • FIG. 4A shows a simplified example of model objects that might be present in the case of an implementation of SID
  • Chassis objects 410a and 420a are represented abstracted as
  • Resource objects 410 and 420 of type Node
  • Physical Port objects 450a to 453a are seen in their abstract representation as Resource objects 450 to 453, of type Vertex
  • Cable object 460a is represented abstracted as Resource object 460, of type Edge.
  • SID Physical Resource class definition layer For each object association formed at the SID Physical Resource class definition layer, another matching association is formed at the abstracted layer.
  • This approach can be extended to include combined use of very different model domains, such as for complex networking or application engineering, in conjunction with the Physical Resource model domain, using the common abstract model domain as a unifying element.
  • Business logic written to analyse the graph structure at the abstracted level can perform inspection of the relevant attribute(s) to determine whether any specific Resource object being examined or traversed is a
  • Embodiments of the present invention add an interaction specification class (not shown in Figure 4A) to enable precise definition of containment and connectivity relationships between logical and physical resource objects.
  • the interaction specification class is a concrete class and instances of this specific class type need to be created directly.
  • Interaction specification objects enable any business logic traversing the graph structure at an abstract level to understand whether Node or Vertex type resource objects are network, storage, database, compute related objects, and of what sub-category etc.
  • An advantage of this model design is that it avoids 'pollution' of generalised code operating at the abstracted level with sub-domain specific class, attribute or association references - for example to avoid the need for class type checks through all logic to see whether a specific Resource object of type Node was a 'Chassis', 'OperatingSystem' or 'VirtualMachine'.
  • the framework is implemented as an information model which is object oriented model having node, vertex and edge resource classes and association classes wherein each resource class inherits a class type from one of node vertex and edge classes.
  • association classes are added for defining associations between resource objects. Containment and connectivity relationships are defined in attributes of the association classes.
  • ResourceNode, ResourceVertex and ResourceEdge definitions are abstract classes used to enable concrete sub-classes to inherit their base class structure from the abstract classes to provide a common way of looking at instances of respective concrete sub-classes (for example "Chassis”, Operating System”, “Logical Volume” etc) for defining system components.
  • Each concrete subclass can be associated with one of the
  • ResourceNode, ResourceVertex, and ResourceEdge abstraction classes so that, by virtue of inheritance, each resource object can be traversed by business logic operating at the abstract level simply as a node, vertex or edge rather than as the actual concrete class types, thus enabling simplification of business logic.
  • association classes added to enable definition of containment and connectivity relationships and complete the graph based structure abstraction, are concrete classes and instances of these specific class types are created directly.
  • association classes enables identification and management at an abstract level of containment and connectivity roles played by associated ResourceNode, ResourceVertex and ResourceEdge objects.
  • a relationship between node type objects is defined using a node association object, for example ResNodeAssoc class.
  • Associations between ResourceNode objects will always define containment relationships and can include relationships between ResourceNode objects located within the same network or architectural layer, between ResourceNode objects located in adjacent network or architectural layers, and between objects having the same or different technology types.
  • a relationship between a node type object and a vertex type object is defined using a nodevertex association object, for example ResNodeVertexAssoc.
  • ResourceNode objects and ResourceVertex objects can be associated with a single ResNodeVertexAssoc object specifying one or more containment and connectivity roles or multiple ResNodeVertexAssoc objects each specifying one or more
  • a relationship between a vertex type object and an edae tvoe obiect is defined using a vertexedge association object, for example ResVertexEdgeAssoc.
  • ResourceEdge objects and ResourceVertex objects can be associated with a single ResVertexEdgeAssoc object specifying one or more containment and connectivity roles or multiple ResVertexEdgeAssoc objects each specifying one or more
  • ResNodeAssoc, ResNodeVertexAssoc and ResVertexEdgeAssoc association classes are referred to collectively in some places in this document as xxxAssoc association classes.
  • Roles & Sub roles on the xxxAssoc objects enable any business logic traversing the graph structure at an abstract level to understand whether ResourceNode or ResourceVertex objects are network, storage, database, compute related objects, and of what sub-category etc.
  • Each xxxAssoc object can describe the ResourceRole (either PhysicalResourceRole or LogicalResourceRole) of each of the objects it relates.
  • Figure 4B illustrates a simple example of the model objects that may be present in the case of an implementation of SID physical resource objects.
  • Each object is shown in the context of the relevant parent class type hierarchy for that object instance.
  • the SID physical resource objects are the same as the example in Figure 4A so the same reference numerals have been used.
  • the resource superclass 465 sits above the abstract classes 470, 480, 490 and each of the SID physical resource objects has an inheritance association via one of the abstract classes 470,480,490 to the resource superclass 465.
  • Chassis objects 410a, 420a inherit from the ResourceNode abstraction class 490 to become Node type objects
  • the physical port objects 450a-453a inherit from the ResourceVertex abstraction class 480 to become Vertex type objects
  • the cable object 460a inherits from the ResourceEdge abstraction class 470 to become an Edge type object.
  • Association class definitions ResNodeAssoc 495, ResNodeVertexAssoc 485, and ResVertexEdgeAssoc 475 are shown. Instances of these association class types are created to define associations between Node, Vertex and Edge objects. Note that associations between xxxAssoc type instances and instances of types ResourceNode, ResourceVertex and ResourceEdge are termed 'abstract' associations, in keeping with general object oriented terminology describing circumstances where the definition of an association is made between one or more abstract class types. It is for this reason that associations in the figure are not drawn directly between the respective object instances, but rather between the objects and the parent class type representations, where the definitions of the relevant associations are actually established.
  • an association object of ChassisPortAssoc type 481 is created to define the association between Chassis Node object 420a and Physical Port Vertex object 453a
  • ChassisPortAssoc type objects 482, 483 and 484 are created to define associations between Node type Chassis objects 420a and 410a and Physical Port Vertex type objects 451a, 452a, and 450a respectively.
  • Two association objects of PortLinkAssoc type 471 , 472 are created to define the associations between Cable Edge type object 460a and Physical Port Vertex type objects 453a and 452a respectively.
  • Resource node association class 495 is shown on Figure 4B but the architecture shown includes no associations between Node objects so no ResNodeAssoc objects are required in this example.
  • the SID model is highly structured towards supporting Catalog definitions that allow precise structural description of the items that they are intended to represent.
  • Each catalog item can be a template system resource specification. All items managed in the inventory repository database (planned, operational or historical) are created as implementations of items selected from an appropriate Catalog. Catalog items are often complex structurally, and may even represent complex layered and graph oriented structures. Any time a new inventory instance of a catalog item is created, the specification structure of the catalog item is reproduced into inventory using 'inventory' relevant counterparts of the relevant template system resource specification objects - for example, if a catalog item includes a 'ChassisSpec' template resource specification, then a 'Chassis' item will be created in inventory.
  • ChassisSpec item has children SlotSpec items, then the Chassis item will have counterpart Slot objects created and associated to it also.
  • Each of the template specification objects concerned may also have attribute values configured on them that are used to populate the initial values of counterpart attributes on the newly created inventory objects.
  • the Catalog 710 is an over-arching term used to describe a unified catalog
  • Resource Catalog 711 holds definitions of resource structures and attributes at a resource engineering level, and provides ongoing reference for non-variant attributes common to all derived inventory instances. These may be referenced or grouped and re-presented within catalogs defined in the Service Catalog 713 layer, which typically have service contracts associated with them. Elements from either the Resource Catalog 711 and/or the Service Catalog 713 layer may be referenced or grouped and re-presented within the Product Catalog 712 layer, which describes product elements as are made available to customers in a
  • the Fulfilment Processes 720 use a unified eTOM process model and drive creation/change of operational inventory from template definitions stored in the Catalog 710 environment. Fulfilment business process definitions are usually implemented into modern OSS product environments as a core supported process domain.
  • the Operational Inventory 730 is an over-arching term used to describe a unified inventory environment, managed by unified eTOM processes implemented into a modern OSS environment. This is comprised of three internal inventory layers: Resource Inventory 731 , Service Inventory 733 and Product Inventory 732. Structural referencing, grouping and re-presentment is similar in the Inventory domain as for the Catalog domain. Any Product, Service or Resource inventory item must be associated with a defining catalog definition element.
  • Any business rules that dictate allowable structural combination of various inventory item types are located on or in association with the relevant catalog element specification definitions for the items concerned, including template specifications of resource structures and attributes.
  • the use of a structured Catalog & Specification based architecture is treated as a desirable pattern that should be followed, particularly given that the model design of embodiments of the present invention can support management of complex potential combinations of product items across technology category type, implementation mode and multilavered / araoh structured network topologies.
  • FIG. 7A depicting a pre-existing resource specification structure 7A10 containing definitions of a ChassisSpec and its related SlotSpec definitions 7A14.
  • a single Chassis 7A22 resource inventory object and its related Slot 7A24 objects created subsequently to the specification structure displayed on the left of the vertical dashed line.
  • Each resource object on the right hand side references a single specification object on the left hand side as representing the template specification for that resource object.
  • Chassis/Slot object sets that all reference the same ChassisSpec/SlotSpec set as being the relevant root defining template specification structure.
  • Interface types may be file, process or protocol oriented (or any another interface technology / architecture type). Examples include Simple Object Access Protocol (SOAP), Java Messaging Service (JMS), XML file exchange, CSV file exchange, Common Object Request Broker Architecture (CORBA) etc.
  • SOAP Simple Object Access Protocol
  • JMS Java Messaging Service
  • XML file exchange CSV file exchange
  • CORBA Common Object Request Broker Architecture
  • Figures 5 and 6 represent two complimentary information models, described at the abstract super class level, supporting graph structures for use in a resource oriented model.
  • This information model can be used commonly to define any system component.
  • Figure 5 shows a template class model structure also referred to as a specification model used in the
  • Catalog 710 and Figure 6 shows a class model structure used for counterpart instances defined in the operational inventory 730, referred to as an inventory model.
  • the specification model depicted in Figure 5, the inventory model depicted in Figure 6 and the logical partition model depicted in Figure 33 are sub-components of what is referred to within this invention as the 'common model element'.
  • Figures 5 and 6 are to be interpreted as UML class diagrams: Abstract super classes are shown with title and attribute wording in an italicised font style. Each abstract super class may have multiple sub class implementations embodying essentially the same meaning. Indicative multiplicity values are shown, these may be implemented differently whilst maintaining the same general relevance of the class types concerned.
  • ResourceLocalLocationSpec DisplayStyleSpec, LayerSpec and ViewPointSpec.
  • More complex resource components may be composed of multiple ResourceSpecification objects, and a proportionally higher number of objects of the other various types in the information model. In every case, one single ResourceSpecification object will represent the 'root' resource item / component being defined.
  • ProductSpecification based product component object item sets can make reference to other existing product component item object sets in order to configure the allowable association relationship rules for that component. This is necessary for most component types. Any objects referenced in this way do not become 'owned' by the referencing objects, they simply become related resource product component item objects that they are dependent on.
  • Figures 5 and 6 include elements of known information models which are extended in the framework of the present invention to enable common model elements to be used as abstract super types for class definitions and objects at all levels.
  • Figure 5 shows a class model structure for a information model used as a template to define functionality, characteristics and relationships for resource element definitions.
  • class model 500 the classes
  • ResourceSpecification 510 ResourceRole 520, ResourceLocalLocationSpec 570 and CapacitySpec 550 are provided. These classes may already exist in information models and fulfil the same functions in the current information model but can be extended for the present invention by adding attributes or be added to an existing information model in embodiments of the present invention. Class
  • ContainConnectlnteractionSpec 560 is newly added in embodiments of the present invention to enable definition of connectivity and containment relationships.
  • the ResourceSpecification class 510 can be used for defining what a physical or logical resource is using the attributes within this class.
  • the ResourceSpecification class 510 corresponds to the Resource class 610 in the inventory model of Figure 6.
  • Embodiments of the present invention include the abstraction type attribute 512 in the ResourceSpecification class 510 to enable a resource to be defined as a NODE, VERTEX or EDGE. It should be noted that these attributes are added to the resource specification class to enable a common way of looking at instances of any respective concrete sub-classes (for example, 'Chassis', Operating system' or 'Logical Volume') that inherit their base class structure from the higher level resource class definition. Any business logic written to analyse architecture defined using this model at an abstract level can view the resource object instances as NODE, VERTEX or EDGE based on the abstraction type 512 rather than viewing the resource objects based on concrete class types.
  • the ResourceSpecification class 510 can also include a name (or
  • CommonName attribute 516 which is used to describe what type of resource object is being specified, for example 'SQL Server 2008', this could be a CommonName attribute inherited from a RootEntity super class.
  • a NAME attribute in the resource object (of any particular ResourceSpecification type) will also be used for storing the real world name of each resource object, for example
  • the ResourceRole class 520 is a super class for both logical and physical resource role specification classes (such as LogicalResourceRoleSpec and
  • PhysicalResourceRoleSpec these are not shown on the figure) and is used to define generally what functionality a logical or physical resource provides and requires.
  • ResourceSpecification class 510 Two important association attributes are provided on the ResourceSpecification class 510 that allow association to ResourceRole objects in order to fulfil important roles:
  • ResourceSpecification object 510 implements a generalised type of resource capability identified by the ResourceRole 520, e.g. a 'ComputeHost', 'Memory', 'Application Package', 'Network Connection Point', 'Transport Connection Point' or 'Database Replication Link'.
  • Use of ResourceRole objects 520 is general i.e. the same 'RDBMS' LogicalResourceRoleSpec object is used across RDBMS ResourceSpecification items from all Vendors.
  • ResourceRole objects must be unique, i.e. there can only be a single 'ComputeHost' LogicalResourceRoleSpec object.
  • ResourceSpecification must be supported by another ResourceSpecification object having the specified ResourceRole as its 'providesResourceRole' ResourceRole type.
  • a ResourceSpecification having a ResourceRole of type 'Operating System' requires support from another ResourceSpecification providing a
  • ResourceRole of type 'ComputeHost' is of type 'ComputeHost'. If a PhysicalResourceRole object named 'PhysicalHost', and a LogicalResourceRole object named 'VirtualMachine' are available, and both of these provide the ResourceRole 'ComputeHost', then either of these objects may be used to satisfy the 'ComputeHost' requiresResourceRoles requirement of the 'Operating System' object.
  • the requiresResourceRoles association plays an important part with respect to configuring 'generally compatibility' containment relationships, in particular where both physical and logical/virtual options exist.
  • CapacitySpec 550 objects to define required Processor Type and Speed and/or minimum Memory or Storage capacities etc.
  • the requiresResourceRoles association allows assignment of both LogicalResourceRole or PhysicalResourceRole objects.
  • the model of Figure 5 includes a new concrete Interaction Specification class, ContainConnectlnteractionSpec 560 to define containment and connectivity attributes. This corresponds to the ContainConnectlnteraction class 660 in Figure 6.
  • Interaction specifications used to define connectivity and containment relationships between ResourceSpecifications can be extended usina additional attributes to more clearly define features or constraints of the relationships.
  • attributes can be provided to define containment importance, option groups, multiplicity and context.
  • a ContainConnectlnteractionSpec may indicate that a 'Windows 7 Standard'
  • Containment support defined via specific ContainConnectlnteractionSpec object 560 definitions allows finely grained description of supporting relationship associations between specific object types. This compares to the more generalised alternative form of containment support available via the
  • ResourceRoleSpec.requiresResourceRoles attribute (described previously). Enabling containment and connectivity relationships to be defined separate from the resource role relationships enables more generalised resource role definitions which, in turn, can reduce overall complexity.
  • ContainConnectlnteractionSpec 560 defines a specific structural relationship between two ResourceSpecification items. This may be either a Containment or a Connectivity based relationship defined using the ContainmentOrConnectivityType (abbreviated as CCT) attribute 562, for example using the COMPNT, SUPPT,
  • ContainConnectlnteractionSpec class definition these can include: Containment Importance, Option Group, Multiplicity and Context.
  • Containment importance 564 can have attribute types "Required” or Optional". "Required” specifies that an item type must be present for correct installation/operation of the relevant resource type. Failure to fulfil an interaction specification with containment importance of required can either cause generation of operator alarms or prevent the user from completing the relevant action. "Optional” specifies that an object type can be, but doesn't need to be added as a contained item.
  • Option groups 566 can be used where a logical resource type may potentially be added as a contained or connected item to just one of a number of optional item types.
  • An example is the potential to add an application package to either a Windows or Windows 2008 product installation, but not to both.
  • a mechanism is required to define such "options" within a "group” association type, so this is provided using the option group attribute in embodiments of the present invention. For example, if five types of "package container" have been specified as a supporting object type for a given object type, these may be grouped by specifying a common value in the option group attribute (this may be something meaningful, like the strina "PackaaeContainer" or a system generated code etc).
  • Membership in the group is therefore based on the presence of a common value used across items within the same option group attribute, rather than assignment of items within a model based association. This can reduce the total number of model associations and complexity. Any given object type specification may have numerous option group sets relating to different
  • Option groups may also be defined as an attribute of a resource role
  • option groups may be defined and used in a manner similar to option groups, as has been done in existing SDO and other information models.
  • advantages however in defining option groups on the interaction specification class, separately from the resource role class. These advantages include: enabling the use of more generalised resource role definitions and clear association of option groups across containment/connectivity relationship sets.
  • Allowable values for the Multiplicity attribute 565 can include:
  • V zero, or at most, only one item.
  • the Multiplicity attribute can be used for all containment and connectivity relationship types. It should be noted that for defining current IT and networking systems, the Multiplicity attribute is mostly relevant for ContainConnectlnteractionSpec objects 560 that specify a 'Containment ' type interaction. This is the case because within the current system architecture multiplicity for CONNECT connectivity based items can usually be regarded as for connectivity type items in the context of current networking standards. However, it should be appreciated that the model can be used to define connectivity type relationships having any Multiplicity as may be required for emerging technologies and system management philosophies, or for non-IT system architecture.
  • the multiplicity value on any of the member items specifies how many total instances of any of the various member item types may be associated to the relevant object.
  • the system must ensure that the same value for Multiplicity is assigned across members of the same Option Group.
  • Multiple Option Sets exist such that selection of a choice in one will dictate the outcome of choices in the rest. This will tend to happen naturally, given for example where a sub-component is added to a Windows 2008 product, the other relevant supporting objects in that context will also be relevant only to Windows 2008. This could be supported using a more highly developed 'OptionGroupSpec' class model definition structure, rather than the option group attribute described above. This variation is envisaged within the scope of the present invention.
  • the Context attribute 568 allows a further specification of the meaning of a particular ResourceSpecification object item. It is a type of Role specification, but is used independently of the ResourceRole object in the model.
  • a Context attribute 568 setting could be used for example where a point-to-multi point connectivity link was being specified, and the meaningfulness of the roles played at each end was significant.
  • One end of the connectivity link may be classed as being the 'Source' end, another as the Target' end, and another as being the 'Listening' end.
  • CapacitySpec 550 is included in the model to aid integration between embodiments of the present invention and the Capacity Specification aspect of the SID Resource model. This is necessary because Resource Specification items may need to specify minimum availability of specific types of Physical or Logical Capacity, for example: Processor Cores (units), Bandwidth (kBps, mBps, GBps, etc), Capacity (MB/GB/TB etc) etc.
  • Capacity 650 allows representation of what types of capacity are available for resource items from each of their relevant physical or logical resource containers, for example Processor Cores (units),
  • Any logical resource may be related to physical resource containers over a number of logical and physical layer levels.
  • Management planes can be defined as layers using LayerSpec 575 and Layer 675 objects.
  • layers in embodiments of the present invention refer to management planes which may conform to existing standard layer models but can also be flexibly defined.
  • the use of LayerSpec 575 and Layer 675 for defining management planes is to enable backwards compatibility with existing architecture definitions which use these objects to define layers.
  • classes used to define local locations ResourceLocalLocationSpec 570 and ResourceLocalLocation 670 are also used.
  • the specific management plane in which a resource is managed can be defined using attributes in the resource local location object. Different management planes are defined for the architecture using LayerSpec 575 and Layer 675.
  • a user interface may use the defined layers/management planes for visually representing the architecture.
  • GUIs graphical user interfaces
  • Embodiments of the present invention provide support for architecture visualisation from different functional perspectives using ViewPointSpec 580 and Viewpoint 680. These classes enable definition of attributes used by a user interface for rendering representations of the architecture from different functional perspectives, referred to as viewpoints.
  • a viewpoint can be defined for any functional perspective from which it may be desirable to view a representation of the architecture or manage aspects of the system architecture. Viewpoints can be defined to enable architecture to be viewed from perspectives independent of conventional ways of looking at or managing the system (such as operational layers or management domains). For example, consider a building and system architecture such as electricity supply, backup power/generators, lighting, air conditioning, water supply systems, sewage systems, communication networks, gas supply, elevator/escalator/travelator, security and emergency sensors and systems which are typically installed within the building and have various dependencies for operation.
  • Viewpoints can also be defined for different functional perspectives, each enabling a representation of the architecture to be generated which is relevant for a particular user or purpose.
  • users may include facility managers, building security, service providers, IT managers of individual tenancies etc.
  • a facility manager may utilise viewpoints which represent the interrelated systems from different perspectives relevant to their needs. For example, floor by floor, by access conduit /panel, or in a manner that highlights dependencies of systems such as systems dependent of a particular power source.
  • Security staff may be interested in the systems from a functional perspective of alarms or access control and their supporting systems and viewpoints may be defined for each desired perspective.
  • Building security may also have a role of emergency management and therefore may also have viewpoints defined for representation of systems which are essential, such as alarms and emergency communication, or to be controlled by security staff during emergencies such as elevators.
  • the viewpoints defined for each purpose can be set up to display the level of detail required for each purpose.
  • a model element called 'LayerSpec' 575 is used.
  • a corresponding 'Layer' object 675 is used as a container for all objects situated within any particular
  • LayerSpec 575 type A ManagementDomain containing Resource objects may have one or more Layer objects 675 associated with it, grouping Resources within the ManagementDomain into respective Layers. Within the Catalog/Specification structure multiple LayerSpec 575 items may be associated to any one ResourceSpecification item.
  • the attributes defined in the LayerSpec 575 and corresponding Layer 675 include a layer type (for example: Application, Transport, Compute, Physical layer etc) and layer name (for example: 'SQL Server Environment').
  • the LayerSpec 575 also includes an attribute for defining whether or not a layer is a network layer. It should be noted that the framework of the present invention does not limit layer definitions to current models such as the OSI layer model.
  • Embodiments of the invention allow what may currently seem to be nonsensical layer orderings to be supported later, completely across the full spectrum of physical, network, compute and application domains. It is also envisaged that different layer types typically containing different object types that may act as containers for a common set of child items types will be present in a normal implementation, particularly with respect to 'virtualised' or 'cloud' based logical resource item containers that can also be realised as physical container object types.
  • ResourceLocalLocationSpec objects 570 are used to hold visual presentation attributes relevant to the definition of other object types, such as physical & logical resource spec items, 'visual presentation attributes' can include: Layout mode, Colour, Style (i.e. stylesheet) reference, Default shape / size information etc.
  • the information model of the invention allows for definition of multiple variables
  • ViewPointSpecs 580 associated with each LayerSpec 575 definition via associative ResourceLocalLocationSpecs 570 for each ResourceSpecification 510 definition.
  • Layout modes can include: FoldingView, HierarchicalView, IconView, FreeformNetworkView etc.
  • a user may change between allowed layout modes in the same way that a file manager, such as Windows Explorer, can be set into different 'view' modes (Large, Small Icon, List, Details, Tiles etc). This selection may be applied at the overall layer/viewpoint display level, or to the layout mode used within any specific object. Additional Layout Modes relevant to domains other than compute, network or application engineering may be defined and used also.
  • a ResourceLocalLocationSpec object 570 is used to describe the relevant presentation attributes of that
  • ResourceSpecification object within each related ViewPointSpec 580 i.e. for each Viewpoint the User may select for display, in which that object appears. This will result in an additional associative ResourceLocalLocationSpec object 570 being created per ResourceSpecification object 510, for every Viewpoint in which that
  • ResourceSpecification may appear.
  • a ResourceSpecification 510 definition for a system component is associated with two Layers and for each layer two viewpoints are defined, the system component can be visually presented in both viewpoints of one layer but in the other layer the system component is hidden from one of the viewpoints, therefore three associative ResourceLocalLocationSpec 570 are used for the system component to define attributes for presentation of the object for each viewpoint in which it can be presented.
  • a default layout mode is specified, and also a configuration of which other Layout Modes may be used to display the object in that Viewpoint.
  • viewpoint definitions can simplify navigation and management of the system via the GUI.
  • Each viewpoint is associated with a resource local location specification (as described above).
  • the resource local location specification includes the attribute managedlnThisLayerViewpoint (Boolean), where True: means this item can be added/moved/removed with respect to containing parent objects when the associated layer viewpoint is visible, and the resource items appear in a Catalog Item list in this layer, and, False: means this item cannot be added/moved/removed with respect to containing parent objects when the associated layer viewpoint is visible, and this item cannot appear in Catalog Item lists in this layer.
  • True means this item can be added/moved/removed with respect to containing parent objects when the associated layer viewpoint is visible, and the resource items appear in a Catalog Item list in this layer
  • False means this item cannot be added/moved/removed with respect to containing parent objects when the associated layer viewpoint is visible, and this item cannot appear in Catalog Item lists in this layer.
  • ResourceLocalLocationSpec is associated to can include:
  • ResourceLocalLocationSpec attributes describing which Layout Mode should be presented by default can include:
  • ResourceLocalLocationSpec attributes describing default size information for each Layout Mode can include:
  • DisplayStyleSpec objects 590 describe which images should be used to display the object under each Layout Mode.
  • the ResourceLocalLocationSpec 570 can include references to displayStyleSpec objects.
  • Display style association attributes can include: DisplayStyleSpec styleFoldingExpandedView
  • Resource Local Location 670 can include attributes describing default position information for different layout types, for example such attributes can include:
  • Resource Local Location 670 can also include attributes describing default size information for different layout types, for example such attributes can include:
  • this information model can be used commonly to define all physical and logical resources and their relationships within a system architecture.
  • the model also provides common elements for defining attributes that can be utilised by a user interface for presentation of the defined architecture from different viewpoints.
  • the framework does not set or impose the precise design of any final structure used, but any class structure used must support the graph model structure to obtain the benefits of the present invention.
  • the graph model structure can be flexiblv aoDlied.
  • a skilled person may potentially design a generalised graph structured model architecture that does not use a pattern of class inheritance as described in this invention to implement various aspects of this invention including generalised containment and connectivity modelling across multiple model domains, integrated generalised specification & catalog structure, integrated generalised user interface elements, etc.
  • Figure 8 shows a simple example of a layered resource inventory structure 800 having an application layer 810, transport layer 820, compute layer 830 and physical layer 840.
  • the layered architecture depicted in Figure 8 is defined using existing information models that have not yet been adapted to this design.
  • the application layer 810 shows database management items that could be modelled using information models such as the SID or CI M, which can be extended to support specific application constructs, and supporting logical and physical constructs in a series of lower layers.
  • the modelling classes used to support elements displayed are: Databaselnstance 812, Database 814, Transaction Log 816 and ReplicationAssociation 818.
  • the transport layer 820 shows items that would typically be modelled using an information model such as the MTNM model, which supports network transport constructs.
  • the MTNM modelling classes used to support the elements displayed are: MatrixFlowDomain 822,
  • the compute layer 830 layer shows items that could be modelled using an information model such as the SID or CIM models, which support compute object constructs (or can be extended to do so). Note that both OSI Layer 2 (Transport) and Layer 3 (Network) structures are effectively combined in the Transport layer diagram representation. Another layer would be required to manage these separately - this has not been done here in order to reduce the complexity of this example.
  • the modelling classes used to support the elements displayed are: OperatingSystem 832, InstalledPackage 834 and LogicalVolume 836.
  • the physical layer 840 shows items that would typically be modelled using an information model such as the SID or CIM models, which support physical resource constructs.
  • the resource inventory structure 900 shown in the diagram of Figure 9 is the result.
  • this diagram is also now showing the presence of associations between relevant objects across inter-layer boundaries. These associations are what define the 'layering' structure between layers.
  • the various inter- layer object associations shown in this diagram are domain-specific, i.e. they are defined specifically within the existing domain information models used, and are therefore of different types.
  • the class inheritance structure and naming of these existing inter-layer associations will also be relevant therefore to the existing domain information model they belong to or are extended from.
  • PhysicalResource objects in the Physical layer 920 In the context of the Transport layer, associations down into the Physical layer would be made using associations such as FlowPoint.physicalPort. It is likely that within the Transport 920 layer, an existing standard information model such as MTNM or a G.800 series model would form the basis of the implementation.
  • association 912 In the context of the Application layer 910, association 912 relates down into the Transport layer 920. This particular Database Replication association type is somewhat manufacturer/product specific, and is not likely therefore to have a direct representation among existing standard information models. Implementers of associations 912 would likely choose a name reflecting the object types being referenced such as Replication. FdFr. In the context of the application layer 910 associations 914 916 are also shown to relate down into the compute layer 930.
  • associations 932 relating down into the Physical layer 940 would be made using associations such as OperatingSystem. chassis.
  • additional associations may also exist between Transport layer and Compute layer objects, describing which OperatingSystem or Package each Transport layer object is contained by.
  • Figure 10 shows the same logical and physical resources at their abstracted super class level as resource objects having types Node, Vertex or Edge and interaction specification objects added to define containment and connectivity relationships.
  • the database instance 812 and its associated database objects 814 are abstracted as respective resource objects of type node 1012, 1014.
  • An interaction specification object of type component (COMPNT) 1013 has been added to define the containment relationship between them.
  • an interaction specification object of type COMPNT 1015 is used to define the containment relationship between the database 814 which is abstracted as Node 1014 and the transaction log 816 contained by the database 816, the transaction log being abstracted as Node 1016.
  • Interaction specification objects of type support have been added to define containment relationships between objects in different layers 1010, 1020, 1030, 1040.
  • SUPPT Interaction specification objects of type support
  • the inter layer relationship 914 between database 814 abstracted as Node 1014 and logical volume 836 abstracted as Node 1036 is defined using a containment interaction specification object of type SUPPT 1035.
  • Interaction specification objects defining connectivity interactions between objects within the layers 1010, 1020, 1030, 1040 have also been added.
  • an interaction specification of type connection (CONNECT) 1027 is added between the Flow Point 828 abstracted as Vertex 1028 and Flow Domain Management Fragment 826 abstracted as Edge 1026.
  • CONNECT type connection
  • Any number of layers can be present, and new layers, layer types and model types can be added and removed, all without impact to the structure of any existing business logic that is written to reference the class model at the abstract super class 'view level' of the common graph-structured class model.
  • a disadvantage is that a higher overall number of object instances may result from the use of this information model, due primarily to the presence of interaction specification classes.
  • a higher overall number of objects under management may affect: OSS data storage requirements, network bandwidth requirements, application server processing requirements and data model complexity.
  • the advantage is a higher level of management, processing and analysis capability across multiple resource engineering and business domains.
  • Compute layer described in this example is a deliberately simplified representation of what could be represented in a real implementation of this design as separately defined Host, Volume & Storage Layers.
  • a 'Compute' layer may optionally instead be implemented such that it sits above the Network Layer.
  • This might represent an entirely different class of objects, for example those required to describe a distributed computing grid.
  • Application type resource specification definitions may in turn be defined to support distributed application containment and connectivity structures in a relevant layer type above this.
  • the Viewpoint capability in this framework enables selected objects from across multiple layer types, such as Host, Volume & Storage layer types to be presented in the same presentation perspective, and to be managed with direct reference to each other in the Ul.
  • Figure 39 shows a specification model and Figure 40 an inventory model.
  • Figure 40 an inventory model.
  • these models can be used in a unified catalog environment as described above with reference to Figure 7. Similar to the first embodiment classes such as
  • ResourceSpecification 3910 and ResourceRole 3920 are classes which are used in existing information models.
  • the ResourceSpecification class 3910 is a super class and the abstract classes ResourceNodeSpec 3950, ResourceVertexSpec 3970, and ResourceEdgeSpec 3990 sit below this super class in the inheritance hierarchy.
  • the ResourceSpecification class 3910 corresponds to the Resource class 4010 in the inventory model of Figure 40.
  • the ResourceRole class 3920 is a super class used to define generally what functionality a logical or physical resource provides and requires.
  • any resource specification class definition representing a resource object type having Node, Vertex or Edge characteristics must be defined as a subclass of one of the abstract classes ResourceNodeSpec 3950, ResourceVertexSpec 3970, or ResourceEdgeSpec 3990.
  • any Resource 4010 object will have inherited parent object type characteristics of one of Node, Vertex or Edge - this object type being based on the functionality of the resource in terms of the graph based structure.
  • ResNodeVertexAssocSpec 3960, and ResVertexEdgeAssocSpec 3980 are provided for definition of connectivity and containment relationships between system
  • Association classes ResNodeAssoc 4040, ResNodeVertexAssoc 4060, and ResVertexEdgeAssoc 4080 in the inventory model of Figure 40 correspond to the association specification classes in Figure 39.
  • the association objects created for any one resource being defined using this model will depend on the resource object type (Node, Vertex or Edge) and the type of each resource object associated by a connectivity or containment relationship.
  • ContainConnectRole 3930 is a super class provided to enable generalised definition of containment or connectivity functionality in respect of association objects, similar to the use of ResourceRole 3920 with resoect to resource objects.
  • Association classes are concrete classes and instances of association objects are created for each containment and connectivity association between resource objects. In this manner association objects are used similarly to ContainConnectlnteraction objects of the first embodiment of the invention.
  • ContainConnectRole objects can be used to describe the generalised functional or application related nature of the association, without inferring any specific manufacturer or product.
  • a ContainConnectRole object 'RDBMS a ContainConnectRole object 'RDBMS
  • ContainConnectRole may be referenced by multiple product specifications and products, for example the ContainConnectRole 'RDBMS Transaction Log contained in RDBMS Database' may be referenced by Oracle, IBM and Microsoft specific RDBMS database product specification definitions.
  • ContainConnectRole object instance could therefore be used as a generalised tag by any business logic operating at the abstracted information model layer in order to efficiently locate and/or make traversal or analysis decisions across all
  • Association objects are associated with ContainConnectRole objects which can define attributes related to the generalised function or application of the relationship the association object defines.
  • the attributes defined on the ContainConnectRole object can be fundamental to the association and therefore common to any implementation of the association.
  • the attribute Name to define the generalised name of association.
  • An attribute Category can be used to define a category of role which may confer explicit or implied constraints.
  • Assignment of whether any particular structural association is being implemented as a containment and/or connectivity form of association is indicated via use of the isContainmentRole and isConnectivityRole attributes on the respective xxxAssocSpec class types. Vendor specific product implementations may have differences with respect to how certain resource object types are contained or connected within what are product definitions that are otherwise similar to those from other manufacturers.
  • the location of the isContainmentRole and isConnectivityRole attributes on the xxxAssoc & xxxAssocSpec class definitions allows this flexibility, awav from the generalised assignment of functional or application related nature. It should be appreciated that any relationship between two node objects will be one of a
  • Attributes can be defined on the xxxAssoc & xxxAssoc class definitions to further characterise the interaction relationship being defined. For example, multiplicity can be used to define whether the containment or connection relationship may be zero or one, only one, or many.
  • An interaction attribute can be used to define special interaction cases, for example COMPNT to define a component containment type association between objects in the same layer or SUPPT to define a support containment type association between objects in different layers.
  • the Interaction attribute can also be used to define special interaction cases for connectivity relationships, for example CONNECT to define a connectivity relationship between objects within the same layer or ACCESSPT to define a connectivity relationship for an access point. It should be appreciated that attributes on the xxxAssoc and
  • xxxAssocSpec classes can be used to define characteristics of the interaction relationship in detail. It is envisaged within the scope of the present invention that the attributes on the xxxAssoc and xxxAssocSpec classes can be extended to include additional attributes or attribute types to accommodate variations in connectivity and containment relationships from those described in the above examples.
  • This second embodiment of the invention also allows adaptation of existing information models to the graph based structure of embodiments of the present invention while retaining the overall structure and usage style of any such existing information model.
  • the inheritance hierarchy of existing information models may require some modification to adapt them to the graph based structure of the second embodiment of this invention. Some associations in existing information models may become redundant, but would remain usable.
  • This can enable architecture defined using an existing information model and modified for the graph structure to be traversed by business logic operating both at the abstract class level using the graph structure supported in this invention and also by business logic adapted to traverse associations present in the original design of the existing information model. For example, relocation of inheritance associations from a super class in an existing model to the relevant abstract super class described by this invention (e.g.
  • Node, Vertex or Edge may mean that some superclasses in the existing information model may cease to be relevant in the graph based structure. These may be left in place in order to maintain the ability for existing/legacy business logic to traverse the information model as if unmodified.
  • existing information models may be adapted to inherit from and therefore utilise the graph based model structure of embodiments of the present invention, without any modification to the inheritance structure of the existing model.
  • layers and associated viewpoints can be defined for each layer and attributes for graphical presentation of each resource object defined for each viewpoint as described above.
  • the classes for definition of layers and viewpoints, and the ResourceLocalLocationSpecification and ResourceLocalLocation classes for defining presentation attributes for each applicable viewpoint for a resource are not shown on Figures 39 and 40, but it should be appreciated that these may be added and used similarly to the model of Figures 5 and 6. It should also be appreciated that the features described below using examples employing the object model of the first embodiment are also applicable employing the object model of the second embodiment.
  • Any resource specification object acting as the root object within a product component item structure can be specified as supporting Mockup state.
  • Mock objects are intended to have the same semantic meaning as their fully specified object counterparts, which may potentially have one or more levels of child object hierarchy.
  • For objects created in mockup state instead only a single resource inventory object is created, mirroring just the root specification object. The system will not generate inventory items mirroring child resource specification objects for the product component item structure concerned.
  • Any mock object will usually have the same appearance as a fully specified object of the same type, when it is in the
  • Mock items allow a user therefore to quickly generate a 'mocked up' resource inventory design, as though they are using simple object shapes within a generalised diagramming / drawing tool, avoiding any detailed specification structure validation or rule evaluation, at that stage. Normal treatment of containment, connectivity, layering and role related rules are relaxed by the system with reaard to obiects beina used in mockup mode.
  • Mock objects can therefore allow a User to freely 'map out' an intended framework of objects at a high level and any type of potential connectivity associations between them, in much the same was as using a general purpose diagramming tool that imposes very few restraints on object linkage rules.
  • mock items can be re-classified into fully specified resource items.
  • System architectures containing mock object items may be sent as a notification to multiple other parties, such as supplier partners, indicating the general intention for a structural change to resource inventory.
  • the notification may include a request to re-classify any mocked-up objects contained in the system architecture to fully specified object types.
  • the finished result could represent a solution proposal submission from that supplier partner.
  • the system may provide warnings if connectivity rules belonging to the object types concerned are not realisable in any way in future conversion of the object to a fully specified type object.
  • connectivity relationships should normally only exist between objects situated within the same Layer. This is the case with respect to resource inventory objects in either the detailed planning lifecycle state, in an approved operational state, or in a retired or decommissioned state. It is normal however that during early planning lifecycle stages, intended connectivity and containment structures may only be known at a loosely defined level. It should be possible therefore at this point to use very simple early stage representations of resource object types and any connectivity associations between them, within any layer, rather than being forced to fully describe detailed containment structures in order to be able to then connect valid connectivity associations through to specific child items within those containment object structures (perhaps across Access Point boundaries). Because the term 'planning' is intended to refer to the
  • 'Mock' object has been chosen instead to describe these early or replacement stage object representations. This is in keeping with a general namina pattern used in various industries and knowledge domains whereby 'mock' objects are used to represent the initial existence of something that will be expanded or replaced with a detailed representation at a later point.
  • Layering rules are also relaxed for mock objects, allowing Mock objects to be placed within any available layer.
  • a mock representation of that object type can represent the intention to ultimately implement a complex resource structure that extends across multiple layer types.
  • the inclusion of a mock object into a single existing resource layer, as a part of an expansion/change planning exercise, may therefore be interpreted as implying that connectivity associations are being formed between differing layer types. In fact they indicate an intention to form regular connectivity associations within other layers at a later point in time.
  • layering rules as defined within the configured structure of the associated product component item structure must be obeyed.
  • Mockup objects may aggregate capacity, usage, fault rate or any other form of relevant information from child specification or inventory items.
  • a resource object is reclassified from mockup to fully specified state, it should be possible to substitute any other resource object type. Regardless of which specific product component item specification is chosen, all of the structural rules associated with that item must be obeyed, and/or appropriate warnings generated and/or logged.
  • searching for replacement objects requires/provides Roles, capacity specifications and other characteristics of the resource specification that define the mock object can be used to refine search result sets for suitable
  • Capacity Spec 550 items could be specified against ResourceSpecification items with MockupAllowed configured as true, such that any real product selected for fulfilment of a derived mockup item must support at least the minimum quantities of the defined capacity specs (or else an Alarm would be generated and/or the user prevented from
  • Capacity Spec items may have a notion of a generalised 'type' associated with them also - e.g. 'INTEL x86', or 'INTEL Itanium' etc.
  • a generalised 'type' associated with them also - e.g. 'INTEL x86', or 'INTEL Itanium' etc.
  • the Customer may not want co-operating supplier / partner organisations to be provided with information regarding the detailed composition of specific resource inventory items within the customer's existing network, for example at early stages of the planning or engagement cycle. To effect this, the Customer may create a Planning copy of the relevant
  • a system defined using one or more existing information models can be transformed to the information model of embodiments of the present invention without losing their original architecture definitions, and so may be used compatibly with business logic operating for both the existing information model and the information model of the present invention.
  • ContainConnectlnteraction classes for the first embodiment and association classes for the second embodiment ContainConnectlnteraction classes for the first embodiment and association classes for the second embodiment.
  • self-referencing class model structures are made available for many class types as a generalised modelling pattern, without description as to their specific use, or support of specific attributes. It is possible to adapt the design of such an existing self-referencing class association reference for the purpose of implementing the specific containment and connectivity interaction utilisation pattern described in embodiments of this invention.
  • each relevant converted resource inventory object instance could then be traversed by business logic acting at an abstracted level as a Node, Vertex or Edge, via associative containment and connectivity objects, in accordance with embodiments of the present invention.
  • business logic acting at an abstracted level as a Node, Vertex or Edge via associative containment and connectivity objects, in accordance with embodiments of the present invention.
  • node Vertex
  • Vertex Vertex
  • Database object instances could then be traversed simply as Node type objects.
  • New Interaction specification objects must of course also be created based on existing association relationships.
  • ContainConnectlnteraction classes as per the first embodiment. For example, with respect to existing resource inventory object instances, if an existing Cable object was directly associated to two existing PhysicalPort objects, it would be necessary to create two new CONNECT type Interaction objects for association at each end of the Cable (Edge) object (between it and each of the PhysicalPort objects). The original
  • the old form of existing model association types may be retained and managed in conjunction with the corresponding new model elements.
  • ResourceLocalLocationSpec DisplayStyleSpec, LayerSpec and ViewPointSpec objects together into a single identifiable unit, suitable for inclusion into a product catalog.
  • This structure is referred to as being a product component item object set.
  • ProductSpecification has a special association to the 'root' ResourceSpecification object, which will usually have the same name as the ProductSpecification object.
  • Other grouping techniques are possible, such as using the root ResourceSpecification, or using a CompoundResourceSpecification object type. Any grouping technique is considered within the scope of the present invention.
  • a product component item object set can make reference to any number of other product component item object sets in order to configure allowable association relationship rules. This type of cross referencing is necessary for most component item definitions. Any product component item object items referenced in this way do not become 'owned' by the referencing objects, they simply become associated product component item object sets that they are dependent on.
  • a convention used for product diagrams used in this example can be explained with reference to Figure 11 , which is an example product specification structure that conforms to the framework of the invention. In the following diagrams, 'referenced' objects belonging to other product component item object sets have a dashed border. Any such referenced object will be the 'root' resource specification item of another product component item object item being referenced.
  • Other object types that are not directly owned by the component specification being defined are also shown having a dashed border, such as LayerSpec items etc. Those objects that are owned as a core internal item of the component specification being defined are shown with a solid border.
  • Complex resource item structures may be built up at run time by selecting compatible component specifications from the relevant product catalogs, and placing them into compatible locations within existing resource inventory items, in turn situated within the overall resource inventory management domain being manipulated.
  • the system creates a mirrored structural representation, using Inventory Model based counterpart objects, of the Specification Model objects that are directly owned by the resource catalog item type being added.
  • Inventory Model based counterpart objects of the Specification Model objects that are directly owned by the resource catalog item type being added.
  • These new objects are added as members to the resource inventory management domain being manipulated at the time.
  • the new inventory objects are firstly associated back to the specification objects they are derived from for future reference / validation purposes. They are next associated to the connecting and/or containing resource inventory objects the user has selected as being the targets of the addition operation.
  • Any such connecting or holding target object must be an implementation of a required / compatible related object defined in the product component item specification of the item being created. From the perspective of the component product item definition of the item type being added, this will be seen as a related specification object having a dashed border in the
  • the ProductSpecification diagram convention used in this design depicts: the high-level product item being described, the root and any other resource specification objects, Specification of ResourceRoleSpecs; Specification of containment and connectivity relationships.
  • the product items depicted represent product subcomponents that would typically be packaged with each other subsequently in order to produce what a customer would recognise as a familiar product item (having a complex make up).
  • Product items should ideally be structured such that a recognisable resemblance or meaning exists between resource types as they exist as engineering level structures and component product item definitions that can be added to Product Catalogs & made available to Users.
  • Each diagram contains a root ResourceSpecification object 1110, referenced by the AtomicProductSpecification object 1120.
  • the diagrammatic line connector shown between these two particular items is the only one shown with doubled line weight.
  • This pair of objects represents the specific product resource element being defined on the diagram.
  • Any other resource specification objects 1 112, 1114 define either containing resource object types, contained resource object types, or resource types that support connectivity relationships. ContainConnectlnteractionSpec
  • Interaction specification objects 1 116, 11 18 show containment relationships using » and « symbols. Where the symbol "»supports»" appears, this indicates that the ResourceSpecification object that is sitting visually in the diagram to the left of the relevant ContainConnectlnteractionSpec object is a container of the
  • AtomicProductSpecification item 1120 which is the grouping object for all other objects visible in the diagram from a business logic perspective.
  • AtomicProductSpecification 1 120 as part of a Catalog query will usually be done in conjunction with all other object items seen in the diagram to be loaded with it, including any referenced object items. All visual items depicted with a solid border are those defined (created originally) in the context of this particular
  • AtomicProductSpecification 1 120 All visual items with a dashed border are those that have been defined Outside' this AtomicProductSpecification defintion, but are referenced by it. Referenced objects may belong to other component /
  • Referenced objects may also exist as generalised items in the system, not belonging to any particular product component item specification.
  • CapacitySpec, DisplayStyleSpec and ViewPointSpec types fall into this latter category.
  • Objects which describe how the object concerned is managed from a layering perspective within the user interface can also be shown. These objects can define layer and viewpoint associations.
  • ResourceLocalLocationSpec items 1 130 1140, shown with a solid border are defined (created originally) in the context of this particular product component item specification.
  • LayerSpec items 1150, 1 160 shown with a dashed border are not owned by any specific product component item specification.
  • the presence of and association to LayerSpec items 1150, 1160 indicates that resource instances derived from this particular product component item specification can appear in view point representations belonging to these two 1 150, 1160 layer types.
  • Figure 12 An example of a fixed hierarchical container specification structure is shown in Figure 12 which is an example of a structure for 'Windows 2008 Standard Edition'
  • ContainConnectlnteractionSpec 1220 for items in a multi-level hierarchy for 'Package Containers' 1230, 1250, 1255.
  • Package is a term meaning 'installed software application, script or device driver' relevant generally in the context of system/software implementations, including Unix, Linux, Routers, Windows, Commercial or Open Source Applications etc).
  • This specification structure allows two types of package containers of types 1250, 1255, to be contained under umbrella package containers of type 1230 in a single level of hierarchy, meaning in a fixed, non-recursive manner.
  • Package containers of types 1250, 1255 are able to provide containment to Windows 2008 specific packages and general windows packages respectively. Any package items contained within either a Windows 2008
  • Node ResourceSpecification 1230, 1250, 1255 items are associated to the same 'Package Container' LogResRoleSpec item 1260. Awareness of these structures needs to be implemented into any relevant business logic implementations, such that they are able to recoanise that the same LogResRoleSpec item 1260 is being encountered during traversal of any such structures.
  • Certain container structure types must support any level of hierarchical depth and potentially even dynamic extension of such hierarchical structures of the same derived resource object type by Users at run time.
  • Windows Group items which are access security grouping items in the Windows operating system, may be added at run time as members of other existing Windows Groups. It should be possible create and add child Windows Group items within other parent Windows Group items, to whatever level of hierarchical depth is required by the User.
  • Support for specification of dynamic hierarchical containers requires creation of additional component product specification items (as compared to support for fixed hierarchical container structures, which do not).
  • Interaction spec 12A20 has supports and supportedBy associations that are both assigned to Windows 2008 Group 12A10.
  • This specification model structure allows an existing Windows 2008 Group resource item to act as a container for another Windows 2008 Group item.
  • a Windows 2008 Group can be added as a hierarchical child of another parent Windows 2008 Group, according to the structure indicated in this example, at least the initial Windows 2008 Group must have been added to an existing Windows 2008 Active Directory resource item 1240.
  • An example of Windows 2008 Group resource items structured in this way is provided in Figure 12B.
  • a single Windows 2008 Active Directory 1240 object can be seen supporting a contained Windows 2008 Group 12B20, in turn supporting multiple contained children / grandchildren Windows 2008 Group objects 12B30 in a
  • ContainmentOrConnectivityType attribute value of SUPPT An example of this is given in Figure 12C, for a 'BroadCom Ethernet NIC NetXtreme Device Driver' 12C10. This defines the specification model structure for a device driver software product component item that supports the operation of a set of physical Ethernet network adapters manufactured by the same company 12C20, 12C30 & 12C40.
  • the presence of the SUPPT attribute value indicates that establishment of derived containment associations will require inter-layer handling, potentially causing additional catalog fetch & Ul management operations etc.
  • the same product component item definition also includes COMPNT type ContainConnectlnteractionSpec references 12C50 & 12C60 to resource spec items 1270 & 12C80 that may act as containers within the same layer type. Note that diagram 12C omits ResourceLocalLocationSpec & LayerSpec objects for the sake of simplicity.
  • ContainConnectlnteractionSpec objects 12C50 and 12C60 This configuration specifies that any BroadCom Ethernet NIC NetXtreme Device Driver 12C10 instance can form a containment association with only one of either a Windows 2008 Device Driver Container 1270, or a Windows 7 Device Driver Container 12C80. This is in addition to containment relationships to the various physical network cards specified, of which there may be multiple instances of the same or different types present (hence there are no OptionGroup constraints specified against these object types). Physical network cards of types 12C20, 12C30 & 12C40 may in turn be contained within the same parent object (likely to be a Chassis type object).
  • Certain types of containing resource specification objects may be intended to conform to a standardised specification that is utilised by numerous other containing resource specification objects also.
  • a resource node container representing a physical Slot as might be available on a computer chassis, as being compatible with the PCI standard.
  • standardised containment & connectivity specifications including support for: backward compatibility, directionality, 'ganging' of adjacent slots or ports, feature set capabilities, speeds, protection etc.
  • a number of existina standards-based approaches for the management of such generalised containment & connectivity compatibility capabilities can be added to support this aspect of the structure of this design.
  • FIG. 12D An example of this is illustrated in Figure 12D.
  • a Unidirectional Trunk Link 12D10 is described having CONNECT type connectivity interaction association objects 12D30 & 12D40 specified in conjunction with vertex type resource specifications 12D50 & 12D60 having Context type ⁇ End' and Context type ⁇ End' respectively. Instances of this link type may therefore be formed where one end of the link connects to one vertex type resource implementing ⁇ End' meaningfulness with respect to the connection, and another implementing the ⁇ End'.
  • 'Access Point' is a term used to refer to a logical resource that provides connection point capability in particular for internally situated software resource items, where a connection point capability is defined to exist at an outer boundary interface layer in the architecture of the software resource type concerned.
  • the high level parent software resource type may have many internal software component objects of one or more types that can be connected to, but only via such an interface located at the outer architectural boundary of the parent.
  • Example Access Point implementations may include Application Programming Interfaces, SOAP/Web Services interfaces, middleware / messaging system interfaces etc.
  • Access points enable connectivity therefore into internal logical resource objects contained somewhere within a parent logical resource object.
  • the parent logical resource acts as both a container to the internal resource being connected to, and also as a boundary location at which external required connection point capability for the internal resources is located.
  • Access points located on SQL Server RDBMS Instances provide interface connection capability to internal RDBMS logical resources such as Database or Reporting objects.
  • the framework of the present invention enables internal resource object instances to be contained to any level of nested hierarchical depth within a parent owning any access points relevant to the internal resource objects concerned.
  • FIG. 8 to 10 A simple access point example is shown in Figures 8 to 10.
  • the application layer 810 shows two database instances 812, and a database replication association 818 between two databases 814 situated within the two database instances 812.
  • Figure 9 also shows database replication association 818 present in an object instance representation.
  • Real database objects are internally contained objects of database instances, and the only form of external access to them is via connection points defined on the database instance parent object. Configuration of both the relevant database instance connection point and also the particular database endpoint reached via that connection point must usually be managed for each end of real world database replication objects.
  • Figure 8 shows the presence of such an external point of connectivity, Access Point 1050 on the Database Instance 812 that is allowing connection through to the Database 814 contained within the Database Instance 812.
  • Figure 10 shows how the first embodiment of the framework supports an implementation of a fully described structure showing an Edge type resource object connecting via Access Points into internally situated Node type resources, and also supporting items objects in lower layers. Items depicted are expressed as object instances at the abstract graph-structured common model element level.
  • All resource inventory objects shown are represented abstracted to their respective resource specification of type node, resource or edge in accordance with the framework of the present invention. It can be seen that the database instances 812 are abstracted as Node type resource objects 1012, access points are abstracted as vertex type resource objects 1050 and the containment/connectivity relationship between the Node 1012 and the Vertex 1050 is implemented as a COMPNT type ContainConnectlnteraction relationship object 1055. The ContainConnectlnteraction relationship object 1055 enables the access point 1050 to act as a connection point for the Database Instance 1012.
  • a ContainConnectlnteraction relationship object of ACCESSPT type 1058 is defined between the access point abstracted as Vertex 1050 and the Database Replication abstracted as the Edge 1018.
  • the Database Replication abstracted as Edge 1018 provides a connectivity relationship between the two Database Instances abstracted as 1012 via the respective access points abstracted as 1050.
  • a ContainConnectlnteraction relationship object of ACCESSPT type 1059 is defined between the Database replication abstracted as Edge 1018 and the Database endpoint object abstracted as the Node 1014.
  • ContainConnectlnteraction relationship objects 1058 and 1059 configures the Edge instance 1018 in a manner that makes visible both the relationship with the Vertex instance 1050 acting as an externally accessible Access Point and the relationship with the 'internal' Database instance 1014, which are the external & internal pair of objects referenced by one end of the Database Replication 1018 Edge object, to thereby define the access point relationship.
  • objects 1058 and 1059 are not themselves Access Point objects, but rather are ContainConnectlnteraction relationship objects having
  • the ContainConnectlnteraction relationship object 1059 defining the access point relationship between the Database Replication Edge type object 1018 and internal Database instance node object 1014 imposes an additional limitation on the relationship defined between the Access Point Vertex 1050 and Database Replication Edge 1018, to define the end point of the access point connectivity relationship and thereby complete the access point definition.
  • ResourceSpecification edge type objects that are required to form Access Point based connectivity relationships with them.
  • Vertex type resource specification objects providing connection functionality associated with the relevant Vertex type resource specification objects. It can be considered that a vertex type object has potential to provide access point functionality but this potential is not realised until a connection is configured that associates the vertex and an internal node which is the ultimate end point of the connection.
  • SQL Server Instance 11 10 An example of an internal sub-object type of SQL Server Instance 11 10 is a SQL Server Database specification object 1350, as seen in the SQL Server 2008 Database product component specification structure shown in Figure 13A. It is clear from Figures 13 and 13A that both the SQL Server Net Connection Point 1310 and SQL Server Database 1350 object specification types are contained by the same SQL Server Instance 1 110 object specification type.
  • Connection Point object specification type 1310 can potentially therefore be configured for Access Point use into nodes of SQL Server Database specification type 1350 situated within parent nodes of the same SQL Server Instance of specification type 11 10.
  • Figure 14 shows definition of an Edge type ResourceSpecification object that is configured to form Access Point based connectivity relationships.
  • Edge type ResourceSpecification object that is configured to form Access Point based connectivity relationships.
  • ResourceSpecification 1410 is defined within the component product item named 'SQL Server 2008 Database Replication' 1420. Instances of this component type allow connectivity links to be formed between SQL Server 2008 Database 1430 items via SQL Server 2008 Net Connection Point 1310 objects, configured in this component product item specification structure to act as Access Points.
  • Each of the ACCESSPT type interaction specification objects 1440 and 1450 is associated to both the SQL Server 2008 Database 1430 (node) specification object, and the SQL Server 2008 Net Connection Point 1310 (vertex) specification object. This results in two ACCESSPT interaction inventory objects being created at each connection end of any particular SQL Server 2008 Database edge inventory object. Each end of any SQL Server 2008 Database edge inventory object will therefore have one ACCESSPT type interaction object associated to a SQL Server 2008 Database 1430 node inventorv obiect, and the other to a SQL Server 2008 Net Connection Point 1310 vertex inventory object.
  • Each of these ACCESSPT type interaction inventory object pairs will be set to the Context type of the relevant specifying interaction specification, resulting in one pair of interaction inventory objects having a Context of 'SourceDB', and the other having a Context of TargetDB'.
  • Access Point type specifications are by definition implemented within component product item specifications using a structural pattern based on
  • ContainmentOrConnectivityType attribute value of 'ACCESSPT' must: a. Reference a single Node type ResourceSpecification object
  • This Node type ResourceSpecification represents an 'internal' resource object type being ultimately connected to; and b. Reference a single Vertex type ResourceSpecification object that belongs within another component product item that is situated within the parental hierarchy of containing product component items of the Node type ResourceSpecification object referenced in (a). This Vertex type Resource Spec represents an Access Point for the internally situated object defined in (a).
  • an Edge type ResourceSpecification In order to configure an access point connectivity specification an Edge type ResourceSpecification must be created and have two connectivity relationship specifications defined: a first to the access point (vertex) type which is contained by the parent system component (node) type; and a second to the internal system component (node) type, inventory instances of which are the ultimate end points of access point based connections and which are contained by the same parent (node) components as the (vertex) access points.
  • Access Point connectivity relationships between edges and internal nodes cannot exist without the associated edge and vertex relationships. This edge and internal node relationship imposes additional structural and lifecycle constraints on the edge vertex relationship. Presenting; the ultimate end point node of an access point based connection in relation to the edge object and associated access points can assist recognition and interpretation of the entire relationship chain by users.
  • ContainmentOrConnectivityType attribute value of 'ACCESSPT is defined for an Edge with reference to both a Vertex and a Node which is the endpoint of the connection. As can be seen from the example of Figure 14 this also enables visibility of both the access point (vertex) system component and internal system component (node) being connected to in the specification model.
  • 'SQL Server' is a proprietary product and trademark of Microsoft Corporation.
  • Database Replication structures are generally intended to allow synchronisation of database contents between related copies of the same database representation.
  • the example in Figure 14 defines an edge (link) type construct connecting via SQL Server 2008 Net Connection Points through to SQL Server 2008 Database type objects having a Context at one end of 'SourceDB' and TargetDB' at the other.
  • the configuration of the two ContainConnectlnteractionSpec ACCESSPT type objects with 'V based values for Multiplicity define this edge spec as being a "point-to-point" type edge/link definition.
  • Each of the ContainConnectlnteractionSpec objects depicted references the same Vertex type ResourceSpecification Access Point definition.
  • each end of the edge object must connect to a SQL Server Net Connection Point type vertex inventory object. These connections may be to the same SQL Server Net Connection Point inventory object instance, or to different SQL Server Net Connection Point inventory object instances.
  • the specification of whether different Access Point inventory object instances must be present at each end of Edge/link instances or not can be managed by another specification type attribute indicating whether this type of connection is allowed. If more flexibility is required regarding the meaningfulness of endpoint object types, the Context attribute can instead be implemented a sub type of ResourceRole, as for example per the SID model which supports configurable ResourceRole type definitions. The choice of approach does not affect the underlying principles of this design.
  • FIG. 15 Another example of a database replication is shown in Figure 15 which defines edge type ResourceSpecification 1510 within component product item 'SQL Server 2008 / Oracle Database Replication' 1520.
  • 'Oracle' is a proprietary product and trademark of Oracle Corporation.
  • This structure defines a hypothetical Database Replication structure that may be used to connect SQL Server 2008 and Oracle Database objects in a Replication relationship (assumina that such a relationship was possible with these products).
  • the appropriate Vertex type ResourceSpecification objects 1310 & 1590 have been established to support this type of connectivity relationship in terms of the required ContainConnectlnteractionSpec 1570 & 1580 and Node type ResourceSpecification 1430 & 1560 objects.
  • this example also illustrates the potential to use a 'many' type Multiplicity on one of the ContainConnectlnteractionSpec 1580 objects.
  • This example implements a "point to multi-point" style edge/link spec, in this case allowing a single SQL Server Database to be connected to one or more Oracle Database objects.
  • Access Point definitions are not simply endpoints defined as being able to support connections somehow with respect to specific internally situated object types.
  • Access Point capability supports the structured establishment of related endpoint, internally situated object and edge/link layer specification definitions, enabling fully traceable connection path/graph support across all related objects within any specific Access Point connectivity scenario.
  • the model elements and structure associated with Access Point based connections provide an unambiguous engineering perspective of all objects involved, and their roles with respect to each other.
  • Embodiments of the present invention provide a graphical user interface which is configured to represent system architecture utilising the viewpoint features described above. Further, the GUI enables creation and modification of objects visibly within any particular viewpoint, with reference to product specifications from one or more catalogs, automatically making corresponding changes to the entire object model including objects not displayed in the currently visible viewpoint or layer.
  • Figures 16 to 23 show examples of various visual aspects in the user interface relevant to: Visual presentment of resource objects across multiple layers & viewpoints; Layout mode (within current viewpoint selection); Folding mode operation; and Layer navigation.
  • Figures 17 to 23 are intended to be regarded as what would be seen in the ManagementDomain Display Region of a functioning Resource Inventory Management application.
  • This management domain disolav reaion 1600 is shown in Figure 16 which shows an example of a screen shot of an embodiment of the graphical user interface.
  • the images used to represent resource elements are defined in the specification model using display style specifications.
  • Figure 17 shows an object model of a physical drive enclosure 1700 system
  • FIG. 17 Also shown in Figure 17 is an example of a corresponding GUI representation of this model from a physical layer front elevation viewpoint showing a representation of physical drive enclosure 1700, physical drives 1710 and vacant drive slots 1720.
  • Figure 18 shows a representation from a storage group viewpoint where logical resources defined in the storage layer are shown as well as some containing resource elements from the physical layer which support the implementation of the logical storage layer resources.
  • the storage layer shows the logical resource objects being managed which are storage groups 1810, which includes nested logical resource objects storage group set A 1820 and storage group set B 1830, and their respective nested Logical Unit Number (LUN) objects 1825, 1832, 1834. It should be appreciated that the nesting of the storage group sets and LUN objects represents containment relationships for these logical resources.
  • Figure 18 also shows representations of the physical drive enclosure 1700 and physical drives 1710.
  • the physical enclosures 1700 and physical drives 1710 are 'containing' objects for the LUN logical resource objects 1825, 1832, 1834, with the containment relationships indicated by lines 1840.
  • Some of the objects displayed may be displayed in viewpoints relevant for both the Storage and Volume layers (for example 'Storage Group' and 'LUN' objects, and not the 'Storage Groups' parent object). It should be noted that in the example of this viewpoint it is the storage layer being managed in terms of object lifecycle (create, remove, change etc). Users may be prevented from modifying the physical layer objects represented - these objects exist in this viewpoint example to allow visualisation and management of containment referencing by Storage layer objects.
  • the physical enclosures 1700 and storage groups 1810 objects as depicted may potentially not form part of the resource inventory structure, but instead be transient Ul framework objectss used as visual containers for similar classes of resource object type.
  • FIG. 19 An example of a viewpoint of a logical volume manager is shown in Figure 19.
  • logical volume groups 1910 are managed. However, containing resource elements from the physical and storage layers can also be shown.
  • Elements in the left hand side include physical drives 1710, drive partitions 1970 and logical unit numbers (LUNs) 1832, 1834.
  • LUN resource elements 1832, 1834 are visible in both the storage layer and volume layer.
  • SAS Disk resource elements 1710 are physical layer elements.
  • Partition element 1970 is a storage layer element, but may be managed using a different viewpoint to the LUN storage group viewpoint shown in Figure 18. These objects are managed in the Physical and Storage layers, but appear as containing objects in the Volume layer. In this context, these are all grouped visually as 'Physical Volumes'.
  • any left hand side element can be assigned to a single Logical Volume Group 1920, 1930, 1940 on the right hand side.
  • Logical Volumes 1922, 1924, 1932, 1934, 1942 may be created within Logical Volume Groups 1920, 1930, 1940. It is not a rule that objects on the land hand side group must be containing objects, and objects on the right hand side group must be contained/managed objects, or that only two groups be present within any viewpoint visualisation. Relative user interface positioning of containing and managed items may be configured as is appropriate for the object types concerned. This may result in 'network' style visual structures as seen in Figures 22 and 23.
  • the Capacity assigned to each Logical Volume is allocated from the total capacity available in the Logical Volume Group parent object (this is in turn an aggregation of the total capacity of all physical volumes assigned from the left hand side).
  • This behaviour can be driven by business logic that is defined to operate both with relevance at the common model element level, and also with respect to any item specific rules relevant to the resource types concerned.
  • Figure 20 shows a representation of the host system melmxl from an Operating System to Volume viewpoint, including primary operating system 2010 component elements 2020, 2030, 2040, 2050 and allows management of these. Shown on the left hand side are Volume resource elements 2060, 2062, 2064, 2066, 2068. In this viewpoint it is possible to assign operating system components 2020, 2030, 2040, 2050, to storage elements 2064, 2066, 2068.
  • Figure 21 shows a representation of the Network layer from a Connection Point viewpoint. This viewpoint shows connection points 211 1 supported by the host svstem melmxl 21 10 and available for connection in the Network layer.
  • FIG. 22 shows a number of elements present at the network layer.
  • the high-level elements shown support Folding, this is recognisable by the '+' 2210 and '-' 2220 symbols at the top left of their icon representations.
  • Two items have been expanded (unfolded): melvml 2230, as represented in the Host layer in Figure 21 , and meldistl 2240, a gigabit Ethernet switch equipment item.
  • the unfolded state of the melvml and meldistl items allows inspection & connection management access to the connection port items contained within them.
  • this Layer Type only shows ConnectionPoint and VLAN type objects, as these are the only items configured for management in this
  • Network Layer, Connection Point viewpoint representation Other Network Layer view point configurations may be established to present additional or different network object types, such as VRF, MPLS, SONET, GPON, MEF objects etc.
  • An example is shown in the case of physical port GeO 2240, which is a member of both VLAN1 2260 and VLAN2 2270.
  • Another viewpoint may be defined within the same layer that shows each physical port only once, but contains more than one representation of the same VLAN item where an association exists to more than one physical port.
  • Figure 23 shows elements 2230 & 2240 of Figure 22 in their collapsed state.
  • This Freeform Network layout mode can be used within any relevant layer type - for example in a SQL Server Replication Network view (a form of Application Network Layer Type), only SQL Server Access Point and Database items would be visible (Database items are relevant because these are the 'internal items' that the Access Point provides connectivity access to in the context of SQL Server Replication).
  • element mel1 2270 in an expanded state. It can be seen that although this object representation exists within the same viewpoint/layer based display as elements 2230 & 2240, the Freeform Network layout mode is use within this object. This can be seen in the way objects are placed freely within 2270, with connectivity links in place as is appropriate. By comparison, in Figure 22 the elements 2230 & 2240 are shown in Hierarchical layout mode.
  • Figure 24 shows a simple example of model elements beside a representation of those same elements as seen from the user interface.
  • Elements represented in the Ul representation 2400 correspond to resource objects in the model 2405.
  • An item such as the 'MEL_SQL_SRV_1 ' SQL Server 2008 Resource object 2410, 2420 would typically contain multiple levels of child items that would quickly overwhelm the level of detail appropriate for the viewpoint shown.
  • These child objects are connected to the 'MEL_SQL_SRV_1 ' SQL Server 2008 Resource object 2410 in the model, but are only assigned via ResourceLocal Location objects to the 'SQL Server' Layer in order to omit them from appearing in the Ul presentation of the viewpoint shown in Figure 24, which is not specific only to SQL Server.
  • Double clicking the 'MEL_SQL_SRV_1 ' SQL Server 2008 Resource object 2420 in Figure 24 will cause the system to present the detailed Ul viewpoint for the 'SQL Server' Layer for that object as seen in Figure 25, showing the associated child objects 2510 that are assigned to the 'SQL Server' Layer.
  • the representation of the model for these child objects shows the relevant supporting Resource objects 2520 in the Operating System and Volume layers.
  • the Host Layer objects shown to the right of the dashed vertical line do not belong to the 'SQL Server' Layer (as per their associated ResourceLocalLocation to Layer associations), and therefore do not appear visually among the Ul elements shown - hence these objects are shown having a white background. Even though they are not visible in the SQL Server Layer, these objects are represented here to indicate that they are present in the background model.
  • Figure 26 shows a pre-state prior to creation of a new Physical Link between Physical Port objects situated on different Management Domains accessed on separate Ul views.
  • Management Domain A Ul view 2610 shows a physical layer representation 2630 of a chassis and its associated physical ports.
  • the associated object model 2635 for management domain A is shown below.
  • Management domain B Ul view 2620 shows a physical layer representation 2640 of another chassis and its associated physical ports.
  • the associated object model 2645 for management domain B is shown.
  • Figure 27 shows a post-state following creation of a new Physical Link 2750 between Physical Port objects 2634, 2644 situated on different Management Domains 2632, 2642.
  • the physical link can be created via a single continuous drag and drop gesture of the Ul. It should be appreciated that both domains 2610, 2620 mav not be able to be presented side by side by the Ul, for example due to screen size, so the Ul may provide thumbnails 2610', 2620' to facilitate navigation between domain representations.
  • the user initiates the drag and drop gesture by the user clicking on and dragging a connectivity link from a candidate connection point 2730 on a source object 2630. This also initiates the creation of an interaction specification object 2735 and physical link object 2750 in the model 2635'. The user can extend the drag operation beyond the boundary of the domain that the source object is located within and select (and enter) a target domain from an adjacent list of potential target domains.
  • dragging from the management domain A Ul view 2610 to the thumbnail 2620' for management domain B Ul view 2620 will cause the Ul to switch to the management domain B Ul view 2620 where the drag and drop operation can be completed by attachment of the connectivity link to a candidate connection point 2740 on the intended target object 2640.
  • Thiumbnail images are provided as an example means to select between alternative management domains. Alternatives to this approach could include presentation of simple tabs, or icons, etc.
  • the cross boundary connection is represented by links 2732, 2742 to off page connectors 2731 , 2741.
  • the completion of the drag and drop operation over the target connection point 2740 also causes an interaction specification object 2745 to be created in the model 2645' to complete the definition of the physical link 2750 connection.
  • a simple gesture in the Ul can cause the appropriate objects to be created in the model.
  • an existing connectivity endpoint can be modified by detachment of the existing connectivity attachment endpoint, extension of the connectivity drag operation into another target domain and completion of the drag and drop operation as per above steps.
  • the interaction specification object for the connection endpoint being modified is modified in accordance with the newly selected end point, or the interaction object deleted and a new interaction object created for the newly selected endpoint.
  • Detachment of an existing connectivity attachment endpoint, followed by extension of the connectivity drag operation over a Trash Can results in deletion of the connection and associated deletion of interaction specifications at each end of the connection as well as the connectivity object (for example the physical link edge object) itself.
  • Embodiments of the present invention enable a change to be made in one viewpoint and the effect of the change also made visible in another viewpoint.
  • FIG. 28 shows a pre-state Ul representation from the logical volume manager viewpoint, showing all object types relevant to the viewpoint. Only the logical volume objects 2800 are managed in terms of their own lifecycle in the viewpoint of Figure 28.
  • Figure 1 shows a pre-state Ul representation from the logical volume manager viewpoint, showing all object types relevant to the viewpoint. Only the logical volume objects 2800 are managed in terms of their own lifecycle in the viewpoint of Figure 28.
  • FIG. 29 is an alternative representation of the pre-state of Figure 28 showing all model objects relevant to the logical volume manager viewpoint but only the Ul representation of the logical volume objects 2800 for simplicity of the diagram.
  • Figure 29 shows three logical volume groups 2910, 2920, 2930.
  • Logical volume groups 1 2910 and logical volume group 2 2920 are both contained in security zone Tenant A 2940, with the containment relationship defined in interaction objects 2942, 2944.
  • Logical volume group 3 2930 is contained in security zone Tenant B 2950, with the containment relationship defined in interaction object 2952.
  • This security zone assignment of logical volume groups is shown in the data model 2900 although not represented by the Ul 2800 in this viewpoint.
  • Figure 30 shows a pre-state Ul representation 3000 of the
  • Figure 30 clearly shows the assignment of Logical Volume Groups 1 and 2 2910, 2920 to security zone Tenant A 2940 and Logical Volume Group 3 2930 to security zone Tenant B 2950. It should be appreciated that Figures 28-30 show different views of the defined model architecture in the same state, before the modification to be discussed is made.
  • logical volume groups can be assigned to security zones using direct drag and drop gestures.
  • the assignment of Logical Volume Group to Security Zones is not seen visually in the Logical Volume Manager viewpoint Ul seen in Figure 29. Note however that it may still be possible to relocate Logical Volume Groups between Security Zones whilst in the Logical Volume Manager Viewpoint Ul using either context menus or other controls available in Ul management panels, perhaps visible elsewhere within the same screen.
  • Figure 31 shows the effect of reassigning logical volume group 2 2920 to security zone Tenant B 2050.
  • the interaction specification 2944 defining the containment relationship between logical volume group 2 object 2920 and security zone Tenant A object 2940 is removed.
  • a new interaction specification 2954 has been created to define a containment relationship between logical volume group 2 object 2920 and security zone Tenant B object 2950.
  • the effect of this change, made in either security zone viewpoint or the logical volume manager viewpoint of Figure 31 becomes visible in the security zone manager viewpoint of Figure 32.
  • the representation of the same model objects in another viewpoint(s) will also reflect this change.
  • Preceding sections in this document have been oriented more towards logical and network related resource structures. Whilst objects from the physical layer may be included within logical representations of resource inventory structures (for example physical disks 1710 within Figures 18 and 19), it is also desirable to depict and manage physical items using representations of their actual physical appearance.
  • a specific 'Physical' viewpoint is supported in this invention that fulfils this purpose. It can support coordinated Front, Rear, Top, Bottom, Left Hand Side, Right Hand Side and Plan elevations of equipment items in their configured state. In order to simplify description of the invention, only Front, Rear and Plan elevations are described in detail.
  • FIG. 17 depicts an example of how a complex configured physical drive enclosure 1700 device appears in the user interface when the User has selected 'Front' elevation for a currently displayed Physical Viewpoint, including contained physical drives 1710 and vacant drive slots 1720. Shown also are the model object items that define the physical items seen. In the context of this example, drive slots are special cases of what are generally called 'adapter slots' in this invention.
  • the system will only allow a device to be inserted into an Adaptor Slot if the device supports the containment, role type any other more specialised definitions contained in the product component item structure definition of the adapter slot concerned.
  • an adapter slot contains a piece of equipment, that equipment item will be visible in the slot's region rather than the appearance of the empty slot or slot cover. If the child equipment item has adapter slots of its own, these will in turn be then visible. and subsequently may have equipment items placed into them.
  • This slot/placement pattern may be nested to any level of depth limited by the engineering architecture of the equipment items concerned, as implemented by the relevant product component item structural definitions.
  • the visual presentation of equipment items and slots may be visually realistic, even to a photographic level of detail, or may be accomplished using less detailed diagrammatic or simple shaded regions to depict the presence of the equipment and slot items concerned.
  • Geometric positioning information for both chassis and adapter slot containing items is defined by ResourceLocalLocation specification objects, associated to a LayerSpec relevant for the Physical layer and to Viewpoints representing the Front and Rear elevation modes within the relevant product component item structures.
  • Equipment objects should typically mimic at least roughly the size and placement of the real counterpart objects represented.
  • connection links can be dragged from or to compatible ports, based on satisfaction of structural component product item definition structures and any other more specialised rules.
  • Plan elevations are diagrammatic layouts depicting adapter slot and connector port elements using the same user interface representation capability as for logical application or network objects, meaning that any combination of the Hierarchical, Icon or FreeformNetwork Layout Modes may be supported.
  • a key feature of Plan elevation is the ability to support adapter slot and connector port elements that are not externally visible on the device concerned. This aspect is described in more detail in the following section titled 'Interior slots and devices supporting external slot availability'.
  • Plan elevations can contain adapter slots and ports that are present also in all external elevations, and also any internally situated adapter slots and ports. It is possible therefore to add a child device to a parent device via either one of the external facina elevations, or within Plan elevation.
  • FIG. 35 An example of a Plan elevation is shown in Figure 35. This shows a resource inventory view of adapter slots of types including DIMM Module Pair slots 3510, Riser Bay Slots 3520, Drive Bay Slots 3530 and Power Supply Slots 3560.
  • DIMM Module Pair slots 1 and 2 are shown as being populated with DIMM memory devices 3512
  • CPU Slot 1 is shown as being populated with a CPU device 3542
  • Power Supply Slot 1 is shown as being populated with a power supply device 3562.
  • Riser Cards are system cards that plug into an internal slot on a Server chassis, and in turn make specific types of children adapter slots available, such as PCI or PCI Express slots, that can contain other devices that have a visible appearance externally, such as PCI or PCI Express cards. Even if such children adapter slots are not populated, they can usually be seen as being present on one of the external elevations for the parent system chassis concerned.
  • Figure 36 shows the presence of the externally visible areas of a server chassis 3610 that may potentially be associated with child adapter slots provided by Riser Cards. Note that any child adapter slots are themselves located within the external geometry of the chassis.
  • Externally visible areas 3620 are associated with children slots provided (contained) by any Riser Card that is contained (plugged into) by Riser Card Slot 1
  • externally visible areas 3630 are associated with any Riser Card that is contained (oluaaed into) by Riser Card Slot 2. Without Riser Cards present, these Riser Card child slots do not therefore exist, and the associated externally visible areas should be displayed as blank slots (i.e. with slot covers in place), and are not accessible for configuration purposes.
  • Plan elevation Figure 35 An example of such an installed Riser Card 3522 is shown Plan elevation Figure 35. Three child PCI Express adapter slots 3524 of Riser Card 3522 can be seen also. With this Riser Card in place, it is possible to add compatible PCI Express type adapters to the child PCI Express adapter slots 3524 as contained (plugged in) items. Addition of compatible PCI Express type adapters to the child PCI Express adapter slots 3524 is possible either in Plan elevation, or in Rear elevation of the server chassis (in the context of the provided example). The User may accomplish this either by dragging and dropping an appropriate PCI Express adapter from an associated catalog list, or by making an appropriate menu selection, etc.
  • Figure 36 provides an example resource inventory object hierarchy of all items from the Server Chassis, through the Riser Card Slot 1 down through to the adapter slot and ports supported on an example PCI Express Multipurpose Adapter Card. This is shown in the lower half of this diagram in resource inventory model form. The upper half of the diagram shows an illustration of the corresponding objects as seen in the Rear elevation of Physical Layer viewpoint.
  • PCI Express adapter 3640 has been added to PCI Express adapter slot 3650 situated on the Riser Card located in Riser Card Slot 1.
  • the external view of the PCI Express adapter presents SD Card adapter slot 3642 and Ethernet connections ports 3644.
  • item 3650 represents the internally situated PCI Express 4x Slot 1 adapter slot on the Riser Card mounted in Riser Card Slot 1. This is not exactly the same thing as the externally visible area associated with it (the topmost of the three 3630 items).
  • the hierarchy of all items in this example from the Riser Card slot down through to the adapter slot and ports supported on the Multipurpose Adapter Card must obey the engineering architecture of the equipment items concerned, as reflected by the relevant product component item structural definitions.
  • interior slot items supporting external slot availability such as Riser Card Slots
  • riser Card Slots it is necessary to configure a value of true in an attribute named interiorSlotltemSupportingExternalSlotAvailability. This is located on the
  • ResourceLocalLocationSpec class associating the ResourceSpecification object representing the Riser Card Slot (in this example) to a Physical LayerSpec object. It is also necessary on the same ResourceLocalLocationSpec object to specify an external geometry reference point relevant to the elevation geometry of the chassis object that will contain the Riser Card Slot being defined (in this example a server chassis).
  • Figure 37 A visual example of this is shown in Figure 37, the top half of which represents the front or rear elevation viewpoint of the user interface view seen during product component item definition for a Riser Card Slot type item.
  • This shows firstly how such a geometric reference point 3710 may be located in support of the definition of Riser Card Slot 2.
  • 3710 is not necessarily an object in the model in its own right.
  • Values 3730 and 3740 could be stored in the parentXOffset and parentYOffset attributes of the ResourceLocalLocationSpec 3760 object associated with the ResourceSpecification 3750 defining Riser Card Slot 2.
  • Figure 38 shows an example product component item definition for a Riser Card. It is necessary to configure a value of true in an attribute named
  • ResourceLocalLocationSpec 3862 object associating the ResourceSpecification 3860 object representing the Riser Card to the Physical LayerSpec 3864 object.
  • the top section of Figure 38 depicts the physical layer front/rear elevation viewpoint of the user interface view seen during product component item definition for a Riser Card type item. Note that the joint reference of both front and rear perspectives refers to the ability of an inventory instance of such a sub-component specification to be placed into either a forward or rearward facing interface slot, potentially within multiple, different parent chassis product types.
  • This final computed offset position, and associated width and length attributes for the child slot defintion may then be used to form the geometric co-ordinates and shape definition for use in presenting a slot cover display object, if one is required. If a child object such as a PCI Express adapter is positioned into such a slot, the same positioning and shape definition information can also be used to achieve visual presentation of the child object.
  • Geometric position offsets on child adapter slots of Riser Cards are able to be utilised regardless of whichever Riser Card Slot any particular Riser Card is inserted into, provided the same external slot positioning pattern is followed across all compatible Riser Card Slots, for any particular Chassis type concerned. If this is not the case, it is possible within the framework of this invention to support more complex specification structures than are described here to support multiple definitions of slot positioning pattern templates for Chassis objects supporting the same Riser Card types but with differing external slot placement.
  • Geometric reference point 3840 represents a single point of reference from which the geometric position offsets on relevant ResourceLocalLocationSpec objects such as 3812, 3822 & 3832 are established during specification item development within the user interface for the Riser Card described. Values for reference point 3840 are stored as parentXOffset and parentYOffset attributes on the 3862 ResourceLocalLocationSpec object (which is linked to the primary RiserCard resource specification object).
  • the parentXOffset and parentYOffset attributes in the relevant ResourceLocalLocationSpec object 3812, 3822 or 3832 are recomputed to reflect the X and Y axis distances from the top left of the child slot object to geometric reference point 3840.
  • FIG 38 is a background rendition of a relevant selected server chassis, which if present allows placement of geometric reference point 3840 belonging to a relevant Riser Card Slot product component item definition by the user in the same location as a selected geometric reference point 3710 (displayed in conjunction with the selected server chassis). With these points in alignment, placement and alignment of geometric reference points belonging to Riser Card Slots against the representation of the location of the same relevant slots in the background server chassis image rendition can be made precisely using a drag style action by the user. This process ensures geometric consistency between instances of these items as defined originally as product component specifications, and when used in conjunction with each other later in the resource inventory run time view.
  • a key factor associated with the emergence of next generation services is the need to achieve 'partitioning', i.e. isolation, between services provided to and between different customers using the same infrastructure. Additionally, within any given customer's infrastructure, further sub-partitioning will usually be required to support differentiated operational processes, service delivery commitments, geographic/location based zones, marketing territories, security zones, security classifications, statutory requirements, or a range of other needs.
  • the system architectural elements owned by any given customer may be of various technology evolution levels, including legacy, contemporary and next generation, including cloud based.
  • High level partitioning structures will usually overlay system architecture infrastructure of various evolution levels and across all layer types in unique ways for every organisation, requiring great flexibility in system management tools as used by both service providers and customers. Due to limitations described with existing modelling approaches, coverage of all these factors is challenging to address using contemporary OSS products, even for those products attempting to provide inherent support for multiple technology types or when attempts are made to integrate across multiple OSS environments using standardised OSS interfaces.
  • resource objects managed according to embodiments of the present invention share a common underlying information model
  • assignment of resource objects of any type into logical partition groups is made very simple, particularly given that processing operations required at the abstract information model level are identical regardless of the domain model or technology type(s) for all containment or connectivity type relationships across all relevant technology domain types.
  • other names may be used for class types designed to group resource inventory objects together, such as the
  • ManagementDomain in the SID model The name 'LogicalPartition' has been chosen within this design deliberately to avoid confusion with such existing type names, due to their inability to group all resource objects, including containment & connectivity associations across and between all layer types, at a single abstract level of reference. Logical Partitions will not be recognised in downstream Element or Network Monitoring (EMS/ NMS) Systems. ManagementDomains or their equivalents may however be created and provided across interfaces to these systems, on a derived or projected basis from Logical Partition structures.
  • EMS/ NMS Network Monitoring
  • Figure 33 shows a view of class types from the common model element embodiment relevant to logical partitioning. These are the same common model element classes, but seen from another modelling perspective. An additional
  • LogicalPartition class type is shown. Also shown is the RootEntity class type, which is relevant generally beyond logical partitioning but needed in this particular modelling view. Given that class types ContainConnectlnteraction 3310, Resource 3320 and ResourceLocalLocation 3330 are the objects used to define individual resource inventory item instances and their specific containment & connectivity relationship assignments, these are the primary objects that logical partition structures must support grouping of. Each of these types is specialised from the RootEntity super class 3340, which has an association 3350 defined with the LogicalPartition class 3360. Any relevant instances of resource inventory types 3310, 3320 & 3330 may therefore be associated with one or more LogicalPartition objects as desired to describe partitioning requirements.
  • Inventory objects of type 3310, 3320 & 3330 do not need to be associated to each other in order to be associated to the same Logical Partition.
  • a LogicalPartitionSpec class could likewise be defined in the Resource Specification model, to support pre-defined Logical Partition specifications supporting a set of resource specifications as part of a 'pre-built kit' type component product item specification structure.
  • 'RootEntity' is provided here as an example of a high level superclass encompassing many sub class types. Real implementations would more likely use a more focussed super class defined somewhere in the Resource domain.
  • Figure 34 depicts a view of the same resource inventory objects as seen originally in Figure 10. Some of these objects have been assianed into a Loaical Partition 3450. This Logical Partition is seen to include resource objects from across all the layers in this structure 3410, 3420, 3430 & 3440, including inter-layer interaction association objects. Note that the curved connection link line representations present in Figure 10 have been left out of this diagram to aid simplicity - these are assumed to still present in the model and included in the logical partition item structure. The meaningfulness of this logical partition shown in the context of this example structure is to partition all objects related to the two SQL RDBMS database environments, including within and across all supporting layers. Its use(s) may be relevant with respect to service assurance, security zoning, or any other purposes as defined by Users of the partition.
  • the 'Services' domain is subject to a large amount of discussion and variance within the industry in regards to both definition and application.
  • logical partitions may be used to group the specific resources relevant to any single service item definition. In this way, a service is implemented as a logical partition. This avoids the need for management of yet another object type dedicated to services, but which actually needs to group and define resource objects somehow.
  • logical partitions can additionally serve to provide insight as to which service contracts / how many of any given type are or would be impacted by various events or event types as they relate to any specific logical partition(s).
  • Embodiments of the present invention enable the same OSS system environment to be used securely by different parties by virtue of the models employed enabling clear definition of connectivity and containment relationships, viewpoints and logical partitions.
  • CPSS Common Platform Support System
  • a CPSS environment would enable:
  • resource and service inventory for a single customer, or multiple customers (for example in the context of a specific service provider).
  • Tenanted security schemes do not provide the granularity required to provide any relevant party with the necessary granularity of access rights across appropriate specific sub-sets of another party's resource / service inventory. It may be necessary to allow or deny access rights based on organisational structure, satisfaction of specific management policies, membership of hierarchical access control groups or roles, technology type, layer type, logical partition membership, and/or any combination of other relevant factors.
  • the information model proposed in embodiments of the present invention greatly reduces the number of object types that need to be secured by such access security management architectures.
  • the support for containment and connectivity structures within the common model element described in this design is a key factor in enabling simple assignment of access rights to resource objects within and across such access security schemes.
  • SMPM Secure Multi Party Model'
  • Figure 41 contains a depiction of resource inventory items that are owned and/or accessible by multiple parties.
  • the resource items are shown structured into Logical Partitions, in a manner that supports the Management or View type role that each party may have with respect to the resources within each Logical Partition.
  • Logical Partition 'Customer 1 Physical' 4110 contains physical server and network switching equipment resources that are Owned and
  • Logical Partition 'Service Provider A Physical' 4120 contains network switching equipment resources that are Owned and Managed by Service Provider A. Additionally, Customer 1 has View access to this Logical Partition.
  • Logical Partition 'Service Provider B Physical' 4130 contains server and network switching equipment resources that are Owned and Managed by Service Provider B. Additionally, Customer 1 has View access to this Logical Partition.
  • Logical Partition 'Service Provider C Physical' 4140 contains server and network switching equipment that is Owned and Managed by Service Provider C. Additionally, Customer 1 and Service Provider B have View access to this Logical Partition.
  • Logical Partition 'Cust 1 Storage' 4150 contains Storage Volume resources that are Owned and Managed by Customer 1. Only Customer 1 has any access to these resources.
  • Logical Partition 'Service Provider B Storage' 4160 is Owned by Customer 1 , but is Managed by Storage Provider B, who provides it as a service to Customer 1. Storage Provider B therefore has Management access to this Logical Partition, while Customer 1 has View access to the storage volume resources in this Logical Partition. Note that this is from a CPSS/OSS management perspective and not necessarily with respect to the operating access rights assigned to the actual resources themselves.
  • Service Provider B uses infrastructure resources made available in Logical Partition 4140 from Service Provider C to host one of the storage volume resources in Logical Partition 4160 in order to provide all the Storage Volume resources required by Customer 1.
  • Logical Partition 'Customer 1 Document Management' 4170 contains Document Management Node resources that are situated on storage volumes that are Owned by Customer 1. Only Customer 1 has either Management or View access to the resources contained in this Logical Partition.
  • Figure 41 illustrates a scenario that reflects how the present invention can support a single multilayered and interconnected inventory repository describing resource elements owned, managed or accessed by various party organisations in order to achieve a given high level functional purpose.
  • This type of inter-organisation view of an interconnected set of related resources may be encountered in various commercial scenarios including Service Provider Hosted Services, Infrastructure As A
  • the same type of structure may additionally include virtualised resources in place of certain or all physical resources.
  • SMPM single-tenant-tenant-tenant-tenant-tenant-tenant-tenant-tenant-tenant-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative-proliferative, 'multi-tenant' operations, where no interaction between 'tenants' is to be allowed.
  • resource elements managed using embodiments of this invention may themselves be representative of real world resource objects designed to provide resources and/or services according to a Tenanted or some other security partitioning model. This is unrelated to the use of an SMPM implementation for management of access control for such resource inventory objects.
  • Architectural structures for implementation of SMPM support are not specifically described in this document, but technical platform options may include elements such as conventional Relational Database Management, NoSQL / Object Oriented Database Management, Directory Management, and Authorisation / Authentication / Single Sign On
  • An advantage of the present invention is that the framework is applicable for definition and management of resources at all traditional networking layers and also across emerging networking, application and computing technologies.
  • the ability to define interaction relationships between system resources in terms of connectivity associations and containment relationships using a common model element has significant advantages for defining system architecture.
  • the ability to enable common definition of containment and connectivity relationships provides flexibility in a system management tool to adapt to emerging technologies and new networking, application and computing philosophies.
  • Lifecycle' is a key concern of Operational Support System management products with respect to management of the planning, implementation, operation and retirement of network, computing and application resources. Lifecycle has a special meaning in particular with respect to helping sharpen the meaning of what is regarded as a 'Structural composition' of resources. Taking the above example of an Operating System ultimately installed on an array of Solid State Storage devices, a variety of relationship cardinalities can be seen in the chain of structural composition:
  • the Operating System is installed on one Logical Volume only.
  • the Logical Volume is implemented on one RAID 0 Volume only.
  • the RAID 10 Volume is implemented on many SSDs.
  • Removing a single SSD will not cause the RAID 10 Volume to be removed from service, but removing more SSDs than striping redundancy can support across the array will result in the RAID 10 Volume being removed from service.
  • a containment relationship may be thought of as any relationship between objects where a change in lifecycle status of one of the objects can potentially impact the lifecycle status of the other(s).
  • Embodiments of the present invention enable these containment relationships to be defined and made clearly visible, regardless of technology type or layer. This can greatly simplify business process / lifecycle management logic, which would otherwise require specific codina for these various technology types and layers.
  • one-to-one, one-to-many and potentially many-to-many containment structures are graph structures, no different to those seen in the networking domain.
  • a series of containment relationships may extend through numerous objects not just vertically but also horizontally, and potentially therefore be confused as though they are connectivity structures.
  • Containment relationships exhibit numerous properties similar to network structures. They may be any one or more of: Graph structured; Layered and
  • any associated business logic must still be aware of the domain specific context of each resource, and use this knowledge during assignment or traversal of structural relationships.
  • This is quite unlike the common model proposed in this invention, in which a single abstract model structure provides a common viewpoint across all containment relationships and connectivity associations for all such logical resource classes, within and across all architecture layers.
  • This failing of existing models makes it impossible for any associated business logic elements to generically traverse all containment and connectivity relationships using a single abstract model based approach. This causes a number of key problems:
  • Figure 34A illustrates a potential view that could be generated with reference to a resource inventory structure conforming to the common model element described in either the first or second embodiments of the present invention.
  • Resource objects are shown in multiple layers - 3410 contains Database Layer resources, 3420 contains Network layer resources, 3430 contains Storage layer resources and 3440 contains
  • Alarm events has occurred within a specific time period.
  • This type of analysis and visualisation makes recognition of the location of the root cause of the fault very obvious.
  • This style of processing, analysis and presentation may equally be applied to processing for other areas of management concern, such as capacity planning, disaster/business impact analysis, etc.
  • OSS Operational Support systems
  • EMS envelope element management systems
  • NMS network management systems
  • service management systems can have visibility therefore of the numerous resource technology and service item types managed within each of these various systems.
  • Embodiments of the present invention employ a graphically presentable framework capable of presenting and manipulating physical and logical inventory resource objects described within the framework of resource and interaction relationships between system resources in terms of connectivity associations and containment relationships.
  • the ability to generically traverse complex network, computing and application related containment and connectivity relationships using high level, abstract relationships between all object types can allow implementation of common aspects in associated software system architectures including: User Interface elements, Generalised processing elements, Message passing elements, Expert System elements, and Data import/export elements.
  • Embodiments of the present invention provide models that support 'convergence' in the real sense between each of the physical, networking, compute and application domains, whether virtualised or not, and a user interface approach for use in conjunction with the model.
  • Advantages with respect to embodiments of the present invention can include: 1. Supporting multiple Physical Resource item types
  • VLAN virtual local area network
  • VPN virtual private network
  • IP internet protocol
  • MPLS Multiprotocol Label Switching
  • MPLS Metro Ethernet & Fibre Optic transports
  • Embodiments of the configuration module and graphical user interface of the system management tool of the invention may be implemented according to a number of system architecture scenarios, including but not limited to:
  • Web Application Server a centralised data server stores data potentially belonging to multiple users ensuring security partitioning is enforced between all Users in compliance with defined access control rules.
  • User interface functionality is implemented as functional web pages, published by one or more centralised web servers operating in conjunction with application layer logic implemented on one or more application servers accessing and manipulating data located on a data management system.
  • Client Server a centralised data server stores data potentially belonging to multiple users and ensures security partitioning is enforced between all Users in compliance with defined access control rules.
  • User interface functionality is
  • client application module implemented as a client application module, or set of modules, that is installed and run locally on the User's computer or computing device. Delivery of client application modules may occur statically (such as via a manual installation process), on an assisted basis (such as via an online application store/shop, or software update process), or on a fully automated basis, such as via transparent delivery via web pages or some other localised application runtime host environment or application.
  • Offline/Disconnected the application and data associated with any particular User are both located on a local computing device in the possession of that specific User.
  • the User may periodically connect the device to a centralised server via a network connection and perform a bi-directional synchronisation of both changes made locally by the User, and changes made by other Users and stored centrally.
  • Each architectural scenario may be implemented using one or more specific technology implementations.
  • RDBMS Proprietary Relational Database Management System
  • Java Web Application Server Tomcat (application logic developed in Java)
  • Microsoft IIS application logic developed in .Net compatible languages - there are numerous, including C# and VB.NET).
  • example CPU architectures/manufacturers include Intel, AMD, Alpha, Power, ARM etc.
  • Example Operating Systems include Windows family, Apple OS/X family, Unix implementations, Linux implementations,
  • CPU architectures/manufacturers include ARM, Tl
  • '(n) layers' which describes the number of architectural element types supporting application functions on an end to end basis from the user-interface through any front end, back end, middleware and data management layers etc. This may potentially be thought of in a vertical 'stack' based sense, as for network layering. For example a Logical Volume may exist within a Virtual Disk, in turn stored on another Logical
  • 'application network' a set of application objects interconnected by one or more communication links and/or application interfaces supporting transfer of data of a specific type between those objects.
  • the objects concerned may be: components that are only relevant within the context of the relevant application framework to which they commonly belong; components of another application architecture; or components of products implementing standards based interface methods.
  • An application network will usually have a 'horizontal' connotation, as for a communications network (even though all object associations may be across Application Programming Interfaces (APIs).
  • APIs Application Programming Interfaces
  • APIs Application Programming Interfaces
  • Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. (National Institute of Standards and Technology, U.S. Department of Commerce).
  • 'Compute and Application layer resource' in this design describes any form of logical resource that is not specifically networking related. This may include Operating
  • 'Connectivity' describes the modelling of connections between object types across a graph structured network model. Existing models and architectures are mostly oriented towards supporting objects and functions that perform a network or application Role of some sort.
  • items related in a connectivity structure are defined as those that do not have a lifecycle dependency on each other - they can be disconnected and continue separately in their own lifecvcles.
  • 'Containment' normally describes an ownership association between objects.
  • NOTE: In this design containment describes the modelling of associations between related objects that are created, modified or removed in conjunction (in some way) with each other - i.e. a lifecycle based relationship.
  • Containment may be simple, whereby an object is fully contained by a single parent, or complex, where an object may continue to 'remain in existence' with the support of one or more other objects.
  • the association structures are analogous to Connectivity structures in that they can be represented by a graph based network structure. The key difference is that addition or removal of a containment association between objects can or will (depending on business rules) have a lifecycle impact on one or both of the objects concerned.
  • 'communications network' a set of computing devices interconnected by one or more communication links supporting transfer of data between those devices.
  • physical networks usually span geographical territory to some extent, they usually have a 'horizontal' connotation.
  • Logical network elements located within the same network layer are usually regarded as having a 'horizontal' connotation also.
  • 'element management system' refers to a computer system used to manage one or more of a specific type of telecommunications network elements (NE).
  • EMS systems manage functions and capabilities within each NE but do not manage the traffic between different NEs in the network.
  • 'graph' a graph is a mathematical structure of nodes and interconnecting links. In the context of this document, 'graphs' are relevant due to the graph structures present in typical network and resource structure designs.
  • 'network layer' describes the hierarchy of transport and processing functions required to move data across a communications link. This is supported historically by the 7 layer ISO model, which defines a standard prescribed strata of network layers, often referred to as a 'Protocol Stack'.
  • the OSI view is commonly regarded now as being outdated in the reach of its descriptiveness.
  • 'network layering' This is a term used more recently, supported by more modern standards such as the ITU G.800 network model which allows flexibility in assignment of layer functions and detailed description of connectivity structures etc. Given that communications links are implemented in the context of graph based structures, modelling of networks becomes a multi-dimensional activity with regard to links and layers. Objects in adjacent layers do not necessarily correspond on a one-to- one basis. Under the ITU model it is possible to describe very complex networks, including network transport layers that are used to carry other complete network protocol stacks, giving rise to the term 'layering'. For example Ethernet layered over MPLS layered over SDH. Rules may change over time regarding layer stacking order, for example MPLS started as a traffic prioritisation architecture that sat 'above' transport protocols. Transport MPLS exists now as a lower layer transport/switching protocol layered underneath even SDH. Network layering has a 'vertical' connotation.
  • 'network management system' refers to a combination of hardware and software used to monitor and administer a computer network.
  • 'network mode' refers to the class of network protocol implementation. These include: Circuit Switched (CS) and Packet Switched (PSN).
  • CS Circuit Switched
  • PSN Packet Switched
  • the Packet Switched category includes two sub-modes: Connection Oriented (CO); and Connectionless (CL).
  • CO Connection Oriented
  • CL Connectionless
  • 'network type' refers to the specific network protocol implementation, and is usually relevant to a particular network mode.
  • Example network types include:
  • ⁇ PSN - CO: ATM, FR, MPLS, TCP/IP, SCTP/IP
  • BSS Business Support System
  • 'party' an organisational or individual system related participant. These may be of various types including users, business units, customers, manufacturers, distributors, system integrators, service providers, consultants, regulators.
  • virtualisation describes firstly the creation and utilisation of emulated copies of resources or services, as though they are the original resource or service object items themselves. Additionally, virtualisation provides benefits and has detractions that are not inherent in the original resource types. The meaningfulness and implementation of virtualisation has differences with respect to the following primary categories of virtualisation: Hardware Virtualisation; Network Virtualisation and Storage Virtualisation. Some vendors also make use of the terms Application

Abstract

A system management tool comprising a configuration module adapted to enable definition of a system architecture having one or more physical and logical resources, the configuration module employing a framework to define system components and interaction relationships between system components in terms of a graph based structure, wherein interaction relationships define connectivity associations and containment relationships between system components; and a graphical user interface (GUI) adapted to enable a user to select a functional perspective from which to view a defined system architecture, and render for display a graphical representation of one or more defined system components and interaction relationships therebetween that are selected for display by the GUI based on the graph based structure of the defined system architecture and the functional perspective selected by the user.

Description

SYSTEM MANAGEMENT TOOL
DESCRIPTION
Technical Field
The present invention relates to tools for management of computer equipment, applications and networks or other complex equipment systems configured from a plurality of components where complex physical and logical relationships can exist.
Background
In the fields of network management, information technology management, medical system management or any other industry category in which complex configured pieces of equipment must be managed and maintained, management tools are required that support high-fidelity representation of containment relationships and connection associations that exist between these objects in terms of both the physical and multiple logical layers of networking, computing, and application elements concerned.
Without such a system, it becomes problematic to properly describe, manage and analyse inter-dependencies between all objects of relevance. The impact of this is experienced across virtually all areas of technology & service management, including but not limited to planning, design, ordering, fulfilment/implementation, testing, service assurance, supplier/partner management and billing.
It should be noted that the computing and application logical 'technology categories' or 'domains' mentioned in this document include (but are not restricted to) elements in the following domains: Networking, Operating system, Database
Management, Storage system, Virtualisation, Application, Security and Messaging.
The ability to perform unified management across all the domain classes outlined is complex due to the large differences in purpose, implementation form factor and complexity associated within each of these domains.
Various standards bodies within the electronic, network, application and service engineering communities have developed models that support comprehensive levels of detail within each of their respective disciplines. Numerous Standards Development Organisations (SDOs) relevant to technology management exist which publish standards relevant to their area of concern. Some of these are purely focussed on management technologies while some are focussed on the underlying engineering standards, but also play a role with respect to development of management standards. Some of the relevant SDO organisations include: International Telecommunication Union (ITU); Tele Management Forum (TMForum, or TMF); Distributed Management Task Force (DMTF); Internet Engineering Task Force (IETF); Metro Ethernet Forum (MEF); and 3rd Generation Partnership Project (3GPP).
In some cases the standards published by these organisations allow for management of inter-relationships between objects situated in different sub-domains. However, the models of existing standards are oriented towards application in specific architecture layers and only support currently understood architectural concepts in terms of containment, connectivity, layering, partitioning and recursion. This limits the ability for known models to support emerging technology domains such as
virtualisation and cloud computing, or to support as yet unknown technology domains of the future. Where emerging structural concepts involving integration between existing and new standards are attempted to be supported using existing and/or new models, overall modelling requirements and hence the system definition becomes increasingly complex and awkward to manage.
There is a need for a model and associated management tool that
accommodates existing standards and enables emerging or future architectural concepts and technologies to be supported.
Brief description of the drawings
Figure 1 is a block diagram of an embodiment of the present invention.
Figure 2 is an example of the graph structure used in embodiment of the present invention.
Figure 3A is an example of a simple system and Figures 3B and 3C are examples of how the example of Figure 3A can be described using the graph structure of embodiments of the present invention.
Figure 4A shows a simplified example of model objects according to a first
embodiment of the present invention.
Figure 4B shows a simplified example of model objects according to a second embodiment of the present invention.
Figure 5 shows a specification class model according to the first embodiment.
Figure 6 shows a complementary inventory class model to the class model of Figure 5.
Figure 7 illustrates a unified catalog environment.
Figure 7 A shows an example of a resource specification structure and corresponding inventory objects.
Figure 8 shows a simple example of a layered resource inventory structure.
Figure 9 shows the example of figure 8 represented using SID class model items.
Figure 10 shows the example of figure 8 represented using the class model of the first embodiment of the present invention. Figure 1 1 shows an example product specification structure for the first embodiment of the invention.
Figure 12 shows an example product specification structure for a Windows Standard installation package in accordance with the first embodiment of the invention.
Figure 12A shows an example product specification structure for a Windows 2008 Group in accordance with the first embodiment of the invention.
Figure 12B shows an example resource inventory structure for a Windows 2008 Group in accordance with the first embodiment of the invention.
Figure 12C shows an example product specification structure for a 'BroadCom
Ethernet NIC NetXtreme Device Driver' in accordance with the first embodiment of the invention.
Figure 12D shows an example product specification structure for a link connectivity item in accordance with the first embodiment of the invention.
Figure 13 shows an example product specification structure for an SQL Server 2008 Net Connection Point in accordance with the first embodiment of the invention.
Figure 13A shows an example product specification structure for an SQL Server 2008
Database in accordance with the first embodiment of the invention.
Figure 14 shows an example product specification structure defining an access point relationship in accordance with the first embodiment of the invention.
Figure 15 shows another example product specification structure defining an access point relationship in accordance with the first embodiment of the invention.
Figure 16 shows an example of a management display region of an embodiment of a user interface.
Figure 17 shows an object model of a physical drive enclosure in accordance with the first embodiment of the present invention and an example of a corresponding Ul representation from a physical front elevation viewpoint.
Figure 18 is an example of a representation of the object model of Figure 17 from a storage group viewpoint.
Figure 19 is an example of a Ul representation from a logical volume manager viewpoint.
Figure 20 is an example of a Ul representation from an Operating System to Volume viewpoint for a specific host system.
Figure 21 is an example of a Ul representation of a Connection point viewpoint corresponding to Figure 20 for a specific host system.
Figure 22 is an example of a Ul representation of a connection point viewpoint in the network layer with some elements in an unfolded state.
Figure 23 shows the example of Figure 22 with some elements folded and another element unfolded.
Figure 24 shows a simple example of model elements beside a representation of these elements as represented by a user interface.
Figure 25 shows another simple example of model elements beside a representation of these elements as represented by a user interface.
Figure 26 is an example of a pre-state Ul representation and corresponding object model prior to creation of new physical link.
Figure 27 is an example of a post-state Ul representation and corresponding object model to Figure 26.
Figure 28 shows an example of a pre-state Ul representation.
Figure 29 is an alternative representation of Figure 28 showing corresponding model objects relevant to a Logical Volume Manager viewpoint.
Figure 30 shows an alternative representation of Figure 29 from a Security Zone Manager viewpoint.
Figure 31 is a post state example of Figure 29 showing a Logical Volume Manager viewpoint.
Figure 32 is an alternative representation of Figure 31 from a Security Zone Manager viewpoint.
Figure 33 is an example of class types relevant to logical partitioning in accordance with the first embodiment of the invention.
Figure 34 shows the example of Figure 10 with some objects assigned to a local partition.
Figure 34A shows an example of an alternative view of the architecture of Figure 34, displaying a structural path traced through related fault/alarm indications as part of a root cause analysis exercise.
Figure 35 shows an example of a Plan elevation.
Figure 36 shows an example of a Ul representation of the externally visible areas of a server chassis and corresponding resource inventory hierarchy.
Figure 37 shows an example of a Ul representation of specifying an external geometry reference point and corresponding resource model.
Figure 38 shows an example of product component item definition for a Riser Card. Figure 39 shows a specification class model according to the second embodiment. Figure 40 shows a complementary inventory class model to the model of Figure 39. Figure 41 shows an example of resource inventory items allocated to logical partitions.
Detailed description
There is provided a system management tool 100 which comprises a configuration module 110 and a graphical user interface 120. The configuration module employs a framework 130 to define system components and interaction relationships between system components in terms of a graph based structure. Interaction relationships define connectivity associations and containment relationships between system components. The graphical user interface is adapted to enable a user to select a functional perspective from which to manage or view a defined system architecture, and render for display a graphical representation of one or more defined system components and interaction relationships therebetween, selected for display by the GUI based on the graph based structure and the functional perspective selected by the user.
The configuration module 110 is used to define system architecture. The configuration module can be implemented as a software module executable on a processor using any suitable software platform or architecture.
The graphical user interface 120 can also be implemented as a software module and can be implemented using the same or a different software language than the configuration module. Although in many embodiments a common software platform will be used to implement both the configuration module and graphical user interface, different languages may be used for different modules, provided the resulting compiled modules execute compatibly. A number of examples of tool implementations are outlined later in this document.
Embodiments of the tool can also include business logic modules for implementing business logic for system management functions. Alternatively the tool may be used simply for defining system architecture which is accessed for system management by a different system management system. It should be appreciated that system architecture defined using embodiments of the present invention can be compatible with business logic of existing system management systems.
The configuration module 1 10 employs a framework to define system architecture in terms of graph based structures. The framework is based on the concept that resource interactions can be defined in a common manner based on a simple graph structure using nodes, vertexes and edges as shown in Figure 2. Nodes
200 may have one or more Vertexes 210 associated with them. Edges 220 may connect two Vertexes together (thereby linking two Nodes together). Nodes 200 may be connected to multiple other Nodes, or the same Node more than once, by the configuration of associated Vertexes 210 and Edges 220.
Embodiments of the framework described herein enable abstraction of system component representations based on the graph structure which can be utilised by business logic for specification network management functions. The framework can be used for defining system architecture to be managed using embodiments of the tool. The framework can also be used for abstract representation of system architecture defined using known information models with, some transformation, in a manner that enables the original system architecture information model definition to be retained.
Each system component in a system architecture can be assigned as a node vertex or edge based on the generalised functional role of the system component. Node is used for a physical or logical resource. Vertex is used for a termination for a connection to a physical or logical resource. Edge is used for a connection between two vertices. Each node component can be associated with one or more vertex components, each vertex component being associated with a single node component. Each edge component can be associated with two or more vertex components to thereby define links between terminations for connection of physical or logical resources. A node component can be associated with another node component thereby defining a containment relationship between the associated node components. In this framework the associations between node components, vertex components and edge components represent interaction relationships and each association is defined as a connectivity association or a containment relationship. Typically connectivity associations and containment relationships will be defined separately but combined definition of connectivity and containment relationships or relationship structures can also be supported.
In an embodiment an edge component can be limited to being associated with only two vertex components, to thereby define a link between two terminals for connection of physical or logical resources. In an alternative embodiment an edge component can be associated with two or more vertex components. Each vertex component associated with a single edge component can be designated a specific role defining the purpose of the vertex component in context of the association with the edge component.
This framework enabling definition of system components in terms of a graph based structure can be implemented using object oriented models.
In an embodiment the framework uses a single abstract information model structure across all containment relationships and connectivity associations across all resource classes. Thus supporting both connectivity and containment relationships using the same information model, this framework can also be referred to as a common model element. This information model can be an object oriented model which includes in classes for defining resources an abstraction type attribute whereby a resource is defined as a node, vertex or edge. Resource class specifications have abstraction types node, vertex or edge. This abstraction tvoe attribute is added into the resource class specifications based on generalised functional role so by virtue of inheritance each instance will carry the appropriate node, vertex or edge attribute. An interaction specification class is introduced to define containment and connectivity relationships between associated resource objects. This information model structure enables business logic to traverse resource objects based on the three abstraction types (node, vertex and edge) rather than resource object type. Containment and connectivity relationships can also be clearly defined.
An example is shown in Figure 3A where two personal computers 301 , 302 each having a network card 310, 320 are connected together using a physical cable 350. Each network card 310, 320 has a physical port 330, 340 for connection of the physical cable 350. Figure 3B is a simple example of how the framework of the present invention can be used to define the physical architecture of the connection between the two network cards 310, 320. The two network cards 310, 320 are defined as physical resources using resource objects 310', 320' having the abstraction attribute type NODE 315, 325. The physical ports 330, 340 are defined as physical resources using resource objects 330', 340' having the abstraction attribute type VERTEX 335, 345, as the physical ports provide the connection for the physical cable 350. The physical cable 350 is defined as a physical resource using a resource object 350' having abstraction attribute type EDGE 355, as the physical cable 350 is what provides the connection between the two network cards 310, 320.
It should be appreciated that within this simple architecture of Figure 3A looked at for the above worked example as well as the obvious connectivity relationship between the physical resources, containment relationships also exist. In particular, the physical ports 330, 340 are functionality provided on the respective network cards 310, 320 and removal of a network card 310 would also result in removal of its physical port 330.
Some embodiments of the framework of the present invention facilitate clear definition of connectivity and containment relationships using Contain Connect Interaction Specifications. Such Interaction specifications can be used to define connectivity and containment relationships between associated objects of NODE,
VERTEX and EDGE abstraction types. Interaction associations between objects can be defined in terms of any one of:
containment type relationship between objects within the same layer of architecture hierarchy;
containment type relationships between objects in different layers of architecture hierarchy using a SUPPT attribute type;
connectivity type relationships between obiects within a same laver of architecture hierarchy; and
connectivity type relationships between objects within different layers of architecture hierarchy. Containment relationships can also be defined in terms of containment importance and multiplicity.
For example, containment can be defined using a component (COMPNT) attribute type for a relationship between objects in the same layer and using a support (SUPPT) attribute type for a relationship between objects in different layers. For example, a component type relationship exists between an operating system and its logical volumes and software packages executing in the operating system
environment, if these are considered to exist with the same logical layer. An example of a support (SUPPT) type relationship is between the physical processor resources in the physical layer and the operating system in a logical layer. Another example is relationships between logical volumes and databases residing in different logical layers.
Connectivity relationships can be defined using a connection (CONNECT) attribute type for connectivity relationships within the same layer, where a single endpoint object is situated at each end of the connection, for example, with respect to relationships between physical links and physical ports. Where a connectivity relationship exists between objects within the same layer and where the connectivity relationship passes at each end through an access point to an internal object which is the actual end point of the connection, a specific access point connectivity attribute type (ACCESSPT) can be used. For example, network connection points for data base instances or applications.
At the time of writing this document connectivity relationships between resources in different layers is not used in common information technology or networking architectures. However, it is envisaged that embodiments of this invention can be used for defining such architectures. For example, connectivity relationships between resource objects in different layers can be defined using one or more interlayer connectivity attribute types. It should be appreciated that the framework of the present invention can accommodate such new architectures simply by adding appropriate connectivity attribute types to the interaction specification. The framework of the present invention can be used for defining complex system architectures other than IT and networking architectures, for example engineering or medical system architectures where interlayer connectivity may be used. A special case does exist and is described whereby objects existing at different lifecycle states need to support what may be regarded as being interlayer connectivity associations. This is described in the section titled 'Mockup Item Definition and Operation'. In embodiments of the present invention layers of the architecture can be flexibly defined in any manner suitable for the architecture. Layer definitions are not restricted to known layer structures, such as within the OSI model. A layer can be defined for any group of resources that have a horizontal management relationship, and can be referred to as a management plane. For example, application, transport, compute and physical layers can be defined as well as layers such as storage, memory, database etc. Layers can be defined for management planes in any manner that makes sense to those building and managing the system architecture. This enables any type of system to be defined using a layer structure. Interaction specifications are used to define containment and connectivity relationships within the layer structure.
It is important to distinguish between utilisation of the term 'management plane' in the context of the present invention, and the conventional utilisation of this term in the field of network engineering. A Management Plane in the field of network engineering normally exists within the networking layer, and usually represents a path through a networking topology that only privileged users have access to for the purpose of managing the relevant network devices themselves. In the context of the present invention a Management Plane can be used to create the distinction of a horizontal layer that represents any technology type, not just the commonly understood technology/layer type combinations as is described in various industry standards, such as the OSI, G.800 series standards, etc. Management Planes can be stacked, similar to layers in layered network models.
Referring back to the simple example of Figure 3A, each physical port 330, 340 is provided on a network card 310, 320, therefore a component containment relationship exists. Figure 3C shows an extension of the object oriented architecture definition of Figure 3B to include interaction objects to clearly define the containment relationships between the physical ports 330, 340 and network cards 310, 320. An interaction object 360 of attribute type COMPNT 365 defines the component containment relationship between the NODE attribute object 310' defining the network card 310 and the VERTEX attribute object 330' defining the physical port 330.
Similarly, and interaction object 370 of attribute type COMPNT 375 defines the component containment relationship between the NODE attribute object 320' defining the network card 320 and the VERTEX attribute object 340' defining the physical port 340. Interaction objects 380, 390 having attributes CONNECT 385, 395 are used to define the connection relationship between the physical cable EDGE type object 350'and the physical port VERTEX type objects 330', 340' respectively.
The abstraction types NODE, VERTEX and EDGE can be used can be used for abstraction of all system architecture elements. Figure 4A shows a simplified example of model objects that might be present in the case of an implementation of SID
Physical Resource objects under the basic information model supporting graph structures of the present invention. Each object instance has been shown decomposed to two aspects. The respective abstract super class aspect of each object is shown in block form having a black background. The SID Physical Resource aspect of each object is shown in block form having a black border and white background. A single object is represented as a pair of aspects. Each concrete aspect has the same numbered reference as the relevant abstract aspect, but with the suffix 'a' present also. In this example: Chassis objects 410a and 420a are represented abstracted as
Resource objects 410 and 420, of type Node; Physical Port objects 450a to 453a are seen in their abstract representation as Resource objects 450 to 453, of type Vertex; and Cable object 460a is represented abstracted as Resource object 460, of type Edge. For each object association formed at the SID Physical Resource class definition layer, another matching association is formed at the abstracted layer. These are not aspects of the same element, they are two distinct associations used to model the same real world item. The Resource Node, Resource Vertex and Resource Edge abstract super class model structure provides a common way of utilising object instances of any sub-class type (such as 'Chassis', Operating System' or 'Logical Volume', etc). This approach can be extended to include combined use of very different model domains, such as for complex networking or application engineering, in conjunction with the Physical Resource model domain, using the common abstract model domain as a unifying element. Business logic written to analyse the graph structure at the abstracted level can perform inspection of the relevant attribute(s) to determine whether any specific Resource object being examined or traversed is a
Node, Vertex or Edge, rather than needing to first interpret the model domain, then object type and finally mode of handling for each object concerned.
Embodiments of the present invention add an interaction specification class (not shown in Figure 4A) to enable precise definition of containment and connectivity relationships between logical and physical resource objects. The interaction specification class is a concrete class and instances of this specific class type need to be created directly. Interaction specification objects enable any business logic traversing the graph structure at an abstract level to understand whether Node or Vertex type resource objects are network, storage, database, compute related objects, and of what sub-category etc. An advantage of this model design is that it avoids 'pollution' of generalised code operating at the abstracted level with sub-domain specific class, attribute or association references - for example to avoid the need for class type checks through all logic to see whether a specific Resource object of type Node was a 'Chassis', 'OperatingSystem' or 'VirtualMachine'.
In an alternative embodiment the framework is implemented as an information model which is object oriented model having node, vertex and edge resource classes and association classes wherein each resource class inherits a class type from one of node vertex and edge classes. In this embodiment association classes are added for defining associations between resource objects. Containment and connectivity relationships are defined in attributes of the association classes.
In this embodiment a resource superclass is included and ResourceNode, ResourceVertex and ResourceEdge definitions are abstract classes used to enable concrete sub-classes to inherit their base class structure from the abstract classes to provide a common way of looking at instances of respective concrete sub-classes (for example "Chassis", Operating System", "Logical Volume" etc) for defining system components. Each concrete subclass can be associated with one of the
ResourceNode, ResourceVertex, and ResourceEdge abstraction classes so that, by virtue of inheritance, each resource object can be traversed by business logic operating at the abstract level simply as a node, vertex or edge rather than as the actual concrete class types, thus enabling simplification of business logic.
The association classes, added to enable definition of containment and connectivity relationships and complete the graph based structure abstraction, are concrete classes and instances of these specific class types are created directly.
Inclusion of association classes enables identification and management at an abstract level of containment and connectivity roles played by associated ResourceNode, ResourceVertex and ResourceEdge objects.
A relationship between node type objects is defined using a node association object, for example ResNodeAssoc class. Associations between ResourceNode objects will always define containment relationships and can include relationships between ResourceNode objects located within the same network or architectural layer, between ResourceNode objects located in adjacent network or architectural layers, and between objects having the same or different technology types.
A relationship between a node type object and a vertex type object is defined using a nodevertex association object, for example ResNodeVertexAssoc.
ResourceNode objects and ResourceVertex objects can be associated with a single ResNodeVertexAssoc object specifying one or more containment and connectivity roles or multiple ResNodeVertexAssoc objects each specifying one or more
containment and connectivity roles.
A relationship between a vertex type object and an edae tvoe obiect is defined using a vertexedge association object, for example ResVertexEdgeAssoc.
ResourceEdge objects and ResourceVertex objects can be associated with a single ResVertexEdgeAssoc object specifying one or more containment and connectivity roles or multiple ResVertexEdgeAssoc objects each specifying one or more
containment and connectivity roles.
Note the ResNodeAssoc, ResNodeVertexAssoc and ResVertexEdgeAssoc association classes are referred to collectively in some places in this document as xxxAssoc association classes. Roles & Sub roles on the xxxAssoc objects enable any business logic traversing the graph structure at an abstract level to understand whether ResourceNode or ResourceVertex objects are network, storage, database, compute related objects, and of what sub-category etc. Each xxxAssoc object can describe the ResourceRole (either PhysicalResourceRole or LogicalResourceRole) of each of the objects it relates.
Figure 4B illustrates a simple example of the model objects that may be present in the case of an implementation of SID physical resource objects. Each object is shown in the context of the relevant parent class type hierarchy for that object instance. Note the SID physical resource objects are the same as the example in Figure 4A so the same reference numerals have been used. In this example the resource superclass 465 sits above the abstract classes 470, 480, 490 and each of the SID physical resource objects has an inheritance association via one of the abstract classes 470,480,490 to the resource superclass 465. For example the Chassis objects 410a, 420a inherit from the ResourceNode abstraction class 490 to become Node type objects, the physical port objects 450a-453a inherit from the ResourceVertex abstraction class 480 to become Vertex type objects, and the cable object 460a inherits from the ResourceEdge abstraction class 470 to become an Edge type object.
Association class definitions ResNodeAssoc 495, ResNodeVertexAssoc 485, and ResVertexEdgeAssoc 475 are shown. Instances of these association class types are created to define associations between Node, Vertex and Edge objects. Note that associations between xxxAssoc type instances and instances of types ResourceNode, ResourceVertex and ResourceEdge are termed 'abstract' associations, in keeping with general object oriented terminology describing circumstances where the definition of an association is made between one or more abstract class types. It is for this reason that associations in the figure are not drawn directly between the respective object instances, but rather between the objects and the parent class type representations, where the definitions of the relevant associations are actually established. The purpose of the dashed lines in the figure is to convey more obviously which concrete object instances any particular association is linking. For example, an association obiect of ChassisPortAssoc type 481 is created to define the association between Chassis Node object 420a and Physical Port Vertex object 453a, similarly ChassisPortAssoc type objects 482, 483 and 484 are created to define associations between Node type Chassis objects 420a and 410a and Physical Port Vertex type objects 451a, 452a, and 450a respectively. Two association objects of PortLinkAssoc type 471 , 472 are created to define the associations between Cable Edge type object 460a and Physical Port Vertex type objects 453a and 452a respectively. Resource node association class 495 is shown on Figure 4B but the architecture shown includes no associations between Node objects so no ResNodeAssoc objects are required in this example.
From the simple example of Figures 3A-3C and Figures 4A and 4B, it should therefore be apparent that the simple graph structure of Figure 2 can be used as a basis for a data model element structure which can be used commonly to define any system architecture. The graph structure is applicable for containment and
connectivity structures within any architectural layer and also for defining relationships across layers. As the simple graph structure is applied commonly for all architecture definition, this allows consistent handling of connectivity and containment structures within and across architectural layers of varying technology types. Embodiments of the framework enable finely grained description of supporting relationship associations between specific object types.
General Description of the SID Specification Pattern
In order to support the dynamic establishment and management of structural definitions for current & future resource technology types in the context of the capabilities of this invention, the SID 'Specification' pattern has been adopted in the embodiment described with reference to Figures 5 and 6. This style of pattern is also seen in other reference standard information model designs.
Generally, the SID model is highly structured towards supporting Catalog definitions that allow precise structural description of the items that they are intended to represent. Each catalog item can be a template system resource specification. All items managed in the inventory repository database (planned, operational or historical) are created as implementations of items selected from an appropriate Catalog. Catalog items are often complex structurally, and may even represent complex layered and graph oriented structures. Any time a new inventory instance of a catalog item is created, the specification structure of the catalog item is reproduced into inventory using 'inventory' relevant counterparts of the relevant template system resource specification objects - for example, if a catalog item includes a 'ChassisSpec' template resource specification, then a 'Chassis' item will be created in inventory. If the ChassisSpec item has children SlotSpec items, then the Chassis item will have counterpart Slot objects created and associated to it also. Each of the template specification objects concerned may also have attribute values configured on them that are used to populate the initial values of counterpart attributes on the newly created inventory objects. In terms of practical usage, the 'flow' of how objects in catalog definitions are referenced during operational delivery processes in order to create object instances within the active inventory register is seen in the diagram of Figure 7. The Catalog 710 is an over-arching term used to describe a unified catalog
environment, as would be implemented in a modern OSS environment. This is comprised of three internal catalog layers: Resource Catalog 711 , Service Catalog 713 and Product Catalog 712. The Resource Catalog 71 1 layer holds definitions of resource structures and attributes at a resource engineering level, and provides ongoing reference for non-variant attributes common to all derived inventory instances. These may be referenced or grouped and re-presented within catalogs defined in the Service Catalog 713 layer, which typically have service contracts associated with them. Elements from either the Resource Catalog 711 and/or the Service Catalog 713 layer may be referenced or grouped and re-presented within the Product Catalog 712 layer, which describes product elements as are made available to customers in a
marketplace, for a price. The Fulfilment Processes 720 use a unified eTOM process model and drive creation/change of operational inventory from template definitions stored in the Catalog 710 environment. Fulfilment business process definitions are usually implemented into modern OSS product environments as a core supported process domain. The Operational Inventory 730 is an over-arching term used to describe a unified inventory environment, managed by unified eTOM processes implemented into a modern OSS environment. This is comprised of three internal inventory layers: Resource Inventory 731 , Service Inventory 733 and Product Inventory 732. Structural referencing, grouping and re-presentment is similar in the Inventory domain as for the Catalog domain. Any Product, Service or Resource inventory item must be associated with a defining catalog definition element. Any business rules that dictate allowable structural combination of various inventory item types (during manipulation by Fulfilment processes) are located on or in association with the relevant catalog element specification definitions for the items concerned, including template specifications of resource structures and attributes. The use of a structured Catalog & Specification based architecture is treated as a desirable pattern that should be followed, particularly given that the model design of embodiments of the present invention can support management of complex potential combinations of product items across technology category type, implementation mode and multilavered / araoh structured network topologies.
This pattern is further illustrated in Figure 7A, depicting a pre-existing resource specification structure 7A10 containing definitions of a ChassisSpec and its related SlotSpec definitions 7A14. To the right of the vertical dashed line are shown a single Chassis 7A22 resource inventory object and its related Slot 7A24 objects, created subsequently to the specification structure displayed on the left of the vertical dashed line. Each resource object on the right hand side references a single specification object on the left hand side as representing the template specification for that resource object. Note that there may be many Chassis/Slot object sets that all reference the same ChassisSpec/SlotSpec set as being the relevant root defining template specification structure.
Resource Inventory and Specification items managed using the invention may be accessed and managed via external interfaces presented for this purpose. Interface types may be file, process or protocol oriented (or any another interface technology / architecture type). Examples include Simple Object Access Protocol (SOAP), Java Messaging Service (JMS), XML file exchange, CSV file exchange, Common Object Request Broker Architecture (CORBA) etc.
Overview of the object oriented framework of a first embodiment of the invention
The framework of an embodiment of the present invention will be looked at in more detail with reference to Figures 5 and 6 which represent two complimentary information models, described at the abstract super class level, supporting graph structures for use in a resource oriented model. This information model can be used commonly to define any system component. In this example Figure 5 shows a template class model structure also referred to as a specification model used in the
Catalog 710 and Figure 6 shows a class model structure used for counterpart instances defined in the operational inventory 730, referred to as an inventory model. The specification model depicted in Figure 5, the inventory model depicted in Figure 6 and the logical partition model depicted in Figure 33 are sub-components of what is referred to within this invention as the 'common model element'.
The diagrams of Figures 5 and 6 are to be interpreted as UML class diagrams: Abstract super classes are shown with title and attribute wording in an italicised font style. Each abstract super class may have multiple sub class implementations embodying essentially the same meaning. Indicative multiplicity values are shown, these may be implemented differently whilst maintaining the same general relevance of the class types concerned.
In order to make individual resource product component item tvoes available ultimately to end users, a standardised approach has been taken towards how these are structured internally and ultimately grouped into Catalogs for access and utilisation by end users. The definition of any individual resource or resource product subcomponent item, such as a Database Instance, Database, Database Table, Disk Drive, Application etc is comprised of a set of sub-object item instances from the information model. Taken together, these objects describe the various required aspects of that component. In order to describe even a simple USB Key, a minimum set of objects is required, including: ResourceSpecification, ResourceRole, CapacitySpec,
ResourceLocalLocationSpec, DisplayStyleSpec, LayerSpec and ViewPointSpec. More complex resource components may be composed of multiple ResourceSpecification objects, and a proportionally higher number of objects of the other various types in the information model. In every case, one single ResourceSpecification object will represent the 'root' resource item / component being defined.
In order to group all the information model objects that comprise any given resource component type together, such that they may be added to a user accessible catalog, multiple modelling techniques are possible. The option described in this embodiment is based around the use of ProductSpecification objects. For every resource component being defined, a single ProductSpecification object associates to and groups all the relevant ResourceSpecification, ContainConnectlnteractionSpec, ResourceRole, CapacitySpec, ResourceLocalLocationSpec, DisplayStyleSpec, LayerSpec and ViewPointSpec objects together into a single identifiable unit. The ProductSpecification has a special association to the 'root' ResourceSpecification object, which will usually have the same name as the ProductSpecification object.
Other grouping techniques are possible, such as using the root
ResourceSpecification, or using a CompoundResourceSpecification object type. The resulting effect of these approaches is the same. It should be noted that
ProductSpecification based product component object item sets can make reference to other existing product component item object sets in order to configure the allowable association relationship rules for that component. This is necessary for most component types. Any objects referenced in this way do not become 'owned' by the referencing objects, they simply become related resource product component item objects that they are dependent on.
The examples shown in Figures 5 and 6 include elements of known information models which are extended in the framework of the present invention to enable common model elements to be used as abstract super types for class definitions and objects at all levels. Figure 5 shows a class model structure for a information model used as a template to define functionality, characteristics and relationships for resource element definitions. In this specification class model 500 the classes
ResourceSpecification 510, ResourceRole 520, ResourceLocalLocationSpec 570 and CapacitySpec 550 are provided. These classes may already exist in information models and fulfil the same functions in the current information model but can be extended for the present invention by adding attributes or be added to an existing information model in embodiments of the present invention. Class
ContainConnectlnteractionSpec 560 is newly added in embodiments of the present invention to enable definition of connectivity and containment relationships.
The ResourceSpecification class 510 can be used for defining what a physical or logical resource is using the attributes within this class. The ResourceSpecification class 510 corresponds to the Resource class 610 in the inventory model of Figure 6. Embodiments of the present invention include the abstraction type attribute 512 in the ResourceSpecification class 510 to enable a resource to be defined as a NODE, VERTEX or EDGE. It should be noted that these attributes are added to the resource specification class to enable a common way of looking at instances of any respective concrete sub-classes (for example, 'Chassis', Operating system' or 'Logical Volume') that inherit their base class structure from the higher level resource class definition. Any business logic written to analyse architecture defined using this model at an abstract level can view the resource object instances as NODE, VERTEX or EDGE based on the abstraction type 512 rather than viewing the resource objects based on concrete class types.
The ResourceSpecification class 510 can also include a name (or
CommonName) attribute 516 which is used to describe what type of resource object is being specified, for example 'SQL Server 2008', this could be a CommonName attribute inherited from a RootEntity super class. In practice a NAME attribute in the resource object (of any particular ResourceSpecification type) will also be used for storing the real world name of each resource object, for example
'MELBOURNE_SQL_SRV_001 '.
The ResourceRole class 520 is a super class for both logical and physical resource role specification classes (such as LogicalResourceRoleSpec and
PhysicalResourceRoleSpec - these are not shown on the figure) and is used to define generally what functionality a logical or physical resource provides and requires.
Resource roles are also important for definition of hierarchical container structures.
Two important association attributes are provided on the ResourceSpecification class 510 that allow association to ResourceRole objects in order to fulfil important roles:
'providesResourceRole': when a ResourceRole 520 is associated to a ResourceSpecification object 510 via this association, it can be said that the
ResourceSpecification object 510 implements a generalised type of resource capability identified by the ResourceRole 520, e.g. a 'ComputeHost', 'Memory', 'Application Package', 'Network Connection Point', 'Transport Connection Point' or 'Database Replication Link'. Use of ResourceRole objects 520 is general i.e. the same 'RDBMS' LogicalResourceRoleSpec object is used across RDBMS ResourceSpecification items from all Vendors. ResourceRole objects must be unique, i.e. there can only be a single 'ComputeHost' LogicalResourceRoleSpec object. Only a single ResourceRole object may be assigned via the providesResourceRole association. This is deliberate so that during interpretation of ContainConnectlnteractionSpec objects (described next), the ResourceRole of the ResourceSpecification objects referenced by the 'supports' and 'supportedBy' associations is singular. Note that the providesResourceRole association allows assignment of subclasses of ResourceRole, for example
'LogicalResourceRole' or 'PhysicalResourceRole'.
'requiresResourceRoles': when a ResourceRole is associated to a
ResourceSpecification object via this association, it can be said that the
ResourceSpecification must be supported by another ResourceSpecification object having the specified ResourceRole as its 'providesResourceRole' ResourceRole type. For example, a ResourceSpecification having a ResourceRole of type 'Operating System' requires support from another ResourceSpecification providing a
ResourceRole of type 'ComputeHost'. If a PhysicalResourceRole object named 'PhysicalHost', and a LogicalResourceRole object named 'VirtualMachine' are available, and both of these provide the ResourceRole 'ComputeHost', then either of these objects may be used to satisfy the 'ComputeHost' requiresResourceRoles requirement of the 'Operating System' object. The requiresResourceRoles association plays an important part with respect to configuring 'generally compatibility' containment relationships, in particular where both physical and logical/virtual options exist. In addition to this, at the physical/logical boundary, compatibility specification can be refined further using combinations of CapacitySpec 550 objects to define required Processor Type and Speed and/or minimum Memory or Storage capacities etc. The requiresResourceRoles association allows assignment of both LogicalResourceRole or PhysicalResourceRole objects.
The model of Figure 5 includes a new concrete Interaction Specification class, ContainConnectlnteractionSpec 560 to define containment and connectivity attributes. This corresponds to the ContainConnectlnteraction class 660 in Figure 6.
Interaction specifications used to define connectivity and containment relationships between ResourceSpecifications can be extended usina additional attributes to more clearly define features or constraints of the relationships. For example, in addition to simply defining the containment or connectivity type, attributes can be provided to define containment importance, option groups, multiplicity and context. For example, a ContainConnectlnteractionSpec may indicate that a 'Windows 7 Standard'
ResourceSpecification object must be supported specifically by a single 'NTFS Logical Volume' ResourceSpecification object. Containment support defined via specific ContainConnectlnteractionSpec object 560 definitions allows finely grained description of supporting relationship associations between specific object types. This compares to the more generalised alternative form of containment support available via the
ResourceRoleSpec.requiresResourceRoles attribute (described previously). Enabling containment and connectivity relationships to be defined separate from the resource role relationships enables more generalised resource role definitions which, in turn, can reduce overall complexity.
ContainConnectlnteractionSpec 560 defines a specific structural relationship between two ResourceSpecification items. This may be either a Containment or a Connectivity based relationship defined using the ContainmentOrConnectivityType (abbreviated as CCT) attribute 562, for example using the COMPNT, SUPPT,
CONNECT and ACCESSPT attribute types as described above.
A number of further attributes can be defined on the
ContainConnectlnteractionSpec class definition, these can include: Containment Importance, Option Group, Multiplicity and Context.
Different levels of 'importance' can be defined for containment type
specifications. Containment importance 564 can have attribute types "Required" or Optional". "Required" specifies that an item type must be present for correct installation/operation of the relevant resource type. Failure to fulfil an interaction specification with containment importance of required can either cause generation of operator alarms or prevent the user from completing the relevant action. "Optional" specifies that an object type can be, but doesn't need to be added as a contained item.
Option groups 566 can be used where a logical resource type may potentially be added as a contained or connected item to just one of a number of optional item types. An example is the potential to add an application package to either a Windows or Windows 2008 product installation, but not to both. A mechanism is required to define such "options" within a "group" association type, so this is provided using the option group attribute in embodiments of the present invention. For example, if five types of "package container" have been specified as a supporting object type for a given object type, these may be grouped by specifying a common value in the option group attribute (this may be something meaningful, like the strina "PackaaeContainer" or a system generated code etc). Membership in the group is therefore based on the presence of a common value used across items within the same option group attribute, rather than assignment of items within a model based association. This can reduce the total number of model associations and complexity. Any given object type specification may have numerous option group sets relating to different
supporting/connecting object types.
Option groups may also be defined as an attribute of a resource role
specification or the resource role specification may be defined and used in a manner similar to option groups, as has been done in existing SDO and other information models. There are advantages however in defining option groups on the interaction specification class, separately from the resource role class. These advantages include: enabling the use of more generalised resource role definitions and clear association of option groups across containment/connectivity relationship sets.
It is necessary to be able to specify whether a specific resource type may be contained or connected by zero, one or many of the relevant ResourceSpecification type. This can be regarded as a classic 'multiplicity' type modelling issue and the Multiplicity attribute 565 is provided to enable this to be defined. Allowable values for the Multiplicity attribute 565 can include:
O.. V - zero, or at most, only one item.
- exactly one item.
'*' - zero, one or many items, commonly referred to as a Multiplicity value of
'many'.
The Multiplicity attribute can be used for all containment and connectivity relationship types. It should be noted that for defining current IT and networking systems, the Multiplicity attribute is mostly relevant for ContainConnectlnteractionSpec objects 560 that specify a 'Containment ' type interaction. This is the case because within the current system architecture multiplicity for CONNECT connectivity based items can usually be regarded as for connectivity type items in the context of current networking standards. However, it should be appreciated that the model can be used to define connectivity type relationships having any Multiplicity as may be required for emerging technologies and system management philosophies, or for non-IT system architecture.
Where an 'Option Group' exists, the multiplicity value on any of the member items specifies how many total instances of any of the various member item types may be associated to the relevant object. In the case of Option Groups, the system must ensure that the same value for Multiplicity is assigned across members of the same Option Group. There are occasions where multiple Option Sets exist such that selection of a choice in one will dictate the outcome of choices in the rest. This will tend to happen naturally, given for example where a sub-component is added to a Windows 2008 product, the other relevant supporting objects in that context will also be relevant only to Windows 2008. This could be supported using a more highly developed 'OptionGroupSpec' class model definition structure, rather than the option group attribute described above. This variation is envisaged within the scope of the present invention.
The Context attribute 568 allows a further specification of the meaning of a particular ResourceSpecification object item. It is a type of Role specification, but is used independently of the ResourceRole object in the model. A Context attribute 568 setting could be used for example where a point-to-multi point connectivity link was being specified, and the meaningfulness of the roles played at each end was significant. One end of the connectivity link may be classed as being the 'Source' end, another as the Target' end, and another as being the 'Listening' end.
A capacity specification object, CapacitySpec 550, is included in the model to aid integration between embodiments of the present invention and the Capacity Specification aspect of the SID Resource model. This is necessary because Resource Specification items may need to specify minimum availability of specific types of Physical or Logical Capacity, for example: Processor Cores (units), Bandwidth (kBps, mBps, GBps, etc), Capacity (MB/GB/TB etc) etc. Capacity 650 allows representation of what types of capacity are available for resource items from each of their relevant physical or logical resource containers, for example Processor Cores (units),
Bandwidth (kBps, mBps, GBps, etc), Capacity (MB/GB/TB etc) etc. Any logical resource may be related to physical resource containers over a number of logical and physical layer levels.
Support for management of system architecture using different management planes and enabling visualisation of the architecture from different perspectives using user interfaces is also provided in the framework of the present invention.
Management planes can be defined as layers using LayerSpec 575 and Layer 675 objects. As described above, layers in embodiments of the present invention refer to management planes which may conform to existing standard layer models but can also be flexibly defined. The use of LayerSpec 575 and Layer 675 for defining management planes is to enable backwards compatibility with existing architecture definitions which use these objects to define layers. Similarly classes used to define local locations ResourceLocalLocationSpec 570 and ResourceLocalLocation 670 are also used. The specific management plane in which a resource is managed can be defined using attributes in the resource local location object. Different management planes are defined for the architecture using LayerSpec 575 and Layer 675. A user interface may use the defined layers/management planes for visually representing the architecture. Visual presentation of object elements in conjunction with the objects they contain is a highly desirable capability within the user interface (Ul) of the invention. Typically, graphical user interfaces (GUIs) enable a user to view objects in their respective layers, one layer at a time. However, often the item(s) that contain another object will be defined and managed in a different layer. In these circumstances, not allowing parent container elements to be shown visually in conjunction with the items they contain can make any Ul more difficult to comprehend & navigate, and the resource structures involved more difficult to comprehend generally. Embodiments of the present invention provide support for architecture visualisation from different functional perspectives using ViewPointSpec 580 and Viewpoint 680. These classes enable definition of attributes used by a user interface for rendering representations of the architecture from different functional perspectives, referred to as viewpoints.
Support is desirable for visual presentment of the same object in more than one layer, and in embodiments of the present invention this is enabled using viewpoints. It is also possible that within any given Layer, multiple Viewpoints may be defined. A viewpoint can be defined for any functional perspective from which it may be desirable to view a representation of the architecture or manage aspects of the system architecture. Viewpoints can be defined to enable architecture to be viewed from perspectives independent of conventional ways of looking at or managing the system (such as operational layers or management domains). For example, consider a building and system architecture such as electricity supply, backup power/generators, lighting, air conditioning, water supply systems, sewage systems, communication networks, gas supply, elevator/escalator/travelator, security and emergency sensors and systems which are typically installed within the building and have various dependencies for operation. The architecture of these systems and
interdependences may be defined using embodiments of the present invention.
Viewpoints can also be defined for different functional perspectives, each enabling a representation of the architecture to be generated which is relevant for a particular user or purpose. For example, users may include facility managers, building security, service providers, IT managers of individual tenancies etc. A facility manager may utilise viewpoints which represent the interrelated systems from different perspectives relevant to their needs. For example, floor by floor, by access conduit /panel, or in a manner that highlights dependencies of systems such as systems dependent of a particular power source. Security staff may be interested in the systems from a functional perspective of alarms or access control and their supporting systems and viewpoints may be defined for each desired perspective. Building security may also have a role of emergency management and therefore may also have viewpoints defined for representation of systems which are essential, such as alarms and emergency communication, or to be controlled by security staff during emergencies such as elevators. The viewpoints defined for each purpose can be set up to display the level of detail required for each purpose.
The default (and current) visual representation/Layout Mode of any object may need to be different within each viewpoint. Where 'Folding' is supported in a specific layer type, definitions of the visual representation of the object in both 'folded' and 'unfolded' condition must also be supported. These factors require support in the information model, user interface and business logic layers for:
- specification of the specific viewpoint and layer type(s) in which each physical or logical resource type may be presented,
- the types of visual presentation allowed within each of those associated layer and viewpoint combinations, including specific images, colours, object sizes etc.
- Storage of screen sizing/positioning attributes, dynamically across all viewpoints, during operational manipulation of resource inventory object instances. It is also possible for objects having a connectivity relationship to exist in different layers and support for visualisation of such relationships via a Ul is also enabled using viewpoints in embodiments of the present invention.
In order to support multiple layer type definitions, including accommodation of the concept of standard layer types, a model element called 'LayerSpec' 575 is used. Within the context of an operational ManagementDomain, a corresponding 'Layer' object 675 is used as a container for all objects situated within any particular
LayerSpec 575 type. A ManagementDomain containing Resource objects may have one or more Layer objects 675 associated with it, grouping Resources within the ManagementDomain into respective Layers. Within the Catalog/Specification structure multiple LayerSpec 575 items may be associated to any one ResourceSpecification item. The attributes defined in the LayerSpec 575 and corresponding Layer 675 include a layer type (for example: Application, Transport, Compute, Physical layer etc) and layer name (for example: 'SQL Server Environment'). The LayerSpec 575 also includes an attribute for defining whether or not a layer is a network layer. It should be noted that the framework of the present invention does not limit layer definitions to current models such as the OSI layer model. Embodiments of the invention allow what may currently seem to be nonsensical layer orderings to be supported later, completely across the full spectrum of physical, network, compute and application domains. It is also envisaged that different layer types typically containing different object types that may act as containers for a common set of child items types will be present in a normal implementation, particularly with respect to 'virtualised' or 'cloud' based logical resource item containers that can also be realised as physical container object types.
ResourceLocalLocationSpec objects 570 are used to hold visual presentation attributes relevant to the definition of other object types, such as physical & logical resource spec items, 'visual presentation attributes' can include: Layout mode, Colour, Style (i.e. stylesheet) reference, Default shape / size information etc.
The information model of the invention allows for definition of multiple
ViewPointSpecs 580 associated with each LayerSpec 575 definition via associative ResourceLocalLocationSpecs 570 for each ResourceSpecification 510 definition.
Within each viewpoint, the layout mode used to present the object (and its immediate children) may be different. Layout modes can include: FoldingView, HierarchicalView, IconView, FreeformNetworkView etc. A user may change between allowed layout modes in the same way that a file manager, such as Windows Explorer, can be set into different 'view' modes (Large, Small Icon, List, Details, Tiles etc). This selection may be applied at the overall layer/viewpoint display level, or to the layout mode used within any specific object. Additional Layout Modes relevant to domains other than compute, network or application engineering may be defined and used also.
For any given ResourceSpecification object 510, a ResourceLocalLocationSpec object 570 is used to describe the relevant presentation attributes of that
ResourceSpecification object within each related ViewPointSpec 580 (i.e. for each Viewpoint the User may select for display, in which that object appears). This will result in an additional associative ResourceLocalLocationSpec object 570 being created per ResourceSpecification object 510, for every Viewpoint in which that
ResourceSpecification may appear. For example, a ResourceSpecification 510 definition for a system component is associated with two Layers and for each layer two viewpoints are defined, the system component can be visually presented in both viewpoints of one layer but in the other layer the system component is hidden from one of the viewpoints, therefore three associative ResourceLocalLocationSpec 570 are used for the system component to define attributes for presentation of the object for each viewpoint in which it can be presented. Within the ResourceLocalLocationSpec 570 relevant to each ViewPointSpec 580, a default layout mode is specified, and also a configuration of which other Layout Modes may be used to display the object in that Viewpoint. It should also be noted that more than one viewpoint for any given resource may be defined for a single layer as defined by the LayerSpec, allowing the visualisation of that resource object to adapt within each laver based on viewpoint presentation perspective. This also enables hiding of objects that are not relevant for a particular user perspective by use of viewpoint definitions, which can simplify navigation and management of the system via the GUI.
Each viewpoint is associated with a resource local location specification (as described above). The resource local location specification includes the attribute managedlnThisLayerViewpoint (Boolean), where True: means this item can be added/moved/removed with respect to containing parent objects when the associated layer viewpoint is visible, and the resource items appear in a Catalog Item list in this layer, and, False: means this item cannot be added/moved/removed with respect to containing parent objects when the associated layer viewpoint is visible, and this item cannot appear in Catalog Item lists in this layer.
ResourceLocalLocationSpec attributes describing which Layout Modes may be used to represent the object in the ViewPointSpec/LayerSpec any particular
ResourceLocalLocationSpec is associated to can include:
Boolean allowsFoldingView
Boolean allowsDragAndEnterView
Boolean allowsHierarchicalView
Boolean allowslconView
Boolean allowsFreeformNetworkView
ResourceLocalLocationSpec attributes describing which Layout Mode should be presented by default can include:
Boolean initiallylnFoldingView
Boolean initiallylnDragAndEnterView
Boolean initiallylnHierarchicalView
Boolean initiallylnlconView
Boolean initiallylnFreeformNetworkView
ResourceLocalLocationSpec attributes describing default size information for each Layout Mode can include:
Number positionFoldingCollapsedViewWidth/Height
Number positionFoldingExpandedViewWidth/Height
Number positionHierarchicalViewWidth/Height
Number positionlconViewWidth/Height
Number positionFreeFormNetworkWidth/Height
DisplayStyleSpec objects 590 describe which images should be used to display the object under each Layout Mode. The ResourceLocalLocationSpec 570 can include references to displayStyleSpec objects. Display style association attributes can include: DisplayStyleSpec styleFoldingExpandedView
DisplayStyleSpec styleFoldingCollapsedView
DisplayStyleSpec styleHierarchicalView
DisplayStyleSpec stylelconView
DisplayStyleSpec styleFreeFormNetworkView
Resource Local Location 670 can include attributes describing default position information for different layout types, for example such attributes can include:
Number positionFoldingCollapsedViewXPos
Number positionFoldingCollapsedViewYPos
Number positionFoldingExpandedViewXPos
Number positionFoldingExpandedViewYPos
Number positionHierarchicalViewXPos
Number positionHierarchicalViewYPos
Number positionlconViewXPos
Number positionlconViewYPos
Number positionFreeFormNetworkXPos
Number positionFreeFormNetworkYPos
Resource Local Location 670 can also include attributes describing default size information for different layout types, for example such attributes can include:
Number positionFoldingCollapsedViewWidth
Number positionFoldingCollapsedViewHeight
Number positionFoldingExpandedViewWidth
Number positionFoldingExpandedViewHeight
Number positionHierarchicalViewWidth
Number positionHierarchicalViewHeight
Number positionlconViewWidth
Number positionlconViewHeight
Number positionFreeFormNetworkWidth
Number positionFreeFormNetworkHeight
It should be appreciated that this information model can be used commonly to define all physical and logical resources and their relationships within a system architecture. The model also provides common elements for defining attributes that can be utilised by a user interface for presentation of the defined architecture from different viewpoints. The framework does not set or impose the precise design of any final structure used, but any class structure used must support the graph model structure to obtain the benefits of the present invention. As will be seen from the examples given below, the graph model structure can be flexiblv aoDlied. A skilled person may potentially design a generalised graph structured model architecture that does not use a pattern of class inheritance as described in this invention to implement various aspects of this invention including generalised containment and connectivity modelling across multiple model domains, integrated generalised specification & catalog structure, integrated generalised user interface elements, etc.
Abstraction of a layered architecture having connectivity and containment relationships An example of how the framework of the present invention may be applied to an abstract layered architecture defined using a combination of one or more existing SDO models will now be described with reference to Figures 8-10.
Figure 8 shows a simple example of a layered resource inventory structure 800 having an application layer 810, transport layer 820, compute layer 830 and physical layer 840. The layered architecture depicted in Figure 8 is defined using existing information models that have not yet been adapted to this design. The application layer 810 shows database management items that could be modelled using information models such as the SID or CI M, which can be extended to support specific application constructs, and supporting logical and physical constructs in a series of lower layers. The modelling classes used to support elements displayed are: Databaselnstance 812, Database 814, Transaction Log 816 and ReplicationAssociation 818. The transport layer 820 shows items that would typically be modelled using an information model such as the MTNM model, which supports network transport constructs. The MTNM modelling classes used to support the elements displayed are: MatrixFlowDomain 822,
FlowDomainFragment 826 and FlowPoint 828. The compute layer 830 layer shows items that could be modelled using an information model such as the SID or CIM models, which support compute object constructs (or can be extended to do so). Note that both OSI Layer 2 (Transport) and Layer 3 (Network) structures are effectively combined in the Transport layer diagram representation. Another layer would be required to manage these separately - this has not been done here in order to reduce the complexity of this example. The modelling classes used to support the elements displayed are: OperatingSystem 832, InstalledPackage 834 and LogicalVolume 836. The physical layer 840 shows items that would typically be modelled using an information model such as the SID or CIM models, which support physical resource constructs. Note that the elements in this layer of the diagram could have been presented in a Physical Resource design format showing the geometric structure of slots & subcomponents configured into each device. The physical layer as presented in Figure 8 appears more like a 'logical network' diaaram. The ouroose in doina this has been to keep this example simple and focused towards layering and connectivity interactions. The SID modelling classes used to support the elements displayed are: Chassis 842, PhysicalPort 844 and PhysicalLink 846.
If the above layers are represented instead using block-form object instances derived again from the existing SDO class model designs relevant for each layer, the resource inventory structure 900 shown in the diagram of Figure 9 is the result. In addition to the objects within each layer this diagram is also now showing the presence of associations between relevant objects across inter-layer boundaries. These associations are what define the 'layering' structure between layers. The various inter- layer object associations shown in this diagram are domain-specific, i.e. they are defined specifically within the existing domain information models used, and are therefore of different types. The class inheritance structure and naming of these existing inter-layer associations will also be relevant therefore to the existing domain information model they belong to or are extended from.
In the context of the Transport 920 and Physical layers 940, the associations
942 down into the Physical Layer 940 may be implemented using the defined associations on each of these relevant objects 844, 828. Each of these associations 942 would likely be titled 'physicalResource' given they both reference the
PhysicalResource objects in the Physical layer 920. In the context of the Transport layer, associations down into the Physical layer would be made using associations such as FlowPoint.physicalPort. It is likely that within the Transport 920 layer, an existing standard information model such as MTNM or a G.800 series model would form the basis of the implementation.
In the context of the Application layer 910, association 912 relates down into the Transport layer 920. This particular Database Replication association type is somewhat manufacturer/product specific, and is not likely therefore to have a direct representation among existing standard information models. Implementers of associations 912 would likely choose a name reflecting the object types being referenced such as Replication. FdFr. In the context of the application layer 910 associations 914 916 are also shown to relate down into the compute layer 930.
In the Compute Layer 930, associations 932 relating down into the Physical layer 940 would be made using associations such as OperatingSystem. chassis. In a fully described model, additional associations may also exist between Transport layer and Compute layer objects, describing which OperatingSystem or Package each Transport layer object is contained by.
In the case of the SID model, the primary modelling mechanism available for formation of complex association relationships between Physical and Loaical resources is via the use of Compound Resource objects. This effectively adds yet another class of object types requiring handling and interpretation overhead.
It can be seen from the above discussion that in order to perform a top-to- bottom traversal of the layering structures, a variety of association types across all the layer types expressed in the context of the relevant various information models, must be navigated.
When building an architecture that seeks to allow for flexible layering of different technology types, both in terms of which layer types must (or may) be adjacent to which other layer types, or with respect to the total number of layers present, the availability only of hard-coded, model specific associations becomes a significant limitation with respect to development of business logic that can handle processing or analysis requirements across multiple layers in a generic, abstracted manner. A similar issue presents itself with respect to traversal of object types and association relationships within layers, as each layer will potentially be based on a different class model or model sub-domain, with unique object and association types within each. As layering and partitioning structures grow in complexity, for example if virtualisation is introduced as a layer/technology type, and security domains are introduced within and across layer boundaries, the problems involved in implementing generalised business logic and analysis capabilities both vertically and horizontally across the entire Resource domain are heavily compounded. In the context of an OSS module that sits entirely above or outside the resource management layer, such as a Service management module, navigation of numerous domain specific object and association types becomes even more unworkable, and the need for a common underpinning information model that allows abstracted navigation of the entire resource domain becomes much more obvious.
By taking the above resource inventory structure example and adapting it to use the common model element described in this embodiment, the structure of the same elements at their super-class level changes to look like the example shown in Figure 10. (Note that the section titled 'Adaptation of Existing System Architectures and Resource Models' discusses in further detail how existing SDO and other information models may be adapted to the information model structure of the present invention). Figure 10 shows the same logical and physical resources at their abstracted super class level as resource objects having types Node, Vertex or Edge and interaction specification objects added to define containment and connectivity relationships. For example, the database instance 812 and its associated database objects 814 are abstracted as respective resource objects of type node 1012, 1014. An interaction specification object of type component (COMPNT) 1013 has been added to define the containment relationship between them. Similarly an interaction specification object of type COMPNT 1015 is used to define the containment relationship between the database 814 which is abstracted as Node 1014 and the transaction log 816 contained by the database 816, the transaction log being abstracted as Node 1016.
Interaction specification objects of type support (SUPPT) have been added to define containment relationships between objects in different layers 1010, 1020, 1030, 1040. For example, the inter layer relationship 914 between database 814 abstracted as Node 1014 and logical volume 836 abstracted as Node 1036 is defined using a containment interaction specification object of type SUPPT 1035.
Interaction specification objects defining connectivity interactions between objects within the layers 1010, 1020, 1030, 1040 have also been added. For example, in the transport layer 1020 an interaction specification of type connection (CONNECT) 1027 is added between the Flow Point 828 abstracted as Vertex 1028 and Flow Domain Management Fragment 826 abstracted as Edge 1026. As can be seen in Figure 10, there is a small set of standardised super class types that need to be supported by any business logic operating at the abstract graph-structured model view level that performs processing or analysis activity within or across one, many or all resource layer types. Any number of layers can be present, and new layers, layer types and model types can be added and removed, all without impact to the structure of any existing business logic that is written to reference the class model at the abstract super class 'view level' of the common graph-structured class model.
A disadvantage is that a higher overall number of object instances may result from the use of this information model, due primarily to the presence of interaction specification classes. A higher overall number of objects under management may affect: OSS data storage requirements, network bandwidth requirements, application server processing requirements and data model complexity. However, the advantage is a higher level of management, processing and analysis capability across multiple resource engineering and business domains.
Note that the Compute layer described in this example is a deliberately simplified representation of what could be represented in a real implementation of this design as separately defined Host, Volume & Storage Layers. In a different implementation of this system architecture also using this framework, a 'Compute' layer may optionally instead be implemented such that it sits above the Network Layer. This might represent an entirely different class of objects, for example those required to describe a distributed computing grid. Application type resource specification definitions may in turn be defined to support distributed application containment and connectivity structures in a relevant layer type above this. Note also that the Viewpoint capability in this framework enables selected objects from across multiple layer types, such as Host, Volume & Storage layer types to be presented in the same presentation perspective, and to be managed with direct reference to each other in the Ul. Overview of the object oriented framework of a second embodiment of the invention A framework for the second embodiment of the invention discussed with reference to Figure 4B will now be looked at in more detail with reference to Figures 39 and 40 which represent two complementary class models, described at the abstract super class level for this embodiment. In this example Figure 39 shows a specification model and Figure 40 an inventory model. Similarly to the embodiment described above these models can be used in a unified catalog environment as described above with reference to Figure 7. Similar to the first embodiment classes such as
ResourceSpecification 3910 and ResourceRole 3920 are classes which are used in existing information models. The ResourceSpecification class 3910 is a super class and the abstract classes ResourceNodeSpec 3950, ResourceVertexSpec 3970, and ResourceEdgeSpec 3990 sit below this super class in the inheritance hierarchy. The ResourceSpecification class 3910 corresponds to the Resource class 4010 in the inventory model of Figure 40. The ResourceRole class 3920 is a super class used to define generally what functionality a logical or physical resource provides and requires.
In this embodiment any resource specification class definition representing a resource object type having Node, Vertex or Edge characteristics, added for example in the context of a domain specific information model, must be defined as a subclass of one of the abstract classes ResourceNodeSpec 3950, ResourceVertexSpec 3970, or ResourceEdgeSpec 3990. Thus, any Resource 4010 object will have inherited parent object type characteristics of one of Node, Vertex or Edge - this object type being based on the functionality of the resource in terms of the graph based structure.
Association specification classes ResNodeAssocSpec 3940,
ResNodeVertexAssocSpec 3960, and ResVertexEdgeAssocSpec 3980 are provided for definition of connectivity and containment relationships between system
components. Association classes ResNodeAssoc 4040, ResNodeVertexAssoc 4060, and ResVertexEdgeAssoc 4080 in the inventory model of Figure 40 correspond to the association specification classes in Figure 39. The association objects created for any one resource being defined using this model will depend on the resource object type (Node, Vertex or Edge) and the type of each resource object associated by a connectivity or containment relationship. ContainConnectRole 3930 is a super class provided to enable generalised definition of containment or connectivity functionality in respect of association objects, similar to the use of ResourceRole 3920 with resoect to resource objects. Association classes are concrete classes and instances of association objects are created for each containment and connectivity association between resource objects. In this manner association objects are used similarly to ContainConnectlnteraction objects of the first embodiment of the invention.
ContainConnectRole objects can be used to describe the generalised functional or application related nature of the association, without inferring any specific manufacturer or product. For example, a ContainConnectRole object 'RDBMS
Transaction Log contained in RDBMS Database' may be used to describe this generalised functionality and optionally any general constraints. The same
ContainConnectRole may be referenced by multiple product specifications and products, for example the ContainConnectRole 'RDBMS Transaction Log contained in RDBMS Database' may be referenced by Oracle, IBM and Microsoft specific RDBMS database product specification definitions. The Name assigned to a
ContainConnectRole object instance could therefore be used as a generalised tag by any business logic operating at the abstracted information model layer in order to efficiently locate and/or make traversal or analysis decisions across all
implementations of a particular type of product, regardless of specific products or manufacturers.
Association objects are associated with ContainConnectRole objects which can define attributes related to the generalised function or application of the relationship the association object defines. The attributes defined on the ContainConnectRole object can be fundamental to the association and therefore common to any implementation of the association. For example, the attribute Name to define the generalised name of association. An attribute Category can be used to define a category of role which may confer explicit or implied constraints.
Further attributes which can accommodate variation in implementation are defined using attributes on the xxxAssocSpec class type. For example, the
generalised association described using a ContainConnectRole object may not necessarily constrain the association to being a containment or connectivity role.
Assignment of whether any particular structural association is being implemented as a containment and/or connectivity form of association is indicated via use of the isContainmentRole and isConnectivityRole attributes on the respective xxxAssocSpec class types. Vendor specific product implementations may have differences with respect to how certain resource object types are contained or connected within what are product definitions that are otherwise similar to those from other manufacturers. The location of the isContainmentRole and isConnectivityRole attributes on the xxxAssoc & xxxAssocSpec class definitions allows this flexibility, awav from the generalised assignment of functional or application related nature. It should be appreciated that any relationship between two node objects will be one of a
containment role the attributes isContainmentRole and isConnectivityRole may be omitted from ResNodeAssocSpec 3940.
Attributes can be defined on the xxxAssoc & xxxAssoc class definitions to further characterise the interaction relationship being defined. For example, multiplicity can be used to define whether the containment or connection relationship may be zero or one, only one, or many. An interaction attribute can be used to define special interaction cases, for example COMPNT to define a component containment type association between objects in the same layer or SUPPT to define a support containment type association between objects in different layers. The Interaction attribute can also be used to define special interaction cases for connectivity relationships, for example CONNECT to define a connectivity relationship between objects within the same layer or ACCESSPT to define a connectivity relationship for an access point. It should be appreciated that attributes on the xxxAssoc and
xxxAssocSpec classes can be used to define characteristics of the interaction relationship in detail. It is envisaged within the scope of the present invention that the attributes on the xxxAssoc and xxxAssocSpec classes can be extended to include additional attributes or attribute types to accommodate variations in connectivity and containment relationships from those described in the above examples.
This second embodiment of the invention also allows adaptation of existing information models to the graph based structure of embodiments of the present invention while retaining the overall structure and usage style of any such existing information model. The inheritance hierarchy of existing information models may require some modification to adapt them to the graph based structure of the second embodiment of this invention. Some associations in existing information models may become redundant, but would remain usable. This can enable architecture defined using an existing information model and modified for the graph structure to be traversed by business logic operating both at the abstract class level using the graph structure supported in this invention and also by business logic adapted to traverse associations present in the original design of the existing information model. For example, relocation of inheritance associations from a super class in an existing model to the relevant abstract super class described by this invention (e.g. Node, Vertex or Edge) may mean that some superclasses in the existing information model may cease to be relevant in the graph based structure. These may be left in place in order to maintain the ability for existing/legacy business logic to traverse the information model as if unmodified. In implementation architectures where multiple inheritance is supported, existing information models may be adapted to inherit from and therefore utilise the graph based model structure of embodiments of the present invention, without any modification to the inheritance structure of the existing model.
Similarly to the first embodiment, layers and associated viewpoints can be defined for each layer and attributes for graphical presentation of each resource object defined for each viewpoint as described above. The classes for definition of layers and viewpoints, and the ResourceLocalLocationSpecification and ResourceLocalLocation classes for defining presentation attributes for each applicable viewpoint for a resource are not shown on Figures 39 and 40, but it should be appreciated that these may be added and used similarly to the model of Figures 5 and 6. It should also be appreciated that the features described below using examples employing the object model of the first embodiment are also applicable employing the object model of the second embodiment. Mock Item Definition and Operation
Any resource specification object acting as the root object within a product component item structure can be specified as supporting Mockup state. Mock objects are intended to have the same semantic meaning as their fully specified object counterparts, which may potentially have one or more levels of child object hierarchy. For objects created in mockup state, instead only a single resource inventory object is created, mirroring just the root specification object. The system will not generate inventory items mirroring child resource specification objects for the product component item structure concerned. Any mock object will usually have the same appearance as a fully specified object of the same type, when it is in the
folded/collapsed view state.
Within the specification data model, support for mockup state is implemented by the presence of a boolean flag called 'MockupAllowed' 514 on the Resource Specification class. During creation of Resource inventory objects based on a
Resource Specification where MockupAllowed mode is true, the user must indicate whether the object is to be created in fully specified or 'mockup' mode. This selection may be aided automatically by the system Ul via the use of default settings, defined either globally or at a more fine grained level.
Mock items allow a user therefore to quickly generate a 'mocked up' resource inventory design, as though they are using simple object shapes within a generalised diagramming / drawing tool, avoiding any detailed specification structure validation or rule evaluation, at that stage. Normal treatment of containment, connectivity, layering and role related rules are relaxed by the system with reaard to obiects beina used in mockup mode.
Mock objects can therefore allow a User to freely 'map out' an intended framework of objects at a high level and any type of potential connectivity associations between them, in much the same was as using a general purpose diagramming tool that imposes very few restraints on object linkage rules. At a later point in time, mock items can be re-classified into fully specified resource items.
System architectures containing mock object items may be sent as a notification to multiple other parties, such as supplier partners, indicating the general intention for a structural change to resource inventory. The notification may include a request to re-classify any mocked-up objects contained in the system architecture to fully specified object types. The finished result could represent a solution proposal submission from that supplier partner. The system may provide warnings if connectivity rules belonging to the object types concerned are not realisable in any way in future conversion of the object to a fully specified type object.
Connection type resources association with mock objects are also classed as being mock objects, and likewise can also be later transformed into fully specified connectivity objects. Examples may include mock connectivity associations between mock Routers, Switches, Database Servers, and Virtual Machines etc. Planning lifecycle activities may include a mixture within the same management domain of pre- existing, fully described conventional objects that are already in a more advanced lifecycle state, and Mock objects that have been added to describe an intention to create or replace a complex resource of some sort.
In general, based on expected patterns of resource specification layering, connectivity relationships should normally only exist between objects situated within the same Layer. This is the case with respect to resource inventory objects in either the detailed planning lifecycle state, in an approved operational state, or in a retired or decommissioned state. It is normal however that during early planning lifecycle stages, intended connectivity and containment structures may only be known at a loosely defined level. It should be possible therefore at this point to use very simple early stage representations of resource object types and any connectivity associations between them, within any layer, rather than being forced to fully describe detailed containment structures in order to be able to then connect valid connectivity associations through to specific child items within those containment object structures (perhaps across Access Point boundaries). Because the term 'planning' is intended to refer to the
development of complex containment & connectivity structures, the term 'Mock' object has been chosen instead to describe these early or replacement stage object representations. This is in keeping with a general namina pattern used in various industries and knowledge domains whereby 'mock' objects are used to represent the initial existence of something that will be expanded or replaced with a detailed representation at a later point.
Layering rules are also relaxed for mock objects, allowing Mock objects to be placed within any available layer. Depending on the structure of any specific resource specification, a mock representation of that object type can represent the intention to ultimately implement a complex resource structure that extends across multiple layer types. The inclusion of a mock object into a single existing resource layer, as a part of an expansion/change planning exercise, may therefore be interpreted as implying that connectivity associations are being formed between differing layer types. In fact they indicate an intention to form regular connectivity associations within other layers at a later point in time. During re-classification of any mock object to fully specified state, layering rules as defined within the configured structure of the associated product component item structure must be obeyed.
Given that it is possible to configure any resource specification type as supporting MockupState state, this allows sub-component items to be used as mock objects in addition to major components. At a later point, should the user wish to start defining the fully specified containment structure and connectivity associations for any object currently in mock state, they (or automated system logic) can first change the MockupState attribute of the object from 'mockup' to 'intermediate'. Once all relevant structural rules have been satisfied, the object may then progress to a MockupState of 'fullySpecified'. Similarly, if a mock object has any associated connection objects in mockup state at this time, an intermediate MockupState should be applied to the object instead, such as 'intermediate'. This indicates the presence of mock connection associations against the object that have not yet been resolved into fully specified connections. Once appropriate child objects supporting the relevant resource vertex specifications/connectivity types have been added, and all mock connectivity objects have been relocated to these vertex connection points, the original underlying object mock object(s) may then be re-classified from being in 'intermediate' to fully specified state.
Given that mock objects are in fact objects of a specific resource specification type, they inherently possess the same requires/provides Roles, capacity
specifications and other characteristics of that resource specification type. This allows the system to provide Users with information regarding the intended size or function of the object while it is in mockup state. Mockup objects may aggregate capacity, usage, fault rate or any other form of relevant information from child specification or inventory items. At the time a resource object is reclassified from mockup to fully specified state, it should be possible to substitute any other resource object type. Regardless of which specific product component item specification is chosen, all of the structural rules associated with that item must be obeyed, and/or appropriate warnings generated and/or logged. When searching for replacement objects, requires/provides Roles, capacity specifications and other characteristics of the resource specification that define the mock object can be used to refine search result sets for suitable
replacement object types.
Capacity Spec 550 items (and a nominated quantity of the relevant capacity type) could be specified against ResourceSpecification items with MockupAllowed configured as true, such that any real product selected for fulfilment of a derived mockup item must support at least the minimum quantities of the defined capacity specs (or else an Alarm would be generated and/or the user prevented from
completing the action). Note that some Capacity Spec items may have a notion of a generalised 'type' associated with them also - e.g. 'INTEL x86', or 'INTEL Itanium' etc. During infrastructure Planning exercises, it is possible that the Customer may not want co-operating supplier / partner organisations to be provided with information regarding the detailed composition of specific resource inventory items within the customer's existing network, for example at early stages of the planning or engagement cycle. To effect this, the Customer may create a Planning copy of the relevant
ManagementDomain(s), and within this revert some or all existing detailed resource inventory objects into mock equivalents. This would require the reverse of the process described above - all contained children of a base inventory object selected for reversion would need to be removed, and all connectivity associations to either the base object or any contained child object would need to be reverted to being in Mock state and re-homed to the relevant base inventory object.
Adaptation of Existing System Architectures and Resource Models
It should be appreciated that a system defined using one or more existing information models can be transformed to the information model of embodiments of the present invention without losing their original architecture definitions, and so may be used compatibly with business logic operating for both the existing information model and the information model of the present invention.
In a case where a given system architecture has been defined using existing information models, the additional class types, generalisations and attributes required can potentially be re-aligned or added to enable graph based abstraction using the information models of embodiments of the present invention. Deoendina on the structure of the existing information model, this conversion transformation may be no more invasive than adding the relevant abstraction type attributes to an appropriate super class. Conversely it may require more complex re-homing of inheritance relationships, thereby breaking the original structure of the information model to some extent. In all cases, new class types that are specific to embodiments of the invention will need to be added and related as is appropriate into the existing information model, for example, with respect to ContainConnectlnteractionSpec &
ContainConnectlnteraction classes for the first embodiment and association classes for the second embodiment. In some information models, such as the SID, self- referencing class model structures are made available for many class types as a generalised modelling pattern, without description as to their specific use, or support of specific attributes. It is possible to adapt the design of such an existing self-referencing class association reference for the purpose of implementing the specific containment and connectivity interaction utilisation pattern described in embodiments of this invention.
If modification of an existing information model is completed successfully, each relevant converted resource inventory object instance could then be traversed by business logic acting at an abstracted level as a Node, Vertex or Edge, via associative containment and connectivity objects, in accordance with embodiments of the present invention. For example, by adding the abstraction type Node to the design of the SID Resource super class, all existing and new sub classes of the Resource super type, including Chassis and Database object instances, could then be traversed simply as Node type objects. New Interaction specification objects must of course also be created based on existing association relationships.
Modification of the design of existing association / link type class associations may result in use of the original association type being abandoned in favour of full conversion to the use of the ContainConnectlnteractionSpec &
ContainConnectlnteraction classes as per the first embodiment. For example, with respect to existing resource inventory object instances, if an existing Cable object was directly associated to two existing PhysicalPort objects, it would be necessary to create two new CONNECT type Interaction objects for association at each end of the Cable (Edge) object (between it and each of the PhysicalPort objects). The original
Cable. physicalPort associations could be regarded as being redundant, and therefore no longer supported or used.
Alternatively, the old form of existing model association types may be retained and managed in conjunction with the corresponding new model elements.
In either case, it would still be possible to present an unchanged view of resource inventory structure at the Ul level according to any given relevant existing SDO model standard, and also to any external systems across any interfaces supported.
Component Resource Item Specification examples for the first embodiment
In the real world, complex physical and logical system structures are built up from numerous individual component items that are combined and connected together in whatever manner is required and allowed. The Specification Data Model described in this embodiment supports creation of template specification structures for the purpose of defining individual system components in terms of their internal
containment structure, their ability to form external containment and connectivity associations, and other factors including which layer types they are supported in and supported interaction types etc. Related component definitions may be added to user accessible catalogs. Catalogs are used at run time to locate component definitions of specific types, and to provide access to various types of detailed information for each component managed including the contents of the detailed Specification Data Model structure for any given specific component item.
Numerous modelling techniques for grouping of Specification Data Model object instances into component item structures are possible. The approach shown in Figures 11 , 12, 12A, 12B & 12C is based around the use of ProductSpecification objects. For every resource component being defined, a single ProductSpecification object associates to and groups all the relevant ResourceSpecification,
ContainConnectlnteractionSpec, ResourceRole, CapacitySpec,
ResourceLocalLocationSpec, DisplayStyleSpec, LayerSpec and ViewPointSpec objects together into a single identifiable unit, suitable for inclusion into a product catalog. This structure is referred to as being a product component item object set. The
ProductSpecification has a special association to the 'root' ResourceSpecification object, which will usually have the same name as the ProductSpecification object. Other grouping techniques are possible, such as using the root ResourceSpecification, or using a CompoundResourceSpecification object type. Any grouping technique is considered within the scope of the present invention.
It should be noted that a product component item object set can make reference to any number of other product component item object sets in order to configure allowable association relationship rules. This type of cross referencing is necessary for most component item definitions. Any product component item object items referenced in this way do not become 'owned' by the referencing objects, they simply become associated product component item object sets that they are dependent on. A convention used for product diagrams used in this example can be explained with reference to Figure 11 , which is an example product specification structure that conforms to the framework of the invention. In the following diagrams, 'referenced' objects belonging to other product component item object sets have a dashed border. Any such referenced object will be the 'root' resource specification item of another product component item object item being referenced. Other object types that are not directly owned by the component specification being defined are also shown having a dashed border, such as LayerSpec items etc. Those objects that are owned as a core internal item of the component specification being defined are shown with a solid border.
Complex resource item structures may be built up at run time by selecting compatible component specifications from the relevant product catalogs, and placing them into compatible locations within existing resource inventory items, in turn situated within the overall resource inventory management domain being manipulated. Each time a new product component item is added from a resource catalog, the system creates a mirrored structural representation, using Inventory Model based counterpart objects, of the Specification Model objects that are directly owned by the resource catalog item type being added. These new objects are added as members to the resource inventory management domain being manipulated at the time. The new inventory objects are firstly associated back to the specification objects they are derived from for future reference / validation purposes. They are next associated to the connecting and/or containing resource inventory objects the user has selected as being the targets of the addition operation. Any such connecting or holding target object must be an implementation of a required / compatible related object defined in the product component item specification of the item being created. From the perspective of the component product item definition of the item type being added, this will be seen as a related specification object having a dashed border in the
ProductSpecification diagram.
The ProductSpecification diagram convention used in this design depicts: the high-level product item being described, the root and any other resource specification objects, Specification of ResourceRoleSpecs; Specification of containment and connectivity relationships. The product items depicted represent product subcomponents that would typically be packaged with each other subsequently in order to produce what a customer would recognise as a familiar product item (having a complex make up). Product items should ideally be structured such that a recognisable resemblance or meaning exists between resource types as they exist as engineering level structures and component product item definitions that can be added to Product Catalogs & made available to Users.
Each diagram contains a root ResourceSpecification object 1110, referenced by the AtomicProductSpecification object 1120. The diagrammatic line connector shown between these two particular items is the only one shown with doubled line weight. This pair of objects represents the specific product resource element being defined on the diagram. Any other resource specification objects 1 112, 1114 define either containing resource object types, contained resource object types, or resource types that support connectivity relationships. ContainConnectlnteractionSpec
Interaction specification objects 1 116, 11 18 show containment relationships using » and « symbols. Where the symbol "»supports»" appears, this indicates that the ResourceSpecification object that is sitting visually in the diagram to the left of the relevant ContainConnectlnteractionSpec object is a container of the
ResourceSpecification object sitting visually to the right. Note that the ""«supports«" symbol indicates the reverse. Note that a ContainConnectlnteractionSpec object having a ContainmentOrConnectivityType (CCT) of SUPPT has a different meaning to the "«supports«" symbol.
Every Logical Resource Product definition diagram will contain a single
AtomicProductSpecification item 1120, which is the grouping object for all other objects visible in the diagram from a business logic perspective. Loading the
AtomicProductSpecification 1 120 as part of a Catalog query will usually be done in conjunction with all other object items seen in the diagram to be loaded with it, including any referenced object items. All visual items depicted with a solid border are those defined (created originally) in the context of this particular
AtomicProductSpecification 1 120. All visual items with a dashed border are those that have been defined Outside' this AtomicProductSpecification defintion, but are referenced by it. Referenced objects may belong to other component /
ProductSpecifications. This includes ResourceSpecification,
ResourceLocalLocationSpec and ContainConnectlnteractionSpec object types.
Referenced objects may also exist as generalised items in the system, not belonging to any particular product component item specification. LayerSpec, ResourceRoleSpec,
CapacitySpec, DisplayStyleSpec and ViewPointSpec types fall into this latter category.
Objects which describe how the object concerned is managed from a layering perspective within the user interface can also be shown. These objects can define layer and viewpoint associations. ResourceLocalLocationSpec items 1 130 1140, shown with a solid border, are defined (created originally) in the context of this particular product component item specification. LayerSpec items 1150, 1 160 shown with a dashed border are not owned by any specific product component item specification. The presence of and association to LayerSpec items 1150, 1160 indicates that resource instances derived from this particular product component item specification can appear in view point representations belonging to these two 1 150, 1160 layer types.
It should be noted that of the various figures following Figure 11 , some represent specification item structures, while others represent resource inventory object structures, implementing those specification object types. An attempt has been made to use different visual styles for different types of specification objects, but to use the same visual style for any given specification object type and any resource inventory objects derived from that particular type of specification object when presented in the same or other diagrams. Some care needs to be taken therefore to recognise inventory class objects from the specification object counterparts they are derived from.
Fixed Hierarchical Container Specification
It is often necessary to support containment for objects having similar but distinct types in a hierarchical (tree structured) format of a pre-defined nature. The configuration of any such structures is established at specification time, within the context of a single product component item definition.
An example of a fixed hierarchical container specification structure is shown in Figure 12 which is an example of a structure for 'Windows 2008 Standard Edition'
1210. Note use of the same common parent ContainConnectlnteractionSpec 1220 for items in a multi-level hierarchy for 'Package Containers' 1230, 1250, 1255. (Package is a term meaning 'installed software application, script or device driver' relevant generally in the context of system/software implementations, including Unix, Linux, Routers, Windows, Commercial or Open Source Applications etc). This specification structure allows two types of package containers of types 1250, 1255, to be contained under umbrella package containers of type 1230 in a single level of hierarchy, meaning in a fixed, non-recursive manner. Package containers of types 1250, 1255 are able to provide containment to Windows 2008 specific packages and general windows packages respectively. Any package items contained within either a Windows 2008
Specific Package Container 1250 object or Windows General Package Container 1255 object automatically become children of the parent Windows 2008 Package Container 1230 containment structure.
A key point is that multiple levels of Node ResourceSpecification 1230, 1250, 1255 items are associated to the same 'Package Container' LogResRoleSpec item 1260. Awareness of these structures needs to be implemented into any relevant business logic implementations, such that they are able to recoanise that the same LogResRoleSpec item 1260 is being encountered during traversal of any such structures.
Dynamic Hierarchical Container Specification
Certain container structure types must support any level of hierarchical depth and potentially even dynamic extension of such hierarchical structures of the same derived resource object type by Users at run time. For example, Windows Group items, which are access security grouping items in the Windows operating system, may be added at run time as members of other existing Windows Groups. It should be possible create and add child Windows Group items within other parent Windows Group items, to whatever level of hierarchical depth is required by the User. Support for specification of dynamic hierarchical containers requires creation of additional component product specification items (as compared to support for fixed hierarchical container structures, which do not).
An example of this is given in Figure 12A, for the product component item
'Windows 2008 Group'. Interaction spec 12A20 has supports and supportedBy associations that are both assigned to Windows 2008 Group 12A10. This specification model structure allows an existing Windows 2008 Group resource item to act as a container for another Windows 2008 Group item. Before a Windows 2008 Group can be added as a hierarchical child of another parent Windows 2008 Group, according to the structure indicated in this example, at least the initial Windows 2008 Group must have been added to an existing Windows 2008 Active Directory resource item 1240. An example of Windows 2008 Group resource items structured in this way is provided in Figure 12B. A single Windows 2008 Active Directory 1240 object can be seen supporting a contained Windows 2008 Group 12B20, in turn supporting multiple contained children / grandchildren Windows 2008 Group objects 12B30 in a
hierarchical structure. Users may continue adding further Windows 2008 Group objects dynamically as is required. Note that '«supports«' style indication is not shown on object 12A20 due to the nature of this example and explicit inclusion of the 'supports' and 'supportedBy' associations.
Inter Layer Type Containment Definition
Product component items that can be contained by other product component items that are themselves defined within a different layer type must do this using ContainConnectlnteractionSpec reference association items having a
ContainmentOrConnectivityType attribute value of SUPPT. An example of this is given in Figure 12C, for a 'BroadCom Ethernet NIC NetXtreme Device Driver' 12C10. This defines the specification model structure for a device driver software product component item that supports the operation of a set of physical Ethernet network adapters manufactured by the same company 12C20, 12C30 & 12C40. The
ContainmentOrConnectivityType attribute value of SUPPT is configured on
ContainConnectlnteractionSpec 12C21 , 12C31 , 12C41 objects relating these items. The presence of the SUPPT attribute value indicates that establishment of derived containment associations will require inter-layer handling, potentially causing additional catalog fetch & Ul management operations etc. The same product component item definition also includes COMPNT type ContainConnectlnteractionSpec references 12C50 & 12C60 to resource spec items 1270 & 12C80 that may act as containers within the same layer type. Note that diagram 12C omits ResourceLocalLocationSpec & LayerSpec objects for the sake of simplicity.
Option Group Support
Present on the product component item structure shown in diagram 12C10 is the definition of OptionGroup attribute values of DRIVERCONT on
ContainConnectlnteractionSpec objects 12C50 and 12C60. This configuration specifies that any BroadCom Ethernet NIC NetXtreme Device Driver 12C10 instance can form a containment association with only one of either a Windows 2008 Device Driver Container 1270, or a Windows 7 Device Driver Container 12C80. This is in addition to containment relationships to the various physical network cards specified, of which there may be multiple instances of the same or different types present (hence there are no OptionGroup constraints specified against these object types). Physical network cards of types 12C20, 12C30 & 12C40 may in turn be contained within the same parent object (likely to be a Chassis type object).
Generalised Containment & Connectivity Specification
Certain types of containing resource specification objects may be intended to conform to a standardised specification that is utilised by numerous other containing resource specification objects also. For example, it should be possible to configure a resource node container representing a physical Slot, as might be available on a computer chassis, as being compatible with the PCI standard. It might also be desirable to configure a vertex type resource object representing a physical Port as being an Ethernet compatible port. There are many technical factors associated with supporting standardised containment & connectivity specifications, including support for: backward compatibility, directionality, 'ganging' of adjacent slots or ports, feature set capabilities, speeds, protection etc. A number of existina standards-based approaches for the management of such generalised containment & connectivity compatibility capabilities can be added to support this aspect of the structure of this design. Link Specification
Definition of Resource Edge (Link) specification items is possible in this information model but not necessary in all cases. Business rules associated with the implementation of a generalised containment & connectivity compatibility architecture as mentioned above can potentially be implemented to allow dynamic management within the Ul of the creation & manipulation of link items, where requirements are generalised enough to allow this.
It is possible also to use the general product component item structure to define resource Edge (link) type items. An example of this is illustrated in Figure 12D. A Unidirectional Trunk Link 12D10 is described having CONNECT type connectivity interaction association objects 12D30 & 12D40 specified in conjunction with vertex type resource specifications 12D50 & 12D60 having Context type Ά End' and Context type Έ End' respectively. Instances of this link type may therefore be formed where one end of the link connects to one vertex type resource implementing Ά End' meaningfulness with respect to the connection, and another implementing the Έ End'.
Access Point support
'Access Point' is a term used to refer to a logical resource that provides connection point capability in particular for internally situated software resource items, where a connection point capability is defined to exist at an outer boundary interface layer in the architecture of the software resource type concerned. The high level parent software resource type may have many internal software component objects of one or more types that can be connected to, but only via such an interface located at the outer architectural boundary of the parent. Example Access Point implementations may include Application Programming Interfaces, SOAP/Web Services interfaces, middleware / messaging system interfaces etc.
Access points enable connectivity therefore into internal logical resource objects contained somewhere within a parent logical resource object. The parent logical resource acts as both a container to the internal resource being connected to, and also as a boundary location at which external required connection point capability for the internal resources is located. For example, Access points located on SQL Server RDBMS Instances provide interface connection capability to internal RDBMS logical resources such as Database or Reporting obiects. The framework of the present invention enables internal resource object instances to be contained to any level of nested hierarchical depth within a parent owning any access points relevant to the internal resource objects concerned.
A simple access point example is shown in Figures 8 to 10. The application layer 810 shows two database instances 812, and a database replication association 818 between two databases 814 situated within the two database instances 812.
Figure 9 also shows database replication association 818 present in an object instance representation. Real database objects are internally contained objects of database instances, and the only form of external access to them is via connection points defined on the database instance parent object. Configuration of both the relevant database instance connection point and also the particular database endpoint reached via that connection point must usually be managed for each end of real world database replication objects. Figure 8 shows the presence of such an external point of connectivity, Access Point 1050 on the Database Instance 812 that is allowing connection through to the Database 814 contained within the Database Instance 812.
Figure 10 shows how the first embodiment of the framework supports an implementation of a fully described structure showing an Edge type resource object connecting via Access Points into internally situated Node type resources, and also supporting items objects in lower layers. Items depicted are expressed as object instances at the abstract graph-structured common model element level.
All resource inventory objects shown are represented abstracted to their respective resource specification of type node, resource or edge in accordance with the framework of the present invention. It can be seen that the database instances 812 are abstracted as Node type resource objects 1012, access points are abstracted as vertex type resource objects 1050 and the containment/connectivity relationship between the Node 1012 and the Vertex 1050 is implemented as a COMPNT type ContainConnectlnteraction relationship object 1055. The ContainConnectlnteraction relationship object 1055 enables the access point 1050 to act as a connection point for the Database Instance 1012.
A ContainConnectlnteraction relationship object of ACCESSPT type 1058 is defined between the access point abstracted as Vertex 1050 and the Database Replication abstracted as the Edge 1018. The Database Replication abstracted as Edge 1018 provides a connectivity relationship between the two Database Instances abstracted as 1012 via the respective access points abstracted as 1050. Additionally, a ContainConnectlnteraction relationship object of ACCESSPT type 1059 is defined between the Database replication abstracted as Edge 1018 and the Database endpoint object abstracted as the Node 1014. The combination of ContainConnectlnteraction relationship objects 1058 and 1059 configures the Edge instance 1018 in a manner that makes visible both the relationship with the Vertex instance 1050 acting as an externally accessible Access Point and the relationship with the 'internal' Database instance 1014, which are the external & internal pair of objects referenced by one end of the Database Replication 1018 Edge object, to thereby define the access point relationship. Note that objects 1058 and 1059 are not themselves Access Point objects, but rather are ContainConnectlnteraction relationship objects having
Interaction type configured as 'ACCESSPT', indicating that they play a role in the implementation of an Edge type object making an Access Point based connection. The ContainConnectlnteraction relationship object 1059 defining the access point relationship between the Database Replication Edge type object 1018 and internal Database instance node object 1014 imposes an additional limitation on the relationship defined between the Access Point Vertex 1050 and Database Replication Edge 1018, to define the end point of the access point connectivity relationship and thereby complete the access point definition.
Whilst this example is given in the context of a connectivity structure that is supported by an underlying network transport structure, it is not required that connectivity structures between access points be supported/contained by such network related connectivity structures. For example, two access points may exist on different logical software type resource objects, situated within the same application type parent container. It may be possible to form a connectivity relationship between children objects via access points of these respective objects, without there being any network layer elements involved in a supporting / containing role. For example, certain types of application programming interface (API) may allow direct interaction, such as: shared memory regions, Microsoft Dynamic Data Exchange (DDE), or Object Linking and
Embedding (OLE) etc.
Access Point Specification Support according to the first embodiment of the invention In this embodiment, the definition of which ResourceSpecification vertex type objects can act as Access Points is not specified on those ResourceSpecification vertex types themselves, but is instead configured within the definition of any
ResourceSpecification edge type objects that are required to form Access Point based connectivity relationships with them.
An example firstly of how a vertex type ResourceSpecification connection point can be defined in a component product item structure for potential treatment as an Access Point is shown in Figure 13. This example defines a vertex type
ResourceSpecification 1310 within component product item ProductSoecification 1320 named 'SQL Server 2008 Net Connection Point'. This item is a directly contained product sub-component item of a SQL Server 2008 Instance 11 10. Whilst the intended purpose of this connection point specification definition is to allow connectivity access to internal sub-objects contained within the SQL Server 2008 Instance, there is nothing specific in the configuration of this product component item itself that defines it as an Access Point - as indicated this is done within other product component item specifications. In embodiments of the present invention, specification of Access Point connectivity relationships are defined in the context of Edge type resource
specifications providing connection functionality associated with the relevant Vertex type resource specification objects. It can be considered that a vertex type object has potential to provide access point functionality but this potential is not realised until a connection is configured that associates the vertex and an internal node which is the ultimate end point of the connection.
An example of an internal sub-object type of SQL Server Instance 11 10 is a SQL Server Database specification object 1350, as seen in the SQL Server 2008 Database product component specification structure shown in Figure 13A. It is clear from Figures 13 and 13A that both the SQL Server Net Connection Point 1310 and SQL Server Database 1350 object specification types are contained by the same SQL Server Instance 1 110 object specification type. A vertex type SQL Server Net
Connection Point object specification type 1310 can potentially therefore be configured for Access Point use into nodes of SQL Server Database specification type 1350 situated within parent nodes of the same SQL Server Instance of specification type 11 10.
Figure 14 shows definition of an Edge type ResourceSpecification object that is configured to form Access Point based connectivity relationships. Edge type
ResourceSpecification 1410 is defined within the component product item named 'SQL Server 2008 Database Replication' 1420. Instances of this component type allow connectivity links to be formed between SQL Server 2008 Database 1430 items via SQL Server 2008 Net Connection Point 1310 objects, configured in this component product item specification structure to act as Access Points. Each of the ACCESSPT type interaction specification objects 1440 and 1450 is associated to both the SQL Server 2008 Database 1430 (node) specification object, and the SQL Server 2008 Net Connection Point 1310 (vertex) specification object. This results in two ACCESSPT interaction inventory objects being created at each connection end of any particular SQL Server 2008 Database edge inventory object. Each end of any SQL Server 2008 Database edge inventory object will therefore have one ACCESSPT type interaction object associated to a SQL Server 2008 Database 1430 node inventorv obiect, and the other to a SQL Server 2008 Net Connection Point 1310 vertex inventory object.
Each of these ACCESSPT type interaction inventory object pairs will be set to the Context type of the relevant specifying interaction specification, resulting in one pair of interaction inventory objects having a Context of 'SourceDB', and the other having a Context of TargetDB'.
Access Point Definition Rules
Access Point type specifications are by definition implemented within component product item specifications using a structural pattern based on
ContainConnectlnteractionSpec objects configured with a
ContainmentOrConnectivityType attribute value of 'ACCESSPT'.
The following rules apply to the configuration of Access Point type structures:
1) ContainmentOrConnectivitySpec objects configured with an interaction type of 'ACCESSPT' must be defined in direct conjunction with an Edge type ResourceSpecification object definition;
2) ContainConnectlnteractionSpec objects configured with an
ContainmentOrConnectivityType attribute value of 'ACCESSPT' must: a. Reference a single Node type ResourceSpecification object
belonging to the root resource specification of another product component item. This Node type ResourceSpecification represents an 'internal' resource object type being ultimately connected to; and b. Reference a single Vertex type ResourceSpecification object that belongs within another component product item that is situated within the parental hierarchy of containing product component items of the Node type ResourceSpecification object referenced in (a). This Vertex type Resource Spec represents an Access Point for the internally situated object defined in (a).
In order to configure an access point connectivity specification an Edge type ResourceSpecification must be created and have two connectivity relationship specifications defined: a first to the access point (vertex) type which is contained by the parent system component (node) type; and a second to the internal system component (node) type, inventory instances of which are the ultimate end points of access point based connections and which are contained by the same parent (node) components as the (vertex) access points. Access Point connectivity relationships between edges and internal nodes cannot exist without the associated edge and vertex relationships. This edge and internal node relationship imposes additional structural and lifecycle constraints on the edge vertex relationship. Presenting; the ultimate end point node of an access point based connection in relation to the edge object and associated access points can assist recognition and interpretation of the entire relationship chain by users.
Thus a ContainConnectlnteractionSpec object configured with a
ContainmentOrConnectivityType attribute value of 'ACCESSPT is defined for an Edge with reference to both a Vertex and a Node which is the endpoint of the connection. As can be seen from the example of Figure 14 this also enables visibility of both the access point (vertex) system component and internal system component (node) being connected to in the specification model.
'SQL Server' is a proprietary product and trademark of Microsoft Corporation.
Database Replication structures are generally intended to allow synchronisation of database contents between related copies of the same database representation. The example in Figure 14 defines an edge (link) type construct connecting via SQL Server 2008 Net Connection Points through to SQL Server 2008 Database type objects having a Context at one end of 'SourceDB' and TargetDB' at the other. The configuration of the two ContainConnectlnteractionSpec ACCESSPT type objects with 'V based values for Multiplicity define this edge spec as being a "point-to-point" type edge/link definition. Each of the ContainConnectlnteractionSpec objects depicted references the same Vertex type ResourceSpecification Access Point definition. This means that when any "SQL Server Database Replication" inventory object instance is created, each end of the edge object must connect to a SQL Server Net Connection Point type vertex inventory object. These connections may be to the same SQL Server Net Connection Point inventory object instance, or to different SQL Server Net Connection Point inventory object instances. The specification of whether different Access Point inventory object instances must be present at each end of Edge/link instances or not can be managed by another specification type attribute indicating whether this type of connection is allowed. If more flexibility is required regarding the meaningfulness of endpoint object types, the Context attribute can instead be implemented a sub type of ResourceRole, as for example per the SID model which supports configurable ResourceRole type definitions. The choice of approach does not affect the underlying principles of this design.
Another example of a database replication is shown in Figure 15 which defines edge type ResourceSpecification 1510 within component product item 'SQL Server 2008 / Oracle Database Replication' 1520. 'Oracle' is a proprietary product and trademark of Oracle Corporation. This structure defines a hypothetical Database Replication structure that may be used to connect SQL Server 2008 and Oracle Database objects in a Replication relationship (assumina that such a relationship was possible with these products). The appropriate Vertex type ResourceSpecification objects 1310 & 1590 have been established to support this type of connectivity relationship in terms of the required ContainConnectlnteractionSpec 1570 & 1580 and Node type ResourceSpecification 1430 & 1560 objects. It should be noted that this example also illustrates the potential to use a 'many' type Multiplicity on one of the ContainConnectlnteractionSpec 1580 objects. This example implements a "point to multi-point" style edge/link spec, in this case allowing a single SQL Server Database to be connected to one or more Oracle Database objects.
The principle being illustrated in this diagram is that of how specification is possible of different configurations for specific Access Point type and the internal Resource Node types referenced at various ends of a Resource Edge object connecting via Access Points. It is possible to implement any scenario from tightly defined point to point style definitions, where each end must be of the same or a specific type, through to 'full matrix' style definitions, where any number of any type of access point or endpoint is allowed.
Access Point definitions are not simply endpoints defined as being able to support connections somehow with respect to specific internally situated object types. Access Point capability supports the structured establishment of related endpoint, internally situated object and edge/link layer specification definitions, enabling fully traceable connection path/graph support across all related objects within any specific Access Point connectivity scenario. The model elements and structure associated with Access Point based connections provide an unambiguous engineering perspective of all objects involved, and their roles with respect to each other. User Interface and data model interactions
Embodiments of the present invention provide a graphical user interface which is configured to represent system architecture utilising the viewpoint features described above. Further, the GUI enables creation and modification of objects visibly within any particular viewpoint, with reference to product specifications from one or more catalogs, automatically making corresponding changes to the entire object model including objects not displayed in the currently visible viewpoint or layer.
Figures 16 to 23 show examples of various visual aspects in the user interface relevant to: Visual presentment of resource objects across multiple layers & viewpoints; Layout mode (within current viewpoint selection); Folding mode operation; and Layer navigation. Figures 17 to 23 are intended to be regarded as what would be seen in the ManagementDomain Display Region of a functioning Resource Inventory Management application. This management domain disolav reaion 1600 is shown in Figure 16 which shows an example of a screen shot of an embodiment of the graphical user interface. The images used to represent resource elements are defined in the specification model using display style specifications.
Within the Physical Layer, resource elements are modeled in the Physical Resource Catalog using realistic image based representations, as shown in Figure 17. Figure 17 shows an object model of a physical drive enclosure 1700 system
component in accordance with the first embodiment of the present invention. Also shown in Figure 17 is an example of a corresponding GUI representation of this model from a physical layer front elevation viewpoint showing a representation of physical drive enclosure 1700, physical drives 1710 and vacant drive slots 1720.
Figure 18 shows a representation from a storage group viewpoint where logical resources defined in the storage layer are shown as well as some containing resource elements from the physical layer which support the implementation of the logical storage layer resources. The storage layer shows the logical resource objects being managed which are storage groups 1810, which includes nested logical resource objects storage group set A 1820 and storage group set B 1830, and their respective nested Logical Unit Number (LUN) objects 1825, 1832, 1834. It should be appreciated that the nesting of the storage group sets and LUN objects represents containment relationships for these logical resources. Figure 18 also shows representations of the physical drive enclosure 1700 and physical drives 1710. These Physical Resource items are appearing in this view in conjunction with Logical Resource type items due to definition of LogicalResourceLocalLocationSpec objects relevant for the Layer Type concerned (in this case, the Storage Layer). The physical enclosures 1700 and physical drives 1710 are 'containing' objects for the LUN logical resource objects 1825, 1832, 1834, with the containment relationships indicated by lines 1840. Some of the objects displayed may be displayed in viewpoints relevant for both the Storage and Volume layers (for example 'Storage Group' and 'LUN' objects, and not the 'Storage Groups' parent object). It should be noted that in the example of this viewpoint it is the storage layer being managed in terms of object lifecycle (create, remove, change etc). Users may be prevented from modifying the physical layer objects represented - these objects exist in this viewpoint example to allow visualisation and management of containment referencing by Storage layer objects.
Containment relationships for Storage Group Set A and B 1820 & 1830 may exist with respect to other objects not included in this viewpoint - for example
Operating System type objects. Depending on implementation specifics, the physical enclosures 1700 and storage groups 1810 objects as depicted may potentially not form part of the resource inventory structure, but instead be transient Ul framework obiects used as visual containers for similar classes of resource object type.
An example of a viewpoint of a logical volume manager is shown in Figure 19. In this viewpoint logical volume groups 1910 are managed. However, containing resource elements from the physical and storage layers can also be shown. Elements in the left hand side include physical drives 1710, drive partitions 1970 and logical unit numbers (LUNs) 1832, 1834. LUN resource elements 1832, 1834 are visible in both the storage layer and volume layer. SAS Disk resource elements 1710 are physical layer elements. Partition element 1970 is a storage layer element, but may be managed using a different viewpoint to the LUN storage group viewpoint shown in Figure 18. These objects are managed in the Physical and Storage layers, but appear as containing objects in the Volume layer. In this context, these are all grouped visually as 'Physical Volumes'. In the context of business rules that may be applied as example against the object types depicted in this particular representation, any left hand side element can be assigned to a single Logical Volume Group 1920, 1930, 1940 on the right hand side. Logical Volumes 1922, 1924, 1932, 1934, 1942 may be created within Logical Volume Groups 1920, 1930, 1940. It is not a rule that objects on the land hand side group must be containing objects, and objects on the right hand side group must be contained/managed objects, or that only two groups be present within any viewpoint visualisation. Relative user interface positioning of containing and managed items may be configured as is appropriate for the object types concerned. This may result in 'network' style visual structures as seen in Figures 22 and 23.
In the context of the object types depicted, the Capacity assigned to each Logical Volume is allocated from the total capacity available in the Logical Volume Group parent object (this is in turn an aggregation of the total capacity of all physical volumes assigned from the left hand side). This behaviour can be driven by business logic that is defined to operate both with relevance at the common model element level, and also with respect to any item specific rules relevant to the resource types concerned.
An example of different viewpoints and layers applying to the same host system is shown in Figures 20 and 21. Figure 20 shows a representation of the host system melmxl from an Operating System to Volume viewpoint, including primary operating system 2010 component elements 2020, 2030, 2040, 2050 and allows management of these. Shown on the left hand side are Volume resource elements 2060, 2062, 2064, 2066, 2068. In this viewpoint it is possible to assign operating system components 2020, 2030, 2040, 2050, to storage elements 2064, 2066, 2068. Figure 21 shows a representation of the Network layer from a Connection Point viewpoint. This viewpoint shows connection points 211 1 supported by the host svstem melmxl 21 10 and available for connection in the Network layer. Elements visible in the Operating System viewpoint for host melmxl , shown in Figure 20, are not visible in this viewpoint. The ability to filter objects represented within viewpoints serves to focus the representation on the information relevant to the specific functional aspect of the system being managed. This in turn makes it easier for a user to interpret the represented information and perform the required management functions.
An example of folding is shown in Figures 22 and 23. Figure 22 shows a number of elements present at the network layer. The high-level elements shown support Folding, this is recognisable by the '+' 2210 and '-' 2220 symbols at the top left of their icon representations. Two items have been expanded (unfolded): melvml 2230, as represented in the Host layer in Figure 21 , and meldistl 2240, a gigabit Ethernet switch equipment item. The unfolded state of the melvml and meldistl items allows inspection & connection management access to the connection port items contained within them. Note that this Layer Type only shows ConnectionPoint and VLAN type objects, as these are the only items configured for management in this
Network Layer, Connection Point viewpoint representation. Other Network Layer view point configurations may be established to present additional or different network object types, such as VRF, MPLS, SONET, GPON, MEF objects etc.
In certain cases, it may be relevant to display the same resource object more than once in the same visualisation. An example is shown in the case of physical port GeO 2240, which is a member of both VLAN1 2260 and VLAN2 2270. Another viewpoint may be defined within the same layer that shows each physical port only once, but contains more than one representation of the same VLAN item where an association exists to more than one physical port.
Figure 23 shows elements 2230 & 2240 of Figure 22 in their collapsed state.
This Freeform Network layout mode can be used within any relevant layer type - for example in a SQL Server Replication Network view (a form of Application Network Layer Type), only SQL Server Access Point and Database items would be visible (Database items are relevant because these are the 'internal items' that the Access Point provides connectivity access to in the context of SQL Server Replication). Figure
23 also shows element mel1 2270 in an expanded state. It can be seen that although this object representation exists within the same viewpoint/layer based display as elements 2230 & 2240, the Freeform Network layout mode is use within this object. This can be seen in the way objects are placed freely within 2270, with connectivity links in place as is appropriate. By comparison, in Figure 22 the elements 2230 & 2240 are shown in Hierarchical layout mode.
Figure 24 shows a simple example of model elements beside a representation of those same elements as seen from the user interface. Elements represented in the Ul representation 2400 correspond to resource objects in the model 2405. An item such as the 'MEL_SQL_SRV_1 ' SQL Server 2008 Resource object 2410, 2420 would typically contain multiple levels of child items that would quickly overwhelm the level of detail appropriate for the viewpoint shown. These child objects are connected to the 'MEL_SQL_SRV_1 ' SQL Server 2008 Resource object 2410 in the model, but are only assigned via ResourceLocal Location objects to the 'SQL Server' Layer in order to omit them from appearing in the Ul presentation of the viewpoint shown in Figure 24, which is not specific only to SQL Server. Double clicking the 'MEL_SQL_SRV_1 ' SQL Server 2008 Resource object 2420 in Figure 24 will cause the system to present the detailed Ul viewpoint for the 'SQL Server' Layer for that object as seen in Figure 25, showing the associated child objects 2510 that are assigned to the 'SQL Server' Layer. The representation of the model for these child objects shows the relevant supporting Resource objects 2520 in the Operating System and Volume layers. The Host Layer objects shown to the right of the dashed vertical line do not belong to the 'SQL Server' Layer (as per their associated ResourceLocalLocation to Layer associations), and therefore do not appear visually among the Ul elements shown - hence these objects are shown having a white background. Even though they are not visible in the SQL Server Layer, these objects are represented here to indicate that they are present in the background model.
User interface mechanism for drag and drop of connectivity structures across domain boundaries
An example of how an action via the Ul will cause a corresponding change in the object model will now be described with reference to Figures 26 and 27. Figure 26 shows a pre-state prior to creation of a new Physical Link between Physical Port objects situated on different Management Domains accessed on separate Ul views. Management Domain A Ul view 2610 shows a physical layer representation 2630 of a chassis and its associated physical ports. The associated object model 2635 for management domain A is shown below. Management domain B Ul view 2620 shows a physical layer representation 2640 of another chassis and its associated physical ports. The associated object model 2645 for management domain B is shown.
Figure 27 shows a post-state following creation of a new Physical Link 2750 between Physical Port objects 2634, 2644 situated on different Management Domains 2632, 2642.
In an embodiment the physical link can be created via a single continuous drag and drop gesture of the Ul. It should be appreciated that both domains 2610, 2620 mav not be able to be presented side by side by the Ul, for example due to screen size, so the Ul may provide thumbnails 2610', 2620' to facilitate navigation between domain representations. In the single drag and drop gesture, the user initiates the drag and drop gesture by the user clicking on and dragging a connectivity link from a candidate connection point 2730 on a source object 2630. This also initiates the creation of an interaction specification object 2735 and physical link object 2750 in the model 2635'. The user can extend the drag operation beyond the boundary of the domain that the source object is located within and select (and enter) a target domain from an adjacent list of potential target domains. For example, dragging from the management domain A Ul view 2610 to the thumbnail 2620' for management domain B Ul view 2620 will cause the Ul to switch to the management domain B Ul view 2620 where the drag and drop operation can be completed by attachment of the connectivity link to a candidate connection point 2740 on the intended target object 2640. (Thumbnail images are provided as an example means to select between alternative management domains. Alternatives to this approach could include presentation of simple tabs, or icons, etc.). In the U I the cross boundary connection is represented by links 2732, 2742 to off page connectors 2731 , 2741. The completion of the drag and drop operation over the target connection point 2740 also causes an interaction specification object 2745 to be created in the model 2645' to complete the definition of the physical link 2750 connection. Thus it can be seen that a simple gesture in the Ul can cause the appropriate objects to be created in the model.
Similarly to the drag and drop operation for creating connectivity objects in a model, an existing connectivity endpoint can be modified by detachment of the existing connectivity attachment endpoint, extension of the connectivity drag operation into another target domain and completion of the drag and drop operation as per above steps. In this operation the interaction specification object for the connection endpoint being modified is modified in accordance with the newly selected end point, or the interaction object deleted and a new interaction object created for the newly selected endpoint. Detachment of an existing connectivity attachment endpoint, followed by extension of the connectivity drag operation over a Trash Can results in deletion of the connection and associated deletion of interaction specifications at each end of the connection as well as the connectivity object (for example the physical link edge object) itself.
If it is possible to accommodate both management domains simultaneously on the screen, the same connectivity creation operation can be achieved via a direct drag and drop motion from one domain directly to the other, with no need for an
intermediate drag motion over any representative thumbnail, tab or icon imaaes. The resulting on-screen representation and model post-state would be identical to that as described above.
User interface for management of structurally related component items across multiple Viewpoints
Embodiments of the present invention enable a change to be made in one viewpoint and the effect of the change also made visible in another viewpoint. Figure
28 shows a pre-state Ul representation from the logical volume manager viewpoint, showing all object types relevant to the viewpoint. Only the logical volume objects 2800 are managed in terms of their own lifecycle in the viewpoint of Figure 28. Figure
29 is an alternative representation of the pre-state of Figure 28 showing all model objects relevant to the logical volume manager viewpoint but only the Ul representation of the logical volume objects 2800 for simplicity of the diagram. Figure 29 shows three logical volume groups 2910, 2920, 2930. Logical volume groups 1 2910 and logical volume group 2 2920 are both contained in security zone Tenant A 2940, with the containment relationship defined in interaction objects 2942, 2944. Logical volume group 3 2930 is contained in security zone Tenant B 2950, with the containment relationship defined in interaction object 2952. This security zone assignment of logical volume groups is shown in the data model 2900 although not represented by the Ul 2800 in this viewpoint. Figure 30 shows a pre-state Ul representation 3000 of the
Volume layer in the Security Zone Manager viewpoint, showing logical volume objects as represented by the Ul and the associated model objects 3010. Figure 30 clearly shows the assignment of Logical Volume Groups 1 and 2 2910, 2920 to security zone Tenant A 2940 and Logical Volume Group 3 2930 to security zone Tenant B 2950. It should be appreciated that Figures 28-30 show different views of the defined model architecture in the same state, before the modification to be discussed is made.
While in the Security Zone Manager viewpoint, as seen in Figure 30, logical volume groups can be assigned to security zones using direct drag and drop gestures. The assignment of Logical Volume Group to Security Zones is not seen visually in the Logical Volume Manager viewpoint Ul seen in Figure 29. Note however that it may still be possible to relocate Logical Volume Groups between Security Zones whilst in the Logical Volume Manager Viewpoint Ul using either context menus or other controls available in Ul management panels, perhaps visible elsewhere within the same screen.
Figure 31 shows the effect of reassigning logical volume group 2 2920 to security zone Tenant B 2050. The interaction specification 2944 defining the containment relationship between logical volume group 2 object 2920 and security zone Tenant A object 2940 is removed. A new interaction specification 2954 has been created to define a containment relationship between logical volume group 2 object 2920 and security zone Tenant B object 2950. The effect of this change, made in either security zone viewpoint or the logical volume manager viewpoint of Figure 31 becomes visible in the security zone manager viewpoint of Figure 32. Thus, by virtue of the data model being updated by a change made in one viewpoint, the representation of the same model objects in another viewpoint(s) will also reflect this change.
Physical Layer Containment Management
Preceding sections in this document have been oriented more towards logical and network related resource structures. Whilst objects from the physical layer may be included within logical representations of resource inventory structures (for example physical disks 1710 within Figures 18 and 19), it is also desirable to depict and manage physical items using representations of their actual physical appearance. A specific 'Physical' viewpoint is supported in this invention that fulfils this purpose. It can support coordinated Front, Rear, Top, Bottom, Left Hand Side, Right Hand Side and Plan elevations of equipment items in their configured state. In order to simplify description of the invention, only Front, Rear and Plan elevations are described in detail.
The top section of Figure 17 depicts an example of how a complex configured physical drive enclosure 1700 device appears in the user interface when the User has selected 'Front' elevation for a currently displayed Physical Viewpoint, including contained physical drives 1710 and vacant drive slots 1720. Shown also are the model object items that define the physical items seen. In the context of this example, drive slots are special cases of what are generally called 'adapter slots' in this invention.
Whilst the user interface is showing either of the Front or Rear elevations of the
Physical Viewpoint, if there are adapter slots available on the front or rear of the equipment item, these will be visible either as part of the background representation of the equipment image, and/or as highlighted selection border regions that appear when the region associated with the adapter slot is clicked or when another equipment item is dragged over or into that adapter slot.
The system will only allow a device to be inserted into an Adaptor Slot if the device supports the containment, role type any other more specialised definitions contained in the product component item structure definition of the adapter slot concerned.
If an adapter slot contains a piece of equipment, that equipment item will be visible in the slot's region rather than the appearance of the empty slot or slot cover. If the child equipment item has adapter slots of its own, these will in turn be then visible. and subsequently may have equipment items placed into them. This slot/placement pattern may be nested to any level of depth limited by the engineering architecture of the equipment items concerned, as implemented by the relevant product component item structural definitions.
The visual presentation of equipment items and slots may be visually realistic, even to a photographic level of detail, or may be accomplished using less detailed diagrammatic or simple shaded regions to depict the presence of the equipment and slot items concerned. Geometric positioning information for both chassis and adapter slot containing items is defined by ResourceLocalLocation specification objects, associated to a LayerSpec relevant for the Physical layer and to Viewpoints representing the Front and Rear elevation modes within the relevant product component item structures.
The only items that should normally be visible on the front or rear external views are those that are visible on the front or rear of the real object concerned. The shape of the equipment and slot objects and the positioning of Slot objects on related
Equipment objects should typically mimic at least roughly the size and placement of the real counterpart objects represented.
If physical port elements are configured, these also will be present as active elements in the display interface when selected into any elevation, meaning that connection links can be dragged from or to compatible ports, based on satisfaction of structural component product item definition structures and any other more specialised rules.
Plan elevation
Plan elevations are diagrammatic layouts depicting adapter slot and connector port elements using the same user interface representation capability as for logical application or network objects, meaning that any combination of the Hierarchical, Icon or FreeformNetwork Layout Modes may be supported. A key feature of Plan elevation is the ability to support adapter slot and connector port elements that are not externally visible on the device concerned. This aspect is described in more detail in the following section titled 'Interior slots and devices supporting external slot availability'.
The appearance of most objects in Plan elevation representations does not need to bear any resemblance to the actual physical geometry of the equipment or slot items concerned. They generally will not, given that Plan elevations can contain adapter slots and ports that are present also in all external elevations, and also any internally situated adapter slots and ports. It is possible therefore to add a child device to a parent device via either one of the external facina elevations, or within Plan elevation.
An example of a Plan elevation is shown in Figure 35. This shows a resource inventory view of adapter slots of types including DIMM Module Pair slots 3510, Riser Bay Slots 3520, Drive Bay Slots 3530 and Power Supply Slots 3560. In this example, DIMM Module Pair slots 1 and 2 are shown as being populated with DIMM memory devices 3512, CPU Slot 1 is shown as being populated with a CPU device 3542 and Power Supply Slot 1 is shown as being populated with a power supply device 3562.
Inclusion of the definition of a resource object specification into a Plan elevation type Viewpoint, including geometric size, appearance and positioning information is defined using the product component item specification model, in particular using
ResourceLocalLocationSpec objects associated to LayerSpec objects relevant for the Physical layer and to a Viewpoint object representing the Plan elevation mode. Only Plan elevations provide visibility and management of adapter slots and ports located in the interior of the equipment item concerned, which are not visible in external elevations. An example of such interior situated adapter slots are CPU slots 3540. These are termed as being 'interior adapter slots'.
Interior slots and devices supporting external slot availability
A special case exists with respect to interior adapter slots that may act as containers of child contained component devices having one or more contained child adapter slots that may in turn contain sub components that are visible in some way in an external elevation. These are termed 'interior slots supporting external slot availability'.
An example of a type of child contained component device having one or more contained child adapter slots that may in turn contain externally visible sub
components are Riser Cards. Riser Cards are system cards that plug into an internal slot on a Server chassis, and in turn make specific types of children adapter slots available, such as PCI or PCI Express slots, that can contain other devices that have a visible appearance externally, such as PCI or PCI Express cards. Even if such children adapter slots are not populated, they can usually be seen as being present on one of the external elevations for the parent system chassis concerned. Figure 36 shows the presence of the externally visible areas of a server chassis 3610 that may potentially be associated with child adapter slots provided by Riser Cards. Note that any child adapter slots are themselves located within the external geometry of the chassis. Externally visible areas 3620 are associated with children slots provided (contained) by any Riser Card that is contained (plugged into) by Riser Card Slot 1 , and externally visible areas 3630 are associated with any Riser Card that is contained (oluaaed into) by Riser Card Slot 2. Without Riser Cards present, these Riser Card child slots do not therefore exist, and the associated externally visible areas should be displayed as blank slots (i.e. with slot covers in place), and are not accessible for configuration purposes.
Only Plan elevation supports addition of an interior device supporting external slot availability. An example of such an installed Riser Card 3522 is shown Plan elevation Figure 35. Three child PCI Express adapter slots 3524 of Riser Card 3522 can be seen also. With this Riser Card in place, it is possible to add compatible PCI Express type adapters to the child PCI Express adapter slots 3524 as contained (plugged in) items. Addition of compatible PCI Express type adapters to the child PCI Express adapter slots 3524 is possible either in Plan elevation, or in Rear elevation of the server chassis (in the context of the provided example). The User may accomplish this either by dragging and dropping an appropriate PCI Express adapter from an associated catalog list, or by making an appropriate menu selection, etc.
Figure 36 provides an example resource inventory object hierarchy of all items from the Server Chassis, through the Riser Card Slot 1 down through to the adapter slot and ports supported on an example PCI Express Multipurpose Adapter Card. This is shown in the lower half of this diagram in resource inventory model form. The upper half of the diagram shows an illustration of the corresponding objects as seen in the Rear elevation of Physical Layer viewpoint.
In this example a 'Multipurpose Adapter Card' PCI Express adapter 3640 has been added to PCI Express adapter slot 3650 situated on the Riser Card located in Riser Card Slot 1. The external view of the PCI Express adapter, as seen in this example on the rear of the server chassis, presents SD Card adapter slot 3642 and Ethernet connections ports 3644.
Note that item 3650 represents the internally situated PCI Express 4x Slot 1 adapter slot on the Riser Card mounted in Riser Card Slot 1. This is not exactly the same thing as the externally visible area associated with it (the topmost of the three 3630 items). The hierarchy of all items in this example from the Riser Card slot down through to the adapter slot and ports supported on the Multipurpose Adapter Card must obey the engineering architecture of the equipment items concerned, as reflected by the relevant product component item structural definitions.
Specification support for external slot availability
Model specification aspects required to support operation of both interior slot items supporting external slot availability and interior devices supporting external slot availability within the user interface are integrated into the product component item structure presented in this invention. Riser Card Slots and Riser Cards are used as example types mostly throughout this embodiment description rather than the terms 'interior slot items supporting external slot availability' and 'interior devices supporting external slot availability', as an aid to simplify readability. Items of both these types have a geometric relationship that must be managed in conjunction with each other in order to achieve expected relative positioning of all related elements.
During definition of interior slot items supporting external slot availability, such as Riser Card Slots, it is necessary to configure a value of true in an attribute named interiorSlotltemSupportingExternalSlotAvailability. This is located on the
ResourceLocalLocationSpec class associating the ResourceSpecification object representing the Riser Card Slot (in this example) to a Physical LayerSpec object. It is also necessary on the same ResourceLocalLocationSpec object to specify an external geometry reference point relevant to the elevation geometry of the chassis object that will contain the Riser Card Slot being defined (in this example a server chassis).
A visual example of this is shown in Figure 37, the top half of which represents the front or rear elevation viewpoint of the user interface view seen during product component item definition for a Riser Card Slot type item. This shows firstly how such a geometric reference point 3710 may be located in support of the definition of Riser Card Slot 2. This results in numeric offset values in the X 3730 and Y 3740 planes being established, relative to the top left corner 3720 of the relevant parent chassis geometric representation (which is treated as a position co-ordinate point at X=0, Y=0). Note that 3710 is not necessarily an object in the model in its own right. Values 3730 and 3740 could be stored in the parentXOffset and parentYOffset attributes of the ResourceLocalLocationSpec 3760 object associated with the ResourceSpecification 3750 defining Riser Card Slot 2.
Figure 38 shows an example product component item definition for a Riser Card. It is necessary to configure a value of true in an attribute named
interiorDeviceSupportingExternalSlotAvailability located on the
ResourceLocalLocationSpec 3862 object associating the ResourceSpecification 3860 object representing the Riser Card to the Physical LayerSpec 3864 object. Note that the top section of Figure 38 depicts the physical layer front/rear elevation viewpoint of the user interface view seen during product component item definition for a Riser Card type item. Note that the joint reference of both front and rear perspectives refers to the ability of an inventory instance of such a sub-component specification to be placed into either a forward or rearward facing interface slot, potentially within multiple, different parent chassis product types. For each child adapter slot 3810, 3820 & 3830 defined on such a RiserCard, it is necessary to configure a aeometric position offset, width and length on the relevant ResourceLocalLocationSpec objects 3812, 3822 & 3832 for use in either Front or Rear elevations. During resource inventory run time operations, when a Riser Card is added to a Riser Card Slot, this offset is utilised by starting from the current geometric location of the top left of the visual item representing the containing chassis, then computing an offset position using the parentXOffset and parentYOffset offset values defined on the containing Riser Card Slot definition. This position is then used as a reference against which the relative parentXOffset and parentYOffset defined for the child adapter slot itself is applied. This final computed offset position, and associated width and length attributes for the child slot defintion, may then be used to form the geometric co-ordinates and shape definition for use in presenting a slot cover display object, if one is required. If a child object such as a PCI Express adapter is positioned into such a slot, the same positioning and shape definition information can also be used to achieve visual presentation of the child object.
Geometric position offsets on child adapter slots of Riser Cards are able to be utilised regardless of whichever Riser Card Slot any particular Riser Card is inserted into, provided the same external slot positioning pattern is followed across all compatible Riser Card Slots, for any particular Chassis type concerned. If this is not the case, it is possible within the framework of this invention to support more complex specification structures than are described here to support multiple definitions of slot positioning pattern templates for Chassis objects supporting the same Riser Card types but with differing external slot placement.
In order to allow definition of correct geometric position offsets on relevant ResourceLocalLocationSpec objects such as 3812, 3822 & 3832, some important visual guides are provided to assist the user achieve this within the user interface supporting definition of product component items. Geometric reference point 3840 represents a single point of reference from which the geometric position offsets on relevant ResourceLocalLocationSpec objects such as 3812, 3822 & 3832 are established during specification item development within the user interface for the Riser Card described. Values for reference point 3840 are stored as parentXOffset and parentYOffset attributes on the 3862 ResourceLocalLocationSpec object (which is linked to the primary RiserCard resource specification object).
As any child adapter slot belonging to the Riser Card is moved within the user interface relative to the geometric reference point 3840, or vice versa, the parentXOffset and parentYOffset attributes in the relevant ResourceLocalLocationSpec object 3812, 3822 or 3832 are recomputed to reflect the X and Y axis distances from the top left of the child slot object to geometric reference point 3840.
Not shown in Figure 38 is a background rendition of a relevant selected server chassis, which if present allows placement of geometric reference point 3840 belonging to a relevant Riser Card Slot product component item definition by the user in the same location as a selected geometric reference point 3710 (displayed in conjunction with the selected server chassis). With these points in alignment, placement and alignment of geometric reference points belonging to Riser Card Slots against the representation of the location of the same relevant slots in the background server chassis image rendition can be made precisely using a drag style action by the user. This process ensures geometric consistency between instances of these items as defined originally as product component specifications, and when used in conjunction with each other later in the resource inventory run time view.
Logical Partitioning
A key factor associated with the emergence of next generation services such as Software As A Service, Platform As A Service, Virtualisation, Cloud and Mashup based services, is the need to achieve 'partitioning', i.e. isolation, between services provided to and between different customers using the same infrastructure. Additionally, within any given customer's infrastructure, further sub-partitioning will usually be required to support differentiated operational processes, service delivery commitments, geographic/location based zones, marketing territories, security zones, security classifications, statutory requirements, or a range of other needs. The system architectural elements owned by any given customer may be of various technology evolution levels, including legacy, contemporary and next generation, including cloud based.
High level partitioning structures will usually overlay system architecture infrastructure of various evolution levels and across all layer types in unique ways for every organisation, requiring great flexibility in system management tools as used by both service providers and customers. Due to limitations described with existing modelling approaches, coverage of all these factors is challenging to address using contemporary OSS products, even for those products attempting to provide inherent support for multiple technology types or when attempts are made to integrate across multiple OSS environments using standardised OSS interfaces.
It is a capability of embodiments of the present invention to support such complex structural interactions by providing a logical partition class.
Given that all resource objects managed according to embodiments of the present invention share a common underlying information model, assignment of resource objects of any type into logical partition groups is made very simple, particularly given that processing operations required at the abstract information model level are identical regardless of the domain model or technology type(s) for all containment or connectivity type relationships across all relevant technology domain types. Note that within other SDO model domains, other names may be used for class types designed to group resource inventory objects together, such as the
ManagementDomain in the SID model. The name 'LogicalPartition' has been chosen within this design deliberately to avoid confusion with such existing type names, due to their inability to group all resource objects, including containment & connectivity associations across and between all layer types, at a single abstract level of reference. Logical Partitions will not be recognised in downstream Element or Network Monitoring (EMS/ NMS) Systems. ManagementDomains or their equivalents may however be created and provided across interfaces to these systems, on a derived or projected basis from Logical Partition structures.
Figure 33 shows a view of class types from the common model element embodiment relevant to logical partitioning. These are the same common model element classes, but seen from another modelling perspective. An additional
LogicalPartition class type is shown. Also shown is the RootEntity class type, which is relevant generally beyond logical partitioning but needed in this particular modelling view. Given that class types ContainConnectlnteraction 3310, Resource 3320 and ResourceLocalLocation 3330 are the objects used to define individual resource inventory item instances and their specific containment & connectivity relationship assignments, these are the primary objects that logical partition structures must support grouping of. Each of these types is specialised from the RootEntity super class 3340, which has an association 3350 defined with the LogicalPartition class 3360. Any relevant instances of resource inventory types 3310, 3320 & 3330 may therefore be associated with one or more LogicalPartition objects as desired to describe partitioning requirements. Inventory objects of type 3310, 3320 & 3330 do not need to be associated to each other in order to be associated to the same Logical Partition. A LogicalPartitionSpec class could likewise be defined in the Resource Specification model, to support pre-defined Logical Partition specifications supporting a set of resource specifications as part of a 'pre-built kit' type component product item specification structure. Note that 'RootEntity' is provided here as an example of a high level superclass encompassing many sub class types. Real implementations would more likely use a more focussed super class defined somewhere in the Resource domain.
Figure 34 depicts a view of the same resource inventory objects as seen originally in Figure 10. Some of these objects have been assianed into a Loaical Partition 3450. This Logical Partition is seen to include resource objects from across all the layers in this structure 3410, 3420, 3430 & 3440, including inter-layer interaction association objects. Note that the curved connection link line representations present in Figure 10 have been left out of this diagram to aid simplicity - these are assumed to still present in the model and included in the logical partition item structure. The meaningfulness of this logical partition shown in the context of this example structure is to partition all objects related to the two SQL RDBMS database environments, including within and across all supporting layers. Its use(s) may be relevant with respect to service assurance, security zoning, or any other purposes as defined by Users of the partition.
Treatment of Services as Logical Partitions
The 'Services' domain is subject to a large amount of discussion and variance within the industry in regards to both definition and application. In cases where simple or complex resource inventory object structures are to be managed as being 'services', logical partitions may be used to group the specific resources relevant to any single service item definition. In this way, a service is implemented as a logical partition. This avoids the need for management of yet another object type dedicated to services, but which actually needs to group and define resource objects somehow.
The utilisation of a single logical partitioning scheme across the entire resource and 'service' domains, in support of all related management facets provides an enormous degree of control, adaptability, and reliability within what is a significantly complex problem space. It also allows a clearer, and very focussed (whether internal or external), definition of what a 'service' is composed of in terms of resource elements. From a modelling perspective this allows related Service object items to focus specifically on service domain aspects, such as timing requirements, contract structure and customer contact points etc. Given that Service Contracts and/or detailed infrastructure configuration attributes relevant to specific service contracts should be associated against resource inventory objects and service type logical partitions, logical partitions can additionally serve to provide insight as to which service contracts / how many of any given type are or would be impacted by various events or event types as they relate to any specific logical partition(s).
Common Platform Support System
Integration of Operations Support Systems used by service providers, their customers and other types of parties can provide significant service delivery benefits for all. For example: 1) If a supplier partner has access to a relevant segment of a customer's resource inventory repository, they can provide a finely adapted solution proposal based on the same source data, and modelled within the same CPSS environment.
2) If a customer can review within the CPSS environment how component or system delivery & implementation / fulfillment events align against an original planned resource inventory change, this is a strong aid in terms of
management visibility and control.
It is clearly a more effective architectural pattern to support the requirements of both supplier partners, customers and other parties from within the same OSS system environment. Embodiments of the present invention enable the same OSS system environment to be used securely by different parties by virtue of the models employed enabling clear definition of connectivity and containment relationships, viewpoints and logical partitions.
A single OSS environment would enable customers, manufacturers, distributors, systems integrators, service providers, consultants, regulators and other relevant participants to interact with respect to a single view of resource inventory. Within this design, such an environment is termed a 'Common Platform Support System' (CPSS). If it is possible to allow management of resource or service inventory for one or more organisations using the common model element design described in this invention, this is considered to be a CPSS implementation. The word Operations' has not been used in this definition in order to better balance the inherent business meaning across Planning, Sales and Operational activities.
A CPSS environment would enable:
• Customers to manage their own view of IT services and resources as though they were using their own dedicated Operations Support System (OSS),
• Service providers to manage services and resources provided to multiple
customers, using shared infrastructure owned by the service provider or in turn procured from other service providers, within a common OSS management environment,
· Solution consultants to structure solution proposal options for customers
incorporating product options from one or more service providers, directly into planning views of existing resource and service inventory.
• Management or engineering consultants to perform analysis across the
resource and service inventory for a single customer, or multiple customers (for example in the context of a specific service provider).
Secure Multi Party Model In order to satisfy the numerous security challenges associated with a CPSS environment, an application and data access security architecture is required that is capable of satisfying classified data security requirements as may be encountered within any type of organisational context. Conventional Row Level Security or
Tenanted security schemes do not provide the granularity required to provide any relevant party with the necessary granularity of access rights across appropriate specific sub-sets of another party's resource / service inventory. It may be necessary to allow or deny access rights based on organisational structure, satisfaction of specific management policies, membership of hierarchical access control groups or roles, technology type, layer type, logical partition membership, and/or any combination of other relevant factors.
The information model proposed in embodiments of the present invention greatly reduces the number of object types that need to be secured by such access security management architectures. The support for containment and connectivity structures within the common model element described in this design is a key factor in enabling simple assignment of access rights to resource objects within and across such access security schemes.
The application of the common model element embodiment described in support of complex security architecture requirements as discussed here is termed within this design as a 'Secure Multi Party Model' (SMPM). Secure partitioning is enabled in embodiments of the present invention by being able to clearly define containment relationships using interaction specification objects.
An example of how embodiments of the present invention may be applied for a secure multi party model is shown in Figure 41. Figure 41 contains a depiction of resource inventory items that are owned and/or accessible by multiple parties. The resource items are shown structured into Logical Partitions, in a manner that supports the Management or View type role that each party may have with respect to the resources within each Logical Partition.
At the Physical Layer, Logical Partition 'Customer 1 Physical' 4110 contains physical server and network switching equipment resources that are Owned and
Managed by Customerl . Only Customer 1 has any access to these resources. Logical Partition 'Service Provider A Physical' 4120 contains network switching equipment resources that are Owned and Managed by Service Provider A. Additionally, Customer 1 has View access to this Logical Partition. Logical Partition 'Service Provider B Physical' 4130 contains server and network switching equipment resources that are Owned and Managed by Service Provider B. Additionally, Customer 1 has View access to this Logical Partition. Logical Partition 'Service Provider C Physical' 4140 contains server and network switching equipment that is Owned and Managed by Service Provider C. Additionally, Customer 1 and Service Provider B have View access to this Logical Partition.
At the Storage Layer, Logical Partition 'Cust 1 Storage' 4150 contains Storage Volume resources that are Owned and Managed by Customer 1. Only Customer 1 has any access to these resources. Logical Partition 'Service Provider B Storage' 4160 is Owned by Customer 1 , but is Managed by Storage Provider B, who provides it as a service to Customer 1. Storage Provider B therefore has Management access to this Logical Partition, while Customer 1 has View access to the storage volume resources in this Logical Partition. Note that this is from a CPSS/OSS management perspective and not necessarily with respect to the operating access rights assigned to the actual resources themselves. Service Provider B uses infrastructure resources made available in Logical Partition 4140 from Service Provider C to host one of the storage volume resources in Logical Partition 4160 in order to provide all the Storage Volume resources required by Customer 1.
At the Document Management Application Layer, Logical Partition 'Customer 1 Document Management' 4170 contains Document Management Node resources that are situated on storage volumes that are Owned by Customer 1. Only Customer 1 has either Management or View access to the resources contained in this Logical Partition.
Figure 41 illustrates a scenario that reflects how the present invention can support a single multilayered and interconnected inventory repository describing resource elements owned, managed or accessed by various party organisations in order to achieve a given high level functional purpose. This type of inter-organisation view of an interconnected set of related resources may be encountered in various commercial scenarios including Service Provider Hosted Services, Infrastructure As A
Service, Software As A Service, Cloud Computing etc. The same type of structure may additionally include virtualised resources in place of certain or all physical resources.
The notion of Owner, Manager and View type roles are arbitrary for the purpose of this example, and could be re-assigned dynamically as responsibilities of the participating organisations change over time. Logical Partitions do not need to adjoin each other neatly, as shown in Figure 41. Assignment into any Logical Partition may be arbitrary, and can result therefore in overlap between two or more Logical Partitions.
No attempt is made here to define specific class models that may be used to implement the security patterns required, given that these may vary very widely.
Within any security scheme or model implemented, if it is possible to assign security associations against instances of the common model element class types described, this is considered to be an SMPM implementation. The SMPM may also be used in a downgraded mode to support simplified security scenarios, such as 'multi-tenant' operations, where no interaction between 'tenants' is to be allowed.
It should be noted that resource elements managed using embodiments of this invention may themselves be representative of real world resource objects designed to provide resources and/or services according to a Tenanted or some other security partitioning model. This is unrelated to the use of an SMPM implementation for management of access control for such resource inventory objects. Architectural structures for implementation of SMPM support are not specifically described in this document, but technical platform options may include elements such as conventional Relational Database Management, NoSQL / Object Oriented Database Management, Directory Management, and Authorisation / Authentication / Single Sign On
Management. Discussion of Advantages
An advantage of the present invention is that the framework is applicable for definition and management of resources at all traditional networking layers and also across emerging networking, application and computing technologies.
The ability to define interaction relationships between system resources in terms of connectivity associations and containment relationships using a common model element has significant advantages for defining system architecture. In particular, the ability to enable common definition of containment and connectivity relationships provides flexibility in a system management tool to adapt to emerging technologies and new networking, application and computing philosophies.
When considering the management of networking, compute and application resources, significant requirements are relevant that are not supported by pure networking reference standards - in particular the inter-related aspects of Structural Composition and Lifecycle. This document groups both of these two areas together for ease of reference into the term 'Containment', which can be taken to collectively mean both Structural Composition and Lifecycle. 'Structural composition' in the context of network, compute and application domains means having an understanding of which objects 'support the existence' of which other objects, therefore implying a lifecycle impact. Whilst it can be said that 'structural composition' is an inherent facet of network structures (i.e. one network layer cannot exist unless it is transported across another lower level network layer), structural composition as it applies to compute and application objects often occurs in situations where no network transmission elements exist between the objects concerned. For example, an Operating; Svstem mav be installed on a Logical Volume implemented on a RAID 10 Volume implemented across an array of Solid State Drives (SSDs) inserted directly into a server chassis as PCI Express devices. In this example, there are no network transmission elements involved at all, however containment and lifecycle dependencies are still managed for these object types in the same common manner as for networking objects.
'Lifecycle' is a key concern of Operational Support System management products with respect to management of the planning, implementation, operation and retirement of network, computing and application resources. Lifecycle has a special meaning in particular with respect to helping sharpen the meaning of what is regarded as a 'Structural composition' of resources. Taking the above example of an Operating System ultimately installed on an array of Solid State Storage devices, a variety of relationship cardinalities can be seen in the chain of structural composition:
The Operating System is installed on one Logical Volume only.
The Logical Volume is implemented on one RAID 0 Volume only.
- The RAID 10 Volume is implemented on many SSDs.
The immediate Lifecycle implications of these relationships are obvious:
Removing the Logical Volume from service will remove the Operating System from service.
Removing the one RAID 0 Volume from service will remove the Logical Volume from service.
Removing a single SSD will not cause the RAID 10 Volume to be removed from service, but removing more SSDs than striping redundancy can support across the array will result in the RAID 10 Volume being removed from service.
It can be observed that removing an object supporting the structural composition of a higher order object can result in the service failure of (and potential damage to) any higher order supported objects. Likewise, in order to bring a particular type of object into service, it must first be supported structurally by any necessary supporting objects. The correct sequencing of lower level or required counterpart objects through planned, implemented, operational, retired and removed states clearly impacts the sequencing of all higher order, dependent objects through their own lifecycle states.
A containment relationship may be thought of as any relationship between objects where a change in lifecycle status of one of the objects can potentially impact the lifecycle status of the other(s). Embodiments of the present invention enable these containment relationships to be defined and made clearly visible, regardless of technology type or layer. This can greatly simplify business process / lifecycle management logic, which would otherwise require specific codina for these various technology types and layers.
From a mathematical / geometric perspective, one-to-one, one-to-many and potentially many-to-many containment structures (as distinct from connectivity structures) are graph structures, no different to those seen in the networking domain. A series of containment relationships may extend through numerous objects not just vertically but also horizontally, and potentially therefore be confused as though they are connectivity structures.
Containment relationships exhibit numerous properties similar to network structures. They may be any one or more of: Graph structured; Layered and
Partitioned. There are many circumstances where containment relationships between computing or application objects are implemented over supporting network connectivity elements. In these cases, the aggregated computing or application object has a containment relationship with the supporting network connection, given that failure or removal of the network connection may result in lifecycle impact to the aggregated computing or application object.
For example, if a distributed application was to be implemented onto a distributed file system, in turn implemented across a number of host system nodes each containing a resource structure including Operating System, Volume, RAID & SSD elements, as described previously, the real advantage of this invention can then be seen more clearly in terms of the ability to support a resource structure containing networked containment structures, implemented through multiple architectural layers using a common containment and connectivity model. The relevance of this capability becomes even more apparent when technologies such as virtualisation, virtual networking, and distributed computing are also included in the mix of technologies under management.
No existing computing, network or application reference standards or models fully address the requirements for definition, traversal and management against cross- domain connectivity and containment structural scenarios in a single abstracted manner. Some of the existing models used in operations support (OSS), network management (NMS) and element management (EMS) systems support a common abstract class for all physical resources (inheriting from a single 'Physical Resource' abstract class), and likewise for all logical resource class types (which inherit from a single 'Logical Resource' abstract class). Some existing models also allow these Physical and Logical resources to be integrated into 'Compound' resources that enable some degree of understanding of the structural relationships between physical and various types of logical objects. In models where this is possible, any associated business logic must still be aware of the domain specific context of each resource, and use this knowledge during assignment or traversal of structural relationships. This is quite unlike the common model proposed in this invention, in which a single abstract model structure provides a common viewpoint across all containment relationships and connectivity associations for all such logical resource classes, within and across all architecture layers. This failing of existing models makes it impossible for any associated business logic elements to generically traverse all containment and connectivity relationships using a single abstract model based approach. This causes a number of key problems:
Within the design of software systems intended to manage objects across various model domains, specialised business logic implementations must be created which are suitable for each sub-model in order to navigate from top to bottom through the total federated model structure.
Business logic relevant to Capacity, Planning & Fault Analysis activities extending across all object elements in the Physical and Logical compute, network, application and service domains cannot therefore be implemented using a single abstract/generic view of the model.
Business logic relevant to any other Service Management activities, including rollup of resource sub-system Performance or Availability into aggregated service contract performance data, likewise cannot be implemented using a single
abstract/generic view of the relevant resource sub systems.
Figure 34A illustrates a potential view that could be generated with reference to a resource inventory structure conforming to the common model element described in either the first or second embodiments of the present invention. Resource objects are shown in multiple layers - 3410 contains Database Layer resources, 3420 contains Network layer resources, 3430 contains Storage layer resources and 3440 contains
Physical layer resources. It would be possible for a business logic or presentation component to generically navigate, analyse and/or present containment and connectivity relationships within and across all layers without any layer or technology domain based interpretation being required. 3450 highlights a path through the containment and connectivity structure where a higher than expected rate of Fault
Alarm events has occurred within a specific time period. This type of analysis and visualisation makes recognition of the location of the root cause of the fault very obvious. This style of processing, analysis and presentation may equally be applied to processing for other areas of management concern, such as capacity planning, disaster/business impact analysis, etc.
From an architectural perspective, Operational Support systems (OSS) envelope element management systems (EMS), network management systems (NMS) and service management systems, and can have visibility therefore of the numerous resource technology and service item types managed within each of these various systems.
Existing OSS data model designs support what are effectively federated views of various resource types, but do not support common, abstracted viewpoints supporting connectivity and containment relationships across all classes of resource objects, restricting the potential to create generalised OSS logic to perform analysis activities across all resources under management, regardless of technology type, vendor and resource lifecycle status. The fundamental limitation of existing standards / designs can be summarised as follows:
1. For those standards/designs that support multiple specific logical resource classes, the models relating to each of those various classes do not share a common inheritance hierarchy for the relevant object types within each that describe
containment, connectivity and forwarding associations.
2. For those models that provide a single unified network model within a particular technology or service type domain, those models do not as they stand support a capability to be implemented in conjunction with other (different) models that implement detailed support for specific classes of logical resources such that a common view of containment, connectivity and forwarding is possible across all objects in all model structures without needing to implement support for those classes of logical resource into the full unified network model - for example, it is not necessarily desirable to implement a containment, connectivity and forwarding model for Database and Storage Systems into a model intended for complex networks.
Embodiments of the present invention employ a graphically presentable framework capable of presenting and manipulating physical and logical inventory resource objects described within the framework of resource and interaction relationships between system resources in terms of connectivity associations and containment relationships. The ability to generically traverse complex network, computing and application related containment and connectivity relationships using high level, abstract relationships between all object types can allow implementation of common aspects in associated software system architectures including: User Interface elements, Generalised processing elements, Message passing elements, Expert System elements, and Data import/export elements. Embodiments of the present invention provide models that support 'convergence' in the real sense between each of the physical, networking, compute and application domains, whether virtualised or not, and a user interface approach for use in conjunction with the model.
Advantages with respect to embodiments of the present invention can include: 1. Supporting multiple Physical Resource item types
2. Supporting multiple Logical Resource item technology types (including Compute, Networking, Operating System, Database, Virtualisation, Security,
Application, Mashup etc)
3. Supporting complex network structures (to an engineering level of definition)
4. Supporting multiple network types/modes
5. Supporting network layering and partitioning
6. Supporting a unified connectivity and containment model structure across all Physical and Logical Resource domain classes; including all networking, compute and application related sub domains.
7. Supporting co-existence of multiple-models supporting different or overlapping domain areas
8. Supporting policy based management principles.
Some examples of the broad mixtures of technology types that can be managed using embodiments of this invention include:
- virtual local area network (VLAN) or virtual private network (VPN) over underlying internet protocol (IP) network over underlying transport network & physical links including Multiprotocol Label Switching (MPLS), Metro Ethernet & Fibre Optic transports,
- Database Instance over Operating System over physical environment
- File System over Storage Resource over physical environment
- Database Mirroring configuration connecting mirrored Databases across underlying logical and physical network infrastructure
- Virtualised server host instance over Operating System
- Virtualised server host instance over Physical Resource
- Virtual Machine object instances dynamically synchronised between separate Virtualisation Hosts
- Virtual Storage object instances dynamically synchronised between separate Virtualisation Hosts
- Virtual Network object instances dynamically synchronised between separate
Virtualisation Hosts
- Customised or optimised network flow paths defined in the context of a Software Defined Networking type network architecture, over host network or compute equipment.
- Virtualised Guest Operating System, Operating System. Application, Storage System or network protocol implementation over network flows defined in the context of a Software Defined Networking type network architecture. Examples of specific tool implementation embodiments:
Embodiments of the configuration module and graphical user interface of the system management tool of the invention may be implemented according to a number of system architecture scenarios, including but not limited to:
1. Web Application Server: a centralised data server stores data potentially belonging to multiple users ensuring security partitioning is enforced between all Users in compliance with defined access control rules. User interface functionality is implemented as functional web pages, published by one or more centralised web servers operating in conjunction with application layer logic implemented on one or more application servers accessing and manipulating data located on a data management system.
2. Client Server: a centralised data server stores data potentially belonging to multiple users and ensures security partitioning is enforced between all Users in compliance with defined access control rules. User interface functionality is
implemented as a client application module, or set of modules, that is installed and run locally on the User's computer or computing device. Delivery of client application modules may occur statically (such as via a manual installation process), on an assisted basis (such as via an online application store/shop, or software update process), or on a fully automated basis, such as via transparent delivery via web pages or some other localised application runtime host environment or application.
3. Offline/Disconnected: the application and data associated with any particular User are both located on a local computing device in the possession of that specific User. The User may periodically connect the device to a centralised server via a network connection and perform a bi-directional synchronisation of both changes made locally by the User, and changes made by other Users and stored centrally.
4. Local: the application and data associated with the implementation are both stored locally in the same local computing device, and can operate completely independently with respect to any centralised server implementation.
Each architectural scenario may be implemented using one or more specific technology implementations.
Examples of these are:
1. Centralised data server:
1.1. Proprietary Relational Database Management System (RDBMS) products such as: Oracle, SQL Server, DB/2
1.2. No SQL / Object Oriented Database Management System / Object Database products, such as: Objectivity/DB, Versant, Berkeley DB Centralised web application server:
2.1. Java Web Application Server: Tomcat (application logic developed in Java)
2.2. Enterprise Java Server: WebSphere Application Server, Oracle Internet
Application Server, JBoss (application logic developed in Java)
2.3. Microsoft IIS (application logic developed in .Net compatible languages - there are numerous, including C# and VB.NET).
2.4. Web servers compatible with other scripting languages such as Python, Ruby On Rails, etc
2.5. Web servers compatible with legacy languages including COBOL, FORTRAN
2.6. Web pages including dynamic content built using Javascript and/or other ECMA compatible languages
2.7. Web pages including dynamic content built using Java Standard Edition
(J2SE)
2.8. Web pages including dynamic content built using Adobe Flash
2.9. Web pages including dynamic content built using HTML5
2.10. Web pages including dynamic content built using Microsoft ActiveX
For 'client application module' the following languages may be used to build:
3.1. Java Platform Standard Edition - J2SE
3.2. Java Platform Micro Edition - J2ME
3.3. C, C++, Objective C
3.4. .Net compatible languages - there are numerous, including C# and VB.NET
3.5. Javascript and/or other ECMA compatible languages
3.6. HTML5
3.7. Adobe AIR
3.8. Other sandboxing technologies, including Google Native Client
For 'local computing device':
4.1. General purpose computer server or workstation:
4.1.1. Note: example CPU architectures/manufacturers include Intel, AMD, Alpha, Power, ARM etc. Example Operating Systems include Windows family, Apple OS/X family, Unix implementations, Linux implementations,
4.2. Tablet, Phone, Music Player, Book Reader, Personal Information Manager,
4.2.1. Note: example CPU architectures/manufacturers include ARM, Tl
OMAP, Intel Atom, AMD, Alpha, Power, etc.
4.2.2. Note: example Operating Systems include Windows family, Apple OS/X family, Unix implementations, Linux implementations,
4.3. Game Consoles,
4.4. Visualisation Systems Definitions:
'application architecture': this is a generalised term that includes (but is not limited to) items referenced in the next two items- 'application layering' & 'application network'.
'application layering': application architectures are often described as having
'(n) layers', which describes the number of architectural element types supporting application functions on an end to end basis from the user-interface through any front end, back end, middleware and data management layers etc. This may potentially be thought of in a vertical 'stack' based sense, as for network layering. For example a Logical Volume may exist within a Virtual Disk, in turn stored on another Logical
Volume. The future will see further evolution of how existing and new Logical Resource types relate to each other in a layered sense.
'application network': a set of application objects interconnected by one or more communication links and/or application interfaces supporting transfer of data of a specific type between those objects. The objects concerned may be: components that are only relevant within the context of the relevant application framework to which they commonly belong; components of another application architecture; or components of products implementing standards based interface methods. An application network will usually have a 'horizontal' connotation, as for a communications network (even though all object associations may be across Application Programming Interfaces (APIs).
NOTE: that Application Programming Interfaces (APIs) do not require communication links to function.
'Cloud Computing': Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. (National Institute of Standards and Technology, U.S. Department of Commerce).
'Compute and Application layer resource': in this design describes any form of logical resource that is not specifically networking related. This may include Operating
System, Virtualisation, Security or Application related objects etc.
'Connectivity': describes the modelling of connections between object types across a graph structured network model. Existing models and architectures are mostly oriented towards supporting objects and functions that perform a network or application Role of some sort. NOTE: In this design, items related in a connectivity structure are defined as those that do not have a lifecycle dependency on each other - they can be disconnected and continue separately in their own lifecvcles. 'Containment': normally describes an ownership association between objects. NOTE: In this design containment describes the modelling of associations between related objects that are created, modified or removed in conjunction (in some way) with each other - i.e. a lifecycle based relationship. Containment may be simple, whereby an object is fully contained by a single parent, or complex, where an object may continue to 'remain in existence' with the support of one or more other objects. When an item has multiple containment relationships to other objects, the association structures are analogous to Connectivity structures in that they can be represented by a graph based network structure. The key difference is that addition or removal of a containment association between objects can or will (depending on business rules) have a lifecycle impact on one or both of the objects concerned.
'communications network': a set of computing devices interconnected by one or more communication links supporting transfer of data between those devices. Given that physical networks usually span geographical territory to some extent, they usually have a 'horizontal' connotation. Logical network elements located within the same network layer are usually regarded as having a 'horizontal' connotation also.
'element management system': refers to a computer system used to manage one or more of a specific type of telecommunications network elements (NE). EMS systems manage functions and capabilities within each NE but do not manage the traffic between different NEs in the network.
'graph': a graph is a mathematical structure of nodes and interconnecting links. In the context of this document, 'graphs' are relevant due to the graph structures present in typical network and resource structure designs.
'network layer': describes the hierarchy of transport and processing functions required to move data across a communications link. This is supported historically by the 7 layer ISO model, which defines a standard prescribed strata of network layers, often referred to as a 'Protocol Stack'. The OSI view is commonly regarded now as being outdated in the reach of its descriptiveness.
'network layering': This is a term used more recently, supported by more modern standards such as the ITU G.800 network model which allows flexibility in assignment of layer functions and detailed description of connectivity structures etc. Given that communications links are implemented in the context of graph based structures, modelling of networks becomes a multi-dimensional activity with regard to links and layers. Objects in adjacent layers do not necessarily correspond on a one-to- one basis. Under the ITU model it is possible to describe very complex networks, including network transport layers that are used to carry other complete network protocol stacks, giving rise to the term 'layering'. For example Ethernet layered over MPLS layered over SDH. Rules may change over time regarding layer stacking order, for example MPLS started as a traffic prioritisation architecture that sat 'above' transport protocols. Transport MPLS exists now as a lower layer transport/switching protocol layered underneath even SDH. Network layering has a 'vertical' connotation.
'network management system': refers to a combination of hardware and software used to monitor and administer a computer network.
'network mode': refers to the class of network protocol implementation. These include: Circuit Switched (CS) and Packet Switched (PSN). The Packet Switched category includes two sub-modes: Connection Oriented (CO); and Connectionless (CL). Modern layering paradigms go well beyond the original intention of the OSI model and allow transport of CL protocols over CO, CO over CL, CS over CO etc.
'network type': refers to the specific network protocol implementation, and is usually relevant to a particular network mode. Example network types include:
(CS): TDM, PDH, SDH, OTN
· (PSN - CO): ATM, FR, MPLS, TCP/IP, SCTP/IP
(PSN - CL): UDP/IP, IPX, Ethernet, CLNP
'operations support system': refers to computer systems used by
telecommunications service providers and/or their customers to manage planning, fulfillment (implementation), assurance (service management) and billing business processes for application, network and computing class product, service and resource elements. The term 'Business Support System', or BSS, may be used with the same or overlapping meaning.
'party': an organisational or individual system related participant. These may be of various types including users, business units, customers, manufacturers, distributors, system integrators, service providers, consultants, regulators.
'SDO': Standards Development Organisation, organisations whose primary activity is to produce technical standards and/or enterprise architecture elements including the Institute of Electrical and Electronics Engineers (IEEE), International Telecommunication Union (ITU), TM Forum (TMF).
'virtualisation': virtualisation describes firstly the creation and utilisation of emulated copies of resources or services, as though they are the original resource or service object items themselves. Additionally, virtualisation provides benefits and has detractions that are not inherent in the original resource types. The meaningfulness and implementation of virtualisation has differences with respect to the following primary categories of virtualisation: Hardware Virtualisation; Network Virtualisation and Storage Virtualisation. Some vendors also make use of the terms Application
Virtualisation and Desktop Virtualisation.

Claims

SYSTEM MANAGEMENT TOOL
CLAIMS: 1. A system management tool comprising:
a configuration module adapted to enable definition of a system architecture having one or more physical and logical resources, the configuration module employing a framework to define system components and interaction relationships between system components in terms of a graph based structure, wherein interaction relationships define connectivity associations and containment relationships between system components; and
a graphical user interface (GUI) adapted to enable a user to select a functional perspective from which to view a defined system architecture, and render for display a graphical representation of one or more defined system components and interaction relationships therebetween that are selected for display by the GUI based on the graph based structure of the defined system architecture and the functional perspective selected by the user.
2. A system management tool as claimed in claim 1 wherein in the graph based structure, each system component in the system architecture is assigned one of a type of node, vertex or edge, based on a functional role of the system component where: node is used for a physical or logical resource;
vertex is used for a termination for a connection to a physical or logical resource; and
edge is used for a connection between two vertices,
wherein each node component can be associated with one or more vertex
components, each vertex component being associated with a single node component, and
each edge component can be associated with two or more vertex components to thereby define links between terminations for connection of physical or logical resources.
3. A system as claimed in claim 2 wherein the associations between node components, vertex components and edge components represent interaction relationships and each association is defined as a connectivity association or a containment relationship.
Substitute Sheet
(Rule 26) RO/AU
4. A system as claimed in claim 3 wherein a node component can be associated with one or more other node components to thereby define a containment relationship between the associated node components.
5 5. A system management tool as claimed in claim 3 wherein an edge component can be associated with only two vertex components, to thereby define a link between two terminations for connection of physical or logical resources.
6. A system as claimed in claim 3 wherein an edge component can be associated l o with two or more vertex components.
7. A system as claimed in claim 6 wherein each vertex component associated with a single edge component is designated a specific role defining the purpose of the vertex component in context of the association with the edge component.
15
8. A system as claimed in claim 3 wherein the framework is an information model.
9. A system as claimed in claim 8 wherein the information model is an object oriented model wherein classes for defining system components include an abstraction
20 type attribute whereby a system component is defined as a node, vertex or edge, and the object oriented model includes an interaction specification class to define containment associations and connectivity relationships whereby associations between objects having abstraction attribute types node, vertex and edge are defined.
25 10. A system as claimed in claim 9 wherein the interaction specification class
enables definition of an association between associated node, vertex or edge attribute objects in terms of any one of the attributes of:
containment type relationship between objects within a same layer of architecture hierarchy;
30 containment type relationship between objects in different layers of architecture hierarchy;
- connectivity type relationship between objects within a same layer of architecture hierarchy; or
connectivity type relationship between objects within different layers of 35 architecture hierarchy.
11. A system as claimed in claim 10 wherein the interaction specification class
Substitute Sheet
(Rule 26) RO/AU further enables definition of, and association between, objects having containment type relationships in terms of the attribute of containment importance.
12. A system as claimed in claim 10 wherein the interaction specification class
5. further enables definition of, and association between, objects having containment or connectivity type relationships in terms of any one or more of the attributes of:
option group;
multiplicity; and
context.
0
13. A system as claimed in claim 9 wherein the graph based structure is applied to existing standards based information models by adding the abstraction type attribute of node, vertex or edge into resource class specifications based on resource type whereby the abstraction attribute type is inherited by all resource inventory object5 instances of the defining resource specification classes, and creating instances of interaction objects to define connectivity or containment relationships between resource object instances based on template interaction specification definitions associated with resource class specifications for each resource type. 0
14. A system as claimed in claim 8 wherein the information model is an object oriented model having node, vertex and edge resource classes and association classes wherein each resource class inherits a class type from one of node vertex and edge resource classes, and association between resource objects are defined using instances of association objects wherein:
5 a relationship between node type objects is defined using a node association object;
a relationship between a node type object and a vertex type object is defined using a nodevertex association object;
a relationship between a vertex type object and an edge type object is defined0 using a vertexedge association object,
whereby containment and connectivity relationships are defined in attributes of the association objects.
15. A system as claimed in claim 14 wherein a node association object is used to5 define a containment relationship between two node objects as one of:
a containment relationship between node objects located within a same layer in architecture hierarchy;
Substitute Sheet
(Rule 26) RO/AU a containment relationship between node objects located within different layers in architecture hierarchy;
a containment relationship between node objects having the same or different technology types.
16. A system as claimed in claim 14 wherein a nodevertex association object is used to define a relationship between a node object and a vertex objection specifying one or more containment and connectivity roles.
17. A system as claimed in claim 14 wherein a vertexedge association object is used to define a relationship between an edge object and a vertex objection specifying one or more containment and connectivity roles.
18. A system as claimed in claim 8 wherein the configuration module includes a repository of information model template system resource specifications for use to define components of a system architecture.
19. A system as claimed in claim 18 wherein the template system resource specifications support definition of any one or more of:
allowed containment structures based on roles;
hierarchical containment structures having a fixed structure defined in the repository; and
hierarchical containment structures that may be modified.
20. A system as claimed in claim 18 wherein the template system resource specifications include any one or more of.
template connectivity structures; and
connectivity constraints.
21. A system as claimed in claim 18 wherein the information model includes a viewpoint class to enable definition of one or more viewpoints for graphical representation of system resources from different functional perspectives, presentation attributes can be defined for each system resource for each defined viewpoint in which the system resource is to be graphically presented, and the graphical user interface (GUI) is configured to render system resources in accordance with the defined presentation attributes for the system resource for a selected viewpoint.
Substitute Sheet
(Rule 26) RO/AU
22. A system as claimed in claim 21 wherein the GUI enables user input to define system components based on template system resource specifications.
23. A system as claimed in claim 22 wherein each template system resource specification defines at least one viewpoint whereby an instance of the system resource can be graphically presented, and default presentation attributes for each of the said at least one viewpoint.
24. A system as claimed in claim 23 wherein one or more instances of system resources are each defined for graphical representation from a first viewpoint and a second viewpoint and wherein the configuration module is adapted to interpret an input made via the GUI to define an attribute of a system resource instance and update corresponding attributes for graphical representation of the system resource instance from each viewpoint, whereby the affect of the attribute definition on graphical representation of the system resource instance made in one of the first viewpoint or the second viewpoint can cause a corresponding affect on the graphical representation of the system resource instance in the other of the first viewpoint and second viewpoint.
25. A system as claimed in claim 24 wherein the first viewpoint is an external viewpoint using a first geometric coordinate system and represents a physical appearance of the system from the outside and shows only physical system
components visible externally, and the second viewpoint is an internal view using a second geometric coordinate system different from the first geometric coordinate system and represents system components in diagrammatic form which can be independent of the physical layout of physical components and shows physical system components are both externally visible and not externally visible.
26. A system as claimed in claim 25 wherein the configuration module is adapted to interpret data entered by a user via the GUI to define system architecture using internal and external views interchangeably and where a configuration is defined using an internal view, a corresponding external view for externally visible system components is constructed or modified, and where configuration is defined using an external view a corresponding internal view is constructed or modified, and where a system
component is defined that has no external visibility but enables use of externally visible system components, the configuration module is adapted to construct or modify the corresponding external view to show that externally visible system components are enabled.
Substitute Sheet
(Rule 26) RO/AU
27. A system as claimed in claim 26 wherein the configuration module determines the externally visible system components enabled by a system component being defined from interaction relationships in a template resource specification for the
5 system component being defined and adds or modifies data for the system component being defined in accordance with the template resource specification to enable rendering of the enabled externally visible system components by the GUI.
28. A system as claimed in claim 21 wherein the GUI enables a single drag and i o drop gesture to be used to navigate between viewpoints and form a connection
between objects managed in the different viewpoints.
29. A system as claimed in claim 18 wherein the configuration module is adapted to support architecture definition where each of one or more system resource instances
15 can be defined as a mock object to enable a system resource instance to exist in an architecture in a state where attribute definition for the system resource is incomplete, the mock object being based on the template resource specification for the system resource.
20 30. A system as claimed in claim 29 wherein containment, connectivity, layering and role based rules are relaxed for mock objects to avoid incomplete definition of the system resource inhibiting definition of other system components and interaction relationships in the system architecture.
25 31. A system as claimed in claim 18 wherein template system resource definitions include support for definition of system components acting as access points, where an access point is a logical resource of vertex type that provides connection point capability for first logical resource of node type which has a containment relationship with a second logical resource of node type, the second logical resource of node type
30 being an internal logical resource of the first logical resource of node type and
connection to the second logical resource of node type is made via the access point, wherein template resource definitions provide a structure for defining connectivity relationships between a logical resource of edge type and both the logical resource of vertex type and the second logical resource of node type to thereby define the access
35 point connectivity relationship of connection to the second logical resource of node type contained by the first logical resource of node type via the logical resource of vertex type contained by the first logical resource of node type.
Substitute Sheet
(Rule 26) RO/AU
32. A system as claimed in claim 18 wherein the information model includes a logical partition class to enable defined system components to be grouped based on defined logical partitions.
33. A system as claimed in claim 32 wherein a logical partition is used to group all system components relevant to a service.
34. A system as claimed in claim 32 wherein logical partitions can be used to group system components based on any one or more of: service management requirements; operational processes; service delivery commitments; geography; location based zones; marketing territories; security partitioning; security classifications; statutory requirements; software as service partitions; platform as service partitions;
virtualisation partitions; and cloud computing partitions.
35. A system as claimed in claim 32 further comprising an inventory repository of defined system components adapted to be accessed via the GUI by a plurality of different parties.
36. A system as claimed in claim 35 wherein access to the defined system components of the inventory for each of the parties is controlled based on defined logical partitions.
37. A graphical user interface (GUI) in data communication with a configuration module storing a defined system architecture having one or more physical and logical resources, the configuration module employing a framework to define system components and interaction relationships between system components in terms of a graph based structure, wherein interaction relationships define connectivity associations and containment relationships between system components,
the GUI being adapted to:
receive a user selection of a functional perspective from which to view the defined system architecture;
select for display one or more defined system components and interaction relationships therebetween based on the graph based structure of the defined system architecture and the functional perspective selected by the user; and
render for display a graphical representation of the selected one or more defined system components and interaction relationships therebetween.
Substitute Sheet
(Rule 26) RO/AU
38. A method of representing a system architecture by a graphical user interface (GUI) the system architecture having one or more physical and logical resources and being defined in a configuration module employing a framework to define system components and interaction relationships between system components in terms of a graph based structure, wherein interaction relationships define connectivity associations and containment relationships between system components, the method comprising the steps of:
receiving by the GUI a user selection of a functional perspective from which to view a defined system architecture;
selecting for display one or more defined system components and interaction relationships therebetween based on the graph based structure of the defined system architecture and the functional perspective selected by the user;
rendering for display a graphical representation of the selected one or more defined system components and interaction relationships therebetween.
39. A method as claimed in claim 38 wherein in the graph based structure, each system component in the system architecture is assigned one of a type of node, vertex or edge, based on a functional role of the system component where:
node is used for a physical or logical resource;
vertex is used for a termination for a connection to a physical or logical resource; and
edge is used for a connection between two vertices,
wherein each node component can be associated with one or more vertex components, each vertex component being associated with a single node component, and
each edge component can be associated with two or more vertex components to thereby define links between terminations for connection of physical or logical resources, and
the associations between node components, vertex components and edge components represent interaction relationships and each association is defined as a connectivity association or a containment relationship.
40. A method as claimed in claim 39 further comprising an initial step of defining the system architecture using the GUI to access the configuration module,
wherein the framework is an information model and the configuration module includes a repository of template system resource specification for use to define
Substitute Sheet
(Rule 26) RO/AU components of a system architecture, and
defining the system architecture comprises the step of, for each system component, inputting data using the GUI to define attributes for the system component based on the template system resource specification of the system component.
*
41. A method as claimed in claim 40 wherein each template system resource specification defines at least one viewpoint wherein an instance of the system resource can be graphically presented default presentation attributes for the system resource for each of the said at least one viewpoint, and the method further comprises:
receiving an input via the GUI to select a template system resource
specification from the configuration module for a system component being defined; creating, by the configuration module, an instance of the selected system resource using the template system resource specification;
graphically presenting, by the GUI, the created system resource instance in accordance with one of said at least one viewpoint using the default presentation attributes for the viewpoint;
receiving data input via the GUI to define attributes for the created system resource instance;
interpreting the data input via the GUI by the configuration module and updating the created system resource instance with the defined attributes.
42. A method as claimed in claim 41 wherein where an instance of a system resource is defined for graphical representation from a first viewpoint and a second viewpoint the method further comprised the steps of:
receiving data input to define an attribute of the graphical presentation of the system resource instance via the GUI for the first viewpoint where the system resource is represented by the GUI from the first viewpoint;
interpreting the data by the configuration module to define the attribute of the system resource instance for the first viewpoint;
determining whether the affect of the attribute definition on graphical representation of the system resource instance made from the first viewpoint will cause a corresponding affect on the graphical representation of the system resource instance from the second viewpoint; and
where the attribute definition will cause a corresponding affect on the graphical representation of the system resource instance from the second viewpoint,
updating corresponding attributes for graphical representation of the system resource instance from the second viewpoint.
Substitute Sheet
(Rule 26) RO/AU
43. A method as claimed in claim 42 wherein the first viewpoint is an external viewpoint using a first geometric coordinate system and represents a physical appearance of the system from the outside and shows only physical system components visible externally, and the second viewpoint is an internal view using a second geometric coordinate system different from the first geometric coordinate system and represents system components in diagrammatic form which can be independent of the physical layout of physical components and shows physical system component are both externally visible and not externally visible.
44. A method as claimed in claim 43 further comprising the configuration module performing the steps of:
Interpreting data entered by a user via the GUI to define system architecture using internal and external views interchangeably, and
where configuration is defined using an external view, constructing or modifying a corresponding internal view,
where a configuration is defined using an internal view, constructing or modifying a corresponding external view for externally visible system components, and where a system component is defined that has no external visibility but enables use of externally visible system components, constructing or modifying a
corresponding external view to show that externally visible system components are enabled.
45. A method as claimed in claim 44 wherein the configuration module performs the steps of:
determining the externally visible system components enabled by a system component being defined from interaction relationships in a template resource specification for the system component being defined; and
adding or modifying data for the system component being defined in accordance with the template resource specification to enable rendering of the enabled externally visible system components by the GUI.
Substitute Sheet
(Rule 26) RO/AU
PCT/AU2013/000547 2012-06-14 2013-05-26 System management tool WO2013185166A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AU2012902487A AU2012902487A0 (en) 2012-06-14 System management tool
AU2012902487 2012-06-14
AU2013900180 2013-01-20
AU2013900180A AU2013900180A0 (en) 2013-01-20 System management tool

Publications (1)

Publication Number Publication Date
WO2013185166A1 true WO2013185166A1 (en) 2013-12-19

Family

ID=49757320

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2013/000547 WO2013185166A1 (en) 2012-06-14 2013-05-26 System management tool

Country Status (1)

Country Link
WO (1) WO2013185166A1 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3001317A1 (en) * 2014-09-26 2016-03-30 Alcatel Lucent Alarm correlation according to dependencies between entities of the managed data processing system
EP3154221A1 (en) * 2014-11-28 2017-04-12 Suntech S.A. A method for inventory of open broadband networks
CN107005454A (en) * 2014-12-23 2017-08-01 英特尔公司 Technology for generating the graph model for cloud infrastructure components
US9866552B2 (en) 2015-05-08 2018-01-09 International Business Machines Corporation Network authentication of a geo-fenced volume
EP3376738A4 (en) * 2016-03-03 2019-01-16 Huawei Technologies Co., Ltd. Resource configuration method and network device thereof
US10217067B2 (en) 2015-03-11 2019-02-26 International Business Machines Corporation System, method and program product for scheduling interventions on allocated resources with minimized client impacts
CN115758731A (en) * 2022-11-18 2023-03-07 中国航空无线电电子研究所 Advanced aviation electronic system architecture modeling tool
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5276789A (en) * 1990-05-14 1994-01-04 Hewlett-Packard Co. Graphic display of network topology
US20080209333A1 (en) * 2007-02-23 2008-08-28 Skypilot Networks, Inc. Method and apparatus for visualizing a network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5276789A (en) * 1990-05-14 1994-01-04 Hewlett-Packard Co. Graphic display of network topology
US20080209333A1 (en) * 2007-02-23 2008-08-28 Skypilot Networks, Inc. Method and apparatus for visualizing a network

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3001317A1 (en) * 2014-09-26 2016-03-30 Alcatel Lucent Alarm correlation according to dependencies between entities of the managed data processing system
EP3154221A1 (en) * 2014-11-28 2017-04-12 Suntech S.A. A method for inventory of open broadband networks
CN107005454A (en) * 2014-12-23 2017-08-01 英特尔公司 Technology for generating the graph model for cloud infrastructure components
EP3238102A4 (en) * 2014-12-23 2018-05-30 Intel Corporation Techniques to generate a graph model for cloud infrastructure elements
US10217067B2 (en) 2015-03-11 2019-02-26 International Business Machines Corporation System, method and program product for scheduling interventions on allocated resources with minimized client impacts
US10832184B2 (en) 2015-03-11 2020-11-10 International Business Machines Corporation System, method and program product for scheduling interventions on allocated resources with minimized client impacts
US9866552B2 (en) 2015-05-08 2018-01-09 International Business Machines Corporation Network authentication of a geo-fenced volume
US9998457B1 (en) 2015-05-08 2018-06-12 International Business Machines Corporation Network authentication of a geo-fenced volume
US9992195B2 (en) 2015-05-08 2018-06-05 International Business Machines Corporation Network authentication of a geo-fenced volume
US9882898B2 (en) 2015-05-08 2018-01-30 International Business Machines Corporation Network authentication of a geo-fenced volume
EP3376738A4 (en) * 2016-03-03 2019-01-16 Huawei Technologies Co., Ltd. Resource configuration method and network device thereof
US10616133B2 (en) 2016-03-03 2020-04-07 Huawei Technologies Co., Ltd. Resource configuration method and network device thereof
US11811681B1 (en) 2022-07-12 2023-11-07 T-Mobile Usa, Inc. Generating and deploying software architectures using telecommunication resources
CN115758731A (en) * 2022-11-18 2023-03-07 中国航空无线电电子研究所 Advanced aviation electronic system architecture modeling tool
CN115758731B (en) * 2022-11-18 2024-01-09 中国航空无线电电子研究所 Advanced avionics architecture modeling tool

Similar Documents

Publication Publication Date Title
WO2013185166A1 (en) System management tool
US9621428B1 (en) Multi-tiered cloud application topology modeling tool
US9703890B2 (en) Method and system that determine whether or not two graph-like representations of two systems describe equivalent systems
US10116525B2 (en) Extensible infrastructure for representing networks including virtual machines
US20180097872A1 (en) System and method for abstraction of objects for cross virtual universe deployment
Pandithurai et al. A method to support multi-tenant as a service
US6314460B1 (en) Method and apparatus for analyzing a storage network based on incomplete information from multiple respective controllers
TWI530890B (en) Distributed network management using a logical multi-dimensional label-based policy model
US9927958B2 (en) User interface for networks including virtual machines
US9467344B2 (en) Mechanism to display graphical IT infrastructure using configurable smart navigation
US10528897B2 (en) Graph databases for storing multidimensional models of software offerings
US7505995B2 (en) Object-relational model based user interfaces
US8954859B2 (en) Visually analyzing, clustering, transforming and consolidating real and virtual machine images in a computing environment
US8495352B2 (en) System and method for instantiation of distributed applications from disk snapshots
CN100580622C (en) Telecommunication region modeling tool based on unified modeling language and modeling method
US10462010B2 (en) Detecting and managing recurring patterns in device and service configuration data
JP2016511894A (en) Building an application to configure a process
US8984121B1 (en) Dependency visualization and fault diagnosis using multidimensional models for software offerings
EP2815346A1 (en) Coordination of processes in cloud computing environments
US20120222004A1 (en) Publishing and updating of multidimensional models using orchestration tools for software offerings
WO2020081949A1 (en) System and method for auto-completion of ics flow using artificial intelligence/machine learning
Dukaric et al. BPMN extensions for automating cloud environments using a two-layer orchestration approach
WO2001008007A9 (en) Method and system of automated generation of program code from an object oriented model
KR20040079337A (en) Architecture for distributed computing system and automated design, deployment, and management of distributed applications
Bobák et al. Application Performance Optimization in Multicloud Environment.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13803765

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13803765

Country of ref document: EP

Kind code of ref document: A1