Section 8.2. Remoting

team bbl


8.2. Remoting

Remoting is one of the core features of EJB session beans. As a result, with declarative transactions, it's often used to justify the use of EJB, where it may not otherwise apply. In this lab, you'll learn how to do remoting declarativelyby writing configuration instead of any additional codewithout EJB. In this example, you'll be able to use Spring's remoting service to access the business logic directly to get all of the bikes in the database over the internet.

Spring supports three kinds of HTTP services: Hessian, Burlap, and HTTP invokers. RMI is a favorite Java remoting technology, but you've got to open an additional port on your firewall, unless you're tunneling. The nice thing about HTTP protocols is that you're using the web's standard communication protocol, so you need not open up your system to do anything beyond what you've to do anyway to support the internet. For starters, you'll provide remote support to the façade through HTTP invokers.

8.2.1. How do I do that?

Most declarative remoting services work by using proxies. For this application, you'll configure remoting so that other applications can access our façade. You're going to need to prepare a client and a server. To prepare the server, you need to set up a second servlet for the remoting services. In the web.xml file, add the servlet definition from Example 8-5.

Example 8-5. web.xml
<servlet>    <servlet-name>remoting</servlet-name>    <servlet-class>       org.springframework.web.servlet.DispatcherServlet    </servlet-class>    <load-on-startup>2</load-on-startup> </servlet>

Then, create a new servlet configuration file for the new servlet called remoting-servlet.xml, as in Example 8-6.

Example 8-6. remoting-servlet.xml
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/ spring-beans.dtd"> <beans>    <bean name="/RentABike"        >       <property name="service"><ref bean="rentaBike"/></property>       <property name="serviceInterface">          <value>com.springbook.RentABike</value>       </property>    </bean> </beans>

On the client side, you'll proxy the façade. Example 8-7 shows the code to configure the client.

Example 8-7. RentABike-servlet.xml
<bean   >    <property name="serviceUrl">       <value>http://YOUR_HOST:8080/RentABike</value>    </property>    <property name="serviceInterface">       <value>com.springbook.RentABike</value>    </property> </bean>

Now, create a test case like Example 8-8. It should simply get the bikes in the store.

Example 8-8. RemotingTest.java
public class RemotingTest extends TestCase {     private ApplicationContext ctx;     private RentABike rental = null;     public void setUp( ) throws Exception {            ctx = new FileSystemXmlApplicationContext(                   "/war/WEB-INF/bikeRentalApp-servlet.xml");            rental = (RentABike)ctx.getBean("rentabikeHttpProxy");     }     public void testRemoting( ) throws Exception {            Bike b = rental.getBike(1);            assertNotNull(b);            //etc.     } }

Run the test on the client to make sure things are working. You should be able to load and test the properties of any object available from the façade.

8.2.2. What just happened?

Let's start the flow at the test case. The test case loads the rentabikeHttpProxy bean from the context. As you know by now, the bike store isn't the true implementation. It's just a proxy. When the test case invokes the getBikes method on the rentabikeHttpProxy, the proxy fires an interceptor, which serializes the parameters and sends the request to the server over HTTP.

On the server side, you've exported the service. The servlet engine forwards the request to Spring, which invokes the object under test. The server code returns a list of bikes. Spring's remoting service serializes that list and sends them to the client proxy, which then returns them to the test case.

8.2.3. What about...

...other remoting services, like Hessian, Burlap, and RMI? Of course, one of the core problems with EJB remoting was that you could not decouple the remoting service from the container. For better or worse, you were stuck with RMI. That's fine, unless you want to remote to clients written in another language, or run over a firewall without opening another port or tunneling.

Spring's HTTP invokers are a good choice for Java over HTTP, but keep in mind that they rely on Java serialization, so they are not necessarily a good choice for cross-language remoting. Hessian and Burlap are remoting services that use a language-neutral representation of the objects. Although the non-Java support is limited in some ways (like for working with proxied objects), you generally do not need sophisticated support when you're remoting across languages.

    team bbl



    Spring. A developer's Notebook
    Spring: A Developers Notebook
    ISBN: 0596009100
    EAN: 2147483647
    Year: 2005
    Pages: 90

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net