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.
Related
I have an Java application which is using an EJB client to make a calls to the server. Server side EJB's create again calls to the DB. Hibernate is used, but second level cache is disabled. When performance testing DB calls using EJB client, usually the first calls take much longer than the next ones, even though calls are made using different parameters. What things can explain or have effect on the performance in this scenario?
EJB's on the top uses Java's RMI calls. Whenever your client calls the EJB components running in an EJB container, then in the meanwhile some expensive operations are performed.
Lets say, you have a remote interface called HelloRemote and a service bean called HelloBean which implements the HelloRemote interface.
1) First your client needs to look-up for the service object which is registered with the JNDI Registry as :
HelloRemote service=(HelloRemote)context.lookup("HelloBean/remote");
// JBoss specific
Here,
i) Your client makes a call to LDAP Server which contains the JNDI Registry and looks for the remote bean registered with the given name.
ii) If the any bean registry with the given name is found then the container first serializes the registered bean object and sends it to the client where it is again deserialized which is also known as marshaling and unmarshaling.
The above step in itself is somewhat costly and that is why it is recommended that if your application architecture is going to use the same JVM for both the client application and the session beans, then use the local interface ( which can be a no-interface option starting from EJB 3.1) instead of using the remote interface.
iii) With the Business interface stub in hand, you now invoke the business operations on that stub interface. This stub performs the required serialization and delegates the call to the container.
The container now performs the deserialization and invokes the corresponding methods on Business interface object. The same process occurs when the result of this invocation is being returned to the cilent.
As you can see there is a lot of Serialization and De-Serialization happening when a client communicates with the EJB component.
Enabling Second Level cache does improves the performance in Hibernate, but In view the communication b/w an EJB Client and an EJB service object is more expensive w.r.to time.
NOTE : I was looking for someone to respond to this post, as i was also eager to know the reasons, however not finding any responses, I had this post with the whatever understanding i have on these topics
i need to create a slideshare to introduce JCA in an easy way. right now i'm trying to understand the whole thing but i'm still stuck in some places. I'm reading an IBM tutorial and in its example code it doesnt implement the transaction and security contracts but instead it uses an Interaction, an InteractionSpec, a RecordFactory, and IndexedRecords interface/classes (Thats CCI i suppose).
well in a share i found they stated that the contracts from JCA v1 specification need to be implemented and in this example only the "connection management contract" is being used if i understand it right.
(ConnectionMetaData, ConnectionFactory, Connection) or (ManagedConnectionFactory, ManagedConnection, ManagedConnectionMetaData) <- Whats the difference between those and are the interfaces prefixed with "Managed" the so called "Managed Connection Contract"?
Also i'm not quite sure yet but is the CCI only used for the creation of the Resource Adapter? Or can i use it as a "framework" inside my application-server to communicate with the resource adapter. In the Bean example they use a JNDI lookup to get an instance of the ConnectionFactory and use the overloaded methods of the extended CCI classes.
I understand what the contracts "do" but when do i use system contracts and when do i use CCI. I'm not getting the purpose of it.
Is the CCI some sort of "API methods" inside my resource adapter, i can then use in my application-server implementation?
The first look of JCA is so complex.
How would i communicate with a Resource Adapter inside a JBoss, Tomcat setting for instance.
Yes, JCA is quite a complicated machinery. The objects that are manipulated by the client (i.e. the EJB, Servlet) are not the internal ones in the JCA adaptor.
From what I recall, one of the reason for this "split" is that connection pooling is managed by the applicaton server. Obtaining connections is thus an interaction between the client, the application server and the internals of the resource adaptor. I haven't been using JCA since long time, so I don't remember sharply the details. However, I had dumped down in a blog post my understanding of JCA few years ago, maybe it will help you.
Now i started a new application, which i divided in>
ApplicationWeb, ApplicationFramework.
The applicationWeb contains my servlets which it will execute the logic in the ApplicationFramework side, this one will make several request in differents webservices and also ofcourse DAO transactions...
Before i was using all this with EJB which i didnt need to worry for Pools, trasactionality, concurrency and so on, but this time i want to do it in Tomcat, with POJOs, should i need in this case, a ThreadManager to manage all the request and dao access? or there will be no problem since the Servlet will create an instance for each session?
i was planning to use also Guice which im related and can get closer somehow to the DI that EJB uses.
Any ideas.
Thanks in advance
Well, technically Servlet will process each request in separate thread. So you don't need to worry about concurrency at Servlet layer.
If you create your DAO and SERVICE layer as stateless (you will not store any state in fields) you don't need to worry about concurrency at this level either (since stateless objects are thread-safe).
So in my opinion you don't need to worry about concurrency...
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.
How do I pass objects from non-GWT server-side code (e.g. regular server code) to the GWT "servlet" (still server-side code), specifically a RemoteServiceServlet?
My GWT server-side code consists of RPC-type RemoteServiceServlets to which I can't seem to get a reference so I can't pass in my real/fake object in testing mode or add servlet attributes. I can't see any way to simply pass objects in (dependency-injection style) as I have no access to the Server object as GWT seems to instantiate it deep within its internals, so what are my options?
P.S. I don't want to use a full-blown DI framework such as GIN/Juice - I find them to much magic. I just want a way to access the instance of a GWT servlet and pass stuff to it.
Let me start out by saying, if you haven't already, I highly recommend watching this Google I/O presentation on GWT Architecture best practices. I found it very useful and it's where most of the following came from.
What I did was create an abstract "dispatch" servlet that extends GWT's RemoteServiceServlet. Every module I have has only one service (that extends my abstract dispatch service) with which I register a set of request handlers. All GWT service calls for a given GWT module come into that module's dispatch service, which looks at the type of request and dispatches it to the appropriate request handler. The request handlers, in effect, handle the work that previously resided in the service servlet. Besides making your life easier by having fewer servlets to register in your web.xml (not to mention avoiding the extra interfaces GWT requires), you can more easily control the dispatcher object that handles all the actual dispatching. You can, for example, pass whatever real/mock object you like into these request handlers since you, and not the web container, are responsible for instantiating them.
And though I rolled my own, the gwt-dispatch project exists for this very purpose.
Hope this helps.
Servlet containers are designed to not allow direct access to the servlets that they host; that's why you've found it difficult to get any kind of handle to a servlet.
Rather, refactor the code that is currently in your servlets into separate request-handler classes, and have your serlvets call into them.
For testing purposes you can hook your testing framework, or your client code, to the request-handler classes directly. That's how people generally solve the problem you've run into.