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 idl2cpp 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
idl2cpp compiler.
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.
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);
};
};
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.
class PortableServer::DynamicImplementation : public virtual PortableServer::ServantBase {
public:
virtual void
invoke(PortableServer::ServerRequest_ptr request) = 0;
. . .
};
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.
class AccountImpl : public PortableServer::DynamicImplementation {
public:
AccountImpl(PortableServer::Current_ptr current,
PortableServer::POA_ptr poa)
: _poa_current(PortableServer::Current::_duplicate(current)),
_poa(poa)
{}
CORBA::Object_ptr get(const char *name) {
CORBA::Float balance;
// Check if account exists
if (!_registry.get(name, balance)) {
// simulate delay while creating new account
VISPortable::vsleep(3);
// Make up the account's balance, between 0 and 1000 dollars
balance = abs(rand()) % 100000 / 100.0;
// Print out the new account
cout << "Created " << name << "'s account: " << balance << endl;
_registry.put(name, balance);
}
// Return object reference
PortableServer::ObjectId_var accountId =
PortableServer::string_to_ObjectId(name);
return _poa->create_reference_with_id(accountId, "IDL:Bank/
Account:1.0");
}
private:
AccountRegistry _registry;
PortableServer::POA_ptr _poa;
PortableServer::Current_var _poa_current;
CORBA::RepositoryId
_primary_interface(
const PortableServer::ObjectId& oid, PortableServer::POA_ptr poa) {
return CORBA::string_dup((const char *)"IDL:Bank/Account:1.0");
};
void
invoke(CORBA::ServerRequest_ptr request) {
// Get the account name from the object id
PortableServer::ObjectId_var oid = _poa_current->get_object_id();
CORBA::String_var name;
try {
name = PortableServer::ObjectId_to_string(oid);
} catch (const CORBA::Exception& e) {
throw CORBA::OBJECT_NOT_EXIST();
}
// Ensure that the operation name is correct
if (strcmp(request->operation(), "balance") != 0) {
throw CORBA::BAD_OPERATION();
}
// Find out balance and fill out the result
CORBA::NVList_ptr params = new CORBA::NVList(0);
request->arguments(params);
CORBA::Float balance;
if (!_registry.get(name, balance))
throw CORBA::OBJECT_NOT_EXIST();
CORBA::Any result;
result <<= balance;
request->set_result(result);
cout << "Checked " << name << "'s balance: " << balance << endl;
}
};
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.
class AccountManagerImpl : public PortableServer::DynamicImplementation {
public:
AccountManagerImpl(AccountImpl* accounts) { _accounts = accounts; }
CORBA::Object_ptr open(const char* name) {
return _accounts->get(name);
}
private:
AccountImpl* _accounts;
CORBA::RepositoryId _primary_interface(
const PortableServer::ObjectId& oid,
PortableServer::POA_ptr poa) {
return CORBA::string_dup((const char *)"IDL:Bank/AccountManager:1.0");
};
void
invoke(CORBA::ServerRequest_ptr request) {
// Ensure that the operation name is correct
if (strcmp(request->operation(), "open") != 0)
throw CORBA::BAD_OPERATION();
// Fetch the input parameter
char *name = NULL;
try {
CORBA::NVList_ptr params = new CORBA::NVList(1);
CORBA::Any any;
any <<= (const char*) "";
params->add_value("name", any, CORBA::ARG_IN);
request->arguments(params);
*(params->item(0)->value()) >>= name;
} catch (const CORBA::Exception& e) {
throw CORBA::BAD_PARAM();
}
// Invoke the actual implementation and fill out
//the result
CORBA::Object_var account = open(name);
CORBA::Any result;
result <<= account;
request->set_result(result);
}
};
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:
|
2
|
Add “IDL:” to the beginning of the string.
|
|
3
|
Add “:1.0” to the end of the string.
|
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.
class CORBA::ServerRequest {
public:
const char*
op_name() const { return _operation; }
void
params(CORBA::NVList_ptr);
void
result(CORBA::Any_ptr);
void
exception(CORBA::Any_ptr exception);
...
CORBA::Context_ptr
ctx() {
...
}
// POA spec methods
const char *
operation() const { return _operation; }
void
arguments(CORBA::NVList_ptr param) { params(param); }
void
set_result(const CORBA::Any& a) { result(new CORBA::Any(a)); }
void
set_exception(const CORBA::Any& a) {
exception(new CORBA::Any(a));
}
};
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.
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.
Like the Account object, the
AccountManager interface also declares one method. However, the
AccountManagerImpl object's
open 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.
The following are the steps the AccountManagerImpl object's
invoke 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's arguments 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's
arguments method is invoked to obtain the values of all of the parameters in the list.
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's
create_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”.
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.
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”.