KR100735669B1 - CORBA-based Adaptive Bridging Pool System and Method thereof - Google Patents

Abstract

A CORBA-based adaptive bridge pool system and method for integrating CALM's MOM, JADE's agent system, and MICO's CCM and allowing transparent connection with other middleware. A first server, a second server with a platform of MICO, CCM middleware, a third server with a platform of CALM, a message-oriented middleware, and a bridge server connected to the first to third servers, respectively. The bridge server includes a dynamic bridge and a static bridge.

By using the CORBA-based adaptive bridge pool system and the method described above, it is responsible for efficient bridging according to the load of objects in a large heterogeneous distributed environment, so that the ubiquitous environment middleware can efficiently process data of various environments. have.

Bridging, Middleware, Agents, CALM, CORBA

Description

CORBA-based Adaptive Bridging Pool System and Method

1 is an explanatory diagram showing a flow of a dynamic bridging operation in a main bridge;

2 shows the architecture of a bridge according to the invention,

3 is a view showing an experimental environment for performance evaluation according to the present invention;

4 is a diagram illustrating a comparison of an object response time;

5 is a diagram showing characteristics when the number of activated objects is increased to 1000;

6 is a block diagram illustrating one embodiment of a group communication system in CORBA as a prior art.

The present invention relates to a CORBA-based Adaptive Bridging Pool (CAB) system and method for implementing the function of Message Oriented Middleware (MOM) in Component-based Autonomic Layered Middleware (CALM), in particular the function of MOLM of CALM, The present invention relates to a CORBA-based adaptive bridge pool system and method for integrating JADE's agent system and MICO's CCM and allowing transparent connection with other middleware.

That is, the present invention is equipped with an adaptive bridging pool technology that ensures transparent and efficient connection between heterogeneous middleware, and the static bridge and dynamic skeleton interface / dynamic invocation interface (DSI / DII) optimized for the objects of the CALM. The present invention relates to a technology that enables efficient interworking between heterogeneous middlewares by selectively using a dynamic bridge.

In general, a system device is a collection of individual application programs or agents having a variety of functions to become a new system equipment, the system equipment configured for communication is called a TMS (TMN) system do.

Each agent constituting the TMN system is configured using a different kind of programming language, and as described above, each agent using a different language is combined and linked to operate. To do this, you need middleware to interface each language.

Middleware is software with its own APIs that help isolate software developers from operating system specific application programming interfaces (APIs). The middleware layer is often located between the client process and the server process. By measuring the root time associated with the middleware layer of the application, problems can be identified and corrected for improved performance and availability.

Currently, the root time associated with the middleware application can be measured by changing the code of the application itself. Such a procedure is considered to be mandatory. Other known procedures used to measure root time rely on multiple resources and require synchronization between multiple components.

In addition, the CORBA (Common Object Request Broker Architecture) is a structure and specification for creating, distributing, and managing distributed program objects in a network, and is known as a standard for providing a transparent communication method between application objects.

The CORBA standard, proposed by an alliance of developers called OMG, enables heterogeneous systems to communicate in a distributed environment using the Object Request Broker (ORB). Clients using an ORB can transparently invoke server object methods, regardless of their development language or location (local or remote). The CORBA standard also specifies the interfaces and services that each ORB must have. The specification includes an IDL to describe the interface.

Many vendors provide a way to map IDL with development languages such as C, C ++, Java, Smalltalk, Ada, and COBOL.

In other words, the core concept of CORBA is the ORB. ORB support for client and server networks of heterogeneous computers means that a client program (which can be an object itself) services from a server program or an object without knowing where the server is in the distributed network or what interface the server program will have. That means you can ask.

To establish requests and responses between ORBs, programs use the General Inter-ORB Protocol (GIOP) and IIOP on the Internet. IIOP maps GIOP requests and responses to each computer's Internet TCP layer.

