Overview of the module model of CORBA

Introduction:

Distributed computing middleware, such as CORBA, is developing rapidly. When fierce competition with the world makes it increasingly difficult to develop and maintain complex systems in a traditional way. CORBA allows you to call operations on distributed objects without worrying about the underlying environment of its applications. The traditional corbar defines a soft bus framework and develops object services with standard interfaces. Using CORBA, we can integrate and combine large and complex distributed application systems.

However, traditional CORBA has its disadvantages:

No standard way to deploy object implementations:

There is no standard way to configure the object application. For example, there is no standard way to distribute object applications, install them in their execution context, or activate applications in a specific orb. Therefore, system designers must use ad hoc policies to instantiate objects in the system. Further, because objects may depend on each other, instantiation may become complicated in a large system.

?? Lack of support for common programming idioms for CORBA servers:

The description of CORBA provides the features of a wide range of application services. In some application domains, only limited features are applied. As a result, it is expected that tools that can automatically generate the application common application instance CORBA code can support required features. For example, in the description of CORBA 2.2, Poa is a mechanism for guiding client requests to specific object applications. PoA provides standard APIs to register, live, or activate object applications. Poa is a flexible CORBA programming model module that provides a large number of rules to configure its behavior. However, an important application only uses a part of it, but service developers have to learn how to configure many rules to get the desired behavior.

?? Difficulty extending object functionalities:

In the traditional CORBA object model, objects can only be extended by inheritance. To support new interfaces, application developers must: 1 define a new interface, inherited from the required interface, the IDL Interface; 2 apply a new interface; 3 assign an application to the server. However, multi-inheritance is fragile in the corba idl, because the heavy load is not allowed in the IDL, because the language like C lacks heavy load.

Therefore, the above introduction limits the application. Further, applications may need to expose the same IDL Interface multiple times. In order to allow developers to use multiple applications or instances of multiple services, a single entry point is used. On the contrary, multiple inheritance makes it impossible to expose the same interface multiple times or decide which one is the most original interface provided to the client.

?? Availability of CORBA object services is not defined a priori:

The description of which object service is provided at runtime is useless. As a result, the object developer must use the ad hoc policy to configure and activate these services.

?? No standard Object lifecycle management:

Although the CORBA object service defines a lifecycle service, it is not required. Therefore, the client needs to clearly manage the object lifecycle in ad hoc mode. Furthermore, developers of the CORBA objects controlled by the lifecycle service must understand this fact and define additional interfaces to control the object lifecycle. The process of defining these interfaces should be implemented automatically, but earlier versions of CORBA indicate that the process is not monotonous.

The limitations of the description of the CORBA, earlier and included in Version 2.3, listed above, often lead to close integration, and difficult to design, reuse, and expand, maintained and extended ad-hoc object applications.

To make up for the above shortcomings, OMG accepts the CORBA Component Model (CCM) as part of CORBA 3. CCM extends the traditional CORBA object model and allows application developers to apply, manage, configure, and expand features and services of modules integrated with the CORBA service, such as tolerance, security Transactions and Event Services in a standard environment. The CCM standard not only improves the reusability of server software, but also provides great flexibility for dynamic CORBA application configuration. As the number of applications of CORBA increases, CCM shows a client/server application that is suitable for upgrading and has strict application requirements. In this chapter, we describe the main features and services defined by CCM, and illustrate the benefits of the CCM structure.

 

The module developer defines the IDL Interface supported by the module application. Next, use the tool application module provided by CCM. As a result, the module applications are packaged into dynamic connections. Finally, the allocation mechanism provided by CCM is used to allocate modules on the module server (component server ). The module server is used by the process supervisor application through the relevant DLL. Therefore, on the module server, the module executes and provides to process client requests. One advantage is that the CCM standard development process. Below, we describe the module in the CCM, from the client point of view and the module developer's point of view, and we describe to support the CCM, orb extension.

Client View

Next, we will introduce what the module is and how to apply it from the client's point of view.

 

The reference of a module Foo instance has been provided to the client, such as an instance with a rule-based CORBA object directing to the interface Foo. Therefore, the client that is not clear to the module can call operations. Through an object guide to the module object equivalent interface, the module entity can be uniquely identified. Through a rule-based CORBA object, the erased equivalent interface can be inherited from another interface, called the module support interface. As we mentioned at the beginning, it is difficult to extend the CORBA object by using inheritance. Because objects cannot be connected to multiple interfaces, a single application entity is used. To solve this problem, CCM adds facets to the module. facets is also the provided interface, which is provided by the module. It is not necessary to connect to the module support interface through inheritance. The CCM polygon is designed in the same way as the extension interface mode. It is similar to the Module Interface in COM (Microsoft's Component Object Model.

In the CORBA: ccmobject interface, a navigation interface is defined, and all the equivalent module interfaces inherit from it. Clients is used in the navigation interface to list the topics provided by all modules. Therefore, any client with a guide to the polygon can use the standard get_component () operation to get the guidance on the module equivalent interface.

Adding a polygon to the CCM object model significantly improves the reusability of the module. For example, the new interface can be provided in the new module without affecting the existing module client. Furthermore, the new client can check whether a module provides a certain interface through the standard CCM browser interface. This is because CCM allows binding of several unrelated interfaces to a module application entity. The client does not need to clearly understand the application details of the module. In order to use the selectable interface provided by the client.

Component lifecycle management:

For module servers, it is important to correctly handle the lifecycle management issues and for clients to help module servers manage the lifecycle of their module instances. For example, a module can output multiple services at the same time like multiple clients. Similarly, a module server can accommodate many modules. In addition, a module server must know when to create a module instance and when to migrate it to prevent resource leakage. Although the liftcycle service is defined in the description of the CORBA object service, it is not necessary for common CORBA objects. Therefore, CORBA developers often apply their own ad hoc lifecycle management policies. In fact, the flexibility of the description in CORBA closely integrates the client and specific applications on the object interface. To standardize the module lifecycle management interface, CCM introduces a new word "home", indicating the lifecycle management policy of each module. The client can use the 'Home' interface to control the lifecycle of each module instance. Each home interface accurately manages a type of module. Home may be keyless or keyless. Keyless home often supports factory operations to create instances of new modules. On the contrary, the key supports the finder operation. The client can use the index to access instances of the persistent module, and use the key provided by the client. To indicate to the module server that a specific module is no longer needed, the client can call the remove_component () operation to notify the module server on the home policy interface. The module server can decide how to remove the module.

Component usage scenarios:

To use a module, the client must first obtain the module 'home' interface. However, the client requires a standard startup mechanism to locate the module's home interface. In order to simplify the self-lifting process, the Home Guide of the provided module can have a central database. Therefore, all clients that need to be self-initiated receive guidance from the central database. To enter the central database, CCM defines the homefinder interface, which is similar to the name service of CORBA. The client starts to use the standard CORBA self-raising API resolve_initial_references ("homefinder") to get the guidance for the object to the homefinder interface. the CCM homefinder application client is used to locate the module home directory service and get guidance on the home interface. In this case, call the correct factory method to create or discover the target module.