Announcement Announcement Module
Collapse
No announcement yet.
Spring vs EJB Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring vs EJB

    "J2EE development without EJB" book (p.108) states that EJB is an appropriate and one of the simplest technologies if 1) you develop application w/out web interface and need distributed( not simple clustered) architecture. 2) you want to use distributed application based on RMI.

    From my point of view it is a little bit confusing. I would like to ask the following questions:
    Why for distributed (w/out web interface) application we should select RMI and not other communication protocol such as HTTP and use Spring's Hessian ?

    Why for distributed application w/ RMI not use Spring's RmiProxyFactoryBean and RmiServiceInvoker instead ? Is it still not simpler than having EJB container ?

    Is it because we would need to run batch program that will work as server for exporting services or for some other reasons ? May be running web container where we would deploy RmiServiceInvoker would still be better ?

    What was the point then to develop these classes if we are still advised to use EJB ?

    Thanks.

  • #2
    calm down

    the "J2EE development without EJB" book is pretty old. At those good ol' days light-weight containers like Spring were only about to appear. I guess the author wanted to prepare the readers to leave to the EJB-servers only the tasks which they were good at and make a migration to IoC containers as smooth as possible.

    Sicne then the things have changed. No one would deploy a JBoss only in order to get the connectivity. Now it's way easier to define an exporter/proxy-pair in your Spring context.

    So, I think the book is ok and doesn't contradict with the reality

    Comment


    • #3
      I asked those questions to get some guidelines that should be used to select one or another architecture basis.
      I realize that book was published a few years ago and it is pretty large period for software evolution. But I hoped that somebody could provide some clarifications on those issues from today's perspective. I believe that Spring's founders and people who has extensive experience w/ it could provide they point of view.

      Thanks.

      Comment


      • #4
        If the questions (that I asked ) are too generic or are incorrect by their nature, then may be the following ones will be easier to answer.

        Let say we have a client and server not separated by firewall, otherwise we would need rmi w/ http tunneling. So this is not a limiting factor. Then we have a stateless service that i can expose as remote using Spring's RMI or Hessian exporter. What would be a better choice ? From my point of view I would select Hessian because that service could run inside web container, which in turn give us the opportunity to implement load balancing and failover. We could also use web container to setup the limits on threads to use our service. To use RMI exporter we would need to use some batch program to run as RMI server and so we would need to come up w/ pooling solution and have the issues w/ clustering for scalability and failover by not having web container. Is it correct ? Anything else should be stated ?

        Then another question. For the situation above Spring's Hessian exporter would be better than stateless EJBs ? We can assume that if we need transaction management on our service we could use Spring's AOP. So I would inclined to say that Spring's solution is better.

        Please comment those considerations are ok for selection of right architecture.

        Thanks.

        Comment

        Working...
        X