JP2015052875A - Software component generation apparatus, software component generation method, and management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To describe a roll definition statement using ontology, and generate a software component corresponding to a roll from the roll definition statement described by ontology.SOLUTION: A software component generation apparatus which generates a software component from a roll definition statement described using ontology, comprises: property parts storage means for storing property parts which are code of property indicating the relationship between rolls; code of the interface definition for an object generated by the software component; code generation means for generating the code to use the property parts of the property described in the roll definition statement; and software component generation and output means for acquiring from the property parts storage means the property parts of the property described in the roll definition statement so as to generate a software component containing the property parts and the code generated by the code generation means and output the software component.

Description

  The present invention relates to a technique for constructing software components using an ontology. One application of the present invention is a network management system automatic construction technique.

  Ontology is a standardized concept and notation method for systematically expressing vocabulary (concepts). Ontology defines vocabulary as a class. A class consists of multiple properties. Each property represents the relationship between that class and other classes. The ontology is expressed in, for example, OWL (Web Ontology Language) using XML (for example, see Non-Patent Document 1).

  On the other hand, in addition to directly managing the physical entities of network equipment, the network management system applies management objects such as paths and channels in the network to manage paths and channels. Furthermore, a virtualized network that virtually represents network facilities for each provided service or each user needs to apply a management object corresponding to each virtual representation to the network.

W3C Recommendation, "OWL Web Ontology Language Overview," 10 February 2004, http://www.w3.org/TR/owl-features/ Kenji Tsuji, Yukio Tsukishima, Fumihiro Shimbu, “Examination of management engine using role hierarchy model,” IEICE Technical Report, ICM2012-38, pp.7-12, January 2013.

  In order to provide a virtual network for each provided service and each user, it is necessary to dynamically construct and apply management objects according to each virtual expression. As a solution, there is a management engine to which the role hierarchy model described in Non-Patent Document 2 is applied.

  As described in Non-Patent Document 2, the role hierarchy model is a model in which roles representing each management target are stacked to represent a network. Therefore, what is important is to express the relationship between rolls, but the technique described in Non-Patent Document 2 has not yet determined a specific method for expressing the relationship between roles.

  The present invention has been made in view of the above points, and provides a technique for describing a role definition document using an ontology and generating a software component corresponding to the role from the role definition document described in the ontology. Objective.

According to an embodiment of the present invention, there is provided a software component generation device that generates a software component from a role definition document described using an ontology,
Property part storage means storing property parts which are property codes indicating the relationship between roles;
Code for generating an interface definition of an object generated by the software component, and code for using a property part of a property described in the role definition document;
Software that acquires a property part of the property described in the role definition document from the property part storage unit, generates a software component including the property part and the code generated by the code generation unit, and outputs the software component There is provided a software component generation apparatus including a component generation / output unit.

  The property described in the role definition document represents, for example, a property representing attribute information of the target role, a property representing an operation provided by the role to the outside, or a constraint condition for the role to exist. It is a property. In addition, as the ontology language, for example, the role definition document is described using a web ontology language (OWL).

According to an embodiment of the present invention, there is provided a management engine system that includes the software component generation device and constructs a network management system using a roll component that is a software component generated by the software component generation device. ,
The role defined in the role definition document is a role expressing a management object of the network,
Storage means for storing the role component generated from the role definition document;
There is provided a management engine system, characterized by comprising means for operating a roll component read from the storage means and causing the roll component to generate a roll object corresponding to a management object.

  According to an embodiment of the present invention, a technique is provided in which a role definition document is described using an ontology, and a software component corresponding to the role is generated from the role definition document described in the ontology.

It is a figure which shows the example which describes a role definition document by ontology. It is a figure which shows the whole image at the time of producing | generating a roll component from a role definition document. It is a figure which shows the procedure etc. which produce | generate the roll component 10 from the roll definition document. 2 is a functional configuration diagram of a roll generation device 100. FIG. It is a figure which shows the image of the interface of a role. It is a figure which shows the example of the management model of the network in an Example. It is a figure which shows the inheritance relationship of the class handled by the Example. It is a figure which shows the property defined in the Example, and its inheritance relationship. It is a figure which shows the example of mounting of Attribute property. It is a figure which shows the implementation example of Action property. It is a figure which shows the example of mounting of Constraint property. It is a figure which shows the example of a role hierarchy model. It is a figure which shows repetition to a roll hierarchy. 2 is a configuration diagram of a management engine system 210. FIG. 2 is a configuration example of a roll matching unit 212.

  Hereinafter, a technique for generating a roll component from a roll definition document described in an ontology will be described with reference to the drawings. Here, the role component refers to a software component using Java (registered trademark) language created from a role definition document. However, the language of the software component is not limited to Java (registered trademark), and may be another language.

  The “role” in the present embodiment is assumed to be a management target (communication device, path, line, etc.) in a role hierarchy model that virtually represents network equipment described in Non-Patent Document 2, for example. However, the technology in the present invention can be applied to objects other than such roles related to the network. The software component of the role indicating the target operates on a device such as a computer (eg, management engine system), generates an object, and the object exchanges information with the role user (external system, other role, etc.). Thus, a desired operation is realized.