CORBA Component Model (CCM) is a standard component middleware technology that is not provided in earlier versions of CORBA2.x middleware based on the DOC model. The CCM standard supports CORBA2.x objects to support the notion of an installation standard for specifying, implementing, packaging, assembling, and deploying components and components. Defined by the CORBA 3.x specification, which extends the model.

Component technology can overcome many of the limitations of traditional object request brokers (ORBs) in the development of distributed, real-time, and embedded (DRE) applications. Component technology has special advantages for building large scale DRE systems.

This CORBA component model enables the composition and reuse of software components and enables configuration that is not a core function of the DRE system, such as timing, fault-tolerance, and security. do.

Agents are generically defined as a program that replaces a user's work, and are also known as intelligent agents and autonomous agents to distinguish them from other programs.

The characteristics of agents are autonomy, intelligence, mobility, and social ability. Additional features include reactivity to respond to changes in the environment, veracity to prevent false information, and rationality to support rational methods.

Agents can be divided into multi-agent and mobile-agent. Multi-agents deal with complex operations that require co-operation between agents in order to achieve complete work. The mobile agent travels the network to handle those operations. For this reason, mobile agents are useful in wireless networks.

Agent platforms must support agent communication languages such as ACL and KQML to allow collaboration between agents residing on other agent platforms. Agents provide designers and developers with a way to build applications and communication elements around Autonomous, and lead the infrastructure to support software tool structures and design metaphors. There are now two common agent platforms, JADE and Aglet.

Component-based Autonomic Layered Middleware (CALM), a message-oriented middleware, adopts reflective and adaptive middleware and provides development tools to build a flexible platform for agents.

It consists of two inner layers, one outer layer, and various tools to form an efficient agent-based application platform. The inner layer consists of a communication platform layer and an agent platform layer.

The communication platform layer is configured to provide various services based on environment and location using efficient communication protocols along with lightweight devices in wired / wireless environment. The agent platform layer consists of components to maximize the efficiency of the service, adapt to the environment, and provide the benefits of various agent systems.

The external layer consists of a self-growing engine and an ontology-based context-aware engine to provide intelligent services.

One of the most important features of CALM is the functionality of Message Oriented Middleware (MOM). MOM allows consumers of services to be physically and temporarily independent of providers of services. Communication between the service provider and their consumers is asynchronous and need not be useful at the same time because they can communicate by sending and receiving messages from designed message queues. In contrast, RPC is a synchronous way to request remote service execution. Consumers must postpone service execution until they receive a response from the supplier.

Also, an example of such CORBA is "A Study on the CORBA-based Intelligent Agent, Korean OA Society Journal No. 7C, March 2002", Korean Patent Application Publication No. 2002-0026299 (April 09, 2002), Patent Publication No. 2003-0008774 (January 29, 2003), Patent Publication No. 2005-0084519 (August 26, 2005) and the like.

That is, in the above document, an agent-based model is presented in a distributed database using an agent communication language, and intelligent using CORBA capable of sharing and exchanging information in distributed operating systems and distributed heterogeneous databases. A model of a product search agent is presented.

In addition, Japanese Patent Laid-Open No. 2002-0026299 discloses a technology related to a group communication system and method in a KOBA that extends an OCI (Open Communications Interface) as shown in FIG. 6.

FIG. 6 is a block diagram illustrating an embodiment of a group communication system in CORBA, and is independent of an operating system (OS), and various existing group communication protocols without modification of an object request broker (ORB) and an OCI. Applicable, in a group communication system in CORBA having a client and a plurality of servers connected via a network, the group application of the first application object, the first application object to control the application of the first group communication OCI A first ORB for selectively requesting functions of a plurality of communication components, which are internal functions of COVA, and a connector factory, a connector, and a connector transport having respective information objects, according to the control for the first time, between the first ORB and the network. In Cobar including a first group communication OCI that selectively applies multiple transport protocols for group communication It is described on the communication system.

