VisiBroker for Java Developer’s Guide : Using the Dynamic Skeleton Interface

Using the Dynamic Skeleton Interface
This section describes how object servers can dynamically create object implementations at run time to service client requests.
What is the Dynamic Skeleton Interface?
The Dynamic Skeleton Interface (DSI) provides a mechanism for creating an object implementation that does not inherit from a generated skeleton interface. Normally, an object implementation is derived from a skeleton class generated by the idl2java compiler. The DSI allows an object to register itself with the VisiBroker ORB, receive operation requests from a client, process the requests, and return the results to the client without inheriting from a skeleton class generated by the idl2java compiler.
Note
From the perspective of a client program, an object implemented with the DSI behaves just like any other VisiBroker ORB object. Clients do not need to provide any special handling to communicate with an object implementation that uses the DSI.
 
The VisiBroker ORB presents client operation requests to a DSI object implementation by calling the object's invoke method and passing it a ServerRequest object. The object implementation is responsible for determining the operation being requested, interpreting the arguments associated with the request, invoking the appropriate internal method or methods to fulfill the request, and returning the appropriate values.
Implementing objects with the DSI requires more manual programming activity than using the normal language mapping provided by object skeletons. However, an object implemented with the DSI can be very useful in providing inter-protocol bridging.
Using the idl2java compiler
The idl2java compiler has a flag (-dynamic_marshal) which, when switched on, generates skeleton code using DSI. To understand how to do any type of DSI:
1
2
Generate with -dynamic_marshal,
3
Steps for creating object implementations dynamically
To create object implementations dynamically using the DSI:
1
When compiling your IDL use the -dynamic_marshal flag.
2
Design your object implementation so that it is derived from the org.omg.PortableServer.DynamicImplementation interface instead of deriving your object implementation from a skeleton class.
3
Declare and implement the invoke method, which the VisiBroker ORB will use to dispatch client requests to your object.
4
Example program for using the DSI
An example program that illustrates the use of the DSI is located in the following directory:
<install_dir>/examples/vbroker/basic/bank_dynamic
This example is used to illustrate DSI concepts in this section. The Bank.idl file, shown below, illustrates the interfaces implemented in this example.
// Bank.idl
module
Bank {
interface Account {
float balance();
};
interface AccountManager {
Account open(in string name);
};
};
Extending the DynamicImplementation class
To use the DSI, object implementations should be derived from the DynamicImplementation base class shown below. This class offers several constructors and the invoke method, which you must implement.
package org.omg.CORBA;
public abstract class
DynamicImplementation extends Servant {
public abstract void invoke(ServerRequest request);
...
}
Example of designing objects for dynamic requests
The code sample below shows the declaration of the AccountImpl class that is to be implemented with the DSI. It is derived from the DynamicImplementation class, which declares the invoke method. The VisiBroker ORB will call the invoke method to pass client operation requests to the implementation in the form of ServerRequest objects.
The code sample below shows the Account class constructor and _primary_interface function.
import java.util.*;
import org.omg.PortableServer.*;
public class AccountImpl extends DynamicImplementation {
public
AccountImpl(org.omg.CORBA.ORB orb, POA poa) {
_orb = orb;
_poa = poa;
}
public synchronized org.omg.CORBA.Object get(String name) {
org.omg.CORBA.Object obj;
// Check if account exists
Float balance = (Float)_registry.get(name);
if (balance == null) {
// simulate delay while creating new account
try {
Thread.currentThread().sleep(3000);
} catch (Exception e) {
e.printStackTrace();
}
// Make up the account's balance, between 0 and 1000 dollars
balance = new Float(Math.abs(_random.nextInt()) % 100000 / 100f);
// Print out the new account
System.out.println("Created " + name + "'s account: " +
balance.floatValue());
_registry.put(name, balance);
}
// Return object reference
byte[] accountId = name.getBytes();
try {
obj = _poa.create_reference_with_id(accountId, "IDL:Bank/
Account:1.0");
} catch (org.omg.PortableServer.POAPackage.WrongPolicy e) {
throw new org.omg.CORBA.INTERNAL(e.toString());
}
return obj;
}
public String[] _all_interfaces(POA poa, byte[] objectId) { return null; }
public void invoke(org.omg.CORBA.ServerRequest request) {
Float balance;
// Get the account name from the object id
String name = new String(_object_id());
// Ensure that the operation name is correct
if (!request.operation().equals("balance")) {
throw new org.omg.CORBA.BAD_OPERATION();
}
// Find out balance and fill out the result
org.omg.CORBA.NVList params = _orb.create_list(0);
request.arguments(params);
balance = (Float)_registry.get(name);
if (balance == null) {
throw new org.omg.CORBA.OBJECT_NOT_EXIST();
}
org.omg.CORBA.Any result = _orb.create_any();
result.insert_float(balance.floatValue());
request.set_result(result);
System.out.println("Checked " + name + "'s balance: " +
balance.floatValue());
}
private Random _random = new Random();
static private Hashtable _registry = new Hashtable();
private POA _poa;
private org.omg.CORBA.ORB _orb;
}
The following code sample shows the implementation of the AccountManagerImpl class that need to be implemented with the DSI. It is also derived from the DynamicImplementation class, which declares the invoke method. The VisiBroker ORB will call the invoke method to pass client operation requests to the implementation in the form of ServerRequest objects.
import org.omg.PortableServer.*;
public class
AccountManagerImpl extends DynamicImplementation {
public AccountManagerImpl(org.omg.CORBA.ORB orb, AccountImpl accounts) {
_orb = orb;
_accounts = accounts;
}
public synchronized org.omg.CORBA.Object open(String name) {
return _accounts.get(name);
}
public String[] _all_interfaces(POA poa, byte[] objectId) { return null; }
public void invoke(org.omg.CORBA.ServerRequest request) {
// Ensure that the operation name is correct
if (!request.operation().equals("open")) {
throw new org.omg.CORBA.BAD_OPERATION();
}

// Fetch the input parameter
String name = null;
try {
org.omg.CORBA.NVList params = _orb.create_list(1);
org.omg.CORBA.Any any = _orb.create_any();
any.insert_string(new String(""));
params.add_value("name", any, org.omg.CORBA.ARG_IN.value);
request.arguments(params);
name = params.item(0).value().extract_string();
} catch (Exception e) {
throw new org.omg.CORBA.BAD_PARAM();
}
// Invoke the actual implementation and fill out the result
org.omg.CORBA.Object account = open(name);
org.omg.CORBA.Any result = _orb.create_any();
result.insert_Object(account);
request.set_result(result);
}
private AccountImpl _accounts;
private org.omg.CORBA.ORB _orb;
}
Specifying repository ids
The_primary_interface method should be implemented to return supported repository identifiers. To determine the correct repository identifier to specify, start with the IDL interface name of an object and use these steps:
1
2
Add “IDL:” to the beginning of the string.
3
Add “:1.0” to the end of the string.
For example, this code sample shows an IDL interface name:
Bank::AccountManager
The resulting repository identifier looks like this:
IDL:Bank/AccountManager:1.0
Looking at the ServerRequest class
A ServerRequest object is passed as a parameter to an object implementation's invoke method. The ServerRequest object represents the operation request and provides methods for obtaining the name of the requested operation, the parameter list, and the context. It also provides methods for setting the result to be returned to the caller and for reflecting exceptions.
package org.omg.CORBA;
public abstract class
ServerRequest {
public java.lang.String operation();
public void arguments(org.omg.CORBA.NVList args);
public void set_result(org.omg.CORBA.Any result);
public void set_exception(org.omg.CORBA.Any except);
public abstract org.omg.CORBA.Context ctx();
// the following methods are deprecated
public java.lang.String op_name(); // use operation()
public void params(org.omg.CORBA.NVList params); // use arguments()
public void result(org.omg.CORBA.Any result); // use set_result()
public abstract void except(org.omg.CORBA.Any except); // use set_exception()
}
All arguments passed into the arguments, set_result, or set_exception methods are thereafter owned by the VisiBroker ORB. The memory for these arguments will be released by the VisiBroker ORB; you should not release them.
Note
The following methods have been deprecated:
Implementing the Account object
The Account interface declares only one method, so the processing done by the AccountImpl class' invoke method is fairly straightforward.
The invoke method first checks to see if the requested operation has the name “balance.” If the name does not match, a BAD_OPERATION exception is raised. If the Account object were to offer more than one method, the invoke method would need to check for all possible operation names and use the appropriate internal methods to process the operation request.
Since the balance method does not accept any parameters, there is no parameter list associated with its operation request. The balance method is simply invoked and the result is packaged in an Any object that is returned to the caller, using the ServerRequest object's set_result method.
Implementing the AccountManager object
Like the Account object, the AccountManager interface also declares one method. However, the AccountManagerImpl object'sopen method does accept an account name parameter. This makes the processing done by the invoke method a little more complicated.
The method first checks to see that the requested operation has the name “open”. If the name does not match, a BAD_OPERATION exception is raised. If the AccountManager object were to offer more than one method, its invoke method would need to check for all possible operation names and use the appropriate internal methods to process the operation request.
Processing input parameters
The following are the steps the AccountManagerImpl object'sinvoke method uses to process the operation request's input parameters.
1
Create an NVList to hold the parameter list for the operation.
2
Create Any objects for each expected parameter and add them to the NVList, setting their TypeCode and parameter type (ARG_IN, ARG_OUT, or ARG_INOUT).
3
Invoke the ServerRequest object'sarguments method, passing the NVList, to update the values for all the parameters in the list.
The open method expects an account name parameter; therefore, an NVList object is created to hold the parameters contained in the ServerRequest. The NVList class implements a parameter list containing one or more NamedValue objects. The NVList and NamedValue classes are described in “Using the Dynamic Invocation Interface”.
An Any object is created to hold the account name. This Any is then added to NVList with the argument's name set to name and the parameter type set to ARG_IN.
Once the NVList has been initialized, the ServerRequest object'sarguments method is invoked to obtain the values of all of the parameters in the list.
Note
After invoking the arguments method, the NVList will be owned by the VisiBroker ORB. This means that if an object implementation modifies an ARG_INOUT parameter in the NVList, the change will automatically be apparent to the VisiBroker ORB. This NVList should not be released by the caller.
 
An alternative to constructing the NVList for the input arguments is to use the VisiBroker ORB object'screate_operation_list method. This method accepts an OperationDef and returns an NVList object, completely initialized with all the necessary Any objects. The appropriate OperationDef object may be obtained from the interface repository, described in “Using Interface Repositories”.
Setting the return value
After invoking the ServerRequest object's arguments method, the value of the name parameter can be extracted and used to create a new Account object. An Any object is created to hold the newly created Account object, which is returned to the caller by invoking the ServerRequest object's set_result method.
Server implementation
The implementation of the main routine, shown in the following code sample, is almost identical to the original example in “Developing an example application with VisiBroker”.
import org.omg.PortableServer.*;
public class Server {
public static void main(String[] args) {
try {
// Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
// Get a reference to the root POA
POA rootPoa =
POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
// Get the POA Manager
POAManager poaManager = rootPoa.the_POAManager();
// Create the account POA with the right policies
org.omg.CORBA.Policy[] accountPolicies = {
rootPoa.create_servant_retention_policy(
ServantRetentionPolicyValue.NON_RETAIN),
rootPoa.create_request_processing_policy(
RequestProcessingPolicyValue.USE_DEFAULT_SERVANT)
};
POA accountPOA = rootPoa.create_POA("bank_account_poa",
poaManager, accountPolicies);
// Create the account default servant
AccountImpl accountServant = new AccountImpl(orb, accountPOA);
accountPOA.set_servant(accountServant);
// Create the manager POA with the right policies
org.omg.CORBA.Policy[] managerPolicies = {
rootPoa.create_lifespan_policy(LifespanPolicyValue.PERSISTENT),
rootPoa.create_request_processing_policy(
RequestProcessingPolicyValue.USE_DEFAULT_SERVANT)
};
POA managerPOA = rootPoa.create_POA("bank_agent_poa",
poaManager, managerPolicies);
// Create the manager default servant
AccountManagerImpl managerServant = new AccountManagerImpl(orb,
accountServant);
managerPOA.set_servant(managerServant);
// Activate the POA Manager
poaManager.activate();
System.out.println("AccountManager is ready");
// Wait for incoming requests
orb.run();
} catch(Exception e) {
e.printStackTrace();
}
}
}
DSI implementation is instantiated as a default servant and the POA should be created with the support of corresponding policies. For more information see “Using POAs”.