(Role definition document by ontology)
An example in which a role definition document is represented by ontology is shown in FIG. The role name is described in the ontology class name, and the relationship between the roles is defined and described in the ontology property. The actual notation is written in XML using OWL.

(Role component generation image)
FIG. 2 shows an overall image when a roll component is generated from a roll definition document.

  The role definition document is written in OWL, but for the convenience of explanation, the expression in Fig. 1 is adopted here. The representation of FIG. 1 is not substantially different from the case described in OWL. The role definition document shown in FIG. 2 describes three properties, property A, property C, and property D. The software configuration (which may be called a program or code) of the roll component 10 generated from this roll definition document is shown below.

  As shown in FIG. 2, the role component 10 includes a property part 11 corresponding to each property described in the role definition document, and a behavior code part 12 that operates the property part 11. The property component 11 is acquired from a property component shelf 15 (for example, memory in a computer) prepared in advance. That is, each property component 11 is coded in advance and stored in the property component shelf 15. The behavior code unit 12 is coded for each role because the content is different for each role.

  With this configuration, a role component can be generated by coding the behavior code unit 12 corresponding to the role definition document. The property component 11 is reused for other roles.

(Processing procedure, device configuration example)
FIG. 3 shows a procedure for generating the roll component 10 from the role definition document 30 using the ontology, and a detailed configuration example of the generated roll component 10. Each part in the roll component 10 shown in FIG. 3 corresponds to a program that realizes the function of the part.

  Further, call, import, and the like in the figure indicate operations such as a call when the roll component 10 is executed in the target device. The target device is a computer, a management engine system described later, or the like.

  FIG. 3 shows a role generation device 100 (an example of a software component generation device). As will be described later, the role generation device 100 generates an interface definition code, a code for using a property component, and the like from a role definition document described in an ontology.

  As shown in FIG. 3, a property is first defined (step 10), a program (code) corresponding to the property definition is created, and it is placed on the property component shelf 15 as a property component 11 (step 11). That is, the property component 11 is stored in a storage unit used as the property component shelf 15 in the computer. For example, the property component shelf 15 may be provided in the roll generation device 100.

  Next, a role definition document 30 is created using the created property definition. Then, the role definition document 30 is converted into two types of codes by the role generation device 100 (step 13). One is a role object / factory interface definition 18, and the other is an automatically generated code unit 16.

  The interface definition 18 is generated from the role component name described in the role definition document.

  The automatically generated code unit 16 mediates property usage definition and property parts in the role definition document. Property usage definition is the property information that is different for each role definition document and the argument information used in the property. The roll generation apparatus 100 automatically generates a code (program) based on these contents described in the roll definition document to create an automatic generation code unit 16.

  Here, the factory component 17 shown in FIG. 3 is a program that has a search function for a roll object generated by a roll component and is created in advance. The factory part 17 may be placed outside the roll component 10 and the factory part 17 may be used for various types of roll components. Note that it is not essential in the present invention to provide a factory having a search function as in this example.

  The behavior code part 12 is a code part (program) in which a user finally writes a part that cannot be automatically generated, and describes different contents for each role. The behavior code part 12 is called from each of the automatically generated code part 16, the factory part 17, and the property part 11. For example, the call from the automatically generated code unit 16 to the behavior code unit 12 is performed when processing across a plurality of property parts is required, and the call from the property part 11 to the behavior code part 12 uses the property part 11 as a general purpose. This is performed when the difference of each role definition is described in the behavior code part 12 when the change is made.

  FIG. 4 shows a functional configuration example of the role generation device 100 that generates the roll component 10 from the role definition document 30.

  As shown in FIG. 4, the role generation device 100 includes a role definition document input unit 110, a role definition document storage unit 120, an interface definition generation unit 130, a property use code generation unit 140, a created program storage unit 150, and a role component generation. An output unit 160 is provided.

  A role definition document written in an ontology language is input from the role definition document input unit 110 and stored in the role definition document storage unit 120. The interface definition generation unit 130 reads the role definition document from the role definition document storage unit 120 and generates the interface definition code as described above. The property use code generation unit 140 reads the role definition document from the role definition document storage unit 120. , And a code for using the property part of the property described in the role definition document, for example, a code for mediating property usage definition and property part in the role definition document is generated. Note that even if the interface definition generation unit 130 and the property use code generation unit 140 are one function unit, the function unit reads the role definition document and generates an interface definition code and a code for using the property component. Good.

  The created program storage unit 150 stores created programs such as a program parts shelf including a plurality of program parts, a behavior code unit 12, and the like, and the roll component generation / output unit 160 is a roll component to be generated. The program component 11 and the behavior code unit 11 to be used are read from the created program storage unit 150, and these are combined with the programs generated by the interface definition generation unit 130 and the property use code generation unit 140 to generate the roll component 10. ,Output. The output roll component 10 may be stored in a predetermined storage device and used when necessary, or the output roll component may be input to a target device (such as a management engine system) to It is good also as performing operation | movement (example: network management).

  The roll generation apparatus 100 can be realized by causing a computer used as the roll generation apparatus 100 to execute a program describing the processing content described in the present embodiment. That is, each functional unit of the role generation device 100 can be realized by executing a program corresponding to a process performed by each unit using hardware resources such as a CPU, a memory, and a hard disk built in the computer. Is possible. The above-mentioned program can be recorded on a computer-readable recording medium (portable memory or the like), stored, or distributed. It is also possible to provide the program through a network such as the Internet or electronic mail.

  In addition, it is good also as providing the roll production | generation apparatus 100 inside the object apparatus (example: management engine system).

  FIG. 5 shows an image of an interface provided to the outside when the roll component generated from the roll definition document is executed by the target device.

