Distributed application (on) using dynamic call mode (on)
(This article is reproduced from Software Engineering Expert Network www.21cmm.com)
Su Yang
Defining Dynamic Invocation Interface (DII) and Dynamic Invocation Interface (DSI) in the CORBA specification is to increase the flexibility of distributed application design.
Typically, based on the client memory root program, information such as the name, parameter, return value type of the called method is needed. However, in practical applications, when designing client applications, do not know the specific details of the service object implementation, or even the service object instance has not been created. According to this situation, CORBA defines another way of customer object call service object implementation: the client is implemented in a dynamic call interface (DII) mode, and the service object is created in the form of dynamic skeleton interface (DSI). In this way, when the distributed application is designed, it is largely reduced the degree of dependence on the service object when the client application is created, and the flexibility of distributed application design is improved.
Client Dynamic Call Interface (DII)
Dynamic call mode Creating a client and service objects When implementing an application, it is no longer relying on the reference of the Pile Program and the Skeleton Program to the Service Object. Therefore, the dynamic call mapping option "-dynamic_marshal" that needs to be specified during the IDL to Java language mapping process, and the way in Visibroker is:
IDL2JAVA-Dynamic_Marshal FileName.IDL
When creating a client application based on a dynamic call-based distributed application, the client should first create a request object, and specify the method name in the request object and the parameters of the application, etc. After creating a request object, query the operation of the service object in synchronous form or asynchronous form, and resolve the return result after the service object is run, end the dynamic call request.
In the dynamic call mode, the client must propose a service request to the service object (Request). The Request object represents a call request to the service object on behalf of the customer object. There are two ways to create a request object: First, by creating a reference to the calling object, create a request object with the reference object, then call the ADD_VALUE method of the Request object to add the method to call the parameters required; another way is called The _create_request method being cited to create a call request for the service object. Example code for creating a request object using the _Request method is:
Org.omg.corba.Request Request = ServerObject._request ("getname")
The request object created in the above code is used to call the name GetName of the service object.
The service request consists of a reference to the service object, the service object method name and parameter list to be called. The requested parameter is implemented in the form of an element list, where the element is an instance of the NamedValue structure type, which is defined as follows:
Typedef unsigned long flag;
Struct NamedValue
{
Identifier Name;
Any argument;
Long Len;
Flags arg_modes;
}
The meaning of the parameters is the name, variable value, variable length, and parameter mode identifier of the elements in the list.
CORBA defines a lot of methods for the dynamic call interface, used to create call requests, query return results, and resolve the return result. The following describes how commonly used clients implement dynamic calls:
Void Create_Request (in Context CTX,
In Identifier Operation, in nvlist arg_list,
INOUT NamedValue Result,
Out Request Request,
IN Flags Req_flags
The parameters respectively provide the CONTEXT object that call the request applied, the method name, calling method, call return result, new return request and request mark, and so on.
2. Boolean Poll_Response (in Request Req)
The parameter REQ is a service request created by the user. The method is used to query the completion of the service request sent to the service object in asynchronous form. Returns True Description Request has been completed, otherwise it will be not completed.
3. Get_Response () Raises (WrongTransaction)
The method is used to query the completion of the service request sent to the service object to the service object synchronously. Method Returns the result of the call request. If the modified method of the service object end is not completed, the get_response method will wait until the request is completed.
Similar methods include GET_NEXT_RESPONSE for querying the execution of the next request without sending multiple call requests at the client.
Service Object Dynamic Skeleton Interface (DSI)
Service Object Dynamic Skeleton Interface (DSI) is located in the service object end for dynamic processing of service requests from the client. The dynamic skeleton interface receives the client service request by the object adapter and passes the request to the service object.
When dealing with the customer request, the service object does not analyze the customer whether to use the pile method or the dynamic call interface to make an object service request; at the same time, the calling client does not deselect the service object Receive service request is through the service object skeleton.
The service object end CORBA object structure is shown below:
The preparation step of the service object realization program based on the dynamic skeleton interface is:
● Create a service object implementation program for the parent object as the DynamicImplementation interface;
● Implement the INVOKE method of the DynamicImplementation interface, apply the service object request to receive customer objects;
● Receive reference to root PoA by Narrow method;
● Create a service PoA (POA Servant) through the root POA's Create_POA method, and specify the implementation of the service object method in the service PoA;
When creating a service object implementation program, INVOKE and other methods in abstract class DynamicImplement are implemented. This class is defined as:
Package Org.omg.corba;
Public Abstract Class DynamicImplementation
Extends org.omg.corba.portable.ObjectImpl
{
Public Abstract void invoke (org.omg.corba.serverRequest Request);
}
It can be seen that the abstract method INVOKE is defined in the DynamicImplementation abstraction. This method is used to handle service requests raised by the client object in the service object implementation program. In this method, first analyze the calling method name in the Request instance to analyze the method's proposed method is defined in the service object implementation. If there is no definition, throw the Bad_Operation exception. Its code is:
IF (! Request.operation (). Equals ("getname"))
{
Throw new org.omg.corba
.BAD_OPERATION ();
}
In the above code, the method name that needs to be called is analyzed by the Operation method of the Request object. Therefore, it is possible to determine whether the method is implemented in the server. In the case where the method name of the Request request is correct, the service object implements the end application calls the appropriate method to process the user request.
