Hi, Stephen.
Stephen Connolly wrote:
>
>
> On Feb 8, 2008 12:57 PM, Jagadish Prasath Ramu <Jagadish.Ramu_at_sun.com
> <mailto:Jagadish.Ramu_at_sun.com>> wrote:
>
>
> > If it does, how does it work, does it transfer the resource adapter
> > classes to the client machine and start a connection pool on the
> > application client's JVM, or does it do some form of remote
> proxying?
> No, resource adapter classes need to be made accessible for the
> appclient container (eg: classpath)
> A separate connection pool will be created within the Appclient
> container's JVM.
>
>
> That is a pity, I was hoping to be able to keep the one pool and have
> it route through the JavaEE container. If the app client starts its
> own pool it will not be able to connect due to the firewall settings
> between the EIS and the network in general (basically it will only
> accept connections from designated servers, and we were going to list
> the JavaEE server as one of the valid connection sources. We cannot do
> that for every Application Client as that could be the entire internet)
>
I think I understand what you are trying to accomplish; let me restate a
couple things to make sure I understand what you mean.
What you are trying to set-up looks like this:
client ---
\
client --- +-- Java EE server ---- FIREWALL ----- EIS
/
client ---
...
For security reasons you want to authorize only a fixed set of systems
access through the firewall to the EIS.
As Jagadish mentioned, for some applications having the resource adapter
as part of the app client is perfectly reasonable, and that leads to
clients connecting directly to the EIS. Some developers want or need
this behavior, so there is no automatic tunneling of resource adapter
traffic from clients through the GlassFish server. Further, there is no
way of turning on such automatic traffic.
I can think of a few ways you might address this. Here's the one that
I'd advise, although that's dangerous given how little I know about your
full set of requirements!
1. Build or add one or more EJBs into your server application. These
EJBs use the resource adapter to contact the EIS.
2. Write the clients to invoke methods on those EJBs when they need to
exchange information with the EIS.
Done this way you need to authorize only the server for access through
the firewall to the EIS yet all clients can make use of the EIS's
services, although indirectly.
This requires a little rethinking about how the clients would be
implemented from what you described. To my mind, having them invoke
methods on EJBs is simpler than having them work with resource adapters.
An additional benefit of the EJB design is that the client logic - and
therefore the client code installed on the client systems - is insulated
from changes in how the connection to the EIS must be done. Maybe that
sort of change seems unlikely now but the EJB-based design is a very
low-cost way to build that independence into your client. The client
logic also takes on the higher-level flavor of the business requirements
(customerService.getCustomer() or inventoryService.addItem(), for
example) instead of getting a connection to the RA and sending messages
on it).
Coding such a client is quite easy as well, because you can use
annotations to simplify the references to the EJBs.
Is this sort of design an option for you?
- Tim