KR100716171B1 - Apparatus and method for pooling the object of distributed system - Google Patents

Abstract

The present invention relates to an apparatus and a method for managing an object in a distributed environment system. The present invention relates to storing information used for an object call in both an internal storage unit and a remote object storage unit. Invoke the object by using the information obtained from the external part, and call the object by using the information obtained from the remote object storage to call the object through socket communication when the object to be called is a remote object. To manage them efficiently.

Distributed Environment, Object Management, Remote Method Invocation (RMI), rmipool, rmiregistry

Description

Apparatus and method for managing objects in distributed environment system {APPARATUS AND METHOD FOR POOLING THE OBJECT OF DISTRIBUTED SYSTEM}

1 is a data flow diagram between components of an object management apparatus according to the prior art.

2 is a data flow diagram between components of an object management apparatus according to the present invention;

3 is a flow chart of object management in accordance with the present invention.

The present invention relates to an apparatus and method for managing objects in a distributed environment, and more particularly, to an apparatus and method for managing objects in a distributed environment that can efficiently manage a call of a remote object.

Most systems are becoming more complex. Distributed environment systems have been introduced for efficient management of such complex systems. One of the most important issues in distributed environment systems is object invocation. A distributed environment system may consist of a combination of a plurality of small systems, a plurality of processes, and the like, which may also operate by calling remote objects.

Referring to the method used in the prior art to call a remote object is as follows. The following description will be based on the Remote Method Invocation (RMI) technology used in the Java (JAVA) environment. RMI technology is a technology used for communication between processes in a distributed environment.

In remote object invocation in a distributed environment system, the remote object can be used in the same way as a local object via RMI technology. The nature of object calls that allow remote objects to be used in the same way as local objects is called location transparency.

When doing RMI communication, the called party rebinds the remote object into rmiregistry, and the calling party looks up the remote object from rmiregistry and calls it. In general, once looked up objects are stored in the rmipool and reused without looking up on the next invocation.

With reference to the accompanying Figure 1 will be described in detail the remote object call process according to the prior art.

1 is a data flow diagram between components of an object management apparatus according to the prior art.

In FIG. 1, callee 100 is a process having a remote object to be called, and caller 110 is a process to call an object. It is assumed that object calls between them are made by Java's RMI. It is assumed that the internal object storage unit 120 of FIG. 1 is RmiPool of Java and the remote object storage unit 130 is rmiregistry of Java.

As shown in FIG. 1, the callee 100 rebinds 101 information to the remote object storage 130 to call an object, which will be used by the caller 110. The information stored in the remote object store 130 may then be used by the caller 110.

If an object call is required, the caller 110 first searches whether the information for calling the object is stored in the internal object storage 120 (103 and 105). Since the information is stored in the remote object storage 130, the caller 110 may not find the information in the internal object storage 120.

The caller 110 who does not find information for calling the object from the internal object storage 120 retrieves the information from the remote object storage 130 (107 and 109). The information obtained through the search from the remote object storage 130 is stored in the internal object storage 120 (111) and transmitted to the caller 110 (113).

The caller 110 performs socket communication with the called party 100 by using the obtained information, and thus can call the object.

On the other hand, in a distributed environment system, an object generally exists in another process but may exist in the same process. For example, a remote object may exist distributed among several processes in multiple servers in a large system, or may exist in the same process in a small system.

However, in the related art, when a function is called with a remote object looked up from rmiregistry, if the remote object exists in the same process, although the direct call through the internal call is possible, unnecessary socket communication is performed, resulting in performance degradation. .

Accordingly, an object of the present invention is to provide an apparatus and method for managing objects in a distributed environment system that can efficiently manage a call of a remote object.

