Tech Talk with Rod Johnson on J2EE Design, AOP, Spring Framework

Discussions

News: Tech Talk with Rod Johnson on J2EE Design, AOP, Spring Framework

  1. In this interview, Rod Johnson discusses when developers should use EJB, messaging, and distributed architectures. He looks at strategies for writing portable J2EE applications, how to decide where to store state, and the problem with entity beans and value objects. He also gives his thoughts on AOP and the industry, and provides an overview of the Spring Framework.

    Watch Rod Johnson's Interview

    Threaded Messages (185)

  2. Its a great interview.
    While I do agree with Rod that EJB is sub set of what AOP can achieve. EJB's has 99% of what every day developer needs and without the uncertainity and complexity AOP adds to a system.
    To me AOP is a techonolgy for my container vendor to provide feature defined in EJB Spec and some container specific services(like Method Tracing and other requirements yet to be discovered for a solution called AOP).
    It would be nice if Rod Johnson can expand on "done a variety of things such as automated auditing".
  3. "without the uncertainity and complexity AOP adds to a system"
    Exactly what uncertainty and complexity are you talking about?

    I recently started using AspectJ and have found it to be an extremely useful complement to traditional OO development. It really has taken a lot of complexity out of the code by better modularizing code, instead of having similar calls scattered throughout the code.
    Take for instance database-persistence: implement a TransactionManager and TransactionManager aspect, and almost all persistence related code and exception-handling is but a memory in your business logic-code, you can pretty much code as if there was no database, only in memory objects!

    In the VERY short while I have been using AOP I have find it immensely useful to get rid of a lot of complexity that traditional OO has no way of getting rid of.
  4. Hi Wille

    I'm intrigued by your use of AOP to solve persistence issues. I use JDO for persistence, and it's pretty transparent. My application objects still demarcate transactions (unless using CMT from a J2EE container), but there is very little else persistence-related in the code. JDO just takes care of stuff.

    If one is using JDO, to what extent can AOP further help to reduce the small amount of persistence management code that remains?

    Thanks, Robin.
  5. Persistence and AOP[ Go to top ]

    I am using Hibernate, which is also very transparent, but I took it one step further by making a TransactionManager-class (basically a version of Fowlers "Work of Unit" pattern, using ThreadLocal), which has two primary methods: beginTransaction and commit.
    A TransactionManagerAspect then keeps track of all changes (calls to setters) on persistent-objects and registers them in the TransactionManager for persisting if they are not registered earlier.
    once commit is called, all objects are persisted (saved or updated). This means that the only persistence-code you need (apart from loads) are the beginTransaction and commit, most of your domain objects will probably need no persistence-code at all.

    It really does clean the code up even more, and makes it easier to debug. No more excessive "catch HibernateException e" stuff in the businesslogic code and enabling you to test most of your "to be persisted domain-objects" without the persistence (in other words: database).

    Of course the step from bare-bones JDBC to JDO or Hibernate is a bigger step in making things transparent, but this takes it even further.

    I also got the idea today into making the loading transparent as well (passing an id to the constructor automatically loading the object by an aspect), but that is still in the "whim of the moment ideas to be explored. :)
  6. I am for one am just outraged. When is TSS going to get off its duff and give this technology the serious coverage and attention it deserves?

    I for one will not rest until the entire world is covered with "Spring-me, baby!" bumper stickers, and if TSS doesn't devote at least three articles a week to this, I'm just going to...

    Oh, wait; never mind...
  7. All kidding aside, the interview says...

    "Two other things that I would say is EJB is more of a portability problem than the web container. In my experience, servlet applications are very, very portable, EJB applications are much less portable. Finally, I would steer clear of any really unique features of your particular application server. For example, the JBoss 4.0 AOP features, sounds pretty cool, but at least at the moment you are going to get totally tied in to that server if you use those features. So I would tend to favor using, say, a portable AOP framework that isn?t tied to a particular server rather than using that particular capability of the server."

    The interview then goes onto talk about Spring, it's miraculous wonders, with bits like "And Spring has an AOP framework which enables it to provide a very good substitute for EJB that?s much lighter weight in many cases".

    I'm curious why the interviewer didn't call Ron out on this - and why Ron expects to be getting away with steering people away from the "really unique features" of JBoss, but to embrace the equally unique-but-also-open-source Spring.

    The remainder of the interview appears to be, as I'd paraphrase it, "Look at me, I'm important", "J2EE sucks outside of the web container", and "I don't understand messaging".

        -Mike
  8. A little biased[ Go to top ]

    His point about Spring AOP is that you could use it in another J2EE server, where as with JBoss AOP you couldn't. Is that not a valid point?

    -tim
  9. There's nothing preventing you from using JBoss' AOP in another app server. If that's his point, he should have done more investigation; the same might be said of those who paraphrase him as saying that, although in all honesty I've not watched the interview yet.
  10. JBoss AOP standalone[ Go to top ]

    Yes, there is a standalone JBoss AOP download. However, it requires control over the class loader (or at least so the documents said when I did that interview in late June). More importantly, the value proposition of JBoss AOP is the enterprise services it allows you to tap into around your POJOs. The implementations of these services are JBoss-specific, so I believe you'd end up with a far reduced value proposition from JBoss AOP if you used it with, say, WebLogic.

    Regards,
    Rod
  11. Mike,

    While not questioning your perspicacity, aren't you perhaps coming down a bit hard on Rod?

    He had several interesting things to say. One that I particularly liked, and is probably going to be controversial, is the suggestion that AOP-based systems can solve (or could evolve to solve) the kinds of problems that EJB was designed to address. While that may or may not be true, it does definitely provide food for thought.

    As to his comment on messaging, with your financial IT systems background, your reaction would be to react strongly to his statement. I think you should probably step back and think about the more regular, less demanding sort of J2EE applications that could probably do well to stay away from distribution, messaging and similar "enterprise" practices and stick to using a simple web container. And perhaps a framework like Spring.

    Personally, I liked the interview.

    Sandeep
  12. Note that I do NOT use the Spring framework currently in any live project (though I do play around with it quite a bit), so this is not a biased perspective.

    But Spring does have some cleanly packaged solutions to commonly dealt with issues. And it does promote concise code.

    I've yet to get over its use of unchecked exceptions, though. But that's just me.

    Sandeep
  13. \Sandeep Dath\
    While not questioning your perspicacity, aren't you perhaps coming down a bit hard on Rod?
    \Sandeep Dath\

    I think certain authoratative writing styles practically beg people to come down hard on them.

    \Sandeep Dath\
    He had several interesting things to say. One that I particularly liked, and is probably going to be controversial, is the suggestion that AOP-based systems can solve (or could evolve to solve) the kinds of problems that EJB was designed to address. While that may or may not be true, it does definitely provide food for thought.
    \Sandeep Dath\

    The idea of using AOP as an alternative to certain J2EE is indeed compelling. However, the interview offers nothing new or interesting on this subject beyond saying that Spring does it. I find it hard to say this, but at least the JBoss folks attempt to convey a detailed argument as to why AOP-based mechanisms might beat out J2EE. I may disagree with the detail of those arguments, and some of it may be bald assertion, but an effort is made. I don't see any such attempt here beyond bald assertion (oh, and BTW, use Spring :-)

    \Sandeep Dath\
    As to his comment on messaging, with your financial IT systems background, your reaction would be to react strongly to his statement. I think you should probably step back and think about the more regular, less demanding sort of J2EE applications that could probably do well to stay away from distribution, messaging and similar "enterprise" practices and stick to using a simple web container. And perhaps a framework like Spring.
    \Sandeep Dath\

    How someone answers questions that are on the borderline of their experience says alot about the person and how you can evaluate their other statements. For example, if someone asks me about JMX my best answer is often "Well, to be honest, I don't know much about that, so why are you asking me?". In this interview, the response tries to sound authorative when it looks to me a better answer would be "that's not my gig".

         -Mike
  14. Mike,

    Have you read Rod's book by any chance ? You'll probably find a lot of answers to your free assertions in here. Notably, you'll see that every advice is well documented, pros versus cons, and you'll see that his statements in here may sound bald due to the interview's time format.

    "I think certain authoratative writing styles practically beg people to come down hard on them."

    Now, that is a very clever comment... Write your own book first, then have most of my J2EE colleagues say that your book is the J2EE bible and then you will be in a position to write such personal comments. What's the point of getting personal here ? I mean, you usually sound like a very clever person from what I can read in your posts in general... Sounds like a bit of a waste here.

                    Yann
  15. \Yann Caroff\
    Have you read Rod's book by any chance ? You'll probably find a lot of answers to your free assertions in here. Notably, you'll see that every advice is well documented, pros versus cons, and you'll see that his statements in here may sound bald due to the interview's time format.
    \Yann Caroff\

    The book isn't bad. But the book was written a year ago (possibly slightly more). What's that got to do with an interview published now? Are you saying people should go buy his book to make sense of the interview? If so - what's the point in the interview?

    \Yann Caroff\
    "I think certain authoratative writing styles practically beg people to come down hard on them."

    Now, that is a very clever comment... Write your own book first, then have most of my J2EE colleagues say that your book is the J2EE bible and then you will be in a position to write such personal comments. What's the point of getting personal here ? I mean, you usually sound like a very clever person from what I can read in your posts in general... Sounds like a bit of a waste here.
    \Yann Caroff\

    Look at the quote of mine you quoted - it talks about writing style and the reaction people (such as myself) may have to it. That's not personal, that's saying "so and so writes on this subject in the tone of an expert, but he's wrong on several particulars (or dodges the details)".

    Like it or not, creating software these days is not an objective zone of fact and code. Personalities clash, people pontificate, pundits push favorites, critics spew bile. People read this stuff and form some conclusions based on all of this information - little of which is objective fact, but instead interactions of personalities and preferences and various agendas.

    As to "Write your own book" - I don't personally subscribe to author worship. People who write books - good or bad - are no different from other people, they're just more visible. And what someone said in a book they wrote a year ago has little to do with what they're saying today in an interview or message board. Each individual "utterance", if you will, should be evaluated individually on their own merits, not on the standings of past accomplishments.

    In this particular case, I think individuals and their agendas do come into play. Certain people looking at this interview will look at it and come to the conclusion that it's a rather transparent effort to promote Spring, trash J2EE, and trash competitors who have dissed Ron in the past like those involved in JBoss AOP - and that the interview serves no other purpose than to push those personal agendas. If you're considering someone's advice and expertise in a given area, it's often quite helpful to understand their biases and agendas - the "why" in addition to the "what". And if you're not a stone-cold expert in a given area it's very easy to get fooled, and mistake ideas generated by a hidden agenda for obejctively useful ideas.

        -Mike
  16. Agendas?[ Go to top ]


    Certain people looking at this interview will look at it and come to the conclusion that it's a rather transparent effort to promote Spring, trash J2EE, and trash competitors who have dissed Ron in the past like those involved in JBoss AOP - and that the interview serves no other purpose than to push those personal agendas.
    :
    "Certain people": maybe you should be clearer and speak for yourself rather than on behalf of others. They can speak for themselves if they want to.

    Not all of J2EE is perfect. We all know that. I don't want to "trash" J2EE, but targeted criticism of certain parts of it hardly constitutes trashing.

    I don't recall being "dissed" by JBoss AOP folk. I met Bill Burke in Boston in June and found him charming and good to talk to. I certainly have no grudge against them. I was merely pointing out what I believe to be a danger of potential lockin to their server. I think what they're doing with AOP is interesting and don't want to leave the impression I'm "dissing" them for some imaginary affront. I agree with their basic motivation.

    Regards,
    Rod
  17. Mike,

    I have to say that that's one of your best posts yet.

    My problem with the Spring framework (besides idealogical differences wrt issues like exception handling) is its being positioned by some as a viable alternative to EJB period. That, from what I've seen of Spring, is definitely not a given.

    It's one thing to use Spring in a small-to-medium sized web application. Or an application that could do without a lot of the unnecessary, over-the-top plumbing that ends up insidiously worming its way into most J2EE applications.

    While the Spring team has never positioned Spring as an absolute alternative to formal J2EE constructs, I have seen many tout Spring as a full-fledged choice of infrastructure in the enterprise context, or should I say in the "so called enterprise context".

    IMHO, I think that Spring, or an equivalent framework, will definitely help new J2EE developers start out on a firm footing, or help experienced users cut through repetitive configuration and coding tasks in simpler applications.

    But for large, demanding applications I don't see how leaving EJBs (minus EBs) and messaging out of the picture will let you solve the problems that are typically faced in those environments.

    So basically what I am trying to say, and I am not sure that the Spring team is saying anything different, is that Spring is NOT the kind of framework that you would use in large applications (at least 1000+ users with 100+ or more simultaneous users, systems integration, multiple databases, legacy connectivity etc).

    Sandeep
  18. PS:[ Go to top ]

    Still nothing on the throughput advantages of Entities, especially in the area of intense reporting or datamining that requires massive concurrency.

    Entity Beans are wonderful, and they were born out of much research into massively concurrent systems.

    If concurrency support isn't a requirement (and NEVER WILL BE), I would recommend straight JDBC from JSP's and maybe throw-in struts for good measure. Even then, why bother with Spring? Many people know JDBC. Get an engineer that can comment and write efficient code, pay him well, and you're off to the races.

    Proprietary pounds.

    Simplicity swivels.

    Best,

    John C. Dale
  19. PS:[ Go to top ]

    Still nothing on the throughput advantages of Entities,

    >especially in the area of intense reporting or
    >datamining that requires massive concurrency.

    Entities do not give you any throughput advantage over many of the O/R mapping tools.

    TopLink, for example, has a transactional cache and supports six levels of caching (Identity Maps) that can be used for each object. This allows for a much finer grain of control on how each individual object is cached than using entity beans allows. TopLink also supports optimistic concurrency architectures, cache synchronization in distributed clustered environments, has several performance related features for querying the database (e.g., in memory querying), and it has a reporting framework.

    Furthermore, TopLink will not impose restrictions on your domain model (like not being able to use inheritance) and you can run unit tests without having to do a build and run your tests inside the container.

    Having used both technologies, I can tell you that development time is significantly shorter using TopLink than entities. I'm sure people with CocoBase and entity bean experience will say the same for CocoBase.

    What exactly are the throughput advantages you think entities have that other technologies are lacking?
  20. Is Toplink Portable?[ Go to top ]

    Can I use it and deploy it into many different Application servers?

    Does it adhere to industry standards of some sort, ensuring the availability of programming resources for the modification/maintenance of enterprise code?

    Honestly, toplink is just another way to reinvent entity beans. If they are equivalent *cough* then why not go with the gen spec?

    Regards,

    John C. Dale
  21. Is Toplink Portable?[ Go to top ]

    John - I think your comments are dead on. In my opinion much of the anti-entitybean rhetoric has become stale over the past 1.5 years as containers, developer understanding and tools (such as BEA's Workshop) have continued to mature.

    > Does it adhere to industry standards of some sort,
    > ensuring the availability of programming resources
    > for the modification/maintenance of enterprise code?

    Definitely an important question to be asking in most enterprises.

    cheers,
    Markus
  22. Is Toplink Portable?[ Go to top ]

    Yes, TopLink is portable.

    In fact, it's more portable and mature than entity beans.

    The use of TopLink simply requires putting a TopLink jar file in your lib directory. In fact, when developing in the past using TopLink we'd often test on Tomcat even though we were deploying on WebLogic. No code changes were required to move back and forth.

    I'm currently working on a BEA WebLogic 7.0 application where the development team was forced to use EJB's. Will that application deploy on WebSphere or JBoss as is? No. We were forced to use WebLogic specific extensions to the EJB spec in order to meet performance requirements.
  23. Is Toplink Portable?[ Go to top ]

    Can I use it and deploy it into many different Application servers?

    >
    > Does it adhere to industry standards of some sort, ensuring the availability of programming resources for the modification/maintenance of enterprise code?
    >
    > Honestly, toplink is just another way to reinvent entity beans. If they are equivalent *cough* then why not go with the gen spec?
    >

    Your statement should really be reversed to, "entity beans is just another way to reinvent toplink", given that TopLink was around long before entity beans.

    However, the whole point is that they are _not_ equivalent. A 'transparent' O/R mapper like TopLink, Hibernate, CocoBase, JDO, etc., allows you to persist domain objects without those domain objects being modified for the specific persistence layer. That is, they can work standalone, with or without the persistence layer. That is not true of Entity beans, where your domain objects, as Entity Beans, need to implement certain interfaces, and run in an EJB container. Furthermore, the relationships allowed between entity beans are quite weak compared to the relationships allowed bewteen plain java objects persisted by a transparent O/R mapper.

    Scalability questions aside, this inability to separate your domain objects from the persistence layer in an EJB environment (and its resultant effect on turnaround time as well as the structure of your code), and the weakness of the relationship model, has tremendous implications (disadvantages) in terms of being able to write and debug code quickly, or properly reflect your problem domain.

    To re-iterate what others have said; while there are uses for Stateless Session Beans in certain circumstances, I have yet to meet an experienced developer who has extensive experience with both Entity Beans and a decent O/R mapper like TopLink, Hibernate, CocoBase, etc., and would on a general basic prefer to use Entity Beans.

    Regards,
    Colin
  24. Cocobase...[ Go to top ]

    I've used Cocobase.

    The management of metadata and the bugginess of the cocoadmin is a JOKE.

    Cocobase? Are you serious? Spend the 60k on J2EE classes for your developers. That's the gift that keeps on giving.

    Transparent persistence. Not attainable. Either you're writing your persistence code in metadata, or you're writing it in Java code. To each his own. Riches to rags, and rags to riches respectively.

    Haven't used Hibbernot. I learned my lesson with Toplink and Cocobase.

    Quit being lazy and do what engineers do...write code.
  25. Cocobase...[ Go to top ]

    Transparent persistence. Not attainable. Either you're writing your persistence code in metadata, or you're writing it in Java code. To each his own. Riches to rags, and rags to riches respectively.

    >
    > Haven't used Hibbernot. I learned my lesson with Toplink and Cocobase.
    >
    > Quit being lazy and do what engineers do...write code.

    With every successive post, you come off as more of a jackass. And being lazy *is* what developers do. We use tools so we don't *have to* write code.
  26. Is Toplink Portable?[ Go to top ]

    Let's take your points one by one:

    > Can I use it and deploy it into many different Application servers?
    >

    Yes, with any of the O/R tools mentioned you can deploy to any application server, even servlet containers that cost a lot less.

    > Does it adhere to industry standards of some sort, ensuring the availability of programming resources for the modification/maintenance of enterprise code?

    Blah. Who cares? I thought you were interested in building applications quickly? It's probably a lot easier to find people with Hibernate experience than people who've used Entity beans and would choose to do so again.

    >
    > Honestly, toplink is just another way to reinvent entity beans. If they are equivalent *cough* then why not go with the gen spec?

    They are NOT equivalent. TopLink was around YEARS before Entity beans, so who's reinventing what? Hinernate, TopLink, Cocobase, etc. are all MUCH more powerful O/R mappers than Entity beans, allowing inheritance and mapping to domain objects which don't have to implement some particular interface or extend a base class or have multiple interfaces.

    >
    > Regards,
    >
    > John C. Dale
  27. John Dale[ Go to top ]

    I chalange you to write a single JSP that does persistance via the PetStore 3 aproach on iBatis. (Yes you have to look at the code example and read a dblayer.pdf).

    You will then see whay J2EE is MUCH better (and you will see why we switched. I sometimes think that you assume that we did not do EJB projects. We DID!!!!!! I used to do EJB and I beleived the hype. Then I tried something else... and in shame, it is better.)

    .V



    > Can I use it and deploy it into many different Application servers?
    >
    > Does it adhere to industry standards of some sort, ensuring the availability of programming resources for the modification/maintenance of enterprise code?
    >
    > Honestly, toplink is just another way to reinvent entity beans. If they are equivalent *cough* then why not go with the gen spec?
    >
    > Regards,
    >
    > John C. Dale
  28. PS:[ Go to top ]

    See, there it is. You're not understanding the motivations behind the product. If you need the remoting support that EEJBs give you, then there's nothing to do but use them. But for a large number of applications, they're overkill and throttle throughput. The alternative is NOT to use straight JDBC, which is a pain in the ass to maintain (although I recall you saying earlier that BMP was easy to maintain, which make me think we have different ideas about what "easy" means). Spring and other frameworks (like Hibernate, iBatis, JDO, etc., etc., etc.) make working with data much much easier. The idea behind using any framework is to reduce complexity and redundancy. NOT to "replace EJBs". The biggest problem Johnson and other EJB critics have with EJBs is that they have been a square peg for the round holes that make up most Java enterprise apps.
  29. Why bother with Spring?[ Go to top ]

    If concurrency support isn't a requirement (and NEVER WILL BE), I would

    > recommend straight JDBC from JSP's and maybe throw-in struts for good
    > measure. Even then, why bother with Spring? Many people know JDBC. Get an
    > engineer that can comment and write efficient code, pay him well, and you're
    > off to the races.

    You are missing the point regarding the relative merits of using JDBC or a JDBC framework. Straight JDBC code is excessively verbose and tends to be database specific (exception blocks check database specific SQL error codes).

    A framework can simplify your code and provide database independence. Why write a big application with 10,000 lines of JDBC code when you can write the same application with 2000 lines of concise code using a framework?

    Spring is a powerful and good JDBC framework. You might also consider a simpler open source JDBC framework like SQLExecutor. There is an article about SQLExecutor here on TheServerSide.com that explains the advantages of using a JDBC framework:

     http://www.theserverside.com/resources/article.jsp?l=SQLExecutor

    Using a JDBC framework can result in more concise and maintainable code than writing your own low level JDBC code.

    Just my $0.02

    Cheers,
    Jeff
  30. There are no absolutes, Jeff...[ Go to top ]

    A framework adds complexity to the application in terms of configuration and learning curve. Furthermore, a bug in the framework could cost you a lot of time.

    There are little tips, tricks, and patterns that can be used to reduce the # of lines of code.

    Any code that is properly documented, that has good exception handling (something that may/may not be included a third-party framework), and solid algorithms will have lots of lines of code.

    Are you including the mapping metadata in your calculation? Are you saying that EVERY application that uses a framework will have less code, and that that code will be easier to maintain?

    Again, no absolutes.

    You have to get the damn data into/outta the data store, and you have to write code to do that.

    Best,

    John C. Dale
  31. There are no absolutes, Jeff...[ Go to top ]

    A framework adds complexity to the application in terms of configuration and

    > learning curve. Furthermore, a bug in the framework could cost you a lot of
    > time.

    Well, I wouldn't recommend using a buggy framework... :-)

    > Any code that is properly documented, that has good exception handling
    > (something that may/may not be included a third-party framework), and solid
    > algorithms will have lots of lines of code.

    But my point is, all things being equal, that I would rather deal with 2000 concise and properly documented lines of code than deal with 10,000. I think that is the goal of most programmers--to solve a problem concisely.

    > Are you including the mapping metadata in your calculation?

    SQLExecutor doesn't do O/R mapping; it is a simple front end to JDBC. Period.

    > Are you saying that EVERY application that uses a framework will have less
    > code, and that that code will be easier to maintain?

    No. I'm saying that most applications that employ appropriate and well designed
    frameworks will have less code and be easier to maintain.

    >"Can Entity Beans work? Yes, but so can COBOL code. And to be honest, I think
    >COBOL code might be prettier. :-)"
    >Unsubstantiated rhetoric...your COBOL code might look better than your EJB
    >code. Don't lump me into that group, however.

    People on TheServerSide used to have a better sense of humor!

    Cheers,
    Jeff
  32. There are no absolutes, Jeff...[ Go to top ]

    Because of the dynamic nature of the application development cycles of the application servers upon which they (the nth miracle framework this year) are running, I think the very nature of third party 'frameworks' can't help but be buggy.

    The entire story is spelled-out in the spec. It is proven.

    I'll stick with what I know works.

    "Well, I wouldn't recommend using a buggy framework... :-)"

    That is rather flippant and uninformative :)

    "People on TheServerSide used to have a better sense of humor!"

    Fair enough.

    Why did the developer cross the road?
    Because someone promised him the framework on the other side would save 15 million dollars this year...bummer about that truck tho.

    Cheers.

    John C. Dale
  33. There are no absolutes, Jeff...[ Go to top ]

    John C. Dale is the awesomest troll of all time... period!

    Sufficently more entertaining than Rolf Tollerud ever was.

    Keep up the good work John and enjoy those EJB's.
  34. There are no absolutes, Jeff...[ Go to top ]

    Thanks man. Hugs and kisses to you, too, bud.

    BTW, 'wonder geek'? Makes me wonder...

    That is worth a laugh. It's difficult to take someone seriously who 1) doesn't have the sense to use a realistic aka and 2) fears publishing his own name and attaching it to his comments.

    Cheers.

    John C. Dale
  35. There are no absolutes, Jeff...[ Go to top ]

    Thanks man. Hugs and kisses to you, too, bud.

    >
    > BTW, 'wonder geek'? Makes me wonder...

    It might be in your interest to "wonder" more about EJB's...

    >
    > That is worth a laugh. It's difficult to take someone seriously who 1) doesn't have the sense to use a realistic aka and 2) fears publishing his own name and attaching it to his comments.

    Ahhh, what is the old adage? "Fight fire with fire..."

    >
    > Cheers.
    >
    > John C. Dale
  36. There are no absolutes, Jeff...[ Go to top ]

    John C. Dale is the awesomest troll of all time... period!

    >
    > Sufficently more entertaining than Rolf Tollerud ever was.
    >
    > Keep up the good work John and enjoy those EJB's.

    BTW, where's Rolf? I miss him.
  37. There are no absolutes, Jeff...[ Go to top ]

    A framework adds complexity to the application in terms of configuration and learning curve. Furthermore, a bug in the framework could cost you a lot of time.

    >

    Replace "framework" with "container" and you'll see where the rest of us are coming from... except your container costs $$$ and lots of time and an opensource container only costs the time.

    I've found way more bugs in commercial containers than I have in released versions of Hibernate, for instance. And porting between app servers? If you're making the Entity beans usable you're using server vendor additions, so now you have to figure out how to do it (if it's possible) on container #2...
  38. There are no absolutes, Jeff...[ Go to top ]

    First of all, there have been some suggestions to use a 'framework' inside an Entity EJB. I would assume that you don't advocate that, and I wouldn't suggest that anyone go that route.

    'where I think the rest of you are coming from' is a position of ignorance about when and how to apply Entity Beans!

    There are a complex solution to a very complex problem. If one doesn't understand either one (the problem or the solution), then there is no hope for understanding why Entity Beans are a very, very good thing. I'm not trying to be insulting (this time ;).

    We all have different levels of expertise, as well as different expectations about where our respective careers are headed. I can respect that, and I can also respect the choice not to use entity beans. That said, I'm not going to sit around and read about people bashing a technology which I know is quite viable without responding.

    Best,

    John C. Dale
  39. There are no absolutes, Jeff...[ Go to top ]

    First of all, there have been some suggestions to use a 'framework' inside an Entity EJB. I would assume that you don't advocate that, and I wouldn't suggest that anyone go that route.

    >

    You seem to be advocating a BMP approach using custom SQL. How have you addressed the N+1 fetch problem which plagues this pattern?

    > 'where I think the rest of you are coming from' is a position of ignorance about when and how to apply Entity Beans!

    I've applied Entity beans and been unimpressed either in terms of performance (fetching one instance and its relationships is ok, not great... fetching using a finder is horrible), or in terms of productivity. Hibernate is awesome in that it both makes you very productive (it's SOOO easy to use, especially for the common easy stuff) and it's performance is very good (sometimes you have to learn more about Hibernate to know how to tell Hibernate to do the right thing, but it's not magic, after all). Have you tried Hibernate? You seem unimpressed with TopLink or Cocobase, and I haven't used those, so I can't speak to those, ut Hibernate is quite good.

    >
    > There are a complex solution to a very complex problem. If one doesn't understand either one (the problem or the solution), then there is no hope for understanding why Entity Beans are a very, very good thing. I'm not trying to be insulting (this time ;).

    Yes, you managed to be reasonable, if condescending and uninformed.

    >
    > We all have different levels of expertise, as well as different expectations about where our respective careers are headed. I can respect that, and I can also respect the choice not to use entity beans. That said, I'm not going to sit around and read about people bashing a technology which I know is quite viable without responding.
    >
    > Best,
    >
    > John C. Dale
  40. n+1[ Go to top ]

    There are several ways of doing this.

    The best way is to limit the query results. A user that issues a query that returns 5k results (for instance) probably didn't intent for that kind of response. How often, when searching google, do you end up viewing the 5k'th result?

    Another way to do this is via a utility method on the Session Bean. Have a fast-lane reader return name/value pairs (the name to be used as a display/link) and have the value be the id/key for the hydration of the entity at a later time.

    Lazy loading can also be a good way to avoid this problem. Don't load an entity until some business method is invoked on it. Just a thought, but display information about the entity could be stored in the PK on find (this would prevent the load if using lazy load if you just want to display a name with a link, z.b.).

    Lastly, a list of dependent object id/values can be the attribute of another (possibly transient) bean. This would be nice in the event that the list (or intersecting members of the list) are viewed by more than one user, or by the same user more than one time, as the container should cache the bean instance. Throughput on subsequent reads should be great (this would/could work for record traversal between requests as well).

    Great question. What ways have you used to solve this problem?

    Cheers.

    John C. Dale
  41. get readin'[ Go to top ]

    For the guy who was just advising others to "get readin'", you /really/ have some reading to do.

    >> Lazy loading can also be a good way to avoid this problem. <<

    Lazy loading CAN NOT be used to avoid the n+1 problem. It is, in fact, the CAUSE of the n+1 problem. The n+1 problem may be avoided by using the diametric opposite of lazy loading, namely /eager outerjoin fetching/. Modern ORM solutions all implement this. Most CMP engines do not (though I understand that WebLogic does) and it is impossible to implement in BMP.

    >> The best way is to limit the query results. <<

    How does this avoid n+1?? Its merely places an upper bound upon n.

    (Oh, and notice that there is no portable way to do this in EJB.)

    >> Have a fast-lane reader return name/value pairs (the name to be used as a display/link) and have the value be the id/key for the hydration of the entity at a later time. <<

    which is just another implementation of the n+1 selects problem LOL!

    >> the container should cache the bean instance <<

    Unless, of course, this is not a read-mostly bean. Or unless another esternal application writes to the table. Or unless the table is huge. Or unless you are using WebSphere. Or unless.....

    You should not /rely/ upon caching for performance. It is "sugar" when and where possible. Any modern ORM solution performs well -without- the need for caching.

    >> Great question. What ways have you used to solve this problem? <<

    http://www.hibernate.org
  42. get readin'[ Go to top ]

    <Gavin>
    It is impossible to implement in BMP.
    </Gavin>

    Unless, of course, you use the FatKey pattern. But that is really such a workaround.

    Sandeep
  43. n+1[ Go to top ]

    Sigh. This thread is really going nowhere.

    > The best way is to limit the query results. A user that issues a query that returns 5k results (for instance) probably didn't intent for that kind of response. How often, when searching google, do you end up viewing the 5k'th result?

    What? This is to address the "n+1" problem? :-O

    Using this strategy with BMP, you would end up calling a finder method and M ejbLoads, where M is your "limit'. Possibly less than N, possible alleviating the problem, but definitely not solving it. It's not a problem only if you don't need anything more than the PKs, but in all other cases, what do you do?

    > Another way to do this is via a utility method on the Session Bean. Have a fast-lane reader return name/value pairs (the name to be used as a display/link) and have the value be the id/key for the hydration of the entity at a later time.

    Riiight. And I thought you were looking at an OO solution to the problem. Why is this elegant?
     
    > Lazy loading can also be a good way to avoid this problem. Don't load an entity until some business method is invoked on it. Just a thought, but display information about the entity could be stored in the PK on find (this would prevent the load if using lazy load if you just want to display a name with a link, z.b.).

    (Unless you and I are talking about different things) Lazy loading CANNOT solve this problem. If you are talking about the N+1 problem, there are really only two clean ways to prevent that with EJB - use an optimized CMP-based solution, where the container can use one large SELECT instead of N+1 selects, or to use caching, where you hit the database once, and the cache (if you are lucky) the remaining N times.
     
    > Lastly, a list of dependent object id/values can be the attribute of another (possibly transient) bean. This would be nice in the event that the list (or intersecting members of the list) are viewed by more than one user, or by the same user more than one time, as the container should cache the bean instance. Throughput on subsequent reads should be great (this would/could work for record traversal between requests as well).

    Again, why would you adopt this roundabout way of doing things, when things would be so much simpler and more OO with a good ORM tool?

    Sandeep
  44. n+1[ Go to top ]

    I intended with my response to lay out a series of strategies that address the n+1 problem - some standing alone, some in conjunction with others.

    "Using this strategy with BMP, you would end up calling a finder method and M ejbLoads, where M is your "limit'. Possibly less than N, possible alleviating the problem, but definitely not solving it. It's not a problem only if you don't need anything more than the PKs, but in all other cases, what do you do?"

    This isn't cogent. Please make this counter argument again so I can see what point you're trying to make. You really just describe the problem, and concur that limiting the results that are returned will reduce the impact of the n+1 issue. This could be one of several design approaches that helps reduce the impact of the problem overall...sum of the parts, my friend.

    "Riiight. And I thought you were looking at an OO solution to the problem. Why is this elegant?"

    I just see a conclusion, but no support for it. What about this approach isn't OO? No code above the Session bean would know the difference. The code below the Session Bean is simple and straight forward. Since the nature of the data is transient and doesn't require state management, using an Entity Bean here would actually be a violation of the cohesion principle. What about using a ListReaderEJB facade to encapsulate this critical functionality and avoid the n+1 problem? That seems OO to me, but then, there are no absolutes.

    "Lazy loading CANNOT solve this problem"

    Lazy loading as I describe it can contribute to minimizing the impact of the problem. Again, the sum of the parts.

    "Again, why would you adopt this roundabout way of doing things, when things would be so much simpler and more OO with a good ORM tool?"

    If I can easily solve the problem with EJB (as I have), so there is no need to bring in a third party potentiall buggy, expensive O/R tool (my experience, the best teacher afterall, is sending me a huge red flag in this regard).

    My personal favorite solution is the fast lane reader encapsulated in a stateless facade that returns list objects (HashMap or some very simple extension to a HashMap).

    So, if I understand correctly, your solution to the issue requires that you dump a well defined specification for a potentially unprove, potentially expensive, potentially buggy, potentially risky third party O/R mapping solution. If I'm right, that speaks volumes.

    Lastly, of the workflows that I typically address, a very small portion of them introduce this problem. I've institutionalized some design practices that minimize to a negligible degree the n+1 problem. I'm still standards compliant, my apps are still simple to maintain, and they are BLAZING fast and ULTRA scalable. If it ain't broke part-nerd, don't fix it.

    Cheers,

    John C. Dale
  45. n+1[ Go to top ]

    I intended with my response to lay out a series of strategies that address the n+1 problem - some standing alone, some in conjunction with others.


    Fine. If you are merely trying to alleviate problems associated with the n+1. As Gavin has pointed out as well, you cannot really solve this problem this way.

    > This isn't cogent. Please make this counter argument again so I can see what point you're trying to make. You really just describe the problem, and concur that limiting the results that are returned will reduce the impact of the n+1 issue. This could be one of several design approaches that helps reduce the impact of the problem overall...sum of the parts, my friend.

    /*
     * @see firstComment
     */

    >>> I just see a conclusion, but no support for it. What about this approach isn't OO? No code above the Session bean would know the difference. The code below the Session Bean is simple and straight forward. Since the nature of the data is transient and doesn't require state management, using an Entity Bean here would actually be a violation of the cohesion principle. What about using a ListReaderEJB facade to encapsulate this critical functionality and avoid the n+1 problem? That seems OO to me, but then, there are no absolutes.

    For me, and I speak for me personally, a domain model is one that accurately reflects the properties of and relationships between business entities that exist in that domain. For me, (any) domain-specific business logic code is code that deals with such a domain model in its most pristine form, i.e., without being overly aware of how that domain model is persisted, or of any semantics associated with the chosen persistence mechanism.

    Sounds abstract? Sounds far-fetched? With Hibernate, I design my database true to 3NF, design my domain model independently of the data model, and finally map the two together. My business logic code is completely unaware that I use Hibernate. Neither is it constrained by any specific semantics that Hibernate imposes on my data access code. In fact, most of my data access code is unaware of any complex Hibernate semantics whatsoever!

    Finally, and most importantly in this discussion, I don't need any optimizations with patterns (hmmph. workarounds) that have been contrived to deal with a badly conceived spec.

    > Lazy loading as I describe it can contribute to minimizing the impact of the problem. Again, the sum of the parts.

    /*
     * @see firstComment
     */
     
    > If I can easily solve the problem with EJB (as I have), so there is no need to bring in a third party potentiall buggy, expensive O/R tool (my experience, the best teacher afterall, is sending me a huge red flag in this regard).

    This is pure FUD. I don't see why a container implementation from one vendor should be in any way more reliable and more efficient than an ORM tool from another. And don't give me the "Gen spec" routine again. There are such things as "mistakes", and the JCP and the Java community at large are getting around to acknowlegding it as far as EBs are concerned.

    Potentially buggy - how many ORM tools have you used? Hell, I don't even know if you even use CMP, John?

    Expensive - Hibernate is not expensive. After you pay the initial upfront license fees of $DownloadAZipFile, I find the ongoing maintenance fees of $KeepTrackOfChangesOnTheWiki quite bearable.

    >>> My personal favorite solution is the fast lane reader encapsulated in a stateless facade that returns list objects (HashMap or some very simple extension to a HashMap).

    My personal favorite solution is to use my domain model as is.
     
    > So, if I understand correctly, your solution to the issue requires that you dump a well defined specification for a potentially unprove, potentially expensive, potentially buggy, potentially risky third party O/R mapping solution. If I'm right, that speaks volumes.

    More FUD. Define "well defined". The fonts are good? Nice formatting? PDF file not too large?

    Golly, what about the entity bean spec (besides maybe the parts about CMP/CMT), is in any way truly reflective of Sun's initial intent to support persistence for an OO domain model without losing the OO part in the bargain?

    In case, you'vent been "readin'" enough lately, there are ORM tools like TopLink that are marketed by vendors who also market containers.

    Do you use Struts or Webwork?. This may be bad news, John, but they might be unproven.
     
    >> Lastly, of the workflows that I typically address, a very small portion of them introduce this problem. I've institutionalized some design practices that minimize to a negligible degree the n+1 problem. I'm still standards compliant, my apps are still simple to maintain, and they are BLAZING fast and ULTRA scalable. If it ain't broke part-nerd, don't fix it.

    So are mine, and I achieve inheritance, polymorphism and database independence in my domain model using clean "idiomatic Java" code on the way as well.

    Sandeep.
  46. n+1[ Go to top ]

    Care to share any of your performance numbers? How about a profile of Hibbernot in action...

    I've used Toplink, Cocobase, Versant, and Castor. I came away from those communities of developers with the impression that the goal was to not have to understand the underlying data model. If one is practical one realizes that the data model should in fact be the focus of the application. It should be vetted against all known workflows that will be constructed around it.

    Smearing your business logic throughout the domain of a multi-layered enterprise system isn't all its cracked-up to be. OODMBS might be good once the serious performance issues surrounding them are resolved. As long as we continue to use RDBMS, it makes good sense to write manual O/R mapping code. There are no silver bullets. The more we as developers keep making unfilled promises to managers about silver bullets, the more we hurt our industry as a whole.

    I, for one, enjoy writing cohesive maintainable code for applications that perform well under load. If one doesn't enjoy writing code, then maybe one should consider another occupation.

    "My personal favorite solution is to use my domain model as is."

    /**
     * see comment about etherial approaches and the domain model in enterprise
     * applications as being unrealistic and impractical
     */

    "So are mine, and I achieve inheritance, polymorphism and database independence in my domain model using clean "idiomatic Java" code on the way as well."

    Prove it. You are really quite good with the party line, but I have been hearing (and in some cases speaking myself about) perfect prestine OO. Most of the time, it just isn't practical. There are no perfect solutions, there are only better and worse ones. As you claim to have achieved perfection, I can hardly contain the laughter.

    That said, you sound like a capable engineer. THAT said, I think you are missing the forrest for the trees.

    Best,

    John C. Dale

    PS: I can't wait to see your performance numbers...
  47. RE: n+1[ Go to top ]

    Care to share any of your performance numbers? How about a profile of Hibbernot in action...

    >

    How about your performance numbers?

    What sized systems are you building?

    How many entities in your domain model?

    How many records in your tables?

    How many concurrent users?

    What's your response time?

    I get the feeling from your other posts that you aren't building very large scale systems (which makes EJB even less appropriate, maybe you should check out Rod's interview?)...
  48. RE: n+1[ Go to top ]

    http://www.pearsonconcert.com

    Performance of the system is solid.

    I can't share any specific numbers for reasons of confidentiality, but I will say that the concurrent usage is expected to be in the millions.

    ...and you?

    Best,

    John C. Dale
  49. More infor for sandeep...[ Go to top ]

    http://www.onlineeducationcommunity.com/features.cfm
  50. RE: n+1[ Go to top ]


    >
    > Performance of the system is solid.

    > John C. Dale

    Ok, so I clicked the link:



    Error 500--Internal Server Error
    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
    10.5.1 500 Internal Server Error

    The server encountered an unexpected condition which prevented it from fulfilling the request.
  51. ...
  52. Uh huh...[ Go to top ]

    I can't share any specific numbers for reasons of confidentiality, but I will say that the concurrent usage is expected to be in the millions.


    Now *that* is funny. Who said TSS lost its sense of humor?

    Ryan
  53. in support of my supposition.

    Aren't you the author of that really cool game, "Jump to Conclusions"?

    Best,

    John C. Dale
  54. The application was written...[ Go to top ]

    to accommodate all teachers, administrators, students, and parents involved in the k-12 space.

    You do the math...

    Best,

    John C. Dale
  55. The application was written...[ Go to top ]

    to accommodate all teachers, administrators, students, and parents involved in the k-12 space.

    >
    > You do the math...
    >
    > Best,
    >
    > John C. Dale

    I can do the math. That population *is* in the millions. But I am guessing most of these parents, admins, students and teachers are doing *many* other things during the day besides using this application (like going to work, teaching class, etc). I am not saying this app does not scale or perform well. I'm sure it is BLAZING (or BLAZINGLY) fast ULTRA scalable. But to say that there are millions of concurrent users, well, that is just amusing. Hence, my chuckling.

    If we are going to use *real* number, let's at least keep them real (dawg).

    Ryan
  56. Concurrency...[ Go to top ]

    The useage pattern during peak hours could easily be in the millions for the most intense use case in the system.

    With students accessing assignment and standards information, front office administrators accessing student data constantly, parents logging in during the day to check up on their kids(how cool would it be to be able to look in and make sure little sally was in class like she was supposed to be, or to check how well she is doing in algebra so far), and teachers entering attendance and gradebook information all at the same time.

    We did the math, and peak useage of the system had the potential to reach 1m plus, home skillet.

    Ever had those kind of performanc requirements?

    Did you know Pearson is a multi-billion dollar company?

    Best,

    John C. Dale
  57. eLearning[ Go to top ]

    <quote>
    http://www.pearsonconcert.com
    <quote>

    Hi John, it seems that we are on the same domain: eLearning... ;-) OK, I don't have as many users as in your platform but OpenUSS is getting more users everyday (about 13,000 users now). I would like to know whether you use database (BLOB) + Entity Beans to save all the documents of the teachers and students? What kind of database and J2EE containers do you use for your platform?

    Thanks,
    Lofi.
    OpenUSS
    http://www.openuss.org
  58. OpenUSS additional[ Go to top ]

    to add, OpenUSS uses EJOSA (Enterprise Java Open Source Architecture = Enhydra and JOnAS) = Servlet, XMLC, SLSB, EB, MDB, Firebird. All Open Source products. Also in the development it only uses Open Source products: NetBeans, XDoclet, Ant.

    OpenUSS and EJOSA itself are also Open Source ;-) For more information:

    http://ejosa.sourceforge.net
    http://openuss.sourceforge.net

    Cheers,
    Lofi.
  59. PS:[ Go to top ]

    Imagine for a moment thousands of teachers committing ~20 attendance records apiece at the same time every hour each day while the system is already under normal load.

    It was a very stressful experience with those kinds of performance requirements. I learned a great deal and experimented with several approaches including Cocobase, PCA (Gemstone), Versant and BMP. BMP was by far the best for our performanc requirements. Now, as a result, I can quickly write solid BMP code that I know will scale.

    At any rate, best of luck.

    John C. Dale
  60. How timely is this HOMERS!!![ Go to top ]

    http://www.theserverside.com/resources/article.jsp?l=DB_Break

    Best,

    JCD
  61. RE: n+1[ Go to top ]


    > Great question. What ways have you used to solve this problem?
    >

    Well, others have answered you already, but I'll say that we didn't put ourselves in this position because we knew of the N+1 problem with BMP... When we tried out Entity beans, we went for CMP, and Weblogic has some nice optimizations... but they're not standard, and they're STILL NOT AS GOOD AS A REAL ORM and still have all of the OO disadvantages of Entity beans.
  62. RE: n+1[ Go to top ]

    Jason:
    Well, others have answered you already, but I'll say that we didn't put ourselves in this position because we knew of the N+1 problem with BMP... When we tried out Entity beans, we went for CMP, and Weblogic has some nice optimizations... but they're not standard, and they're STILL NOT AS GOOD AS A REAL ORM and still have all of the OO disadvantages of Entity beans.

    Can you be more specific, Jason?

    (it's not every day that I get to use the OSS technique of addressing critiques by asking their author to either report the bug or fix it themselves :-))

    --
    Cedric
  63. RE: n+1[ Go to top ]

    Can you be more specific, Jason?

    >
    > (it's not every day that I get to use the OSS technique of addressing critiques by asking their author to either report the bug or fix it themselves :-))
    >
    > --
    > Cedric

    * Well, there's inheritance, for one (or the lack thereof).

    *There's the fact that you have to implement all of the interfaces, build the deployment descriptor, etc. for a heavyweight component

    *You can't test them outside of a container.

    * It's been a while, but I seem to remember relationships not being as expressive as Hibernate's (in terms of types of relationships and loading policies)

    * You can't use them as real domain objects throughout your app, you need to create Value Objects to pass out to the web layer (with Hibernate you can just disconnect them (or not))

    * finders and EJB-QL are weak compared to SQL or HQL

    Overall, these are problems with the spec. WLS has the best implementation I saw, but we have to support WebSphere too, and that's just a nightmare. I didn't really see a way to be spec compliant (not using WLS specific extensions) and make them work.
  64. Scalability[ Go to top ]

    While the Spring team has never positioned Spring as an absolute alternative to formal J2EE constructs [presumably you mean EJB? there's no conflict with JTA etc.], I have seen many tout Spring as a full-fledged choice of infrastructure in the enterprise context.
    We have never said that Spring is an alternative to EJB period; I didn't in the interview. We're not responsible for what others say. For example, Spring doesn't aim to replace remote EJBs if you need a distributed app. EJB is an excellent technology for writing distributed apps. Spring aims to replace certain EJB services. However, we argue that this covers a very large proportion of applications. And lots of people agree that EJB is inappropriate for such apps. Where web apps are concerned, I think the non-distributed architecture is often a lot more performant and equally scalable. I would have no reservations in putting Spring into production in very high-throughput web apps. (Subject to adequate performance testing to prove the architecture--an essential whatever approach you use.)

    As to whether Spring would be a good choice for the integration-style applications you describe, we don't push its declarative service model as a solution for such apps. Time will tell. However, if you wanted a distributed architecture you could use Spring to simplify your use of remote EJBs. Some Spring users use EJBs, and seem to find that Spring helps them implement an EJB architecture more easily. A Spring BeanFactory behind an EJB provides a good way of managing POJO helpers, while leaving EJB to do transaction management, threading etc. I don't believe there's any fundamental reason that Spring won't scale to such applications (EJB applications often fail as well, btw). So I'm not saying it won't, just that we don't guarantee it will right now. Btw Spring can work with JTA, so it doesn't cut against J2EE. EJB != J2EE, and Spring does not preclude use of EJB. (There are two EJB-related packages, one to support implementing EJBs, and one to simplify accessing them.)

    I should say that the basic concept of the Spring lightweight container was developed while I worked for a very high profile .com with well over 1M page impressions per day at that time. The framework (including a precursor of the Spring MVC framework) performed just fine, and is still in production 3 years later. The parts of the site that performed best and were most reliable were the lighter-weight parts (no entity beans, no distribution).

    In my experience I haven't found distributed EJB architectures to be supremely scalable in most cases.

    Regards,
    Rod
  65. Scalability[ Go to top ]

    While the Spring team has never positioned Spring as an absolute alternative to formal J2EE constructs [presumably you mean EJB? there's no conflict with JTA etc.], I have seen many tout Spring as a full-fledged choice of infrastructure in the enterprise context.

    > We have never said that Spring is an alternative to EJB period; I didn't in the interview. We're not responsible for what others say.

    Rod, No disagreement. That's why my post clearly stated that I am not accusing the project of any "official mispositioning" whatsover. However, that's not to say that this hasn't been said, and said in no uncertain terms.

    >>>For example, Spring doesn't aim to replace remote EJBs if you need a distributed app. EJB is an excellent technology for writing distributed apps. Spring aims to replace certain EJB services. However, we argue that this covers a very large proportion of applications. And lots of people agree that EJB is inappropriate for such apps. Where web apps are concerned, I think the non-distributed architecture is often a lot more performant and equally scalable.

    No disagreement here either.

    >>I would have no reservations in putting Spring into production in very high-throughput web apps. (Subject to adequate performance testing to prove the architecture--an essential whatever approach you use.)

    My bad. When I said at least 1000+ users, 100+ simultaneous users etc., I never really meant to talk about throughput. I was merely trying to delineate what might constitute an enterprise app from wannabees, for want of formal qualitative and quantitative attributes for classification. Note that I equally emphasize the other issues of legacy connectivity, integration with (ERP, corporate MIS) systems, as well as issues like clustering and failover.

    I also never said that Spring could not scale. Hell, take a look at TPC-C scalability. There's raw procedural C and C++ code that often goes in there. Strictly speaking, scalability is not precluded by choice of a specific technology. Scalability is, however precluded, by restrictions on possible deployment architectures and topologies when using those technologies. And that's why I think J2EE's flexibility makes it very powerful. (Also dangerous.)

    >>> As to whether Spring would be a good choice for the integration-style applications you describe, we don't push its declarative service model as a solution for such apps. Time will tell. However, if you wanted a distributed architecture you could use Spring to simplify your use of remote EJBs. Some Spring users use EJBs, and seem to find that Spring helps them implement an EJB architecture more easily. A Spring BeanFactory behind an EJB provides a good way of managing POJO helpers, while leaving EJB to do transaction management, threading etc. I don't believe there's any fundamental reason that Spring won't scale to such applications

    If I am going to invest in EJB on an application, I am going to invest in EJB.
    I might use Spring to facilitate my use of EJB but that's about it. Mixing and matching parallel architectural elements is not something that, IMHO, is advisable.

    >>>(EJB applications often fail as well, btw).

    Disagree. Well designed EJB applications can be made virtually unbreakable. (Ellison is only a distant cousin, but hey, blood is thick, you know.)

    >>>So I'm not saying it won't, just that we don't guarantee it will right now. Btw Spring can work with JTA, so it doesn't cut against J2EE. EJB != J2EE, and Spring does not preclude use of EJB.

    Yes. Spring does work very well with JTA from my tests.

    > I should say that the basic concept of the Spring lightweight container was developed while I worked for a very high profile .com with well over 1M page impressions per day at that time. The framework (including a precursor of the Spring MVC framework) performed just fine, and is still in production 3 years later. The parts of the site that performed best and were most reliable were the lighter-weight parts (no entity beans, no distribution).

    Again, I do not think that straight linear scalability is the only characteristic of a good enterprise system. Often an enterprise system is one that is "stitched together". J2EE offers a great sewing kit.

    > In my experience I haven't found distributed EJB architectures to be supremely scalable in most cases.

    I have seen this to be the case with the use of excessive remoting. But with 2.0, my experience speaks otherwise. With clustered, homogeneous configurations of SLSBs using local interfaces, you can make a J2EE system scale really, really well.

    Sandeep

    PS: Despite your arguments to the contrary Rod, I still think Spring is a good framework! Written by a smart bunch a fellas. ;-) Tee Hee.
  66. Correction[ Go to top ]

    Sandeep,

    When I said "EJB applications often fail" I meant "Applications built using EJB often fail to deliver to expectations". Not that EJB apps will fail in production; just that using EJB is no guarantee of getting where you want to go with scalability etc. I now realise what I wrote was unclear...

    I completely agree that EJB apps, designed well, can be extremely robust. No disagreement there.

    Regards,
    Rod
  67. Correction[ Go to top ]

    Rod,

    My concluding remarks on this thread would be that: there is a whole class of J2EE applications (and a sizable percentage of the total) that could benefit enormously from using Spring.

    From my own and ultimately subjective perspectives, I've tried to characterize what that category is in my posts above. I may or may not be proven wrong.

    There are many upsides to using Spring (and I say this as a staunch supporter of the usable EJB subset). And developers out there will do well to at least consider using it. The very evaluation process can be enlightening.

    Btw, its the first time I've seen a software framework codify the message of a book. Fun.

    Sandeep

    > Sandeep,
    >
    > When I said "EJB applications often fail" I meant "Applications built using EJB often fail to deliver to expectations". Not that EJB apps will fail in production; just that using EJB is no guarantee of getting where you want to go with scalability etc. I now realise what I wrote was unclear...
    >
    > I completely agree that EJB apps, designed well, can be extremely robust. No disagreement there.
    >
    > Regards,
    > Rod
  68. RE: Scalability[ Go to top ]


    > Again, I do not think that straight linear scalability is the only characteristic of a good enterprise system. Often an enterprise system is one that is "stitched together". J2EE offers a great sewing kit.
    >
    > > In my experience I haven't found distributed EJB architectures to be supremely scalable in most cases.
    >
    > I have seen this to be the case with the use of excessive remoting. But with 2.0, my experience speaks otherwise. With clustered, homogeneous configurations of SLSBs using local interfaces, you can make a J2EE system scale really, really well.
    >
    > Sandeep

    Can someone please explain to me why they think EJBs make things more scalable?

    If you use remote interfaces, you can perhaps put your EJBs on another machine and scale them separately, but then you have to deal with serialization, remote method calls, value objects, etc. and I think we all realize by now that this is not the recipe for scalability.

    If you use local interfaces you're in the same JVM, the same as calling any other class, except that you have the overhead of the container and the services it applies for every call (not all of which you may want or need). AFAIK no app server keeps a separate pool of threads for executing EJBs (there is probably a thread pool for executing RMI calls, but we're local, remember?), so you're using the same threading model from the Servlet container, no win there. The container WILL maintain a pool of EJB instances, but this is only really needed because of the heavyweight nature of EJBs. Remember, I'm not talking about pooling connections here, everyone agrees that's a good idea, but SERVICE OBJECT INSTANCES. If your service is implemented by a POJO and is stateless, object creation is nearly free, and often-times attempting to pool object instances will COST you in terms of performance because of more frequent total garbage collection cycles. So where's the win over a POJO? Container managed transactions? Aha... Now what if those could be provided for you? That's what Rod is saying. It doesn't have to be Spring. It could be done in a Servlet filter with a ThreadLocal and a smart lazy loading Proxy. <plug:shameless> It could be done in an Xwork Interceptor</plug:shameless>.

    The point is that if you're using local SLSB's, which is what most people are using exclusively from EJB (excluding the Entity bean guy from above (good luck buddy)), then you're probably not getting the benefit you think you are. If you're using them because of political pressure, that's a different and entirely valid, if somewhat unsavory, reason. Using EJBs to fulfill a checklist is not the same thing as "EJBs make your app more scalable", though, and I wish people would at least think before they say silly things like this.
  69. Sure...[ Go to top ]

    Intelligent Caching. Get readin'.

    Failover. Get readin'.

    Clustering. Get readin'.

    Thread and Transaction mgt. Get readin'.

    Best,

    John C. Dale
  70. Sure...[ Go to top ]

    Other tools already provide these features...still no clear advantage to entities over other tools.
  71. Sure...[ Go to top ]

    I'm trying not to get antagonistic here, but you're making it difficult....

    > Intelligent Caching. Get readin'.

    How is caching the sole domain of entity beans? Caching is not even in the J2EE spec yet, so you must be talking about vendor specific features. Hibernate has very good support for caching, and I've just implemented the SwarmCache provider for Hibernate so you can have clustered caching transparently managed by Hibernate (non-transactional... if you need transactional caching you need Tangosol)

    >
    > Failover. Get readin'.
    >

    How is this different from servlet container failover?

    > Clustering. Get readin'.

    Again, how is this different from what I can get from a good servlet container?
    >
    > Thread and Transaction mgt. Get readin'.
    >

    Did you read what I wrote?

    > Best,
    >
    > John C. Dale

    I've done my reading... Perhaps it's time you started listening what everyone else is trying to tell you or read some of the thinking on enterprise java from the last 2 to 3 years.
  72. transactional cache[ Go to top ]

    I've just implemented the SwarmCache provider for Hibernate so you can have clustered caching transparently managed by Hibernate (non-transactional... if you need transactional caching you need Tangosol) <

    I have a complete open source transactional replicated cache running on my box right now ;-)

    Next release of Hibernate will have an embarrassingly great array of caching options!

    One thing that I'm _really_ looking forward to is getting some real numbers comparing the transactional replicated cache - Bela Ban's JBoss TreeCache - with the nontransactional SwarmCache, also based on jgroups. I have absolutely no idea what is the cost of making the cache fully transactional and I've not seen any research into this elsewhere.
  73. transactional cache[ Go to top ]

    One thing that I'm _really_ looking forward to is getting some real numbers comparing the transactional replicated cache - Bela Ban's JBoss TreeCache - with the nontransactional SwarmCache, also based on jgroups. I have absolutely no idea what is the cost of making the cache fully transactional and I've not seen any research into this elsewhere.

    >
    Transaction isolation must not be a very big owehead for cache.
    There are a few ways to implement it, but it can look like this kind of map :

    <code>
    Object put(Object key,long currentTxId, Object value );


    maxTxId is the last commited transaction id on current trasaction start
    Object get(Object key,long maxTxId, long currentTxId );

    txId can be ignored for cache "remove" and clear all by key.
    void remove(Object key );
    </code>

    Looks like the implementation must not be very expensive,
    this is a trivial transactional memory cache implementation :
    http://cvs.sourceforge.net/viewcvs.py/voruta/voruta/src/java/net/sf/voruta/SnapshotCache.java?rev=1.11&view=markup
  74. transactional cache[ Go to top ]

    Juozas, this is more like our "nonstrict-read-write" concurrency strategy that Hibernate wraps around a nontransactional cache in order to get read committed isolation. But I don't think that this is quite sufficient for a fully transactional cache with repeatable read. I understand that Bela is using locking in TreeCache, which certainly would have scalability implications, I suppose. Perhaps he can comment....
  75. transactional cache[ Go to top ]

    Juozas, this is more like our "nonstrict-read-write" concurrency strategy that Hibernate wraps around a nontransactional cache in order to get read committed isolation. But I don't think that this is quite sufficient for a fully transactional cache with repeatable read. I understand that Bela is using locking in TreeCache, which certainly would have scalability implications, I suppose. Perhaps he can comment....


    "nonrepeatable read:
    A transaction re-reads data it has previously read and finds that data has been modified by another transaction (that committed since the initial read)."

    Is it possible ?


    /**
    FIND MAX(txId)
    WHERE key.txId <= lastCommitedAtCurrentBegin or key.txId == currentTxId.
    */
    Object get( Object key,long lastCommitedAtCurrentBegin,long current )"

    It must be possible to implement it without locking. If we drop "or key.txId == currentTxId" transaction will be isolated form itself too.
  76. transactional cache[ Go to top ]

    Is it possible ?


    Juozas, clearly its -possible-, but not, I think, without a full implementation of the multiversion concurrency model - which must start to have some performance costs, I think.

    I'm not 100% though. You might be right. I would have to really think this through....

    I recall that last time I thought about this stuff, there was one little obscure detail that stopped our "read-write" concurrency strategy from being true repeatable read. (Wish I would have written this stuff down!)
  77. transactional cache[ Go to top ]

    Is it possible ?

    >
    > Juozas, clearly its -possible-, but not, I think, without a full implementation of the multiversion concurrency model - which must start to have some performance costs, I think.
    >
    > I'm not 100% though. You might be right. I would have to really think this through....

    The implementation for Serializable and Read committed isolation can be the same, it depends on "last" parameter
    (last committed txid for "Read committed" and last comitted txid before to start current transaction for "Serializable")

    synchronized Object get( Object key,long last,long current ){
      //store single version only and reread from db on conflict:
       ValueWrapper vw = get(key);
       if( isCommited(vw.getTxid()) &&
             (vw.getTxid() <= last || vw.getTxid() == current) ){
           return vw.getValue();
        }else{
          return null;
        }

    }

    There are a lot of ways to implement isCommited(txid), but just store uncomited keys in local cahe and copy it to glogal after commit.

    >
    > I recall that last time I thought about this stuff, there was one little obscure detail that stopped our "read-write" concurrency strategy from being true repeatable read. (Wish I would have written this stuff down!)
  78. transactional cache[ Go to top ]

    I'm working on documentation for the transactional cache, I will make available a standalone version plus documentation on jboss.org at the end of the week starting Nov 10th. Here's what we currently provide:

    - Local or replicated cache, runs outside of JBoss container
    - Choice of async or sync replication
    - Support for transactions. Users can plug in their own TransactionManager (API available).
    - W (serializable) or R/W (dirty reads) locks, or no locks can be chosen
    - Fully configurable
    - Structure is tree, similar in concept to JNDI (or LDAP for that matter)
    - AOP subclass; any object can be put into the cache using putObject(String name, Object pojo)
    - We currently use pessimistic locking, but support for optimistic locking is in the works (better concurrent access)

    Todo list:
    - Support for XA. We may make the TreeCache a JCA adapter
    - Optimistic locking (via versioning)

    This will be released mid November. The only dependency is currently on JMX and javax.transaction.

    Cheers,

    Bela Ban
  79. transactional cache[ Go to top ]

    The existing TreeCache done optimistically with versioning per object (not per field!) would be a very, very slick thing indeed. I do hope you have time to get XA support included though - it not only would be a great differentiator, but there are lots of scenarios where people want cache updates tied to other resources (like a JMS publish, or a push to an enterprise system via JCA).

    Also - kudos on removing the reliance on the JBoss tran manager. I noticed this going into the CVS tree several weeks ago and was curious if you guys were serious about being independent of the JBoss or not. I suppose you are...

    Question: will the optimistic version support the same chinese menu of transactional configurations that the pessimitic one does, or be more restricted?

         -Mike
  80. transactional cache[ Go to top ]

    The existing TreeCache done optimistically with versioning per object (not per field!) would be a very, very slick thing indeed.


    I think eventually we will make this configurable, right now TreeCacheAop (this is the one you're talking about) 'does' fields rather than the entire object. Actually, doing entire objects is way simpler, it just entails keeping track of whether an object was modified or not, rather than keeping a list of field modifications.


    > I do hope you have time to get XA support included though - it not only would be a great differentiator, but there are lots of scenarios where people want cache updates tied to other resources (like a JMS publish, or a push to an enterprise system via JCA).


    Yes - I agree.


     
    > Question: will the optimistic version support the same chinese menu of transactional configurations that the pessimitic one does, or be more restricted?

    It will support the same options.
    Bela
  81. Distributed cache[ Go to top ]

    I've used the technique of inserting a JNDI object with cached data with good success... it's not transactional, but it's good for very infrequenly-changed, mostly read-only data.
  82. Sure...[ Go to top ]

    <Jason Carreira>
    > I've done my reading... Perhaps it's time you started listening what everyone else is trying to tell you or read some of the thinking on enterprise java from the last 2 to 3 years.
    </Jason Carreira>

    What I am wondering is if Ted Neward's Effective Enterprise Java (from AW) comes out, would we atleast have some concrete facts to base our discussions upon? I can't find an official link to that book anywhere but enough websites (and his weblog) has mentioned that it *might* be out sometime next year.

    Would it give a better platform for discussing whether EJB suits the bill?

    --Dilip
  83. Entity Beans and Ted Neward[ Go to top ]

    What I am wondering is if Ted Neward's Effective Enterprise Java (from AW)

    > comes out, would we atleast have some concrete facts to base our discussions
    > upon? I can't find an official link to that book anywhere but enough
    > websites (and his weblog) has mentioned that it *might* be out sometime next
    > year.
    > Would it give a better platform for discussing whether EJB suits the bill?

    At a Java symposium a few months ago, I asked Ted whether there are any circumstances under which he would recommend using Entity Beans. He thought for a moment and then said "no".

    None of the other 9 panelists at the symposium endorsed Entity Bean use either.

    I agree with an earlier post from Colin: I have never heard of anyone who was experienced in both Entity Beans and alternative O/R frameworks (like JDO or Hibernate) say they prefer Entity Beans.

    Can Entity Beans work? Yes, but so can COBOL code. And to be honest, I think COBOL code might be prettier. :-)

    Cheers,
    Jeff
  84. I have used both...[ Go to top ]

    All of the applications I've worked on have pretty stringent performance requirements.

    I love entity beans. There are some things coming down the pike that will make them much easier to manage like packaging of metadata in the comments of the code, and no need for remote and home interfaces.

    "Can Entity Beans work? Yes, but so can COBOL code. And to be honest, I think COBOL code might be prettier. :-)"

    Unsubstantiated rhetoric...your COBOL code might look better than your EJB code. Don't lump me into that group, however.

    Best,

    John C. Dale
  85. % of EJB users here...[ Go to top ]

    "What percentage of all enterprise java bean users are represented here?" John Dale

    No idea but I currently use Session and CMP Entity beans. It wasn't my choice since the client dictated it but now that I've been doing it for a while the only thing I can think is "what a complete waste of time." See John, they don't actually have a distributed environment here. The lost productivity in building, starting WLS alone is unbeliveable. Tack on the extra time it takes me to code EJBs and the difficulty involved in debugging them and I would guess this project is costing the client about 50% more to build. The fact that EJBs don't support basic OO features is just a bonus...
  86. Hot deploy?[ Go to top ]

    You should consider structuring your project so you can hot-deploy into the container. You don't have to worry about startup time unless a limitation of your design means you have to cycle the server.

    What you are going through is not related to entity beans directly, right? It sounds like you are having some struggles with J2EE in general.

    I went through the same thing with WLS at my last position (Pearson). I learned quickly that hot-deploy for development is the only way to go.

    Best of luck and hang in there.

    John C. Dale
  87. Hot Deploy...[ Go to top ]

    "You should consider structuring your project so you can hot-deploy into the container. You don't have to worry about startup time unless a limitation of your design means you have to cycle the server."

    We have attempted to use hot deploy several times. Most of the time it fails and the application poller goes into an infinite loop and fails to reload the app. The times when it does work doesn't help much since hot deploy seems to take almost as long as a restart of the server. (side note: we are developing on W2k and WLS 7.1.

    "What you are going through is not related to entity beans directly, right? It sounds like you are having some struggles with J2EE in general."

    Not sure what you're getting at here. I've done plenty of J2EE work (non-EJB).

    "I went through the same thing with WLS at my last position (Pearson). I learned quickly that hot-deploy for development is the only way to go."

    If it worked reliably and quickly, I would agree. However, it does not (at least with WLS 7.1).
  88. % of EJB users here...[ Go to top ]

    I used to get involved heavily in the EJB -vs- whatever-else discussions. From the various discussions in past threads I noticed that the people who disliked entity beans most were those that believed a lot of the hype about them or that were looking more for persistance than anything else. Those that like them were often from a CORBA world or had a variety of other EAI experiences.

    I have used entity beans very often and quite successfully in heavily distributed EAI environments, data warehousing and the like. The performance is quite good, the savings in development and maintenance costs over traditional CORBA methods is fairly substantial, at least in my experience.

    On the other hand, I am working on an implementation of the Common Warehouse Metamodel and am using Hibernate and WebWork - it works very, very well and I would hate to have to use entity beans for this project. Such a project would be much more expensive to develop using them and would be a maintenance nightmare.

    I won't be glib and say that we should use the right tool for the right project, because as others have noted and as we have all seen from experience, we don't always have that luxury. But I always make my opinions known to those making the decisions, of course. Sometimes I have an effect, sometimes not.

    Cheers
    Ray
  89. % of EJB users here...[ Go to top ]

    I used to get involved heavily in the EJB -vs- whatever-else discussions. From the various discussions in past threads I noticed that the people who disliked entity beans most were those that believed a lot of the hype about them or that were looking more for persistance than anything else. Those that like them were often from a CORBA world or had a variety of other EAI experiences.

    I have used entity beans very often and quite successfully in heavily distributed EAI environments, data warehousing and the like. The performance is quite good, the savings in development and maintenance costs over traditional CORBA methods is fairly substantial, at least in my experience.

    On the other hand, I am working on an implementation of the Common Warehouse Metamodel and am using Hibernate and WebWork - it works very, very well and I would hate to have to use entity beans for this project. Such a project would be much more expensive to develop using them and would be a maintenance nightmare.

    I won't be glib and say that we should use the right tool for the right project, because as others have noted and as we have all seen from experience, we don't always have that luxury. But I always make my opinions known to those making the decisions, of course. Sometimes I have an effect, sometimes not.

    Cheers
    Ray
  90. % of EJB users here...[ Go to top ]

    Hi Ray,

    Can you tell us what particular aspects of distributed EAI environments
    and data warehousing make entity beans suitable? So far, I have only
    heard negative arguments (inefficient, slow to develop, etc) publicized.
    It would be good to have someone with real-life positive experience
    explain why entity beans fit his project context and what his context is.

    >I have used entity beans very often and quite successfully in heavily >distributed EAI environments, data warehousing and the like. The performance >is quite good, the savings in development and maintenance costs over >traditional CORBA methods is fairly substantial, at least in my experience.

    Thanks and regards,
    Calvin Loh
  91. % of EJB users here...[ Go to top ]

    I use entity beans to maximize throughput on database-intensive reports.

    I have many users transforming the parameters of a given report. The report takes about 10 seconds to load the first time. I load core report data (about 10kb) after doing some intense database queries. The data is then just transformed by date range and content with no additional database queries. The system would come to its knees and users would yell if the report had to be read from the database each time.

    Best,

    John C. Dale
  92. % of EJB users here...[ Go to top ]

    I have many users transforming the parameters of a given report. The report takes about 10 seconds to load the first time. I load core report data (about 10kb) after doing some intense database queries. The data is then just transformed by date range and content with no additional database queries.

    How's that better than something simple, such as a report servlet with a caching JDBC driver?
  93. % of EJB users here...[ Go to top ]

    Honestly, I've never used a caching JDBC driver.

    I do know that I'm able to distribute my components accross a cluster and ensure ACIDity.

    Tell me more...

    JC
  94. % of EJB users here...[ Go to top ]

    Hi John,

    Thanks for your explanation. However, it seems that
    you only use Entity Beans for read-only reports. Do
    Entity Beans still offer any practical advantage in
    read-write or mainly-write use cases?

    Thanks and regards,
    Calvin Loh
  95. Jason is Homer's Brother![ Go to top ]

    http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules/

    Throughput is amazing when you allow a good container vendor to work for you. Entity Beans as a source of major throughput advantage is mentioned in the J2EE docs (http://java.sun.com/j2ee). Give them a thourough read.

    You are full of hot air, and are a total homer.

    I see a major problem in the Java Enterprise space right now. Nobody wants to accept the fact that Sun and BEA and Oracle, IBM and JBoss got it right.

    There are a plethora of container services available to us, and only a small percentage of us use a high percentage of them.

    No, it's all about developing one's own stupid framework, and then making promises to some management homer about all the cost and time savings. The push it off on some poor bloak to maintain, telling him "Yeah, I developed this..." *wipes knuckles on lapel* "It only took me two weeks" *shuffles feet a bit* "and improves performance 60% - we'll save millions...eventually..." *the $shit piles thickly at his feet*

    I'm not saying stop developing software. I am saying, take a look at what the pioneers of our industry have laid-out for us. Read the documentation and learn how to apply the concepts. I've done so and have been handsomely rewarded.

    GEN SPEC IS YOUR FRIEND. If you don't truly believe that, you will never work for me. Furthermore, eventually, you won't be working for anyone, or you'll be making a career change at some point in the future.

    Best of luck with the latest big open source thing.

    John C. Dale
  96. Jason is Homer's Brother![ Go to top ]

    I have followed this discussion a bit (although without reading every post in detail) and have to say it is utterly stupid.
    You do not come off as particularly intelligent calling people names and not even listening to their arguments.

    The thing is, you have a few valid points, but so do the others, if you would only listen instead of seeing things in black and white like a 5 year old.

    General specs are useful a lot of the time, but an inferior spec will either change dramatically or die altogether, either case, its useless in its current form.

    "There are a plethora of container services available to us, and only a small percentage of us use a high percentage of them."
    Do you know why? YAGNI. If you do not need them, why use them? Just because the vendor said they were useful? I do not condone "re-implementation" of container-services, but as long as you dont need the services, dont use them! It makes life easier testing and debugging the application if you can test stuff without the container all-together, provided the services add no value to the use-case.

    Why do people use Hibernate over Entity Beans for example? Because from a lot of aspects, its a superior technology: leaps and bounds more productive, more flexible, easier to test and debug. General specs might in part be your friend, but on the other hand, unnecessary complexity is your mortal enemy.

    "GEN SPEC IS YOUR FRIEND. If you don't truly believe that, you will never work for me."
    Thanks for the advice, but I dont think the majority of people here fancy a career change to part-time developer, part-time interior decorator..

    Life is not black and white. General specs are no silver bullet, believing that is like saying "oh, there is no vendor-lock in with .Net, its an open standard because MS submitted it to a standards commité".
  97. Nice :o)[ Go to top ]

    I'm sure that you have some very solid talents for color coordination, but if you don't use entity beans you'll never hang a curtain in my shop. I *think* you're smarter than that, therefore I *am* sure you don't really believe that the alternatives you mention will make a significant impact on that portion of our community that actually build applications that reach non-technical end-users, and applications that have stringent requirements for scalability.

    BTW, where are the performance #'s on spring?

    Where is the cost savings analysis of dumping entity beans?

    In fact, I've had a rather enjoyable time participating in this thread. Homers always give me a chuckle.

    I like to identify harmful trends (part of the work I do at my current position). Non-adherance to the gen-spec for the majority of cases is dangerous...for some. For me personally, it means there will be many more opportunities to 'fix it' in the future. It is just kind of unfortunate that stockholder dollars hang in the balance. Haven't the stock of US businesses taken enough abuse from movements like Spring?

    Best,

    John C. Dale

    PS: Green and Blue aren't truly complementary colors, but nonetheless than can be used together.
  98. One Clarification...[ Go to top ]

    by 'stock of businesses' I mean public companies existing and operating in the US.
  99. Nice :o)[ Go to top ]

    Well, on the subject of Spring, I have absolutely no opinion on the matter as I know almost nothing about the whole thing (I am not negative, and not positive, oblivious and neutral would be the words). What I did have an opinion was the immediate slating of anything not coming out of a JCP commité.

    "I *think* you're smarter than that, therefore I *am* sure you don't really believe that the alternatives you mention will make a significant impact on that portion of our community that actually build applications that reach non-technical end-users, and applications that have stringent requirements for scalability."
    I have been participating heavily in projects that built Scandinavias largest and most high-volume payment systems, as well as a news website which is one of the regions most visited sites (both projects in the past 18 months).
    The latter doesnt have a single entity bean (some session beans though), the former actually doesnt have a single EJB (run on a single peace of monster hardware with failover, so EJB:s were redundant). If you know what you are looking at in terms of scalability requirements, plan for that, not less, and not a lot more (by that I mean: dont plan for Gartner .com-report growth projections anno 1999 if it is not realistic).

    But of course you are right that you shouldnt foolishly jump on the latest and greatest stuff, but on the other hand, open source works in a darwinistic way: projects that ARE viable will survive.

    Take for instance Struts and Hibernate, well handled by their lead groups I believe they will be around for some time to come, probably longer than entity beans in their current form. Entity beans WILL probably be around, but considering the heavy critique against them, they will probably change heavily.

    And speaking of technologies as complete opposites: why? There is nothing stopping you from using say Hibernate in collaboration with BMP Entities (should you want to do that), simply wrapping the hibernate objects in your bmp beans. Thats basically what I used to do when I did BMP:s (minus Hibernate, having base "PersistentObject:s" with JDBC code) to be able to test it outside a container.

    You should adhere to general specs when it is reasonable, but you shouldnt adhere to a technical spec just to adhere to a spec if it is redundant or overkill in terms of time needed vs. benefits.
    I for one hate to see when people throw in 50 new dependencies in the form of miscallaneous Jars for stuff that are standard in the J2SE and J2EE spec and do the stuff well..
  100. Wille,

    My ancestors on my mother's side were from Norway.

    Oof Dah!

    ;o)

    I see no reason to integrate an o/r mapper into my entity beans. As you state, that means including other libraries that might be referenced at multiple points within my ear file. Furthermore, why would I add a cache in my cache? Doesn't make sense. Lastly, I've become VERY good at writing JDBC code, as well as adhering to my business domain model, which is implemented as Entity EJBs.

    Simplicity. After I understood the life cycle of entity beans, and after I understood how finders work, it was VERY easy to develop and deploy entity beans when adding new business concepts. They are very easy to refactor, as well.

    I use some simple patterns that externalize SQL, uses prepared statements, is Facaded by a session bean (one point of entry for various application segments makes debugging easy, and also makes it easy to refactor/find things).

    At any rate, I hear where you're coming from, but after journies through Castor JDO, Versant, Gemstone PCA, and Cocobase *puke* I'm very happy developing JDBC code in entity beans. It works well, and is fast as hell.

    Best,

    John C. Dale, Interior Designer

    PS: Design Tip - when doing window treatments, if you choose to go with fabric, don't be afraid to lengthen the treatment such that there is extra slack at the bottom. When they drag on the floor, it can add a really nice 3-d effect that makes your rooms shine!
  101. "I use some simple patterns that externalize SQL"
    Congratulations! I would say that you have built your own "OR-mapper light", wouldnt you agree? :)
    I can agree with you to some extent: I prefer straight JDBC if I am working with an existing schema and some existing app, Its just easiest that way to see what is happening behind the scenes, since a lot of older apps are pretty heavily database centric.
    However, If I get the choice to work from "a clean slate", I go with Hibernate and try to let the Object oriented way drive the database schema (within reason, some things just dont translate to well from OO to DB), and generate the schema from my objects.
    The thing I like about Hibernate is that it lets me concentrate on business logic instead of persistence logic, especially using AOP (see my previous post in this thread regarding the TransactionManager), making applications a joy to test outside of a container.

    But I do understand where you are coming from as well, I would say its a matter of taste and opinion more than "right" or "wrong".

    And to put the records straight: I am from Sweden, but I have worked in Finland for the past 12 months. Swedish only sounds like norwegian when we are drunk and up-beat. ;)
  102. One would have to do O/R mapping...[ Go to top ]

    but relying on a third party framework that really doesn't save any time I do not.

    The bulk of my time is spent understanding the business problem, vetting my data models, and understanding the nature of the translation from database to end-user - workflows - in a way that will make the end-user more productive.

    Putting O/R code via JDBC (a time-tested o/r mapping API) into entities is cohesive and easy to maintain, has less moving parts than adding a third-party O/R mapper into the mix.

    Cheers,

    John C. Dale
  103. I once knew a girl that was...[ Go to top ]

    born on a small island between Sweeden and Finland. She spoke both languages, as well as German, English, and Italian. Nice girl. Pretty, too.

    You are right about using what works. Given my average requirements, timelines, and margin for error, using entity beans is the only approach for me.

    I would recommend to other aspiring developers out there to start understanding the concept of a distributable cachable entity as well. Why write an app that can't potentially be used by millions of people at the same time...if you're going to play the game, you may as well aim for the galaxies.

    JMHO.

    Best,

    John C. Dale (of the Karlsen's)
  104. Jason is Homer's Brother![ Go to top ]

    Wow, it took so long(didn't count the # of messqages but I think is big enough) before somebody mentioned .NET.
    That's a good sign. I can put up with imprecations, but not with derailed threads.
    Since I also mentioned .NET --> Shame on me!
  105. Jason is Homer's Brother![ Go to top ]

    My apologies, I just thought it was a suitable metaphor.

    And my apologies to John for the cheapshop as well, my ex girlfriend actually got me a bit interested in interior design. God knows she preferred decorating over me... ;)
  106. Couldn't agree more[ Go to top ]

    I agree with what Jason said.

    Can someone please explain to me why they think EJBs make things more scalable? Is it because the books, spec and your local jug guy says so?

    I see, three reasons being touted here:
    Transactions
    Security
    Concurrancy

    Declarative transactions are provided by Spring. I think, declarative security can also be provided with same ease, Spring developers here is a challenge for you.

    With the guys who really need distributed objects, go use EJBs. I am talking about people who use EJBs in the same container(JVM) that runs servlets as well.
    Please explain what concurrancy means. You are going to stop the servlet thread, make a call to the EJB, which may start a new thread, or start executing the logic in a pooled thread. You haven't saved anything, you actually have a servlet thread waiting till the EJB thread returns the call.

    Any real database worth it's salt, takes care of concurrancy for you. What on top of that does EJBs give you? Can they perform if the database doesn't?

    Doing a method call through the networking stack to the same OS program (JVM); How do you justify that? The logic most of the time is so that one day I can separate it. Well, except the fact, that separating them turns out to be a big anti-pattern. Read some articles by JBOSS's Mark Fluery, He actually says people should run EJB servers in the same JVM for performance. You know why people split EJB servers and servlet containers....licensing!!! They have to pay for EJB containers and servlet containers are free. So, run few paid EJB containers and run multiple free servlet containers. But you see, if you had not jumped on EJB bandwagon, you wouldn't have to do this "clustering for licenses". I rather do "clustering for performace" while still keeping license cost small.

    http://www.jroller.com/page/prane
  107. Transactions[ Go to top ]

    Container managed transactions? Aha... Now what if those could

    > be provided for you? That's what Rod is saying. It doesn't have
    > to be Spring. It could be done in a Servlet filter with a ThreadLocal
    > and a smart lazy loading Proxy. <plug:shameless> It could be done
    > in an Xwork Interceptor</plug:shameless>.

    Sun's Adventure Builder application has a TransactionFilter class.

    http://java.sun.com/blueprints/code/adventure/1.0/src/com/sun/j2ee/blueprints/waf/controller/web/TransactionFilter.java.html

    http://java.sun.com/blueprints/code/adventure/1.0/docs/architecture.html
  108. Scalability[ Go to top ]

    \Rod Johnson\
    We have never said that Spring is an alternative to EJB _period_; I didn't in the interview. We're not responsible for what others say.
    \Rod Johnson\

    From the interview:

    "And Spring has an AOP framework which enables it to provide a very good substitute for EJB that?s much lighter weight in many cases."

    Other team members have made similar statements in other threads.

    In general, Spring people never come out and say that Spring is "an alternative to EJB". Instead, they dance around the subject quite an agile manner, and point out a plethora of areas where Spring is better. In the end result, technically nobody says "Spring is better than EJB; dump EJB and use Spring!". But that's the message that's being sent. When the lead Spring person says "Spring has an AOP framework which enables it to provide a very good substitute for EJB", most people are going to read that as "Spring is better than EJB". Maybe it's not what you intend, but that's the message I'm receiving.

        -Mike
  109. Scalability[ Go to top ]

    \Rod Johnson\

    > We have never said that Spring is an alternative to EJB _period_; I didn't in the interview. We're not responsible for what others say.
    > \Rod Johnson\
    >
    > From the interview:
    >
    > "And Spring has an AOP framework which enables it to provide a very good substitute for EJB that?s much lighter weight in many cases."
    >
    > Other team members have made similar statements in other threads.
    >
    > In general, Spring people never come out and say that Spring is "an alternative to EJB". Instead, they dance around the subject quite an agile manner, and point out a plethora of areas where Spring is better. In the end result, technically nobody says "Spring is better than EJB; dump EJB and use Spring!". But that's the message that's being sent. When the lead Spring person says "Spring has an AOP framework which enables it to provide a very good substitute for EJB", most people are going to read that as "Spring is better than EJB". Maybe it's not what you intend, but that's the message I'm receiving.

    What Spring team members are saying cleary (to everybody but yourself apparently), is that we think Spring presents a better choice than EJBs, some of the time (ok, even most of the time). How does Rod's quote above equate to saying that Spring is an alternative to EJBs, period, in the context of that interview?

    Nobody is dancing around the subject, nobody is saying one thing and meaning another. The message (w/regards to EJBs) is pretty simple: there are a lot of situations in which people are using EJBs, and would be better off using Spring (or something like Spring even). There are also situations when it makes sense to use EJBs, be it legacy code, the need for remoting, etc. For these situations there is even a significant body of code in Spring whose only use is to make working with EJBs even easier (both as a client and to implement EJBs.

    You are trying to make a black and white thing out of this, and nobody (from the Spring team) has ever positioned it that way. Nobody has ever tried to get a message across as simple as "Spring is better than EJBs". That would be a simplistic, ludicrous position to try to push. There are any number of factors which combined together would make one a better choice than the other, for that particular situation.

    Please stop imagining things that aren't there; it serves no useful purpose. Use Spring if it's of some use to you, don't use it if it's not. It's that simple...

    Regards,
    Colin
  110. Scalability[ Go to top ]

    \Colin Sampaleanu\
    What Spring team members are saying cleary (to everybody but yourself apparently), is that we think Spring presents a better choice than EJBs, some of the time (ok, even most of the time). How does Rod's quote above equate to saying that Spring is an alternative to EJBs, period, in the context of that interview?
    \Colin Sampaleanu\

    I apologize, sometimes I get easily confused. I think I get it now. Some of the times Spring presents a better choice than EJBs (no make that most of the time). The few times (almost never times) when this isn't true is when remote access to a component is needed, in which case EJB may be superior (in those few times/whoever does this times when remoting is needed).

    Have I got it right now? This is the message that is being portrayed clearly? Or am I still flubbing it?

    \Colin Sampaleanu\
    Nobody is dancing around the subject, nobody is saying one thing and meaning another. The message (w/regards to EJBs) is pretty simple: there are a lot of situations in which people are using EJBs, and would be better off using Spring (or something like Spring even). There are also situations when it makes sense to use EJBs, be it legacy code, the need for remoting, etc. For these situations there is even a significant body of code in Spring whose only use is to make working with EJBs even easier (both as a client and to implement EJBs.
    \Colin Sampaleanu\

    Actually, I've yet to see Spring demonstrated to be superior to Stateless Session Beans and other standard mechanisms in the long haul. There are alot of people who have little desire to buy into a code base which is less than a year old that's still not quite 1.0 and which is completely non-standard - not even a de-facto standard. If I seem a bit over-the-top with criticism of Spring, it may because I've yet to see any Spring member admit that Spring has any limitations in public at all beyond "we don't do remoting, we don't do JMS". What's presented is an endless stream of positives and not one negative. To be frank, the posts of Spring members don't sound like open source developers sharing their work with the world; it sounds like a marketing department coupling with Sales trying to make a hard sell to a target company.

    \Colin Sampaleanu\
    You are trying to make a black and white thing out of this, and nobody (from the Spring team) has ever positioned it that way. Nobody has ever tried to get a message across as simple as "Spring is better than EJBs". That would be a simplistic, ludicrous position to try to push. There are any number of factors which combined together would make one a better choice than the other, for that particular situation.
    \Colin Sampaleanu\

    This is a nice twisting of what I said, but ironically right along the lines of what I was trying to say. Get off your high horse and read what I said again:

    "When the lead Spring person says 'Spring has an AOP framework which enables it to provide a very good substitute for EJB', most people are going to read that as 'Spring is better than EJB'.

    As I also said, and it now _ironically_ applies to you, technically no one is saying Spring is better than anything. Oh no - can't say that. Instead - just like you're doing - you say it's better in some cases and not so much in others. And the phrase "enables it to provide a very good substitute for EJB" hangs out there.

    For the record, I'm not saying there's any grand conspiracy. I don't think anyone's trying to dupe anyone here. The point is much simpler - you guys are misleading people. Here's one way to dissect the interview:

       - show a bunch of problems with EJBs
       - talk about the possibilities of AOP supplanting much of J2EE
       - Hey - hey! - we've got a framework which does AOP and J2EE type stuff
       - Who knows - our framework might be a good substitute for using EJBs.

    You knock down the evil existing regime, talk about a utopia, talk about your little world which has a piece of that utopia, make a small connection between your world and that utopia - and let the reader draw her own conclusions.

    And before I see another round of protests and shocked outrage, let me ask a real serious question. There's a framework floating around in open source, it's called Spring. It wraps J2EE in some ways and works with it in others. OK, fine.

    Now tell me this - why can't someone turn around in a TSS thread without Spring being brought up? Why is there an aggressive push to inject "Spring" into any remotely related discussion? Hell, two months after the project was setup on Sourceforge people were posting here saying, to paraphrase "Hey, buddy - got problems with JDBC? Why don't you give Spring a try?". This isn't happening in a grass-roots-movement sort of way where tons of honest people have tried it, liked it, and are trying to help out their fellow man. No - it's the same two or three Springers pumping up their own technology wherever they can.

    Why is that?

    \Colin Sampaleanu\
    Please stop imagining things that aren't there; it serves no useful purpose. Use Spring if it's of some use to you, don't use it if it's not. It's that simple...
    \Colin Sampaleanu\

    Ah, the biggest fallacy there is in software today. You don't like it, just ignore it and move along.

    HA! The supposition is that the average developer gets to choose the tools he works with, and the projects he works on. Again I say - HA! At least 50% of what I work with and on is chosen by someone else - that's the nature of projects in an IT environment. At least half of what you work with is inherited from someone else.

    So whether I like it or not, when Spring or AOP or JBoss or Coherence or Hibernate or Oracle App Server or Joe's Noodle Farm and Web Framework get aggressively marketed on forums like this, chances are I'm going to see that product down the line at some point. This isn't always a bad thing, mind you - Coherence and Oracle and Hibernate don't seem all bad :-) But I'd _love_ to live in a world where I could say "Spring is of no use to me - I choose not to use it!". Again - HA! The way you guys are pushing it, I guarantee within 6 months some yahoo I work with will have integrated it into half of an application code base whether I like it or not. But, by posting here, I have maybe raised the possibility by a millionth of a percent that that yahoo will have second thoughts and thoroughly evaluate the thing in context and not trust the cheerleading of Spring team members on its own.

         -Mike
  111. -Mike

    > "When the lead Spring person says 'Spring has an AOP framework which enables >it to provide a very good substitute for EJB', most people are going to read >that as 'Spring is better than EJB'....
    >
    > Now tell me this - why can't someone turn around in a TSS thread without Spring being brought up?
    >This isn't happening in a grass-roots-movement sort of way where tons of >honest people have tried it, liked it, and are trying to help out their fellow >man. ...
    >      -Mike

    Speaking as an honest man from the grass roots (born in a log cabin) who's tried Spring and liked it, I'll take a shot at this.

    Before I'd heard of any of these IoC/AOP frameworks, I was acutely aware of the need to develop and test persistence and domain code outside an EJB container. I started a home brew framework based on Martin Fowler's and Scot Ambler's Enterprise Patterns and soon saw too much re-invention of wheels. Then I checked out JBoss AOP, pico-container, and Avalon. Close but no cigar. Then, thanks to numerous mentions on TSS, I checked out Spring and read Rod's book, it speaks directly to my frustrations with EJB's and is usually steps ahead of me toward solutions.

    Spring and other frameworks are too new, too incomplete, and have no track record. Promoting Spring on TSS is a smart way to attract users and developers to keep the project viable and lay down a track record to prove how good it is, or isn't.

    It's way too early to say how good it will become. Lots of things still need to go right. But using Spring in its current unfinished state looks less risky than most pre-1.0 software because its non-intrusive architecture and compatibility with third party software should let people replace just the bits they don't like without having to junk it all. It lets you keep EJB's as a fall back option if it disappoints.

    It's already sensible to try Spring on pilot projects, as I'm doing, and arguable to try it on critical projects. Especially if it prevents known EJB problems.

    Spring and Hibernate can fairly be called grass-roots movements. They reflect what developers want from enterprise Java, people see the potential and have high hopes.

    Gary

  112. > It's way too early to say how good it will become. Lots of things still need to go right. But using Spring in its current unfinished state looks less risky than most pre-1.0 software because its non-intrusive architecture and compatibility with third party software should let people replace just the bits they don't like without having to junk it all. It lets you keep EJB's as a fall back option if it disappoints.
    >
    It is very important for any stable or pre-1.0 framework, "safe" application life cycle must not depend on framework life cycle (ideal architecture), non-intrusive architecture makes code more reusable too.
    I think AOP is the best way to solve this kind of problems at this time, It is not any kind of alternatyve for EJB, but it can be a way to make EJB better.
  113. Well, that was so well written I'm just flabbergasted.

    My only point of disagreement is in lumping Hibernate and Spring into similar types of grass-roots movements. Hibernate's been 1.0 for well over a year, and hit 2.0 back in June (and by all accounts the 1.0 and 2.0 versioning is an accurate reflection of the state of the code), and by any measurement has quite a thriving user base. There are risks in using it, being non-standard, but those are fairly well understood, and the developers do a good job of stating in total what Hibernate is and what it ain't. By comparison Spring still a toddler, and by my research has a pretty small user community so far - and it's _not_ clear that it will ultimately rise above the competition and come as close to a de facto standard as Hibernate has (Hibernate isn't there yet, but it's coming close).

    I have no beefs with people pitching their wares, but some have more cause to do so then others, and some pitching just goes over the top IMHO.

        -Mike
  114. Scalability[ Go to top ]

    I apologize, sometimes I get easily confused. I think I get it now. Some of the times Spring presents a better choice than EJBs (no make that most of the time). The few times (almost never times) when this isn't true is when remote access to a component is needed, in which case EJB may be superior (in those few times/whoever does this times when remoting is needed).

    >
    > Have I got it right now? This is the message that is being portrayed clearly? Or am I still flubbing it?

    Give me a break. The point of my message was not to list all the reasons why you would want or not want to use Spring over or together with EJBs. The technical arguments have been gone over before. The point, which was stated very clearly, was that the Spring team has never tried to portray Spring as a total replacement for EJBs, and that there are a number of factors involved in such a decision.

    > \Colin Sampaleanu\
    > You are trying to make a black and white thing out of this, and nobody (from the Spring team) has ever positioned it that way. Nobody has ever tried to get a message across as simple as "Spring is better than EJBs". That would be a simplistic, ludicrous position to try to push. There are any number of factors which combined together would make one a better choice than the other, for that particular situation.
    > \Colin Sampaleanu\
    >
    > \Mike Spille\
    > This is a nice twisting of what I said, but ironically right along the lines of what I was trying to say. Get off your high horse and read what I said again:
    >
    > "When the lead Spring person says 'Spring has an AOP framework which enables it to provide a very good substitute for EJB', most people are going to read that as 'Spring is better than EJB'.
    >
    > As I also said, and it now _ironically_ applies to you, technically no one is saying Spring is better than anything. Oh no - can't say that. Instead - just like you're doing - you say it's better in some cases and not so much in others. And the phrase "enables it to provide a very good substitute for EJB" hangs out there.
    >
    > For the record, I'm not saying there's any grand conspiracy. I don't think anyone's trying to dupe anyone here. The point is much simpler - you guys are misleading people. Here's one way to dissect the interview:
    >
    > - show a bunch of problems with EJBs
    > - talk about the possibilities of AOP supplanting much of J2EE
    > - Hey - hey! - we've got a framework which does AOP and J2EE type stuff
    > - Who knows - our framework might be a good substitute for using EJBs.
    >
    > You knock down the evil existing regime, talk about a utopia, talk about your little world which has a piece of that utopia, make a small connection between your world and that utopia - and let the reader draw her own conclusions.
    >
    > And before I see another round of protests and shocked outrage, let me ask a real serious question. There's a framework floating around in open source, it's called Spring. It wraps J2EE in some ways and works with it in others. OK, fine.
    >
    > Now tell me this - why can't someone turn around in a TSS thread without Spring being brought up? Why is there an aggressive push to inject "Spring" into any remotely related discussion? Hell, two months after the project was setup on Sourceforge people were posting here saying, to paraphrase "Hey, buddy - got problems with JDBC? Why don't you give Spring a try?". This isn't happening in a grass-roots-movement sort of way where tons of honest people have tried it, liked it, and are trying to help out their fellow man. No - it's the same two or three Springers pumping up their own technology wherever they can.
    >
    > Why is that?
    >
    > \Colin Sampaleanu\
    > Please stop imagining things that aren't there; it serves no useful purpose. Use Spring if it's of some use to you, don't use it if it's not. It's that simple...
    > \Colin Sampaleanu\
    >
    > \Mike Spille\
    > Ah, the biggest fallacy there is in software today. You don't like it, just ignore it and move along.
    >
    > HA! The supposition is that the average developer gets to choose the tools he works with, and the projects he works on. Again I say - HA! At least 50% of what I work with and on is chosen by someone else - that's the nature of projects in an IT environment. At least half of what you work with is inherited from someone else.
    >
    > So whether I like it or not, when Spring or AOP or JBoss or Coherence or Hibernate or Oracle App Server or Joe's Noodle Farm and Web Framework get aggressively marketed on forums like this, chances are I'm going to see that product down the line at some point. This isn't always a bad thing, mind you - Coherence and Oracle and Hibernate don't seem all bad :-) But I'd _love_ to live in a world where I could say "Spring is of no use to me - I choose not to use it!". Again - HA! The way you guys are pushing it, I guarantee within 6 months some yahoo I work with will have integrated it into half of an application code base whether I like it or not. But, by posting here, I have maybe raised the possibility by a millionth of a percent that that yahoo will have second thoughts and thoroughly evaluate the thing in context and not trust the cheerleading of Spring team members on its own.

    So let me summarize: You don't really think Spring is that great (for some reasons that will be shared with us at some other time, this forum is reserved for pissing matches only I guess). You feel Spring is getting way more exposure than it deserves. Too much exposure for any product is bad, although if you (Mike Spille) like it, then it's really ok. Other developers are just to stupid to consider the technical merits of various products and try them out on their own; your arguments to the effect that Spring is getting too much publicity will steer them towards the right path, so that when you inherit the projects those misguided developers produce they will be in at least a slightly better state.

    The above paragraph, distorted and ridiculous as it is, is totally representative of the kind of stuff you have been spewing yourself.

    Spring has gotten some exposure lately. So what? On TSS, this is a combination of 3 or 4 front page mentions (e.g. the Spring 0.9 release, Rod's article a few weeks back, and Rod's interview, which was done in June but only got posted now), as well as the fact that it has come up in some other threads from time to time. What is wrong with this. If there was no interest in Spring, it would quickly die down, same as any number of other products have faded away. I have yet to see a posting from a Spring developer where I would call it inappropriate mention of the product, or misleading info was intentionally given (which would be a problem). If somebody is looking for a way to solve a problem, and a Spring developer knows that Spring can solve that problem in a decent fashion, it is normal and expected that he would advocate trying Spring.

    What I would suggest to you is that you have a bit of faith in the ability of others to make decisions for themselves, based on the technical merits (which you can add to, if you have something to say). The same applies w/regards to any perceived agressive marketing (I don't think anybody here is buying Gerald Bauer's various conspiracy theories, despite the intensity and frequency of his postings). If somebody is not sharp enough to make up their own minds, the bile you have been spouting here is not going to make a difference. If Spring is really as useless as you seem to think it is, then any kind of buzz created by the recent publicity is not going to be enough to keep it going. If it serves a real need for real developers, as we think it does, it's going to be around for a long time to come.

    Regards,
    Colin
  115. Scalability[ Go to top ]

    \Colin Sampaleanu\
    Give me a break. The point of my message was not to list all the reasons why you would want or not want to use Spring over or together with EJBs. The technical arguments have been gone over before. The point, which was stated very clearly, was that the Spring team has never tried to portray Spring as a total replacement for EJBs, and that there are a number of factors involved in such a decision.
    \Colin Sampaleanu\

    Give me a break. I was reacting to statements in this interview, like " And Spring has an AOP framework which enables it to provide a very good substitute for EJB". If you don't understand what "very good substitute for EJB" means, then I don't know what to say. If you want to get mad at somebody, get mad at Rod Johnson, not me. The quote is his, not mine. Twist and dance all you like, that's what the friggin' guy said.

    \Colin Sampaleanu\
    So let me summarize: You don't really think Spring is that great (for some reasons that will be shared with us at some other time, this forum is reserved for pissing matches only I guess).
    \Colin Sampaleanu\

    I suppose reading plain english is a problem here. Spring has promise and uses some interesting ideas. It's also very young, pre-1.0, and has yet to be proven. And yet the author suggests this immature technology as a "very good substitute for EJB". Maybe Spring will succeed, but it's too early to tell.

    \Colin Sampaleanu\
    You feel Spring is getting way more exposure than it deserves. Too much exposure for any product is bad, although if you (Mike Spille) like it, then it's really ok. Other developers are just to stupid to consider the technical merits of various products and try them out on their own; your arguments to the effect that Spring is getting too much publicity will steer them towards the right path, so that when you inherit the projects those misguided developers produce they will be in at least a slightly better state.
    \Colin Sampaleanu\

    Close, but not quite. My issue is that the Spring team members are responsible for the bulk of the exposure it gets - they shamelessly plug it any chance they get. And when they do so, they neglect to mention that it's young and unproven and that they feel free to diddle with it and break existing code when they feel like it. My issue is that the Spring team members plug their product in an unresponsible manner.

    \Colin Sampaleanu\
    Spring has gotten some exposure lately. So what? On TSS, this is a combination of 3 or 4 front page mentions (e.g. the Spring 0.9 release, Rod's article a few weeks back, and Rod's interview, which was done in June but only got posted now), as well as the fact that it has come up in some other threads from time to time. What is wrong with this. If there was no interest in Spring, it would quickly die down, same as any number of other products have faded away.
    \Colin Sampaleanu\

    Some exposure? Give _me_ a break, sir. Spring developers hijack threads on a weekly basis to promote Spring.

    As for "If there is no interest in Spring" - my point, which you seem to miss, is that the majority of the interest is the developers beating the bushes for users. In fact, there's damn little interest in Spring, but the Spring developers just keep posting more if there's a little slack in coverage.

    Interest in a product is signaled when 3rd parties seek you out, when independent articles and books start growing up around you without your pushign for them. "Interest" is not the web equivalent of the originators passing out flyers and cold calling customers. When you or Juergen or Johnson post a Spring spiel on TSS threads, that's not the community showing interest - it's you guys trying to force interest.

         -Mike
  116. Scalability[ Go to top ]

    <Mike Spille>
    Give me a break. I was reacting to statements in this interview, like " And Spring has an AOP framework which enables it to provide a very good substitute for EJB". If you don't understand what "very good substitute for EJB" means, then I don't know what to say. If you want to get mad at somebody, get mad at Rod Johnson, not me. The quote is his, not mine. Twist and dance all you like, that's what the friggin' guy said.
    </Mike Spille>

    The friggin' guy actually said: "And Spring has an AOP framework which enables it to provide a very good substitute for EJB that’s much lighter weight in many cases."
  117. Mike,

    >
    > I have to say that that's one of your best posts yet.
    >
    > My problem with the Spring framework (besides idealogical differences wrt issues like exception handling) is its being positioned by some as a viable alternative to EJB period. That, from what I've seen of Spring, is definitely not a given.
    >
    > It's one thing to use Spring in a small-to-medium sized web application. Or an application that could do without a lot of the unnecessary, over-the-top plumbing that ends up insidiously worming its way into most J2EE applications.
    >
    > While the Spring team has never positioned Spring as an absolute alternative to formal J2EE constructs, I have seen many tout Spring as a full-fledged choice of infrastructure in the enterprise context, or should I say in the "so called enterprise context".
    >
    > IMHO, I think that Spring, or an equivalent framework, will definitely help new J2EE developers start out on a firm footing, or help experienced users cut through repetitive configuration and coding tasks in simpler applications.
    >
    > But for large, demanding applications I don't see how leaving EJBs (minus EBs) and messaging out of the picture will let you solve the problems that are typically faced in those environments.
    >
    > So basically what I am trying to say, and I am not sure that the Spring team is saying anything different, is that Spring is NOT the kind of framework that you would use in large applications (at least 1000+ users with 100+ or more simultaneous users, systems integration, multiple databases, legacy connectivity etc).

    I am glad that you make the distinction between what the Spring team has said about Spring, and what 'others' have said. The Spring team has never positioned Spring as an alternative for EJBs, period. They have positioned it as a viable alternative to EJBs for _most_ of the problem sets where EJBs are currently being used, with significant advantages in those cases. If somebody wants to use EJBs, there is in fact a significant amount of supporting code in Spring for usage of Spring together with EJBs, that will make EJB usage a more pleasant experience. And I can say that from experience, having brought Spring into a large project which was previously using Session and Entity ejbs...

    Having said that, I seriously question that 'automatic or inherent' scalability which many people assume comes of writing an app with EJBs. My experience working with teams writing code using EJBs is that the increased turnaround time in a code/build/debug cycle and inability to isolate code properly results in suboptimal, buggy code. This is especially true when talking about Entity beans, which force persistence semantics onto the domain model.

    Messaging is another matter entirely, and I don't think anybody (from the Spring team) has positioned Spring as an alternative to MOM, when MOM is actually needed.

    Regards,
    Colin
  118. Mike,

    "The book isn't bad. But the book was written a year ago (possibly slightly more). What's that got to do with an interview published now? Are you saying people should go buy his book to make sense of the interview? If so - what's the point in the interview?"

    My understanding of the book is that its main ideas are for a designer to understand the technology, understand the requirements and use common sense. Not using the technology for the sake of it. Hopefully, this way of envisaging any kind of architecture will never become obsolete, unlike technology. The interview is about J2EE design, the book is about J2EE design, and fundamentals of J2EE design have not changed much in a year. The point of an interview is to expose a few ideas in a short period of time. People who disagree with the interviewee on the sole basis of the interview should perhaps make sure they don't misunderstand the interviewee's position in their haste. The same way you should not judge a book by its cover, you should not judge an author by an interview. Rod's book after a year is still my J2EE bible (and many of my colleagues') because I feel it's a collection of common (quintes)sence.

    "Look at the quote of mine you quoted - it talks about writing style and the reaction people (such as myself) may have to it. That's not personal, that's saying "so and so writes on this subject in the tone of an expert, but he's wrong on several particulars (or dodges the details)"."

    The fact that many people express ideas that diverge precisely means noone is "right" or "wrong". There are many ways to build a house. And I don't think you can tell an expert from his tone: this is a totally shallow argument in that respect. For the dodged details, noone is perfect; refer to the book, and criticise constructively. Debate is fine, ego-conflict is a pure waste of time and energy.

    "Like it or not, creating software these days is not an objective zone of fact and code. Personalities clash, people pontificate, pundits push favorites, critics spew bile. People read this stuff and form some conclusions based on all of this information - little of which is objective fact, but instead interactions of personalities and preferences and various agendas."

    You are "right" to stress upon politics and personalities clashes. These are actually the strongest hindrances to software development. Both are listed in the antipatterns book (which means it is quite a known fact). As to the lack of objectivity, this is only your opinion. Rod's book shows a special care for explaining the rationale behind most positions in the interview, which I think is a good approach to objectivity. Also, people expressing views is not always the outcome of hidden agendas... Leave the conspiracy theory to Fox Mulder and Scott McNealy. :)

    "As to "Write your own book" - I don't personally subscribe to author worship. People who write books - good or bad - are no different from other people, they're just more visible. And what someone said in a book they wrote a year ago has little to do with what they're saying today in an interview or message board. Each individual "utterance", if you will, should be evaluated individually on their own merits, not on the standings of past accomplishments."

    I think you misunderstood my comment or maybe I did not explain it right. Let me reformulate: writing a book that is visibly widely acknowledged as *the* reference, in my working environment and in various public forums, as far as I can see, is surely a good sign that the book is of good value. And I don't really care what Rod's motivation was if the book brings me more than what I initially expected. I'm very happy if he can now enjoy reaping the benefits of it: he just deserves it.

    I don't understand the difference you make between merits and past accomplishments. I think taking almost a year to write such a valuable book that the whole J2EE community can benefit from is at the same time an accomplishment, a gift and thereby a merit. And I don't see many changes between the ideas expressed in the interview and in the book.

    "In this particular case, I think individuals and their agendas do come into play. Certain people looking at this interview will look at it and come to the conclusion that it's a rather transparent effort to promote Spring, trash J2EE, and trash competitors who have dissed Ron in the past like those involved in JBoss AOP - and that the interview serves no other purpose than to push those personal agendas. If you're considering someone's advice and expertise in a given area, it's often quite helpful to understand their biases and agendas - the "why" in addition to the "what". And if you're not a stone-cold expert in a given area it's very easy to get fooled, and mistake ideas generated by a hidden agenda for obejctively useful ideas."

    I agree with you. We are all manipulated at various degrees, purposedly or not. Rod has never hidden he's not very keen on entity beans. As soon as you publicly express an opinion, it is normal that people react in many ways: some will simply accept everything as Gospel's truth, others will contradict for the sake of it, others will spend time enquiring the hidden agendas, some will just evaluate what the opinion brings to them, etc. In any case, there is only so much we can do about understanding the "whys". I assume many people do designing/programming as a job, not as an ideology. Again, I can only strongly advocate people to read his book and make their own opinion about the "whats" and "whys". Additionally, I can also recommend to read the interview: Rod is not trashing J2EE. J2EE != EJB != entity beans.

    What's wrong with promoting a framework you created and in which you believe ?

    Perhaps you could tell me more about what you think is Rod's hidden agenda (since you sound like you imply there is one...).

                    Yann
  119. Ack, another Spring developer[ Go to top ]

    Yann, I didn't realize you were a Spring developer until I just brushed by the Sourceforge page.

    That puts your comments in rather a different light...

        -Mike
  120. Ack, another Spring developer[ Go to top ]

    Yann, I didn't realize you were a Spring developer until I just brushed by the Sourceforge page.

    >
    > That puts your comments in rather a different light...
    >
    > -Mike

    Yes, his comments, previously considered insightful, are now rendered invalid, as he is revealed to be just a card-carrying member of the Evil Spring Cabal, out to ensure world domination by using all despicable tactics at their disposal...
  121. Ack, another Spring developer[ Go to top ]

    Is there a special prize for 'outing' covert members of the Spring development team? Mike is making sterling efforts to keep alive every Spring thread that appears about to die due to lack of technical content. Not declaring himself on the Spring site as a developer clearly marks him out as the most evil and sneaky of the whole wicked bunch. Top marks also for John Dale's hilarious charicature of the pro-entity beans lobby.
  122. Ack, another Spring developer[ Go to top ]

    \David Friar\
    Is there a special prize for 'outing' covert members of the Spring development team? Mike is making sterling efforts to keep alive every Spring thread that appears about to die due to lack of technical content. Not declaring himself on the Spring site as a developer clearly marks him out as the most evil and sneaky of the whole wicked bunch. Top marks also for John Dale's hilarious charicature of the pro-entity beans lobby.
    \David Friar\

    <Sigh> People so often for the grand and melodramtic, when the reality is far simpler (and boring). I pointed out who was who to contradict the posts about grass-roots movements - if you look into it, you'll find most of the "grass roots" movements behind Spring are the spring developers themselves.

    That's all - no grand conspiracy, no Evil (or evil). No wickedness.

    As for technical content - it's hard to debate Spring people seriously on technical information, because their reply to every technical question is invaribly "this works well in our experience" and "you can easily back it out if it's a problem" and "well, the don't use that". If Spring tech discussions often devolve into pissing contents, perhaps it's because the Spring developers have little interest in talking technology except for touting how great it is and generally boasting, and responding to every negative with "no dependencies" "easy to back out".

         -Mike
  123. Ack, another Spring developer[ Go to top ]

    Mike,

    > As for technical content - it's hard to debate Spring people seriously on technical information, because their reply to every technical question is invaribly "this works well in our experience" and "you can easily back it out if it's a problem" and "well, the don't use that". If Spring tech discussions often devolve into pissing contents, perhaps it's because the Spring developers have little interest in talking technology except for touting how great it is and generally boasting, and responding to every negative with "no dependencies" "easy to back out".

    As I know what you're refering to: You've never bothered to ask a technical question about Spring's functionality. Your level of discussion is rather:
    - "how could you dare to switch your root package name from com.interface21 to org.springframework, as that breaks all your users' code"
    - "an alternative to certain J2EE services is the same as an alternative to the whole of J2EE, period"
    - "how to get Spring out of a codebase again if some yahoo dared to use it in a project that I might get in touch with"

    I'd love to discuss technical issues; care to dive into our bean factory features or our generic transaction support? No, you don't: You prefer to repeat the same general accusations over and over again. Of course there are valid issues with introducing third-party software to a an application's codebase, but they aren't specific to Spring at all. For example, if you choose to use a persistence toolkit like Hibernate or TopLink, you'll depend on that choice quite heavily.

    Just try a little play: Exchange the word "Spring" in your postings with the name of any other open source infrastructure software, be it "Struts", "WebWork", or "Hibernate". Your arguments are so general that they easily apply to any of those too. For example:
    - WebWork and Hibernate both changed their root package names from 1.x to 2.0;
    - Hibernate is an alternative to Entity Beans, just like TopLink and CocoBase;
    - all of those are proprietary in the sense that they can't be replaced in a drop-in style.

    This "discussion" reminds me of those Hibernate vs JDO threads last year. Many people didn't bother to actually check out Hibernate's features but rather kept complaining about it being "non-standard". There's so much interesting stuff going on outside of "standards", particularly in the open source world -- why do people like you try to fight innovative projects so fiercely, already in their early stages? Do you consider them a serious threat in the sense that you might come across them and have to learn about them one day?

    I don't expect a meaningful answer to the latter questions from you, so consider them rhetoric. No matter what anybody says or does, you will keep dissecting the value of projects that you hardly know anything about, and also dissect people's postings and try to make their points ridiculous. I prefer to be constructive and make things happen. After all, most people will judge a project by its value in everyday software development rather than by the balance of praise and ignorance in forums.

    Juergen
  124. Ack, another Spring developer[ Go to top ]

    \Juergen Hoeller\
    As I know what you're refering to: You've never bothered to ask a technical question about Spring's functionality.
    \Juergen Hoeller\

    I've never had such a conversation with _you_. I attempted several with Mr. Johnson, who was highly unresponsive to questions, and the whole discussion degenerated into an ugly furball with Mr. Johson pledging to never read another post of mine again.

    I've given up on trying any in-depth approach, because Johnson's response is always the same to anything that can be even mildly critical.

    \Juergen Hoeller\
    Just try a little play: Exchange the word "Spring" in your postings with the name of any other open source infrastructure software, be it "Struts", "WebWork", or "Hibernate". Your arguments are so general that they easily apply to any of those too. For example:
    \Juergen Hoeller\

    I don't know WebWork - I do know a bit about Struts and Hibernate. Those latter two (and particularly Strugs) are so popular these days that they are effectively de-facto standards. Hmm, perhaps Hibernate isn't _quite_ there yet, but it's gaining ground.

    As I said in another post right here in this thread, you can get locked in with these technologies, but the lock-in points and risks are pretty well known. Plus the products themselves are well-known and are pretty much guaranteed to be around for quite some time.

    Spring is not. Spring is still very young and has a very tiny user community, and there are no guarantees that it will take off - or that it might get crushed by another IoC competitor.

    You seem to fail to understand the concept of risk analysis as it happens to occur in big IT software decisions. People don't choose standards because they're dumb - they choose them because they've been burned badly in the past by non-standard products. In the case of Hibernate, it's got alot going for it - but being non-standard will always hurt it in some circles. The same is true, but more so, for a very young technology like Spring taking its first baby steps. Alot of people don't just like standards, they need them. That's reality - deal with it.

    In Spring's particular case - Mr. Johnson's public disdain of standards bodies (I'll post references if you like) means to me that Spring has no hope of ever being any kind of formal standard, which leaves only the possibility of de-facto. And who knows if that will happen? At least with Hibernate and other tools there's a chance that they will turn towards a standard if a good one comes out (like Hibernate possibly bending towards JDO if JDO 2.0 delivers the goods). With Spring, and Mr. Johnson in charge, I doubt you'll ever see Spring being standard anything.

    \Juregen Hoeller\
    There's so much interesting stuff going on outside of "standards", particularly in the open source world -- why do people like you try to fight innovative projects so fiercely, already in their early stages?
    \Juregen Hoeller\

    Let me turn this around a bit - why do people like you hijack threads all over TSS promoting alpha-level projects in their early stages? You guys were pushing Spring in _May_ as the cat's ass when it was so young it would qualify more as "unborn" then immature. You call what you're doing "innovative projects" - I have another name for it.

        -Mike
  125. re:Ack, another Spring developer[ Go to top ]

    <mike>
    I've never had such a conversation with _you_. I attempted several with Mr. Johnson, who was highly unresponsive to questions, and the whole discussion degenerated into an ugly furball with Mr. Johson pledging to never read another post of mine again.
    </mike>

    Well Mike, you called him ******* (http://www.theserverside.com/home/thread.jsp?thread_id=20100#87776). How can you expect him to respond to you?
  126. re:Ack, another Spring developer[ Go to top ]

    <mike>

    > I've never had such a conversation with _you_. I attempted several with Mr. Johnson, who was highly unresponsive to questions, and the whole discussion degenerated into an ugly furball with Mr. Johson pledging to never read another post of mine again.
    > </mike>
    >
    > Well Mike, you called him ******* (http://www.theserverside.com/home/thread.jsp?thread_id=20100#87776). How can you expect him to respond to you?

    He could've stopped there but did he? Instead he dropped another gem:

    <Mike Spille>
    "I'm curious how one makes money selling books when they have problems reading?"
    [http://www.theserverside.com/home/thread.jsp?thread_id=20100#87953]
    </Mike Spille>

    Since Rod has problems reading you can hardly expect him to respond, right?

    --Dilip
  127. The Real Buzz[ Go to top ]

    Toys come from factories and go to garbage. No need to remember where and how the last game ended. Containers serve some purpose but are rarely part of the game.

    Let's ask our heroes: Can you "find a lost transaction", Mike? Can you "rebuild a bank", Rod? The Server Side Star Command has done it many times, "to infinity and beyond".

    If there is somebody on this planet willing to pay an auction price for action figures delivered overnight from secure storage we can certainly offer our research and educated advice.

    For everyone here that has the crucial flow of considering that <toy intellect can rule the game> there exists one simple <work your levers and buttons> manual called "As We May Think". So if you can read, please examine it!

    An aisle full of Buzzes
    Toy Warehouse
  128. Ack, another Spring developer[ Go to top ]

    You seem to fail to understand the concept of risk analysis as it happens to occur in big IT software decisions. People don't choose standards because they're dumb - they choose them because they've been burned badly in the past by non-standard products.


    Granted, those are viable arguments. But nobody tries to promote Spring as instant infrastructure replacement for mission critical systems at that point of time. Many people are willing to use younger products for not so critical systems because they like their programming model. And many people just want to try out new stuff because they might eventually be able to leverage its benefits in an upcoming project. Why do you consider it so wrong to talk about stuff that's still in the process or reaching its final shape? Every product has to start somewhere; I guess Gavin could tell you a lot about early stages.

    > Let me turn this around a bit - why do people like you hijack threads all over TSS promoting alpha-level projects in their early stages? You guys were pushing Spring in _May_ as the cat's ass when it was so young it would qualify more as "unborn" then immature. You call what you're doing "innovative projects" - I have another name for it.

    Due to its heritage, Spring has been beta level since its inception as a SourceForge project. We're not eager in calling something "1.0 final"; that's why we're currenty at 1.0 M2. Mind you, other projects have been used or are currently used at 0.x stages, like Struts, Tyrex, Castor JDO, or C3P0. PicoContainer is also hardly final yet but already used in applications. What's so bad about that, after all? You're free to choose differently. But please do not generally discredit all people that are less conservative or face less restrictions in terms of infrastructure software choice.

    And finally, marketing is what makes people interested, be it in the shape of classic ads for commercial products or forum talk about open source projects. If you don't talk about your stuff, noone will be able to know about it. You can hardly blame people like us for mentioning Spring's benefits in appropriate contexts. Oh, I know you *can* but I guess most people would agree that your level of tolerance is very questionable. And frankly, I repeatedly wonder why you are able and willing to invest so much time in such destructive efforts. Over and out, once more.

    Juergen
  129. lifecycle[ Go to top ]

    Why do you consider it so wrong to talk about stuff that's still in the process or reaching its final shape? Every product has to start somewhere; I guess Gavin could tell you a lot about early stages. <

    Perhaps its just that america-lovin'-capitalist-pig-dog in me, but I just don't see anything at all wrong with pimpin' ya wares on TSS. I mean, I thought that was the whole /point/ of TSS; most of the news items relate to some product announcement or another.

    And in fact, i would argue that many of the announcements coming from commercial vendors relate to software products that are far less ready for primetime than OSS projects that still call themselves 0.9.5 or whatever.

    For a serious opensource project, early exposure here and elsewhere is essential to success. This is how we generate the necessary level of peer-review to get a good design nailed down in the early stages. Its also how we know if a project is a dead end or not.

    Hell, when I first announced the Hibernate project here, it was very early days. Probably, it was not even as ready as a couple of our existing opensource competitors. But we had a clear statement of goals, and the interest generated by this convinced me to keep working - which was an /incredibly/ huge risk at that time. The sheer number of hours of work and stress I put into something that, when I thought about it with a clear head, seemed unlikely to really go anywhere was perhaps a bit crazy.

    What I'm trying to say is that at the 3-6 month stage of an opensource project's life, it is vulnerable to the project founder(s) simply "giving up". To keep this stuff alive, the developers have to be able to see other people using and taking an interest in the software.

    (IMO, Spring is probably already past this stage, incidentally.)

    So, Mike, if you /want/ open source software, I think you're just going to have to put up with seeing new projects being advertised. Otherwise they will die before they progress from "new" to "mature" - and then there will be no more open source.

    And anyway, even new projects that go nowhere have something to offer in terms of concepts that eventually get picked up on and "done right" in another project.
  130. Ack, another Spring developer[ Go to top ]

    Btw, if you want to be mock polite (an interesting new touch), it's Dr Johnson. And my first name's Rod, not Ron. Says something about the quality of your research, perhaps?
  131. Ack, another Spring developer[ Go to top ]

    Btw, if you want to be mock polite (an interesting new touch), it's Dr

    >Johnson. And my first name's Rod, not Ron. Says something about the quality of
    >your research, perhaps?

    Dr. Johnson--er, can I still call you Rod? :-)

    I guess I was lucky not to have to answer and endure obnoxious posts on my SQLExecutor thread here last month. Some people didn't like aspects of my framework, but they were polite when they pointed out the "flaws" out to me!

    People--how about some civil debate, good humor, and cordiality here? We are discussing technical issues and design patterns--not politics and abortion!

    By the way, interesting interview, Rod. I need to learn more about AOP to have an opinion on that. But I would love for some better technology to come along and gain enough market share to replace Entity Beans in the corporate world.

    Cheers,
    Jeff
  132. Ack, another Spring developer[ Go to top ]

    \Colin Sampaleanu\
    Yes, his comments, previously considered insightful, are now rendered invalid, as he is revealed to be just a card-carrying member of the Evil Spring Cabal, out to ensure world domination by using all despicable tactics at their disposal...
    \Colin Sampaleanu\

    It's interesting how rather mild mentions of possible conflicts of interest, and trying to ascertain just where Spring fits in the scheme of things, results in people twisting things around into me talking about conspiracy theories and black and white absolutes.

    I neither said nor implied that his comments were invalid. When I said "...in a rather different light...", what was meant was that his responses were somewhat colored by his association. Not that they're invalid, just that he can hardly be considered all that objective. Just like Cedric defending Weblogic has to be considered in the light of his working for BEA, comments from a Spring developer should be considered in the light that he's a Spring developer. There's no need to invoke Evil, or Cabals, or conspiracies - it's just a useful factoid.

        -Mike
  133. The gentleman with the accent clearly has an agenda that is supported by discounting two if the most incredible features of J2EE!

    EEJB and Messaging are AWSOME.

    Best,

    John C. Dale
  134. Text transcript[ Go to top ]

    Where's the text transcript?! Our corporate firewall blocks almost every media file, so I can't watch the video... please, provide the text transcript as always...
  135. Text transcript[ Go to top ]

    Forget it. it seems the same stupid firewall didn't finished to load the bottom frame... after reloading a few times it finally appeared, sorry.
  136. My impressions...[ Go to top ]

    Spring Biggot.

    Be careful about taking his word for it on EJB. He actually proposes that Spring be used to substitute for EJB. This is a conflict of interest, as it is in his endorsed product’s interest for developers NOT to use EJB, and instead substitute 'his' product.

    Grain of salt, folks.

    It is cohesive to encode information about storing EEJB’s with the EEJB itself. Using BMP and SQL statements in the entity bean is practical, fast, and easy to maintain. A transactional cache at the app server tier is a HUGE advantage for performance and throughput, and if the EEJBs are designed and implemented correctly…all I can say is ‘B’utta. This methodology is quite mature, and easy to debug.

    He mentioned nothing about the throughput advantage of using Entity Beans. They also make it very easy to reuse components.

    I like what he said about coarse-grained EJB’s, and in fact I try to do this with my EEJB’s whenever possible.

    He didn’t mention much about performance and scalability. For the same reason he doesn’t endorse the distribution and marshaling to/from value objects (what is happening under the covers with any O/R mapper anyway – value concepts are being distributed from/to the database, albethem in different form), he shouldn’t also endorse extraneous marshaling to/from something other than a domain object. Frankly, I think Entity Beans (modeled after the Entity concept (syrah syrah) make great domain objects, and there is little overhead with interacting directly with JDBC in the Entity Bean Code. They (Entities)are cohesive and have behavior, and have intimate knowledge about how to persist themselves into the database.

    I liken an entity’s persistence like a little kid being tucked in. Eventually, when that kid grows up, he’ll want (hopefully) to tuck himself in. He knows just how he likes it. The entity should be the same way, tucking himself into a persistent data store.

    I think he is way to quick to discount Entity Beans. JMHO.

    “It is a great time to be a J2EE developer…”

    Indeed.

    Best,

    John C. Dale
  137. My impressions...[ Go to top ]

    Be careful about taking his word for it on EJB. He actually proposes that Spring be used to substitute for EJB. This is a conflict of interest, as it is in his endorsed product’s interest for developers NOT to use EJB, and instead substitute 'his' product.

    When I published my book, Spring (not yet an open source project) did not attempt to compete with EJB services such as CMT. Spring still doesn't, and never will, compete with entity beans. Yet I expressed similar views on EJB in the book.

    So things were rather the other way around: my reservations on EJB (note that I don't reject all use of EJB, by the way) predated and prompted my involvement in an effort to offer a replacement to some EJB services. I think it's perfectly reasonable to become involved in a project that reflects one's convictions. And I hardly think it disqualifies me from commenting on EJB.


    The gentleman with the accent clearly has an agenda that is supported by discounting two if the most incredible features of J2EE!
    EEJB and Messaging are AWSOME.

    Well, I imagine you sound like you have an accent to me :-) So let's leave accent out of the discussion.

    I have nothing against messaging, JMS or MDBs. I was just commenting on the fact that I've seen it used inappropriately in some cases. I make it clear that I think that in certain types of application, messaging is central, and that I think MDBs are a good MOM technology.

    I'm not exactly lonely in the anti-entity beans camp these days. But each to his own.

    Regards,
    Rod

    P.S. Ok, I can't live with the guilt. I own up. I get 50c every time someone chooses not to write an entity bean.
  138. My impressions...[ Go to top ]

    Be careful about taking his word for it on EJB. He actually proposes that Spring be used to substitute for EJB. This is a conflict of interest, as it is in his endorsed product’s interest for developers NOT to use EJB, and instead substitute 'his' product.

    >


    I think you're being a little harsh on the guy. I mean, "his product" ... last time I checked Spring was free/OS. I give the guy credit for having the cajones to admit that EB's for the most part suck, after writing a book on J2EE. The *book* is his "product", and I don't see how this interview helped promote a J2EE book.
  139. Nice rhetoric and some substance Rod...[ Go to top ]

    So you're saying that a strategy for replacing Entity services wasn't even a glimmer in your eye?

    my reservations on EJB...

    You have had reservations about using EJB before you started attempts at a competing paradigm. That's great, but isn't really cogent in support of the fact that you currently induce a conflict of interest with your contemporary associations and your viewpoints.

    And I hardly think it disqualifies me from commenting on EJB...

    You know what they say about opinions and ********s right Rod? I agree on this topic for sure. Everyone is entitled to their opinion.

    Well, I imagine you sound like you have an accent to me :-) So let's leave accent out of the discussion.

    I missed the 'no accent discussion' clause in the TSS rules of engagement. I used this trait as an identifying characteristic, much as I could have used your name. No reason to be insulted, as if I had said something like 'that ignorant britt has his head up his...' well, you get the picture.

    I'm not exactly lonely in the anti-entity beans camp these days. But each to his own.

    I would be interested in some empiricle data before letting my opinion be impacted by this statement. If you and one other are in question, than 2/totJavaDevs is a negligible rate.

    I can't live with the guilt. I own up. I get 50c every time someone chooses not to write an entity bean.

    Nice rhetoric, but everyone has to pay the bills, and if you could get .50 for every switch, you would do it, no? How about the prospect of 200k for 400 switches? More reasonable? Thanks for coming clean, anyway.

    Long Live Entity EJBS!

    ;oP

    Cheers,

    John C. Dale
  140. I'm not exactly lonely in the anti-entity beans camp these days. But each to his own.

    >
    > I would be interested in some empiricle data before letting my opinion be impacted by this statement. If you and one other are in question, than 2/totJavaDevs is a negligible rate.

    Unless you have been *completely* shut off from the Java community in the last few years, it would be clear that there is a large group of Java developers who are not satidfied with EEJBs. I would think that a quick glance at any Java forum year would be enough "empiricle data" for you. Not sure how you missed this.

    Ryan
  141. What you state...[ Go to top ]

    is far from some sort of fair empirical analysis.

    I think some developers have been dissatisfied with Entities for the following reasons:

    1) they are complex to implement
    2) they have been missapplied
    3) engineers are quicker to code than they are to read (related to 2)

    Entities make it possible to leverage an application-tier distributable clusterable cache that, if applied correctly, will DRASTICALLY improve throughput, performance, and will DRASTICALLY reduce maintenance costs if applied correctly.

    No matter where you go, $hitty engineers write $hitty code. Give credit where credit is due, however - blaming Entity EJB's because so many jackasses have missaplied them is foolish. Add EEJBs where you have big concurrency requirements, and where there is an intersection of data access concurrency. In short, cache things (intelligently) where you have many people accessing the same data.
  142. Nice rhetoric and some substance Rod...[ Go to top ]

    So you're saying that a strategy for replacing Entity services wasn't even a glimmer in your eye?
    Absolutely. Why should I attempt it when Hibernate, various JDO implementations etc already have? Not to mention TopLink, which existed before entity beans.

    I missed the 'no accent discussion' clause in the TSS rules of engagement. I used this trait as an identifying characteristic, much as I could have used your name. No reason to be insulted, as if I had said something like 'that ignorant britt has his head up his...' well, you get the picture.
    OK, John, I'm sure you didn't mean to offend. Maybe I was too touchy. So I won't mention your spelling either. Btw I'm now British, I'm Australian :-) However, I live in the UK so I guess my accent may have changed.

    [I'm not lonely in the anti-entity beans camp] I would be interested in some empiricle data before letting my opinion be impacted by this statement. you and one other are in question, than 2/totJavaDevs is a negligible rate.

    You really should read other people's postings more often. There have been a lot of people criticizing entity beans on TSS. Several books. And many projects have abandoned entity beans due to harsh experience. I could list quite a few (nothing to do with me btw), except that I can't really name names. Suffice to say that one of the cases I have information on is a big global bank, another is a big national bank in Europe, another is a major airline...

    Regards,
    Rod
  143. Popular opinion on EEJBs[ Go to top ]

    I have yet to meet anyone who has used an O/R mapper that thinks EEJBs are anything but a disaster. Having actually used them extensively, I would have to agree. So far the only people who I can find that have a favorable impression of them are people who have only done JDBC in the past.
  144. "If I am going to invest in EJB on an application, I am going to invest in EJB.
    I might use Spring to facilitate my use of EJB but that's about it. Mixing and matching parallel architectural elements is not something that, IMHO, is advisable." -- Sandeep

    Praise da lo'!

    Did it not occur to you, Rod, that there may be a silent majority of EEJB advocates/developers who are building/doing more than they are complaining?

    For your sake, of the projects you mention, I hope you weren't a principle part of those development efforts. Furthermore, the biggest killer of a project is an approach that is illustrated in Sandeep's comments.

    Cohesion and simplicity are best. More moving parts increase the liklihood of failure.

    In closing, this has been a great debate. I really enjoyed the bulk of your interview. It be far from me to lay dormant whilst some opinion or assumption be unquestioned. Nothing personal.

    Pardain me, now. I'll forgow the speel cheeker so's I can get bak to coding Jarva Entitty Beens.

    Damn Auzzies...

    ;o)

    Cheers,

    John C. Dale
  145. "Cohesion and simplicity are best. More moving parts increase the liklihood of failure."

    I find it really hard to believe that the author of this statement is a proponent of EEJBs, and is using it in their defense. As Jason said above, good luck, buddy.
  146. Luck has nothing to do with it...[ Go to top ]

    R-e-a-d.

    If your (or my) requirements include complexities for which J2EE and EJB was design to manage, then EJB is the simplest way to meet those requirements. Moving to a heterogeneous architecture wherein several disparate systems (some third party, some immature, some off the wall) are forced to work together where there is already a cohesive story that was already paid for with app server licensing fees is AN ASSES GAME.

    Those requirements would be (homer):

    GEN SPEC
    CONCURRENCY
    SCALABILITY

    EEJB's, when applied correctly, easily meet these requirements.

    Good luck to you if you're ever under the gun to meet these requirements in the extreme. Doh!

    Best to you Mr. Simpson.

    John C. Dale
  147. Luck has nothing to do with it...[ Go to top ]

    If your (or my) requirements include complexities for which J2EE and EJB was >design to manage, then EJB is the simplest way to meet those requirements.


    No, it's the simplest way that you understand how to meet those requirements. There are other solutions out there that are simpler. That's why the industry is moving toward AOP, Hibernate, and other technologies as alternatives to entity beans.

    >Moving to a heterogeneous architecture wherein several disparate systems (some >third party, some immature, some off the wall) are forced to work together >where there is already a cohesive story that was already paid for with app >server licensing fees is AN ASSES GAME.

    TopLink, is not a disparate system, unless you consider putting a jar file in your lib directory a disparate system.

    >Those requirements would be (homer):
    >
    >GEN SPEC
    >CONCURRENCY
    >SCALABILITY

    Again, nothing new here that entities provide that you can't easily get elsewhere.

    You're thinking a bit narrowly in terms of cost. Development costs and maintenance costs still exist no matter how much you spend on a J2EE app server with an EJB container.

    The cost for the additional time it takes to unit test the entity beans in a moderately sized EJB application by far exceeds the cost of TopLink licenses. BEA's own customer documentation used to tout a 40% efficiency gain in productivity when using TopLink. They've since pulled that advertising - but my guess is they pulled it only because Oracle now owns TopLink and they have a competing app server - not because the 40% efficiency gain is no longer valid.

    And for the record, TopLink was around long before entity beans. If anything is a cheap imitation, immature technology - well, I'll leave it at that.
  148. Luck has nothing to do with it...[ Go to top ]

    If your (or my) requirements include complexities for which J2EE and EJB was design to manage


    J2EE was designed to do many things. It does some very well. JMS is an example. JavaMail is an example. There are things that it was designed to do that it does not do as well as other potential solutions, such as ORM. EEJBs are a failed solution. The only real reason to use EJBs at all is to provide transaction management and remoting, and those can be easily handled with session beans. Session beans, by the way, when required, are another example of a good solution. But there's no reason to use Entity beans just because they're in the j2ee toolbox. There is nothing that entity beans can do that JDO or Hibernate behind a session bean facade couldn't, except screw up domain models, introduce unneeded complexity, and increase development costs.

    >>EEJB's, when applied correctly, easily meet these requirements.
    I don't doubt that they do. It's just that there are other solutions out there that do the same (in conjunction with other J2EE technologies) without the hassle, headache, and cost.

    As for under the gun, lets just say I know which of us could get a solution out the door quicker. One of us isn't burdened by unnecessary APIs. And one of us can actually test domain objects and persistence, which is extremely difficult to do with EEJBs, and potentially increase code quality.
  149. but alas, my activities are limited to things that continue to pay the bills.

    There are no absolutes, friend.

    I'm sure we could both agree that a speedy implementation depends much more upon the developer than on whatever new contemporary time saving framework is the flavor of the week.

    EEJBs are a failed solution...

    All I have to say to that is...

    <img src=http://arizona.rivals.com/images/smilies/roll.gif alt="roll" border=0>

    Oh man, I need a tissue. My eyes are watering.

    I think you're in the wrong line of work...comedy, definitely comedy.

    Best,

    John C. Dale
  150. One thing that I think gets lost in the religious war of EJBs versus non EJBs is some of the benefits that EJBs (most specifically SLSBs) offer beyond the container. (And I will purposely ignore scalability, because scalability is generally more related to how you use the technology then the technology itself.)

    For example, there are tools available today that will allow you to schedule batch jobs that invoke methods on EJBs (e.g. Flux http://www.simscomputing.com/ and Kronova http://www.kronova.com/index.html). If you were to implement your services as POJOs, it would be more difficult to integrate with these types of tools. (In fact, you would probably end up writing an EJB wrapper around whichever POJO services you wanted to expose.)

    Another great tool for testing is the Universal Test Client provided by IBM's WSAD tool. Basically, it allows you to interact with your EJBs in a generic way for testing purposes (it's not a substitute for writing test code, but sometimes it is helpful).

    Another great example is that many development environments and application servers offer tools to automatically expose your EJB interfaces as SOAP services (albeit with a bunch of caveats regarding the interfaces).

    Most appservers also provide some performance monitoring tools for EJBs out of the box, as opposed to having to build that type of intstrumentation into your code manually for POJO approaches.

    I guess what I'm saying is that because EJBs are a standard, it means that additional layers/tools can be built upon them without having to perform as much integration work as would be required by a Spring/POJO service approach. So in the long term "buy versus build" scenario, EJBs turn out to be the clear winner since there are more options to buy if you build with EJBs.

    All that being said, I think the Spring stuff is pretty cool and have found uses for it inside of EJBs. And for small applications or smaller companies, it arguably makes more sense to go with the lighter weight approach.
  151. EJB's are the worst part of J2EE[ Go to top ]

    Rod said:

     There have been a lot of people criticizing entity beans on TSS. Several books. And many projects have abandoned entity beans due to harsh experience. I could list quite a few (nothing to do with me btw), except that I can't really name names. Suffice to say that one of the cases I have information on is a big global bank, another is a big national bank in Europe, another is a major airline...
    >

    Vic:

    +1
    EJB's are realtively worse than any other aproach, and is a danger to J2EE, since even .NET is better than EJB.
    Thank J2EE community for the alternatives.
    To the (vocal minority?) that advoacates EJB, can you relate EJB to another aproachelse ( I use iBaits and now starting Hibrenate) and you will see the light.
    .V
    .V
  152. EJB's are the worst part of J2EE[ Go to top ]

    Vic:

    EJB's are realtively worse than any other aproach, and is a danger to J2EE, since even .NET is better than EJB.
    Thank J2EE community for the alternatives.
    To the (vocal minority?) that advoacates EJB, can you relate EJB to another aproachelse ( I use iBaits and now starting Hibrenate) and you will see the light.
    >>

    It depends. People just seem to have different ideas about the purpose of EJBs. If you use EJBs to distribute your enterprise app., then there is hardly a better alternative! Whether you need to distribute or not, is a different matter.

    You can make the EJBs a bad guy if you do not understand what they are for. Sure, people use them for whatever reason but many times the reasons are not right. Just do not rule out the EJBs as worthless for everything because they do have a very good place in J2EE when used right. Also, I am inclined to think that you are mixing up EJB concepts - should I read your message so that entity beans are bad, instead?
  153. My impressions...[ Go to top ]

    First, I don't think he's selling "his product". It's opensource, so if he's trying to propagate its use, there's nothing sinister in that. He doesn't make money from it.

    Using BMP and SQL in an entity bean is not easy to maintain. Based on my experience. Other solutions, like Hibernate and JDO, are much easier to maintain, and just as fast.

    The throughput advantage of Entity Beans is only apparent when dealing with a heavily distributed environment. For most applications, which don't need to deal with remoting, there is actually a performance hit, due to the overhead of unnecessary remoting. This is pretty common knowledge. That's why Sun created local interfaces, which made a complex API even more complex. And no, EJBs don't make it easy to reuse components. Not in my experience.

    EJBs make TERRIBLE domain objects. They are more tied to the EJB spec than they are to any domain model. A sophisticated domain model would allow for subclassing, for example, which EJBs do not. That's a pretty glaring omission.

    Spring aside, I think you need to read up on some of the discussion that's been going back and forth over the past few years about EJBs. Rod's not the first to criticize them, and he won't be the last.
  154. My impressions...[ Go to top ]

    I agree that Entity beans pretty much suck for most uses. Fortunately this is mostly common knowledge this day, so there's nothing new or shocking about such a statement.

    \Drew McAuliffe\
    First, I don't think he's selling "his product". It's opensource, so if he's trying to propagate its use, there's nothing sinister in that. He doesn't make money from it.
    \Drew McAuliffe\

    Consultants who write books and release open source are, IMHO, a special case seperate from other cases. Look back at the rash of OO methodology authors of the 90s. The purpose of writing those books wasn't really to raise knowledge, or to make money from the book. The real purpose is raise prestige and marketability of the individual (and consulting company if they have one), so they can command big bucks at lectures and even bigger bucks if you hire them to work on a project. There's no altruism here - it's enlightened self-interest to raise your visibility and thereby command significantly hire consulting rates e.g. a very vested economic interest. You might find that people who don't have a vested economic interest act rather differently.

         -Mike
  155. Dead on in regards to EJB[ Go to top ]

    Finally someone willing to say, "The emperor has no clothes!"

    Rod is dead on in his assessment of entity beans. Entity beans are a horrible way to implement a domain model in an object-oriented application. The additional time requirements they impose on a project for unit testing alone should be enough of a deterrent that projects would avoid the technology.

    Unfortunately, there are way too many developers writing procedural code in session beans that operates on dumb entity beans (no behavior, basically just data structures). Many of these developers adamantly support entity beans. It's difficult to have an intelligent conversation with them because they don't have a basic understanding of OO to use as a foundation or starting point.

    Just because you're using EJBs does not mean you're writing an OO application - even if you do have a ServiceLocator object in your system :)

    I'll be picking up a copy of Rod's book. We need more people educating developers on issues related to good design and the fact that an object is something that has behavior.
  156. Dead on in regards to EJB[ Go to top ]

    I'll be picking up a copy of Rod's book. We need more people educating developers on issues related to good design and the fact that an object is something that has behavior.


    I have to tell you that Rod's book is one of the best books on J2EE development currently. And goodness me, there are so many out there.

    Sandeep
  157. Dead on in regards to EJB[ Go to top ]

    Agreed. Regardless of how he comes across in the interview (I haven't watched it yet), the book is one of the better ones out there. Pros and cons of various competing solutions to numerous J2EE-related problems are given, and always in a fair light. Some highlights:
    -The discussion of web frameworks. It compares Struts, webwork, and Maverick, and shows a pretty good knowledge of what makes each tick.
    -The chapter on coding standards
    -The discussion of exception use (and the eternal battle between typed and untyped exceptions). Again, all sides are presented fairly, and he comes up with some pretty intelligent recommendations.
  158. Dead on in regards to EJB[ Go to top ]

    Unfortunately, there are way too many developers writing procedural code in session beans that operates on dumb entity beans (no behavior, basically just data structures). Many of these developers adamantly support entity beans. It's difficult to have an intelligent conversation with them because they don't have a basic understanding of OO to use as a foundation or starting point.

    >
    > Just because you're using EJBs does not mean you're writing an OO application - even if you do have a ServiceLocator object in your system :)
    >
    I found procedural code is a very good way for things like RPC, data access and messaging. I like java, it lets me to use procedural code :)
  159. "EJB" is design by resume[ Go to top ]

    http://www.jroller.com/page/prane
  160. Spring behind the facade[ Go to top ]

    Spring accommodates EJB's in a clever way. A Session Facade is a natural wrapper for domain logic using Spring. Session Beans can easily provide Spring with CMT and JNDI resource lookups. Spring allows for simpler and testable domain logic development outside the EJB container. Domain experts can code without knowing EJB's (but still have to obey EJB rules on i/o and concurrency). Then domain logic can be deployed freely into whatever EJB server you have to use.

    For those of us who are edging toward calling EJB's superfluous we are free to try and prove it by running the same domain logic sans EJB's.

    Another selling point for EJB's as Spring wrappers is that you're free to deploy domain logic stand alone, in a Servlet container, a JMS server, or as a component of a larger application.

    Criticism of the implementation of Spring and other IoC/AOP products shouldn't blind us to the beauty of the vision.

    Gary
  161. soap opera[ Go to top ]

    This is one of the dumbest threads I have ever seen on TSS.

    - Most of what Rod says in the interview is quite reasonable (ok, I violently disagree with his comments on messaging, but thats a matter of opinion, I suppose).

    - Spring is great!

    - Rod's book is very good, according to everyone I know who's actually read it.

    - Comments about accents reveal a lack of sophistication in the listener.

    - This stuff about "conflict of interest" is an absurd ad hominem that could equally easily be directed at anyone who is trying to innovate in the area of application infrastructure.

    - It is actually possible to have a civil debate about the merits and demerits of particular technology options without resorting to impugning other people's motives, qualifications, or to name calling. Mike Spille, you are a serial offendor in this respect, and you have turned quite a number of recent threads into pissing contests so please, either learn some manners or STFU.
  162. Should be believe him?[ Go to top ]

    Arguing against the person - glad you brought that out.

    "Lacks sophistication.."

    So, that is ad hominim too, right? Why even bring that up, or might the sophistication (and other personal attributes) have bearing on a cogent and/or valid response to a supposition?

    Hi Kettle, I'm pot.

    Doh! There I go again...I'm arguing against the person. Sorry. I guess that's just a result of the extrapolation and extraction of attributes of my own behavior that I am superimposing in the individuals around me (I forgot the label of that type of argument - not a fallacy of reasoning coincidentally).

    This stuff about "conflict of interest" is an absurd ad hominem that could equally easily be directed at anyone who is trying to innovate in the area of application infrastructure.

    Indeed...however, we are beyond the point of innovation. We are talking about endorsement here...an appeal to an authority on a matter of interest. The term 'conflict of interest' has been engrained through years of use in situations just like this.

    If only he hadn't bashed EEJB (a part of his argument) on his way to endorsing its substitute I'm sure the course of things would have been much different - less interesting, but nonetheless much different.

    The fact that such an enflamed debate is even occurring is testament to the validity of EEJB's as an implementation approach.

    We've present many arguments that arean't Homini-centric. Address those if you have time to read through the much more dynamic and interesting book we've just authored.

    Best,

    John C. Dale
  163. Should be believe him?[ Go to top ]

    If only he hadn't bashed EEJB (a part of his argument) on his way to endorsing its substitute I'm sure the course of things would have been much different - less interesting, but nonetheless much different.

    >
    > The fact that such an enflamed debate is even occurring is testament to the validity of EEJB's as an implementation approach.
    >

    You're the only one arguing for Entity beans. The fact that you're very vocal is not a measure of Entity bean's success.

    Jason
  164. You are a HOMER!!![ Go to top ]

    Count the number of posters in this forum.

    What percentage of all enterprise java bean users are represented here?

    I'm the ONLY one!?

    You are a homer.

    I'll just keep cranking out software that ACTUAL END USERS are benefitting from now, and they'll keep on benefitting from them.

    Did I mention you're a homer?

    What IS homer you ask? Someone who 1) can't see his feet in the shower or 2) someone who is completely blinded to the fact that he/she is doing something counter productive or illogical not because of stupidity, but because of ignorance.

    Have a good day.

    John C. Dale
  165. soap opera[ Go to top ]

    Thank you. Couldn't agree more. Lots of putting words into peoples' mouths and "mine is bigger" talk, and no one really seems to be saying anything worth remembering. There have been a lot of talks here in the past where I've learned something, even when I was the voice of dissent. This isn't one of them.
  166. soap opera[ Go to top ]

    Mike Spille, you are a serial offendor in this respect, and you have turned quite a number of recent threads into pissing contests so please, either learn some manners or STFU.

    STFU? Gavin, using language like that will make people thing you hang around marcf too much or that you've gone and joined the JBoss proje... oh wait... nevermind...

    :) j/k
  167. soap opera[ Go to top ]

    Mike Spille, you are a serial offendor in this respect, and you have turned quite a number of recent threads into pissing contests so please, either learn some manners or STFU.

    >
    > STFU? Gavin, using language like that will make people thing you hang around marcf too much or that you've gone and joined the JBoss proje... oh wait... nevermind...
    >
    > :) j/k

    LOL,

    Gavin BE-LONGS in JBoss Group. He is a natural. Young, brilliant, brash, got his project going. And we are teaching him some proper table manners. Man he speaketh the truth. JBoss Group is a cool place to be at if you are going to be blunting speaking the truth. People expect it from us :)
  168. soap opera[ Go to top ]

    \Gavin King\
    - Most of what Rod says in the interview is quite reasonable (ok, I violently disagree with his comments on messaging, but thats a matter of opinion, I suppose).
    \Gavin King\

    There are several reasonable bits, and several bits I disagree with. You "violently disagree" on messaging, I disagree on that and other points as well.
    So where's the problem here? Should we all just politely applaud and mutter "nice interview", or should we use a message forum to post real opinions?

    \Gavin King\
    - Spring is great!

    - Rod's book is very good, according to everyone I know who's actually read it.
    \Gavin King\

    Spring is certainly interesting, and as I said the book isn't bad (and as some may have guessed "not bad" coming from me means something slightly different than coming from others...).

    With that said, I also believe people on the sharp end of the stick in software have a responsibility to give the straight scoop, and to try to be balanced in their discussions. This is where you have to step beyond pure technology issues and talk about wider subjects. When the author of a framework says "And Spring has an AOP framework which enables it to provide a very good substitute for EJB that?s much lighter weight in many cases. Spring also provides a transaction abstraction", I think it's perfectly reasonable to point out there are downsides to this sort of "substitute" as well as upsides. We're not marketing people here, for the most part, we're software developers.

    \Gavin King\
    - Comments about accents reveal a lack of sophistication in the listener.
    \Gavin King\

    It's also purely irrelevant...

    \Gavin King\
    - This stuff about "conflict of interest" is an absurd ad hominem that could equally easily be directed at anyone who is trying to innovate in the area of application infrastructure.
    \Gavin King\

    Disclosing a person's interest in the thing he's pitching, and the prejudices behind their opinions helps people make an informed decision. As a trivial example - John Q. Developer saying "Weblogic rocks!" and giving several examples paints one picture if John Q. Developer has nothing to do with Weblogic. Quite another picture forms if you find out that John Q. Developer is gainfully employed by Weblogic.

    As I said - a trivial example, and I don't mean to imply that any kind of deep subterfuge is going here. But the underlying concept remains - in a complex world a statement "X...Y...Z" is meaningless without knowing the context and the originator of the statement. The only time it's not meaningless is if you're omniscient anyway and have complete information on the objective truth of the matter. I don't know about you, but I just don't have the time to achieve omniscience.

    \Gavin King\
    - It is actually possible to have a civil debate about the merits and demerits of particular technology options without resorting to impugning other people's motives, qualifications, or to name calling. Mike Spille, you are a serial offendor in this respect, and you have turned quite a number of recent threads into pissing contests so please, either learn some manners or STFU.
    \Gavin King\

    What you describe is a worthy goal - if we're all emotionless cyborgs.

    But I for one am based on pure carbon wetware, as I assume most TSS posters are, and as such passions and prejudices and little mini wars are part and parcel of the landscape. A great example of this is "learn some manners or shut the **** up".

    You might want to consider as well an interesting side effect of some of these pissing concepts - some people seem to contribute the most interesting and relevant information when their blood is boiling and they're saying what they really feel, and not censoring every thought in a misguided attempt at appearing "Professional". I've learned far more about Spring and JBoss and Hibernate from pissed off players On A Mission to Teach Me (or someone else) a Lesson than I have from polite meaningless professional exchanges.

    To put that another way - the only way to get really deep information from some people is to either be their best friend or to really piss 'em off. When dealing with such people, attempts at "civil debate" mostly result in people manipulating the "civilness" environment into never giving a straight answer to a straight question.

        -Mike
  169. Good article. Thanks for being brave enough to tell us what you're up to.
    Steve
  170. AOP, middleware[ Go to top ]

    Rickard Oberg
    November 29, 2001

    http://www.theserverside.com/home/thread.jsp?thread_id=10469

    "[...] btw, have I mentioned that AOP is cool? No?
     uhm.. it is.. you'll see.."


    Marc Fleury
    July 23, 2003

    http://www.theserverside.com/discussion/thread.jsp?thread_id=20514&noise=hide

    "AOP itself is great but what is interesting are the aspects
     built on top and middleware we build out of them. AOP for the
     beauty of it isn't really relevant to system designers. AOP for
     systems is nirvana though. [...] middleware aspects are AOP's
     killer app"


    Marc Fleury
    September 23, 2003

    http://www.theserverside.com/home/thread.jsp?thread_id=21595

    "Note that most framework of AOP DO NOT BOTHER WITH THE ASPECTS. They
     don't ship "aspects" they define frameworks for them (including JBossAOP),
     which is why we all talk about the "logging" aspects which btw may not be
     the best candidate (it is very contextual) but that is another discussion.
     THE CROWN JEWEL OF AOP in MIDDLEWARE are the aspects themselves.
     JBoss 4 ships aspects."

    Marc Fleury
    September 28, 2003

    http://www.theserverside.com/home/thread.jsp?thread_id=21595

    "Applicability of AOP. What kind of problems are solved with AOP?
     in my mind insertion of really orthogonal concerns in the flow.
     That is why middleware is so relevant as an AOP enabled framework.
     AOP for applications? I will doubt until proven wrong (not to say
     that I am right on that point). EXTENSION of user applications with
     AOP etc."


    Rod Johnson
    October 2003
    TheServerSide TechTalk interview
    http://www.theserverside.com/events/index.jsp

    "I think AOP is going to be very, very important. I think in the long term AOP
     is going to change the way we design applications. I think in the short to
     medium term, it’s going to have a significant effect on J2EE, primarily,
     as a replacement for EJB. As I’ve said, I think that EJB is a transitional
     solution to AOP middleware. I think AOP generalizes a lot of the ideas
     that we successfully applied in EJB, and makes them both more powerful,
     but eliminates a lot of the downsides of EJB. For example, declarative
     transaction management is one of the nicest features of EJB. But, in fact,
     we can implement this in a simple way using an AOP framework. So I think
     we’ll be hearing a lot more about AOP, both in the next one or two years
     as it becomes a popular replacement to EJB and in the next 5 to 10 years when
     it really changes the way we design applications."
  171. AOP, middleware[ Go to top ]

    Sean,

    One minor correction: the date of my interview was late June 2003. TSS chose to run it last week.

    Regards,
    Rod
  172. There was a time when developers commonly thought they had to use EJBs to create a Java application. Developers were complaining how difficult it is to program with Java because they had to use EJBs. That same mentality seems to linger around in the dark corners of Java developer community still. Doh!

    Most of the developers have stepped back to thinking that they have to seriously consider EJBs when creating a Java application. Should I use EJBs because they offer transactions, role-based security, and so on? The missing, and the most important question by far is: do we need to distribute? Developers commonly do not relate EJBs to distribution at all or it is some issue behind all the other reasons to use EJBs. Doh!

    I guess many developers have the right to think this way because EJBs have local interfaces. Great, I can use EJBs locally so I do not need to pay the penalty. Doh!

    EJBs are great for distribution. That is a big part of their job and has been from the beginning. The thinking even went so far that entity beans have remote interfaces. There is nothing local or warm fuzzy feeling of easyness associated with EJBs unless they are truely remote components. Trying to use EJBs in any other context is like fish trying to swim on dry land, out of its element.

    But wait a minute. Even then, you do not need EJBs unless you want robust enterprise features (all those transactions, security, ...). You can still use regular RMI stuff for all the trivial distribution needs. Why is raw RMI a bad choice suddenly? It can be far simpler than fiddling with EJB containers. I still use 'raw' RMI quite frequently when I need to distribute something.

    So, why use something like Spring? The problem is that your regular application can be far from simple if you need to glue together various frameworks from database stuff to web. All kinds of frameworks are available for free and they are very useful, but not everyone can put it together as well as Spring does. In my opinion, Spring lowers the hurdle quite a bit and maybe deters you from grasping for things like EJBs when you really do not need them. I think that EJBs are often used as a substitute for something that should be Spring instead.

    I am not an expert and I am guilty of doing all the bad things at least once. Rod has it together pretty well, I think. I am just not sure about those unchecked exceptions, yet :)
  173. I prefer to use standard J2EE container (servlet and EJB model) instead using another type of containers like Pico, Keel (using Avalon), Spring and Avalon in "business oriented applications" because using standard J2EE are:

    -> simple because you can learn it everywhere (a lot of good books, documentations),
    -> cheap (very good Open Source production EJB containers like JOnAS and JBoss) and
    -> easy to maintain (a lot of EJB developers available, slowly but surely)

    If you are using interface-based development strategy (just by
    adding simple Factory, EJBDelegate and DTO) you are already independent
    from the EJB technology itself, although sometimes I think that those
    independencies are useless because the points I already mentioned above. Adding framework dependency like Spring or Keel in your application means adding complexity and it will be difficult to find developers, who can easily understand and maintain your application.

    I prefer to use such frameworks like OSCore from OpenSymphony, which has some value adds to my EJB development or Jakarta Commons libraries, which add some missing utilities in my J2EE development. But not using new containers or independent frameworks. If you want to become really independent, then you will have to be independent of Java itself and I think, MDA/UML would be the way.

    IMO, we should always use standard J2EE container (servlet + EJB container) to write our business oriented applications at "client- and server-side". Also for "simple" or "complex" applications. You can distribute the same application easily both on client- and server-side. This becomes nowadays very cheap and affordable thanks to Open Source J2EE containers like JOnAS or JBoss.

    What we need is an integration of other Open Source libraries within our J2EE standard container and !NOT! another containers with their own component model style. Check this out:
    http://ejosa.sourceforge.net/ejosa-images/ejosa-template-process-matrix.jpg

    I think, the way of JOnAS and JBoss is the best way. J2EE standard container (servlet, EJB) and adding JDO, Hibernate, etc. within the container.

    Cheers,
    Lofi.
    http://www.openuss.org
  174. I wonder if this thread set a record...*[ Go to top ]

    ...
  175. OK, OK, I surrender![ Go to top ]

    I see I've gotten myself into a quagmire of my own making and verily gotten myself hoisted by my own petard. Frustration and too much caffeine has obviously pushed me over that invisible line somewhere.

    As such I've performed a mental reset, am changing theserverside.com to 127.0.0.1 in my hosts file, and will be firmly surfing in read-only mode for the foreseeable future. Many thanks to TSS for hoisting a pretty cool forum, and sincere apologies to the obvious many who have been just this side of mortally offended by some of my comments. Life's just too short, and the obvious and overwhelming hatred directed in my very specific direction has sent me a clear message that I'm doing more harm then good with my activity here.

    I do humbly request that you keep your cheers muted as I exit the building...

         -Mike
  176. Mike, you are weak!!![ Go to top ]

    ;o)
  177. Re: OK, OK, I surrender![ Go to top ]

    Hold on! Please stay.
  178. For those of you that support the use of entity beans for implementing a domain model I have a simple question for you.

    In many applications I've worked on, the dba's insist that there is a commitTimestamp attribute and a commitUser attribute on each database table.

    When you're using entity beans, how do you go about updating these attributes?

    Assume these are your constraints:
    *database rows should only be updated when the entity has actually changed, i.e., you can't simply update the timestamp and user attributes whenever ejbStore is called.
    *you have a complex domain model where entities can invoke methods on other entities that may cause changes to the internal state of entities in your domain.

    I'm not sure about all the O/R mappers, but in TopLink this is relatively easy. TopLink throws events whenever an object is about to be committed to the database. TopLink is smart enough to only fire these events when the object has been changed. Domain objects can register to receive these events and update the timestamp and user appropriately at commit time.

    How do you do this with entity beans? Where is this basic type of functionality covered in the EJB spec?
  179. I don't mean to seem flippant, but whenever you have to modify data in a particular table, issue an update statement and populate into it the timestamp.

    I don't like having the constraint that I have one entity bean per table (some containers enforce this via CMP). I always use BMP. On store, I perform some logic and only update the data that has changed. If nothing has changed, then the call to the EJBStore just returns. If something changes, then I update the database appropriately by writing a helper method in the BeanImpl.

    This works really well, is easy to maintain, and performs really well.

    If you are stuck with CMP, and/or have no control over EJBStore, then I can definitely see your predicament.

    Tell me what you think of what I've written so far, and we can take it from there. I would be happy to help you work through it offline. Just drop me a line.

    Best,

    John C. Dale
  180. Thanks for the reply, John.

    Yes, we are stuck with CMP.

    Thanks for you offer of help. We've already got a solution worked out for our problem. However, it's not pretty. Basically, we have to manage our own dirty flag on the entity beans, compare values of attributes before actually calling a "set" method, update the dirty flag when we know we're changing values, and then call setUser and setTimestamp during ejbStore - but only if the dirty flag is true.

    I really just wanted to stress the point that entity beans have some inherent weaknesses that require you to jump through hoops if you try to implement a domain model with entity beans.

    Sounds like you always use BMP. I'm sure that works well for you and I'm sure you've got it down. However, it also sounds like you're doing quite a bit in your own code that's well beyond what's covered in the spec. For me, there's not much point in going down the entity bean path unless I can use CMP. Why reinvent the wheel? It sounds like you've written a bunch of code that does the things already handled by TopLink. If I'm going to use BMP I might as well write my own persistence layer or use an O/R mapping tool and be able to use basic OO features like inheritance.

    To further stress the point, one of the arguments raised by others here is that EJB is a standard that many developers will be familiar with as opposed to having to learn some "proprietary" third party code. If you're doing everything in BMP I don't see how that's any different from third party code. You're doing things outside the spec that anyone coming on to one of your projects will have to learn.

    I am not anti-EJB although it may seem like that. I think a great solution (not necessarily for every app) is to use Session beans talking to POJOs as advocate by Fowler and others. That way, you can take advantage of all the transaction, security, etc. capabilities of EJBs and use whatever tool you want for persistence. I worked on a couple Smalltalk/CORBA applications. EJB is certainly easier to implement than CORBA but everything we were doing could be handled by session beans.

    My main problem is with people in the industry perpetuating the idea that CMP entity beans are well suited for building domain models. This may change in the future, but for now, CMP is not the way to go. Sounds like we at least agree on that.
  181. "We've already got a solution worked out for our problem. However, it's not pretty. Basically, we have to manage our own dirty flag on the entity beans, compare values of attributes before actually calling a "set" method, update the dirty flag when we know we're changing values, and then call setUser and setTimestamp during ejbStore - but only if the dirty flag is true."

    Sounds like a prime candidate for use of AOP, doing all the checking of attributes and getting/setting of dirty-flags in one aspect instead of scattered throughout the code, have you considered that? Would probably make it a lot less ugly while keeping the core idea of the work-around intact.
  182. I guess my point would be - why not make an improvement to the entity bean framework (in progress) as opposed to scrapping it altogether?

    There is a lot of code out there written and running great using EEJBs. Those customers will gladly take a migration/upgrade path to something that solves the same problems, is an approved spec, and that is an enhancement in some way.

    I need a distributed cache. This is the only way to do INTENSE security without the system falling to its knees. Entity Beans are perfect for this.

    I like the freedom to move around when implementing entities. CMP is just another cumbersom O/R mapper that requires just as much work as writing the JDBC O/R code myself. I've gotten quite good at it, actually. The difficult part is understanding and authoring a good data model (a severely negelected area in our discipline, if you ask me).

    Have you tried a unit of work pattern, i.e., as you make updates to the Bean instance, register 'update events' with the bean. Then, on store, call the update events - oh wait, I forgot you were using CMP ;o)

    At any rate, as long as your users are happy, you should be happy. OT - my users are happiest when the thing ZIPS.

    Cheers,

    John C. Dale
  183. Dion:
    For me, there's not much point in going down the entity bean path unless I can use CMP.

    Totally agree here.


    Thanks for you offer of help. We've already got a solution worked out for our problem. However, it's not pretty. Basically, we have to manage our own dirty flag on the entity beans, compare values of attributes before actually calling a "set" method, update the dirty flag when we know we're changing values, and then call setUser and setTimestamp during ejbStore - but only if the dirty flag is true.

    Really? You must be using EJB 1.1 then, correct?

    Because any decent CMP 2.0 container will manage dirty flags for you (WLS does).

    --
    Cedric
  184. RE: Cedric[ Go to top ]

    Hey Cedric,

    I hope you saw my response to your question through all of this noise...

    Jason
  185. Cedric,

    Actually, we are using WLS and 2.0 CMP beans.

    My understanding is that anytime a "set" method is called the bean's state is marked as dirty whether or not the value of the parameter passed in on the "set" method is equal to the current value of the attribute or not.

    Ideally, we should be able to call set methods on an entity bean and have the entity manage its internal state so that its internal dirty flag only gets set to true if the internal state changes as the result of invoking "set" methods. Is this the way WLS works?

    Also, my understanding is that in WLS the dirty flag is not accessible by client code. So, even if WLS is managing the dirty flag as described above, there's no way for us to query the entity to determine if we should update a commitTimestamp or commitUser attribute.

    Please correct me if I'm wrong and let me know if you'd like to take this outside of this forum.

    Thanks

    Dion
  186. Has this thread broken any records, yet? *[ Go to top ]

    ...