Using J-Integra with a Firewall or Load Balancer |
|
Contents
- Introduction
- Non-NAT Based Firewalls
- NAT Firewalls
- Load Balancers with J-Integra's DCOM Mode
- Load Balancers with J-Integra's Native Mode
- A VB Program to Test DCOM Connection
1. Introducation
You may still get one of these errors after configuring DCOM if you use J-Integra in DCOM mode with firewalls or load balansers:
AutomationException: 0x80070005 - General access denied error
AutomationException: 0x5 - Access is denied
There are some limiations in DCOM itself involving firewalls or load balancers. This is not caused by J-Integra and happens in all DCOM applications including VB and VC++ programs.
2. Non-NAT Based Firewalls
J-Integra uses DCOM, layered over TCP/IP to talk from a Java client to a COM component. A DCOM application needs to open a socket to port 135 on the NT box to send a DCOM "remote activation" request to the DCOM SCM (a kind of daemon thread). The SCM then starts up the COM server and returns the port on which it has been started back to J-Integra. J-Integra then opens a socket to that port.
So the first port (135) must be opened, however the second port (an arbitrary port returned by the SCM) is more of an issue. From NT4 SP4 onwards it should be possible to restrict the range of ports returned by the SCM using DCOMCNFG (Start|Run|DCOMCNFG->Default Protocols->Connection Oriented TCP/IP->Properties).
It is also possible to tell J-Integra what range of local ports should be used when connecting to COM servers, by setting the JINTEGRA_LOCAL_PORT_START and (optionally) the JINTEGRA_LOCAL_PORT_END properties. The runtime will try to use these ports, and will cycle back to the start if the last port is reached (an IOException is thrown if all ports in the range are already in use locally).
Microsoft References
3. NAT Firewalls
Currently, DCOM cannot be used over NAT (Network Address Translation) firewalls, and thus J-Integra will not work over NAT firewalls either.
When the Java and COM subsystems are located on different machines and separated by a NAT firewall, method calls from either of the subsystems may fail with an error such as "0x800706BA (RPC_S_SERVER_UNAVAILABLE)". The calls may also hang, with no errors logged immediately.
Microsoft References
4. Load Balancers with J-Integra's DCOM Mode
"Even though you can configure the port used by the client to communicate with the server, the client must be able to reach the server by its actual IP address. You cannot use DCOM through firewalls that do address translation (e.g. where a client connects to virtual address 198.252.145.1, which the firewall maps transparently to the server's actual address of, say, 192.100.81.101). This is because DCOM stores raw IP addresses in the interface marshaling packets and if the client cannot connect to the address specified in the packet, it will not work." - Quote from Microsoft Knowledge Base Article - 154596
DCOM cannot work behind a load balancer which hides the actual IP of a server from the client, and thus J-Integra will not work in this scenario either. However, Microsoft offers a software solution for component load balancing on Windows 2000. As well, Microsoft cluster server can be used for NT 4.0/Win2000 and DCOM.
Microsoft References
5. Load Balancers with J-Integra's Native Mode
However it is possible to use a Load Balancer in native mode. The steps below shows an example of using BEA WebLogic server for J-Integra clustering. The source code can be downloaded below.
Steps for J-Integra clustering:
- Configure Environment variables and JVM id using regjvm
Set system Environment Variables from Start > Settings > Control Panel > System > Advanced > Environment Variables > System variables. Do not use command-line to add a temporary CLASSPATH or PATH.
The CLASSPATH environment variable should include the following:
.;C:\jintegra\lib\jintegra.jar;C:\bea\weblogic81\server\lib\weblogic.jar;C:\clustering;C:\clustering\ejb20_basic_statelessSession.jar;
The PATH environment variable should include the following:
.;C:\jintegra\bin\;C:\j2sdk1.4.2_01\bin
Run the regjvm and click on New JVM...
Add simple as the new JVM name and click OK.
Choose Native mode in process.
Check Advanced option.
For JVM choose proper dll by clicking the drop down list.
In my case, I choose C:\j2sdk1.4.2_01\jre\bin\client\jvm.dll
In the Classpath add the following:
.;C:\jintegra\lib\jintegra.jar;C:\bea\weblogic81\server\lib\weblogic.jar;C:\clustering;C:\clustering\ejb20_basic_statelessSession.jar;
Note: In my classpath, I added the jintegra.jar, weblogic.jar and the EJB. I have the Proxy.class in C:\clustering compiled from the Proxy.java, which points to my WebLogic Server instances. Please change them to point to your WebLogic Server instances and compile the class.
Click Save JVM and Close.
- Important: Register the JVM of the Servers on which you deploy the EJB
For example, I deployed the EJB to the managed servers cs1 and cs2. So I have to register the JVM's cs1 and cs2 in the following way:
In the JVM register tool, click New JVM... and add 'cs1' and you can leave the DCOM mode (which is DCOM - pure java). Repeat the same for all the WebLogic Server instances on which you add the EJB.
- Enable native mode of J-Integra
Command Line: java -DJINTEGRA_NATIVE_MODE [MyJavaMainClass]
Java Code: System.setProperty("JINTEGRA_NATIVE_MODE", "");
- Deploy the attached EJB (ejb20_basic_statelessSession.jar) to the WeLogic servers.
- Configure the security setting for the EJB
Add java.util.* to COM class and click Define Security Policy...
In the policy condition, double click Caller is a member of the group.
Add everyone to Enter Group Name and click Add then OK..
Click Apply.
Repeat the above procedure for ejb20.basic.statelessSession.*
- Run the example
Open and run Test.vbp.
Click on the Command1 button.
You will see the following output on one of the WebLogic Server instances:
In Constructor TradeResult
In Constructor method of TradeResult
This indicates that the call flow is like this:
VB Client (invokes the Proxy class) --> the call in turn will go to one of WebLogic Server instances.
6. A VB Program to Test DCOM Connection
To test the DCOM connection, download the VB program below.
This VB program launches Excel on a remote machine. To test it on local machine first, just double click TestDCOM.exe, enter "Excel.Application" as ProgID and "localhost" as IP address, and then click OK, and then you should be able to see a message box pops up saying "Microsoft Excel" if DCOM connection is successfully established. Similarly, to access remote Excel via DCOM, simply enter the IP address of your remote machine.
Because VB cannot dynamically set authentication credentials, you need to make sure that the user running the VB program can also logon to the Excel machine. For example, the VB test program is on machine A, and it accesses Excel on machine B. After DCOM settings have been configured on machine B, you can use "user1", "password1" and "domain1" to logon to machine A and run the VB program. The VB program will only work if you can also use "user1", "password1" and "domain1" to logon to machine B. Otherwise you will get "Run-time error '70': Permission denied".
Once the VB testing program can work with firewall, the Java client will also work.