In addition, Korean Patent Laid-Open Publication No. 2003-0008774 discloses a method of dynamically moving a management object using various CORBA middleware, configuring each agent, and comprising various languages from one agent to another.

In other words, in the management of a management object in the CORBA environment and the TMS system consisting of a plurality of agents, it is determined in an intensive process and an intensive process of determining whether access to a specific managed object is above a predetermined level among a plurality of managed objects constituting the agent If the management object does not concentrate more than a predetermined level, the update process to determine whether the management object constituting the agent is updated, modified, or backed up, and when the management object constituting the agent is updated, modified, or backed up, Copying the same management object and moving to another agent and registering the move and processing the work, determining whether to continue with the above process returns to the intensive process, if not continue continuing process, intensive process Judging from the house, access to the management object above a certain level In the case of heavy load, the management object creates and registers the same management object in the registered agent, distributes the work in the existing management object and the newly registered management object, and then proceeds to the distributed process. Is disclosed.

The publication also discloses a system for monitoring middleware performance, comprising: a computer system for generating sample messages and application messages, and a computer memory electrically connected to the computer system and having instructions encoded therein; Determining the root time for a sample message sent along a given network route, the instructions reflecting the amount of time an application message is stored in at least one respective queue located along a given network route. A method is disclosed for a middleware performance monitor system that determines at least one queue residence time and calculates a middleware response time according to a root time and at least one queue residence time.

However, in the technique disclosed in the above-mentioned document, the pervasive computing system is a more dynamic paradigm than the conventional computing system, and therefore, a middleware framework is required to integrate the objects existing in the pervasive computing paradigm. Due to the increased overhead and complexity, the implementation of single middleware for pervasive computing objects has been very difficult.

In addition, the Java Agent Development Framework (JADE) does not fully support CORBA, requiring a bridge to interconnect CORBA-based middleware. JADE is a software framework developed completely in the Java language. Therefore, the Java ORB that maps Java fully supports JADE. If CALM's applications do not use CCM, JADE and CALM can communicate with each other by IIOP without a bridge. However, the Java ORB does not support full CCM interoperability, which means that you can't directly access CORBA components without a bridge.

Also, in the CORBA specification, CCM uses the IDL compiler without bridges to support backward compatibility. However, the ORB platform vendors that can support these lower versions are only a few, so the use of these lower versions is generally not applicable. Another heterogeneous agent platform or CCM platform has a problem in that it cannot directly use the CAM MOM or agent functions without a bridge.

An object of the present invention is to solve the problems described above, by integrating agent platform (JADE) and CCM platform (MICO) transparently based on CALM to provide interoperability between heterogeneous middleware, and transparent and efficient connection To provide a CORBA-based adaptive bridge pool system and method thereof.

It is another object of the present invention to provide a CORBA-based adaptive bridge pool system and method that uses a portable interceptor to mix a dynamic bridge and a static bridge to enable transparent and efficient connections between pervasive objects.

In order to achieve the above object, the CORBA-based adaptive bridge pool system according to the present invention comprises a plurality of servers connected through a network, CORBA-based adaptive bridge pool system to ensure a transparent and efficient connection between heterogeneous middleware, The first server with the platform of the Java Agent Development Framework (JADE), the agent platform middleware, the second server with the platform of the MICO, the CCM middleware, and the platform of the component-based autonomic layered middleware (CALM), the message-oriented middleware. And a third server including a bridge server and a bridge server connected to the first server to the third server, respectively, wherein the bridge server uses a dynamic bridge and a static bridge.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is characterized by connecting the first server to the third server by using a dynamic bridge and a static bridge by using a portable interceptor.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server obtains time-per-request information of the first server to the third server by using a portable interceptor, and by using the information, The hotspot objects are distinguished.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is characterized by providing a function of a dynamic bridge to the cool spot object.

