Discussions

News: Book Review: J2EE Development without EJB

  1. Book Review: J2EE Development without EJB (30 messages)

    Dion Almaer reviews Rod Johnson's latest book, 'J2EE Development without EJB'; he walks us through the three sections of the book. Part 1 provides a thorough, high level view of architecture in the enterprise Java arena. Part 2 looks at the lightweight container movement and the Spring Framework, and the final section overviews the Spring version of the Petstore sample application.

    Read the Book Review of J2EE Development without EJB

    Threaded Messages (30)

  2. what will people say?[ Go to top ]

    If this go on I seriously will consider Java development again myself but what of the common "computer scientist"?

    Indignified:
    No SessionBeanStore EJB pattern? No Aggregate pattern of EntityBeansAsDomainObjects? No Extended Super Remote Interface via Session FacadesAsDistributedComponent? No CacheEntity pattern of EntityBeansAsDomainObjects? No object grahps of EntityKeys with local interfaces calling session beans with remote interfaces? No "Organization of inter-service transfers according to known use cases from domain objects into coarse-grained Composites?" Not even some small generic Entity Patterns?

    What will the world come to if the unwashed masses is allowed to produce better code than US!?
    You have to think trough again the implications of taking away the professional pride and reason for living for the Créme de la Créme of the Java Society.

    It is terrible, IMO.

    Regards
    Rolf Tollerud
  3. what will people say?[ Go to top ]

    If this go on I seriously will consider Java development again myself
    Dont
  4. AOP Transactions[ Go to top ]

    I recently read AspectJ in Action from Manning Press. It discusses transactions too, but through AspectJ and the resulting efforts are not container dependent. I think that Spring as an IoC container is great, but if people want Aspect Oriented features, just do yourself a favor and learn AspectJ in Eclipse with the AJDT plugin. None of this runtime Proxy of Proxy of InvocationHandler stuff to slow down your application.
  5. AOP Transactions[ Go to top ]

    Jacob
    I recently read AspectJ in Action from Manning Press. It discusses transactions too, but through AspectJ and the resulting efforts are not container dependent. I think that Spring as an IoC container is great, but if people want Aspect Oriented features, just do yourself a favor and learn AspectJ in Eclipse with the AJDT plugin. None of this runtime Proxy of Proxy of InvocationHandler stuff to slow down your application.
    AspectJ is a great language: no argument there. I also like Laddad's book. But AspectJ is not the perfect solution to all AOP problems, and often simpler, lower-tech, solutions are compelling.

    Transaction management is a case in point. For a lot of middleware aspects, which typically require only method interception, AspectJ's full power doesn't come into play, and it has no great advantage over Spring AOP, DynAOP or another proxy based framework. For example, Laddad's book is excellent, but the transaction examples are just that--examples of how you might start work on transaction management in AspectJ. Spring's transaction interception is way more powerful than anything I've seen implemented using AspectJ. Of course you can implement whatever sophisticated of transaction interception you like with AspectJ--it's just that what really matters is how you abstract the underlying transaction infrastructure, not what AOP framework you use. The performance overhead of a proxy-based approach is insigificant in such cases.

    So there is a valid case for the subset of AOP that proxy-based solutions provide. (Also they can do one or two things that are hard to do with "full-blown AOP," such as maintain different advice for different objects of the same class.)

    Having said that, I believe that AspectJ is going to become increasingly important as we come to understand the full implications of AOP. So one of the major features in Spring 1.1 is AspectJ integration. This will allow AspectJ aspects to be configured by the Spring IoC container using Dependency Injection, which brings similar benefits to applying DI for classes. Both Adrian Colyer and I are very excited about this, and both Spring and AspectJ teams are working together. Support for the core AspectJ integration is already in Spring CVS and will be released with Spring 1.1 RC1 (probably end of next week). I'm also working on some samples, which will probably be released separately slightly later. The Spring/AspectJ integration opens up some interesting possibilities.

    Beyond that, we're looking at using AspectJ pointcuts to target Spring AOP advice. This relies on AspectJ changes--they are going to expose an API for Spring and other tools to use at runtime.

    Another interesting area is implementing Spring services as "native" AspectJ aspects. Thus we'll provide a transaction aspect, probably in the Spring 1.2 timeframe, although I might release it with the samples.

    Rgds
    Rod
  6. A timely classic.[ Go to top ]

    Rod, congratulations on a fantastic book. It cuts right to the heart of what's wrong, and right, with J2EE.
  7. A timely classic.[ Go to top ]

    Rod, congratulations on a fantastic book. It cuts right to the heart of what's wrong, and right, with J2EE.
    Maybe Spring folks will now have some time to read book by Jacob Nielsen (http://www.useit.com/alertbox/20031110.html ) and then change their horribly looking site to something more usable and user friendly (liquid layout).
  8. A timely classic.[ Go to top ]

    Rod, congratulations on a fantastic book. It cuts right to the heart of what's wrong, and right, with J2EE.
    Maybe Spring folks will now have some time to read book by Jacob Nielsen (http://www.useit.com/alertbox/20031110.html ) and then change their horribly looking site to something more usable and user friendly (liquid layout).
    You kidding ? Spring's site is simple, elegant and to the point. You wanted some naked chicks in there ? Better take a look to XUL site and many others in fact. spring framework site is decent.
  9. A timely classic.[ Go to top ]

    Maybe Spring folks will now have some time to read book by Jacob Nielsen (http://www.useit.com/alertbox/20031110.html ) and then change their horribly looking site to something more usable and user friendly (liquid layout).
    You kidding ?
    No, I am not. Look how it looks on biiger monitors when I try to scale (CTRL+ in Mozilla) at http://kgionline.com/annoying/web/annoying_web.jsp
    Spring's site is simple, elegant and to the point. You wanted some naked chicks in there ? Better take a look to XUL site and many others in fact. spring framework site is decent.
    What a silly argument, if somebody does poor job it DOES NOT an excuse for doing poorly too!
    Spring is a nice framework and deserves better cyberspace gateway.
    And yes, I would prefer naked HTML and scalable layout to anything else, no mastter how nice that something looks on a particular system with particular monitor size and screen resolution.
  10. A timely classic.[ Go to top ]

    Why didn't you just say so from the start ? Why should some people (Spring) read some '10 points receipe' to successful web sites to find that their site doesn't work in a particular situation in a particular browser that has 2% from the total number of web surfers ? I hope that when you find a bug in Spring you won't point them to reading GoF patterns or Effective Java and say that reading it would have helped them to avoid the bug in the first place :-)
    ummm ... however you have a valid point. The screenshot you took looks pretty bad
  11. You will see "Hibernate, or JDO" a lot in the text. Maybe we should create a new acronym H/JDO which means the same thing.
    Perhaps we should call it "jDOH!" for all those Homers out there...

    Cheers,
    Lars :-)
  12. Acronym fun[ Go to top ]

    How about HOJO = HO + JO, Hibernate Object + JDO Object!

    :)
  13. With all the buzz around Hibernate and JDO , it seems many people are missing out on the simplicity that is provided by IBATIS. Kudos to Rod and Spring team for keeping it simple and going with IBATIS for their Pet Store implemention.
  14. iBATIS[ Go to top ]

    With all the buzz around Hibernate and JDO , it seems many people are missing out on the simplicity that is provided by IBATIS. Kudos to Rod and Spring team for keeping it simple and going with IBATIS for their Pet Store implemention.
    I like iBATIS. I was skeptical at first about whether there was value in something between JDBC (or neater JDBC like Spring JDBC) and an ORM tool, but I think that Clinton's mapped statement concept is really useful in many cases. I heard him give an excellent presentation on it in New York a few months ago and that helped to convince me, too. Of course with Spring's data access abstraction, business logic is substantially insulated from the details of data access, also.

    R
  15. I don't mind that Dion and Rod are JDO fans, but I can't say I care for the term H/JDO. JDO and Hibernate are not interchangable technologies and the use of such an acronym suggests that one is a drop in replacement for the other. Both offer some measure of transparent persistence, but the similarity ends there.

    Is this an attempt to create some kind of association between JDO and Hibernate? The same thing appears in Bruce Tates java.net articles where he suggests that JDO (Kodo in particular), is the enterprise-level ORM tool that people should use when they graduate from Hibernate, as if that is the natural evolutionary path.

    Rod appears to have gone out of his way to suggest that developers use some kind of transparent persistence, with Hibernate and JDO as possible ideas. Let's not use reviews like this to play advocacy games.
  16. Point of clarification[ Go to top ]

    Since you've called me out, perhaps I should comment. I don't think that there's any doubt that Hibernate and Kodo are two of the top persistence frameworks out there. I don't mind plugging good frameworks, and don't mind talking about the niches were I think they best fit. As it relates to Spring, this comes up pretty frequently, for a reason.

    In the realm of persistence frameworks, especially as they pertain to persistence programming within something like Spring, Hibernate and JDO have some striking similarities. In particular, the programming model that surfaces at the facade in Spring is now very close. The PM/session usage models have some similarities, especially when they're hidden behind some abstractions. The two-level caching models are similar, in contrast with something like CMP or Top Link. And when you start to use proxies within Hibernate, then you're using byte code modification for both, and the line blurs a little more, which is also in contrast with many of the existing frameworks that rely on code generation like CMP, subclass-based persistence frameworks, and others.

    Contrast them to Cayane, which uses subclassing rather than transparent persistence, or EJB, which uses a proprietary component model and code generation, or Top Link, which has a fundamentally different caching model, or frameworks like IBatis which fundamentally simplify JDBC DAO models, and you can see why so many people see the usage as similar.

    To get back on topic, the nice thing about this book is that it shows you how to build an effective abstraction around something like a Hibernate and effectively hedge your bets with a pluggable DAO layer. You could then have a lightweight migration to something like, yes, JDO, or in the other direction, should your needs ever move in that direction. You have common exceptions and a common exception model (unchecked), common pluggable transaction strategies, common resource management strategies...with a simple application, a whole lot is common with a couple of big exceptions: the JDO 2.0 detachment model and lifecycle issues, and the query languages. You can then effectively take advantage of significant differences in implementation, performance, and mapping support as your business needs dictate.

    I don't mean to make them seem as completely transparent, or imply that a migration would be effortless. But there are enough similarities so that an effective abstraction can make pluggability, to some extent, desirable. Get the book. It's all in there.
  17. Hi Merrick -

    I think the acronym posts on this thread are people having a bit of fun.

    I think that Rod has tried hard NOT to plug one technology. This is why he uses Foo OR Bar, and "a lightweight container" not just Spring.

    I am a fan of transparent persistence. I think that there are many tools that give you this, including Hibernate and JDO. I don't think anyone is trying to directly plug one.

    Cheers,

    Dion

    ps. we are lucky to have the options that we do in our technology stack. Ask the ObjectSpaces guys if they want to just ship already! ;)
  18. Eagerly anticipating this book![ Go to top ]

    I've used Rod's first book and if his second has even 50% of the nuggets, it will be well worth it!

    Rod's work has caused fundamental changes in how I write code.
  19. donot like runtime exception[ Go to top ]

    I like Spring framework. Just do not like the runtime exception.
  20. Since it looks like the book has made it to the people at The Middleware Company, will those of us who indicated that we wanted this book as part of the promotion of attendance at May's Java Symposium in Las Vegas have that wish fulfilled? Is there anyone else out there in the community that attended the Symposium that still waiting for this book fulfillment, or did mine get lost in the shuffle? Just wondering if I'm going to have to dole out some money for this book.


    Kind regards,

    -- chris bartling --
  21. stability and problems[ Go to top ]

    Being new to Spring but very open indeed to the "back-to-simplicity"-approach it represents, I'd love to base one of my next projects on Spring rather than EJBs. I would greatly appreciate if some of you were willing to share their experiences with Spring - in particular if they had problems that we could learn from.

    One of the larger concerns I have is the rate of change in Spring: with a conservative EJB-approach I can be rather sure that I won't have to adapt my software to changes in the middleware anytime soon. (But EJBs are much more intrusive than Spring, of course.) Which areas of Spring are considered stable and mature, and which are the most fluid?

    Lastly, I wonder how Spring's approach can find a way into the JCP and "mainstream, standardised" J2EE. This *is* important to some of us...

    Alas, I'm looking forward to the delivery of my copy of "J2EE Development without EJB" (-;

      cheers,
      gerald
  22. Stability[ Go to top ]

    Gerald
    One of the larger concerns I have is the rate of change in Spring: with a conservative EJB-approach I can be rather sure that I won't have to adapt my software to changes in the middleware anytime soon. (But EJBs are much more intrusive than Spring, of course.)
    I don't want to engage in EJB bashing--really--but EJB is a technology with a poor record of backward compatibility. E.g.
    - entity beans needed a rewrite to go from 1.1 to 2.x
    - entity beans will need a rewrite--pretty much a re-design--to go from 2.1 to 3.0
    - The recommended EJB 3.0 programming model will look a whole lot more like Spring/Hibernate than EJB 1.x or 2.x, meaning that migration from a Spring/Hibernate solution would probably be easier than migration from a traditional EJB solution.

    True, backward compatibility is guaranteed in each version of the EJB specification. So your EJBs don't break with each new version of the spec. But obviously there are many reasons you don't want code in very different styles sticking around in your codebase. So ultimately the aim will be to migrate the old stuff to the new model, and that's a big cost. (I know, I've been there.) It's a matter of time as to when you migrate, but you will want to if your application lives long enough.

    Why is this? Because, arguably, each generation of the EJB spec has had flaws that needed to be rectified. Most--but by no means all--of those flaws concerned entity beans.

    But far more importantly, it's the issue of intrusiveness, which you mention. (We normally use the term invasive.) EJB is an invasive API, which forces you to work either with an abstraction layer, and to depend on JNDI as well.

    EJB does not decouple the evolution of the container from the evolution of application code. Dependency Injection--and the ability to provide declarative services to POJOs--does provide such decoupling, to a very large degree. And that's a huge benefit. Thus we can improve the implementation of Spring without breaking your apps. We aim that you shouldn't need to depend on Spring APIs to get the core IoC and AOP features. There are parts of Spring that work much like class libraries--like the JDBC abstraction layer--but that is distinct from the component model.

    So I would say--judge whether you need to use EJB based on whether it's the best technology for your requirements, not because of trusting in it to provide backward compatibility.
    Which areas of Spring are considered stable and mature, and which are the most fluid?
    We consider the Spring API to be stable and mature. That's why we spent over a year of development before we released 1.0 final. Remember that the open source project began from the Interface21 framework published with Expert One-on-One J2EE, so that year's hard work took place with much of the basic architectural model already in place.

    To put this in perspective, to my knowledge 1.1 will be 100% backward compatible with 1.0. There's a significant amount of new functionality, but the existing API is honoured. I know of 4 or 5 method deprecations, but the deprecated methods will stay there until at least 1.2. I would say that our record on backward compatibility is very good.

    Above all, we have a large user base. People have applications in production, and we do not want to break them. (Many Spring developers support Spring apps in production themselves also.)

    Rgds
    Rod
  23. Stability[ Go to top ]

    Just to clarify: when I mention "4 or 5 method deprecations," the methods in question are very rarely used by application developers. We're pretty happy with our architecture and API overall, and have no plans to deprecate any commonly used methods.
  24. stability and problems[ Go to top ]

    [...] I would greatly appreciate if some of you were willing to share their experiences with Spring - in particular if they had problems that we could learn from. One of the larger concerns I have is the rate of change in Spring: [...]
    We have been using Spring in several projects, including some high volume ones, since pre-1.0 days. In the run-up to 1.0 some APIs were tweaked, and this did affect us, the changes were well documented and easy to absorb. We've kept up to date with zero problems since, and I am not aware of any upcoming incompatible changes in 1.1. As Rod indicates, most of the framework is fully mature.

    About the general Spring experience I can be quite brief. The only real problem we had is that it took the team some time to get their heads around IoC, AOP, the flexibility of the MVC framework and so on. It might be an idea not to go the whole hog at once like we did :) As early adopters, we found a few issues, all of which we could either fix ourselves (amazing, a codebase that you can actually find your way around in) or were fixed by the Spring team in one or two days. Spring it has been the single most liberating and problem-free framework we've ever had the pleasure to work with. It definitely helped us to produce better software quicker. I have no reservations in recommending it wholeheartedly.

    HTH

    Peter (Principal Systems Engineer, Objectivity Ltd, not speaking on behalf of my company though.)
  25. Thanks, Peter and Rod, for taking the time to answer - I appreciate your feedback and it sounds very convincing to me.

    (A note on entity beans: I would never use them - that's what I meant by "conservative" use of EJBs ;-)

      cheers,
      gerald
  26. Gerald,

    As co-lead developer of the Spring core, I can assure you that we go beyond our personal limits to keep the Spring codebase as stable, clean, and backward-compatible as possible :-) Whatever is still in flux remains in the sandbox for the time being, not becoming part of a Spring release.

    When you look at Spring's timeline, you'll notice that we had 4 milestone release before 1.0 RC1. We decided to adopt that approach for the phase in which the rate of change and in particular of new core features was very high. Incompatible changes were preferred to imperfect solutions at that time.

    Since 1.0, backward compatibility is a primary goal. Spring 1.1 introduces some new options in the core (like support for method injection), but mainly focuses on new integration packages that do not the affect the rest of the framework (like OJB support, JMS support, and enhanced JDO support).

    Regarding the JCP and standardized J2EE: I take the view that J2EE should concentrate on specific system services (servlets, JTA, JCA, RPC entry points, etc). Fine-grained local component models on the other hand should be the domain of application frameworks, (potentially) running on top of J2EE.

    Spring runs nicely on plain Java just like any J2EE server out there, being able to leverage whatever system services are available, and allowing for a high degree of testability. Its main goal is reusability of application objects in any environment, including services like declarative transactions.

    The primary goal of J2EE is arguably different: It provides system services for the server side, which inevitably incurs a different tradeoff. EJB is a component model on top of that, for the server side only. EJB3 still follows that tradition, with services that are just available in a J2EE server.

    Cheers,
    Juergen

    P.S.:
    If you're the same Gerald Loeffler that does J2EE lectures for the university of Linz in Austria - I happen to be based in Linz :-) Maybe drop me an email (to my SourceForge address) if you're interested in having a personal chat!
  27. Thick client?[ Go to top ]

    I am disappointed that both of Rod Johnson's books ignore Java Web Start and Swing clients. Folks tend to use web clients always, and many, many situations are better served by a thick client (intranet apps for example). His books persuade legions of developers to follow him into web-client nirvana. Hey, if Rod Johnson never uses thick clients, they must be inferior!
  28. Thick client?[ Go to top ]

    I am disappointed that both of Rod Johnson's books ignore Java Web Start and Swing clients. Folks tend to use web clients always, and many, many situations are better served by a thick client (intranet apps for example). His books persuade legions of developers to follow him into web-client nirvana. Hey, if Rod Johnson never uses thick clients, they must be inferior!
    So, you are auto mechanic because he doesn't fix bikes? Why not take your bike to a bike shop? They both get you from A->B, but they are not the same, vehicle, are they?

    Instead of being mad at Rod, why not find a book that talks about what you do like? For me, Rod's books are right on target.
  29. Thick client?[ Go to top ]

    I am disappointed that both of Rod Johnson's books ignore Java Web Start and Swing clients. Folks tend to use web clients always, and many, many situations are better served by a thick client (intranet apps for example). His books persuade legions of developers to follow him into web-client nirvana. Hey, if Rod Johnson never uses thick clients, they must be inferior!
    So, you are **mad** auto mechanic because he doesn't fix bikes? Why not take your bike to a bike shop? They both get you from A->B, but they are not the same, vehicle, are they?Instead of being mad at Rod, why not find a book that talks about what you do like? For me, Rod's books are right on target.
  30. Thick client?[ Go to top ]

    I am disappointed that both of Rod Johnson's books ignore Java Web Start and Swing clients. Folks tend to use web clients always, and many, many situations are better served by a thick client (intranet apps for example). His books persuade legions of developers to follow him into web-client nirvana. Hey, if Rod Johnson never uses thick clients, they must be inferior!
    So, you are **mad at the** auto mechanic because he doesn't fix bikes? Why not take your bike to a bike shop? They both get you from A->B, but they are not the same, vehicle, are they?Instead of being mad at Rod, why not find a book that talks about what you do like? For me, Rod's books are right on target.
    Sheesh.
  31. Just received my copy from Amazon.

    I don't know why Dion gave the sample application as much as one third of the book. In fact, it takes just 1 (!) out of 17 chapters. And what chapters!

    Compated to the first Rod's book ("Expert one-on-one J2EE Design and Development") the new book presents some familiar material but completely re-worked and updated, plus entirely new stuff; what is even more important is that the book reflects the fundamental shift in extremely dynamic Java/J2EE software development world happened since the time of the first edition.

    The only question is why Juergen in not on the cover page?

    Regards,
    Valeri