A role component 10 automatically generated from a role definition document exists, and an instance of a role generated / deleted in accordance with the operation of the role component 10 is a role object.
Role users such as external systems and other role components access the role object. However, the factory provided by the role component 10 can be used when necessary for searching or the like.

  The role object has a getter / setter interface for attribute information defined by the Attribute property, which will be described later, and an interface for each Action defined by the Action property. Role users use role objects using these interfaces.

(Example of role definition by ontology and role component generation)
In the following, an embodiment of a network management model for ontology role definition and role component generation will be described.

[1. Target management model]
FIG. 6 shows a management model of a target network in this embodiment. The model shown in FIG. 6 is a management model extracted from ITU-T M.3100 as a reference. The management model is only an example to which the present invention is applied.

  Fabric in FIG. 6 represents a device. The fabrics are connected by a physical link, and the connection point is a physical port. There is a Connection in the PhysicalLink, and the end point of the Connection is a ConnectionTerminationPoint (connection termination point). There are multiple Connections in one PhysicalLink, but only one is shown in this figure. Among the three fabrics in FIG. 6, the center fabric has a cross connection that connects the connection termination points. This CrossConnection switches the connection relationship between ConnectionTerminationPoints.

  A trail is created by connecting multiple Connections and CrossConnections. In the example of FIG. 6, the end point of the Trail is a TrailTerminationPoint (trail termination point) in the Fabric at both ends. This trail becomes a network connecting two points.

[2. Class inheritance relationship]
FIG. 7 shows the inheritance relationship of classes handled in this embodiment.

  In the role definition document, in addition to the definition of the role component, it is necessary to define the structure of data passed between the role components. Since both are class definitions in the ontology, class inheritance is used to classify them into Component classes and Data classes in order to clearly distinguish them from each other in code generation.

  That is, as shown in FIG. 7, Component and Data are placed in the parent class. A subclass of Component generates code as a role component, and a subclass of Data generates a POJO (Plain Old Java Object) assuming that it is a data definition.

  In this embodiment, Fabric, CrossConnection, and Pipe are role components, so they are defined as child classes of Component. Pipe is a parent class of Trail, Connection, and PhysicalLink that represents a connection.

  Since TerminationPoint, ObjectId, and Capacity have data structures, they are defined as child classes of Data. TerminationPoint is a parent class of TrailTerminationPoint, ConnectionTerminationPoint, and PhysicalPort representing an end point.

  ObjectId is a parent class of each class for identifying each data. Capacity is a parent class of TrailCapacity, ConnectionCapacity, and PhysicalCapacity representing the capacity used by each instance of Trail, Connection, and PhysicalLink.

[3. Properties]
In this embodiment, the properties of the role definition document are also classified using inheritance. FIG. 8 shows the properties defined in this embodiment and their inheritance relationships. In this embodiment, the properties are classified into the following three types, and each property is inherited from the parent properties of Attribute, Action, and Constraint.

(3.1) Attribute
This is the parent property of each property that represents the attribute information of the role. Create getter / setter of role object according to the attribute information described in the child property of this property, and generate code to make the attribute information permanent.

(3.2) Action
This is the parent property of each property that represents the operation that role provides externally. Generate the external interface of the role according to the contents described in the child property of this property.

(3.3) Constraint
It is the parent property of each property that represents the constraint condition for the role to exist. Creation and deletion of role objects are restricted according to the contents described in the child properties of this property.

  The OWL definition of each property shown in FIG. 8 will be described below. The explanation uses OWL terminology.

