KR20060088411A - 대표구현객체를 이용한 형상 관리 시스템 및 그 방법 - Google Patents

대표구현객체를 이용한 형상 관리 시스템 및 그 방법 Download PDF

Info

Publication number
KR20060088411A
KR20060088411A KR1020050009290A KR20050009290A KR20060088411A KR 20060088411 A KR20060088411 A KR 20060088411A KR 1020050009290 A KR1020050009290 A KR 1020050009290A KR 20050009290 A KR20050009290 A KR 20050009290A KR 20060088411 A KR20060088411 A KR 20060088411A
Authority
KR
South Korea
Prior art keywords
information
agent
representative implementation
manager
stored
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
KR1020050009290A
Other languages
English (en)
Other versions
KR100624477B1 (ko
Inventor
임용식
Original Assignee
삼성전자주식회사
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
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR1020050009290A priority Critical patent/KR100624477B1/ko
Priority to US11/270,446 priority patent/US20060173907A1/en
Priority to CNA200510129648XA priority patent/CN1815978A/zh
Priority to EP05027875A priority patent/EP1686725A1/en
Publication of KR20060088411A publication Critical patent/KR20060088411A/ko
Application granted granted Critical
Publication of KR100624477B1 publication Critical patent/KR100624477B1/ko
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • A—HUMAN NECESSITIES
    • A47—FURNITURE; DOMESTIC ARTICLES OR APPLIANCES; COFFEE MILLS; SPICE MILLS; SUCTION CLEANERS IN GENERAL
    • A47K—SANITARY EQUIPMENT NOT OTHERWISE PROVIDED FOR; TOILET ACCESSORIES
    • A47K10/00—Body-drying implements; Toilet paper; Holders therefor
    • A47K10/02—Towels
    • 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/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B82—NANOTECHNOLOGY
    • B82Y—SPECIFIC USES OR APPLICATIONS OF NANOSTRUCTURES; MEASUREMENT OR ANALYSIS OF NANOSTRUCTURES; MANUFACTURE OR TREATMENT OF NANOSTRUCTURES
    • B82Y30/00—Nanotechnology for materials or surface science, e.g. nanocomposites
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B82—NANOTECHNOLOGY
    • B82Y—SPECIFIC USES OR APPLICATIONS OF NANOSTRUCTURES; MEASUREMENT OR ANALYSIS OF NANOSTRUCTURES; MANUFACTURE OR TREATMENT OF NANOSTRUCTURES
    • B82Y40/00—Manufacture or treatment of nanostructures
    • D—TEXTILES; PAPER
    • D06—TREATMENT OF TEXTILES OR THE LIKE; LAUNDERING; FLEXIBLE MATERIALS NOT OTHERWISE PROVIDED FOR
    • D06M—TREATMENT, NOT PROVIDED FOR ELSEWHERE IN CLASS D06, OF FIBRES, THREADS, YARNS, FABRICS, FEATHERS OR FIBROUS GOODS MADE FROM SUCH MATERIALS
    • D06M11/00—Treating fibres, threads, yarns, fabrics or fibrous goods made from such materials, with inorganic substances or complexes thereof; Such treatment combined with mechanical treatment, e.g. mercerising
    • D06M11/32—Treating fibres, threads, yarns, fabrics or fibrous goods made from such materials, with inorganic substances or complexes thereof; Such treatment combined with mechanical treatment, e.g. mercerising with oxygen, ozone, ozonides, oxides, hydroxides or percompounds; Salts derived from anions with an amphoteric element-oxygen bond
    • D06M11/36—Treating fibres, threads, yarns, fabrics or fibrous goods made from such materials, with inorganic substances or complexes thereof; Such treatment combined with mechanical treatment, e.g. mercerising with oxygen, ozone, ozonides, oxides, hydroxides or percompounds; Salts derived from anions with an amphoteric element-oxygen bond with oxides, hydroxides or mixed oxides; with salts derived from anions with an amphoteric element-oxygen bond
    • D06M11/46—Oxides or hydroxides of elements of Groups 4 or 14 of the Periodic Table; Titanates; Zirconates; Stannates; Plumbates
    • 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/04—Network management architectures or arrangements
    • H04L41/046—Network management architectures or arrangements comprising network management agents or mobile agents therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Chemical & Material Sciences (AREA)
  • Nanotechnology (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Condensed Matter Physics & Semiconductors (AREA)
  • Crystallography & Structural Chemistry (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Materials Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Textile Engineering (AREA)
  • Manufacturing & Machinery (AREA)
  • Composite Materials (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 대표구현객체(representative object instance)를 통해 미등록 구현 객체(unregistered object instance)에 대한 정보를 호출하는 방식을 구현하여 구체적으로 노드를 관리(생성/삭제/변경/검색)하기 위한 대표구현객체를 이용한 형상 관리 시스템 및 그 방법에 관한 것으로, 본 발명에 따르면, 관리대상 시스템의 초기화시 시스템 형상에 대한 초기화 정보를 객체 정보로 저장하고 상기 객체 정보를 대표하는 대표구현객체를 생성하여 망관리 시스템의 매니저로부터 객체 호출이 발생하는 경우 상기 대표구현객체를 통해 호출된 객체에 대한 커맨드를 수행하여 그 결과값을 상기 망관리 시스템의 매니저로 전달하는 에이전트를 포함한다.
코바, 에이전트, 매니저, 대표구현객체, 네이밍 서비스, EMS

Description

대표구현객체를 이용한 형상 관리 시스템 및 그 방법{CONFIGURATION MANAGEMENT SYSTEM AND METHOD USING REPRESENTATIVE OBJECT INSTANCES}
도 1은 망관리 표준에 의해 네이밍 서비스에 등록된 구현객체에 대한 GET operation의 일예를 나타내는 도면.
도 2는 망관리 표준에 의해 네이밍 서비스에 등록된 구현객체에 대한 SET operation의 일예를 나타내는 도면.
도 3은 망관리 표준에 의해 네이밍 서비스에 등록되지 않은 구현객체에 대한 GET operation의 일예를 나타내는 도면.
도 4는 망관리 표준에 의해 네이밍 서비스에 등록되지 않은 구현객체의 SET operation에 대한 일예를 나타내는 도면.
도 5는 본 발명에 따른 CORBA 에이전트와 실제 망 구성 요소들과의 구성에 대한 일예를 나타내는 도면.
도 6은 본 발명에 따른 형상 초기화 파일의 구성예를 나타내는 도면.
도 7은 본 발명에 따른 DB 테이블의 구조를 정의한 도면.
도 8은 본 발명에 따른 해쉬 테이블의 구조를 정의한 도면.
도 9는 본 발명에 따른 대표구현객체 EquipmentR1 클래스의 Attribute를 정 의한 도면.
도 10은 본 발명에 따른 대표구현객체 EquipmentR1 클래스의 Method를 정의한 도면.
도 11은 본 발명에 따른 대표구현객체 EquipmentR1 클래스의 Attribute Value Type을 정의한 도면.
도 12는 본 발명에 따른 대표구현객체 EquipmentHolder 클래스의 Attribute를 정의한 도면.
도 13은 본 발명에 따른 대표구현객체 CircuitPack 클래스의 Attribute를 정의한 도면.
도 14는 본 발명에 따른 초기화 과정을 나타내는 도면.
도 15는 초기화 정보의 포함관계를 나타내는 도면.
도 16은 초기화 파일에서 라인별로 얻은 개별 노드 정보를 받아 노드 종류별 구성 데이터로 구분하여 리스트 형태로 저장하는 과정을 설명한 도면.
도 17은 본 발명에 따른 구현객체의 GET operation을 나타내는 도면.
도 18은 본 발명에 따른 구현객체의 SET operation을 나타내는 도면.
도 19 내지 도 20은 본 발명에 따른 GET operation 수행 과정을 나타내는 흐름도.
도 21 내지 도 22은 본 발명에 따른 SET operation 수행 과정을 나타내는 흐름도.
도 23은 본 발명에 따른 해쉬 테이블의 조회시의 과정을 나타내는 흐름도.
도 24 및 도 25는 본 발명에 따른 해쉬 넘버를 생성하는 과정을 나타내는 흐름도.
도 26은 본 발명에 따른 해쉬 테이블의 추가시의 과정을 나타내는 흐름도.
* 도면의 주요 부분에 대한 부호의 설명 *
10 : 망관리 시스템 11 : 코바 매니저
12 : 응용 프로그램 13 : stub
20 : 코바 에이전트 21 : 미등록객체 DB
22 : 응용 프로그램 23 : 대표구현객체
24 : 시스템 인터페이스 25 : skeleton
30 : 관리대상 시스템 40 : EMS
50 : 통지 서비스 60 : 네이밍 서비스
본 발명은 대표구현객체를 이용한 형상 관리 시스템 및 그 방법에 관한 것으로, 보다 상세하게는 대표구현객체(representative object instance)를 통해 미등록 구현 객체(unregistered object instance)에 대한 정보를 호출하는 방식을 구현하여 구체적으로 노드를 관리(생성/삭제/변경/검색)하기 위한 시스템 및 그 방법에 관한 것이다.
코바(Common Object Request Broker Architecture: 이하, "CORBA" 라 칭함)는 분산 객체 컴퓨팅을 위해 OMG(Object Management Group)에서 제정한 표준 스펙으로, CORBA를 사용하는 경우에 분산 컴퓨팅을 위한 응용 프로그램 개발이 쉬워질 뿐만 아니라, 하드웨어와 운용체계, 프로그래밍 언어와 무관하게 분산 객체들간에 커뮤니케이션이 이루어진다. CORBA는 어떠한 언어로 구성되어 있건 간에 클라이언트와 서버는 서로 커뮤니케이션을 할 수 있다.
이와 같은 CORBA의 등장으로 객체(Object)간 직접 호출 및 데이터 전송이 가능하게 되었다. CORBA 개념에서 객체간 호출을 위해서는 각각의 컴퓨터가 읽을 수 있고 상호 운용할 수 있는 객체 레퍼런스(Interoperable Object Reference, IOR)를 만들어서 공유하거나, 네이밍 서비스(Naming Service)와 같은 CORBA Service를 통한 등록 과정을 거친 후에 해당 인스턴스를 호출할 수 있다.
네트워크 상에서 망을 관리하기 위해서 관리객체(Managed Object) 표준을 정의하고 있는데, 모든 객체를 객체 레퍼런스(IOR)나, 네이밍 서비스(Naming Service)에 등록하지는 않기 때문에 이 관리객체 중 일부는 직접 호출하지 않거나, 직접 호출할 수 없는 경우가 발생할 수 있다. 특히 형상 관리객체의 경우에는 다수의 시스템 노드 정보를 가지고 있으며, 시스템 노드와 각 시스템별 하부 요소 노드(예:형상 정보)가 실시간으로 추가/삭제/변경되는 경우가 있기 때문에 이러한 경우에 해당할 수 있다. 또한, 객체간 호출시 범위(scope)와 필터(filter) 조건이 주어지는 경우에는 더더욱 직접 호출 방식을 사용할 수 없게 된다.
현재 운용중인 망관리 시스템(NMS : Network Management System)은 상위 매니저(MANAGER)가 중간에 에이전트(AGENT)라는 대리자를 통해 관리 대상 시스템(예: 유무선 시스템)의 자원에 대한 정보를 가져오고, 필요시 에이전트를 통해 시스템으로 명령을 내리기도 하고 시스템에서 올라오는 각종 메시지를 에이전트를 통해 수신하는 구조로 되어 있다. 이러한 기능을 수행하기 위해 에이전트는 시스템의 구성, 장애, 연결, 통계 등 물리적/논리적 정보를 관리 객체(Managed Object)라는 개념으로 형상화해서 관리하고 있다. 각종 데이터의 전송을 위해 매니저(MANAGER)와 에이전트(AGENT) 사이에는 여러가지 프로토콜을 통한 통신방식(CMIP, CORBA, SNMP 등)이 사용된다. 이중 CORBA 환경에서 구동되는 에이전트에서는 네트워크 상에서 관리가 요구되는 대상을 CORBA 표준에 따라 객체화하고 매니저(MANAGER)와 ORB단에서 객체간 통신을 통해 데이터를 전송하게 된다.
일반적인 CORBA 개념에 따라 표준에 정의된 구현객체(instance)의 GET/SET operation은 다음과 같이 구현될 수 있다.
도 1은 망관리 표준(3GPP)에 의해 네이밍 서비스(Naming Service)에 등록된 구현객체(instance)에 대한 GET operation의 일예를 나타내는 도면이다.
도 1에 도시된 바와 같이, 분리된 두개의 장비에 각각 매니저(1)와 에이전트(2)가 CORBA platform 내에서 구현이 되면, 매니저(1)는 ORB를 통해서 실제 관리객체가 구현된 에이전트(2)의 구현객체(instance)에 접근하여 해당 정보를 얻거나 매쏘드(method)를 수행할 수 있게 된다. 이 경우, 모든 객체는 생성시에 네이밍 서비스(Naming Service, 2)에 등록이 되어 있어야 하며, 에이전트(2)는 CORBA Object Adaptor (예: POA(Portable Object Adaptor) 또는 BOA(Basic Object Adaptor))를 통해 객체별 고유한 id를 부여하고 이를 관리한다. 그리고, object instances' pool 이라 함은 이와 같이 구현과 동시에 등록이 되어 있는 구현객체를 말한다.
즉, 먼저 에이전트(2)는 구현객체를 생성(S1)한 다음 네이밍 서비스(3)에 접속(S2)하여 클래스 네임들을 등록(S3)한다. 이어서, 매니저(1)는 네이밍 서비스(3)에 접속(S4)하여 등록된 클래스 네임들에 대한 요청(S5)을 하게 되면 네이밍 서비스(3)는 등록된 클래스 네임을 매니저(1)로 전달(S6)하게 된다.
이어서, 매니저(1)는 에이전트(2)로 구현객체의 레퍼런스를 호출(S7)하게 되면 에이전트(2)는 호출된 구현객체의 레퍼런스를 매니저(1)로 전달(S8)하게 됨으로써 매니저(1)는 에이전트(2)로 구현객체의 구성 요소들(attributes)에 대한 GET Operation을 수행하게 된다(S9).
도 2는 망관리 표준(3GPP)에 의해 네이밍 서비스(Naming Service)에 등록된 구현객체(instance)에 대한 SET operation의 일예를 나타내는 도면이다.
도 2에 도시된 바와 같이, 에이전트(2)는 구현객체를 생성(S1)한 다음 네이밍 서비스(3)에 접속(S2)하여 클래스 네임들을 등록(S3)한다. 이어서, 매니저(1)는 네이밍 서비스(3)에 접속(S4)하여 등록된 클래스 네임들에 대한 요청(S5)을 하게 되면 네이밍 서비스(3)는 등록된 클래스 네임을 매니저(1)로 전달(S6)하게 된다.
이어서, 매니저(1)는 에이전트(2)로 구현객체의 레퍼런스를 호출(S7)하게 되면 에이전트(2)는 호출된 구현객체의 레퍼런스를 매니저(1)로 전달(S8)하게 된다. 이에 따라, 매니저(1)는 에이전트(2)로 구현객체의 요소들(attributes)의 변경을 요청(S9)하게 되면 에이전트(2)에서는 요소들(attributes)의 값(value)을 변경(S10)하고 변경된 요소들(attributes)의 값(value)을 상기 매니저(1)로 보내게 된다(S11).
도 3은 망관리 표준(3GPP)에 의해 네이밍 서비스(Naming Service)에 등록되지 않은 구현객체(instance)에 대한 GET operation의 일예를 나타내는 도면이다.
도 3에 도시된 바와 같이, 에이전트(2)는 표준(3GPP)에서 정의(BasicCmIRPSystem.idl)한 BasicCmIrpOperations 객체를 구현하고, 매니저(1)에서 이 객체의 참조값(reference)를 가져온 후 find_managed_objects, modify_managed_objects 메소드(method)를 호출하면 에이전트(2)가 BasicCmInformationIterator를 생성한 후 여기에 해당 결과값을 저장하면 매니저(1)가 다시 이 객체의 참조값을 가져가는 구조이다.
즉, 에이전트(2)는 BasicCmIrpOperations 객체를 생성(S1)하여 네이밍 서비스에 등록(S2)한다. 이어서, 매니저(1)는 에이전트(2)로 BasicCmIrpOperations 객체의 레퍼런스를 호출(S3)하게 되면 에이전트(2)에서는 BasicCmIrpOperations 객체의 레퍼런스를 매니저(1)로 전달(S4)하게 된다.
이어서, 매니저(1)가 에이전트(2)로 BasicCmIrpOperations 객체에서 정의된 find_managed_objects를 호출(S5)하면 에이전트(2)에서는 BasicCmInformationIterator 객체를 생성(S6)하여 매니저(1)로 BasicCmInformationIterator 객체의 레퍼런스를 전달(S7)한 후 호출된 객체를 찾아 결과값을 저장하게 된다(S8~S9).
이에 따라, 매니저(1)는 에이전트(2)로 BasicCmInformationIterator객체에서 정의된 next_basicCmImformations()를 호출(S10)하게 되면 에이전트(2)에서는 저장된 GET 결과값을 매니저(1)로 전달(S11)하게 된다. 이어서, 매니저(1)는 에이전트(2)로 BasicCmInformationIterator 객체에서 정의된 destroy()를 호출(S12)하게 되면 에이전트(2)에서는 BasicCmInformationIterator 객체를 삭제(S13)하게 된다.
도 4는 망관리 표준(3GPP)에 의해 네이밍 서비스(Naming Service)에 등록되지 않은 구현객체(instance)의 SET operation에 대한 일예를 나타내는 도면이다.
도 4에 도시된 바와 같이, 에이전트(2)는 BasicCmIrpOperations 객체를 생성(S1)하여 네이밍 서비스에 등록(S2)한다. 이어서, 매니저(1)는 에이전트(2)로 BasicCmIrpOperations 객체의 레퍼런스를 호출(S3)하게 되면 에이전트(2)에서는 BasicCmIrpOperations 객체의 레퍼런스를 매니저(1)로 전달(S4)하게 된다.
이어서, 매니저(1)가 에이전트(2)로 BasicCmIrpOperations 객체에서 정의된 modify_managed_objects를 호출(S5)하면 에이전트(2)에서는 BasicCmInformationIterator 객체와 ModifyResultIterator 객체를 생성(S6~S7)하여 매니저(1)로 BasicCmInformationIterator 객체와 ModifyResultIterator 객체의 레퍼런스를 전달(S8~S9)한 후 호출된 객체를 찾아 요소값(attribute value)을 변경하여 변경된 결과값을 저장하게 된다(S10~S12). 이어서, 에이전트(2)는 매니저(1)로 변경된 요소값(attribute value)을 전달(S13)하게 된다.
이에 따라, 매니저(1)는 에이전트(2)로 BasicCmInformationIterator에서 정의된 next_basicCmImformations()를 호출(S14)하게 되면 에이전트(2)에서는 저장된 결과값을 매니저(1)로 전달(S15)하게 된다.
이어서, 매니저(1)는 에이전트(2)로 ModifyResultIterator에서 정의된 next_modificationErrors()를 호출(S16)하게 되면 에이전트(2)에서는 저장된 에러 결과값을 매니저(1)로 전달(S17)하게 된다.
이어서, 매니저(1)는 에이전트(2)로 BasicCmInformationIterator에서 정의된 destroy()를 호출(S18)하게 되면 에이전트(2)에서는 BasicCmInformationIterator를 삭제(S19)하게 된다.
이어서, 매니저(1)는 에이전트(2)로 ModifyResultIterator에서 정의된 destroy()를 호출(S20)하게 되면 에이전트(2)에서는 ModifyResultIterator를 삭제(S21)하게 된다.
이와 같이, CORBA 환경에서 이기종간에 상대편 구현객체(instance)에 직접 접근하기 위해서는 해당 구현객체에 대한 정보(reference value, name, etc)를 IOR 파일이나 CORBA Naming Service에 등록하는 과정이 필요하다. 하지만 구현객체의 수가 많은 경우 혹은 구현객체가 수시로 추가/삭제 등으로 변경되는 경우에는 이 모든 구현객체 정보를 등록하고 각각 호출하는 데에는 어려움이 있다.
이에 따라, 표준(3GPP TS 32.603)에서는 BasicCmIrpOperations 라는 객체를 정의해 모든 구현객체 정보를 얻어오는 방식을 제시하고 있지만, 이러한 방식은 모든 호출이 BasicCmIrpOperations 을 통해 이루어져야 하고, 동시에 여러 개의 호출 명령을 받는 경우 순차적으로 처리된다는 단점이 있다.
상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, 대표구현객체(representative object instance)를 통해 미등록 구현 객체(unregistered object instance)에 대한 정보를 호출하는 방식을 구현하여 구체적으로 노드를 관리할 수 있도록 한 대표구현객체를 이용한 형상 관리 시스템 및 그 방법을 제공함에 있다.
상기한 목적을 달성하기 위한 본 발명에 따른 대표구현객체를 이용한 형상 관리 시스템의 일 측면에 따르면, 관리대상 시스템의 초기화시 시스템 형상에 대한 초기화 정보를 객체 정보로 저장하고 상기 객체 정보를 대표하는 대표구현객체를 생성하여 망관리 시스템의 매니저로부터 객체 호출이 발생하는 경우 상기 대표구현객체를 통해 호출된 객체에 대한 커맨드를 수행하여 그 결과값을 상기 망관리 시스템의 매니저로 전달하는 에이전트를 포함한다.
상기 에이전트는 객체간 통신을 위한 네이밍 서비스에 등록되지 않은 미등록 객체 정보를 저장하는 미등록 객체 DB와, 상기 망관리 시스템의 매니저부터 객체 호출이 발생하는 경우 상기 대표구현객체를 통해 상기 미등록 객체 DB에 접근하여 호출된 객체에 대한 커맨드를 수행하는 응용프로그램부와, 상기 관리대상 시스템과의 인터페이스 작용을 위한 시스템 인터페이스부를 포함한다.
상기 응용프로그램부는 인터페이스 정의 언어(IDL)를 통해 정의된 객체간 관계나 동작을 실제로 구현한 사용자 프로그램이다.
상기 미등록 객체 DB에 저장되는 미등록 객체 정보는 구조적 데이터 리스트(structured linked list) 형태로 저장된다.
상기 미등록 객체 정보 중 형상 정보는 Mo_Node에 저장되고, 상기 형상 정보에 대한 각각의 속성 정보는 Mo_Attributes에 저장된다.
상기 초기화 정보는 System 정보와, Rack 정보와, Shelf 정보와, Slot 정보와, Board 정보 중 적어도 어느 하나의 정보를 포함한다.
상기 System 정보는 EquipmentR1 클래스로 정의된 속성(attribute) 정보에 맞춰서 상기 미등록 객체 DB에 저장된다.
상기 Rack 정보와, Shelf 정보와, Slot 정보는 EquipmentHolder 클래스로 정의된 속성(attribute) 정보에 맞춰서 상기 미등록 객체 DB에 저장된다.
상기 Board 정보는 CircuitPack 클래스로 정의된 속성(attribute) 정보에 맞춰서 상기 미등록 객체 DB에 저장된다.
상기 에이전트는 상기 망관리 시스템의 매니저로부터 객체 정보에 대한 GET operation 커맨드를 수신하는 경우, 대표구현객체를 통해 상기 미등록 객체 DB를 검색하여 호출된 객체의 검색 결과 정보를 상기 망관리 시스템의 매니저로 전송한다.
상기 에이전트는 상기 미등록 객체 DB로부터 검색된 객체의 결과 정보를 해쉬 테이블에 추가로 등록한다.
상기 에이전트는 상기 망관리 시스템의 매니저로부터 객체 정보에 대한 SET operation 커맨드를 수신하는 경우, 대표구현객체를 통해 상기 미등록 객체 DB를 검색하여 호출된 객체에 대한 정보를 변경하고 결과 정보를 상기 망관리 시스템의 매니저로 전송한다.
상기 에이전트는 상기 미등록 객체 DB로부터 검색되어 변경된 객체의 결과 정보를 해쉬 테이블에 추가로 등록한다.
상기 해쉬 테이블에 등록되는 정보는 구조적 데이터 리스트(structured linked list) 형태로 저장되어진다.
상기 에이전트는 상기 관리대상 시스템에서 장애나 상태변경이 발생하는 경우 해당 객체에 대한 정보를 변경하고 변경된 정보를 이벤트(event)를 통해 상기 망관리 시스템의 매니저에게 전송하게 된다.
상기 에이전트는 operation 커맨드 수행시 DN 정보에 맞게 검색된 구현객체 중 상기 매니저로부터 요구되는 필터 조건을 만족하는 것을 구하게 된다.
상기 필터 조건은 산술 조건, 비교 조건, 포함관계 조건 중 적어도 어느 하나의 조건을 포함한다.
상기 에이전트는 operation 커맨드 수행시 scope 정보에 따라 검색할 범위를 지정하고 대표구현객체를 정해서 명령을 내리게 된다.
상기 scope 정보는 타입(type) 정보와, 레벨(level) 정보 중 적어도 어느 하나의 정보를 포함한다.
한편, 상기한 목적을 달성하기 위한 본 발명에 따른 대표구현객체를 이용한 형상 관리 방법의 일 측면에 따르면, 관리대상 시스템 형상에 대한 초기화 정보를 객체 정보로 저장하는 과정과, 상기 객체 정보를 대표하는 대표구현객체를 생성하는 과정과, 객체 호출이 발생하는 경우 상기 대표구현객체를 통해 호출된 객체에 대한 커맨드에 따라 그 결과값을 전달하는 과정을 포함한다.
상기 대표구현객체를 통해 호출된 객체에 대한 커맨드가 GET 커맨드인 경우, GET 결과값을 전달하게 된다.
상기 GET 결과값을 전달하는 과정은, 상기 대표구현객체와 관련된 객체를 조회하는 과정과, 상기 조회된 객체의 GET 결과값을 저장하는 과정과, 상기 조회된 객체의 GET 결과값을 전달하는 과정으로 이루어진다.
상기 조회된 객체의 GET 결과값을 전달한 후 조회된 객체 정보를 해쉬 테이블에 추가하게 된다.
상기 대표구현객체를 통해 호출된 객체에 대한 커맨드가 SET 커맨드인 경우, SET 결과값을 전달하는 과정을 포함한다.
상기 SET 결과값을 전달하는 과정은 상기 대표구현객체와 관련된 객체를 조회하는 과정과, 상기 조회된 객체의 속성값(attribute value)을 변경하는 과정과, 상기 변경된 속성값(attribute value)을 전달하는 과정과, 상기 조회된 객체의 SET 결과값을 전달하는 과정으로 이루어진다.
상기 변경된 속성값(attribute value)을 전달한 후 상기 조회된 객체 정보를 해쉬 테이블에 추가하는 과정을 포함한다.
이하, 본 발명의 바람직한 실시예의 상세한 설명이 첨부된 도면들을 참조하 여 설명될 것이다. 도면들 중 참조번호들 및 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 참조번호들 및 부호들로 나타내고 있음에 유의해야 한다. 하기에서 본 발명을 설명함에 있어, 관련된 공지 기능 또는 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략한다.
도 5는 본 발명에 따른 CORBA 에이전트와 실제 망 구성 요소들(NMS, EMS, WCDMA 시스템, etc)과의 구성에 대한 일예를 나타내는 도면으로서, CORBA platform(stub, skeleton, IOR, ORB, invoke/callback, Naming Service, Notification Service,etc)하에서의 데이터 전송 동작은 일반적인 CORBA Server/Client 구조와 동일하다.
도 5에 도시된 바와 같이, 본 발명은 크게 망관리 시스템(Network Management System: NMS, 10)과, 코바 에이전트(20)와, 관리대상 시스템(30)으로 구성되어진다.
망관리 시스템(10)은 통신 서비스 운용자가 관리하는 통합 망관리 운용 시스템을 의미하는 것으로, 코바 매니저(CORBA MANAGER, 11)와, 응용 프로그램(12)과, 스터브(stub, 13)으로 구성되어진다.
코바 매니저(11)는 망관리 시스템(NMS, 10)과 코바 에이전트(CORBA AGENT, 20) 사이에서 CORBA ORB를 통한 통신을 하기 위한 NMS 어댑터(Adaptor) 기능을 수행한다.
코바 에이전트(CORBA AGENT, 20)는 상기 망관리 시스템(Network Management System: NMS, 10)와 관리대상 시스템(30) 사이에 존재하여 CORBA Server기능과 함께 망관리 구조에서의 에이전트 기능을 수행하게 된다.
즉, 코바 에이전트(CORBA AGENT, 20)는 망관리 시스템(Network Management System: NMS, 10)의 코바 매니저(CORBA MANAGER, 11)와는 CORBA 관련(operation, alarm/status event(or notification), 기타 서비스) 처리를 하고, 하부로는 관리대상 시스템(30)과 연동하게 된다.
특히, 시스템 초기화시에는 각 교환기 시스템의 형상 및 상태 등을 CORBA 객체로 형상화(instance 생성)한 후 코바 매니저(CORBA MANAGER, 21)가 관리할 객체 정보를 네이밍 서비스(Naming Service, 60)를 통해 등록하고, 시스템 운용시에는 망관리 시스템(NMS, 10)의 객체 호출(invoke)를 통해 커맨드(command: get, set, create, delete, etc)를 받아 시스템에 내리게 된다.
또한, 시스템으로부터의 커맨드(command) 결과를 내부 형상화한 객체에 반영하고 이를 망관리 시스템(NMS, 10)에 전달(callback)하게 되며, 변경된 상태(status, alarm, etc)는 이벤트 서비스(Evnet Service)를 통해 상위 망관리 시스템(NMS)로 보고하게 된다.
이와 같은 코바 에이전트(20)는 미등록 객체 DB(21)와, 응용프로그램(Application program, 22)와, 대표구현객체(23)와, 시스템 인터페이스(24)와, 스켈레톤(skeleton, 25)로 구성된다.
미등록 객체 DB(unregistered objects, 21)는 관리하고자 하는 대상에 대한 정보를 객체(object) 형태로 저장(예: unregistered object instances)하고 있다. 즉, CORBA ORB를 통한 객체간 통신을 위해서는 네이밍 서비스(Naming Service, 60) 등에 의해 등록되어야 하나 그렇지 않고 등록에서 제외된 객체들이 저장되어진다.
응용프로그램(Application program, 22)은 인터페이스 정의 언어(Interface Definition Language: IDL) 등을 통해 정의된 객체 및 객체간 관계나 동작 등을 실제 구현(implement)한 사용자 프로그램(user program)이다.
또한, 응용프로그램(Application program, 22)은 상기 망관리 시스템(10)의 코바 매니저(CORBA MANAGER, 11)와 관리객체와의 연결을 위해 대표구현객체(representative object instances, 23)를 두어 코바 매니저(CORBA MANAGER, 11)가 이 객체에 직접 접근할 수 있도록 한다.
시스템 인터페이스(24)는 지역망에서 시스템의 상태를 감시하고 운용하기 위한 이엠에스(Elementary Management System: EMS, 40)를 통해 관리대상이 되는 상기 시스템(예: MSC, SGSN, GGSN, 30)과의 인터페이스 작용을 한다.
스켈레톤(skeleton, 25)과 스터브(stub, 13)는 인터페이스 정의 언어(Interface Definition Language: IDL) 인터페이스에 의해 생성되는 코드(code)로 각각의 애플리케이션(application)단에서 이를 상속받아 객체를 구현하게 된다.
이와 같이, 본 발명의 에이전트(20)는 시스템의 초기화 과정을 통해 현재 시스템의 모든 정보(시스템의 물리적인 구성정보와 논리적인 구성 및 연결 정보)를 가져오게 된다. 즉, 에이전트(20)에서는 초기화 파일 등으로 얻어진 시스템 정보를 CORBA 구현객체(instance)로 구성/관리한다. 이 때, 매니저(11)로부터 직접 호출을 받는 객체의 경우에는 형상화된 객체의 참조(reference)값을 네이밍 서비스(Naming Service, 60) 등을 통해 등록한다. 여기서, 등록에 제외되는 객체 정보는 구조적 데이터 리스트(structured linked list) 형태로 관리(=>DB table)하고 이들을 대표하는 대표구현객체(representative object instance)를 생성하게 된다.
이하, 도 6은 본 발명에 따른 형상 초기화 파일의 구성예를 나타내는 도면이다.
도 6에 도시된 바와 같이, 에이전트는 초기화시 시스템으로부터 교환기 형상에 대한 정보를 파일 형태로 가져오게 된다. 이러한 형상 초기화 파일은 system/Rack/Shelf/Slot 정보로 이루어진다. 여기서, system 정보는 예를 들어, MSC1:3:1:1:0: // elemld:rackCnt:replace:admin:oper 이고, Rack 정보는 Rack0:18:1:1:1: // elemld:shelfCnt:replace:admin:oper 이며, Shelf 정보는 SHELF0:1:1:1:1: // elemld:slotCnt:replace:admin:oper 이며, Slot 정보는 SLOT0:1:1:1:0:SMBA,SBBA// elemld:replace:admin:oper:holdStatus 이며, BOARD 정보는 BOARD0:0:0:1:1:SMBA:NULL:NULL:9:0:NULL:NULL://boardld:rackld:shelfld:slotld:replace:admin:oper:circuitpackType:availState:NULL:NULL:portCnt:protecting:serialNum:fwVer: 이다.
즉, system은 EquipmentR1 class, Rack/Shelf/Slot은 EquipmentHolder class, Board는 CircuitPack class별로 정의되어 있는 구성요소(attribute) 정보에 맞춰서 DB table의 Mo_Attributes 에 저장되게 된다. 상기 각 필드별 형상 초기화 구성 파라메터(parameter)에 대한 설명은 하기의 표 1과 같다.
Field Description
elemId system, rack, shelf, slot별 ID
rack(/shelf/slot)Cnt rack(/shelf/slot) count
replace replaceable 상태
admin admininistrative state
oper operational state
holdStatus holder status
rack(/shelf/slot)Id board의 위치, rack(/shelf/slot)ID
circuitpackType circuitpack type.
availState availability state
portCnt board내 port count
portecting 이중화 상태
serialNum serial number
fwVer firmware version
상기 표 1에서와 같이 elemId는 system, rack, shelf, slot별 ID를 의미하며, rack(/shelf/slot)Cnt는 rack(/shelf/slot) count를 의미한다. 그리고, replace는 replaceable 상태를 의미하고, admin은 admininistrative state를 의미한다. 그리고, oper는 operational state를 의미하고, holdStatus는 holder status를 의미한다. 그리고, rack(/shelf/slot)Id는 board의 위치, rack(/shelf/slot)ID를 의미하고, circuitpackType은 circuitpack type을 의미한다. 그리고, availState는 availability state를 의미하고, portCnt는 board내 port count를 의미한다. 그리고, portecting은 이중화 상태를 의미하고, serialNum은 serial number를 의미한다. 그리고, fwVer은 firmware version를 의미한다.
한편, AGENT에서는 시스템 초기화시와 운용시에 네이밍 서비스(Naming Serviece)에 등록되지 않는 형상 정보 등과 관련된 구현객체는 다음과 같은 구조적 데이터 리스트 형태로 DB 테이블에 저장하게 된다.
도 7은 본 발명에 따른 DB 테이블의 구조를 정의한 도면으로, 에이전트가 시스템 초기화시 DB 테이블에 데이터를 저장하는 방식은 다음과 같다.
형상 정보, 즉, System, Rack, Shelf, Slot, Board 정보는 Mo_Node 에 저장되어지고, 이에 대한 각각의 attribute들은 Mo_Attributes에 linked list 형태(데이터 영역을 할당/세팅 후 그 데이터를 리스트 형태로 차례로 메달아 저장하는 형태)로 저장된다. Mo_Node도 시스템 형상이 여러개로 이루어져 있으므로 linked list 형태로 정보를 저장하게 된다. 그리고, rightP, leftP는 해당 데이터의 좌/우측에 저장된 리스트와의 포인트 관계를 유지하기 위한 정보이다.
Mo_Node의 id 에는 system name, rack name, shelf name, slot name, board name 등의 노드 네임이 저장되어지고, kind 에는 이들 각각의 Id가 저장된다. lockKey는 수정중인 데이터는 다른 곳에서 접근할 수 없도록 하기 위한 flag 용도로 사용하며, attr_cnt는 각각이 가지는 attribute 의 총수를 의미한다.
그리고, attribute라 함은 도 9 내지 도 13(표 5 ~ 표 9) 등에서 정의하고 있는 형상 객체별로 갖고 있는 attribute를 의미하며, 이것들 하나하나를 Mo_Attributes에 저장한다. Mo_Attributes에서 Id는 도 9 내지 도 13의 인터페이스 정의 언어(Interface Definition Language: IDL)에서 정의하고 있는 attribute 이름을 저장하고, valueP에는 각 attribute별 값(초기화 파일에서 읽어들인 값으로 replace, admin, oper 등의 값)을 저장한다. "CORBA::Any" 라는 것은 CORBA에서 정의하고 있는 데이터 타입중 Any 라는 타입을 의미하며, 이 타입은 모든 종류의 데 이터 타입을 표현할 수 있는 데이터 타입이다.
이와 같이, 초기화가 완료된 후 에이전트는 운용중에 매니저의 요구 및 시스템 상태에 따라 다음과 같은 동작을 수행하게 된다.
에이전트는 매너저로부터의 객체 정보에 대한 GET operation을 받아서 호출된 대표구현객체를 통해 해쉬 테이블(hash table)과 DB 테이블을 검색 후 그 결과를 전송하게 된다. 즉, 해쉬 테이블에서 검색되지 않은 경우 DB 테이블을 검색하고 이 내용을 해쉬 테이블에 추가 등록한다.
또한, 에이전트는 매니저로부터의 객체 정보에 대한 SET operation을 받아서 호출된 대표구현객체를 통해 해쉬 테이블과 DB 테이블을 검색 후 해당 객체에 대한 정보를 변경하고 그 결과와 이벤트를 전송한다. 이 경우에도 해쉬 테이블에서 검색되지 않은 경우 DB 테이블을 검색하고 이 내용을 해쉬 테이블에 추가 등록한다.
그리고, 에이전트는 관리하고 있는 시스템에서 장애나 상태변경이 발생하는 경우 해당 객체에 대한 정보를 변경하고, 매니저에게 해당 정보를 EVENT(or Notification)를 통해 전송하게 된다.
그리고, 에이전트는 GET/SET operation 수행시 scope 정보(type, level)에 따라 검색할 범위를 지정하고 대표구현객체를 정해서 명령을 내리게 된다.
그리고, 에이전트는 GET/SET operation 수행시 DN 정보에 맞게 검색된 구현객체중 매니저로부터 요구되는 filter 조건(산술조건, 비교, 포함관계,etc)을 만족하는 것을 구한다.
그리고, 에이전트에서는 GET/SET에 의한 접근(access) 이력이 있는 노드 정 보에 대한 내용을 다음과 같은 구조적 데이터 리스트 형태로 저장하게 된다. 본 발명에서는 이를 해쉬 테이블(hash table)로 명명하였다. 이는 해당 노드에 대한 반복적인 접근시 검색 속도를 향상시키기 위해 해싱 알고리즘(hashing algorithm)을 적용하여 원본 데이터를 해쉬 테이블(hash table) 정보로 매핑시킨 구조이다.
도 8은 본 발명에 따른 해쉬 테이블(hash table)의 구조를 정의한 도면이다.
도 8에 도시된 바와 같이, 해쉬 테이블(hash table)의 구조를 살펴보면, "int number"는 hash number를 나타내며, "DBImpl::Monode *node;"는 노드(node) 정보가 저장된 DB table list point를 나타낸다. 그리고, "bool top_flag"는 가장 최근 등록된 정보에 부여하는 플래그(flag)를 나타낸다.
한편, 본 발명에서 사용하는 대표구현객체(EquipmentR1, EquipmentHolder, CircuitPack)는 표준(ITU-T M.3100, GENERIC NETWORK INFORMATION MODEL)에 정의된 class 이름과 동일하게 정의(ConfigurationNetworkResourcesNRMDefs.idl)하였으며, 내부 정의 attributes는 자체 정의 데이터(StateManagementIRPConstDefs.idl) 및 Method(ConfigurationNetworkResourcesNRMDefs.idl)를 제외한 데이터 타입은 표준(TS 32.623, TS 32.300, etc)을 따른다. 구체적인 내용은 하기의 도 9 내지 도 13을 참조하여 살펴보기로 한다.
도 9는 본 발명에 따른 관리대상 시스템을 형상화한 대표구현객체 EquipmentR1 클래스의 Attribute를 정의(ConfigurationNetworkResourcesNRMDefs.idl)한 도면이다.
도 9에 도시된 바와 같이, EquipmentR1 클래스는 시스템 노드(node)에 대한 정보를 관리하기 위한 대표구현객체로서, 정의된 내용은 크게 Attribute Names과 Attribute Value Type으로 구분되어진다.
도 10은 본 발명에 따른 관리대상 시스템을 형상화한 대표구현객체 EquipmentR1 클래스의 Method를 정의 (ConfigurationNetworkResourcesNRMDefs.idl)한 도면이다.
도 10에 도시된 바와 같이, 매니저로부터 GET이나 SET을 하고자 하는 객체에 대한 접근(access call) 명령이 내려오면, 에이전트는 매니저에게 대표구현객체(EquipmentR1,EquipmentHolder,CircuitPack)에 대한 객체 참조값(reference)를 넘겨주고, 매니저는 객체내에 있는 getAttribute와 setAttribute method를 다시 호출하여 원하는 객체 노드에 대한 정보를 GET 혹은 SET operation을 수행할 수 있게 된다.
이 경우, 매니저는 여러 개의 객체에 대한 네이밍(Naming) 정보나 참조값을 요구하지 않고 대표 객체에 대한 네이밍(Naming) 정보와 참조값만 알고 있으면 되고, 에이전트에서도 대표객체에 대한 구현 및 네이밍 서비스(Naming Serive) 등록만 하면 된다. 위 함수가 호출되어지면 에이전트는 내부 데이터(DB table, hash table) 내에 있는 결과를 검색하여 매니저에게 넘겨주게 된다.
도 11은 본 발명에 따른 관리대상 시스템을 형상화한 대표구현객체 EquipmentR1 클래스의 Attribute Value Type을 정의 (StateManagementIRPConstDefs.idl)한 도면이다.
도 11에 도시된 바와 같이, 에이전트에서 자체 정의한 Attribute에 대한 Value Type을 정의하게 된다.
도 12는 본 발명에 따른 RACK/SHELF/SLOT에 대한 정보를 관리하기 위한 대표구현객체 EquipmentHolder 클래스의 Attribute를 정의(ConfigurationNetworkResourcesNRMDefs.idl)한 도면이다.
도 12에 도시된 바와 같이, EquipmentHolder Class 는 EquipmentR1 Class를 상속받아 getAttribute와 setAttribute 기능을 제공하고, 추가적인 Attribute는 도시된 바와 같이 정의한다. 정의된 내용은 크게 Attribute Names과 Attribute Value Type으로 구분되어진다.
도 13은 본 발명에 따른 Board에 대한 정보를 관리하기 위한 대표구현객체 CircuitPack 클래스의 Attribute를 정의(ConfigurationNetworkResourcesNRMDefs.idl)한 도면이다.
도 13에 도시된 바와 같이, CircuitPack Class 는 EquipmentR1 Class를 상속받아 getAttribute와 setAttribute 기능을 제공하고, 추가적인 Attribute는 도시된 바와 같이 정의한다. 정의된 내용은 크게 Attribute Names과 Attribute Value Type으로 구분되어진다.
한편, 본 발명에서는 scope와 filter 조건이 포함된 GET/SET operation 수행시 구현 방법을 제공한다.
전체 DN이 주어진 instance GET 인 경우나 scope type이 base-only인 경우에는 테이블을 검색하면서 filter 조건 만족 여부 확인 후, 만족하는 구현객체를 바로 return 한다. 주어지는 DN이 전체 DN이 아닌 경우, 즉, scope type이 base-only 가 아닌 경우에는 노드의 종단까지 검색하면서 filter 조건을 만족하는 다수개의 구현객체를 return 한다.
또한, 본 발명에서는 GET/SET 수행 속도를 향상시킨다. 즉, 우선적으로 해싱 룰(hashing rule)을 정해서 저장한 해쉬 테이블(hash table)을 검색한 후 내부 데이터 테이블(DB table)을 검색함으로써 관리객체 검색시 속도 향상을 기대할 수 있다. 내부에서 알람(alarm) 등 상태 반영시에도 검색 테이블로 유용하게 사용할 수 있으며, 특성상 반복적인 GET/SET이 수행될 가능성이 높은 경우에 더 좋은 결과를 얻을 수 있게 된다. 하기의 표 2는 본 발명의 에이전트를 통해 실제 시스템에 적용해 시험한 결과 데이터로서 instance GET 수행시 수행 속도 비교( 단위 : tps(transaction per second) )를 나타낸다.
구성데이터 단일기종내 이기종간
(1)일반 (2)본발명 (3)일반 (4)본발명
SYSTEM(4개) 198.52 252.31 91.76 92.12
RACK(8개) 168.91 248.52 65.58 72.11
SHELF(18개) 160.77 225.10 64.18 71.18
SLOT(429개) 65.47 214.70 56.95 68.68
BOARD(242개) 99.01 200.01 51.96 65.95
상기 표 2에 나타난 바와 같이, 단일기종내에서나 이기종간에 각 구성 데이터에 대한 instance GET 수행 속도가 일반적인 수행 속도에 비해 빠르다는 것을 알 수 있다.
도 14는 본 발명에 따른 초기화 과정을 나타내는 도면이고, 도 15는 초기화 정보의 포함관계(CM Containment Tree)를 나타내는 도면이다.
도 14에 도시된 바와 같이, 에이전트는 구동시 시스템에 초기화 파일을 요청(S10)하여 초기화 파일(Initialization File)을 받는다(S20).
이어서, 에이전트는 초기화 파일 정보 라인을 차례로 읽어 정보를 얻게 되며(S30) 이 정보에서 시스템(System) 정보에 대한 데이터가 존재하는지를 확인(S40)한다. 이때, 시스템 정보가 존재하면 System DB node를 생성하여 System DB node 테이블에 추가(S50)한 후 계속해서 다음 라인을 읽게 된다(S60).
그러나, 더이상 시스템 정보가 존재하지 않는 경우 에이전트는 Rack에 대한 정보가 존재하는지를 확인(S70)하게 된다. 이때 Rack에 대한 정보가 존재하면 Rack DB node를 차례로 생성하여 Rack DB node 테이블에 추가(S80)한 후 계속해서 다음 라인을 읽게 된다(S90).
그러나, 더이상 Rack에 대한 정보가 존재하지 않는 경우 에이전트는 Shelf에 대한 정보가 존재하는지를 확인(S100)하게 된다. 이때 Shelf에 대한 정보가 존재하면 Shelf DB node를 차례로 생성하여 Shelf DB node 테이블에 추가(S110)한 후 계속해서 다음 라인을 읽게 된다(S120).
그러나, 더이상 Shelf에 대한 정보가 존재하지 않는 경우 에이전트는 Slot에 대한 정보가 존재하는지를 확인(S130)하게 된다. 이때 Slot에 대한 정보가 존재하면 Slot DB node를 차례로 생성하여 Slot DB node 테이블에 추가(S140)한 후 계속해서 다음 라인을 읽게 된다(S150).
그러나, 더이상 Slot에 대한 정보가 존재하지 않는 경우 에이전트는 Board에 대한 정보가 존재하는지를 확인(S160)하게 된다. 이때 Board에 대한 정보가 존재하 면 Board DB node를 차례로 생성하여 Board DB node 테이블에 추가(S170)한 후 계속해서 다음 라인을 읽게 된다(S180).
그러나, 더이상 Board에 대한 정보가 존재하지 않는 경우 에이전트는 초기화 파일의 끝(EOF)인지를 확인(S190)하여 파일의 끝이면 초기화 과정은 종료되어지고, 만약 파일의 끝이 아니면 다시 파일의 라인을 읽고 정보를 얻어 상술한 과정을 반복하게 된다.
즉, 이와 같은 동작이 반복되면서 Shelf, Slot, Board에 대한 DB node 까지 생성되어지면 초기화는 완료되어진다.
이와 같은 초기화 정보는 도 15와 같은 포함관계(CM Containment Tree)를 갖는 구성관리(Configuration Management) 데이터 형태로 저장소(DB table)에 저장되게 된다.
특히, 상기 노드 종류별(System, Rack, Shelf, Slot, CircuitPack)로 노드가 생성되는 과정은 다음의 도 16과 같은 과정을 통해 얻어지게 된다.
도 16은 본 발명에 따른 초기화 파일에서 라인별로 얻은 개별 노드 정보(노드 자체 정보와 속성 정보)를 받아 노드 종류별(System, Rack, Shelf, Slot, CircuitPack) 구성 데이터로 구분하여 리스트(linked-list) 형태로 저장하는 과정을 설명한 도면으로, DB 테이블 정보를 의미한다.
도 16에 도시된 바와 같이, 우선 파일에서 라인별로 개별 형상 노드의 속성(attribute) 값를 얻어서 표준(M.3100)에서 정의하는 구성요소(attributes)를 IDL로 매핑시킨 상기 도 9 내지 도 13에서 정의한 데이터 타입에 맞게 변환한 후 리스 트(linked-list) 형태로 MoAttrNodeP에 계속 저장한다(S41~S44).
이어서, 속성 정보가 모두 만들어지면 다음으로는 노드 자체에 대한 정보(dn, loc_id, id, kind, attr_cnt, attrP, lockKey)를 만든다. 여기서 MoNodeP내에 attrP 항목에 이전 과정에서 만든 노드 자신의 속성정보인 MoAttrNodeP 데이터를 저장(S45)한다.(dn : Distinguished Name, naming rule for physical location, id : Node identification number, kind : Node value, attr_cnt : Node's attribute count, attrP : Node's attribute info., lockKey : key for locking node data)
상기 DB 테이블을 구성하는 MoNode와 MoAttrNode의 내부 파라미터(parameter) 의미는 상술한 도 7의 설명과 동일하므로 생략하기로 한다.
도 17은 본 발명에 따른 구현객체(instance)의 GET operation을 나타내는 도면으로써, 망관리 표준(3GPP)에 의해 네이밍 서비스(Naming Service)에 등록된 구현객체(instance)에 대한 GET/SET은 물론, 네이밍 서비스(Naming Service)에 등록되지 않은 구현객체에 대한 GET/SET이 가능하다.
도 17에 도시된 바와 같이, 먼저 에이전트(20)는 시스템 초기화 과정에서 대표구현객체(EquipmentR1,EquipmentHolder,CircuitPack)를 생성(S10)하여 네이밍 서비스에 대표구현객체를 등록(S20)하게 된다. 이어서, 모든 configuration 데이터를 DB 테이블에 저장(S30)하게 된다.
이어서, 매니저(11)는 대표구현객체의 레퍼런스를 호출(S40)하여 에이전트(20)로부터 전달(S50)받게 된다.
이어서, 매니저(11)는 초기화시 네이밍 서비스(Naming Service) 등에 등록되 어 호출 가능한 에이전트의 대표구현객체에 대한 참조값을 가지고 간 후, 대표구현객체내에 정의된 getAttribute를 호출(S60)하게 된다.
이에 따라, 에이전트(20)에서는 검색을 위한 DB 테이블을 요청(S70)하여 대표구현객체와 관련된 구현객체를 조회(S80)하게 된다.
이어서, 에이전트(20)는 조회된 결과값(GET resultSet)을 저장(S90)하고 나서 조회된 결과값(GET resultSet)을 매니저(11)로 전달(S100)하게 된다.
이 후, 에이전트(20)는 액세스(access)된 노드 정보를 해쉬 테이블(hash table)에 추가(S110)하게 된다.
이어서, 매니저(11)는 대표구현객체내에 정의된 getAttribute를 다시 호출(S120)하게 되면, 에이전트(20)에서는 조회를 위한 해쉬 테이블을 요청(S130)하여 대표구현객체와 관련된 구현객체를 조회(S140)하게 된다.
이어서, 에이전트(20)는 조회된 결과값(GET resultSet)을 저장(S150)하고 나서 조회된 결과값(GET resultSet)을 매니저(11)로 전달(S160)하게 된다.
도 18은 본 발명에 따른 구현객체(instance)의 SET operation을 나타내는 도면으로써, 망관리 표준(3GPP)에 의해 네이밍 서비스(Naming Service)에 등록된 구현객체(instance)에 대한 GET/SET은 물론, 네이밍 서비스(Naming Service)에 등록되지 않은 구현객체에 대한 GET/SET이 가능하다.
도 18에 도시된 바와 같이, 먼저 에이전트(20)는 시스템 초기화 과정에서 대표구현객체(EquipmentR1,EquipmentHolder,CircuitPack)를 생성(S10)하여 네이밍 서비스에 등록(S20)하게 된다. 이어서, 모든 configuration 데이터를 DB 테이블에 저 장(S30)하게 된다.
이어서, 매니저(11)는 대표구현객체의 레퍼런스를 호출(S40)하여 에이전트(20)로부터 전달(S50)받게 된다.
이어서, 매니저(11)는 초기화시 네이밍 서비스(Naming Service) 등에 등록되어 호출 가능한 에이전트의 대표구현객체에 대한 참조값을 가지고 간 후, 대표구현객체내에 정의된 setAttribute를 호출(S60)하게 된다.
이에 따라, 에이전트(20)에서는 조회를 위한 DB 테이블을 요청(S70)하여 대표구현객체와 관련된 구현객체를 조회(S80)하게 된다.
이어서, 에이전트(20)는 DB 테이블에 구성요소값(attribute value)을 변경(S90)하고 나서 변경된 결과값(SET(,err) resultSet)을 저장(S100)한 후 변경된 구성요소값(attribute value)을 매니저(11)로 전송(S110)하게 된다.
이 후, 에이전트(20)는 해쉬 테이블에 액세스(access)된 노드 정보를 추가(S120)하게 된다.
이어서, 매니저(11)로부터 다시 대표구현객체내에 정의된 setAttribute가 호출(S140)되어지면 에이전트(20)에서는 조회를 위한 해쉬 테이블을 요청(S150)하여 대표구현객체와 관련된 구현객체를 조회(S160)하게 된다. 만약 해쉬 테이블에 등록되지 않아 조회가 되지 안는 경우에는 다시 DB 테이블에 요청하여 대표구현객체와 관련된 구현객체를 조회(S160)하게 된다.
이어서, 에이전트(20)는 DB 테이블에 구성요소값(attribute value)을 변경(S170)하고 나서 변경된 결과값(SET(,err) resultSet)을 저장(S180)한 후 변경된 구성요소값(attribute value)을 매니저(11)로 전송(S190)하게 된다.
이어서, 해쉬 테이블에 등록되지 않아 DB 테이블에 요청했던 노드 정보인 경우 에이전트(20)는 해쉬 테이블에 처리된 노드 정보를 추가(S200)하게 된다.
이와 같이, 본 발명에서는 매니저가 원하는 노드에 대한 정보가 해쉬 테이블에 이력이 없는 노드의 경우 DB 테이블을 통해서 얻는 방식을 사용하며, 검색된 노드에 대한 GET/SET에 대한 내부 처리를 거쳐 대표구현객체에서 결과를 전송하게 된다.
그리고, SET operation의 경우 해당 Notification을 추가로 매니저에게 전송하게 되며, 에이전트는 미등록된 구현객체에 대해 표준(3GPP)에서 정의(BasicCmIRPSystem.idl)한 BasicCmIrpOperations에 의한 GET/SET 기능도 제공한다. 즉, 매니저에서 BasicCmIrpOperations 객체에 GET/SET operation을 내리면 BasicCmIrpOperations는 바로 대표구현객체를 호출하도록 하고, 이 객체가 해쉬 테이블과 DB 테이블을 검색하여 그 결과를 생성된 iterator에 저장하게 하면, 매니저가 다시 iterator에 접근해서 결과를 순차적으로 가져가게 된다. 또한, 이러한 구조에서는 표준(3GPP)에서 정의(BasicCmIRPSystem.idl)한 Scope와 Filter 기능도 포함한다.
도 19 내지 도 20은 본 발명에 따른 GET operation 수행 과정을 나타내는 흐름도이다.
도 19에 도시된 바와 같이, 에이전트는 매니저로부터 GET operation을 수신(S100)하게 되면 대표구현객체(representative object instance)를 호출(S200)하여 GET operation을 요청(S300)하게 된다. 여기서, GET은 CORBA 표준(3GPP)에 의해 정의된 GET function 및 arguments를 의미하며, 대표구현객체(representative object instance)는 네이밍 서비스(Naming Service)에 등록되지 않아 직접 호출되지 않는 형상 객체를 대표해서 구현된 객체로서 CORBA 표준(3GPP)에 의해 BasicCmIrpOperations를 통한 GET/SET 수행시 에이전트단에서 호출하도록 설정한 객체로 이를 통해 DB 테이블에 접근하여 원하는 노드 정보를 검색하고 결과를 수집하게 된다.
이에 따라, 에이전트는 GET operation에 대한 수행 결과값을 받아(S400) 결과값이 정상적으로 얻어졌는지 아닌지를 확인(S500)한 후, 정상적으로 결과값이 얻어진 경우에는 결과값(GET resultSet)을 저장(S600)하고, 정상적으로 결과값이 얻어지지 않은 경우에는 호출 에러과정 루틴(call error proc. routine)을 수행(S700)하게 된다.
특히, 상기 과정에서 GET operation이 요청되어지면 에이전트에서는 다음과 같은 도 20의 과정을 수행하여 GET operation에 대한 수행 결과값을받게 된다.
먼저, 에이전트는 GET operation을 수신(S401)하게 되면 해쉬 테이블이 존재하는지를 확인(S402)하게 된다. 확인 결과, 해쉬 테이블이 존재하면 해쉬 테이블을 조회(S403)하고, 해쉬 테이블이 존재하지 않는 경우에는 DB 테이블을 조회(S404)하게 된다. 여기서, DB 테이블은 에이전트 초기화시 네이밍 서비스(Naming Service) 등에 의해 등록되지 않아 CORBA ORB 단에서 직접 객체 호출할 수 없는 객체 정보(class, attribute, DN, etc)를 가진 저장소이며, 해쉬 테이블(hash table)은 operation 수행시 검색 속도를 향상시키기 위해 과거 검색된 노드와 정보를 해쉬 노드(hash node)와 리스트(list)로 관리하고자 만든 저장소이다.
이어서, 에이전트는 DN 정보와 필터(filter) 정보를 입력(S405)하여 해쉬 테이블에서 해당 DN 정보를 갖고 원하는 attribute를 갖는 노드가 있는지 검색(D-1 과정)하고, 해쉬 테이블에 없는 경우에는 DB 테이블에서 검색하게 된다.
이어서, 에이전트는 검색 후 매니저로부터 받은 SearchControl 정보내 포함된 필터(filter) 조건을 파싱(parsing)하고, 검색 결과, 해당 노드가 발견되고 실제 노드 attribute가 필터(filter) 조건을 만족하는지를 확인(S406)하게 된다. 여기서, 필터(filter)는 CORBA 표준(3GPP)에 의해 정의된 GET operation 수행시 필터 조건을 의미한다.
이어서, 확인 결과 해당 노드가 발견되고 실제 노드 attribute가 필터(filter) 조건을 만족하는 경우, 검색된 노드를 해쉬 테이블에 추가(D-2 과정)하고 결과값(result)를 저장(S407)한 후 스콥 타입(scope type)을 입력(S408)하게 된다. 여기서, 결과값(result)은 GET operation 수행 결과값을 의미한다.
이어서, 에이전트는 scope 조건(type(=base-only, base and sub-tree, base-to-nth-level, base-all), level)이 base-only인지를 확인(S409)하게 된다. 이때, scope type 정보가 base-only가 아니라 다른 타입의 경우에는 복수개의 결과가 나올 수 있으므로 검색을 계속하여 마지막 노드(last node)인지를 확인(S410)하게 된다. 여기서, 스콥(scope)은 CORBA 표준(3GPP)에 의해 정의된 GET operation 수행시 scope 조건(type(=base-only, base and sub-tree, base-to-nth-level, base-all), level)을 의미한다.
이어서, 확인 결과 마지막 노드가 아닌 경우에는 다음 노드로 이동(node=node→next, S411)하며, 마지막 노드인 경우에는 마지막 노드가 해쉬 노드인지를 확인(S412)하여 해쉬 노드인 경우에는 해당 노드가 한번도 검색된 이력이 없는 경우이므로 상기 DB node를 조회하는 과정을 수행하게 된다.
도 21 내지 도 22은 본 발명에 따른 SET operation 수행 과정을 나타내는 흐름도이다.
도 21에 도시된 바와 같이, 에이전트는 매니저로부터 SET operation을 수신(S100)하게 되면 대표구현객체(representative object instance)를 호출(S200)하여 SET operation을 요청(S300)하게 된다. 여기서, SET은 CORBA 표준(3GPP)에 의해 정의된 SET function 및 arguments를 의미하며, 대표구현객체(representative object instance)는 네이밍 서비스(Naming Service)에 등록되지 않아 직접 호출되지 않는 형상 객체를 대표해서 구현된 객체로서 CORBA 표준(3GPP)에 의해 BasicCmIrpOperations를 통한 GET/SET 수행시 에이전트단에서 호출하도록 설정한 객체로 이를 통해 DB 테이블에 접근하여 원하는 노드 정보를 검색하고 결과를 수집하게 된다.
이에 따라, 에이전트는 SET operation에 대한 수행 결과값을 받아(S400) 결과값이 정상적으로 얻어졌는지 아닌지를 확인(S500)한 후, 정상적으로 결과값이 얻어진 경우에는 결과값(SET resultSet)을 저장(S600)하고, 정상적으로 결과값이 얻어지지 않은 경우에는 호출 에러과정 루틴(call error proc. routine)을 수행 (S700)하게 된다.
특히, 상기 과정에서 SET operation이 요청되어지면 에이전트에서는 다음과 같은 도 22의 과정을 수행하여 SET operation에 대한 수행 결과값을받게 된다.
먼저, 에이전트는 SET operation을 수신(S401)하게 되면 해쉬 테이블이 존재하는지를 확인(S402)하게 된다. 확인 결과, 해쉬 테이블이 존재하면 해쉬 테이블을 조회(S403)하고, 해쉬 테이블이 존재하지 않는 경우에는 DB 테이블을 조회(S404)하게 된다. 여기서, DB 테이블은 에이전트 초기화시 네이밍 서비스(Naming Service) 등에 의해 등록되지 않아 CORBA ORB 단에서 직접 객체 호출할 수 없는 객체 정보(class, attribute, DN, etc)를 가진 저장소이며, 해쉬 테이블(hash table)은 operation 수행시 검색 속도를 향상시키기 위해 과거 검색된 노드와 정보를 해쉬 노드(hash node)와 리스트(list)로 관리하고자 만든 저장소이다.
이어서, 에이전트는 DN 정보와 필터(filter) 정보를 입력(S405)하여 해쉬 테이블에서 해당 DN 정보를 갖고 원하는 attribute를 갖는 노드가 있는지 검색(D-1 과정)하고, 해쉬 테이블에 없는 경우에는 DB 테이블에서 검색하게 된다.
이어서, 에이전트는 검색 후 매니저로부터 받은 SearchControl 정보내 포함된 필터(filter) 조건을 파싱(parsing)하고, 검색 결과, 해당 노드가 발견되고 실제 노드 attribute가 필터(filter) 조건을 만족하는지를 확인(S406)하게 된다. 여기서, 필터(filter)는 CORBA 표준(3GPP)에 의해 정의된 SET operation 수행시 필터 조건을 의미한다.
이어서, 확인 결과 해당 노드가 발견되고 실제 노드 attribute가 필터 (filter) 조건을 만족하는 경우, 검색된 노드를 해쉬 테이블에 추가(D-2 과정)하게 된다.
이어서, DB 노드의 attribute를 변경(S407)하고 나서 결과값(result)을 저장(S408)한 후 매니저에게 Notification을 통해 변경을 통보한다(S409). 여기서, 결과값(result)은 SET operation 수행 결과값을 의미한다.
이 후, 스콥 타입(scope type)을 입력(S410)하게 되면, 에이전트는 scope 조건(type(=base-only, base and sub-tree, base-to-nth-level, base-all), level)이 base-only인지를 확인(S411)하게 된다. 이때, scope type 정보가 base-only가 아니라 다른 타입의 경우에는 복수개의 결과가 나올 수 있으므로 검색을 계속하여 마지막 노드(last node)인지를 확인(S412)하게 된다. 여기서, 스콥(scope)은 CORBA 표준(3GPP)에 의해 정의된 SET operation 수행시 scope 조건(type(=base-only, base and sub-tree, base-to-nth-level, base-all), level)을 의미한다.
이어서, 확인 결과 마지막 노드가 아닌 경우에는 다음 노드로 이동(node=node→next, S413)하게 되며, 마지막 노드인 경우에는 마지막 노드가 해쉬 노드인지를 확인(S414)하여 해쉬 노드인 경우에는 해당 노드가 한번도 검색된 이력이 없는 경우이므로 상기 DB node를 조회하는 과정을 수행하게 된다.
도 23은 본 발명에 따른 해쉬 테이블의 조회(find)시의 과정을 나타내는 흐름도이다.
도 23에 도시된 바와 같이, 에이전트는 DN 정보를 입력(S100)받아 해쉬 테이블을 검색하기 위한 키(key) 값인 해쉬 넘버(Hash number)를 구하고(S200) 이 정보 로 해쉬 테이블 인덱스(Hash table index)를 구한다(index = number % HASH_DENOM, S300).
이어서, 노드 포인트(node point)를 선언한 후 여기에 해쉬 테이블의 정보를 넘겨준다(Hashlmpl::data*tmp, tmp = hash[index], S400).
이어서, 입력받은 DN 정보와 해쉬 테이블 DN 정보를 비교(DN = = tmp→node→dn ?, S500)하여 입력받은 DN 정보와 해쉬 테이블 DN 정보가 동일한 경우에는 해쉬 테이블 DN 정보를 가진 노드 포인트를 넘겨주게 됨으로써(return tmp→node, S600) 해당 해쉬 테이블의 해쉬 데이터를 찾게 된다(found, S700).
그러나, 상기 DN 정보와 해쉬 테이블 DN 정보가 동일하지 않은 경우에는 다음 노드로 이동(tmp=tmp→next, S800)하여 마지막 노드(last node)인지를 확인(S900)하게 된다. 확인 결과, 마지막 노드이면 해쉬 데이터를 찾지 못하게 되며(S1000), 마지막 노드가 아닌 경우에는 상기 입력받은 DN 정보와 해쉬 테이블 DN 정보를 비교하는 과정으로 이동하게 된다.
특히, 상기 해쉬 넘버(Hash number)를 구하는 과정을 첨부된 도 24 및 도 25를 참조하여 상세히 설명하면 다음과 같다.
도 24 및 도 25는 본 발명에 따른 해쉬 넘버를 생성하는 과정을 나타내는 흐름도이다.
도 24에 도시된 바와 같이, 에이전트는 DN을 입력(S201)받아 DN 네임과 값을 얻어(get DN name & value pairs, S202) 다음 스트링 네임이 "EquipmentR1.equipmentld" 인지를 확인(next_string_name == "EquipmentR1.equipmentld", S203)한다.
확인 결과, 다음 스트링 네임이 "EquipmentR1.equipmentld" 인 경우에는 시스템 넘버를 dn_num으로 설정한다(rack_num = atoi(next_string_value), dn_num = system_num, S204).
이어서, 다음 스트링 네임이 "EquipmentHolder.equipmentld"인지를 확인(next_string_name == "EquipmentHolder.equipmentld", S205)하여 다음 스트링 네임이 "EquipmentHolder.equipmentld"이면 상기 설정된 dn_num에 rack_num을 합산하여 새로운 dn_num를 구한다(rack_num = atoi(next_string_value), dn_num = rack_num + dn_num, S206).
이어서, 다음 스트링 네임이 "EquipmentHolder.equipmentld"인지를 확인(next_string_name == "EquipmentHolder.equipmentld", S207)하여 다음 스트링 네임이 "EquipmentHolder.equipmentld"이면 상기 dn_num에 shelf_num을 합산하여 새로운 dn_num를 구한다(shelf_num = atoi(next_string_value), dn_num = shelf_num + dn_num, S208).
이어서, 다음 스트링 네임이 "EquipmentHolder.equipmentld"인지를 확인(next_string_name == "EquipmentHolder.equipmentld", S209)하여 다음 스트링 네임이 "EquipmentHolder.equipmentld"이면 상기 dn_num에 slot_num을 합산하여 새로운 dn_num를 구한다(slot_num = atoi(next_string_value), dn_num = slot_num + dn_num, S210).
이어서, 다음 스트링 네임이 "SKTCircuitPack.equipmentld"인지를 확인 (next_string_name == "SKTCircuitPack.equipmentld", S211)하여 다음 스트링 네임이 "SKTCircuitPack.equipmentld"이면 상기 dn_num에 board_num을 합산하여 새로운 dn_num를 구한다(board_num = atoi(next_string_value), dn_num = board_num + dn_num, S212).
이어서, 최종적으로 구해진 dn_num을 이용하여 hash[index]. number를 생성하게 된다(hash[index] number = dn_num, S213).
이와 같이, 에이전트는 DN을 입력받아 해쉬 테이블(Hash table)에 저장할 해쉬 넘버(Hash number)로 변환한다. 변환 규칙은 기존 DN 정보에서 각 레벨(level)별 ID 정보를 정수로 변환한 후 레벨별로 구해진 dn_num 을 합산하는 것으로 한다.
특히, 상기 레벨별로 구해진 dn_num 을 합산하는 과정은 도 25에 도시된 바와 같이, 다음 DN 요소로 이동(goto next DN element, S214)하여 다음 DN 요소가 존재하는지를 확인(S215)한다. 이 때, 다음 DN 요소가 존재하면 다음 스트링 네임을 확인하는 과정으로 이동하게 되며, 다음 DN 요소가 존재하지 않게 되면 dn_num을 이용해서 hash[index]. number를 생성하게 된다(hash[index] number = dn_num, S216).
도 26은 본 발명에 따른 해쉬 테이블의 추가(add)시의 과정을 나타내는 흐름도이다.
도 26에 도시된 바와 같이, 에이전트는 추가할 노드(node)를 입력(S100)받아 상술한 도 23의 해쉬 테이블 조회 과정을 통해 기존 해쉬 테이블에 있는 정보인지 확인(S200)한다. 확인 결과, 이미 해쉬 테이블에 있는 정보이면 해쉬 테이블 추가 과정은 종료(S300)되어진다.
그러나, 추가할 노드가 기존 해쉬 테이블에 없는 정보인 경우에는 추가할 노드를 새로운 해쉬 테이블에 저장하고 그 노드의 탑 플래그(top flag)를 설정(S400)하게 된다(index = number % HASH_DENOM, Hashlmpl::data*tmp, tmp = malloc(sizeof(Hashlmpl::data)), tmp → number = number, tmp → node = node, tmp → top_flag = true, tmp → next = hash[index]). 여기서, HASH_DENOM 파라메터는 해쉬 테이블(Hash table) 생성시 테이블(table)의 개수를 지정하기 위한 최대 인덱스(index) 값을 의미한다.
이어서, 해쉬 테이블의 인덱스가 널(null) 상태인지를 확인(hash[index] == NULL ?, S500)하여 널 상태인 경우 즉, 새로운 노드 정보인 경우 이전 탑 노드(top node)의 플래그(flag)는 해제(hash[index] → top_flag = false, S600)하게 되며, 그렇지 않고 해쉬 테이블의 인덱스가 널(null) 상태가 아닌 경우에는 탑 플래그(top flag)를 설정하고 추가(hash[index] = tmp, S700)하게 된다.
이상에서는 본 발명에서 특정의 바람직한 실시예에 대하여 도시하고 또한 설명하였다. 그러나, 본 발명은 상술한 실시예에 한정되지 아니하며, 특허 청구의 범위에서 첨부하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자라면 누구든지 다양한 변형 실시가 가능할 것이다.
본 발명에 따르면, 대표구현객체(representative object instance)를 통해 미등록 구현 객체(unregistered object instance)에 대한 정보를 호출하는 방식을 구현함으로써, 형상관리객체와 같이 네이밍 서비스에 직접 등록되지 않는 클래스당 구현되는 객체 수가 많고 종류가 다양한 경우에도 구체적으로 노드를 관리할 수 있게 되는 효과가 있다.

Claims (36)

  1. 네트워크망의 객체 관리 시스템에 있어서,
    관리대상 시스템의 초기화시 시스템 형상에 대한 초기화 정보를 객체 정보로 저장하고 상기 객체 정보를 대표하는 대표구현객체를 생성하여 망관리 시스템의 매니저로부터 객체 호출이 발생하는 경우 상기 대표구현객체를 통해 호출된 객체에 대한 커맨드를 수행하여 그 결과값을 상기 망관리 시스템의 매니저로 전달하는 에이전트를 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  2. 제 1항에 있어서,
    상기 에이전트는,
    객체간 통신을 위한 네이밍 서비스에 등록되지 않은 미등록 객체 정보를 저장하는 미등록 객체 DB와,
    상기 망관리 시스템의 매니저부터 객체 호출이 발생하는 경우 상기 대표구현객체를 통해 상기 미등록 객체 DB에 접근하여 호출된 객체에 대한 커맨드를 수행하는 응용프로그램부와,
    상기 관리대상 시스템과의 인터페이스 작용을 위한 시스템 인터페이스부를 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  3. 제 2항에 있어서,
    상기 응용프로그램부는,
    인터페이스 정의 언어(IDL)를 통해 정의된 객체간 관계나 동작을 실제로 구현한 사용자 프로그램인 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  4. 제 2항에 있어서,
    상기 미등록 객체 DB에 저장되는 미등록 객체 정보는 구조적 데이터 리스트(structured linked list) 형태로 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  5. 제 4항에 있어서,
    상기 미등록 객체 정보 중 형상 정보는 Mo_Node에 저장되고, 상기 형상 정보에 대한 각각의 속성 정보는 Mo_Attributes에 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  6. 제 2항에 있어서,
    상기 초기화 정보는 System 정보와, Rack 정보와, Shelf 정보와, Slot 정보와, Board 정보 중 적어도 어느 하나의 정보를 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  7. 제 6항에 있어서,
    상기 System 정보는 EquipmentR1 클래스로 정의된 속성(attribute) 정보에 맞춰서 상기 미등록 객체 DB에 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  8. 제 6항에 있어서,
    상기 Rack 정보와, Shelf 정보와, Slot 정보는 EquipmentHolder 클래스로 정의된 속성(attribute) 정보에 맞춰서 상기 미등록 객체 DB에 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  9. 제 6항에 있어서,
    상기 Board 정보는 CircuitPack 클래스로 정의된 속성(attribute) 정보에 맞 춰서 상기 미등록 객체 DB에 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  10. 제 2항에 있어서,
    상기 에이전트는,
    상기 망관리 시스템의 매니저로부터 객체 정보에 대한 GET operation 커맨드를 수신하는 경우, 대표구현객체를 통해 상기 미등록 객체 DB를 검색하여 호출된 객체의 검색 결과 정보를 상기 망관리 시스템의 매니저로 전송하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  11. 제 10항에 있어서,
    상기 에이전트는,
    상기 미등록 객체 DB로부터 검색된 객체의 결과 정보를 해쉬 테이블에 추가로 등록하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  12. 제 2항에 있어서,
    상기 에이전트는,
    상기 망관리 시스템의 매니저로부터 객체 정보에 대한 SET operation 커맨드를 수신하는 경우, 대표구현객체를 통해 상기 미등록 객체 DB를 검색하여 호출된 객체에 대한 정보를 변경하고 결과 정보를 상기 망관리 시스템의 매니저로 전송하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  13. 제 12항에 있어서,
    상기 에이전트는,
    상기 미등록 객체 DB로부터 검색되어 변경된 객체의 결과 정보를 해쉬 테이블에 추가로 등록하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  14. 제 11항 또는 제 13항에 있어서,
    상기 해쉬 테이블에 등록되는 정보는 구조적 데이터 리스트(structured linked list) 형태로 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  15. 제 12항에 있어서,
    상기 에이전트는,
    상기 관리대상 시스템에서 장애나 상태변경이 발생하는 경우 해당 객체에 대한 정보를 변경하고 변경된 정보를 이벤트(event)를 통해 상기 망관리 시스템의 매니저에게 전송하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  16. 제 10항 또는 제 12항에 있어서,
    상기 에이전트는 operation 커맨드 수행시 DN 정보에 맞게 검색된 구현객체 중 상기 매니저로부터 요구되는 필터 조건을 만족하는 것을 구하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  17. 제 16항에 있어서,
    상기 필터 조건은 산술 조건, 비교 조건, 포함관계 조건 중 적어도 어느 하나의 조건을 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  18. 제 10항 또는 제 12항에 있어서,
    상기 에이전트는 operation 커맨드 수행시 scope 정보에 따라 검색할 범위를 지정하고 대표구현객체를 정해서 명령을 내리게 되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  19. 제 18항에 있어서,
    상기 scope 정보는 타입(type) 정보와, 레벨(level) 정보 중 적어도 어느 하나의 정보를 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 시스템.
  20. 네트워크망의 객체 관리 에이전트 시스템에 있어서,
    객체간 통신을 위한 네이밍 서비스에 등록되지 않은 미등록 객체 정보를 저장하는 미등록 객체 DB와,
    망관리 시스템의 매니저부터 객체 호출이 발생하는 경우 대표구현객체를 통해 상기 미등록 객체 DB에 접근하여 호출된 객체에 대한 커맨드를 수행하는 응용프로그램부와,
    관리대상 시스템과의 인터페이스 작용을 위한 시스템 인터페이스부를 포함하는 것을 특징으로 하는 대표구현객체를 이용한 객체 관리 에이전트 시스템.
  21. 제 20항에 있어서,
    상기 응용프로그램부는,
    인터페이스 정의 언어(IDL)를 통해 정의된 객체간 관계나 동작을 실제로 구현한 사용자 프로그램인 것을 특징으로 하는 대표구현객체를 이용한 객체 관리 에이전트 시스템.
  22. 제 20항에 있어서,
    상기 미등록 객체 DB에 저장되는 미등록 객체 정보는 구조적 데이터 리스트(structured linked list) 형태로 저장되는 것을 특징으로 하는 대표구현객체를 이용한 객체 관리 에이전트 시스템.
  23. 제 22항에 있어서,
    상기 미등록 객체 정보 중 형상 정보는 Mo_Node에 저장되고, 상기 형상 정보에 대한 각각의 속성 정보는 Mo_Attributes에 저장되는 것을 특징으로 하는 대표구현객체를 이용한 객체 관리 에이전트 시스템.
  24. 네트워크망의 객체 관리 방법에 있어서,
    관리대상 시스템 형상에 대한 초기화 정보를 객체 정보로 저장하는 과정과,
    상기 객체 정보를 대표하는 대표구현객체를 생성하는 과정과,
    객체 호출이 발생하는 경우 상기 대표구현객체를 통해 호출된 객체에 대한 커맨드에 따라 그 결과값을 전달하는 과정을 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  25. 제 24항에 있어서,
    상기 초기화 정보는 System 정보와, Rack 정보와, Shelf 정보와, Slot 정보와, Board 정보 중 적어도 어느 하나의 정보를 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  26. 제 25항에 있어서,
    상기 System 정보는 EquipmentR1 클래스로 정의된 속성(attribute) 정보에 맞춰서 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  27. 제 25항에 있어서,
    상기 Rack 정보와, Shelf 정보와, Slot 정보는 EquipmentHolder 클래스로 정의된 속성(attribute) 정보에 맞춰서 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  28. 제 25항에 있어서,
    상기 Board 정보는 CircuitPack 클래스로 정의된 속성(attribute) 정보에 맞춰서 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  29. 제 24항에 있어서,
    상기 객체 정보는 구조적 데이터 리스트(structured linked list) 형태로 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  30. 제 24항에 있어서,
    상기 객체 정보 중 형상 정보는 Mo_Node에 저장되고, 상기 형상 정보에 대한 각각의 속성 정보는 Mo_Attributes에 저장되는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  31. 제 24항에 있어서,
    상기 대표구현객체를 통해 호출된 객체에 대한 커맨드가 GET 커맨드인 경우, GET 결과값을 전달하는 과정을 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  32. 제 31항에 있어서,
    상기 GET 결과값을 전달하는 과정은,
    상기 대표구현객체와 관련된 객체를 조회하는 과정과,
    상기 조회된 객체의 GET 결과값을 저장하는 과정과,
    상기 조회된 객체의 GET 결과값을 전달하는 과정으로 이루어지는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  33. 제 32항에 있어서,
    상기 조회된 객체의 GET 결과값을 전달한 후 조회된 객체 정보를 해쉬 테이블에 추가하는 과정을 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  34. 제 24항에 있어서,
    상기 대표구현객체를 통해 호출된 객체에 대한 커맨드가 SET 커맨드인 경우, SET 결과값을 전달하는 과정을 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  35. 제 34항에 있어서,
    상기 SET 결과값을 전달하는 과정은,
    상기 대표구현객체와 관련된 객체를 조회하는 과정과,
    상기 조회된 객체의 속성값(attribute value)을 변경하는 과정과,
    상기 변경된 속성값(attribute value)을 전달하는 과정과,
    상기 조회된 객체의 SET 결과값을 전달하는 과정으로 이루어지는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
  36. 제 35항에 있어서,
    상기 변경된 속성값(attribute value)을 전달한 후 상기 조회된 객체 정보를 해쉬 테이블에 추가하는 과정을 포함하는 것을 특징으로 하는 대표구현객체를 이용한 형상 관리 방법.
KR1020050009290A 2005-02-01 2005-02-01 대표구현객체를 이용한 형상 관리 시스템 및 그 방법 Expired - Fee Related KR100624477B1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020050009290A KR100624477B1 (ko) 2005-02-01 2005-02-01 대표구현객체를 이용한 형상 관리 시스템 및 그 방법
US11/270,446 US20060173907A1 (en) 2005-02-01 2005-11-10 Configuration management system and method using representative object instances
CNA200510129648XA CN1815978A (zh) 2005-02-01 2005-12-14 使用代表性对象实例的配置管理系统和方法
EP05027875A EP1686725A1 (en) 2005-02-01 2005-12-20 Configuration management system and method using representative object instances

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020050009290A KR100624477B1 (ko) 2005-02-01 2005-02-01 대표구현객체를 이용한 형상 관리 시스템 및 그 방법

Publications (2)

Publication Number Publication Date
KR20060088411A true KR20060088411A (ko) 2006-08-04
KR100624477B1 KR100624477B1 (ko) 2006-09-20

Family

ID=35892542

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020050009290A Expired - Fee Related KR100624477B1 (ko) 2005-02-01 2005-02-01 대표구현객체를 이용한 형상 관리 시스템 및 그 방법

Country Status (4)

Country Link
US (1) US20060173907A1 (ko)
EP (1) EP1686725A1 (ko)
KR (1) KR100624477B1 (ko)
CN (1) CN1815978A (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101127630B (zh) * 2006-08-15 2017-04-12 华为技术有限公司 对对象实例进行管理的方法、装置和系统
CN101753428A (zh) * 2008-12-16 2010-06-23 华为终端有限公司 实例标识的信息获取、上报方法及装置、处理系统
US12254328B2 (en) * 2022-04-29 2025-03-18 Volvo Car Corporation Service framework for developing application services in a dependency controlled software stack

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134581A (en) * 1997-10-06 2000-10-17 Sun Microsystems, Inc. Method and system for remotely browsing objects
JP2001333072A (ja) 2000-05-19 2001-11-30 Toyo Commun Equip Co Ltd Ｓｎｍｐネットワーク管理システム及び方法
KR20020057781A (ko) * 2001-06-28 2002-07-12 김행곤 망 관리 사용자 인터페이스 시스템
KR100418917B1 (ko) * 2001-07-10 2004-02-14 김영탁 인트라넷 관리를 위한 구성관리 컴포넌트 설계 및 구현 방법
KR20030010218A (ko) * 2001-07-26 2003-02-05 엘지전자 주식회사 교환장비와 관리서버 간의 연동 장치 및 방법
KR100382357B1 (ko) * 2001-07-28 2003-05-09 엘지전자 주식회사 노드를 관리하는 서버 객체에 대한 동적관리 방법
KR20030021611A (ko) * 2001-09-07 2003-03-15 엘지전자 주식회사 망 관리 시스템의 구성관리 연동장치 및 그 정보 제공 방법
DE10163533A1 (de) * 2001-12-21 2003-07-17 Siemens Ag Persistente Speicherung von Netzwerkmanagementdaten unter Verwendung von Objektreferenzen
US7849171B2 (en) * 2002-02-27 2010-12-07 Ricoh Co. Ltd. Method and apparatus for monitoring remote devices by creating device objects for the monitored devices
KR20060022188A (ko) * 2004-09-06 2006-03-09 엘지전자 주식회사 코바 기반 망관리 시스템에서 관리대상의 자동등록 방법

Also Published As

Publication number Publication date
KR100624477B1 (ko) 2006-09-20
EP1686725A1 (en) 2006-08-02
CN1815978A (zh) 2006-08-09
US20060173907A1 (en) 2006-08-03

Similar Documents

Publication Publication Date Title
US6317748B1 (en) Management information to object mapping and correlator
US20240179103A1 (en) Network slice configuration
US7383552B2 (en) Object manager for common information model
JP4132441B2 (ja) 管理対象オブジェクトのデータ管理装置
US7970823B2 (en) System for sharing data objects among applications
US6934706B1 (en) Centralized mapping of security credentials for database access operations
US20150215386A1 (en) Management of data object sharing among applications
US20050108206A1 (en) System and method for object-oriented interaction with heterogeneous data stores
KR100606025B1 (ko) 간이 망 관리 프로토콜 기반의 망 관리 장치 및 방법
US7904588B2 (en) Method and system for creating an overlay structure for management information bases
JP2007509431A (ja) タイプ・パス索引付け
KR20020050160A (ko) 오브젝트 통합 관리 시스템
US6044369A (en) Hash table call router for widely varying function interfaces
US7864700B2 (en) Discovering and merging network information
KR100624477B1 (ko) 대표구현객체를 이용한 형상 관리 시스템 및 그 방법
US8356085B2 (en) Automated transformation of specifications for devices into executable modules
EP3672158A1 (en) Network slice management
WO2001086495A1 (en) Centralized management of a distributed database system
KR101063577B1 (ko) 대용량데이터베이스의 스키마 및 저장프로시저 실시간관리시스템 및 방법
US12177076B2 (en) Restoration of a network slice
JPH096666A (ja) データ管理システム
KR100270914B1 (ko) 망 관리 시스템 및 방법
KR100461353B1 (ko) 데이터베이스 연결 풀을 이용한 통합망관리 게이트웨이시스템 및 그 운용방법
JP2002297418A (ja) 操作制御装置、操作制御システム、およびコンピュータプログラム
CN114978853A (zh) 一种管理信息库适配方法、装置、设备及存储介质

Legal Events

Date Code Title Description
A201 Request for examination
PA0109 Patent application

Patent event code: PA01091R01D

Comment text: Patent Application

Patent event date: 20050201

PA0201 Request for examination
PG1501 Laying open of application
E701 Decision to grant or registration of patent right
PE0701 Decision of registration

Patent event code: PE07011S01D

Comment text: Decision to Grant Registration

Patent event date: 20060831

GRNT Written decision to grant
PR0701 Registration of establishment

Comment text: Registration of Establishment

Patent event date: 20060908

Patent event code: PR07011E01D

PR1002 Payment of registration fee

Payment date: 20060911

End annual number: 3

Start annual number: 1

PG1601 Publication of registration
FPAY Annual fee payment

Payment date: 20090827

Year of fee payment: 4

PR1001 Payment of annual fee

Payment date: 20090827

Start annual number: 4

End annual number: 4

LAPS Lapse due to unpaid annual fee
PC1903 Unpaid annual fee