The present invention to achieve this object; An internal object storage for storing an internal object, a remote object storage for storing a remote object, and an object to be called in the internal object storage (rmipool), and storing the object information stored in the internal object storage in the remote A caller stored in an object storage unit and, when a call to an arbitrary object is requested, the object is searched in an internal object storage unit, and if the object exists in the internal object storage unit, the object is called internally; If the object does not exist in the internal object storage unit, search for the remote object storage unit, the object management in a distributed environment comprising a caller to call the object through the socket communication from the remote object storage unit Suggest a device.

In addition, the present invention; An object management method in a distributed environment system, comprising: a first process of storing an object to be called in an internal object storage; a second process of storing object information stored in the internal object storage in a remote object storage; If a call is required, the internal object storage unit searches for the object, and if the object information exists in the internal object storage unit, internally calls the object, and if the object does not exist in the internal object storage unit, And a third step of searching for the remote object storage unit and calling the corresponding object from the remote object storage unit through socket communication.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In describing the present invention, if it is determined that the detailed description of the related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

The present invention supports location transparency of an object call in a distributed environment system, and improves performance by allowing a direct call without socket communication when a remote object exists in the same process in a distributed environment.

The present invention to be described below is characterized in that the information for calling the object is stored in both the internal object storage and the remote object storage. Through this, the information of the internal object can be retrieved from the internal object storage, and the information of the remote object can be retrieved from the remote object storage.

Hereinafter, an object management apparatus and method in a distributed environment system according to the present invention will be described in detail with reference to the accompanying drawings. Among the terms used in describing the present invention, "callee" is a process having an object to be called, and "caller" is a process to call the object. On the other hand, the present invention will be described below based on Java. However, the present invention is not limited thereto, and may be implemented through other means than Java.

2 is a data flow diagram between components of an object management apparatus according to the present invention.

It is assumed that the internal object storage unit 120 of FIG. 2 is RmiPool of Java and the remote object storage unit 130 is rmiregistry of Java.

As shown in FIG. 2, the callee 100 stores the information for calling the object in the internal object storage 120 (201 and 203) to be used by the caller 110. Information for calling the object is also stored in the remote object storage 130 (205).

The caller 110 who wants to call the object first searches whether internal object storage 120 stores information for calling the object (207 and 209). If the caller 110 and the callee 100 are the same process, the object to be called becomes an internal object for the caller 110 as well. In this case, the information of the object will be stored in the internal object storage unit 120 retrieved by the caller. Therefore, in this case, the caller 110 can obtain the information of the object from the internal object storage 120.

On the other hand, when the caller 110 and the callee 100 are not the same process, the information of the object does not exist in the internal object storage 120 retrieved by the caller 110.

If the information of the object does not exist in the internal object storage 120, the caller 110 retrieves the information of the object from the remote object storage 130 (211) and obtains the information (213). . The information obtained through the search from the remote object storage 130 is stored in the internal object storage 120 (215) and forwarded to the caller 110 (217). The information of the object obtained from the remote object storage unit 130 is stored in the internal object storage unit 120 for the case where the object is later called again.

The caller 110 calls the object using the information of the object obtained through the above-described processes (S219). In this case, the caller 110 directly calls the object through an internal call when the object is an internal object, and calls the object through socket communication when the object is a remote object.

That is, the present invention can perform the object call through the socket communication only to the remote object, the internal call to the internal object to reduce unnecessary socket communication, and efficiently perform object management.

Meanwhile, "stub" mentioned in FIG. 2 is used for RMI technology. Any person having a general technology for Java can understand it, so a separate description thereof will be omitted.

3 is a flowchart illustrating object management according to the present invention.

3 specifically illustrates the operation of caller 110. A separate flow chart is omitted for the operation of the called party 100 for storing information of the object in the internal object storage 120 and the remote object storage 130. For operation of the called party 100, refer to steps 201 to 205 of FIG. 2.

In step 300 of FIG. 3, the caller 110 searches for object information stored in the internal object storage 120. If it is determined that the information of the object is stored in the internal object storage 120 (302), in step 304 the caller 110 internally calls the object using the information.

