Discussions

News: Side-by-Side Comparison of Spring and EJB 3.0

  1. Side-by-Side Comparison of Spring and EJB 3.0 (60 messages)

    DevX has posted the first of a two-part series on a side-by-side comparison of Spring and EJB 3.0, attempting to clarify what each one of them is, and the article also tries to reevaluate how well EJB 3.0 has addressed the shortcomings of previous versions and determine what Spring has to offer above and beyond EJB3. The article starts off by comparing Spring + Hibernate and the Java Persistence Architecture. Considering that Hibernate 3 is a compliant implementation of JPA, it's not surprising that the two are roughly equivalent; no direct comparison against Spring's other persistence mechanisms (JDBC, iBatis, etc) is suggested, although JDO, iBatis, and JDBC support in Spring is mentioned. Declarative transaction management is mentioned next; the interesting point here is that identical code is used for Spring and EJB3 here. EJB3 uses the container's transaction support for EJB3 method calls, whereas Spring uses its transactional aspect. One advantage of Spring here is that multiple transaction types are supported, whereas EJB3 only supports JTA transactions. Statefulness is the next item for consideration. Stateful beans are supported in EJB3 via stateful session beans; state is supported in Spring through the use of prototypes. The article states that Spring is primarily a framework emphasizing statelessness so there are some issues to consider when using a stateful element; note that this doesn't prevent stateful objects in Spring. As the author concludes:
    If you are working with applications that are highly stateful then you may want to consider whether EJB 3.0 SFSBs might be a good solution. For highly conversational applications you may want to consider SEAM, which provides a very powerful solution for conversational interaction built on SFSBs and JSF. Spring gives you more flexibility in many aspects of application development than EJB does—and as you've seen in this article, this is particularly true with regards to persistence and transaction providers. But the trade-off for this added flexibility is increased complexity in configuration. EJB 3.0 provides less flexibility but its tight technology stack, annotations-based configuration, and philosophy of configuration by exception make configuring EJB 3.0 applications quite simple. If flexibility is more important to you than a pre-defined approach then you certainly will want to consider Spring. A final point on standardization: While Spring integrates many standards such as JTA, JDBC, and JMS it is not itself a Java standard. If standardization (and by extension vendor support, tooling, etc.) is important to your organization or application then you will want to consider EJB 3.0. But luckily Spring and EJB 3.0 are not mutually exclusive choices. There are very powerful ways of integrating these two technologies to take advantage of their relative strengths and weaknesses.

    Threaded Messages (60)

  2. I do not agree.[ Go to top ]

    I noticed that the author compared only the functionalities they have in common, and nothing has been taken into account about the large ammount of functionalities that spring has and EJB3 does not have. Thus, it is obvious that the two frameworks appears quite similar... I do not agree with the author when said: "Spring gives you more flexibility ... . But the trade-off for this added flexibility is increased complexity in configuration." I think spring is more simple than EJB3 (I used both) and again more powerful. One of the most important spring features is the aspectj integration: it is very important, every modern framework should be aspect-oriented (EJB3 does not have!) Finally I think that the most important comparison should be done not about the funtionalities they have in common; but also about the functionalities that spring has and EJB3 does not. If we list all the spring functionalities that are not present in EJB3, we'll see the difference. Bye bye. Mike
  3. JEE5 is reaction to spring[ Go to top ]

    The JEE5 spec is a reaction to spring and similar technologies that tried to fix the old J2EE. The problem with the current spring framework is that it has a strong overlap with JEE5. In other words, you have to choose to do things the spring way or the JEE5 way. For some things that make sense and for other things it doesn't really make sense. Of course the two technologies don't have to byte each other and you can probably mix them quite easily. But clearly many of the old reasons for adopting spring have been addressed in the new JEE5 specs. Things like persistence, transactions, setting up web services, etc are now really easy in JEE5 and not really a good reason for going for a non standard framework. BTW. I don't think aspectj should be anything else than an optional thing right now. It's a nice language but I wouldn't want to expose it through a framework (I don't care if the framework implementation uses it though).
  4. EJB3 == Sun's Revenge![ Go to top ]

    JEE5 is the Sun reaction to Spring, that's correct. But their answer was a copy of spring, a little and very partial copy. Generally, I prefer the original ones, than the copies. J2EE5 simply implements only some Spring2 features, not the whole framework, I mean: Spring > J2EE5. It is for this reason that I thing Spring is better than J2EE from a user's point of view. From a technical point of view, Spring is very very better designed than the EJB3, is lightweight, Aspect Oriented (did you ever use aspects in real world? I did, and I think Aspectj is foundamental! Of course, OOP address your 20 % of problems, the rest 80 % is Object Oriented!). Finally, I like Spring over J2EE because it is a more complete - flexible - portable solution. that's all! BTW, EJB3 is much better than EJB2.1, but, I'm afraid, it is still not enough to fill the gap with Spring2. Mike
  5. Re: EJB3 == Sun's Revenge![ Go to top ]

    Instead of Sun's revenge, I'd rather see it as Spring's contribution to the entire enterprise Java sociaty. The new EJB3 spec says that open source solutions like Spring and Hibernate give a strong and positive impact to the standard, and that the system is working! Hopefully moving forward, frameworks like Spring will provide more cutting edge solutions that the standard/spec does not provide or fails at (hopefully in a simple and elegant way as it has been for the most part).... Cheers, Qingtian
  6. Re: EJB3 == Sun's Revenge![ Go to top ]

    Instead of Sun's revenge, I'd rather see it as Spring's contribution to the entire enterprise Java sociaty.

    The new EJB3 spec says that open source solutions like Spring and Hibernate give a strong and positive impact to the standard, and that the system is working!

    Hopefully moving forward, frameworks like Spring will provide more cutting edge solutions that the standard/spec does not provide or fails at (hopefully in a simple and elegant way as it has been for the most part)....
    This is actually an important observation. Much like Gavin embraced EJB3 in extending Hibernate, because it made Hiberante a "first class citizen" of the EJB stack (more or less), Spring too, with its fundamental IoC foundations, is part of the EJB stack. With the plethora of OSS EJB containers now available (Glassfish, JBoss, Geronimo, and others), it would be interesting to see if instead of expanding Spring as a bolt on to an existing EJB system the creators would rather extend an EJB container directly, giving them more access to the internals and getting a better overall total integration. I know it won't happen, but it seems like get back on the bandwagon rather than running along the side of it would be more productinve for Enterprise Java as a whole.
  7. Re: EJB3 == Sun's Revenge![ Go to top ]

    Instead of Sun's revenge, I'd rather see it as Spring's contribution to the entire enterprise Java sociaty.
    * Applause * I totally agree. The JCP works. The best of breed open-source solutions are being recognized, their creators are being implicated in the JCP and J2EE is growing and becoming more useful as a result of this.
  8. Re: EJB3 == Sun's Revenge![ Go to top ]

    Of course EJB3 is not a revenge against anyone! I wanted to be provocative....! I think that much of Spring phylosophy is "embedded" in EJB3 spec, that is a good think for the new ejb spec, of course! But I still prefer the spring solution, that's more complete and flexible. For the Application Server: I noticed that Geronimo next verison will be shipped with a Maven2 repository embedded. Move over there will be a special Geronimo version, named "Little Geronimo", that will be a simple servlet engine with a Maven2 repository embedded without the library OpenEJB: i.e. without EJB!!! On top on Little G you will be enabled to install every thing you want: the spring container itself and all the 3-rd party libraries you want (of course, OpenEjb too!). I think this solution is the best, and it is the future of Application server: a simple servlet engine with a repository of 3-rd party libraries organized in an elegant way (for example using Maven2) where every service is loaded using your "loved" j2ee framework with no preferences: Spring, Ejb3, Pico Container...etc..etc... I hope Geronimo will meet its promises.... bye bye.
  9. Re: EJB3 == Sun's Revenge![ Go to top ]

    I think this solution is the best, and it is the future of Application server: a simple servlet engine with a repository of 3-rd party libraries organized in an elegant way (for example using Maven2) where every service is loaded using your "loved" j2ee framework with no preferences: Spring, Ejb3, Pico Container...etc..etc...

    I hope Geronimo will meet its promises....

    bye bye.
    Why mandate a servlet engine? Why not a common infrastructure into which any protocol adapter can be plugged (HTTP, JMS, SMTP/POP3), along with service containers (JEE, pojos, WS) to supply the actual functionality. Hey presto! It's JBI! Seriously, I'd really like to see OpenEJB reworked as a JBI service component.
  10. Completely agree.[ Go to top ]

    Recentely I have worked with ServiceMix, it is fantastic! JBI is the future! Unfortunately, serviceMix has very poor documentation....I worked hard to understand how it must be configured...but at the end it works well. Servlet is only one of the numerous protocols we are able to use to export remotely our services. Up to now I think the most advanced "idea" of Application Server is around Geronimo idea, but its developement is still in progress. I think it is not yet ready. Good ideas become from JBI world. But no new idea have come from the EJB3 workd: I think that a "bunbled" and "one-shop" "heavy-weight" solution as GlassFish, Jboss...etc...etc. belongs to the past and obsolete "idea" of Application Server.
  11. Re: Completely agree.[ Go to top ]

    JBI is the future!
    Good ideas become from JBI world.

    That is true.
    But no new idea have come from the EJB3 workd: I think that a "bunbled" and "one-shop" "heavy-weight" solution as GlassFish, Jboss...etc...etc. belongs to the past and obsolete "idea" of Application Server.
    JBI is an integration technology and modern integration techniques (MoM, ESB, etc..) are proven solutions to integration of coarse-grained systems/subsystems.
    Application Servers solve problems related to fine-grained business logic components (transactions,security,persistence,maintainance,etc).
    I don't think the idea of Application Server is obsolete, especialy in large and complex environments. I'm also very concerned about numerous attempts to build fine-grained business logic using integration-related techniques (eg. misused SOA).
    http://www.enterpriseware.eu
  12. Re: EJB3 == Sun's Revenge![ Go to top ]

    Why mandate a servlet engine? Why not a common infrastructure into which any protocol adapter can be plugged (HTTP, JMS, SMTP/POP3), along with service containers (JEE, pojos, WS) to supply the actual functionality. Hey presto! It's JBI!
    And why not use OSGI to plug them in? Hey presto! It's Eclipse! ;-) (Yup, Eclipse could just be the basis of the next uber mega enterprise container.) Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  13. Re: EJB3 == Sun's Revenge![ Go to top ]

    And why not use OSGI to plug them in? Hey presto! It's Eclipse! ;-)

    (Yup, Eclipse could just be the basis of the next uber mega enterprise container.)
    Eclipse *uses* OSGi. It is an implementation of OSGi technology, just as Apache Felix is, and some others. OSGi would be the basis of the next uber mega container *not* Eclipse. Peace
  14. Re: EJB3 == Sun's Revenge![ Go to top ]

    OSGi would be the basis of the next uber mega container...
    Note that we've been working on Spring and OSGi integration for some time now. I posted a short description and some links on the Interface21 blog site today. The principles underlying Spring enable it to support a very wide range of environments...
  15. Re: EJB3 == Sun's Revenge![ Go to top ]

    Note that we've been working on Spring and OSGi integration for some time now.
    I honestly can't keep up with Spring. It moves faster than I can read ;-) Hopefully I'll get a chance to discuss this a bit further with you before too long .. it's a very interesting area, and I'm afraid it's going to catch some giants sleeping. Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  16. Re: EJB3 == Sun's Revenge![ Go to top ]

    Why mandate a servlet engine? Why not a common infrastructure into which any protocol adapter can be plugged (HTTP, JMS, SMTP/POP3), along with service containers (JEE, pojos, WS) to supply the actual functionality. Hey presto! It's JBI!


    And why not use OSGI to plug them in? Hey presto! It's Eclipse! ;-)

    (Yup, Eclipse could just be the basis of the next uber mega enterprise container.)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
    Yes, OSGi, or JMX, or (albeit non-standard) GBeans. The focus of these are on component lifecycle which IMO is less important than component interactivity, which JBI addresses and solves better. I am in the middle trying decide between all these approaches for a component-based server application I'm involved in. Regards Kit
  17. spring[ Go to top ]

    First good about spring, it is a non invasive technology and makes it possible to use a lot of technology with ease. However, - it does not provide much advantage while using it with Hibernate. it is a simple wrapper and you will immediately feel the fire after you deal with lazy loading issues, if you do not make the transaction configuration correctly. - AOP is a nice technology but i stil fail to see how much value it brings to JEE applications. some places it makes sense is the security and transactions maybe, but that areas can easily be covered with non AOP technologies. Main problem with aop is that it is a hurdle if your team is not educated about it. - Spring does not take advantage of Java 5 yet. Even after 2.0, there will be limited support. It means maintianing external configuration files. No generics support in API's. Even Spring MVC suffers because of it, Stripes by givin full Java5 support shines ove Spring MVC on this issue. - i dont like an API trying to please all libraries out there. sometimes is better off with going standards, or a tecnology focused on one thing, but doing it right. - Again, since it tries to please eveybody, it is bloated. it will help a little in Spring 2 i think by seperating the jars. you can even see different versions of libraries supported in it (hibernate 2-3, hessian 2-3 etc..) this also goes for the JEE 5 implementations, they should remove a whole lots of old stuff from their systems (EJB1-2 systems).. or at least versions they do not contain those stuff.
  18. Statefulness is the next item for consideration. Stateful beans are supported in EJB3 via stateful session beans; state is supported in Spring through the use of prototypes. The article states that Spring is primarily a framework emphasizing statelessness so there are some issues to consider when using a stateful element; note that this doesn't prevent stateful objects in Spring.

    As the author concludes:
    If you are working with applications that are highly stateful then you may want to consider whether EJB 3.0 SFSBs might be a good solution.

    I am wondering very much about this recommendation. We had an homegrown framework based on stateful session beans. This decision caused a lot of trouble with clustering, failover, performance (NFRs). After changing the architecture, using just and only stateless session beans and holding state just in the servlet containers, NFRs are met.

    What is your experience with stateful session beans?
    Regards
    Boris
  19. Statefulness is the next item for consideration. Stateful beans are supported in EJB3 via stateful session beans; state is supported in Spring through the use of prototypes. The article states that Spring is primarily a framework emphasizing statelessness so there are some issues to consider when using a stateful element; note that this doesn't prevent stateful objects in Spring.

    As the author concludes:
    If you are working with applications that are highly stateful then you may want to consider whether EJB 3.0 SFSBs might be a good solution.


    I am wondering very much about this recommendation. We had an homegrown framework based on stateful session beans. This decision caused a lot of trouble with clustering, failover, performance (NFRs). After changing the architecture, using just and only stateless session beans and holding state just in the servlet containers, NFRs are met.


    What is your experience with stateful session beans?


    Regards

    Boris
    Boris, My experience with stateful session other than SFSB (SFSB in the container didn't scale for me either), was very positive. We had a simple programming model for our webapp (setAttribute() getAttribute()) and yet we had total session fault tolerance at runtime. This meant that with a load balancer, we could shift traffic to any server at any time blindly without regard to what users might be doing on our site. And so operations had a very simple system to work with as did developers. As for scale, we were serving as many as 200 requests / second on a 2-way bottom-of-the-line Intel machine (actually, there were 100 of them so I guess we were doing 20K / second) with custom session clustering and 10 / second when we were stateless w/o Oracle storing most of the user's session-like data. Sort of why I built a company to contain these ideas and get them into others' hands. Have you checked out Terracotta for Spring? or Terracotta for Sessions? They are meant to help you along your way from state-in-the-DB or state-on-the-message-bus to state-in-the-heap. --Ari http://www.terracottatech.com/
  20. Sort of why I built a company to contain these ideas and get them into others' hands. Have you checked out Terracotta for Spring? or Terracotta for Sessions?
    Sort of why TSS feels sometimes like the Truman Show. I think there should be some kind of limit for the most blatant plugs. -Henri
  21. Have you checked out Terracotta for Spring? or Terracotta for Sessions?
    Nope. sorry. I've got Terracotta floor tiles though. ;-)
  22. Re: Recommendation for Stateful Session Beans?[ Go to top ]

    Could you please give some more details about SFSBs in your framework? From my experience I can say that SFSBs perform very well (clustering with memory-to-memory session replication) but of course configuration and fine-tunning of session replication is needed. http://www.enterpriseware.eu
  23. comparison?[ Go to top ]

    next up: a side by side comparison of apples and oranges the only piece of information i was looking for in the article is: if one choses Spring are they tying themself to a technology that prevents using the "standards"? i.e. going the Spring route are you hindering the usage of some feature of EJB3 or JEE5, etc. i think i know the answer but if the answer is that there is nothing in choosing Spring that prevents standard usage of EJB3 functionality then I don't see the purpose of the comparison one can like apples and orange -- and even eat them at the same time too. now, reading an article comparing Hibernate and EJB3 would be a worthwhile use of my time.
  24. Re: comparison?[ Go to top ]

    the only piece of information i was looking for in the article is: if one choses Spring are they tying themself to a technology that prevents using the "standards"? i.e. going the Spring route are you hindering the usage of some feature of EJB3 or JEE5, etc. i think i know the answer but if the answer is that there is nothing in choosing Spring that prevents standard usage of EJB3 functionality then I don't see the purpose of the comparison
    You can easily use Spring and EJB3 together. I did for a while before removing Spring altogether. The comparison is not pointless, however. Spring was and is intended to make J2EE easier. The introduction of JEE 5 addresses many of the concerns that Spring was a reaction to. In our case, I felt, for example, that the IoC capabilities of EJB3 worked well enough for us that Spring was no longer needed. Injection works well for us, and save us some external configuration management. Likewise, the automatic txn support is quite handy, so there's something else for which we don't need Spring.
    now, reading an article comparing Hibernate and EJB3 would be a worthwhile use of my time.
    Speaking of apple and oranges. I can only assume you mean Hibernate vs. JPA, in which case, JPA (to which we've migrated) works quite similiarly to Hibernate. In fact, we're using Hibernate as the JPA provider. The only thing I've run across so far is the lack of Criteria support in JPA, but we didn't use that under Hibernate, so that's a non-issue. jason lee
  25. Re: comparison?[ Go to top ]

    I can only assume you mean Hibernate vs. JPA, in which case, JPA (to which we've migrated) works quite similiarly to Hibernate.
    I can only assume you mean the JPA API of Hibernate .vs. the Hibernate3 API, since JPA as we all know is a (very light) API specification.
  26. Re: comparison?[ Go to top ]

    I can only assume you mean the JPA API of Hibernate .vs. the Hibernate3 API, since JPA as we all know is a (very light) API specification.
    Why would one compare the "JPA API of Hibernate" to JPA? You'd comparing two identical things, would you not? My guess is that he's curious as to how Hibernate, in its full JBoss goodness, compares to what can be done with JPA (regardless of provider). jason lee
  27. Comparison between truck and standard car[ Go to top ]

    next up: a side by side comparison of apples and oranges


    the only piece of information i was looking for in the article is: if one choses Spring are they tying themself to a technology that prevents using the "standards"? i.e. going the Spring route are you hindering the usage of some feature of EJB3 or JEE5, etc.

    i think i know the answer but if the answer is that there is nothing in choosing Spring that prevents standard usage of EJB3 functionality then I don't see the purpose of the comparison

    one can like apples and orange -- and even eat them at the same time too.


    now, reading an article comparing Hibernate and EJB3 would be a worthwhile use of my time.
    It's a comparison between using a truck and a standard car to commute. Due to overlaps between them, you can use both of them to commute between home and office, but in most cases people just choose one of them based on the type of their job and other requirements.
  28. Apples + Oranges = "Side-by-Side Comparison of Spring and EJB 3.0"
  29. JavaEE5 development without EJB3[ Go to top ]

    It has been well documented that the EJB3 spec borrows heavily from the lessons of Spring. A little less attention has been paid to the ways that Spring is playing catch-up with EJB3. EJB3 makes it pretty easy to handle stateful components, and to enable container management (including injection) of persistent model objects. Spring 1.x was extremely weak in both of these areas. The yet-to-be-released Spring 2.0 introduces a session scope for components, and injection capability for domain objects. Here's the kicker, though. The domain-injection feature requires use of AspectJ5. AspectJ5 is awesome, cool, and powerful, and has a steep learning curve. Spring has implemented a shared syntax between Spring 2.0 AOP and AspectJ5. In principle, this is the right thing to do, but in practice, it can sometimes be confusing to know where Spring AOP ends and where AspectJ5 begins. Two years ago, EJB2 was the complex, overfeatured monster, and Spring brought elegance and simplicity to the development process. Now, EJB3 brings a basic, 'good-enough-for-most-jobs' implementation of component management. Spring 2.0 offers a lot more power and customization, but the use of AspectJ actually makes the learning curve steeper. My preference is certainly for Spring 2.0, but it would not surprise me to see a lot of IT shops take the 'good enough' EJB3 route.
  30. Re: JavaEE5 development without EJB3[ Go to top ]

    You don't need wait for Spring 2.0 for stateful support. Spring 1.2.x has pooling support via AOP. In page 4, the article says: "In order for Spring-managed beans to contain state, instances cannot be shared between callers. To accomplish this, the scope of stateful beans in Spring should be configured as prototype. This means that each time a bean is retrieved from a bean factory a new instance is created." That is true if you use, for example, context.getBean() to retrieve a bean each time. But you can use a org.springframework.aop.TargetSource with a proxy to accomplish most of the EJB features, such as component pooling and even more (hot swappable, thread local and lazy initialized components). However, it is a bit more difficult to configure it, but it is the price for flexibility.
  31. Re: JavaEE5 development without EJB3[ Go to top ]

    Here's the kicker, though. The domain-injection feature requires use of AspectJ5. AspectJ5 is awesome, cool, and powerful, and has a steep learning curve. Spring has implemented a shared syntax between Spring 2.0 AOP and AspectJ5. In principle, this is the right thing to do, but in practice, it can sometimes be confusing to know where Spring AOP ends and where AspectJ5 begins .
    This is good point that you are raising and hopefully we'll see a sample app that showcases the two working together. better yet, i21 has AOP (AspectJ) gurus who wo do well to write a pragmatic book on these new features.
  32. What version of Spring?[ Go to top ]

    The article mentions Spring 2.0 in passing (basically when referring to JPA), but doesn't compare any of the annotation based abilities of Spring 2.0. Plus there is a Spring add-on project called Pitchfork which supports most EJB3 annotations. This doesn't even get a mention. In the persistance section, when talking about extended persistance scoping he talks about how EJB3 uses a persistance context on the Stateful sesssion bean.... in a conversation about persistance (which deals with entity beans). And he completely leaves out that persistance engines support level 2 caching. Depending on the cache (of which there are several open source and commercial) you can do clustering, file backing, etc. Also when talking about stateful session beans and Spring state, that when used in an HTTP session or a memory cache they need to be replicated (which is true) and it not transactional (which depends on the replication technology). I don't mind a comparison between Spring and EJB3. And Spring doesn't have to be better at everything. But I'm disappointed at the quality of the comparison.
  33. I'd like to see the author address what steps need to be taken to run a EJB 3.0 application outside of the JEE container versus what needs to be done in Spring. For starters, just to run the unit tests. But for more functional examples, what if I wanted to write an offline batch process, or needed to run some processes in separate JVMs so that it would be possible to kill one without impacting the other, or if I wanted to reuse some of the services in a standalone client application. To me, these are the real areas where Spring provides significant benefits by not handcuffing you to the container. I realize one of the efforts of EJB 3.0 was, at least for the persistence layer, enabling the running outside the container. However, I'm curious what steps are involved for doing so at the session bean level and how transaction management is maintained.
  34. The JBoss EJB3 container will run outside of an app server. There is nothing in the spec that prevents a vendor from making their implementation work outside the container.
  35. There is nothing in the spec that prevents a vendor from making their implementation work outside the container.
    They would be in pretty big trouble if the implementation *didn't* work outside of a container.
  36. Spring vs EJB 3.0[ Go to top ]

    If EJB 3.0 is a response to Spring then surely Spring has been doing the right thing. I realise EJB is a standard,but its not a proper true standard. Sun has a vested interest that developers follow their standard. If it was an ISO standard then I would say "yes lets follow that standard". Spring 2.0 provides support for Java 5 and I believe when Spring 2.0 is officially released it will make EJB 3.0 look paltry in comparison. AOP is an excellent concept that solves alot of problems that OO fails to address. I have been using Spring for nearly 2 years now and I think it's a excellent application framework that provides an array of benefits which aid the development of enterprise applications. As for distributed applications I can only quote Martin Fowler's law of object distribution: "Don't distribute your objects".
  37. Re: Spring vs EJB 3.0[ Go to top ]

    As for distributed applications I can only quote Martin Fowler's law of object distribution: "Don't distribute your objects".
    Well, most of us are aware of that "law". Unfortunately, when you have to support both Web and non-Web clients, you'll have to distribute your BOs, and that "law" becomes quite immaterial. A fair number of us working in financial environments have, or had to face the above case at some point. AFAIK, Spring does not support SFSB functionality. And saying that the case that I'm describing is quite rare (as Spring folks & Spring fans usually do) does not address the issue. Therefore, at least in this scenario, the statement "Spring > EJB3" is not true.
  38. Re: Spring vs EJB 3.0[ Go to top ]

    As for distributed applications I can only quote Martin Fowler's law of object distribution: "Don't distribute your objects".
    As far as I remember the main Fowler's point was that instead of distributing different objects on different machines (in order to scale a system) the whole object graphs should be clustered. The latter solution avoids remote operations of highly coupled objects. This doesn't mean that we should avoid distribution at all. http://www.enterpriseware.eu
  39. Re: Spring vs EJB 3.0[ Go to top ]

    This doesn't mean that we should avoid distribution at all.
    My point was precisely that sometimes, you can't avoid distribution. And in that case, Spring does not provide a viable alternative to EJB.
  40. Re: Spring vs EJB 3.0[ Go to top ]

    Perhaps you can't avoid object distribution but I don't think EJB is the only model alternative. Jon Spalding makes some valid points about the alternatives to the EJB model, and I am aware that a major US investment bank is currently using Spring and Gigaspaces that provides a better solution than the traditional approaches to J2EE. See the following: http://www.interface21.com/news-home/2006/gigaspaces-spring-june-2006
  41. Re: Spring vs EJB 3.0[ Go to top ]

    Perhaps you can't avoid object distribution but I don't think EJB is the only model alternative.

    Jon Spalding makes some valid points about the alternatives to the EJB model, and I am aware that a major US investment bank is currently using Spring and Gigaspaces that provides a better solution than the traditional approaches to J2EE. See the following:
    http://www.interface21.com/news-home/2006/gigaspaces-spring-june-2006
    I am fully aware that there are or might be alternatives. The problem, as always, would be to choose the one that is the simplest for the problem domain. I am only looking for the right tool for the right job, and I didn't want to come out as anti-Spring nor particularly pro-EJB. The two can actually be used together...as our own architecture (banking) does. Thanks for the link, though.
  42. Re: Spring vs EJB 3.0[ Go to top ]

    AFAIK, Spring does not support SFSB functionality.

    And saying that the case that I'm describing is quite rare (as Spring folks & Spring fans usually do) does not address the issue.

    Therefore, at least in this scenario, the statement "Spring > EJB3" is not true.
    Whilst Spring does not support SFSB functionality out of the box it is possible to replicate it's features if necessary. Session scoping can be implemented using Spring 2.0's custom scopes or by writing your own in-house solution. Spring-managed beans can be clustered using third-party tools such as Tangosol Coherence, Gigaspaces and Terracotta. More complex to set up than SFSB I admit, but you gain increased flexibility and the ability to choose your own architecture rather than rely on the EJB model.
  43. Upgrade paths[ Go to top ]

    An important point to note is the different upgrade paths for Spring and EJB. Whilst EJB 3 is a good spec, there is no easy way to convert all of your EJB 2.1 code and configuration to EJB 3. Plus you have the added effort of upgrading your app server and possibly paying extra licensing costs. Spring 2.0 however, will be a drop-in replacement for 1.2 and will require no other changes than swapping the JAR files over. This can also be an indication of future trends, will EJB 3.1/4 be backwards compatible with 3.0? Will Spring 2.x/3.0 be as easy to adopt as 2.0? We can't know for sure but the Spring team seem far more committed to this issue than the EJB team.
  44. Re: Upgrade paths[ Go to top ]

    An important point to note is the different upgrade paths for Spring and EJB.

    Whilst EJB 3 is a good spec, there is no easy way to convert all of your EJB 2.1 code and configuration to EJB 3.
    Two points to make here. First, it's not necessary to convert any of your EJB 2.1 or earlier code over to EJB 3. Everything in EJB 2.1 and earlier revs of the spec is still fully supported and continues to work the same way. You can mix EJB 3 beans with 2.1 and earlier beans in the same app, and you can call EJB 3 beans from a J2EE 1.4 or earlier server if you provide a backward-compatibility "component interface" on your EJB 3 bean. (Providing this interface doesn't interfere with any of its EJB 3 capabilities.) So while you may want to convert some code you certainly don't have to. Perhaps if you need to go in and mess with the code for some other reason, such as adding new function.... Second, for session beans it's trivial to convert them to EJB 3 POJOs. Basically you delete the "implements SessionBean" from your implementation class declaration. Then you delete the "implements EJBObject" or "implements EJBLocalObject" from your business interface definition(s). (And you can also delete your EJBHome interface since Homes aren't used in the EJB 3 model.) Now since you're down to basic Java objects and interfaces, you can test your object's business logic outside of the container, etc. For the configuration, it's essentially a matter of deleting the stanzas in your XML deployment descriptor that no longer apply (or even deleting the DD entirely and marking your bean class with the @Stateless or @Stateful annotation instead.) For entity beans it's more of an apples and oranges thing. The POJO entities in JPA are more of a radical shift from EJB 2.x and 1.x entity beans than the POJO session beans are in EJB 3. 2.x and 1.x entities continue to work unchanged under EJB 3 so if you have working entities, there's no particular reason to convert them over to JPA unless you want to use a new function like disconnect/reconnect (merge). And 2.x and 1.x entities can co-exist happily with JPA entity POJOs in the same application. (It's recommended that you avoid operating on the same database rows with JPA POJOs and entity beans within the same transaction, because the JPA data operations are not intercepted by the container. Exactly like it's recommended that you avoid using direct JDBC calls and entity beans on the same database rows within the same tran.) I can vouch that the EJB 3 expert group was quite committed to preserving upward-compatibility. If you look at the track record of EJB versions, every version has preserved compatibility with previous versions and EJB 3 continues this.
  45. Re: Spring vs EJB 3.0[ Go to top ]

    Whilst Spring does not support SFSB functionality out of the box it is possible to replicate it's features if necessary. Session scoping can be implemented using Spring 2.0's custom scopes or by writing your own in-house solution. Spring-managed beans can be clustered using third-party tools such as Tangosol Coherence, Gigaspaces and Terracotta.

    More complex to set up than SFSB I admit, but you gain increased flexibility and the ability to choose your own architecture rather than rely on the EJB model.
    Not a very good alternative. In this case, EJB is still the simplest solution. And I do not find the Spring alternative you're describing particularly "lightweight", as opposed to the so-called "heavyweight" or "too complex" (sigh) EJB. And what's wrong with relying on the EJB model, if it is the right tool for the job in the particular case that I described?
  46. Re: Spring vs EJB 3.0[ Go to top ]

    I don't know why all this interest in stateful session beans. I cannot understand! Anyway there is no particulare problem where a stateful session service cannot be changed in another stateless session session service equivalent. More over, there is a lot of code out there written in java based on Spring philosophy, not based on the EJB3 framework. This is indicative. In my honest opinion spring framework is simpler yet powerfull. Anyway, of course, the simpler framework for you is the framework you use, not the framework you don't,....and probably the best framework for you is the framework you know better. bye bye
  47. Re: Spring vs EJB 3.0[ Go to top ]

    Anyway there is no particulare problem where a stateful session service cannot be changed in another stateless session session service equivalent.
    When the problem to solve has stateful nature using stateless solution usually causes performance problem called "cost of session restoration"
    http://www.enterpriseware.eu
  48. Re: Spring vs EJB 3.0[ Go to top ]

    mmmmmm.....it depends on your implementation! The problem of "cost of session restoration" is not true in general. Anyway using a stateless service you can distribute it on more than one host, that's is a great thing! You can distribute and duplicate it as many times you want. This is important for high availability.
  49. Re: Spring vs EJB 3.0[ Go to top ]

    mmmmmm.....it depends on your implementation! The problem of "cost of session restoration" is not true in general. Anyway using a stateless service you can distribute it on more than one host, that's is a great thing! You can distribute and duplicate it as many times you want. This is important for high availability.
    FWIW, Services themselves do not tend to be stateless, so stateless implementations of stateful services just delegate the state management somewhere else, typically introducing single points of failure (SPOFs) and bottleneck (SPOBs) into an architecture. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  50. Re: Spring vs EJB 3.0[ Go to top ]

    mmmmmm.....it depends on your implementation!

    The problem of "cost of session restoration" is not true in general.

    Anyway using a stateless service you can distribute it on more than one host, that's is a great thing!
    You can distribute and duplicate it as many times you want.

    This is important for high availability.


    FWIW, Services themselves do not tend to be stateless, so stateless implementations of stateful services just delegate the state management somewhere else, typically introducing single points of failure (SPOFs) and bottleneck (SPOBs) into an architecture.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
    I find this subject very interesting so can you elaborate on this please? What are the disadvantages of storing objects in the http session in conjunction to using a cache solution compare to stateful session beans? I have heard Gavin King couple of times on the subject but I wasn't really convinced. On the other hand, the Spring team seems to think that handling state in the web tier is most of the time the way to go.
  51. Re: Spring vs EJB 3.0[ Go to top ]

    On the other hand, the Spring team seems to think that handling state in the web tier is most of the time the way to go.
    I guess they are considering the most common uses of J2EE, i.e Web applications. In most of those cases, holding session data in the Web tier is usually more scalable. The problem starts when you need to hold state on behalf of multiple client types, or share state, or maintain remote sessions for non-Web clients. Also, there are cases where holding state in the database and using stateless services result in excessive amount of data being transfered across the network, and hence is not a viable alternative. I wish some people would refrain in general in considering IoC containers as Golden Hammers, as others - or the same people? - did with EJB a few years ago. There are still (a few?) cases where using EJB is the best solution, IMHO.
  52. Re: Spring vs EJB 3.0[ Go to top ]

    On the other hand, the Spring team seems to think that handling state in the web tier is most of the time the way to go.


    I guess they are considering the most common uses of J2EE, i.e Web applications.
    In most of those cases, holding session data in the Web tier is usually more scalable.

    The problem starts when you need to hold state on behalf of multiple client types, or share state, or maintain remote sessions for non-Web clients.

    Also, there are cases where holding state in the database and using stateless services result in excessive amount of data being transfered across the network, and hence is not a viable alternative.

    I wish some people would refrain in general in considering IoC containers as Golden Hammers, as others - or the same people? - did with EJB a few years ago.

    There are still (a few?) cases where using EJB is the best solution, IMHO.
    Actually I think Rod Johnson recommends in his book using EJB in those cases.
  53. Re: Spring vs EJB 3.0[ Go to top ]

    Actually I think Rod Johnson recommends in his book using EJB in those cases.
    There is a conceptual heuristic that can be used: is the problem presentation or business logic related?
    There are also technical features of EJBs: concurrency management, transparent transactions management, remote interfaces (using servlets for remote process communication is possible but requires some hand-coding and doesn't provide passing of transaction context)
  54. Re: Spring vs EJB 3.0[ Go to top ]

    I find this subject very interesting so can you elaborate on this please? What are the disadvantages of storing objects in the http session in conjunction to using a cache solution compare to stateful session beans?

    Well, I used (in a past proj) the solution you refered : http session with a simple cache on the server side, it worked well and fast. In another proj, I had developed an e-commerce server with a WebStart client: it was very nice and amusement! The session was stored in the client side; The server services could be implemented in stateless way; They could be clustered with a balancer installed in the client side. Thus, if you have a "heavy" client, I think you have no problems on this kind. So, IMHO, the only problem is when the client is a Web Browser, i.e., using JSP technology. But, in this latter case, you can use the web session mechanism as you said before. I have not encountered problems of this kind:
    typically introducing single points of failure (SPOFs) and bottleneck (SPOBs) into an architecture.
    I think that these problems are related on how you define your services, how much work they do and how they are organized, how your have defined your use cases in your UML diagrams.... But everyone has its own experience in j2ee projects and in problems encountered.... What did you hear about this problem from Gavin King? Bye Bye.
  55. Re: Spring vs EJB 3.0[ Go to top ]

    What did you hear about this problem from Gavin King?Bye Bye.
    When he speaks about Seam, he is usually comparing the different server-side possible stateful mechanisms. While I agree with him that storing the state in the DB is a bad idea, I wasn't getting the difference between storing it in the http session and using stateful EJBs. But I guess like Cameron said, the difference is in the programming model : real stateful objects versus a kind of hashmap, although Spring scoped beans offer a nice abstraction over the http session.
  56. Re: Spring vs EJB 3.0[ Go to top ]

    FWIW, Services themselves do not tend to be stateless, so stateless implementations of stateful services just delegate the state management somewhere else, typically introducing single points of failure (SPOFs) and bottleneck (SPOBs) into an architecture.
    I find this subject very interesting so can you elaborate on this please? What are the disadvantages of storing objects in the http session in conjunction to using a cache solution compare to stateful session beans? I have heard Gavin King couple of times on the subject but I wasn't really convinced. On the other hand, the Spring team seems to think that handling state in the web tier is most of the time the way to go.
    Gavin's work in Seam is based on stateful session beans (EJBs). At a storage / network level, there is really nothing conceptually different between HTTP sessions and stateful session beans, or caches for that matter. However, at a programming level there are some trade-offs in terms of what QoS the standards provide, which is probably why Gavin selected the stateful session beans. Contrast that (stateful in the app container) with round-tripping to the database on every request, and you understand why stateless architectures scale so poorly for typical applications. Peace, Cameron Purdy Tangosol Coherence: Clustered Shared Memory for Java
  57. JEE container ... unit tests...
    It took a while for someone to mention unit testing. This was a a good, timely article by the way. I was surpised to hear a poster say that ejb3 offered enough to drop Spring from his stack? I suspect there will be creeping spaghetti code without a good IoC framework to incent good design. Unit testing will probably be just a bit harder too. Spring is a better setter/getter-based IoC framework that was first popularized by pico container's constructor oriented IoC. It's not Spring or ejb3. I can have my pojos and componentize them too. If you take some of the non-functonal features that J2EE does a good job addressing, albeit through verbose desriptors and forced interfaces (old school), such as remotability, transactional demarcation, security, naming, and deployment, Spring has a simple answer for most of these or it wraps a J2EE answer. The implementation specific features of J2EE such as high availibility, scalibility, concurrency, performance, and instrumentation are still available to a Spring-centric app. Your container is as heavy as you want it to be. I can scale from Tomcat to Weblogic (quality/(time*$)). ejb3 brings back simplicity but I lose choice given the number of implementations. Reflection-oriented aspects are pretty powerful too. You don't need to learn AspectJ to get started with aop-alliance reflection-oriented aspects. Acegusecurity uses aop to manage method interception and object ACL security. Check it out. You can secure a method call by role and filter objects being returned from the call. I look forward to the follow-up article.
  58. Correction[ Go to top ]

    Already commented on the mistakes in the article when I first saw it and posted here: http://www.infoq.com/news/spring-ejb-3-compared#view_2452
  59. Re: Correction and Switch[ Go to top ]

    Is this a first? Refer back to a InfoQ comment from TSS. Not sure the landlord will like this.
  60. Re: Correction and Switch[ Go to top ]

    Well Mike works for Oracle, not InfoQ, and posted under his own name, so I guess there's no evil agenda there :-)
  61. Re: Correction and Switch[ Go to top ]

    Is this a first? Refer back to a InfoQ comment from TSS. Not sure the landlord will like this.
    Most JEE stuff on InfoQ seem to be references to TSS posts any way. "You scratch my back, I'll scratch yours".