In addition, in the CORBA-based adaptive bridge pool system according to the present invention, the cool spot object and the hot spot object are distinguished by using a discrete distribution.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is characterized by optimizing the connection according to the characteristics of the object by measuring the cool spot object and hot spot objects.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is characterized by optimizing the elapsed time of the connection process by storing the existing bridge in the factory.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is configured to connect the first server to the third server by using a dynamic bridge and an on-demand bridge.

In addition, in the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is characterized by providing the function of the dynamic bridge as a cool spot object.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is characterized by using a mechanism-based static bridge of the on-demand bridge as an object of a hot spot.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server is characterized by providing a static bridge to the object moving from the cool spot to the hot spot.

In the CORBA-based adaptive bridge pool system according to the present invention, the bridge server selectively selects a static bridge optimized for objects of the CALM and a dynamic bridge using DSI / DII (Dynamic Skeleton Interface / Dynamic Invocation Interface). It is characterized by using as.

In addition, to achieve the above object, the CORBA-based adaptive bridge pool method according to the present invention comprises a first server having a platform of JADE (Java Agent Development Framework), which is an agent platform middleware, and a first having a platform of MICO, a CCM middleware. Heterogeneous middleware in a system comprising two servers, a third server having a platform of component-based autonomic layered middleware (CALM), a message-oriented middleware, and a bridge server respectively connected to the first to third servers A CORBA-based adaptive bridge pool method that guarantees transparent and efficient connection between the servers, wherein the bridge server connects the first server to the third server by using a dynamic bridge and a static bridge by using a portable interceptor. It is done.

The above and other objects and novel features of the present invention will become more apparent from the description of the specification and the accompanying drawings.

First, the concept of the present invention will be described.

Currently, three bridging techniques are known as static bridges, dynamic bridges, and on-demand bridges.

Static bridges require static proxy and stub implementations to perform marshalling for each interface. If there is any change to the interface, the proxy and stub must reflect this change, and thus the interface must be recompiled to generate new proxy and stub codes to encode, decode, and call the new interface. . Thus, the static bridge is not suitable for pervasive environments with correctly changing situations.

Dynamic bridges, on the other hand, eliminate the hassle of static bridges because they have a generic proxy that can marshal all data types based on some form of run-time form library. This form of information look-up can be efficient in performance. In general, however, dynamic bridges are not as efficient as static bridges. Despite this potential performance, the general mapping method of the dynamic bridge provides less memory footprint than the static interface mapping method of the static bridge. Therefore, dynamic bridges can be suitable for rapidly changing situations.

The third form of bridge is an on-demand bridge. Here, the bridge factory automatically generates the source code for the static bridge, which is usually based on the interface of the client and server being bridged. Based on this definition, the bridging code must convert the values between the two middleware domains, and the mapping rules for each type are coded into the bridge factory.

The present invention proposes a method of mixing a dynamic bridge and an on-demand bridge for efficiency.

EMBODIMENT OF THE INVENTION Hereinafter, the structure of this invention is demonstrated according to drawing.

An adaptive bridging strategy according to the present invention is as follows.

In this approach, all the servers implementing the objects are divided into cool spot objects and hot spot objects by the request per time measurement of the portable interceptor.

Object requests in a coolspot are bursty, and the time per request of objects does not have a high value. On the other hand, object requests in hotspots are relatively persistent, and the time per request of the object has a very high value.

In this approach, CoolSpot objects use Dynamic Skeleton Interface / Dynamic Invocation Interface (DII / DSI) based dynamic bridges. On the other hand, hotspot objects use an on-demand bridge mechanism based static bridge. Thus, in the present invention, this approach provides an efficient balance between throughput and flexibility.

Portable interceptors play a very important role in this method. Portable interceptors transparently route requests to the main bridge. The portable interceptors provide time information per request to help the adaptive decision of the main bridge. The interceptors provided to the object list the objects to use either a static bridge or a dynamic bridge by the order of the main bridges.

Next, an on-demand bridge pull strategy according to the present invention will be described.

