Opinion: You Call That An Elephant?

Discussions

News: Opinion: You Call That An Elephant?

  1. Opinion: You Call That An Elephant? (31 messages)

    Mike Spille critiques Bruce Tate's article 'Don't Make me Eat the Elephant Again', which likens his experiences with EJB to an elephant hunt. Spille asks that J2EE not be judged in its entirety due to the failure of entity beans. He also thinks the move towards a POJO-esque EJB 3 spec 'has all the makings of an epic disaster'.
    "I don't think J2EE is the be-all, end-all. Unlike some, I don't take the "elephant" whole - I recognize that J2EE consists mostly of pluggable components, and (gasp!) I can choose what components I want to use and what ones aren't suitable for me. I think where Bruce fundamentally errs is that he feels to need, and teach, and test _every_ technology that comes down the pike - an attitude I've never really understood. Where I come from, I don't pick a suite of technologies and then hunt for a problem that fits it. Rather, I study the problem space and come up with the solution that fits it."
    Read You Call That An Elephant?

    Threaded Messages (31)

  2. And I ate: CMP, MDB, JNDI. And life was a little better, especially on the persistence front.

    "but ultimately we find him trying to convince us that MDB's, and JNDI, and stateless session beans are horrors that have been unleashed upon us witless Java developers."


    Didn't Bruce say life got better after those technologies? He also goes on to say with XDoclet he didn't have to create all the necessary files himself. I think it's important to think about that EJB's complexity is for a reason. Building a PDA is a bit more complex than building a datebook/addressbook, because the PDA has more functionality. If you need a (single) simple web application, EJB may not be for you. However for the bigger elephants it might be a choice to consider.


    Hunting elephants may or may not be easy, but it will always be time consuming.
  3. you have to try new stuff[ Go to top ]

    "I think where Bruce fundamentally errs is that he feels to need, and teach, and test _every_ technology that comes down the pike - an attitude I've never really understood. "

    But if you never try new stuff, how do you find out if it's any good? I think it's great the someone is out there kicking the tires on the latest models and writing about it.

    We need more folks out there to fight their way through thoughleader induced reality distorition fields to see whether or not new technologies really do live up to all the lip service they get.
  4. you have to try new stuff[ Go to top ]

    I agree. You have to do enough research to make an educated decision, but ultimately, any new technique or technology needs to be tried to determine if it is good or bad.

    I've learned quite a bit from following The Server Side, evaluating a given solution and then, *if* I think it fits my issue, trying it. Sometimes it works out well and makes its way into my staple of solutions and sometimes they don't.

    But I always learn...
  5. If it ain't broke don't fix it[ Go to top ]

    I've found Bruce Tate to be a great technical other. I recently read his book from O'reilly - Better, Faster, Lighter Java. Great stuff.

    As for Mike Spille, 'if aint broke don't fix it'. Of course I'm being sarcastic.
  6. I agree to most of what Mike says."Do POJO persistence as a separate and independent component service" and leave EJB 2.1 as it is more or less, for legacy purposes. But that will not solve the main problem which is that it is not fun anymore. I remember when you jumped out of the bed at 5.30 in the morning to get directly to the keyboard just for the fun of new great tools. First there was C++ then Powerbuilder/Visual Basic, what a joy! (not for the language but for the environment), and then come Java! Suddenly creating COM components was a breeze.

    And then come the Sun lawsuit, and since that nothing have been really fun anymore, not like in the old days when you always could look forward to some new and exciting technology. When I refused to eat the elephant my Java period was soon over. But no good alternatives showed up.

    Shall I have to wait 3 years before building rich clients with Longhorn Aero Glass, XAML and Clickonce deployment? Is there nothing else now?
    Wherever I look, I see nothing.

    Go into ide like the bear is the only viable option.

    Regards
    Rolf Tollerud
  7. Hi Rolf,

    <rolf>
    I remember when you jumped out of the bed at 5.30 in the morning to get directly to the keyboard just for the fun of new great tools. First there was C++ then Powerbuilder/Visual Basic, what a joy! (not for the language but for the environment), and then come Java! Suddenly creating COM components was a breeze.
    </rolf>

    Yeah, I still remember the good old time with IBM PC 8086 with writting those TSR
    applications (Terminate and Stay Resident, like SideKick from Borland). And also the time as the first Borland Delphi came into the market, what a cool stuff!

    If you want to get the same feeling, go for AndroMDA (MDA). It's really cool. You can build your own cartridges (Java, C#, J2EE, .NET, whatsoever you want to build) and then use those cartridges to build your application. I get the same fun feeling just like as I used Borland Delphi for the first time! It's maybe a bit complicated for the first time but the idea of doing your own "language" to define the problem is gorgeous! Yeah, the feeling of going into each methods, attributes in your model and generate or transform into something else is undefinable! You'll have fun of it, I'm sure!

    And one day you will say, gee folks, that all the discussions about EJB, JDO, POJO or Java vs. C++ vs. C# in TSS was just non-sense ;-) I build my own cartridge and do whatever I want. Just I said, eat slephant, chicken, cat, dog, whatever ;-)

    I'm learning AndroMDA 3.x at the moment and I love it! You build your own cartridges with other cartridge from AndroMDA (eat your own dog food!). Amazing!

    Regards,
    Lofi.
    http://ejosa.sourceforge.net
  8. Take entity beans out of J2EE. Take stateful session bean out of J2EE. Keep the stateless session bean. But remind users to use it only when situation requires. Like my work place they use it as a wrapper around JDBC code, namely to function like entity beans, which i don't think is the appropriate place to use it. Keep JNDI and JMS around and MDB around.
  9. Take entity beans out of J2EE. Take stateful session bean out of J2EE. Keep the stateless session bean. But remind users to use it only when situation requires. Like my work place they use it as a wrapper around JDBC code, namely to function like entity beans, which i don't think is the appropriate place to use it. Keep JNDI and JMS around and MDB around.
    The technology has to be chosen to fit the requirement, not vice versa, as it seems to be done at your work place. Must have been thrown in by some developer who wanted to jazz up his resume with buzzwords.
    Just because its there in J2EE doesn't mean it should be used.
    There are scenarios where Entity EJBs & Statefull EJBs are just the right thing and hence should and will remain part of J2EE.
  10. Take entity beans out of J2EE. Take stateful session bean out of J2EE.
    Why?

    I think this is very short sighted (or should I say "narrow sighted"?). If you don't need entity beans, don't use them. Same for stateful session beans. Your demand is like requesting to remove the java.text package from the Java 2 SDK just because you never used it. Other people might actually want to work with it.

    I never was able to understand people who believe that just because two things are defined in the same specification (like session beans and entity beans), they all have to be used at the same time. The spec just states what services are provided, but does not mandate you to use them. For instance, it was perfectly feasible to use JDO out of session beans in March 2002 (when the JDO 1.0 spec appeared), but I don't have the tiniest of ideas why therefore anyone should want to remove entity beans from the EJB spec.

    Just my 2 cents,
    Lars
  11. Lightweight container[ Go to top ]

    Well, you do not need to use all things, that are in specification, but when you are working on EJB container, you need to add ALL things that are in specification to the container. So removing entity beans out of specification results in smaller, faster container with much smaller development cycle.
  12. Lightweight container[ Go to top ]

    Well, you do not need to use all things, that are in specification, but when you are working on EJB container, you need to add ALL things that are in specification to the container. So removing entity beans out of specification results in smaller, faster container with much smaller development cycle.
    Let me propose an analogy: Street lanes have a standard width, which is specified wide enough that not only compact cars, but SUVs and even trucks fit into them. Now, imagine someone would propose to specify the lanes to have a width that would be just enough for the compact cars -- after all, this way a given highway with 4 lanes so far could be re-marked and now have six lanes, thus having a higher throughput.

    Now, not everyone wants to drive a compact car, and if you have goods to transport, a truck might be mandatory. The same with EJB vs. lightweight containers: If you really need clustering, transactional control and remote accessibility via RMI, you should consider using EJB. In any case, it should be possible for EJB and lightweight containers to live happily side by side. If you are developing an EJB container and the spec is too complex in your point of view, why not develop a lightweight container instead?

    What might be a good idea is a specification for the services a "standard" IoC container should provide, but I think it is a bit early for this, and alone getting the Spring/Pico/Avalon faction to agree on a standard way of injection will be very difficult, if not impossible.

    Cheers,
    Lars
  13. Lightweight container[ Go to top ]

    Let me propose an analogy: Street lanes have a standard width, which is specified wide enough that not only compact cars, but SUVs and even trucks fit into them. Now, imagine someone would propose to specify the lanes to have a width that would be just enough for the compact cars -- after all, this way a given highway with 4 lanes so far could be re-marked and now have six lanes, thus having a higher throughput.Now, not everyone wants to drive a compact car, and if you have goods to transport, a truck might be mandatory.
    Good comparison.
    Just b'cos all those entity beans are there, you dont need to use them. If you are concerned about pricing, many J2EE servers provide cut down version. (This is my take anyway).

    And abt. EJB3 POJO, i hope still there would be support for legacy applications. I have no problem in using POJO or whatever as long as it fits into my problem space.
  14. Lightweight container[ Go to top ]

    ...getting the Spring/Pico/Avalon faction to agree on a standard way of injection will be very difficult, if not impossible
    I've talked a lot to the Pico guys, and we agree that both Constructor and Setter Injection should be supported by a good IoC container. Both mechanisms rely on pure Java language features.
  15. Lightweight container[ Go to top ]

    ...getting the Spring/Pico/Avalon faction to agree on a standard way of injection will be very difficult, if not impossible
    I've talked a lot to the Pico guys, and we agree that both Constructor and Setter Injection should be supported by a good IoC container. Both mechanisms rely on pure Java language features.
    Any thoughts, then, on what a specification of a "standard" IoC container should include? Any services that a IoC container should provide, or best practices it should definitely follow? Normally, I am against standardizing, as it constricts free thinking and innovation, and misleads people to think in boxes instead (as demonstrated earlier on this thread). But if one could define a least common denominator, this might ease the migration of a project from one IoC container to the other, for example in a scenario where a project was started with Pico, but as it grows develops the demand to use the services provided by Spring.

    Cheers,
    Lars
  16. Lightweight container[ Go to top ]

    Any thoughts, then, on what a specification of a "standard" IoC container should include? Any services that a IoC container should provide, or best practices it should definitely follow?
    I think that services are a separate issue from IoC. PicoContainer is an IoC container. Spring includes an IoC container that doesn't depend on any other Spring services. Nanocontainer and other value-adds around Pico aim to provide services. Keeping core IoC distinct from services is a good idea IMO.

    I see services in an ideal world as being supplied by aspect libraries that can deliver services to POJOs. Ideally there should be minimal constraints on those POJOs, meaning that there's less service-specific gunk to standardize. Spring's transaction interceptor is a good example of what can be achieved here. Bob Lee is using it in his DynAOP framework, as it's written to AOP Alliance interfaces, not Spring AOP interfaces. It works in all application servers, with JTA or other transaction strategies. And it's possible to drive rollback declaratively by specifying "rollback rules" for exceptions, checked or otherwise. Thus it's rare to need to import Spring APIs to drive it.

    Declarative transaction management is definitely a key service. The IoC container should also be able to integrate with its environment: for example, providing a JNDI lookup service so that an object can either be obtained by JNDI or configured by the IoC container itself, but where that object comes from is concealed from other objects.

    I would love to see such aspects come from different providers. This is a powerful form of reuse that should benefit the whole community.

    So I think an IoC container must be able to integrate with AOP solution(s), to enable this. It's not as simple as using an IoC container along with an AOP solution; it must be possible to use IoC to configure aspects etc.

    In the case of Spring, we provide our own proxy-based AOP framework, and will be offering strong integration with AspectJ in Spring 1.1.

    Rgds
    Rod
  17. Lightweight container[ Go to top ]

    Constructor and Setter Injection should be supported by a good IoC container. Both mechanisms rely on pure Java language features.
    I'm studying Spring right now. I'm honestly trying to work all of this out. I have to say I find the above statement misleading in this sense...It's all just JavaBean spec code, -but- The code you write for Spring has many dependencies and assumptions buit in, this may appear simplistic, but I'm interested in reactions.

    -It requires the presence of an XML config file specific to container to supply dependencies. It also requires a setter method to be implemented in the bean code. The presence of these methods or constructors may follow the JavaBeans spec, but would otherwise be unnecessary in the implementing class if it were pure. The XML files and additional bean methods are both 'cruft' required by an IoC container. It may be asthetically more pleasing, but what has this gotten me? I'm still going to run an app server, so why do I want to hide that fact from myself? I already had gone on on previous threads on why I'm running app servers, so I'll not revisit that.

    -The container supplies many marker interfaces specific to the Spring container which may be used to control the life cycle or other behavior of your beans. Again, they follow the bean spec, but these are not just JavaBeans, they are IoC container beans. I've achieved a bunch of extra libraries to deploy my classes with!

    -Beans may very well be built with assumptions on the context of which they will run in the IoC container...ie is it a singleton? Is it listening for container events as a spring listener? Is the bean subject to a particular life cycle? Purity in and of itself is laudable, but you have to balance out a lot of things. I find I'd be writing a lot of IoC flavored code, that's not pure either!

    -If I run spring now, to get bonus features and container-like behavior I desire, I have to swallow Hibernate and AOP Alliance. I can write spring 'wrappers' for other o/r mappers, I understand that, but now I feel like I'm having to 'write the elephant' or wait for somebody to do it for me. I also have to go thru Spring factories and methods to bury the fact that I might be using underlying J2EE features such as JNDI or connection pooling from my J2EE container. Is this really a 'Good Thing'? As an example, we have a connection pooling mechanisms that have been very stable, and we can monitor and configure them. I can either ditch them for something else or add more steps to abstract out those lookups...I am asking myself why I would go to the trouble?

    I also wish the word 'container' was not thrown around so much in regards to IoC...container implies to me many services, including things like messaging implementations and transaction coordinators. This is leading to conversations that compare IoC directly to J2EE with silly statements like 'my container is only 90K, I can load that in my palm'.

    Anyway, this isn't Spring bashing...we all need to strive to be pro's, I'm trying to work out what the value proposition is, I feel like I'm getting hyped about this stuff as much as if I was talking to a corporate sales-weasel.

    The most difficult thing I've done in quite some time on my J2EE servers has been trying to build and debug a problem between and XML parser and FOP, no container, no J2EE even, just reams of Java Code I didn't design or write to wade thru. A bunch of beans...hard as hell...why is this stuff going to be any different?

    Again, I'm looking for people to disagree and tell me where I'm wrong, this is a resource to me.

    Cheers,
    Mike C
  18. Lightweight container[ Go to top ]

    Mike,

    Phew, a lot of points to respond to :-)
    The code you write for Spring has many dependencies and assumptions buit in, this may appear simplistic, but I'm interested in reactions.-It requires the presence of an XML config file specific to container to supply dependencies.
    Such code does *not* require an XML config file. No matter whether it uses setters or constructors, it can easily be wired programmatically, for example in test code but also in production code. All you need to is "new MyComponent()" and some setter invocations (in the case of a JavaBean).

    The main point of an IoC-style component is that it doesn't look up its dependencies itself but rather expects to receive those dependencies from the outside (be it Spring or manual code). This makes the component usable in virtually any environment: with and without JNDI, etc.

    Furthermore, even when running your component in a Spring BeanFactory, note that the XML bean definition format is just one option (though the most popular one). Spring also provides BeanFactory implementations for properties files and programmatic registration via BeanDefinition objects.
    It also requires a setter method to be implemented in the bean code. The presence of these methods or constructors may follow the JavaBeans spec, but would otherwise be unnecessary in the implementing class if it were pure. The XML files and additional bean methods are both 'cruft' required by an IoC container.
    What does "pure" mean here? A component that looks up its dependencies via JNDI? If your component expects dependencies from the outside rather than looking them up itself (which does not tie it to a container, see above), there needs to be some way to actually pass those dependencies in - be it setters or constructor arguments.
    It may be asthetically more pleasing, but what has this gotten me? I'm still going to run an app server, so why do I want to hide that fact from myself?
    To be able to reuse your components outside an app server, for example in a test environment or standalone application. If your DAO looks up its DataSource via JNDI, it is effectively tied to a J2EE environment. If it expects the DataSource as dependency from the outside, the component can be used with and without JNDI.
    The container supplies many marker interfaces specific to the Spring container which may be used to control the life cycle or other behavior of your beans. Again, they follow the bean spec, but these are not just JavaBeans, they are IoC container beans.
    Those marker interfaces are just an option, and we deemphasize them as far as possible. For typical scenarios, you shouldn't need any of them. For example, a Spring bean definition allows to specify a declarative "init-method" and "destroy-method" - no need to implement interfaces for those.
    Beans may very well be built with assumptions on the context of which they will run in the IoC container...ie is it a singleton? Is it listening for container events as a spring listener? Is the bean subject to a particular life cycle?
    Sure every bean has some usage assumptions. But whether it is thread-safe or not (i.e. a singleton or not) is not specific to an IoC environment. Init and destroy methods are also a rather general concept. And container events are rarely used, BTW - no need in typical scenarios.
    If I run spring now, to get bonus features and container-like behavior I desire, I have to swallow Hibernate and AOP Alliance. I can write spring 'wrappers' for other o/r mappers, I understand that, but now I feel like I'm having to 'write the elephant' or wait for somebody to do it for me.
    You do by no means have to swallow Hibernate. Spring ships with out-of-the-box support for JDBC, Hibernate, JDO and iBATIS SQL Maps. Spring 1.1 improves significantly on the JDO support, BTW. Note that Spring mainly provides resource and transaction management: It does not try to abstract the underlying tool - you'll still work with the concepts of the chosen tool.

    And writing integration for a further persistence tool is by no means an "elephant". If you just want the tool to participate in JTA transactions and look its resource factory from JDNI, you can use it just like you would in a plain J2EE environment: Code a DAO with a JNDI lookup, custom resource handling, and custom exception conversion.

    Note that you can use any API in any fashion you want within a Spring-managed bean, doing manual JNDI lookups etc! Spring does not restrict you in any way in that respect: Spring's pre-built integrations just make things easier than plain usage of the tool would be.
    I also have to go thru Spring factories and methods to bury the fact that I might be using underlying J2EE features such as JNDI or connection pooling from my J2EE container. Is this really a 'Good Thing'?
    As I outlined above, the main point is to not tie your application components to the environment. If you want to work with a JNDI DataSource, this is absolutely straightforward - just do not put the JNDI lookup into your DAO but rather in the code that configures your DAO (for example, a Spring bean definition).
    I also wish the word 'container' was not thrown around so much in regards to IoC...container implies to me many services, including things like messaging implementations and transaction coordinators.
    That's what people are used to from J2EE. However, "container" does by no means imply a full J2EE server: Look at the terms "servlet container" and "EJB container" which just refer to the particular solution rather than the entire J2EE server. An IoC container basically provides configuration and lifecycle for POJOs: more or less like a servlet container, just for POJOs.

    I hope I've been able to clarify a few points...

    Juergen
  19. Lightweight container[ Go to top ]

    I hope I've been able to clarify a few points...Juergen
    Yes you have. I see things I did not consider before, and this makes me more interested in the concepts. I truly appreciate your effort!

    Regards,
    Mike C
  20. Lightweight container and JBoss[ Go to top ]

    Well, you do not need to use all things, that are in specification, but when you are working on EJB container, you need to add ALL things that are in specification to the container. So removing entity beans out of specification results in smaller, faster container with much smaller development cycle.
    Lightweight containers aren't so lightweight after you've added a TM, messaging, Hibernate, Tomcat, Struts/Webworks/etc., connection pooling, clustering. All the stuff you need for any non-trivial application.

    We've tried our best to componentize JBoss so that you can easily remove components you don't want/need simply by deleting archives from the deploy/ directory and/or removing jar files.

    <shameless-plug>
    JBoss is built on a lightweight JMX-based container. Provides dependency injection, lifecycle (create/start/stop/destroy), resolving of lifecycle dependencies (components wait for one another in lifecycle), remoteness, management (SNMP, generic GUI, graphing, snapshot recording, monitoring, alerts), as well as classloading domains if you need to run multiple versions of the same app within it. As well as hotdeployment.

    We also have an archive abstraction so that you can plug in your own component types. These are called our abstract deployers. We have written deployers for EJB, J2EE, JCA, WARS, Hibernate, AOP, Bean shell, and Service Archives (our JMX archive format). It is pretty easy to extend, write, and plug-in your own. Deployers automatically get hooked into lifecycle, hotdeployment, and classloading.

    This has been used in production since our JBoss 3.0 version back in 2002.
    </shameless-plug>
  21. Entity beans is one of the features that is provided by EJB. I have found it to be useful in several circumstances and not so useful in some. However, discrediting EJB because somebody does not like entity beans is not fair, as it is one of the features of EJB that you do not have to use if it does not solve your problem.

    Also, I think EJB3 is going in the right direction in trying to provide a fully functional ORM persistence layer like Hibernate. Please read the following link for more info on EJB3 by Gavin King:

    http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/05/07
  22. The problem is that the solutions promised by stateful session beans and entity beans ARE the problem we need solved. It's just that they don't live up to their promise. Instead, people are using stateless beans as transient persistence objects, and realizing that there is zero advantage to using an EJB container for stateless objects. What we need are lightweight stateful objects with persistence and locking and search and rollback capabilities. And it'd be nice if they were scalable.
  23. Aaron: What we need are lightweight stateful objects with persistence and locking and search and rollback capabilities. And it'd be nice if they were scalable.

    You're not the only one who feels that way ;-)

    (However, there are no J2EE standards for that type of functionality.)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  24. Backwards-compatibility bad? Why?[ Go to top ]

    In Mike's article he says:
    EJB 3's POJOesque solution looks like it will be a real nightmare, particularly when you consider backwards compatible to "legacy" entity beans.
    ...trying to re-write entity beans yet again (with the added bugaboo of trying to be backwards compatible with old entity beans as well).
    Um, why is it bad to be backwards-compatible with 2.1 entity beans? (Actually I prefer to think of it as 2.1 being upward-compatible with the 3.0 model, but whatever.) What if you have an existing 2.1 application where you want to start using 3.0 POJO entity beans in some places? What if you have a 2.1 bean and a 3.0 POJO bean that are mapped to the same table (in an O/R scenario) and select the same row? It seems you'd want there to be some commonality between the two resulting objects.... Having the two flavors of entities be compatible and intermixable is needed to _avoid_ problems (I won't call it an "epic disaster", but desirable to avoid). Actually they really shouldn't even be thought of as two kinds of entities, but rather the 3.0 POJOs are merely a alternate _view_ of the 2.1-style entities, where the developer can directly operate on the entity bean instance rather than having it always managed by the container. And by being able to obtain the EB instance directly, it can then be used as a data transfer object, etc. which was one of the main complaints about the 2.x beans.

    Randy Schnier
  25. Mike, the new POJO-based model of EJB3 is absolutely built from scratch with no backward compatibility in mind. None.
     
    Backward compatibility simply means that
     
    - EJB containers still need to support the EJB2 programming model (which I believe is a necessity since it will allow users to progressively migrate their applications to EJB3).

    - All the EJB QL enhancements will be backported to EJB2.
     
    That's all.

    With that in mind, I'd be curious to hear in more details why you think EJB3 is headed in the wrong direction.

    --
    Cedric
  26. I especially love that sentence: "Perhaps I am some sort of super-genius, but I've never found JNDI or JMS or stateless session beans very difficult to understand or program to.".

    Should that mean that understanding JNDI makes a good excuse to use it? It makes it a nice thing? Or constructor/setter injection looks like rocket science for you, or it would just count as "extreme lightweight"?

    To recall a Pearl Jam song, "It's evolution, baby". And lightweight technologies coming don't really care how fast you accept them, regardless how much of an enterprise developer you are.
  27. I seem to recall that Mike Spille asked TheServerSide and TMC to refrain from linking to his blog.
  28. i thought so too[ Go to top ]

    I seem to recall that Mike Spille asked TheServerSide and TMC to refrain from linking to his blog.
    I thought so too.
  29. Opinion: You Call That An Elephant?[ Go to top ]

    Perhaps I am some sort of super-genius, but I've never found JNDI or JMS or stateless session beans very difficult to understand or program to.
    I'm even smarter ;-)), because I use and like to use even entity EJBs as well. With a bit of sagacity of couse.

    Best,
    --
    Mike
  30. Mike, you missed it.[ Go to top ]

    I'm not saying any of the following:

    - EJB are wrong for everyone
    - J2EE is evil
    - Entity beans are the only problem
    - JNDI, by itself, is hard (maybe harder and heavier than it needs to be...)
    - you should adopt a technology without a problem

    In fact, I'm saying

    - EJB are wrong for me, and others like me
    - J2EE is better without EJB
    - Entity beans are only a part of the problem (don't just gloss over testability)
    - When taken all together, EJB is harder than it needs to be
    - There are better alternatives for most problems


    Then, I show how EJB3 can be improved by taking some important steps. You agree with the persistence and layering parts of the discussion. In short, I may be wrong, but I don't make many of the mistakes that you say that I do.

    Now, I get to take a shot at a gross characterization.

    http://weblogs.java.net/pub/wlg/1461
  31. Gross Characterization[ Go to top ]

    Now, I get to take a shot at a gross characterization.
    You forgot one tribe: Those that can distinguish between an elephant and a chicken and know at what time to hunt which of the two beasts. They will hunt the elephant when preparing to throw a party for the whole village, but normally hunt chicken for a dinner for two.

    I, for one, think that any healthy diet has to be well-balanced. :-)

    Cheers,
    Lars
  32. Good post...[ Go to top ]

    Now, I get to take a shot at a gross characterization.
    You forgot one tribe: Those that can distinguish between an elephant and a chicken and know at what time to hunt which of the two beasts. They will hunt the elephant when preparing to throw a party for the whole village, but normally hunt chicken for a dinner for two.
    This cuts right to the heart of the matter. Cutting across tribes is in fact a very good idea.

    But there's problem with EJB, and technologies like them. From the perspective of a lead architect, independent, or small-team developer, the hunt can easily consume most of your time and resources, leaving very little time to communicate with other tribes. If you want to really know the elephant, and you need to because it's a dangerous beast, the hunt can consume you. It's a noble goal, but one that's proven to be above me.

    So I left out the idea that you can cut across tribes for three reasons. Here's the first:
    They may talk about hunting other game, but they will always come back to the elephant.
    Elephant warriors don't usually hunt other game. It's usually beneath them. And happy hunters can adapt. After all, it all tastes like chicken. They use whatever's in front of them...

    From the perspective of the chicken hunters, most of them left the elephant for a very good reason. It didn't work for them.