views:

134

answers:

4

Using Spring as Framework, if i need provide business logic's service to either JSP/Servlets(on Web Servers) or to Application desktop client or Mobile clients, the only way to accomplish the logic business(without EJB) in a remote server is through Servlets?

+2  A: 

No. You can expose logic via RMI, Hessian, Burlap, JAX-RPC etc.

Brian Agnew
thank you for reply, but is necessary that those that expose services(Using RMI, for example) are servlets or may be any bean?
HenryOS
+1: You can use these technologies without an external web container. Btw, you should read the reference documentation for version 3 instead. It's better.
Espen
+2  A: 

It's one alternative. But nothing stops you from creating your own server or handle the work to the Spring container.

The advantages with using a Servlet container is that you get thread and socket handling for free. (This also applies to RMI with a RMI server)

The advantages with using a Web Service framework that uses a Servlet is that you only need to handle and configure generated code. And that it works with all major technologies such as .NET and PHP, since it's just XML.

Another advantage in advanced operations environment is that a Servlet sends HTTP messages by default on port 80. With rigid firewalls, this is the absolute easiest solution.

For example with RMI, you need two ports for communication.

If you are interested in using a web container like Tomcat on your remote server, you should have the Spring container inside the web container.

But the absolute simplest alternative if you can live with Spring in both ends is to use Spring invokers together with Java 6's bundled web container.

With good layering, you can test all the business and integration layer code with JUnit tests! That's quite elegant!

Espen
ok.. i understand.. thank you for all information. But all of these solutions need servlets for your implementation?
HenryOS
No, the simplest remoting solution possible with Spring is Spring invokers and it doesn't require a Servlet. You only need SimpleHttpServerFactoryBean. (see link in post for more details) The downside with Spring invokers is Java serialization's limitations and portability in general.
Espen
Perfect!, what you say is as i had read. But as yet had not implemented then i had that doubt, and the possibilities of remoting in Spring. Thank you!!. Regards!
HenryOS
+1  A: 

It is not required that business logic services on a remote server be exposed via a servlet. The exposed service can be anything that your client code knows how to use. Spring provides facilities for making some types of communication easier than others: RESTful HTTP, SOAP, and RMI would be easier than JINI or a unique wire protocol.

Jacob Tomaw
+1  A: 

As it was told in previous comments, you could always expose your logic via RMI, Hessian/Burlap, JAX-WS/JAX-RPC or even JMS.

In case of RMI or JMS you even don't have to change your business interface to expose it as a remote service. It's just a matter of configuration.

For example, suppose you have business interface:

 public interface HelloWorld {
    public String getMessage();
  }

and its implementation:

public class SimpleHelloWorld implements HelloWorld {
    public String getMessage() {
       return "Hello World";
    }
}

To expose this service via RMI on a localhost at 9000 port you need to add following code snippet to Spring config:

<?xml version="1.0" encoding="UTF-8"?>
   <beans xmlns="http://www.springframework.org/schema/beans"&gt;
       <bean id="helloWorldService"
            class="com.apress.prospring2.ch15.remoting.SimpleHelloWorld"/>
       <bean id="serviceExporter"
             class="org.springframework.remoting.rmi.RmiServiceExporter">
           <property name="serviceName" value="HelloWorld" />
           <property name="service" ref="helloWorldService" />
           <property name="serviceInterface"
               value="com.apress.prospring2.ch15.remoting.HelloWorld" />
            <property name="registryPort" value="9000" />

  </bean>

Your client side config should have following configuration (appCtx.xml):

  <?xml version="1.0" encoding="UTF-8"?>
    <beans xmlns="http://www.springframework.org/schema/beans"&gt;
       <bean id="helloWorldService"
            class="org.springframework.remoting.rmi.RmiProxyFactoryBean">
          <property name="serviceUrl" value="rmi://localhost:9000/HelloWorld" />
          <property name="serviceInterface"
              value="com.apress.prospring2.ch15.remoting.HelloWorld"/>
       </bean>
       <bean id="helloWorldClient"
            class="com.apress.prospring2.ch15.remoting.rmi.HelloWorldClient">
          <property name="helloWorldService" ref="helloWorldService" />
       </bean>
</beans>

Here is a simple client:

public class HelloWorldClient {
   private HelloWorld helloWorldService;

   public static void main(String[] args) throws Exception {
      ApplicationContext ctx = new ClassPathXmlApplicationContext("appCtx.xml");
      HelloWorldClient helloWorldClient = 
        (HelloWorldClient) ctx.getBean("helloWorldClient");
      helloWorldClient.run();
   }

   public void run() {
       System.out.println(helloWorldService.getMessage());
  } 
  public void setHelloWorldService(HelloWorld helloWorldService) {
      this.helloWorldService = helloWorldService;
   }

}

That's it. Spring will take care of everything else.

wax