(3.4) hasObjectId
This property represents the relationship between the class representing the management target and its identifier. The name of the class to be managed is placed in the subject (Domain), and the object ID that is the parent class of the identifier is placed in the object (Range).

  Since the property of the property and the identifier of the managed object are uniquely determined from each other, it is set to “Funtional and Inverse Functional”. If the subject and object are swapped, ObjectId cannot be related, so it is Asymmetric, and ObjectId cannot be related to itself, so it is Irreflexive.

The OWL definition of hasObjectId is shown below.
<owl: ObjectProperty rdf: about = "hasObjectId">
<rdfs: domain>
<owl: Class>
<owl: unionOf rdf: parseType = "Collection">
<rdf: Description rdf: about = "CrossConnection"/>
<rdf: Description rdf: about = "Fabric"/>
<rdf: Description rdf: about = "Pipe"/>
<rdf: Description rdf: about = "TerminationPoint"/>
</ owl: unionOf>
</ owl: Class>
</ rdfs: domain>
<rdfs: range rdf: resource = "ObjectId"/>
<rdf: type rdf: resource = "&owl;FunctionalProperty"/>
<rdf: type rdf: resource = "&owl;InverseFunctionalProperty"/>
<rdf: type rdf: resource = "&owl;AsymmetricProperty"/>
<rdf: type rdf: resource = "&owl;IrreflexiveProperty"/>
</ owl: ObjectProperty>
(3.5) hasTerminationPoint
This property represents the relationship between the Pipe class that represents a connection and the TerminationPoint class that represents its end point. The Pipe class is placed in the subject (Domain), and the TerminationPoint class is placed in the object (Range).

  The property is not set to Functional because there is a TerminationPoint at each end of the Pipe, so there is no single target from the subject. On the other hand, since the Pipe related to TerminationPoint is determined as one, Inverse Functional is set. If you replace the subject and object, you can't have the relationship of hasTerminationPoint, so it's Asymmetric, and Pipe cannot be related to itself, so it's Irreflexive.

  The definition of hasTerminationPoint is shown below.

<owl: ObjectProperty rdf: about = "hasTerminationPoint">
<rdfs: domain rdf: resource = "Pipe"/>
<rdfs: range rdf: resource = "TerminationPoint"/>
<rdf: type rdf: resource = "&owl;InverseFunctionalProperty"/>
<rdf: type rdf: resource = "&owl;AsymmetricProperty"/>
<rdf: type rdf: resource = "&owl;IrreflexiveProperty"/>
</ owl: ObjectProperty>
(3.6) hasPart
This property represents the relationship in which the subject contains the object. Since the inclusion relationship is a general relationship and the subject and object classes cannot be fixed, Domain and Range are not set.

  The nature of the property is not functional because the subject may contain more than one object and there is no single object for the subject. The object is not an Inverse Functional because it may be contained in multiple types of subjects. Since the relation to include is recursive, we set Transitive. The inclusion relationship cannot be replaced, so it is Asymmetric, and the relationship that includes itself is unnatural, so it is Irreflexive.

  hasPart is inversely related to isPartOf described below. The definition of hasPart is shown below.

<owl: ObjectProperty rdf: about = "hasPart">
<rdf: type rdf: resource = "&owl;TransitiveProperty"/>
<rdf: type rdf: resource = "&owl;AsymmetricProperty"/>
<rdf: type rdf: resource = "&owl;IrreflexiveProperty"/>
<owl: inverseOf rdf: resource = "isPartOf"/>
</ owl: ObjectProperty>
(3.7) isPartOf
This property represents the relationship in which the subject is included in the object, and is inversely related to hasPart. Like hasPart, Domain and Range are not set.

  Property properties are the same as hasPart. The definition of isPartOf is shown below.

<owl: ObjectProperty rdf: about = "isPartOf">
<rdf: type rdf: resource = "&owl;TransitiveProperty"/>
<rdf: type rdf: resource = "&owl;AsymmetricProperty"/>
<rdf: type rdf: resource = "&owl;IrreflexiveProperty"/>
<owl: inverseOf rdf: resource = "hasPart"/>
</ owl: ObjectProperty>
(3.8) hasCapacity
This property represents the relationship between the Pipe class that represents the connection and the Capacity class that represents the capacity of the Pipe. Place Pipe in the subject (Domain) and Capacity in the object (Range).

  The property is assumed to have a one-to-one correspondence between one instance of Pipe and one instance of Capacity, so Functional and Inverse Functional are set. Since the subject and the object cannot be interchanged, it is set to Asymmetric, and since it is not related to itself, it is set to Irreflexive.

  The definition of hasCapactiy is shown below.