On the other hand, if it is determined in step 302 that the information of the object is not stored in the internal object storage unit 120, the caller 110 retrieves the information of the object in the remote object storage unit 130 in step 310. . In operation 312, the caller 110 stores the information obtained from the remote object storage 130 in the internal object storage 120. In step 314, the caller 110 performs a socket communication for calling a corresponding object by using the information of the object obtained from the remote object storage 130.

Hereinafter, the present invention will be described once again using specific Java code.

First, the present invention should have a rmipool class that provides rebind and lookup functions that support both remote and internal objects. This class may be represented as shown in Table 1 below.

RmiPool getInstance (): RmiPool rebind (name: String, object: Object) lookup (name: String): Object

The caller 110 and the callee 100 operate as follows using the rmipool class.

First, the operation of the callee 100 is as follows.

1. Register the remote object by calling rmipool rebind.

rmipool.rebind (remoteObjectName, remoteObjectInstance);

a) RmiPool stores remote objects in an internal buffer.

objectpool.put (remoteobjectname, remoteobjectinstance);

b) Rebind to rmiregistry.

naming.rebind (remoteobjectname, remoteobjectinstance);

Next, the operation of the caller 110 is as follows.

1. Look up the name of the remote object you want to call from rmipool.

rmipool.lookup (remoteobjectname);

a) If rmipool finds a remote object by its name from an internal buffer, it returns the retrieved remote object immediately. Otherwise, it looks up from rmiregistry, saves the retrieved remote object in an internal buffer, and returns the remote object.

remoteObjectInstance = objectPool.get (remoteObjectName);

if (remoteObjectInstance == null)

{

    remoteObjectInstance = Naming.lookup (remoteObjectName);

    objectPool.put (remoteObjectName, remoteObjectInstance);

}

return remoteObjectInstance;

  In the following, in particular, the case where the present invention is applied to a network management system (Network Management System; NMS) will be described as an example. Network management system is also a system to which distributed environment is applied. In addition, the decentralization requirements of network management systems are increasing in next generation networks.

First, a brief description will be given of a network management system (hereinafter referred to as a network management system) for a next generation network.

General requirements of current network management system are as follows. First, since it is necessary to manage various devices of various vendors, it must be able to accommodate various management protocols such as SNMP, CORBA, and TL1. Second, the addition of new services should be easy and the disruption of management functions should be minimized. Third, when upgrading due to the addition / change of functions, if all equipment cannot be upgraded at the same time due to regional restrictions or the upgrade policy of the operator, it is necessary to manage the existing version equipment during the upgrade, so two or more versions must be managed within the same equipment. do. Fourth, the management function should be distributed to expand the management capacity due to the increase of the management equipment in the future. Fifth, the limited resources are efficiently used to increase the management capacity of the system.

To accommodate these requirements, network management systems are typically designed in a hierarchical structure.

A case of applying the object management of the present invention to message processing in a network management system having a hierarchical structure is as follows.

In a network management system, a point-to-point method for delivering a request / response message and a publish-subscribe method for delivering an event message may be used as a message delivery method. The point-to-point method is a message delivery method used when there is only one receiver interested in a message. It is used to deliver request and response messages in an Integrated NMS. The publish-subscribe method is a message delivery method used when there are several recipients interested in a message. The publish-subscribe method is mainly used for delivering event messages.

In the following, an object call of the present invention, which is used for message delivery in a publish-subscribe method in a network management system, is applied.

An example of applying the object call of the present invention to an interface for supporting the aforementioned message delivery method may be defined as follows using RMI and CORBA, which are mainly used to support a distributed environment system.

First, RMI, or JAVA.

public interface Session {

    public void receive (AbstractList messages)

        throws RemoteException;

    public AbstractList send (Map message)

        throws RemoteException;

    public void send (Map message, Session receiver)

        throws RemoteException;

    public void isAlive ()

        throws RemoteException;

}