As mentioned above, objects in a hotspot use their static bridges. This static bridge is created by the main bridge at runtime. And already created bridges are stored in the bridge pool. The main bridge activates or creates at runtime the most optimized bridge in its pool based on the information provided by the portable interceptor.

Here, the bridge factory automatically generates the source code for the static bridge based on the client and server interface definitions that would normally be bridged. Bridging code based on these definitions must convert values between the two middleware domains, and the mapping rules for each type are coded into the bridge factory.

Next, the architecture of the adaptive bridging pool of CALM according to the present invention will be described.

In the present invention, three different platforms such as CALM as a backbone middleware, Java Agent Development Framework (JADE) as an agent platform middleware, and MICO as a CCM middleware are linked for performance evaluation. In the present invention will be described through such an example.

The main bridge uses portable interceptors to obtain time information per request. Based on this information, the main bridge distinguishes between cool spot objects and hot spot objects. The threshold for this division is not always the same.

In the present invention, the limit value was obtained by empirical value through repeated experiments.

To distinguish objects between cool and hot, we use a Poisson distribution like this:

The main bridge uses portable interceptors to get the lambda value of each object, which is the amount of time per request. The threshold value k is not always the same as described above.

In the present invention, the discrete distribution function uses a CDF (Cumulative Distribution Function), and the hot spots focus on using only the cool spots and explaining the concept.

The main bridge provides the functionality of a dynamic bridge with cool spot objects. All internal platform communications are routed by the main bridge.

1 is a diagram illustrating a flow of a dynamic bridging operation in a main bridge.

The main bridge is an object of CALM, which uses not only the CALM ORB but also the MICO ORB and the Java ORB. This structure allows the main bridge to provide general and dynamic bridging. In general, dynamic bridges are not as efficient as static bridges. Although this performance factor, the generic mapping of the dynamic bridge takes up less memory than the specific interface mapping of the static bridge.

The main bridge then provides a static bridge for objects moving from the coolspot to the hotspot. So hotspot objects in the system use static bridges created by the main bridge at runtime. Using static bridges, hotspot objects can achieve efficient throughput.

However, not all bridges can get their own static bridge. If all objects have their own bridges, they will require very large memory and computing resources. So only objects in the coolspot are bursty, and only have low time-per-request values using dynamic bridges.

The architecture of the bridge according to the invention is shown in FIG.

Interceptors are an optional extension that allows services such as security to be inserted into the calling process. For example, you can use interceptors to learn about communication between clients and servers, and modify these communications if you want to effectively change the behavior of the ORB.

The present invention uses portable interceptors to measure each object load. The portable interceptor measures the amount of time per request of the object. The portable interceptor then sends this information to the main bridge.

3 is a view showing an experimental environment for performance evaluation according to the present invention.

In Figure 3, Jade, the agent platform consists of two Pentium 4 (3.0 GHz, 1GB RAM) servers and one SUN (SUN SPARC dual CPU 800MHz, 2GB RAM) server. Agent objects are loaded on this platform.

The MICO and CCM platforms consist of three Pentium 4 (3.0 GHz, 1GB RAM) servers. CCM objects are loaded on this platform.

The CALM platform consists of three Pentium 4 (3.0 GHz, 1GB RAM) servers. This platform is loaded with COS objects. Agent, CCM, and COS objects are simply implemented for performance evaluation. And these objects are for interconnection and interoperability.

All objects (agents, CCM, COM objects) are also activated by the load constructor by the experimental environment. The system of Figure 3 consists of CALM, JADE, and MICO, the objects of which are configured to connect other middleware.

In the present invention the experiment is carried out using different scenarios. In scenario 1, the entire object uses its own static bridge. Each object has its own stubs and skeletons and accesses objects on different platforms.

In the present invention, the number of activated objects was changed, and the response time of each object was measured. In scenario 2, the entire object uses a dynamic bridge. In scenario 3, the main bridge measures the PDF of the discrete distribution and divides it into coolspot and hotspot objects.