<owl: ObjectProperty rdf: about = "hasCapacity">
<rdfs: domain rdf: resource = "Pipe"/>
<rdfs: range rdf: resource = "Capacity"/>
<rdf: type rdf: resource = "&owl;FunctionalProperty"/>
<rdf: type rdf: resource = "&owl;InverseFunctionalProperty"/>
<rdf: type rdf: resource = "&owl;AsymmetricProperty"/>
<rdf: type rdf: resource = "&owl;IrreflexiveProperty"/>
</ owl: ObjectProperty>
(3.9) makeXC
It is a property that creates the connection relationship of TerminationPoint. CrossConnection is placed in the subject (Domain), and TerminationPoint is placed in the object (Range).

  This property represents an action related to CrossConnection, not a containment relationship like the properties described so far. By executing this property, it is assumed that connections between TerminationPoints in the same Fabric will be created.

  The properties are omitted because this property is related to actions. Definitions are shown below.

<owl: ObjectProperty rdf: about = "makeXC">
<rdfs: domain rdf: resource = "CrossConnection"/>
<rdfs: range rdf: resource = "TerminationPoint"/>
</ owl: ObjectProperty>
[4. class]
Next, each class definition (corresponding to a role definition document) in the present embodiment will be described. For convenience, the contents of each definition will be described in the notation as shown in FIG.

(4.1) Fabric
Fabric has FabricId as an identifier. Definitions are shown below.

Class name: Fabric
hasObjectId exactly 1 FabricId
(4.2) PhysicalLink
PhysicalLink has PhysicalLinkId as an identifier, two PhysicalPorts as both end points, and PhysicalCapacity as a capacity. Definitions are shown below.

Class name: PhysicalLink
hasObjectId exactly 1 PhysicalLinkId
hasTerminationPoint exactly 2 PhysicalPort
hasCapacity exactly 1 PhysicalCapacity
(4.3) Connection
Connection has ConnectionId as an identifier, two ConnectionTerminationPoints as both end points, and ConnectionCapacity as a capacity.

  Since Connection is included in PhysicalLink, it also has an isPartOf relationship. The reason why Connection is not described in the definition in PhysicalLink is that Connection exists above PhysicalLink in the role hierarchy model. In the role hierarchy model, the definition of the upper role is not described in the lower role so that anything can come to the upper role.

  Definitions are shown below.

Class name: Connection
hasObjectId exactly 1 ConnectionId
hasTerminationPoint exactly 2 ConnectionTerminationPoint
hasCapacity exactly 1 ConnectionCapacity
isPartOf exactly 1 PhysicalLink
(4.4) Trail
Trail has TrailId as an identifier, two TrailTerminationPoints as end points, and TrailCapacity as capacity.

  Since Trail is a connection of Connection, HasPart places Connection. ConnectionTerminationPoint and CrossConnection related to Connection are not included in this definition because they can be extracted if the Connection can be specified.

  Definitions are shown below.

Class name: Trail
hasObjectId exactly 1 TrailId
hasTerminationPoint exactly 2 TrailTerminationPoint
hasCapacity exactly 1 TrailCapacity
hasPart some Connection
(4.5) CrossConnection
CrossConnection uses CrossConnectionId as an identifier and has two ConnectionTerminationPoints as components.

  As an action for creating a CrossConnection, makeXC with two ConnectionTerminationPoints as objects is placed.

  Definitions are shown below.

Class name: CrossConnection
hasObjectId exactly 1 CrossConnectionId
hasPart exactly 2 ConnectionTerminationPoint
makeXC exactly 2 ConnectionTerminationPoint
(4.6) PhysicalPort
PhysicalPort has PhysicalPortId as an identifier. Definitions are shown below.

Class name: PhysicalPort
hasObjectId exactly 1 PhysicalPortId
(4.7) ConnectionTerminationPoint
ConnectionTerminationPoint has ConnectionTerminationPointId as an identifier. Since ConnectionTerminationPoint is included in one PhysicalPort, it has an isPartOf relationship. Definitions are shown below.

Class name: ConnectionTerminationPoint
hasObjectId exactly 1 ConnectionTerminationPointId
isPartOf exactly 1 PhysicalPort
(4.8) TrailTerminationPoint
TrailTerminationPoint uses a TrailTerminationPointId as an identifier and has a HasPart relationship to one ConnectionTerminationPoint. Definitions are shown below.

Class name: TrailTerminationPoint
hasObjectId exactly 1 TrailTerminationPointId
hasPart exactly 1 ConnectionTerminationPoint
(4.9) PhysicalCapacity
PhysicalCapacity has an integer value as the capacity of PhysicalLink. Definitions are shown below.

Class name: PhysicalCapacity
hasIntegerValue some integer
(4.10) ConnectionCapacity
ConnectionCapacity represents a Connection capacity and is included in one PhysicalCapacity. This represents the capacity relationship between Connection and Physical.

  Definitions are shown below.