public interface Publisher {

    public void isAlive ()

        throws RemoteException;

    public Integer subscribe (Session subscriber, Serializable topic)

        throws RemoteException;

    public void cancel (Integer id)

        throws RemoteException;

    public void publish (AbstractList messages)

        throws RemoteException;

    public void publish (Integer id, AbstractList messages)

        throws RemoteException;

}

The following is the case of CORBA.

module com {module samsung {module nms {

   module protocol {module corba {

// Define Message (Name-Value List)

typedef sequence <NameValue> Message;

// Define Message List

typedef sequence <Message> MessageList;

// Define Exception

exception RemoteException {string message;};

interface Session {

    MessageList send (in Message message)

      raises (RemoteException);

    MessageList send (in Message message,

        in Session receiver)

      raises (RemoteException);

    void received (in MessageList messages)

      raises (RemoteException);

};

interface Publisher {

    void isAlive () raises (RemoteException);

    short subscribe (in Session subscriber)

      raises (RemoteException);

    void cancel (in short id)

      raises (RemoteException);

    void publish (in MessageList messages)

      raises (RemoteException);

    void publishTo (in short id, in MessageList messages)

      raises (RemoteException);

};};};};};};

Since the above codes are easily understood by those who use JAVA or CORBA, a separate description thereof will be omitted. In addition, the present invention is not limited to the above code, but may be implemented by various programs and codes.

As described above, when the present invention is applied to message delivery in a distributed environment system, a simple rule is because the message delivery in the same process, message delivery between different processes, and message delivery in a distributed environment are all made in the same pattern. Only complex systems can be completed.

As described above, in the object search in a distributed environment system, a reference of a corresponding object is directly obtained if an internal object exists in a process, and a reference of a stub object is obtained if a remote object exists in another process. The reference of the object once obtained is stored in internal storage and reused to maintain optimal performance regardless of the object's location.

It supports location transparency regardless of whether the remote object is distributed in different processes or in the same process on multiple servers, and there is no socket communication when the remote object exists in the same process in a distributed environment. Direct calls can be made to improve performance. As a result, even if the placement of the remote object varies according to the scale of the applied system, it is possible to provide optimal performance without modification of code.

Claims (7)

In the object management apparatus in a distributed environment, An internal object storage unit for storing internal objects, A remote object storage unit for storing the remote object, A caller for storing an object to be called in the internal object storage unit and storing object information stored in the internal object storage unit in the remote object storage unit; When a call to any object is required, the object is searched for in the internal object storage, and if the object exists in the internal object storage, the object is called internally, and the object exists in the internal object storage. Or a caller which retrieves the remote object storage and calls the corresponding object through socket communication from the remote object storage. The method of claim 1, The caller, An object management apparatus in a distributed environment for storing an object called through the socket communication from the remote object storage in the internal object storage. The method of claim 1, The caller and callee, An object management device in a distributed environment that uses Java's Remote Method Invocation (RMI) to store, retrieve, and invoke the objects. The method of claim 1, The internal object storage unit is RmiPool of Java, and the external object storage unit is a rmiregistry of Java object management apparatus in a distributed environment. In the object management apparatus in a distributed environment, An internal object storage unit for storing internal objects, A remote object storage unit for storing the remote object, An object management apparatus in a distributed environment that stores the object to be called in the internal object storage, and stores the object information stored in the internal object storage to the remote object storage. In the object management method in a distributed environment system, A first step of storing the object to be called in an internal object storage; A second process of storing object information stored in the internal object storage in a remote object storage; If an object call is required, the internal object storage unit searches for the object, and if the object information exists in the internal object storage unit, internally calls the object, and if the object does not exist in the internal object storage unit, And a third step of searching for the remote object storage and calling the corresponding object from the remote object storage through socket communication. The method of claim 6, And a fourth process of storing the object called through the socket communication from the remote object storage in an internal object storage.

Images