You've pretty much got the right approach. Not only do you want modularity, but you want a single point for accessing common data. It's re-use and reduced maintenance.
You can package them in separate jars or in the same jar - in a sense, your deployment and maintenance is a separate issue from your architecture.
For ejb-jar.xml you do the following to refer to external resources:
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_2_0.dtd">
So I'm referencing a stateless session bean called eventlogger, a database pool called AmityPool, and a custom resource called TablePool.
Now, JBoss needs a bit more to sort out referencing issues. So, you'll need to provide jboss.xml. This goes in the META-INF directory with ejb-jar.xml.
<configuration-name>Standard Stateless SessionBean</configuration-name>
I've removed the container configurations section that we normally include in our deployment file. It shouldn't effect you, but you can put in the section based on the standardjboss.xml supplied with JBoss. Of course, the bean will need to connect to the resources as if it were a normal client so you'll need to have that code in place.
Hope that gets you on your way.
Does this approach also work with Local references?
I would like a Sessionbean from one application to talk to an Entity bean from the other application locally.
This way I can use the first application as my model plus the standard features, and then as I discover new areas this model can be used in, I simply deploy a new Jar with some session-beans that implements these features using the old model.
I've read somewhere, that the jars must be in the same ear. Is that correct?
Is there any changes in your deployment-code, that is needed to make this Local-approach work?
I'm not sure what you mean by locally. If you mean that they are in the same container then yes this is what this is the purpose for these reference declarations. You create a blank initial context in the calling bean, do what you would normally do to connect to the bean so if bean A is calling bean B, bean A is really no different to a remote client.
See this for more information:
My example works for beans in different jars. As the document points out, if they are in the same jar, you need to include an <ejb-link> tag in ejb-jar.xml. Note that the <ejb-link> tag is container dependent.
This article covers some more about linked EJBs.
Hope that clarifies things.
With locally I mean by using Local Objects. I don't know how much the extra time is for a call to a bean by its remote interface compared with a call to its local object, but it gives me the advantage that I from my Session bean of my application 2, that calls the "model"-application can use the components of the "model"-application directly, without implementing anything in that "model"-application.
In my model application I only implement the getXXX()/setXXX(..) methods in the LocalObject-interfaces in my CMP-based beans.
OK. I see where you are going with this. In CMP 2.0 you can make a CMP Bean only accessible intracontainer. The local home and local interfaces cannot be accessed from outside the container.
See the following tutorial:
You pretty much follow the same process for declaring the resource in your xml.
Try this for a fairly straightforward tutorial.
Now, I haven't tried this yet but I vaguely remember seeing the coding for JBoss and it looked pretty much compliant with the tutorial. The jboss.xml will still need the JNDI binding much as for standard remote calls. I think the only time saving you will have is not having to work with a remote portable object.