|
Figure 11
|
|
Figure 12
|
The way to specify the paths to the server is described in “Specifying communication paths to the server”.
|
Figure 13
|
With bidirectional IIOP, servers use the client-initiated connections to transmit asynchronous information back to the clients. Servers need not initiate any connections to the client. The CORBA specification also adds a new policy to portably control this feature. For information about bidirectional communications exclusive of the GateKeeper, see the VisiBroker for Java Developer's Guide or VisiBroker for C++ Developer's Guide for more information.
You can also selectively set the channels to unidirectional or bidirectional. If the client defines vbroker.orb.enableBiDir=client and the server defines vbroker.orb.enableBiDir=server, the following table describes the type of channels for the different values of vbroker.orb.enableBiDir for GateKeeper.
An example that demonstrates GateKeeper's support for bidirectional connections is located in the examples/vbroker/gatekeeper/bank_bidir subdirectory under the VisiBroker installation.
In this example, the client Client.java:
|
1
|
Creates a callback object on the POA named callback_poa. (This callback object will be invoked by the server through the GateKeeper.)
|
|
2
|
Binds to the AccountManager object.
|
|
3
|
Sends the object reference of this callback object to the server by opening a bank account by invoking open() and passing the callback object as an argument.
|
|
4
|
Queries the Account object reference obtained for the balance, again passing the callback object (this time it is passed to the balance method).
|
In the example, the server Server.java:
|
1
|
Creates a persistent POA named bank_poa and a transient POA named account_poa with firewall policy value of EXPORT.
|
|
2
|
Creates an instance of the AccountManager servant.
|
|
3
|
Activates that servant on bank_poa.
|
|
Property file used to configure the bank server. In this example, the server is configured to accept listen points so that the connection between the GateKeeper and the server will be bidirectional. To make the connection unidirectional, either remove the property vbroker.orb.enableBiDir or set the value of this property to none. The other properties in this file are for loading the firewall package and then setting the firewall path so that server-side objects can be bound and called by the client.
|
|
|
Property file used to configure the bank client. In this example, the client is configured to publish its listen points so that the connection between the client and the GateKeeper will be bidirectional. To make the connection unidirectional, either remove the vbroker.orb.enableBiDir property or set its value to none. As with the server, the vbroker.orb.dynamicLibs property is set to load in the necessary firewall library so that the client request can traverse the GateKeepers.
|
|
For security reasons, a server running VisiBroker for Java will not use bidirectional IIOP unless explicitly configured to do so. The property vbroker.se.<sename>.scm.<scmname>.manager.importBiDir gives you control of bidirectionality on a per-SCM basis. For example, you might choose to enable bidirectional IIOP only on a server engine that uses SSL to authenticate the client, and to not make other, regular IIOP connections available for bidirectional use. (See “Appendix GateKeeper properties” for more information about how to do this.) In addition, on the client-side, you might want to enable bidirectional connections only to those servers that do callbacks outside of the client firewall. To establish a high degree of security between the client and server, you should use SSL with mutual authentication (set vbroker.security.peerAuthenticationMode to REQUIRE_AND_TRUST on both the client and server).
All rules are evaluated in the order in which you specify them. Action is taken based on the first matched rule. If there is no matched rule, the default action you specify is taken. See , “Appendix GateKeeper properties” for the syntax of the rules.
Access Controllers use the TcpConnectionInfo interface to get more information about the Client:
The Access Control Manager calls the init method to initialize the Access Controller. GateKeeper supports the following types of Access Controller interfaces:
|
•
|
ObjectAccessController: The isObjectAccessible() method is invoked when the client requests GateKeeper to set up a proxy channel (communication path) to the server object. It should return true if the object is accessible:
|
|
•
|
OperationAccessController: The isOperationAccessible() method is invoked when the client sends requests through the GateKeeper. It should return true if a given operation is accessible:
|
You can program an access controller (for example, myAC) and install it on GateKeeper using following properties:
|
Figure 16
|
The ORB default implementation of load distribution uses the round-robin algorithm in which the client request is shared among a server and GateKeeper in a sequential order. The following code example shows a distributor implementation:
|
•
|
Throughput is reduced: It may be reduced by as much as 50 percent when compared to the direct scenario.
|
|
•
|
Response Time is slowed: Response time will take longer when compared to the direct scenario. In some cases, it may take up to 200 percent longer.
|
|
•
|
Constraint on Bid-Portfolio: The following properties are useful for setting exclusive bids in the case of static chaining of GateKeeper:
|
|
•
|
Order of Bid-Selection: The order of the bid can affect the speed of the selection of a specific bid. For example, if you are certain that most of the connections allowed on a specific GateKeeper will be of a secure type, you can place the SSL as the first entry in the string as follow:
|
|
•
|
Specifying high-precedence Bid: You can set the following property to the highest precedence bid. By default, it is set to inprocess in the ORB:
|
Depending on the response needs of GateKeeper, different techniques of thread management can be applied, such as thread pooling, thread-per-session, and so forth. By default, the request forwarding IIOP service uses ThreadPool, and the HIOP service uses ThreadSession:
The bi-directional GIOP has advantages of using the same communication path for forward and backward communication. Therefore, Micro Focus recommends that you use the vbroker.orb.enableBiDir property setting in callback scenarios. The following properties let you optimize connection resource usage (see “Appendix GateKeeper properties” for more details):
vbroker.ce.iiop.ccm.connectionMax should not be used in the context of GateKeeper, because GateKeeper should be allowed to connect to as many servers as needed as it is an intermediate service to potentially many clients. GateKeeper must not stop already connected clients from proceeding with connections to servers just because the number of outgoing connections it can open is limited. Instead, GateKeeper can restrict the number of clients it is willing to service using the following property:
vbroker.ce.iiop.ccm.connectionMaxIdle, however, can be used to drop idle connections to servers. This is particularly useful when the number of servers the GateKeeper would potentially connect to is large, the number of connecting clients is small, and the clients mainly target only a few servers.
For more information, see “Performance and load balancing” for additional properties that can be adjusted for better performance.
vbroker.se.<xxx>.scm.<yyy>.manager.connectionMax
vbroker.se.<xxx>.scm.<yyy>.manager.connectionMaxIdle
vbroker.se.<xxx>.scm.<yyy>.manager.connectionMaxIdle
For more information about SSL, refer to the VisiBroker Security Guide. Additional properties for setting SSL can also be found in “Appendix GateKeeper properties”.
|
Figure 17
|
If the client sets vbroker.orb.alwaysSecure=true in its property file, it will always connect to the Server or GateKeeper in SSL mode and will not first try other types of connections (which may fail if the Server or GateKeeper does not accept other types of connection). This shortens the time for connections.
You must create *.config files (examples shown below) to specify the authentication and realm related parameters.