The main bridge then provides the object with a specific static bridge. Dynamic bridges, on the other hand, are provided as coolspot objects by the main bridge. So scenario 3 is an experiment according to the invention, scenarios 1 and 2 are used as control groups. The number of requests for activated objects is determined irregularly. The ratio of activated objects with runaway requests that are coolspot objects and the ratio of activated objects with persistent requests that are hotspot objects are the same rate under the control of the load creator.

In the present invention, the limit value k in the Cumulative Distribution Function (CDF) of the discrete distribution is an empirical value obtained by repeated experiments, and the optimized value of K is affected by the system clock speed and RAM.

4 is a diagram illustrating response times of objects.

Response time is calculated by a portable interceptor. Scenario 1 shows the result of using one dynamic bridge. As described in the discrete distribution above, the entire objects use a dynamic bridge developed by DII / DSI in scenario # 1. Therefore, as in scenario 1, the system is common and simple to implement. The throughput of the bridge is not good because the dynamic bridge uses DII / DSI which does not have good throughput. And since the whole bridge uses only one bridge, bottle necks appear.

In scenario 2, the entire object uses its own static bridge. The static bridge handles the object statically. So the throughput of the static bridge is much better than that of the dynamic bridge. And the use of two bridges can avoid bottlenecks. In practice, however, it is not possible to provide all static bridges in a pervasive computing environment with fast situation changes. And because static bridges consume their memory and computing resources, objects with congestion requests using static bridges can waste resources. If the system has many congestion objects, cool spot objects, the use of static bridges may even have less throughput than the dynamic bridge has.

In scenario 3, the system allows a mixed use of dynamic and static bridges as described above. This method is very adaptable to pervasive computing environments with rapidly changing situations. And this method is more flexible than the fully static method and more efficient than the fully dynamic method.

The results in FIG. 4 show the tradeoff relationship between static and dynamic bridging methods.

5 shows a characteristic when the number of activated objects increases to 1000. FIG.

Scenario 1 deals with the entire object using a dynamic bridge without considering the context of the objects. In this case, if the system only uses the RPC congestion function, there is no problem with the server, but the dynamic bridge has enormous overhead when objects use an interface that transfers large amounts of data. The response time in scenario 1 increases gradually.

In scenario 2, the entire object has its own static bridge. In this case the bridges have a relatively short response time. Throughput when the number of activated objects is 550 or less is most efficient. However, above 550, throughput is significantly reduced due to resources consumed by multiple static bridges. So in the present invention, it can be seen that the throughput of the proposed bridging pool technique is better than others, when the number of activated objects is less than 550.

In scenario 3, the main bridge measures the PDF of the discrete distribution and divides it into coolspot and hotspot objects. The main bridge then provides the object with a specific static bridge. Dynamic bridges, on the other hand, are provided as coolspot objects by the main bridge. So scenario 3 is an experiment according to the invention, scenarios 1 and 2 are used as control groups. The number of requests for activated objects is determined irregularly. The ratio of activated objects with congestion requests that are coolspot objects and the ratio of activated objects with persistent requests that are hotspot objects are the same rate under the control of the load creator.

As mentioned above, although the invention made by this inventor was demonstrated concretely according to the said Example, this invention is not limited to the said Example and can be variously changed in the range which does not deviate from the summary.

Ubiquitous middleware requires vast amounts of information and operation in various heterogeneous environments, which cannot be compared with existing middleware. This vast amount of data and diverse heterogeneous environments require efficient information processing and compatibility.

As described above, according to the CORBA-based adaptive bridge pool system and method according to the present invention applying a bridging pool technology to CALM and connecting a component platform and an agent platform, objects in a large heterogeneous distributed environment are Since it is responsible for efficient bridging according to the load, the ubiquitous environment middleware can efficiently process data in various environments.

