Getting Used to EJB

Home

News: Getting Used to EJB

  1. Getting Used to EJB (17 messages)

    In the latest TSS cartoon, conceived by Jason Carreira, an experienced EJB developer breaks in a newbie. He shows off the golden hammer, and then puts on the pads which aim to help out.

    View Getting Used to EJB

    Threaded Messages (17)

  2. HA![ Go to top ]

    Great work Jason! Best TSS cartoon yet!
  3. Ummm...[ Go to top ]

    Shouldn't it be

    "Getting Use to EJB"?

    Or, even better

    "Getting Used by EJB"
  4. Ummm...[ Go to top ]

    Reminds me of the quote - "only two industries refere to their customers as 'users' - the drug and the software industry."
  5. Stockholm/CMP[ Go to top ]

    I think the sentiment was summed up best in an earlier comment that many EJB users suffer from the Stockholm syndrome, where after awhile we begin to identify with, and apologize for, our abusers.

    I recently migrated a decent-sized app from an EJB-based architecture to Spring-Hibernate, and it was a joy. I was repeatedly chuckling at myself, saying, "I can't believe I used to live with this!"

    However...

    Spring (and presumably other frameworks) is far from perfect, and I repeatedly see its advocates defending its shortcomings every bit as vehemently as those who suffer from Stockholm/CMP.

    For example, Spring rapidly loses its usefulness as soon as you hit a layer of the architecture where you are not hydrating your objects. If your domain objects are instantiated by Hibernate, you lose the ability to do dependency injection from that point forward in your architecture. One Spring architect responded to this problem by saying we should move all our domain code that requires dependencies to a different Spring-managed class, say from Person to PersonManager. What? Screw up my domain model just to work around a framework limitation? I thought that's what CMP was for!

    Of course, Spring does not support XA-compliant transactions, either. Another Spring-head who I respect a great deal blithely states that only 2% of applications need such functionality. Huh? Am I the only person who has ever updated a database and sent a related JMS message within the scope of the same transaction? Maybe 98% of developers have acquiesced that they do not deserve distributed transaction, and have learned to live without them, but most enterprise applications have requirements that are supported by distributed transactions.

    Anyway, I know that there will be solutions to these problems in the future, and that's not my point. It's just interesting to see that even the really smart Spring advocates learn to live with the occasional mallet to the head.
  6. Stockholm/CMP[ Go to top ]

    Corby
    If your domain objects are instantiated by Hibernate, you lose the ability to do dependency injection from that point forward in your architecture.
    I'm working on some code that will add this capability, for Hibernate and at least two JDO implementations, in Spring 1.2. Some users have already implemented it themselves: there's a Spring forum topic on it.
    Spring (and presumably other frameworks) is far from perfect
    We'll never manage "perfect" but we certainly do our best to improve steadily. And listen to feedback from users.

    Rgds
    Rod
  7. Stockholm/CMP[ Go to top ]

    BTW Rod:

    Your new book is nice(occasionally boring in parts though)
  8. Stockholm/CMP[ Go to top ]

    We'll never manage "perfect" but we certainly do our best to improve steadily. And listen to feedback from users.RgdsRod
    Agreed. I've been spending time on the Spring Forums, and have been very impressed with the team's focus and responsiveness.
  9. Stockholm/CMP[ Go to top ]

    Rod,

    I'm glad to read some critics about Spring.

    I'm just starting to approach your great framework, but since reading last threads I was (a bit) worried, somehow blocked, about too much consensous about it... is very uncommon to see such attitude between developers and on TSS readers, too.

    :D
  10. Stockholm/CMP[ Go to top ]

    Another Spring-head who I respect a great deal blithely states that only 2% of applications need such functionality. Huh? Am I the only person who has ever updated a database and sent a related JMS message within the scope of the same transaction? Maybe 98% of developers have acquiesced that they do not deserve distributed transaction, and have learned to live without them, but most enterprise applications have requirements that are supported by distributed transactions.
    Often it is possible to design your system to handle duplicates (i.e. duplicate messages) in which case 2PC isn't necessary.

    I'm not acting as a Spring apologist here but I think that sometimes people do not consider that option irrespective of what other technologies or frameworks they are using. It can often yield higher performance than 2PC.

    Robert
  11. Stockholm/CMP[ Go to top ]

    Of course, Spring does not support XA-compliant transactions, either.
    Ehm, let me correct this: It's true that Spring does not ship its own XA transaction manager implementation. It does not aim to implement such complex system level services in the first place, but rather leaves that to dedicated third-party products: in the server-side case, a J2EE application server. After all, it is an application framework, not an system service provider.

    Fortunately, there is a common API for XA transactions: JTA. Spring has supported JTA as transaction strategy right from the start, literally since day one of its transaction abstraction. It can delegate to any JTA provider, be it a J2EE application server with container DataSources, or a standalone transaction manager like ObjectWeb's JOTM with local XAPool DataSources.

    So just use Spring's JtaTransactionManager with the JTA provider of your choice, and you get Spring's transaction demarcation facilities backed by full XA transactions. This is a pretty common combo, actually, and a good indication for how Spring and J2EE services complement each other. In that respect, Spring *does* support XA-compliant transactions.

    Juergen
  12. Spring on WebLogic or WebSphere[ Go to top ]

    Good point. Declarative transactions, without EJB, and with pluggable strategies, is acutally one of the more common reasons to use Spring.

    Pluggable transaction strategies actually let you use the strength of the WebLogic or WebSphere servers: their JTA implementations. And you can use them with a much cleaner model, that can extend declarative services beyond just transactions, remoting, security, messaging and persistence.
  13. Hello Corby,

    <corby>
    I recently migrated a decent-sized app from an EJB-based architecture to Spring-Hibernate, and it was a joy. I was repeatedly chuckling at myself, saying, "I can't believe I used to live with this!"
    </corby>

    could you please tell us what was/were the reason(s) to migrate the EJB-based application to Spring-Hibernate?

    Thanks a lot!
    Lofi.
    OpenUSS and EJOSA.
  14. could you please tell us what was/were the reason(s) to migrate the EJB-based application to Spring-Hibernate? Thanks a lot!Lofi.OpenUSS and EJOSA.
    When I did a refactoring pass over the codebase, I was getting really annoyed by accomodations I was making to the CMP framework. Re-entrancy problems, inability to use a clean 'this' reference, awkward inheritance hierarchies.

    I was also getting bit by ease of testability. Not because it is hard to test in-container (it isn't, I use JUnitEE), but because I frequently use alternate implementations of some application services for my test cases. I was running into 'wiring' issues where it was hard to ensure that the right implementation of the services was being accessed during my integration tests.

    And it was finally clear to me that POJO/AOP is how everthing will be done in the near future, and that there will be competing implementations with pretty good portability. Spring, JBoss4, and EJB3 have all gone this route, and I no longer see the case for using a legacy component model.

    (Off on a tangent, anyone who complains about how Stateless Session Beans are evil because they lock you irrevocably into a container is being silly. It took me approximately 15 seconds per component to convert my SLSB's to POJO. It took me longer to set up the Spring configuration for the beans than to make the conversion).

    Anyway, once I got started, I found little reason to stop. I didn't have to become an expert on the Spring or Hibernate codebases, I just did what the docs told me to and it worked. I solved some code structure issues that were caused by IDEA's half-ass support for EJBs.

    And as to the checked vs. unchecked exception debate, all I can say is that Rod is doing something right. Everytime I ran into an exception, it clearly described the problem. I didn't have to search for root causes (or debug the Spring source code) to find it. More annoying, though, is the tendency for configuration problems to lead to infinite loops on startup. These are left to the developer to debug.
  15. Getting Used to EJB[ Go to top ]

    Another good quality cartoon. But it should have been more violent.
  16. EJB Hammer?[ Go to top ]

    Java time!
    Dum dum dee dum
    Dee dum
    Dee dum
    ... ya can't code this!

    (sorry, first thing that came to mind when I saw "EJB Hammer")
  17. Getting Used to EJB[ Go to top ]

    Hmm, a cartoon showing real people, not humanified tentacles... er, beans.
  18. Getting Used to EJB[ Go to top ]

    Hmm, a cartoon showing real people, not humanified tentacles... er, beans.
    /s/ent/est

    Also, as an aside, the cartoon isn't the first time that I've seen Jason hammered :)) ..

    Peace.