Class name: ConnectionCapacity
isPartOf exactly 1 PhysicalCapacity
(4.11) TrailCapacity
TrailCapacity represents the Trail capacity and has a relationship of several ConnectionCapacity and hasPart. Since there are multiple Connections related to Trail, we have some relationship.

  Definitions are shown below.

Class name: TrailCapacity
hasPart some ConnectionCapacity
[5. Example of implementation]
Hereinafter, an example of the implementation contents of each property in the present embodiment will be described. In the following, explanation will be given using the CrossConnection role definition document described above as an example.

(5.1) Implementation example of Attribute property
An example implementation of the Attribute property is shown in FIG. In FIG. 9, the hasConnectionId property of CrossConnection is used as an example.

  Generate CrossConnectionId getter and setter interfaces from role definition document. The auto-generated code part 16 has getter and setter implementation parts, which call the hasObjectId component to make the CrossConnectionId permanent. When calling the hasObjectId component, context information with the corresponding role object information is also passed. The image of context information is BundleContext in OSGi.

  In hasObjectId property component, persistence of role object attribute information with CrossConnectionId as primary key from the passed information.

(5.2) Implementation example of Action property
An implementation example of the Action property is shown in FIG. In FIG. 10, the makeConnection property of CrossConnection is used as an example.

  Generate makeXC interface from role definition document. The automatically generated code unit 16 has a makeXC implementation. The automatically generated code unit 16 calls the makeXC property component using the ConnectXTerminationPoint which is an argument of makeXC and the context information of the role object as arguments.

  The makeXC property component checks the conditions such as whether the argument ConnectionTerminationPoint exists in the same Fabric, and performs cross connection.

(5.3) Implementation example of Constraint property
An example of implementation of the Constraint property is shown in FIG. In FIG. 11, the hasPart property of CrossConnection is used as an example.

  Since the role user does not assume individual operations of the Constraint property, a Constraint interface as an external interface of the role object is not generated. The automatically generated code unit 16 to be generated calls the hasPart property component 11 with the context information of the corresponding role object as an argument when the corresponding role is generated / deleted. The hasPart component 11 sees the argument relationship and returns whether the inclusion relationship is satisfied.

(Example of management engine system)
Hereinafter, an embodiment of a management engine system that automatically creates a network management system by automatically generating a roll component from a role definition document using an ontology and causing the roll component to operate autonomously will be described.

  A role that is a management object according to the present embodiment virtually represents a network facility to be managed. The management engine system operates a plurality of role components at the same time while maintaining consistency with each other, thereby providing the same network facility to a plurality of users in different virtual representations. As a result, the network equipment can be shared by various network services, thereby reducing the investment cost. Furthermore, since each role operates consistently on the management engine system, the operation cost can be reduced.

[About role hierarchy model]
Next, an example of a role hierarchy model used in the management engine system in the present embodiment will be described.

  The role hierarchy model of the present embodiment expresses management objects applied to the network by the concept of roles. Rolls are expressed from the lower layers. FIG. 12 shows an example of a role hierarchy model according to the present embodiment. Note that the example shown in FIG. 12 is merely an example, and rolls can be defined in various ways other than those shown in FIG.

  As shown in FIG. 12, a role representing the function of the physical entity of the network facility is placed in the lowest layer. This is called a primitive roll. In FIG. 12, a switch roll representing a switch, a data line roll representing a data line between the switches, and an access line roll representing a line between the switch and the user are arranged.

  By using the function of this primitive role, a path that is a network element at a higher layer than the physical entity is expressed. This is called a path roll. The path roll is composed of a part of the forwarding setting in each switch roll and a part of the band provided by the data line roll. Furthermore, as a higher rank of the path roll, a channel roll can be constructed by combining a part of the band of the path roll and a part of the band of the access line roll. That is, a network element at a higher hierarchy than the physical entity is expressed by a role in which a part or all of roles composed of a part or all of primitive roles are hierarchically combined. This can be said to be expressed by a roll in which some or all of the primitive rolls are combined directly or indirectly. Here, indirect combination of a part or all of a primitive roll with another roll means, for example, that a part of a band of a path roll using a part of a band of a data line roll which is a primitive roll is assigned to another roll. Equivalent to combining.

  In this manner, based on the primitive roll, a new roll can be stacked by combining a part of the functions provided by the roll. The flow is shown in FIG. There is a basic roll at the bottom. A new role can be defined by combining each divided role, considering a divided role obtained by dividing the functions provided by the basic role independently of each other. The new role becomes the next repeating base role. In the example of FIG. 12, the basic roll includes a switch roll and a data line roll, a part of the switch roll forwarding setting is a split roll, and a part of the band of the data line roll is a split roll. By combining these divided rolls, a path roll can be constructed as a new roll.

  In this embodiment, a management engine system is constructed based on this concept.

