Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 119 120 121 122 123 124 < 125 > 126 127 128 129 130 131 .. 166 >> Next

107 }
108
109 }
110
Listing 39.1 (continued)
What is wrong with this approach? Actually, there is nothing explicitly wrong. Countless systems have been built that use this servlet-to-EJB paradigm. However, in this case, both the Web container and the EJB container are running in the same process (in this case the JBoss Application Server). Therefore, this is what happens:
1. The client calls a local stub.
2. That stub performs the necessary translations (marshalling) to make the Java objects suitable for network transport.
3. The skeleton receives the stub's transmission and converts everything back to Java objects.
4. The actual EJBObject is called, and it does all of its necessary magic (why you built it).
5. The response is transformed back into a network neutral format.
6. The skeleton returns the response.
7. The stub converts back into Java stuff.
This is typical RMI stuff, right? So what is the big deal? Well, in this case we are operating in the same process. No one would ever make RMI calls to interact with their local objects, so why would you do it in EJB? It used to be that you had to do it; the EJB 1.x specifications gave you no other option. This was based on a basic principle in distributed objects: Design things to be independent of their location.
I'll Take the Local 345
Furthermore, let's not forget that the Web server and EJB server running in different processes is not that uncommon. As a matter of fact, it is very common to see Web containers running on entirely different machines. However, in this case, we have provided a SOAP interface to our EJBs. That it communicates like a Web server, in other words, over HTTP, is not really the point. We are essentially writing a protocol wrapper to our business objects. It makes little sense to write a protocol wrapper that communicates in an entirely different protocol when it doesn't have to do so.
All signs point to J2EE 1.4 containing the Web services protocols as an inherent part of J2EE. However, this shows that it is not required in order to use SOAP right now.
So how do you solve this problem? EJB 2.0 offers a solution: local interfaces. When you use a local interface, you can interact directly with the object. This avoids all the network-related issues. This is a remarkable timesaver when you consider just how much is dependent on the size and complexity of the objects.
Listing 39.2 shows the code that changes to use the local interface.
1: //get the text for the number element to put in response
2: String value = sentSE.getValue();
3: Context ctx = new InitialContext();
4: SOAPHome obj = (SOAPHome)ctx.lookup("mySOAPHome");
5: SOAPHandler soapHandler = soapHm.create();
6: String responseData = soapHandler.convert(value);
7:
Listing 39.2 LocalEJBServlet
That doesn't look much different than our previous example—because it isn't. In this case, I have only removed the narrowing of the Home object. I left the names of the other interfaces the same. Why? Because the real difference is in the back end. Listing
39.3 is an example of a remote home interface.
01 package org.javapitfalls;
02
03 /**
04 * This is an example of SOAPHome as a remote interface.
07 */
08
09 public interface SOAPHome extends javax.ejb.EJBHome
10 {
NOTE
Listing 39.3 SOAPHome (remote) (continued)
346 Item 39
11:
12 : / * *
13: * This method creates the SOAPHandler Object
16 : */
17:
18 : SOAPHandler create() throws java.rmi.RemoteException, 2
javax n; 0 1 t p e c x E e t a e r C b. j e
19:
20: }
21:
Listing 39.3 (continued)
Listing 39.4 is the exact same thing as a local interface.
01 package org.javapitfalls;
02
03 /**
04 * This is an example of SOAPHome as a local interface.
07 */
08
09 public interface SOAPHome extends javax.ejb.EJBLocalHome
10 {
12 /**
13 * This method creates the SOAPHandler Object
16 */
17
18 SOAPHandler create() throws javax.ejb.CreateException;
20 }
21
Listing 39.4 SOAPHome (local)
Notice that this extends EJBLocalHome instead of EJBHome as in the remote case. Furthermore, notice how the methods in the local version do not throw RemoteEx-ception. This is because it is local. It won't have problems with remote access, because it won't be dealing with things that are remote.
But this isn't all. Let's examine the actual business interface and notice its differences. Listing 39.5 is an example of a remote SOAPHandler object.
I'll Take the Local 347
01 package org.javapitfalls;
02
03 /**
04 * This is an example of SOAPHandler remote interface.
07 */
08
09 public interface SOAPHandler extends javax.ejb.EJBObject
10 {
11
12 /**
13 * This method converts the parameter into the response
16 */
17
18 String convert(String param) throws javax.rmi.RemoteException;
20 }
Listing 39.5 SOAPHandler (remote)
Listing 39.6 is the exact same thing as a local SOAPHandler object.
01 package org.javapitfalls;
02
03 /**
04 * This is an example of SOAPHandler local interface.
Previous << 1 .. 119 120 121 122 123 124 < 125 > 126 127 128 129 130 131 .. 166 >> Next