Deploying application for remote EJB access

[Rob Micah]

Guys, I'm looking for some constructive criticism or feedback on what I'm doing. I'm attempting to deploy an application with an EJB that has remote access so other applications can use its logic. My EJB has a JPA persistence unit in it. So my strategy looks like this:

1. Assemble EJB class and persistence.xml into a jar (ejb.jar).
2. Assemble the remote EJB interface and persistence classes into a jar (remote.jar).
3. Assemble both jars into an ear and deploy on a local glassfish instance.
4. Put the remote.jar and hibernate jar(s) somewhere on the remote machine in the classpath of the remote glassfish instance.
5. Build and deploy remote application on remote server using jars from previous step.

Does this sound like I'm using the right approach? So far all my EJB work has been local so any feedback is appreciated.

[K. Tsang]

What kind of functions are you building for this so-called "remote access"?

Just wondering, will web services be a better approach?

The dependent libraries (eg JPA, hibernate etc) will be bundled with the jar file. I don't recommend relying on the app server's classpath libraries.

[Rob Micah]

By remote access, I meant defining a Remote interface for my EJBs. Mainly the clients will be web applications who consume the business methods of the remote EJBs and format the results for return through a JAX-WS web service. But there will be a few application clients as well.

[K. Tsang]

Rob Micah wrote:By remote access, I meant defining a Remote interface for my EJBs. Mainly the clients will be web applications who consume the business methods of the remote EJBs and format the results for return through a JAX-WS web service. But there will be a few application clients as well.

Ah like I thought "...return through a JAX-WS web service". You ought to develop web service rather than just EJB.

When it comes to web service, you can choose SOAP (JAX-WS) or REST (JAX-RS).

[Rob Micah]

My question isn't really which API to use, but rather how to package the core logic so it is not repeated all over the place. That's why I was thinking of remote interfaces.

[K. Tsang]

Assume you going the web service route, you will only need 1 set of files.

If not, you probably need 2 sets (like one local and another remote). This approach surely will make maintenance harder.

[Rob Micah]

Yes, that's what I was thinking as well. But I may wind up with 5 or more different applications that need the same core functionality and each of those applications may be fairly large on their own. How do most people approach this problem?

[K. Tsang]

Rob Micah wrote:Yes, that's what I was thinking as well. But I may wind up with 5 or more different applications that need the same core functionality and each of those applications may be fairly large on their own. How do most people approach this problem?

Then you need to design the web service functions by application (segregation of concern).

If there are indeed common to 2 or more apps, have a common/core web service app and use that.

Looking at it, you may end up having multiple web service apps