[Management engine system configuration example]
FIG. 14 shows an example of the overall configuration of the management engine system 210 according to this embodiment. As illustrated in FIG. 14, the management engine system 210 according to the present embodiment includes an external relay unit 211, a role matching unit 212, a resource management unit 213, and a role generation tool 214. The resource management unit 213 of the management engine system 210 is connected to a physical entity (communication device, transmission path, etc.) of the network via an OpenFlow Controller, an EMS, or the like. The external relay unit 211 is connected to a user terminal or another management system.

  Hereinafter, each module of the management engine system 210 will be described.

<Resource Management Department>
The resource management unit 213 is a functional unit that manages a physical entity as a primitive role and provides an interface of the primitive role to the role matching unit 212. More specifically, it has the following functions.

  (1) The resource management unit 213 connects to the physical entity, raises monitoring information from the physical entity to the role matching unit 212, and passes a control command from the role matching unit 212 to the physical entity.

  (2) A physical entity is internally represented as a primitive role, and an interface of the primitive role is provided to the role matching unit 212.

  (3) The resource management unit 213 manages the relationship between the defined primitive role and the physical entity. For example, the relationship between the primitive role identification information and the physical entity identification information is stored in the database in association with each other.

  Based on the above relationship, the resource management unit 213 converts the control request from the role matching unit 212 into a control command to the physical entity. Also, the event from the physical entity is notified to the role matching unit 212 via the primitive role interface. At this time, information that does not need to be sent to the roll matching unit 212 is processed in the primitive roll, and is hidden in the roll matching unit 212. In addition, it is assumed that an external system is used as internal processing of the primitive role as necessary. For example, requesting an external dedicated system for log analysis of a physical entity.

<Role definition document>
Next, the role definition document 215 input to the role generation tool 214 will be described. The role definition document 215 is a definition document that defines a role. The role definition document 215 defines the resources to which the role is related and the relationship between the roles. As described above, the ontology language (OWL in this embodiment) is defined. ) To describe the role definition document 215. The definition document contains at least the following information.

-Role name-Role attribute information-Instructions that can be executed for the role-Role constraint conditions-Event information related to the role-Other <Role generation tool>
The roll generation tool 214 corresponds to the roll generation apparatus 100 described above, and generates a roll component from a roll definition document described using an ontology. One role component is generated for one role definition.

<Roll alignment unit>
The role matching unit 212 instantiates the role component created by the role generation tool 214, operates the role component, and automatically manages the relationship between the role instances. It also distributes events between role components and dynamically adds and deletes role components.

  Further, the role matching unit 212 controls the primitive role of the resource management unit 213 via the primitive role interface as necessary (for example, according to an instruction to the role from the outside), and sends it to the external relay unit 211. Provides an interface for roles.

  FIG. 15 shows a configuration example in the roll matching unit 212. The roll matching unit 212 will be described in more detail with reference to FIG. In the example illustrated in FIG. 15, the roll matching unit 212 includes a roll matching unit framework 221, a roll component A, roll objects A1 and A2, a roll component B, and roll objects B1 and B2.

  The roll components A and B (programs) generated by the roll generation tool 214 are stored in the storage means in the roll matching unit 212, and the roll components A and B are read from the storage means and are read by the roll matching unit framework 221. It is instantiated and works. The roll components A and B correspond to factories for creating and deleting roll objects, and one or a plurality of roll objects are created for one roll component. In the example of FIG. 15, it is shown that roll objects A1 and A2 are generated from the roll component A, and roll objects B1 and B2 are generated from the roll component B. Each role object here is an instance representation of a role, which may be referred to as a managed object.

  The role matching unit framework 221 instantiates and operates the roll component as described above, and mediates information transmission between the roll components. The method for realizing the role matching unit framework 221 is not limited to a specific method, but for example, the OSGi framework can be used as the role matching unit framework 221, and in this case, the roll component can be realized using an OSGi bundle.

  Each role component has a function of ensuring consistency of data of role objects. In order to ensure consistency, the role component performs an operation of confirming information of other related role components.

  Since it has the function of ensuring consistency in this way, for example, even if the same physical entity is expressed by different roles and the different roles are used by different external systems, the consistency of information can be guaranteed. As specific processing operations for ensuring consistency, for example, there is an external processing request for a role representing a physical entity, and the value is changed to a value (such as a network resource allocation value) in the physical entity. When there is, there is an operation such as reflecting the change of this value to another role expressing the same physical entity.

