I have recently started reading about Java EE6 and in the examples I follow I need to make remote interface. What is the purpose of this? I also read about home interfaces, but I don't understand. I have never done enterprise programming before so I can't relate it to something else either. Could someone explain me these interfaces?
Basically by declaring the #Local #Remote interfaces you specify which methods should be available for the remote clients and which for the local beans in the same JVM.
Home interface is used to allow a remote client to create, find, and remove EJB objects.
You can easily find that information on the official documentation pages, for example for EJBHome, or nice overview for local and remote here
I highly recommend reading EJB book by Bill Burke, Richard Monson-Haefel for starters.
Every Session bean has to implement Interface and Bean Class. When User requests then JNDI helps to lookup which Interface is required for that Request. When your EJBs are deployed in same EAR then you should prefer Local Interface.
If EJBs are in same EAR then Remote Interface should be used.
This Interface will call business logic which resides in Bean Class. Home Interface creates and finds EJB objects for Remote Interface. So first you should create Home Interface with create method and then Remote Interface.
Related
As per my knowledge, in the EJB 2.x, the client uses the home interface to ask for a reference to the component interface and calls Enterprise java bean’s business method using that reference.
But the concept of stub and skeleton are not clear to me.
Is the reference to the component interface acts as a stub? Then which one act as a skeleton?
Please clarify.
Stub and skeleton are actually RMI concepts, EJB is just reusing them. As such, they are only needed when you are using remote interfaces.
Stub is used by the client to invoke methods on the remote EJB -- it is basically a proxy object that implements the remote interface. It is responsible for serializing the invocation into a byte stream and sending it to the server hosting the EJB.
Skeleton is running on the server side -- it receives the remote calls from the stub over the network, deserializes the invocation and and delegates it to the EJB.
See also: Java RMI : What is the role of the stub-skeleton that are generated by the rmic compiler
Nowadays, stubs and skeletons are typically generated at runtime (or the same function is just handled via reflection), so you do not need to worry about them (see also Do I need RMI stubs to access EJBs from my java client? - this is specific to Glassfish, but the general principles usually apply also to other containers).
Skeletons have been obsolete since 1998. Don't worry about them.
Well stub and skeleton are just there when you are using Remote interfaces.
Stub is an object implementing Remote interface (implemented usually by code generation) and skeleton is implemented inside the container and invokes method on the EJB (inside the container).
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?
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.
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.
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.
Any one dealing with the RMI would certainly have come across this dilemma of how to easily maintain the interfaces to objects providing remote method invocation service to other client applications. Whenever we decide to have a minor change in the method declaration or adding/deleting methods declared in the interface, we have to manually replicate the change in all the clients that would be using that interface for accessing RMI service from a remote server.
Think about having a downloadable (Serializable) agent that has a more stable interface used by the client, and that uses the remote interface to do its job. You can use the codebase feature to ensure its availability to all clients. The agent needs to contain the stub. You can bind the agent to the Registry, or return it from some other remote method.
Or, use JWS to distribute new versions of the clients.
Or, design your remote interfaces more stably so they don't have to change -:)
One of the good workaround I came up with is to
put all the interfaces provided by the RMI server in a separate
project which will pack itself into a jar file when built.
Then just add that jar file as dependency or in the
classpath of the server application which is meant to provide the
RMI service as well as to any of the client applications that
want to use those interfaces for invoking remote methods.
This will ease the task of maintaining RMI interfaces by updating them at just one place. Extra effort of changing method signature in some interface will be limited to changing the application code which calls that method.
I am reading the Enterprise JavaBeans 3.1 book and I wonder if I have understood the concept of EJB proxy object correctly. I now know that it follows the proxy pattern and I have read some about it.
When we make the interfaces for the beans, we are doing it because we want to have the proxy pattern implemented. This helps us because the clients are only concerned about what we can do and not tied to directly to a class but rather a interface that can act as if it where the real object.
So, the container probably instantiate the proxy objects implementing the corresponding interface and add some magic code (networking code) before invoking upon the real EJB for us, because the proxy object is automatically made right?
Have I misunderstood the concept? If thats the case could someone tell me whats wrong?
Correct. The interfaces you're writing for your beans would have been sufficient if your application was confined to a local JVM. In this case no proxy would be needed, as the implementing class could be instantiated and supplied directly.
Clients of EJBs cannot work on their implementing classes, as they don't have them in their classpath. EJBs are location-transparent, you can call them across the network, or from another application located on the same server, but isolated out by different class loaders. In such cases, you need to have proxy objects to marshal, send over the network, and unmarshal the parameters you supply to EJB calls and results of these calls that you receive. And on the client side, you need a dummy EJB interface implementation, that forwards your calls to the server where this EJB is installed.
Proxies also handle other functions, such as starting/ending transactions around EJB method calls.
EDIT: if you're curious what EXACTLY such proxies could do, take a look at overviews of RMI in Java and AOP (either in AspectJ or Spring). It will give you the idea what kinds of tasks can be implemented this way.
Are you referring to the proxy interfaces to stateless (and stateful) session beans and message driven beans?
If so, I think your understanding is correct. The only thing you seemed to have missed is the concept of instance pools for stateless beans. The container does not instanciate these per request, but instead provides an implementation when needed.
Also, using proxies allows the container managed things to take place: transaction management, asynchronous thread management etc.
How can I use Business Interface pattern with an EJB (session bean) with Local as well remote interfaces?
It does not matter whether the interface is local or remote. You can write all your business methods into one interface and then use it as local and remote interface. The difference is how it will get called, but not what is executed.