In addition, according to the CORBA-based adaptive bridge pool system and method according to the present invention, the middleware framework required to integrate the objects existing in the pervasive computing paradigm is a single middleware because of the increased overhead and complexity Since the implementation of is very difficult, the effect of using adaptive bridging pool technology can be transparently and efficiently interoperated with other middleware.

In addition, according to the CORBA-based adaptive bridge pool system and the method according to the present invention, it is possible to determine the heterogeneous environment dynamically to reduce the load and to reconsider the efficiency.

In addition, according to the CORBA-based adaptive bridge pool system and the method according to the present invention, it is easy to integrate each part developed by each module in the heterogeneous integration solution in the middleware or firmware field, and the performance of the integrated product itself is also improved. As a result, it can be achieved by optimizing the solution into an optimized solution in a large distributed environment.

Claims (18)

In a CORBA-based adaptive bridge pool system having multiple servers connected through a network and ensuring transparent and efficient connection between heterogeneous middleware,  A first server equipped with a platform of Java Agent Development Framework (JADE), which is an agent platform middleware, A second server with the platform of MICO, the CCM middleware, A third server with a platform of component-based autonomic layered middleware (CALM), a message-oriented middleware; and A bridge server connected to each of the first server to the third server, The bridge server mixes a dynamic bridge and a static bridge, The bridge server obtains time-per-request information of the first to third servers by using a portable interceptor, and distinguishes cool spot objects from hot spot objects based on the information. CORBA-based adaptive bridge pool system, characterized in that the distinction between the hotspot object and the hotspot object using a discrete distribution (Poisson distribution). The method of claim 1, And the bridge server uses a portable interceptor to connect the first to third servers by using a dynamic bridge and a static bridge. delete The method of claim 2, And the bridge server provides the functionality of a dynamic bridge to the coolspot object. delete The method of claim 4, wherein And the bridge server measures the coolspot object and the hotspot objects to optimize the connection according to the characteristics of the object. The method of claim 6, The bridge server CORBA-based adaptive bridge pool system, characterized in that to store the existing bridge in the factory to optimize the elapsed time of the connection process. The method of claim 1, The bridge server is a CORBA-based adaptive bridge pool system, characterized in that the first server to the third server to connect by using a mixed bridge and dynamic bridge. The method of claim 8, The bridge server is a CORBA-based adaptive bridge pool system, characterized in that to provide the function of the dynamic bridge to the cool spot object. The method of claim 9, And the bridge server uses a mechanism-based static bridge of the on-demand bridge as an object of a hotspot. The method of claim 2, And wherein the bridge server provides a static bridge for objects moving from the coolspot to the hotspot. The method of claim 2, And the bridge server selectively uses a static bridge optimized for objects of the CALM and a dynamic bridge using a dynamic skeleton interface / dynamic invocation interface (DSI / DII). The first server with the platform of the Java Agent Development Framework (JADE), the agent platform middleware, the second server with the platform of the MICO, the CCM middleware, and the platform of the component-based autonomic layered middleware (CALM), the message-oriented middleware. In the CORBA-based adaptive bridge pool method for ensuring transparent and efficient connection between heterogeneous middleware in a system comprising a third server having a and a bridge server connected to the first server to the third server, respectively, The bridge server uses a portable interceptor to connect the first to third servers by using a dynamic bridge and a static bridge, The bridge server obtains time-per-request information of the first to third servers by using a portable interceptor, and distinguishes cool spot objects from hot spot objects based on the information. The division of the cool spot object and the hot spot object is divided using a distribution distribution (Poisson distribution), CORBA-based adaptive bridge pool method. delete The method of claim 13, Wherein the bridge server provides the functionality of a dynamic bridge to the coolspot object. delete The method of claim 15, And the bridge server measures the cool spot object and the hot spot objects to optimize the connection according to the characteristics of the object. The method of claim 17, CORBA-based adaptive bridge pool method, characterized in that the bridge server stores the existing bridge in the factory to optimize the elapsed time of the connection process.

Images