<External relay section>
The external relay unit 211 uses the role interface provided from the role matching unit 212 to mediate with other management systems and to express the role to the operator using a GUI. That is, the external relay unit 211 is a module that converts the role expression in the role matching unit 212 into a protocol of another management system or expresses it with a GUI.

  When the management engine system winds up an existing network service, the external relay unit 211 connects to the old management system to realize migration. When providing a customer control function of the network to the user, the external relay unit 211 constructs an interface for the user.

  The management engine system 210 according to the present embodiment can be realized by causing one or a plurality of computers to execute a program corresponding to each module. That is, the management engine system 210 executes a desired process while causing a computer to execute a program corresponding to the function of each unit, and repeatedly storing / reading data in / from the memory and processing by the CPU. In addition, the instantiated roll component operates in accordance with the implementation content of the roll component. This operation is also executed while repeatedly storing / reading data in / from the memory and processing by the CPU.

  The above-mentioned program can be recorded on a computer-readable recording medium (portable memory or the like), stored, or distributed. It is also possible to provide the program through a network such as the Internet or electronic mail.

  Note that the role generation tool 214 may be placed outside the management engine system 210, and the role component generated by the role generation tool 214 may be stored in the management engine system 210 from the outside and used.

  In the management engine system 210 as described above, a trail role component is generated from a role definition document (for example, a trail definition document) written in an ontology language, and the generated trail role is generated in the role matching unit 212. Exists as a roll object. The role of the trail receives an event from the physical entity corresponding to the role of the trail from the resource management unit 213, or receives a command from the external relay unit 211 and returns a response (for example, the connection configuration or the current free space ) Is performed. Network management is realized by each role performing such processing under information consistency management.

(Summary of the embodiment, effects)
In the embodiment of the present invention, since the ontology is applied to the role definition document that defines each role in the role hierarchy model of the network, it is possible to create a role definition document that appropriately represents the relationship between roles, and as a result, It is possible to quickly generate a roll component.

  That is, in the prior art shown in Non-Patent Document 2, it is difficult to organize the relationship between roles, and since there was no appropriate method for expressing the relationship between roles, the relationship between roles could not be expressed. In the present embodiment, an ontology, which is an expression method of a vocabulary system different from software technology, is applied to solve this problem and to quickly generate a roll component.

  In addition, according to the present embodiment, a technique for generating a software component from a role definition document described in an ontology is provided. In this embodiment, an example related to network management is mainly described. However, since the ontology OWL is a standardized notation method, a mechanism for generating software components from the OWL is not limited to network management and can be applied.

  The present invention is not limited to the above-described embodiments, and various modifications and applications are possible within the scope of the claims.

DESCRIPTION OF SYMBOLS 10 Roll component 11 Property part 12 Behavior code part 15 Property part shelf 16 Automatic generation code part 17 Factory part 18 Interface definition 30 Role definition document 100 Roll generation apparatus 110 Roll definition document input part 120 Roll definition document storage part 130 Interface definition generation part 140 Property usage code generation unit 150 Created program storage unit 160 Roll component generation / output unit 210 Management engine system 211 External relay unit 212 Role matching unit 213 Resource management unit 214 Role generation tool 221 Role matching unit framework

Claims (8)

A software component generation device that generates a software component from a role definition document described using an ontology,
Property part storage means storing property parts which are property codes indicating the relationship between roles;
Code for generating an interface definition of an object generated by the software component, and code for using a property part of a property described in the role definition document;
Software that acquires a property part of the property described in the role definition document from the property part storage unit, generates a software component including the property part and the code generated by the code generation unit, and outputs the software component A software component generation apparatus comprising: a component generation / output unit. The property described in the role definition document is a property representing attribute information of the target role, a property representing an operation provided by the role to the outside, or a property representing a constraint condition for the role to exist. The software component generation apparatus according to claim 1, wherein the software component generation apparatus is a software component generation apparatus. The software component generation apparatus according to claim 1, wherein the role definition document is described using a web ontology language (OWL) as the ontology language. A management engine system comprising the software component generation device according to any one of claims 1 to 3 and constructing a network management system using a roll component that is a software component generated by the software component generation device. And
The role defined in the role definition document is a role expressing a management object of the network,
Storage means for storing the role component generated from the role definition document;
A management engine system comprising: means for operating the roll component read from the storage means, and causing the roll component to generate a roll object corresponding to the management object. Resource management means for connecting to the physical entity, having a primitive role corresponding to the physical entity, and providing an interface of the primitive role;
The management engine system according to claim 4, further comprising: an external relay unit that provides role information to the outside using the role object interface. A software component generation method executed by a software component generation apparatus that generates a software component from a role definition document described using an ontology,
A code generation step of generating a code for using an interface definition of an object generated by the software component and a property part of a property described in the role definition document;
The property part of the property described in the role definition document is acquired from the property part storage means storing the property part that is the property code indicating the relationship between roles, and is generated by the property part and the code generation step. A software component generation method comprising: a software component generation / output step for generating and outputting a software component including the generated code. The property described in the role definition document is a property representing attribute information of the target role, a property representing an operation provided by the role to the outside, or a property representing a constraint condition for the role to exist. The software component generation method according to claim 6, wherein: The software component generation method according to claim 6 or 7, wherein the role definition document is described using a web ontology language (OWL) as the ontology language.

Images