Corba's basic content (below)
(This article is reproduced from Software Engineering Expert Network www.21cmm.com)
Su Yang
The purpose of the Interface Warehouse CORBA introduction interface warehouse is to allow the service object to provide a persistent object service. After the interface information is stored in the interface repository, if the client application submits the dynamic invocation request (Dynamic Invocation), the ORB can obtain the information required to request calls according to the data objects in the interface information in the interface repository and the distribution environment. The interface warehouse is part of the CORBA system, manages and provides access to the OMG IDL mapping interface definition. The important role of information in the interface warehouse is to connect to each ORB. When the request is passed from an ORB to another ORB, the receiving ORB needs to create a new object to represent the transmitted object, which requires the interface of the receiving ORB. The interface information is matched in the warehouse. You can match the interface in the interface repository of the receiving end by getting the interface ID in the interface repository of the service request end ORB.
The interface warehouse consists of a set of interface warehouse objects representing interface information in the interface warehouse. The interface warehouse provides a variety of operations to complete the addressing, management of the interface. In the implementation process, you can select an object permanent existence or reference to the creating.
In the implementation form of the interface warehouse, the form of object definitions in the interface warehouse is disclosed, and the information defined in the library can be used by the client and the server. Application developers can use interface functions in the following aspects: ● Management interface definition installation and deployment; ● Provide interface information to advanced language compilation environments; ● Provide components of the end user environment.
1. Management of the interface warehouse
The interface warehouse contains object information required to request calls when calling. Once the information is loaded into the library, the client memory rendering rely on the information of the interface warehouse to provide objects, so the corresponding policy must be selected to ensure consistency and integrity of information in the interface warehouse.
Consistency in the interface warehouse is usually manifested as a set of valid OMG IDL definitions. Due to the cause of communication delays during interface loading, there is a possibility that the interface name conflict or method definition collision is possible. In a distributed environment, in order to solve this problem, replication techniques are usually used to increase the consistency and availability of interface information. In addition, interface warehouse objects typically use transaction processing and concurrent control methods defined by the service object to complete updates to the interface warehouse.
2, interface warehouse object
The features and methods provided by the interface warehouse object depends on the specific CORBA product, and the developer should be used in different choices of products. In the interface warehouse, the following objects are included, each object provides a corresponding method for managing the object information in the interface warehouse: ● Repository: Indicates the interface warehouse details; ● ModuleOf: module definition object; ● InterfaceOf: interface definition object; ● valueof: value Type definition; ● ExceptionOf: A definition of exceptions caused by operation.
The object adapter object adapter is introduced to the service object-side management object reference and implementation. There must be an object adapter when system implementation is required in the CORBA specification. The object adapter completes the following functions: ● Generate and interpret the reference to the object to map the client's object reference to the functionality of the service object; ● Activate or undo the implementation of the object; ● Implementation of the registration service function; ● Ensure the security of the object reference; ● Complete calls to the service object method.
As the object adapter commonly used in CORBA - Basic Object Adapter, it is necessary in distributed application design. ORB passes the parameters and operation control of the service request to the BOA, and the execution result is returned to the ORB by BOA. The BOA uses the service object skeleton (SKELETON) to link the method in the ORB and object implementations, and the corresponding method in the service object skeleton maps the request to the BOA method to map into the service object. The role of the BOA during the call request is shown in Figure 1. Dynamic Call Interface Dynamic Call Interface (DIID, DYNAMIC Invacation Interface) Allows requests for service objects to be dynamically created and calling on clients. A request includes an object reference, an operation, and a parameter list. The definition of the parameter list is as follows: typedef unsigned long flag; struct name; any arguments; long list; flags arg_modes;} where Name represents passing parameter name; arguments represents passing parameters; arg_modes represents parameters Pattern ID.
Dynamic call request operation includes a wealth of ways, which is a brief introduction to the corresponding method of dynamic request: 1. Void Create_Request (IN Context CTX; In NVList arg_list; inout namedValue Result; OUT Request Request; in flags req_flags; ) Role: Create a dynamic request; method parameters: The parameters included in this method are in turn to the Context object used in the operation, the object's operation type, the parameters used in the operation, the method results, the returned call request, and the flag used in the request.
2. Void get_response () Raises (WrongTransAction) Role: Returns the result of the request execution. After calling the method, you will always wait until the request method is completed.
3. Void get_next_response (RAESTSEQ * &) RAISES (WrongTransaction) Rack: Return the next request; method parameters: object request sequence identity.
Context Object Context Object (Context) contains information that the client, running environment, or delivery is not delivered as a parameter, the context object is a list of composed of identifiers and corresponding strings, and programming sector can be defined in context. Operation on the interface to create and operate the context object.
The context object can be stored in a permanent or temporary manner, the client application uses the context object to acquire the running environment; and the information in the orb is used to determine the position of the server and the requesting method activation. The method in the context object is described below:
1. Void get_default_context (OUT Context CTX) Role: Create a context object; method parameters: The context object obtained.
2. Void get_values (in identifier start_scope, in identifier prop_name, out nvlist value) Run: Return the feature value in the context object; return type: return feature value; method parameters: start_scope is the search scope ID; op_flags is operational Sign; Prop_name is a feature name; Values is the corresponding feature value.
