Netbeans Remote In Project (EJB)

Question

This is so confusing, when I make a new Session Bean in Netbeans, it has an option for making local interface, and a remote. If I choose the remote however, a list comes up with existing Java SE, and ME projects. If I choose any of them (by the way one of them I intended to use as a GUI client for the beans later). It makes the session beans in my Enterprise Application, but it adds the remote class in the Java SE project. I don't get it what is this about?

My Netbeans Project Tree

enter image description here

Could you please add the headers of NewStudent*.java, so that we can see the package, the class/interfaces, and their annotations. — Beryllium, Aug 07 '13 at 18:49
@Beryllium I added the two things you mentioned, can you make any sense now ? — Lali Pali, Aug 08 '13 at 09:20
Could you replace the `testing` method with another implementation? — Beryllium, Aug 08 '13 at 09:43

score 2 · Accepted Answer · edited May 23 '17 at 12:07

If you create an stateless EJB sesion bean, it can implement a local and/or a remote interface.

In your case I suggest using the remote interface, because one of your clients will be remote: A command-line stand-alone application is typically not run on the application server host (in contrast to a servlet which normally resides in the same JVM).

Try to design the remote interface in a way that one user interaction results in one call to the EJB layer. If your stand-alone application runs fast enough, the servlet is probably fast enough as well. If you do it the other way round, you possibly will find out that the interface design which works for a servlet is not suitable for remote access.

There are some semantic and technical differences between the local and the remote interface: Using the first means that the interface is designed to be used only from localhost (so many calls do not really affect performance). Local beans only live in one JVM. It affects the behaviour regarding call by value/reference (see Why do we need separate Remote and Local interfaces for EJB 3.0 session beans).

Regarding the NetBeans screenshots:

The (remote) client has the remote interface in its scope. That's OK, as it does not need to see anything else.
On the server/EJB side, there is everything else: The EJB, and the local interface. The only thing which seems to be missing is the remote interace, as the EJB implements it as well. There is possibly some NetBeans IDE magic behind it, but the server side needs the remote interface as well.

That is my question, why does `Netbeans` adds the `remote` interface in the Java `SE project`, sine I did not create that file, I just wanted a remote interface together with a local interface, but if I don't do it manually, `Netbeans` only gives me the option to add the remote interface in some other project_ — Lali Pali, Aug 08 '13 at 10:11
Where else, if not in another project? If you don't have a remote client, you don't need the remote interface, because with "servlets only", a local interface is enough. So possibly the IDE wants to guide you in the recommended direction, so from that perspective it makes sense. Consider the two packages you have to build later: One for the client (only the remote interface), and one for the server (EJB implementation etc.) — Beryllium, Aug 08 '13 at 10:58

score 1 · Answer 2 · answered Aug 07 '13 at 19:40

1

EJBs are meant to be components that "execute business logic". They can be used locally (called by other components in the app server itself) or remotely by a client (such as an applet, a desktop application).

In the later case, you access the EJBs through the remote interface (which makes sense that it should be included with the client, doesn't it?) plus some configuration that tells the client how to connect to the server that actually executes those beans.

answered Aug 07 '13 at 19:40

rdcrng

3,415
2
18
36

Well I want to access that bean actually from my client, but I have been struggling with that. So how this would help me to connect form that client to that bean? – Lali Pali Aug 08 '13 at 09:11
And do you mean `it makes sense to be included with the client` is not supposed all this classes to be in the server **Glasfish** in my case ? And then from my client to access that interface, through **JDNI** or some way ? – Lali Pali Aug 08 '13 at 09:23
1

@LaliPali Your bean implementation and local interface do live on the server. The remote interface however, although can live on the server as well, should live on the client. Here's a FAQ page for Java EE 5 describing how to configure JNDI for accessing remote EJBs https://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#nonJavaEEwebcontainerRemoteEJB. You'd have to find the exact configuration for your particular server to get it right, as configuration parameters do tend to change. – rdcrng Aug 08 '13 at 09:49
I don't get it, why the `Interface` have to be in the client, doesn't the `Enterprise Application` needs that `Interface`, is not suppose the client find that interface from the server, to use its methods ? – Lali Pali Aug 08 '13 at 10:22
1

The server doesn't need it - why would it need the interface if it has the actual implementation? The client needs it because it has to call methods on an actual object. Under the covers, when you look up an EJB on the client side, JNDI creates an object that can talk to the server - this object implements the remote interface. – rdcrng Aug 08 '13 at 10:34
So why `Java SE project` needs that Interface the, and how the heck does my `Java EE` application understands what is going on on the interface in a Java SE application, coz now I declared a method in the Interface, and `Netbeans` understood that, and it says I must implement the method, but how, this is so confusing – Lali Pali Aug 08 '13 at 10:42
1

Your Java SE project only needs the interface if it intends to call methods on the EJB that lives on the server - if you don't need that, then don't include the interface there. Your Java EE project doesn't understand anything about your Java SE project, it can live just fine with or without the remote interface. NetBeans, on the other hand, once you told it to create an EJB with a local and a remote interface, is trying to keep you from making mistakes, i.e. trying to keep your implementation in sync with your interfaces. – rdcrng Aug 08 '13 at 11:29

score 0 · Answer 3 · answered Sep 16 '15 at 18:43

Here's the issue, and I have struggled mightily with this: When creating EJB's from entity classes, NetBeans give you the ability to create remote interfaces. This is something that I am doing because I will have a number of stand-alone clients accessing these ejb's. When you tell NetBeans you want to create the remote interfaces, it forces you to place them in another project. That's all well and good, until you define your implementation, which looks something like this:

public class DataFacade extends AbstractFacade<MyEntityClass> implements DataFacadeRemote {
...
}

Now, when you try to deploy your ejb jar to Glassfish, it claims there are no ejb's in your jar, and rightly so, because it doesn't know anything about the interface DataFacadeRemote. What I did to solve this round-robin of problems is to create a library jar, which I copied to the glassfish server manually. Then when I deploy the ejb jar, it happily finds the library jar and understands the facade classes (ejbs). This is also a monumental pain because it's necessary to copy the library jar any time you have a change to the interface or entity classes, and that might require restarting the app server to reload the library, as it doesn't seem to happen automatically.

If I'm also doing things incorrectly, I'd appreciate a nudge in the right direction.

Netbeans Remote In Project (EJB)

3 Answers3