Announcement Announcement Module
Collapse
No announcement yet.
Spring and Clustering Services don't mix? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring and Clustering Services don't mix?

    http://www.onjava.com/pub/a/onjava/2...ring-ejb3.html


    "..In Spring, it is more difficult to optimize the interaction between the framework and the services. For instance, in order to use Spring's declarative transaction service to manage Hibernate transactions, you have to explicitly configure the Spring TransactionManager and Hibernate SessionFactory objects in the XML configuration file. Spring application developers must explicitly manage transactions that span across several HTTP requests. In addition, there is no simple way to leverage clustering services in a Spring application..."


    Do you all have an example application or article that will demostrate clustering serivices in spring or is above statement correct that was posted on OnJava?

  • #2
    Jeryl,

    That article was factually flawed and the author showed limited understanding of Spring. (Of course, he does work for an EJB 3.0 vendor, so you can draw your own conclusions.) Spring integrates extremely well with JTA transaction management. Spring will also integrate with the Java Persistence API (persistence part of EJB 3.0) in a seamless manner.

    Spring poses no issues wrt clustering. I would recommend you refer to Chapter 14 of "J2EE without EJB", (Replacing Other EJB Services) which discusses the issue of clustering in much greater detail than I can fit here.

    Rgds
    Rod

    Comment


    • #3
      Maybe it would be a good idea to make an unbiased comparison between EJB3 and Spring.

      I have read the article and came to the same conclusion, eg: "Spring dependency injection is complex". Well..if that is complex.. you have to explain to me what is simple. And there are other parts in the system (like isolution issues) that are much more complex.

      Finally I came to the conclusion the article was bad because:
      -he didn`t understand Spring
      -he wasn`t objective.
      It was very funny to read the comments: a lot of people shared this conclusion.

      Comment


      • #4
        Yes, we did (naturally) consider replying, but it did seem from reaction that the community had no difficulty seeing the shortcomings of the article.

        Comment


        • #5
          Originally posted by Rod Johnson
          Yes, we did (naturally) consider replying, but it did seem from reaction that the community had no difficulty seeing the shortcomings of the article.
          An unbiased comparison between EJB3 and Spring would be nice to have I think. There are a lot of EJB programmers that would like to know how EJB3 can be compared to Spring. And I certainly would like to know what the advantages (and disadvantages) are of EJB3 (compared to Spring).

          And a biased article (towards Spring or towards EJB3) wouldn`t be helpful to give me a better understanding of these (hot) technologies.

          Comment


          • #6
            Just my two cents but comparing Spring to EJB3 is like comparing apples to oranges. Spring doesn't do any ORM by itself but rather integrates other frameworks that do handle this extremely well.

            Here is a quote (just browsing through the article):
            In Spring, it is more difficult to optimize the interaction between the framework and the services. For instance, in order to use Spring's declarative transaction service to manage Hibernate transactions, you have to explicitly configure the Spring TransactionManager and Hibernate SessionFactory objects in the XML configuration file. Spring application developers must explicitly manage transactions that span across several HTTP requests. In addition, there is no simple way to leverage clustering services in a Spring application.
            This is simply FUD - in Spring you have control over the transaction in an extremly flexible manner - declarative (plus annotations) and programatically.

            Comment


            • #7
              Originally posted by costin
              Just my two cents but comparing Spring to EJB3 is like comparing apples to oranges.
              I think in practice the comparison between Spring and EJB3 will be made (it already has been made). So if parts can`t be compared it would be usefull to know which parts and why.

              A possible audience would be developers that aren`t ejb3/spring experts and would like to know why/why not to use one of these technologies. In most cases they won`t have to time to master both the make a good decision.

              Comment


              • #8
                pun intended?

                Pun intended?

                Spring will also integrate with the Java Persistence API (persistence part of EJB 3.0) in a seamless manner.
                www.jboss.com/products/seam

                Comment


                • #9
                  Pun intended?
                  No, but it's quite funny now you point it out.

                  I would regard a "seam" as something that shouldn't be visible or should be avoided if possible. And Spring successfully does away with many such architectural disjunctions, through addressing multiple layers.

                  But it's really a matter for JBoss's marketing people

                  Personally I'm more worried about whatever "subversion of control" may mean. It seems like something that you wouldn't want to put on a US Visa Waiver form.

                  Rgds
                  Rod

                  Comment


                  • #10
                    It seems to me like their terms "subversion" and "subjection" are a way to pretend like they're doing something new and not wanting to admit that they're following in the steps of or building on the work of others. Or it could just be marketing. Or maybe they are doing something new; I haven't read any of the Seam docs.

                    Comment

                    Working...
                    X