The code for the example application is provided in the bank_agent_java.html file. You can find this file in:
IDL is the language that an implementer uses to specify the operations that an object will provide and how they should be invoked. In this example, we define, in IDL, the Account interface with a balance() method and the AccountManager interface with an open() method.
With the interface specification described in step 1, use the idl2java or idl2cpp compilers to generate the client-side stubs and the server-side classes for the implementation of the remote objects.
To complete the implementation of the client program, initialize the VisiBroker ORB, bind to the Account and the AccountManager objects, invoke the methods on these objects, and print out the balance.
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 idl2java 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 method 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 idl2java compiler to generate Java classes 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.
Because Java allows only one public interface or class per file, compiling the IDL file will generate several .java files. These files are stored in a generated sub-directory called Bank, which is the module name specified in the IDL and is the package to which the generated files belong. The following is a list of .java files generated:
|
•
|
_AccountManagerStub.java: Stub code for the AccountManager object on the client side.
|
|
•
|
_AccountStub.java: Stub code for the Account object on the client side.
|
|
•
|
Account.java: The Account interface declaration.
|
|
•
|
AccountHelper.java: Declares the AccountHelper class, which defines helpful utility methods.
|
|
•
|
AccountHolder.java: Declares the AccountHolder class, which provides a holder for passing Account objects.
|
|
•
|
AccountManager.java: The AccountManager interface declaration.
|
|
•
|
AccountManagerHelper.java: Declares the AccountManagerHelper class, which defines helpful utility methods.
|
|
•
|
AccountManagerHolder.java: Declares the AccountManagerHolder class, which provides a holder for passing AccountManager objects.
|
|
•
|
AccountManagerOperation.java: This interface provides the method signatures defined in the AccountManager interface in Bank.idl.
|
|
•
|
AccountManagerPOA.java: POA servant code (implementation base code) for the AccountManager object implementation on the server side.
|
|
•
|
AccountManagerPOATie.java: Class used to implement the AccountManager object on the server side using the tie mechanism, described in “Using the tie mechanism”.
|
|
•
|
AccountOperations.java: This interface provides the method signatures defined in the Account interface in the Bank.idl file
|
|
•
|
AccountPOA.java: POA servant code (implementation base code) for the Account object implementation on the server side.
|
|
•
|
AccountPOATie.java: Class used to implement the Account object on the server side using the tie mechanism, described in “Using the tie mechanism”.
|
Many of the classes used in implementing the bank client are contained in the Bank package generated by the idl2java compiler as shown in the previous example.
The Client.java file illustrates this example and is included in the bank_agent directory. Normally, you would create this file.
The Client class 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) method, the client must use the bind() method to establish a connection to the server that implements the AccountManager object.
The implementation of the bind()method is generated automatically by the idl2java compiler. The bind() method 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. An object reference to the AccountManager object is returned to your client program.
Next, your client class needs to call the open() method on the AccountManager object to get an object reference to the Account object for the specified customer name.
Once your client program has established a connection with an Account object, the balance() method can be used to obtain the balance. The balance() method on the client side is actually a stub generated by the idl2java compiler that gathers all the data required for the request and sends it to the server object.
This file is located in the Bank package. It contains an AccountManagerHelper object and defines several methods for binding to the server that implements this object. The bind() class method contacts the specified POA manager to resolve the object. Our example application uses the version of the bind method that accepts an object name, but the client may optionally specify a particular host and special bind options. For more information about Helper classes, see the VisiBroker Programmer's Reference.
package Bank;
public final class AccountManagerHelper {
...
public static Bank.AccountManager bind(org.omg.CORBA.ORB orb) {
return bind(orb, null, null, null);
...
}
}
public final class AccountManagerHelper {
...
public static Bank.AccountManager bind(org.omg.CORBA.ORB orb) {
return bind(orb, null, null, null);
...
}
}
Several other methods are provided that allow your client program to manipulate an AccountManager object reference.
Many of these methods and member functions are not used in the example client application, but they are described in detail in the VisiBroker Programmer's Reference.
Just as with the client, many of the classes used in implementing the bank server are contained in the Bank package generated by the idl2java compiler. The Server.java file is a server implementation included for the purposes of illustrating this example. Normally you, the programmer, would create this file.
The examples directory of your VisiBroker release contains a vbmake.bat for this example and other VisiBroker examples.
Assuming VisiBroker is installed in C:\vbroker, type the following to compile the example:
If you encounter problems while running vbmake, check that your path environment variable points to the bin directory where you installed the VisiBroker 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:
|
•
|
VisiBroker Java packages archived in the vbjorb.jar file, located in the lib subdirectory where you installed VisiBroker.
|
When you use the vbj executable, the environmental variables are automatically set up for you.
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 vbroker.agent.addr property as a command-line argument to specify a hostname or IP address. The table below 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 vbroker.agent.port (Java) command-line argument to specify the UDP port number.
|
A deployed application uses either the dynamic skeleton interface or dynamic implementation interface. See “Using Interface Repositories” for a description of these interfaces.
|
|
You can use the vbj command to start your application and enter command-line arguments that control the behavior of your application.
Before you attempt to run VisiBroker client programs or server implementations, you must start the Smart Agent on at least one host in your local network. The Smart Agent is described in detail in “Starting the Smart Agent”.
A client may be started with the vbj command, or from within a Java-enabled web browser.
|
Specifies the size of the intermediate buffer used by VisiBroker for operation request processing. To improve performance, the VisiBroker ORB does more complex buffer management than in previous versions of VisiBroker. The default size of send and receive buffers is 4—4kb. If data sent or received is larger than the default, new buffers will be allocated for each request/reply. If your application frequently sends data larger than 4kb and you wish to take advantage of buffer management, you may use this system property to a specify a larger number of bytes for a default buffer size.
|
|
|
When set to true, all network connections will send data immediately. The default is false, which allows a network connection to send data in batches, as the buffer fills.
|
|
|
Specifies the maximum number of connections allowed for an object implementation when OAid TSession is selected. If you do not specify a value, the default is unlimited.
|
|
|
Specifies the number of milliseconds which a network connection can be idle before being shutdown by VisiBroker. By default, this is set to 360 which means that connections will never time-out. This option should be set for Internet applications.
|
A server application is one that offers one or more VisiBroker ORB objects to client applications. A server application may be started with the vbj command or it may be activated by the Object Activation Daemon (oad).
|
-DOAport <port_number>
|
|
|
Specifies the maximum number of threads allowed when OAid TPool is selected. If you do not specify or you specify 0, this selects unlimited number of threads or, to be more precise, a number of threads limited only by your system resources.
|
|
|
Specifies the minimum number of threads available in the thread pool. If you do not specify, the default is 0. You can specify this only when OAid TPool is selected.
|
|
|
Specifies the maximum number of connections allowed when OAid TSession is selected. If you do not specify, the default is unlimited.
|
|
|
Specifies the time which a connection can idle without any traffic. Connections that idle beyond this time can be shutdown by VisiBroker. By default, this is set to 0, meaning that connections will never automatically time-out. This option should be set for Internet applications.
|