To complete the implementation of the server object code, we must derive from the AccountPOA and AccountManagerPOA classes, provide implementations of the interfaces' methods, and implement the server's main routine.
You then use the idl2cpp compiler to generate stub routines and servant code compliant with the IDL specification. The stub routines are used by your client program to invoke operations on an object. You use the servant code, along with code you write, to create a server that implements the object.
The sample below shows the contents of the Bank.idl file for the bank_agent example. The Account interface provides a single member function for obtaining the current balance. The AccountManager interface creates an account for the user if one does not already exist.
module Bank{
interface Account {
float balance();
};
interface AccountManager {
Account open(in string name);
};
};
interface Account {
float balance();
};
interface AccountManager {
Account open(in string name);
};
};
The interface specification you create in IDL is used by VisiBroker's idl2cpp to generate C++ stub routines for the client program, and skeleton code for the object implementation.
Because the Bank.idl file requires no special handling, you can compile the file with the following command.
|
•
|
|
•
|
Bank_c.cc: Contains internal stub routines used by the client.
|
|
•
|
|
•
|
Bank_s.cpp: Contains the internal routines used by the server.
|
You will use the Bank_c.hh and Bank_c.cpp files to build the client application. The Bank_s.hh and Bank_s.cpp files are for building the server object. All generated files have either a .cpp or .hh suffix to help you distinguish them from source files.
The default suffix for generated files from the idl2cpp compiler is .cpp. However, the Makefiles associated with the examples for VisiBroker Edition use the -src suffix to change the output to the specified extension.
You should never modify the contents of files generated by the idl2cpp compiler.
Many of the classes used in implementing the bank client are contained in the Bank code generated by the idl2cpp compiler as shown in the previous example.
The Client.C file illustrates this example and is included in the bank_agent directory. Normally, you would create this file.
The Client program implements the client application which obtains the current balance of a bank account. The bank client program performs these steps:
|
2
|
Binds to an AccountManager object.
|
|
3
|
|
4
|
Before your client program can invoke the open(String name) member function, the client must first use the bind() member function to establish a connection to the server that implements the AccountManager object.
The implementation of the bind() member function is implemented automatically by idl2cpp. The bind() member function requests the VisiBroker ORB to locate and establish a connection to the server.
If the server is successfully located and a connection is established, a proxy object is created to represent the server's AccountManagerPOA object. A pointer is returned to your client program.
Next, your client program needs to call the open() member function on the AccountManager object to get a pointer to the Account object for the specified customer name.
Once your client program has established a connection with an Account object, the balance() member function can be used to obtain the balance. The balance() member function on the client side is actually a stub generated by the idl2cpp compiler that gathers all the data required for the request and sends it to the server object.
Several other member functions are provided that allow your client program to manipulate an AccountManager object reference.
Just as with the client, many of the classes used in implementing the bank server are contained in the header files of Bank generated by the idl2cpp compiler. The Server.C file is a server implementation included for the purposes of illustrating this example. Normally you, the programmer, would create this file.
The Account class that you implement is derived from the POA_Bank::Account class that was generated by the idl2cpp compiler. Look closely at the POA_Bank::Account class definition that is defined in the Bank_c.hh file and notice that it is derived from the Account class. The figure below shows the class hierarchy.
The examples directory of your VisiBroker Edition release contains a Makefile.cpp for this example and other VisiBroker examples.
The Client.C that you created and the generated Bank_c.cc file are compiled and linked together to create the client program. The Server.C file that you created, along with the generated Bank_s.cpp and the Bank_c.cpp files, are compiled and linked to create the bank account server. Both the client program and the server must be linked with the VisiBroker ORB library.
The examples directory also contains a file named stdmk (for UNIX) or stdmk_nt (for Windows NT), and defines file location and variable settings to be used by the Makefile.
You may need to customize the stdmk or stdmk_nt file if your compiler does not support the specified flags.
Assuming VisiBroker is installed in C:\vbroker, type the following to compile the example:
If you encounter some problems while running make, check that your path environment variable points to the bin directory where you installed the VisiBroker Edition software.
Also, try setting the VBROKERDIR environment variable to the directory where you installed the VisiBroker Edition software.
Assuming VisiBroker is installed in /usr/local, type the following to compile the example:
In this example, make is the standard UNIX facility. If you do not have it in your PATH, see your system administrator.
Start your Account server by typing:
|
•
|
The VisiBroker libraries, located in the bin sub-directory where the product is installed.
|
If the deployed application is to use a Smart Agent (osagent) on a particular host, you must set the OSAGENT_ADDR environment variable before running the application. You can use the ORBagentAddr property as a command-line argument to specify a hostname or IP address. The table in “Support service availability” lists the necessary command-line arguments.
If the deployed application is to use a particular UDP port when communicating with a Smart Agent, you must set the OSAGENT_PORT environment variable before running the application.
You can use the ORBagentPort (C++) command-line argument to specify the IP port number.
For more information about environment variables, see the VisiBroker Installation Guide.
|
A deployed application uses either the dynamic skeleton interface or dynamic implementation interface. See “Using Interface Repositories” for a description of these interfaces.
|
|
Before you attempt to run VisiBroker Edition client programs or server implementations, you must first start the Smart Agent on at least one host in your local network. The Smart Agent is described in detail in “Using the Smart Agent”
|
If set to 1, this option specifies that support for the 1.0 IDL-to-C++ mapping should be provided. If set to 0 or not specified at all, the new 1.1 mapping will be used. The default setting is 0. If -ORBbackcompat is set to 1, this option will automatically be set to 1.
|
|
|
Specifies the name of the Interface Repository to be accessed when the Object::get_interface() method is invoked on object implementations.
|
|
|
Specifies the IOR of the Interface Repository to be accessed when the Object::get_interface() method is invoked on object implementations.
|
|
|
If set to 1, this option specifies that the VisiBroker ORB will allow C++ NULL strings to be streamed. The NULL strings will be marshaled as strings of length 0 opposed to the empty string (“”) which is marshaled as a string of length 1, with the sole character of \0. If set to 0, attempts to marshal out a NULL string will throw CORBA::BAD_PARAM. Attempts to marshal in a NULL string will throw CORBA::MARSHAL. The default setting is 0. If -ORBbackcompat is set to 1, this option will automatically be set to 1.
|
|
|
When set to 1, it sets all sockets to immediately send requests. The default value of 0 allows sockets to send requests in batches as buffers fill. This argument can be used to significantly impact performance or benchmark results.
|