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.
Related
I wanna do a service that distributs tasks amongst several servers, which execute those tasks.
To do that, I made use of the Java RMI technology and all works just fine, but it is a mess. I have a big class, which is
mixed with remote methods which are called by the servers to post messages and client methods
to schedule tasks to the service which are called by the client.
I am now trying to find a proper solution to encapsulate the remote methods from the business methods, but struggle as they are thighly coupled. The message implementation (see the example class diagramm) interacts thightly with the private business methods.
This might also include invoking events which the Client class
subscribed. My first thought was the approach with a message handler. But how can the message handler still interact with private methods of the server and invoke events on the service.
I like to ask you if you have any idea for my problem. How can I encapsulte the remote interface and its methods from the non remote methods?
If I understand the problem correctly, you have a big class with three kinds of method:-
Remote methods intended for use by the client, but not by the server;
Remote methods intended for use by the server, but not by the client; and
Local methods not intended to be remote at all.
It seems to me that creating two remote interfaces (one for the client, one for the server) and implementing them both in the big class will do what you want. The client will only see one interface and the methods in it; similarly for the task server.
Is that enough encapsulation? Or did you mean something more?
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).
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.
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.