That's the design I had come to!
Basically I'm writing the EIS client library...
The EIS client library has to support callbacks.
For a JavaSE client, this is simple as the call backs are just standard
PropertyChangeListeners on the objects from the EIS datamodel.
Due to the EJB spec, I cannot have the EJBs register for these callbacks. I
was planning on using the resource adapter to provide the inbound events...
Basically the resource adapter uses the JavaSE client library, splits the
callbacks through the inbound connection, and the outbound connection is
mapped to the JavaSE datamodel.
On the caller's side (which is a JavaEE application client), I now have to
have two shim layers.
JavaSE client lib <----> Resource Adapter Shim <----> EJB Shim <------>
JavaEE client lib <-----> JavaEE application client
Oh did I mention that I want both client libs to have the same API, so that
a swing based client can be written to work with the JavaSE client and
trivially ported to be a JavaEE application client
-Stephen
On Feb 13, 2008 4:22 PM, Tim Quinn <Timothy.Quinn_at_sun.com> wrote:
> Hi, Stephen.
>
> Stephen Connolly wrote:
>
>
>
> On Feb 8, 2008 12:57 PM, Jagadish Prasath Ramu <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
>