Home/ Questions/Q 7974757
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T08:28:04+00:00

Case: Developing a standalone java client which will run on different locations on multiple

  • 0

Case:
Developing a standalone java client which will run on different locations on multiple user desktops.
Application server(Oracle Weblogic) will be running at centralized location in different place.

Now I want to access/call EJB (Session Bean) running on central server from client.
As client and server are on different location and not connected via Intranet or LAN only medium of connection is internet.

My question is how can I call EJB’s in server directly from client without using a servlet/JSP layer in between?

EJB was devised for remote access , why a servlet dependency?

I have read that RMI-IIOP can be used to make this type of connection but I am unable to use RMI-IIOP over internet!

What is the best architecture/solution for this type of remote communication?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There is no servlet dependency. There is a custom client/protocol dependency that’s app server specific. Each server has their own way of setting up the connection, manifested through configuring JNDI for the proper providers and protocol handlers.

    Why won’t RMI-IIOP work over the internet? The only potential issue I can see there is security, I don’t know if there’s an encrypted version of RMI-IIOP or not, but other than that, it’s a perfectly routable protocol.

    You may run in to port and firewall issues, but that’s not the protocols fault. If you want to run RMI-IIOP over port 80 (http’s port), then that’s fine (obviously it won’t be http, nor work with http proxies, but again, that’s not the protocols issue).

    Weblogic also has (had?) their own protocol, T3? I think it was? Can you use that?

    I think the key is why you don’t think you can run RMI-IIOP “over the internet”, and trying to solve that problem, not necessarily what protocol to use.

    • 0