Home

News: Opinion: Don't Make me Eat the Elephant Again

  1. Bruce Tate has written another opinion piece on EJB 3. He discusses the history that lead us to the elephant (EJB), and how he wants to hunt in the future. The topics of persistence (of course), metadata, JDK 1.5, are all mentioned.

    Introduction
    When I got an early glimpse of the EJB3 directions from the ServerSide conference and from the Colorado Software Symposium, I was tremendously excited. I've since tempered my enthusiasm, but it's been difficult to put those intangible reservations into words. In this article, I attempt to put some of my initial misgivings into solid, logical arguments.

    The Hunt

    You see, for me, this adventure has been a rocky one from the beginning. I got dragged, kicking and screaming, into my first encounter with EJB. Everyone was doing it, but until I joined a startup in 2000, I'd successfully avoided the beast. Soon, I was an independent consultant, and I knew that I'd have to bring down some big game to feed my family. I steeled myself to join the hunt, and a messy one it was. I mean, around me was total carnage -- broken projects, stalled careers on top of a stalled economy. I knew that I'd have to work hard to learn the ways of my game. Reluctantly but vigorously, I took on the inevitable preparations, going to monthly classes, reading five best-practices books a day, and even learning UML. At first, it proved elusive, but after months of wandering in the jungle, I finally landed the animal.
    Read Bruce Tate in Don't Make me Eat the Elephant Again.

    Threaded Messages (99)

  2. Hasn’t had a so good laugh in years. :)
  3. Hasn’t had a so good laugh in years. :)
    You need to get out more.
  4. Comities don't solve anything, comities have meetings!
    They ignores us, why can't we ignore them?
    (Even silly JSF does not use EJB or JDO, they use CachedRowSet DAO AFAIK )

    There are many good open source and open standards popular DAO implementations that let you write nice SQL and return XML or collections back, KISS and fast. Why do you need Sun to say: “You are doing a good job”.

    As far as JCP... I think GNU Java Classpath project is re-writing all the jars to break free:
    http://www.gnu.org/software/java/java.html

    .V
  5. Vic,

    I have some difficulties putting some of your statements into context. Maybe you could help me out here?

    And, yes, I am an individual member of the JCP and the JDO 2.0 expert group. I speak neither for the JCP nor the expert group; I just speak for my humble self.
    Comities don't solve anything, comities have meetings!
    As far as the JDO 2.0 expert group is concerned, the majority of work is in fact done via a mind-boggling number of e-mails. It is hard enough work to keep up with reading them, I do not want to imagine the number of hours some key contributors put in to actually write the bulk of those messages. Whether or not this expert group, any other JCP expert group, or even any other standards committee achieves anything is certainly in the eye of the beholder and will have to be decided on a case-by-case basis. However, I think your statement is somewhat off the mark.

    Can you help me understand how far-reaching decisions are made on the GNU project you mentioned in your post?
    They ignores us, why can't we ignore them?
    I have tried to find your name in the list of JCP members, but failed. So I assume you are a member through an organisation. Is this so? (By the way, individual membership is free!)

    More importantly, have you ever tried to interact with an expert group, e.g. by sending an e-mail to the corresponding jsr-nnn-comment e-mail alias? What were your experiences? Have you ever tried to join an expert group? This is really easy with the JDO 2.0 expert group: all I had to do was send a polite e-mail to the specification lead. I explained what I have done before, and what my interest in this specification was. And in I was. Real easy, didn't hurt a bit.

    I trust that we will receive your comments on the early draft for JDO 2.0 shortly after it has become available on jcp.org.
    (Even silly JSF does not use EJB or JDO, they use CachedRowSet DAO AFAIK )There are many good open source and open standards popular DAO implementations that let you write nice SQL and return XML or collections back, KISS and fast.
    I shouldn't really comment on this bit, but have you ever considered the possibility that other projects don't have exactly the same problems as your project? Maybe their system is bigger, smaller, more complex, or simpler? Maybe they prefer [my favourite JDO feature or Cedric's favourite EJB feature] over [your favourite feature of your favourite persistence technology here]?

    What, exactly, is an open standard? How are JCP specifications closed or not open?
    Why do you need Sun to say: You are doing a good job.As far as JCP...
    The last time I checked the JSR for JDO 2.0, I didn't see "Sun to say we are doing a good job." as one of the objectives. Neither did I find this in the one for EJB 3.0. Instead, I believe that those expert groups, as well as any other ones, are putting in significant amount of work into what they expect to be beneficial to their user base.


    Regards,
    Oliver Kamp

    http://www.fiftybar.com
  6. Oliver,
    have you ever tried to interact with an expert group, e.g. by sending an e-mail to the corresponding jsr-nnn-comment e-mail..
    Vic interacting with JCP! That I would like to see. Like Lous Armstrong registering at the unemployment office :)

    I also would like to see the GNU Java Classpath succeed. Then I can compile all Java software into IL code and run on .NET.

    Regards
    Rolf Tollerud
  7. JCP[ Go to top ]

    Oliver,

    I did try to join "Expert" group. I sent in the paperwork and tried to follow up with contacts and nothing happened many years ago. Nothing!
    I did comment on JDO. Many times on TSS! You can just look at my posts by clicking on my name. JDO does not default to SQL, but it uses OQL for one, so no SQL expert (that may not know Java) can help for one. There are people with 9 years or more of SQL. And now need to force O/R when you can have collections.
    Not interested in helping now, I do not want to help Sun, there is nothing in it for me(but you can hire someone). But you can take a look at an popular standard in use, such as iBatis.
    People should elect a popular standard, by popularity. Not be assinged a King by JCP.
    GNU I would help!

    You ask if I did complex projects. This assumes that you think complex is good in some cases I would jump to guess. Let me address that part that I take pains to KISS. Simple runs faster in general and scales more(less crap to go into CPU). Simpler is easier to maintain. Simpler is faster time to market. Simpler is less bugs. Complexity is sign of technical immaturity.
    Some developers take pride in showing how they did something complex.
    It limits how big and sophisticated and useful application you can implement if you are challenged by the technology. I am not flexible on KISS, if no KISS, not my project.

    And I think people that are saying that sometimes you need more complexity than JSP/Serlvet + DAO: I used to take pride in the 1st 7 years of development that I could build complex things, and then I gained experience.

    So a short message: Don't worry about the current king or the new king.
    Stick with open source and use a popular standard such as:
    http://news.netcraft.com/archives/web_server_survey.html

    JCP gave us EJB and JSF, and now you are telling me JDO will be great? With OQL? What is the use case? Saving to a file system. OK, for people that want to save to file system, let it be known that I Sun has blessed JDO.
    (Sun is a sick company, and in a fever doing silly things)

    The controversy is that a fast JSP/Servlet container is all you need plus a DAO.
    The vendors that want to charge for more complexity.... well the emperor is not wearing any clothes. That is what Spring is trying to do. (I do Struts, not Spring but same goals).

    Good luck, do you thing.

    .V
  8. Flawed argument[ Go to top ]

    Vic,

    your arguments are flawed in many ways, so I will only address some of them.
    JDO does not default to SQL,
    JDO aims to provide 'transparent' or 'orthogonal' datastore-independent for Java objects, so it does not make a lot of sense to make the query language for a particular type of datastore the default JDO query language. By the way, JDO 2.0 will support SQL queries, and many implementations have done this as a vendor extensions for a long time.
    but it uses OQL for one,
    JDO uses JDOQL as its default query language.
    so no SQL expert (that may not know Java) can help for one.
    Are you saying it is a problem that an aircraft technician will not be able to help you with your car's problems?
    There are people with 9 years or more of SQL. And now need to force O/R when you can have collections.
    Again, your argument is flawed: there are a lot of people around who do not have 9 years of SQL experience.

    Are you concerned that your current skill set is devalued by JDO?
    Not interested in helping now, I do not want to help Sun, there is nothing in it for me(but you can hire someone).
    If you choose not to participate, you can hardly complain that 'committees ignore you', as you said before.
    But you can take a look at an popular standard in use, such as iBatis.People should elect a popular standard, by popularity.
    What organization has standardized the iBatis API or implementation? ISO, ANSI, ECMA, IEEE, any other, maybe more community-related organization (such as the JCP)?

    Or are you confusing a specific software product (I know it's open-source, but it's still a software product) with a standard or a specification?

    (Please note that I have not made any comment on iBatis itself. I have not looked at it, but am convinced it serves its purpose. I wish this project and its contributors much success.)
    You ask if I did complex projects.
    I did not. Please re-read my e-mail.
    This assumes that you think complex is good in some cases I would jump to guess.
    That is a very far jump. You missed.

    Undoubtedly, some problem domains and, therefore, applications are inherently more complex than others. Writing a distributed telecoms customer care and billing system is, at least in my experience, inherently more complex than, say a desktop calendar application.
    Let me address that part that I take pains to KISS. Simple runs faster in general and scales more(less crap to go into CPU). Simpler is easier to maintain. Simpler is faster time to market. Simpler is less bugs.
    This does not relate to anything I said.
    Complexity is sign of technical immaturity.
    Unless, of course, we are talking about inherent complexity in a problem domain.

    [lots of stuff I will not comment on]
    ...and now you are telling me JDO will be great?
    Oh, no. I am telling you that JDO is great, at least when used to address the problems it is intended to solve.

    This comes back to what I said before: other people have different problems than you or your project. Other people have different problems than me and my project.

    [lots of more stuff deleted]
    Good luck
    And good luck to you.
  9. Flawed argument[ Go to top ]

    Vic,

    I understand your complains about the results from past specifications built by the Expert Group, and I also understand and personally like the KISS aproach.

    I'm one for using KISS instead of using complex frameworks like EJB and JSF. By using JSP+JSTL, simple web containers and technologies that provide easy development like iBatis and Spring, you have simple, scalable and low cost solutions.

    I also think that JDO can be considered inside of the KISS group. JDO can avoid from developers the need of coding the database layer, and some other nice things like transaction and APIs designed to work in environment where you can keep or not state and active transactions. All of that in a simple persistence interface.
  10. JDO[ Go to top ]

    Granted JDO is simpler than EJB, congrats, but not simple enough at all.

    Persistence is to a SQL DB, that is all anyone cares about.
    To say that persistence is can be for other things complicates things, and then people start showing youy how "smart" they are by designing complex solutions to a problem we do not have. It's OQL vs SQL. Why would they even write it, when there is ANSI SQL.

    Spring supports Hibernate and iBatis SQL Maps. Great. iBatis even has another project, DAO that can use any persistence, such as Hibernate. EG would not look at it?
    How about:

    <XML><CACHE ="5 Minutes" AutoFlush = true />
    <STATMENT = "Users.selectAll >
      Select *
    from users a, users b
    where a.parent_id = b.id
    </STATMENT>
    </XML>

    List l = _SQLMap.populate("Users.selectAll", parms);

    Notice now I can now ask a DBA (that does not know Java - that does not make him a bad person) to look at the XML text file to tune SQL w/o Java.
    Simplest possible solution, you do not even need OMG's O/R.(Else I would have to intercept the JDBC call to see the SQL generated). People the slowest part of J2EE is DB access. If you make it complex, then it just means more code has to go trough the CPU.
    Example for insert and update is similar (and from the iBatis manual)

    Most J2EE project should support iBatis and Hibernate, most Struts users use one or the other. That is a popular standard , like Apache HTTP server. No one endorses Struts or Apache, yet they are both dominant and well supported.

    So if you are an "EG" blessed superior, that we should be in awe of, just read the DAO manual of an open source DAO pattern implementation that is useful and make a thin interface around it. Sun won't help JDO becuase they make money by lying about EJB.

    What if EG committee does not produce anything useful? We have the source to the DAO we want to use.
    There are technical systems programmers that love bit twiddling. I just pick and chose the API, no one in their right mind tries to use every J2EE api.
    I am more of an application's programmer that tries to solve a business problem efficiently.

    Now whom can I invoice for this consulting? Did you listen or learn?
    I sure don't want anyone to build a better app then mine.
    ;-)
    .V

    ps: And all the article about data caching on TSS: Data Caching should be in the Data Layer, behind the DAO.
  11. To listen and to learn[ Go to top ]

    I intended not to participate further in this particular thread, but I just cannot help it.
    Persistence is to a SQL DB, that is all anyone cares about.
    Apparently, there is a sizable number of people who do care about persistence to datastores other than relational databases. Furthermore, there seems to be a sizable number of people who care about object persistence on top of relational databases.

    Otherwise, the vendors of non-relational databases would be out of business. Ditto for the vendors of object-relational mapping tools and JDO implementations supporting relational datastores. Also, people such as the contributors to Hibernate or open-source JDO implementations would not put in the effort.

    Again, you are confusing your particular problems and your particular opinion with the problems and opinions of large parts of the rest of the world. And again, I am aware of the fact that my particular problems and my particular opinion are not necessarily those of large parts of the rest of the world.
    To say that persistence is can be for other things complicates things, and then people start showing youy how "smart" they are by designing complex solutions to a problem we do not have.
    That is a problem that you do not have, but how can you speak for the rest of the world?
    It's OQL vs SQL.
    How did OQL come into this. As I have said before, JDO supports JDOQL, which is different from OQL.
    Why would they even write it, when there is ANSI SQL.
    This is actually funny, considering the differences in ANSI SQL support the major database vendors provide.
    Notice now I can now ask a DBA (that does not know Java - that does not make him a bad person) ...
    A little polemical, isn't it?
    So if you are an "EG" blessed superior, that we should be in awe of
    Ditto. Why are you dissing people who commit significant amounts of their time to work that is publicly available? Has anyone dissed you or your work?
    What if EG committee does not produce anything useful?
    So don't use the technology they specify.
    We have the source to the DAO we want to use.
    So use it! Who is we, by the way?
    I am more of an application's programmer that tries to solve a business problem efficiently.
    Funnily enough, so am I. Maybe you mistake things like the JDO spec for a tutorial or a user manual? Large parts of such specifications are primarily aimed at the implementors, rather than the users.
    Now whom can I invoice for this consulting? Did you listen or learn?
    I certainly listen, and I try to learn.
    I sure don't want anyone to build a better app then mine.
    I certainly want to, but am sure I couldn't.
  12. JDO[ Go to top ]

    Vic,

    You're not listening.
    Persistence is to a SQL DB, that is all anyone cares about.
    Not everyone works in an environment with one database that they can connect to. Even if the data is in a relational database, they may have to go through a connector to talk to a mainframe service to access the data, for example. There is a lot of pre-existing crap out there that developers have to support and contend with, and iBatis and other KISS frameworks have nothing to offer there.
    To say that persistence is can be for other things complicates things, and then people start showing youy how "smart" they are by designing complex solutions to a problem we do not have.
    I'm not sure what you mean by "we," but I can guarantee that those problems do exist at almost every big company, and big companies do employ big numbers of developers, so you have overextended on your "we."
    It's OQL vs SQL. Why would they even write it, when there is ANSI SQL.
    Why do you repeat that JDO uses OQL after someone explains that it is not OQL?

    Secondly, how do you propose to query objects that you cannot access through a JDBC connection? Some companies have more than one server, and it's not a Dell desktop box with Redhat Linux running MySQL either. Some companies even use mainframes. Some companies even use applications that were written by other companies that don't use normalized data stores, even if they store the data in an RDBMS.
    How about: .. Select * ..
    Hmm. I hope that's just an example.
    Simplest possible solution, you do not even need OMG's O/R.
    What is "OMG"? If you mean the Object Management Group, then I can only assume that you are trying to be insulting.
    Most J2EE project should support iBatis and Hibernate, most Struts users use one or the other.
    Vic, if they work for the projects that you are doing, then by all means use them and cheerlead for them. I've yet to see iBatis being used once, but that's probably because it's not applicable to most enterprise applications. As for a good definition of what an "enterprise application" is, you can simply assume that an enterprise application is one that ties together multiple ugly things that iBatis can't talk to.
    That is a popular standard , like Apache HTTP server.
    Maybe some day it will be. There's a bit of a difference in acceptance between the Apache HTTP server and iBatis, but if it's useful to you, then by all means you should be telling people about it and praising it, and maybe someday it will be that widely used.

    Don't take anything above as negative. I'm glad for you that you can use KISS software. Most developers working on enterprise hell -- oops, I meant enterprise applications -- can't select such simple solutions because those solutions do not solve any of the problems that those developers are facing. Hopefully, over time, that will change.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  13. Enterprise "problems"[ Go to top ]

    Cameron: "Even if the data is in a relational database, they may have to go through a connector to talk to a mainframe service to access the data"

    What is most common Cameron?

    The data is in a mainframe, and

    1) you can connect to it with a native JDBC driver.
    2) is batched every night (or at other interval) to a database you can connect to.
    3) you talk to it via a Webservice.
    4) you talk to it via a connector and a batch scenario is not viable.

    And of course the most common of all is that the data is in a Unix or window box.

    As usual, the elusive "sense of proportions" is nowhere in sight.

    Regards
    Rolf Tollerud
  14. Enterprise "problems"[ Go to top ]

    Rolf:
    What is most common Cameron?

    The data is in a mainframe, and

    1) you can connect to it with a native JDBC driver.
    2) is batched every night (or at other interval) to a database you can connect to.
    3) you talk to it via a Webservice.
    4) you talk to it via a connector and a batch scenario is not viable.

    And of course the most common of all is that the data is in a Unix or window box.
    Strangely enough, I'm not in disagreement with you in some sense. Most business applications and "web site" applications (in terms of percentage of all applications written) can talk directly to a database.

    There are a lot of parts of J2EE, like EJB for example, that are intended for enterprise applications. While there may be relatively few enterprise applications, they are usually big and complex and employ lots of people and plod on for years at a time. Also, they cost so much that if something like EJB saves them a little time and money percentage-wise, it ends up saving them tens or even hundreds of millions of dollars in the long haul.

    I don't expect you to understand any of this, but it's safe to say that there are environments out there that are a little more complicated than what iBatis or whatever is designed for, and EJB is used in those environments, and despite its ugliness to you as a VB programmer, it is broadly used and has saved companies large amounts of money. In the end, that cost savings is a lot more important to these companies than what Rolf Tollerud thinks.

    Remember: As simple as possible, but no simpler.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  15. j2ee guys has wrong glasses[ Go to top ]

    Cameron,

    While there may be relatively few enterprise applications, they are usually big and complex and employ lots of people and plod on for years at a time.

    All depends on the view. One se the glass half full, the other half empty. An enterprise’s total data systems can be viewed as one large program, or as a conglomerate of small independent systems that is inherently distrustful of each other. Change glasses and try to view it the second way, then you will find that the number of large big and complex (and ugly) systems in the world go down dramatically.

    Regards
    Rolf Tollerud
  16. j2ee guys has wrong glasses[ Go to top ]

    Yes, there are a lot very "ugly" solutions (RPG), but "new" solution ( EJB ) can complicate things more than "legacy" too.
  17. j2ee guys has wrong glasses[ Go to top ]

    BTW I think the true eginiering is to build simple model for complex problem and to solve it in simple way, new complex solution for complex problem means new problem (some people use EJB for to solve simple problem like petstore, but we do not talk about it at this time, do we ?).
  18. Cameron,While there may be relatively few enterprise applications, they are usually big and complex and employ lots of people and plod on for years at a time.All depends on the view. One se the glass half full, the other half empty. An enterprise’s total data systems can be viewed as one large program, or as a conglomerate of small independent systems that is inherently distrustful of each other. Change glasses and try to view it the second way, then you will find that the number of large big and complex (and ugly) systems in the world go down dramatically.RegardsRolf Tollerud
    Sorry Rolf, but the world is not that simple. Wish it could be, but reality is much worse than that. Where I work, there are tens of big, complex, old monolithic systems, with hundreds of thousands lines of code, and if they could be seen as you are saying, we could have replaced these dinaosaurs with better solutions long ago, going piece by piece, but such is not the reality. I don't know if the company I work for is much different from the rest of the world (a big telco company), but I think it is not.

    As Cameron already said: make it simple, but no simpler.

    Regards,
    Henrique Steckelberg
  19. I saw "dinaosaurs" in "small" and in "large" companies a lot of companies have problems, but people solve problems not tools (or people do not think it is a problem)
    Sorry Rolf, but the world is not that simple. Wish it could be, but reality is much worse than that. Where I work, there are tens of big, complex, old monolithic systems, with hundreds of thousands lines of code, and if they could be seen as you are saying, we could have replaced these dinaosaurs with better solutions long ago, going piece by piece, but such is not the reality. I don't know if the company I work for is much different from the rest of the world (a big telco company), but I think it is not.As Cameron already said: make it simple, but no simpler.Regards,Henrique Steckelberg
  20. "As Cameron already said: make it simple, but no simpler."

    Unfortunately Cameron is no Einstein, Henrique, only a guy that always misses "the sense of proportions" view and uses an image of wounded innocence while lashing condescending tangential attacks at others. In short, a Bona Fide hypocrite. Don't forget that he is part owner of a Java company that lives on a product that "is build with Java and used for Java", a double lock in. (and now his innocence will get even more wounded! :)

    Replacing "old monolithic systems, with hundreds of thousands lines of code" with EJB systems must be the ultimate of folly. "The patient died from the medicine".

    Of all the hundreds of post in TSS and elsewhere, bashing the J2EE application servers in all directions, this is my favorite: a href=""Now" rel="nofollow">http://www.theserverside.com/news/thread.tss?thread_id=24823#116183">"Now we have server side applications that behave like 1992 desktop applications"</a>.

    The J2EE application servers are in the process of becoming extinct, except that it will take many years. Don't worry for your job yet! There are still hundreds of thousands of Cobol programmers working around the world.

    On the server side there is better solutions with Spring, Pico, etc and with Webservices,
    "Web services will become the dominant distributed computing architecture in the next 10 years and will eventually define the fabric of computing... Web services will drive a total software, services and hardware opportunity in the U.S. of $21 billion by 2007 and will peak at $27 billion in 2010."
    And on the client side;

    Chris Anderson (Avalon team):
    We are past the world of generating static snapshots
    of display and blasting them down to a client.

    Dynamic applications should be dynamic on the client. The
    server should send data - either through web services,
    database access, or any other wire protocol - and the
    client should consume that data and generate UI. The
    model of a server trying to generate the correct
    display for a client is just broken".
    Imagine when the new Spring Rich Client Platform or the XUL stuff from Mr Bauer is compiled with the Excelsior JET, keeping state at the client, leaving the server nice and stateless and communicate with Hessian, Burlap or Soap or whatever. Are you not young? Do you not seek adventure?

    Go west, young man.

    Regards
    Rolf Tollerud
  21. Let's say Spring is the answer to all of our prayers...

    My question remains...you don't put your eggs in one basket, so you have to cluster. Once you have a cluster, you have to manage it, manage deployments across it, upgrade and patch this stuff even though you actually have zero maintenance window? (do web sites close up shop after 5:00 like CICS goes down in the evening?). You don't have 1 app or 2 apps, you have 100 different apps with different requirements. How much soap is being sold here? I'm often told that I don't need all these servers, just an instance of TomCat, it's SIMPLE. I want to strangle the next person that tells me how simple something is!

    How do you know when stuff is down? How do you know when it is running -slow-?

    I could not find the workflow tools in Spring, or the messaging implementation, or the tools to synchonize its LDAP directory with microsoft active directory.

    Web services are going to 'fix this'? If we think JTA is onerous, how about SOAP!...I'm getting told that all that parsing, and the bloat, eg ratio between payload and soap wrappers, makes exchanging plain xml much faster, or better dropping down to something like RMI/IIOP. What about things like UDDI and WS-Security, or BPEL...I could not find that in Spring either, but I can switch from JNDI to IoC style code and move my JNDI lookup to a factory bean wrapped in my XML descriptor so it doesn't appear in my Java code. That makes for clean looking code, but now it's spring-flavored IoC code versus J2EE flavored code with the lookups in my classes. I see myself moving laterally, not forward.

    I'm reading this and thinking to myself, how is this going to rock my world in a concrete sense? Neat ideas, probably some of it is useful, good to understand, food for thought yes...the end of application servers? The end of J2EE?

    Cheers!
  22. Mike,
    the end of application servers? The end of J2EE?
    For the first the end of application servers does not mean the end of J2EE.

    For the second if you think that one large application as big as 100 ordinary applications is easier to develop and maintain than 100 separate applications the only thing I can say is:

    Please try! :)

    Regards
    Rolf Tollerud
  23. "As Cameron already said: make it simple, but no simpler."Unfortunately Cameron is no Einstein, Henrique, only a guy that always misses "the sense of proportions" view and uses an image of wounded innocence while lashing condescending tangential attacks at others. In short, a Bona Fide hypocrite. Don't forget that he is part owner of a Java company that lives on a product that "is build with Java and used for Java", a double lock in. (and now his innocence will get even more wounded! :)
    There you go again with ad hominem attacks, won't you learn to behave yourself in public places? AFAIK, Cameron is a hell of a successfull and respected Bona Fide... ;)
    Replacing "old monolithic systems, with hundreds of thousands lines of code" with EJB systems must be the ultimate of folly. "The patient died from the medicine".
    So are all those sucess stories lies?
    Of all the hundreds of post in TSS and elsewhere, bashing the J2EE application servers in all directions, this is my favorite: a href=""Now" rel="nofollow">http://www.theserverside.com/news/thread.tss?thread_id=24823#116183">"Now we have server side applications that behave like 1992 desktop applications"</a>.The J2EE application servers are in the process of becoming extinct, except that it will take many years. Don't worry for your job yet! There are still hundreds of thousands of Cobol programmers working around the world.
    Rolf, you should know by now that you can't use Cobol in any solution, just as you can't use EJB (or .Net, for that matter) in any solution. There are specific cases where they are demanded, and Java developers have already learned that. It is time some microsoft defenders should learn that too. By the way: I used to be an ASP developer until recently - thanks god I am not anymore, so don't worry about by job, I am fine.
    On the server side there is better solutions with Spring, Pico, etc and with Webservices,
    "Web services will become the dominant distributed computing architecture in the next 10 years and will eventually define the fabric of computing... Web services will drive a total software, services and hardware opportunity in the U.S. of $21 billion by 2007 and will peak at $27 billion in 2010."
    Again, you need to understand where to apply these solutions. They won't work for every situation out there, despite what Microsoft may say: there is not a single solution to all problems in the world, you need the right tool for the job. Knowing with one to use is half way into the solution. BTW, the last time I checked, it was systems engineers that defined the solutions to problems, not marketing guys, so your quote doesn't help much today.
    And on the client side;Chris Anderson (Avalon team):
    We are past the world of generating static snapshotsof display and blasting them down to a client.Dynamic applications should be dynamic on the client. Theserver should send data - either through web services,database access, or any other wire protocol - and theclient should consume that data and generate UI. Themodel of a server trying to generate the correctdisplay for a client is just broken".
    Imagine when the new Spring Rich Client Platform or the XUL stuff from Mr Bauer is compiled with the Excelsior JET, keeping state at the client, leaving the server nice and stateless and communicate with Hessian, Burlap or Soap or whatever. Are you not young? Do you not seek adventure?Go west, young man.RegardsRolf Tollerud
    Are you telling this to Java developers, which already have all this today? Go tell that to Microsoft developers, which will have to wait until 2006 to have production level quality access to all this (if MS doesn't delay it one more time...) ;)

    Regards,
    Henrique Steckelberg
  24. What do you mean I very seldom use hominem attacks. But I make a special case of Cameron, he should be proud. After all he is my friend!, at least he was the only one that defended me and said "I was not part of TSS problems" :)

    I really do not blame Cameron, he has a company and family to feed. In his position I would do the same (hypocrisy and all..), but the truth must always prevail. He is in a position where it is impossible for him to be impartial.

    Regards
    Rolf Tollerud
  25. What do you mean I very seldom use hominem attacks. But I make a special case of Cameron, he should be proud. After all he is my friend!, at least he was the only one that defended me and said "I was not part of TSS problems" :)I really do not blame Cameron, he has a company and family to feed. In his position I would do the same (hypocrisy and all..), but the truth must always prevail. He is in a position where it is impossible for him to be impartial.RegardsRolf Tollerud
    Henrique:

    You should know by now that disscusing with Trolf in a logical and civilized manner will most likely be a frustrating experience for anyone that has more than 2 neuronal cells (99.999% of the people in this forum).

    As you can see, he is full of ad-hominem and when he can not answer a good reply (like yours and your well thought answer), he will just resort to a diferent argument. In this case, he has shut his mouth (something which 99.999% of the people would certainly appreciate if it were forever...) and just keeps talking about Cameron and conveniently forgetting about his other defeated arguments.

    As for Trolf, it was an expected outcome... too predictable and consistent with his bad looser attitude.

    (Trolf, if you like the British so much, I guess you wouldnt mind to duel with me. Am I right?)

    Long live and prosperity!

    StarTrooper
  26. Don't worry Star Trooper, I know Rolf's evasive discourse pretty well, and have "dueled" him few times before, so I know where I am stepping on... ;)

    BTW, nice nick.

    Regards,
    Henrique Steckelberg
  27. what is there more to say[ Go to top ]

    Star Trooper: In this case, he has shut his mouth

    I was away, there are customers you know (if it was not for the customers that keep bothering me all the time I could run a pretty good business :)

    Anyway as consensus has arrived and most people agree what point is there to go on with the thread forever. I much rather start a new thread based upon

    Joel on Software

    Anyway you guys should not worry so much about my so called "evasive technique" and listen more to what I am saying. What the defenders of bad technology always want to is to boggle down to nonimportant trivial details and discuss forever. In this way you can defend anything. All post in TSS is saved forever though, and so far I do not have to be ashamed over my track record.

    Regards
    Rolf Tollerud
  28. what is there more to say[ Go to top ]

    Anyway you guys should not worry so much about my so called "evasive technique" and listen more to what I am saying. What the defenders of bad technology always want to is to boggle down to nonimportant trivial details and discuss forever. In this way you can defend anything. All post in TSS is saved forever though, and so far I do not have to be ashamed over my track record.RegardsRolf Tollerud
    "listen more to what I am saying."?? I would but you haven't said anything worth of listening. I ussually just wait for 2 minutes once the crap gets poured since my time is too valuable. In your case, my time is UP.

    "What the defenders of bad technology always want ..." Those suckers use the very same "evasive technique" you are good at. Therefore...

    "and so far I do not have to be ashamed over my track record" really??? have you got any record???
  29. Star Trouper British?[ Go to top ]

    I was just using our post as a convient way to replay to all. You do not think I discuss with an anonymous person do you? Neither would an Oxford intellectual.

    (Which BTW I don’t think you are. :)
  30. Star Trouper British?[ Go to top ]

    I was just using our post as a convient way to replay to all. You do not think I discuss with an anonymous person do you? Neither would an Oxford intellectual. (Which BTW I don’t think you are. :)
    Interestingly, the test proposed by Turing for defining the concept of artificial inteligence (AI) was based on the use of an "anonymous" entity (in this case a computer) sided with a human counterpart... and I've seen several Oxford intelectuals talking to "Eliza" for research... If they did not care to do so, I failed to see why you would make such a fuss.

    "You do not think I discuss with an anonymous person do you" I have to grant this one to you. When talking to real people you just resort to your "evasive tactics". Nothing to be ashamed of (you know better than us your own intelectual limitations) but also nothing I personally would be proud of.


    Long live and prosperity!
    StarTrooper
  31. I really do not blame Cameron, he has a company and family to feed. In his position I would do the same (hypocrisy and all..), but the truth must always prevail. He is in a position where it is impossible for him to be impartial.
    You're getting better at those backhanded compliments ;-)

    OTOH I'm not sure how what I've said is "hyposcrisy" since I'm not selling an EJB server nor is there a Coherence*EJB module (yet) that takes advantage of the EJB standard using our software.

    So I think you need to dig deeper to find a reason why I would defend EJB. Maybe it's because I see some good uses for it?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  32. j2ee guys has wrong glasses[ Go to top ]

    All depends on the view. One se the glass half full, the other half empty. An enterprise’s total data systems can be viewed as one large program, or as a conglomerate of small independent systems that is inherently distrustful of each other. Change glasses and try to view it the second way, then you will find that the number of large big and complex (and ugly) systems in the world go down dramatically.RegardsRolf Tollerud
    Yeah, but even then, and I not believe it is true in the first place, you end up with a <em>huge</em> number of "simple" systems. So, whereever you pile up the entropy, it is a simple truth that is will not go away. So there is something to be said for the entropy being "contained" in some large and ugly barrels - not least from a system management and accountability perspective: Better a couple of barrels with steaming oil than hot oily grease all over the floor. BTW: The latter used to be called CORBA Business Objects in my not-so-distant youth, so it's back to square one.
  33. Enterprise "problems"[ Go to top ]

    Cameron: "Even if the data is in a relational database, they may have to go through a connector to talk to a mainframe service to access the data"What is most common Cameron? The data is in a mainframe, and1) you can connect to it with a native JDBC driver.2) is batched every night (or at other interval) to a database you can connect to.3) you talk to it via a Webservice.4) you talk to it via a connector and a batch scenario is not viable.And of course the most common of all is that the data is in a Unix or window box.As usual, the elusive "sense of proportions" is nowhere in sight.RegardsRolf Tollerud
    5. Communicate via Message Queue.
    And of course the most common of all is that the data is in a Unix or window box.
    Is it? By volume? By number of machines? Is it that way because people think data vs objects (ie moving big piles around)?

    BTW Rolf, Gartner wants their crystal ball back. It has been a day since they last astounded us with their look into the future. :)
  34. Enterprise "problems"[ Go to top ]

    Mark,

    5. Communicate via Message Queue
    Of course. I forgot that one.

    Mark: By volume? By number of machines?
    I meant by projects!

    BTW IBM claims that by data volume mainframes still carry over 50% of the world data transfers. I wonder if that is true.

    Regards
    Rolf Tollerud
  35. Enterprise "problems"[ Go to top ]

    BTW IBM claims that by data volume mainframes still carry over 50% of the world data transfers. I wonder if that is true.RegardsRolf Tollerud
    If what I have seen over the last 10 years is any indication - definitely.
  36. Enterprise "problems"[ Go to top ]

    No, it's clearly a lie. The truth is that 99% of world data transfers (including those of all the major banks) are run on MS boxes using Access with a VB front-end.
  37. Enterprise "problems"[ Go to top ]

    Ah, now I understand. Thank you! That is why I'm having so much trouble with my accounts. One day up one day down. I am on my third bank now and if this too does not work out I will revert to good old snail-mail or visit the bank-office in person! :)

    After all it is my money.
  38. Enterprise "problems"[ Go to top ]

    The truth is that 99% of world data transfers (including those of all the major banks) are run on MS boxes using Access with a VB front-end.

    I would have guessed Excel ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  39. Enterprise "problems"[ Go to top ]

    You disappoint me Cameron. The same joke twice. :(

    Try to be a good loser, like an english gentleman!

    Regards
    Rolf Tollerud
  40. Enterprise "problems"[ Go to top ]

    IBM claims that by data volume mainframes still carry over 50% of the world data transfers. I wonder if that is true.I wonder if that includes SMTP & HTTP data transfers, surely a large percentage of all data existant.
  41. JDO[ Go to top ]

    Vic,You're not listening!
    I agree with Vic, if you can implement JDO for "crap" or "legacy system" then you can implement JDBC too, but JDO members do not ignore developers, I see it was changed and I started to trust JDO is going to change and to become usable for me. I am not very happy with the ways I use to access data too, but there is no good choise at this time (I think I know the most of ways to do it).
  42. JDO[ Go to top ]

    I've yet to see iBatis being used once, but that's probably because it's not applicable to most enterprise applications. As for a good definition of what an "enterprise application" is, you can simply assume that an enterprise application is one that ties together multiple ugly things that iBatis can't talk to. Most developers working on enterprise hell -- oops, I meant enterprise applications -- can't select such simple solutions because those solutions do not solve any of the problems that those developers are facing.
    And thus the native hue of resolution
    Is sicklied o'er with the pale cast of thought,
    And enterprises of great pith and moment
    With this regard their currents turn awry,
    And lose the name of action.
  43. JDO[ Go to top ]

    ps: And all the article about data caching on TSS: Data Caching should be in the Data Layer, behind the DAO.
    You're write. But EJBs were created because of something you overlooked and probably won't believe:

    DATABASES DON'T SCALE!

    It's true. The database is the most complex and powerful component in most every application, but when it comes down to it, the database is the bottleneck and single point of failure. That's why caching is needed, and that's why EJBs are needed.

    The problem is that no one has spent the effort to create a good EJB container. Weblogic and Websphere are barely improvements on the Reference Implementation, architecture-wise. JBoss is innovative, not in it's implementation of EJB, but in it's architecture.

    Sun thought that EJB container implementors would compete on implementation, much the same way database implementors have, and the best implementation would win marketshare. Perhaps it is because if the complexity (and some would say brokenness) of the EJB spec that none of the vendors have actually gone beyond a proof-of-concept implementation.

    What's needed to make EJBs useful is a good query language and engine. Maybe there isn't a way to do that, but OODBMS vendors think they have at least part of the solution.

    Whatever, one thing is for sure, that in some cases, you can't just keep adding memory to you monster DB box and hope that disk seek speed keeps outstripping Moore's Law. Or maybe you can?
  44. JDO[ Go to top ]

    I have this dream too and I hate RDBMS and SQL, but I have no choise, customers need solutions not dreams.
  45. JDO[ Go to top ]

    BTW Have you ever tried to tune DB before to say "DATABASES DON'T SCALE!" and to use some workaround or buzzword you are talking about ?
  46. JDO[ Go to top ]

    But EJBs were created because of something you overlooked and probably won't believe:DATABASES DON'T SCALE!It's true. The database is the most complex and powerful component in most every application, but when it comes down to it, the database is the bottleneck and single point of failure. That's why caching is needed, and that's why EJBs are needed.
    Not quite sure where you get the fact that databases don't scale. If scalability is a factor in my experience EJB's scale much , much worse than databases.
    If database is a bottleneck , EJB is certainly not the cure.
    What's needed to make EJBs useful is a good query language and engine.
    Not another broken Query Language please. You will end up poorly reinventing SQL (yes, I know it's not fashionable to support something that's not OO or has been around for more than 5+ years).
  47. I am agree with you. From more than 20 projects I worked. I found that most of time, what enterprise care is the "TIME".

    EJB (Entity Bean) is really convenient for data query with SQL (Many IDE tools can "drag and drop" for EJB-DB linking). But if people want to put business logic into Session bean, everytime when the business changed, the new deploy will need. However, this may cause business to stop and wairt for deployment.

    So, for me, if the project is really simple and no complex transaction and report needed. I just use simple Entity bean as data source and session bean deal with business logic. If there is no transaction and only a lot of reports, EJB is not the solution since it is too weak for report composing(Somtimes, even some lines of SQL can be more easier and powerful than EJBs). If the project is complex, Session is only used for order split and transaction control. Business logic will be placed into some simple java class and plugable for session bean. I usually make EJB and Web UI parts into seperate ears. UI is the subject for change, but business loigc doesn't change really often.

    Put business logic into servlet and JSP? Unless it is really simple, I won't put it into web tier. One reason is written above. another reason is for security issue. Many companies have their own security policy and tools. It is better to hide the business logic into another place other than web server.

    When I have TIBCO and some other process flow softwares, I will only use JSP to co-op with TIBCO. The pages are built via Dreamweaver, TIBCO, Struts(This one is not so friendly as the previous two).

    JCP builds too many "specs". But what we need is a "generic, simple, fixed" one. In only 3-5 years, we faced J2SDK 1.2, 1.3, 1.4. and J2EE 1.2, 1.3, and Servlet 2.2, 2.3, 2.4, and JSP 1.0, 1.X and a lot of JXXX stuff. Now J2EE wants to put the finger into business proecess interface! Please keep Java and J2EE clean and stable, OK? Does JCP think that all people are supermen to remember a lot of specs? If we need the tools, we can ask the vendor to provide one for us.

    When will Java become open source and stable as C++ or other traditional language?
  48. As a seasoned software architect and developer I've eaten my fair share of Elephants.. one thing that the past 15 years of experience has taught me is to keep things as simple as possible.

    I was the co-founder of a J2EE startup a few years back and therefore have plenty experience of J2EE but when I write solutions for clients today I often make very little use of J2EE other than for the web tier.

    I've just finished development of a solution that has been designed to handle 1 million active users and it is based on a platform consisting of Red Hat, Apache, Tomcat and MySQL. The Java code is entirely stateless allowing for very easy horizontal scaling behing a hardware load-balancer and the persistence tier is based on JDBC (using stateless DAO classes generated by my company's FireStorm/DAO product - you can't get faster raw performance than this). The MySQL database is replicated for fail-over. This architecture is easy for most developers to understand, it is easy to monitor and support, everything can be tested easily using automated JUnit tests and the cost of the platform (hardware and software) has been inexpensive.

    J2EE certainly is required for some applications but probably only for about 5% of the applications that most people are building, IMHO.

    Cheers,

    Andy Grove.
    CodeFutures
  49. mind-boggler[ Go to top ]

    Try to compute how much money that could have been saved for US (and the rest of the world too) if everyone had been as wise as you.

    Andy Grove += 10

    Regards
    Rolf Tollerud
    (and stateless too!)
  50. mind-boggler[ Go to top ]

    Try to compute how much money that could have been saved for US (and the rest of the world too) if everyone had been as wise as you.Andy Grove += 10RegardsRolf Tollerud(and stateless too!)
    You're expected on the Java vs C++ Performance thread Rolf :-) Don't miss that one...
  51. +1
  52. +1
    Oops forgot to quote. +1 To Andy Grove, that is :-)
  53. the andy approach[ Go to top ]

    Andy, i was wondering if you could talk about
    performance as you scale up to your 1 million users?
    Are the pages complex? How long does it take to render
    a page? I assume your session state is in the database
    and is replicated? How are you handling the locking
    of objects shared between different users, even though
    they are transient? Is a stateless session bean really more
    complex then your generator approach?

    thanx
  54. the andy approach[ Go to top ]

    Hi Thoff,

    The application I'm working on consists of a web site, a WAP portal, and an asynchronous back-end that polls external web resources such as email and web servers and sends notifications to the users via email and SMS. I can't go into too much detail because of NDA restrictions.

    The web tier is built using Struts/Tiles/JSP. I do cache some basic state information (a user object for the current user) in the web tier as we are willing to accept that if one server in the cluster dies then some users will need to log back on. Again, this goes back to the KISS principle - we could have designed for complete fault-tolerance but this would have had performance & complexity costs. However, all reads/writes of the user's transaction data go direct to the database each time. The web tier caching isn't so bad because the load-balance has session affinity i.e. once a user logs on all of their requests will go to the same web server for the duration of their session.

    The only area where locking is required is in the asynchronouse back-end processes. These are clustered across a number of nodes that are all trying to process data at the same time. I have built locking at the application level using a JMS-style publish/subscribe approach but just using MySQL tables i.e the producer threads insert rows into a table and the consumer threads run a query to 'lock' a thousand rows from the table by placing their unique node name in a 'locked_by' column. Once this operation is complete the consumer threads will process the locked rows and then remove them. We did run into some performance problems with this approach using Postgres but we moved to MySQL and it flies now.

    As for your question about stateless session beans... no they are not so complex. I'm actually a huge fan of stateless session beans but they were not used in this project since the client who will be supporting the project do not have extensive J2EE support skills.

    Cheers,

    Andy.
  55. EJB is definitely bloated, and a big overkill for most of the situations I've seen it used in - as countless others have reported. This article accurately points to the 'every one's doing it' and 'resume building' factors that drive the overuse.

    Good points are also made for moving EJB3 POJO persistence to a seperate spec:
    <article quotes>
    In short, I'd rather see EJB define how to package, produce, and consume services, rather than define exactly what those services should be.

    this approach of defining a service within EJB is fundamentally inconsistent with the rest of EJB: for messaging, EJB lets another standard define messaging, and it embraces the standard. EJB customers would be better served if EJB3 allowed pluggable persistence, or separated another service. Similarly, EJB embraces existing standards for the expression of metadata, and the management of transactions.
    </article quotes>

    It's good to hear that members of the EJB and JDO expert groups are willing to work toward this. Hope they can sell the others on this and see it through.
  56. It would be great to have one persistence specification we can all work with. I know most of us were worried after the symposium that we were going to build yet another way of doing persistence.

    I am still hoping that as the specs get developed and implemented that Sun will introduce the concept of EJB 3.0 only certified containers. I fear making the containers support previous versions will make the containers just as bloated ever.

    Great article btw. I think most people who have been doing J2EE EJB development over the last 5 years can relate to it.
  57. Firstly I'd like to congratulate Bruce on an excellent commentary: you have chosen an excellent metaphor and addressed a very "hot topic" without getting "political", for which you deserve much kudos.

    Secondly, I'd like to consider the closing paragraph of Bruce's piece, the paragraph called "Some Hope".
    Fortunately, some independent minds within the JCP, like Richard Monson-Haefel, are working hard to add real sanity to the persistence space. Some recent threads in cyberspace point to the desire to have the JDO and EJB3 expert groups work together. It looks like there's been serious movement on both sides:

    • Some in the EJB3 expert group, such as Richard Monson-Haefel, are willing to discuss the option of moving persistence into a separate JSR.
    • Some in the JDO group, such as Bruce Snyder and Patrick Linskey, are willing to move JDO as far as it needs to go to support EJB3.
    • If it proves inadequate, some in the JDO group have expressed willingness to build a new standard for J2EE POJO persistence.
    This first step would be the most important, and the most significant. It would consolidate persistence for J2SE and J2EE under a single, complete standard for the first time. (JDO might have been that standard, but did not address object-relational mapping.) It would allow a cleaner model for integrating alternate persistence solutions. It would also unify the purpose of EJB, as a platform for producing and consuming enterprise services. And it would free customers who are struggling with CMP to move forward in a safe direction, since it looks like CMP will be supported only for backward compatibility.
    For full disclosure I am a member of the JDO 2.0 Expert Group, but I am writing in my personal capacity and not on behalf of JSR-243. I'm going to make a special effort to avoid politics in this response, to keep in the spirit of Bruce's commentary.

    The JDO expert group has a track record of engaging with alternative opinion, and that track record is already well known to the community. It has even affected the shape of JDO 2.0. I refer specifically to our dialogue with Oracle since August 2003 and with Gavin King (then Hibernate) since later that year, but I believe we now have representatives from IBM on the JDO expert group as well - I'm not sure whether we have representation from BEA. I believe we have no representation from JBoss. In this way there are or have been open channels of communication between the core JDO camp and most, although not all, of the major EJB 3.0 players.

    The early draft JDO 2.0 specification has been written. It is now in the hands of the web publishing folks at Sun and the JCP, and should be available to download from the JCP in a day or perhaps two. We finished our work on the early draft on Friday 11 June, and it takes about a week to have the document published.

    The JDO 2.0 draft is being published with the specific intention of receiving community feedback. The community includes everyone interested in Java, from the most junior programmer to the most senior architect and beyond, including all of the EJB 3.0 members. We actively seek feedback. We will carefully consider the feedback we receive, and no doubt some of it will affect our own thinking and result in changes to the JDO 2.0 specification.

    The JDO 2.0 first draft covers almost all of the planned scope for JDO 2.0. Chapter 15 is a good place to start - it covers the standardization of Object Relational Mapping. Enhancements for JDOQL (including aggregation and projection) and support for SQL queries are in Chapter 14. Detachment and Fetch Plans are detailed in Chapter 12.

    I guess the point I'm trying to make is that the scope for JDO 2.0 is not only well defined, but the underlying capabilities have been reasonably well-specified (albeit with less rigour than a Proposed Final Draft). Whilst we will consider all comments from the community we will be reluctant to introduce new capabilities that would warrant our going back to the JCP to change the defined scope of JDO 2.0, or which might result in delays to the finalization of JDO 2.0. We have a duty of care to the JDO community to deliver JDO 2.0 both within the agreed scope of JSR-243 and in a timely manner. Of course, JDO 2.1 could swiftly follow, the scope of which remains open.

    The JDO 2.0 draft specification is the result of a huge amount of work from the JDO Expert Group. I know that many of the JDO vendors are already engineering support of JDO 2.0's features as described in the early draft. And, if I recall correctly, we've actually achieved this specification with complete backward compatibility (of both APIs and metadata) to JDO 1.0.1.

    Now that the draft specification is available (well, it will be before this TSS thread is done!) I hope that it will be - figuratively speaking - downhill from here to the ratification of JDO 2.0 at the JCP Executive Committee towards the end of the year.

    Kind regards, Robin.
  58. I would agree with many of Bruce's arguments particularly wrt separating the persistence standard from the EJB spec (as it has been done with JMS, JDBC etc.)

    Given the progress that has taken place with EJB3, is it possible to change course at this stage?

    I would disagree on some of the comments, however. One could always go with a a-la-carte option and nothings in the specs prevented that. e.g. one could go with a different persistence approach and not use entity beans. The problem was more with available books, blueprints, vendor documentation and other literature which almost all suggested "eating the whole elephant". It took the community quite a while to mature and learn from the bitter experiences from the heavy solutions (which are really needed for the high-end niche).

    Regards,
    Kalyan
  59. Kudos to Bruce for an excellent article! I too laughed at the all too true analogies that Bruce used in characterizing a typical EJB project. I also appreciated the non-political/non-technology bashing approach Bruce took. Nice job!

    In working with other companies, I've seen projects that feel like they would have been more successful utilizing the Chicken Hunter approach Bruce outlines. I'm looking from this list for more insight into specific project examples that would help me more clearly understand which approach would be more appropriate.

    What characteristics would suggest that an enterprise project would be better served with a Chicken Hunter mentality versus an Elephant Hunter mentality? I believe I understand the distinction drawn in the article between a chicken and elephant hunt, and the high level project characteristics.

    Any more thoughts on what a typical Chicken Hunter would look like? Skill sets?

    Thanks

    Scott Cranton
    Nexaweb Technologies
  60. Unless I'm misreading the article, Bruce wants EJB3 to a) only specify the persistence interfaces and let vendors provide pluggable implementations, b) not be tied to the application server, c) not use metadata and d) not use J2SE 1.5. Or, in simpler terms, he would like JDO to be renamed EJB3.

    Praising the EJB3 group for embracing lightweight POJO-style programming while calling into doubt all of the things that are not like JDO sounds a little biased to me. Innovation, particularly with regards to J2SE 1.5 is a good thing, particularly when you consider that this standard will only start to be dominant in 2005 and then for several years afterwards. Merely bringing EJB or JDO up to current standards isn't good enough.
  61. I read the same article. My perception of those same points was more along the lines of:

    • EJB 3.0 should not specify persistence, but perhaps J2EE should specify or nominate interfaces under which a persistence implementation could be active.
    • Ideally the persistence specification in J2EE should not be tied to an EJB container.
    • Not require the use of JSR-175 annotations, since (a) metadata sometimes has a different lifecycle to that of the source code, and (b) JSR-175 introduces a JDK 1.5 dependency.
    • Not unnecessarily tie EJB 3.0 into JDK 1.5.
    I actually think the last point is less relevant since JDK 1.5 will probably have penetrated large enterprise accounts by the time EJB 3.0 is a commercial reality. For this not to be the case there would have to be viable EJB 3.0 implementations commercially supported by the big vendors before a Q3 2006 timeframe.

    I guess we each read from our own perspectives....
  62. It's humbling to see so many responses from people who have impacted my career deeply. Thanks for all of the kind words. Often, it's hard to express a hard-hitting opinion without tearing down the work of others. I've tried to do that here. An article like this one will be read from many different perspectives, and atrribute me with insight that I did not have in advance. But I love the metaphor. It sums up my feelings pretty well. (I also write about the feelings in Better, Faster, Lighter...it's on Amazon. They have books even though they say that they have not shipped yet....have to look into that.)

    Re. JDO, I currently use both Hibernate and JDO in my commercial implementations. You can see why I'd be uncomfortable with an EJB standard that shut out one or the other, without input from both.

    Thanks for the kind words, and pardon me while I go kill a chicken for lunch.
  63. Robin,

    Apparently our perceptions of the article are not that different, as I don't think anything you wrote contradicts my own interpretation, save for use of the word "should". The points Bruce made are perfectly valid opinions, but apart from being fun to read, I don't see anything here that moves us forward.

    Your Q3 2006 date is odd though. Is that a typo? I fully expect to see both JDO2 and EJB3 implementations commercially supported next year. Certainly the vendors I talked to in Vegas indicated this would be the case.

    Cheers,

    Merrick
  64. Moving forward[ Go to top ]

    In fact, I'm seeing more and more corporate architectures simplifying, and moving away from enterprise-style frameworks, in favor of lighter, simpler frameworks. I'm seeing this trend at banks, in manufacturing, in consumer data. The trend spans start-ups and the most conservative fortune 500 companies, in Europe and here at home.

    The reason? Many development shops simply can't get their arms around the enterprise frameworks anymore. It's getting too hard. A forum like this one is often difficult for books and articles like mine, because those who post the most frequently are so smart. I try to communicate to the 80% of the developer population, who struggles with EJB and XML schema and the full web services stack.

    In fact, some of what we do requires the big guns. But we're selling these solutions into the masses. Easily half of the enterprise applications out there do nothing more than babysit a big, fat relational database. They don't even always do it in volume. For these users, traditional architectures, with EJB or otherwise, are overkill. I'm trying to get the message out that overkill commands a price, and it's usually a stiff one.

    AOP didn't get invented because some joe blow said "I think I'll invent a new programming model today." It was invented because the current model is being pressed a little too hard, and falls down a little too often. And it may not be ready for prime time in all of it's full glory, but we can certainly take advantage of the ideas in a more restricted context, with frameworks like Pico and Spring.

    So if we're talking about it and showing the major vendors that we're paying attention and these lighter frameworks have value to us, I do think this article has value. I'm probably going to be a boring read for most of you for the next year or so, because this is going to be my recurrent theme: simplicity, productivity, flexibility.

    Take care.
    - bt
  65. Moving forward[ Go to top ]

    I don't think it's always the case that simple == small. The J2EE specification is large, but most developers will only use the components that make sense for their application, and most of these components have well defined boundaries. The problem is and always has been that the individual components of the J2EE platform are complicated and have a steep learning curve.

    Spring is a great framework, but a lot of the development around it is in integrating with existing, complicated J2EE APIs. If I use the simplified API of Spring as a wrapper to Servlets, JDBC, Portlets, JMS and other enterprise technologies, is that still lightweight programming? Yes, there are value adds there in the AOP context, but fundamentally I'm just compensating for deficiencies in the standard APIs. I don't think the application server issue would matter to people at all if they could have a simple way to gain access to enterprise services.

    Based on what I've seen from the J2EE 1.5 EG vision, it's like they realized last year that wheels roll more smoothly with round edges instead of sharp corners. If they can follow through on simplicity, ease of adoption and productivity will follow suit.

    Cheers,

    Merrick
  66. Hi Merrick
    Your Q3 2006 date is odd though. Is that a typo? I fully expect to see both JDO2 and EJB3 implementations commercially supported next year. Certainly the vendors I talked to in Vegas indicated this would be the case.
    The adoption of EJB 3.0, if it is indeed dependent upon JDK 1.5 as present marketing statements suggest, will be tied to the adoption of JDK 1.5 itself.

    Bearing in mind:
    • JDK 1.5 general availability in Q4 2004
    • Historic adoption rates in the "enterprise" (whatever that means now)
    One of my financial sector clients takes JDK releases one year after general availability, and does not contemplate initial releases. If JDK 1.5 is Q4 2004, the first point release will probably be Q1 2005. Adding a year gets us to Q1 2006, by which time sufficient confidence levels should have been attained for implementation to go ahead.

    Then there's the issue of the application server itself. Major vendors will not release EJB 3.0-compliant servers until after JDK 1.5 goes GA. Similar principles apply, but clients will usually accept more recent AppServer releases than JDK releases due to the safety net provided by expensive support contracts. However, the availability of commercial product which is stable enough for adoption is nevertheless an issue. Once that is achieved, clients must verify that the broad mix of technologies present in a potentially heterogenous deployment environment will "play nicely" together. Those clients with homogenous deployments (one or two big name vendors) will potentially be able to adopt EJB 3.0 more quickly.

    So let me revise my suggestion to Q1-Q3 2006, dependent on the degrees of both heterogeneity and risk aversion. Of course, there will be "early adopters" too.

    Kind regards, Robin.
  67. humor is good[ Go to top ]

    I thoroughly enjoyed that opinion piece. Now if only J2EE can take a more practical approach and really make JDO and EJB3 work nicely together, that would make life better for developers. I would be disappointed to see EJB disappear because distributed concepts are hard to grasp or the specification is not flexible enough to ease new developers into the EJB model. Not having a standard for distributed transactions/objects would mean those who need it have to build their own solution, which is far more scary than learning EJB. Atleast in my mind.
  68. Article is Off[ Go to top ]

    As somebody who's done way, way too many EJBs the article is simply off in a lot of places.

    1) Testing with Cactus is hardly "barely tolerable". If you design your application correctly it's possible to write very thorough, very complete unit tests that can deploy, run, and clean-up from a single test. Also, I find the focus on unit testing kind of funny. In real enterprise systems functional testing is a lot more important than making sure a certain class lives up to its contracts. Anybody who is depending on Cactus to tell them if their system is working is already lost.

    2) J2EE is complex. There's really no way around this IMO. I've watched people try to reinvent J2EE too many times over the years and I've never seen it done well. When it comes down to it enterprise computing is just hard. The solution isn't to try and teach every developer everything but to isolate them in little boxes. You have your servlet guys, your entity guys, your jms guys, etc.

    3) The security example is a very poor and dishonest one. 1) You can't reasonably expect EJB to provide you with a security framework that will do 100% of what you need and fulfill everybody else's greatest dreams also. Regardless of whether you use EJB or not, you would still end up developing your own security framework. 2) With a bit of extra design work and liberal use of session facades (which can be hammered to be a type of interceptor) his problem is easily solvable. Restricting access based not just on role but also department is, believe it or not, a well-known problem that's been solved many times before.

    4) Complaining about the use of XDoclet and Cactus and IDEs is a bit silly. These tools represent an insignificant amount of the complexity in any J2EE project.

    5) I like how people equate Spring (a simplistic IoC container, an MVC framework, and a bunch of utilities for various projects like Hibernate) with J2EE. This is just stupid. One is a distributed component framework (including lifecycle and deployment) and the other is a wrapper over the Servlet API. Please be a bit more realistic. The awful truth is that any application that could work as a Spring application can be classified as a JSP/Servlet application and should be thought of as such. The use of Spring is actually irrelevant here.

    6) I test outside the container right now and I'm sure many others do too. We all learned a long time ago not to put complex business logic inside EJBs and instead treat them as component mediators. JSR-175 does nothing that XDoclet can't do right now. Anybody still complaining about "unwiedly deployment descriptors" deserves it.

    7) The point about transparent persistence is the only one that has any real merit and it's hardly clear cut. Gavin King et al are always talking about killing DTOs and what not but I'm not convinced this is a good idea. I don't use DTOs because entity beans can't be passed between tiers, I use DTOs because passing entity beans between tiers is a BAD IDEA. Every tier in an enterprise system should completely encapsulate its underlying data layer. In this case, transparent persistence isn't useful from an architectural point-of-view (you will still end up writing DTOs) and it amounts to little more than syntactic sugar.

    I could go on but I'll stop here. I understand J2EE bashing is now very fashionable but let's try to raise the bar a bit. There are real, architectural problems with J2EE (no standard distributed cache!) and this kind of ranting really doesn't add much.
  69. Article is Off[ Go to top ]

    I like how people equate Spring (a simplistic IoC container, an MVC framework, and a bunch of utilities for various projects like Hibernate) with J2EE. This is just stupid. One is a distributed component framework (including lifecycle and deployment) and the other is a wrapper over the Servlet API. Please be a bit more realistic. The awful truth is that any application that could work as a Spring application can be classified as a JSP/Servlet application and should be thought of as such. The use of Spring is actually irrelevant here.
    So to flip this on its head, should I *only* use EJBs if having distributed components is a requirement?

    Ryan
  70. Article is Off[ Go to top ]

    I like how people equate Spring (a simplistic IoC container, an MVC framework, and a bunch of utilities for various projects like Hibernate) with J2EE. This is just stupid. One is a distributed component framework (including lifecycle and deployment) and the other is a wrapper over the Servlet API. Please be a bit more realistic. The awful truth is that any application that could work as a Spring application can be classified as a JSP/Servlet application and should be thought of as such. The use of Spring is actually irrelevant here.
    So to flip this on its head, should I *only* use EJBs if having distributed components is a requirement? Ryan
    While I disagree with the original poster, who equates J2EE with a distributed component framework (I guess he mistook J2EE for EJB) and apparantly has never worked with Spring, I would answer your question with a big YES. I would not want to endure all the overhead of EJB development when I'm sure my application will never run in a cluster or be called remotely.

    Cheers,
    Lars
  71. Article is Off[ Go to top ]

    The point about transparent persistence is the only one that has any real merit and it's hardly clear cut. Gavin King et al are always talking about killing DTOs and what not but I'm not convinced this is a good idea. I don't use DTOs because entity beans can't be passed between tiers, I use DTOs because passing entity beans between tiers is a BAD IDEA. Every tier in an enterprise system should completely encapsulate its underlying data layer. In this case, transparent persistence isn't useful from an architectural point-of-view (you will still end up writing DTOs) and it amounts to little more than syntactic sugar.
    Why is this a bad idea? If I materialize a Person object from a database, do I need another DTO that represent this same object so I can pass to my presentation tier? Why not have one Person object? I display this in my presentation tier (e.g. web). I can also transparently persist this object. DTO is duplication of effort for no real benefit other than to satisfy an artificial requirement to keep tiers seperate.

    Ryan
  72. Article is Off[ Go to top ]

    D Ocean,

    While I agree that DTOs are often a good idea anyway (because the abstractions your presentation tier uses are different to the abstractions your business tier uses), transparent persistence is *far* *more* than 'syntactic sugar'. It allows you to work with an object model instead of a relational model, simplifying your business logic code immensely. Give it a try.

    The security example is excellent. As you say, you need to develop a security framework for any non-trivial application, but the worst sort of J2EE architect (the type who has read J2EE patterns books, but hasn't read Gamma et. al.) will often say 'you should use JAAS' even when it is inappropriate. I'd like to see your solution to the security problem in more detail.

    Enterprise applications (by which I mean simply systems which are custom developed for a particular business) are rarely so complex that they require distributed transactions, or justify having one team (or even one developer) working on entity beans. A framework must allow a single developer to implement a feature from top to bottom -- imposing unecessary specialisations and communication overheads is not acceptable.

    You may classify applications into 'enterprise' applications and 'JSP/Servlet' applications (incidentally, JSP is another poor part of the J2EE spec), but these two classes of applications have many needs in common (particularly persistence), and these should be met by J2EE in the same way, rather than requiring two different architectures. Do you expect 'enterprise' applications to use entity beans while 'JSP/servlet' applications use something else?

    Tom
  73. Article is Off[ Go to top ]

    D Ocean,While I agree that DTOs are often a good idea anyway (because the abstractions your presentation tier uses are different to the abstractions your business tier uses),
    The only time I have ever seen them "useful" is to solve the Entity EJB "problem" which is usually better solved by not doing EJBs.

    I thought the Presentation layer was to provide a "view" to the business objects (domain). Not sure what needs to be "abstracted". If you need abstraction - use interfaces, etc.
  74. Article is Off[ Go to top ]

    D Ocean,While I agree that DTOs are often a good idea anyway (because the abstractions your presentation tier uses are different to the abstractions your business tier uses),
    The only time I have ever seen them "useful" is to solve the Entity EJB "problem" which is usually better solved by not doing EJBs. I thought the Presentation layer was to provide a "view" to the business objects (domain). Not sure what needs to be "abstracted". If you need abstraction - use interfaces, etc.
    I've used DTOs to contain presentation related metadata, i.e. while the business object has an attribute which is simply a double, the DTO will know whether the user is allowed to update it (or even see the contents), what the title of the field to display it in is, what tooltip is associated with the field and so on. The DTOs can also maintain a long-lived optimistic lock on the domain object (although JDO can do this happily without DTOs).

    So the DTOs feed the presentation layer information about what needs to be displayed (in a way which has no dependencies on the actual presentation technology) which doesn't belong in the business objects. That's the abstraction I was referring to.

    I agree that simply having struct-like copies of your domain objects as DTOs is pointless.

    Tom
  75. Article is Off[ Go to top ]

    Ok. So what you have really isn't a DTO because it does more than just hold "data". More like a 'PBO' (presentation business object) or 'PDO'.

    I understand why you would do what you have done.
  76. Article is Off[ Go to top ]

    I agree that simply having struct-like copies of your domain objects as DTOs is pointless.
    I can say more. I you have struct-like objects as interface for client then you do not need something like domain objects, stuct is domain model for client and tables is a domain model for server. If your domain model is object oriented then you do not need structs. Boths ways a good, but they are useless if both are used at the same time and you need to drop one of them. Probably it is better to drop objects in my practice, because domain model is more "table driven" in "enterpise" or some "online database" (does nothing more than reads/writes data in the most of cases). I do not recommend as solution for all problems, there are a lot of good use cases for OOP, but I do not think it is a good idea to look for a problem just because OOP as a solution for this problem.
  77. uniform persistence service[ Go to top ]

    Do you expect 'enterprise' applications to use entity beans while 'JSP/servlet' applications use something else?
    It is such a succinct point that it is worthy of being repeated.
  78. I like to eat both elephant and chicken, it would be very boring if we only could eat elephant *or* chicken. We need some variations and not a mono culture :-)

    It is funny to see that people complaining about J2EE (elephant) and saying as if POJO/ORM/IOC (chicken) is such a big deal. Folks, if you like to eat a nice tasting chicken check out Enhydra! It has a full POJO/ORM/Very good structure -> Presentation Object, Business Object and Data Object (all POJO), which can be used to handle a huge site thanks to Enhydra Director (Software load balancer with Apache). You also get A plug-in for Eclipse, JBuilder, NetBeans, so that you can develop your web application just in a snap! Just as easy to use as PHP but with the power of Java. Installation is in just one click. Everything Open Source and (the most important thing) Enhydra is already 5 years old (or more, surely older than TSS)! Nothing new here :-)

    So, let's go forward, eat chicken and elephant at the same time, just what you think you would like to eat. Go for MDA, so you have the freedom to eat anything you want. Help AndroMDA (Open Source MDA) developers to develop as many "foods" (cartridges) as we need: chicken, elephant, snake, dog, cat, what so ever you may want to eat :-)

    Cheers,
    Lofi.
    http://www.openuss.org
  79. May I congratulate you guys to have woken up from the temporal insanity, for a while I thought that it was I who was insane. I have only one small complain, the project to port Spring to .NET seems to have stopped of, everybody is working on the new Spring Rich Client Platform instead.

    Many years from now there will still be "concrete EJBists" that claim that EJB is a viable solution at least for some projects. The truth is sad enough that a better solution always can be made with simpler (=better tools). The correct number is not 5% of the projects or even 0.5%. More like 0%.

    Only one other thing puzzles me, why hasn't any vendor presented a commercial Spring like product yet? For instance Caucho? It would be a perfect complement to Resin.

    Regards
    Rolf Tollerud
  80. Only one other thing puzzles me, why hasn't any vendor presented a commercial Spring like product yet? For instance Caucho? It would be a perfect complement
    to Resin.
    Which aspect of Spring? In general, Caucho can't invent APIs and have them accepted like Spring or another open source projects can. Hessian was possible only because we produced an open source Hessian implementation.

    The IoC configuration capability is already part of Resin's configuration file parsing (unless I totally misunderstand the IoC concept). Resin can add transaction boundaries for POJO methods (not released yet, but something we're playing with). But there would need to be some standard before anyone would actually use it. (Although maybe people would use Resin-specific JDK 1.5 metadata, since they seem to be happy having multiple XDoclet tags. Hmmm.)
  81. resin + srping is a good idea[ Go to top ]

    I think we're likely to see companies that want to strive for simplicity package with Spring rather than EJB. It's much more than IOC. The Spring downloads are significant, and ramping up sharply.

    Standardized or no, open source or no, Spring is a great framework that saves real customers (banks, manufacturing, portals, etc) much more productive. It only makes sense for companies like Resin to package with something like Spring. I do think that many will want to ride the wave rather than fight it.

    I think Spring has legs, and I'm basing more and more of my consulting practice on it. I expect others to do the same. While Better, Faster, Lighter Java is not a Spring book, my next one will be.
  82. resin + srping is a good idea[ Go to top ]

    It only makes sense for companies like Resin to package with something like Spring.
    In fact, Resin as web application server and Spring as application framework within a web application are a popular combo. They definitely share a similar spirit in that they are equally lightweight and equally easy to configure.

    Spring also provides explicit support for Caucho's Hessian and Burlap protocols (which are open source). The Spring JPetStore illustrates how to use them for simple HTTP-based remoting needs, as alternative to SOAP via Axis.

    There is indeed no point in duplicating Spring's application-level functionality in a proprietary fashion for each J2EE server. Spring runs nicely on all major J2EE application servers and is freely available, after all.

    Using a configuration style similar to Spring within the server, like Caucho did for Resin 3.0.8, is a different matter. You configure server resources there, not application objects, so this is complementary rather than competing.

    Juergen
  83. Well Juergen you know, in this business we work in you are never allowed to retain a good idea for any long period of time. And since you have been so generous to publish under the Apache license, nothing can stop a vendor from building their own proprietary product upon Spring. It may happen or not happen, whatever it goes: nothing can stop you and Rod from being fixed in Computer History for all time.

    Regards
    Rolf Tollerud
  84. There is indeed no point in duplicating Spring's application-level functionality in a proprietary fashion for each J2EE server. Spring runs nicely on all major J2EE application servers and is freely available, after all.Using a configuration style similar to Spring within the server, like Caucho did for Resin 3.0.8, is a different matter. You configure server resources there, not application objects, so this is complementary rather than competing.
    Exactly. Which is why Rolf's suggestion of implementing Spring and even Bruce's suggestion of bundling Spring don't make sense for us. Resin already has Spring.

    Still, it makes sense to learn from Spring and use some of the ideas to improve our own product.
  85. The truth is sad enough that a better solution always can be made with simpler (=better tools). The correct number is not 5% of the projects or even 0.5%. More like 0%.
    0%? A little unfair I think. Have you ever come across EAI (Enterprise Application Integration)? The idea is that over time an organisation builds ups an enterprise wide service bus, with business service components exposing their interfaces over a network. This way new applications in the enterprise can re-use existing services. Similar to data redunancy but for services. Implement a service once and once only across the enterprise. I've also seen such architectures implemented using Tuxedo which does the same thing using messaging. It appears that much of the disatisfaction with EJBs comes from people implementing "standalone" database applications where the only distribution needed is a web front end. In this case I agree that EJB is an over kill.

    Please bare in mind that we are not all implementing "stove-pipe" type apps. To me enterprise means distributed, service re-use, access security, cross service transactions etc. I could not do all this using servlets and DAOs.
  86. eai[ Go to top ]

    I would subsribe to the ideas about EAI. We are looking at the J2EE tools, as well as the extra-J2EE parts of applications servers as ways to knock down stovepipes. Now it's about messaging and portalizing web front ends. It's also about WorkFlow and issues like that. Greater ideas about integration, such as hub and spoke architectures and transformation of data, workflow kind of stuff. Especially as we see more packages, ERP type things that need to integrate into the business.

    We're not running web services in any large capacity now, that's in a bit of assessment phase. My take on this so far is that you should immediately run away from the folks telling you they are going to solve your problems. That is, it looks more like the lowest common denominator you can run to when other, more performant and secure options don't exist.

    We'll see, I'm sure, web services become more enterprise quality once standards for orchestration and security, and transactions, mature. I think a pre-req for some of these things coming is more and more emphasis on identity management, including provisioning of client side ssl certs for things like ws-security and electronic signatures. Honestly, these are things on my plate, things I'm truly concerned about dealing with. Don't tell me I don't have to deal with them by changing a container. That's why some of this stuff I read on the server side passes me by...

    Cheers,
    MC
  87. eai[ Go to top ]

    I'm glad I'm not alone. Sounds like a lot of people out there are busy building client/Server database apps in Java/J2EE and are not architecting distributed "enterprise wide" solutions. Iagree, the focus should be enterprise and service distribution. Code re-use has failed, service re-use is the way forward (IMHO), EJBs address this well(ish). What is missing is versioning and ways of extending an exisiting service interface without breaking existing client code. Tuxedo adresses many of these distribution issues, yet to be adressed by J2EE but is written in C/C++.

    I think the problem with J2EE is that it is trying to be all things to all men (and women). As someone else mentioned, modularity is an answer. So that you can pick and choose a la carte, instead of being forced to eat the whole elephant in one go. On the JBoss website they propose a vision where a POJO design is "anotated" with cross cutting concerns like distributed, secured, transacted, etc where needed. An AOP Container intercepts and applies AS services.

    I quite like this vision as it would allow people to use just what they need, without needing to understand or even know what they didn't need. As anyone out there implemented/used such a framework? I got the impression that JBoss wasn't quite there yet. Has anyone else come across other ideas which adress the need for modularity?

    IMHO Modularity and decoupling of concerns is the answer to keeping everyone happy.

    Cheers

    Paul.
  88. eai[ Go to top ]

    BTW...

    I don't think that web services offers much promise for intra-company distributed services. But across companies - well thats a whole new ball game. Early days yet I think.

    Paul.
  89. Make it modular![ Go to top ]

    Reading opinions on EJB3 so far I think one thing is certain and it's that people want a modular spec and one which recognizes the freedom of choosing appropriate gun for the current hunt :-)

    In other words people want Spring :-) With Spring you are free to use iBatis and its pedal-to-the-metal approach of using bare SQL for persistence, but you can also use an ORM like Hibernate if the domain model is complex, and possibly other pluggable persistence mechanism.

    Just recognize this pluggability and freedom of choice, make life easier for all these approaches to be embedded into the system, and outsource specific parts of it like persistence for example to separate specs.

    Ara.
  90. To tame the beast...[ Go to top ]

    It is a lot easier to tame an elephant than to tame a hundred chicken.

    It makes me think of the old Monty Python sketch of the guy who wants to become a lion tamer. Man is he surprised if he realises what kind of beast he is really trying to deal with.
  91. To eat the beast...[ Go to top ]

    Yes, but it's a lot easier to eat 100 chickens than one elephant.

    Is this now a metaphor too far?
  92. To eat the beast...[ Go to top ]

    Yes, but it's a lot easier to eat 100 chickens than one elephant.
    ...especially if the food objects to the idea!

    Anyway, I thought the point was that instead of eating the whole elephant one could whoose which sub-set of the available 100 chickens would be more palatable.


    Well, it's going to be a close-run thing. This thread is drawing to a close and yet the JCP has not yet published the JDO 2.0 Early Draft. I'll give them until close of business in California before eating my earlier words....

    Kind regards, Robin.
  93. To eat the beast...[ Go to top ]

    Yes, but it's a lot easier to eat 100 chickens than one elephant.
    ...especially if the food objects to the idea!Anyway, I thought the point was that instead of eating the whole elephant one could whoose which sub-set of the available 100 chickens would be more palatable.
    Nonono, if you go for this metaphor, it would be: It is easier to come up with one recipe for an elephant than with 100 potential recipes for the chickens.

    :-)
  94. To eat the beast...[ Go to top ]

    Nonono, if you go for this metaphor, it would be: It is easier to come up with one recipe for an elephant than with 100 potential recipes for the chickens.:-)
    But isn't variety the spice of life?
    Anyway, I heard that elephant tastes like chicken.
    Even if you come up with a recipe for elephant, how would you cook the thing?
    ...
  95. Eating humble pie...[ Go to top ]

    Ok, I have to admit that my promise of an Early Draft of JDO 2.0 before this thread was done has not been fulfilled. And this thread is done - I even resorted to marking one message as "noisy", and by the time that starts happening on a thread it really is time to move on to the next topic.

    So, I offer my apologies for the lack of a spec by the weekend, and I'll be sure to let y'all know when it becomes available from the JCP.

    Kind regards, Robin.
  96. Great article, well said[ Go to top ]

    I really enjoyed Bruce's article. I just came from a project where we ate a lot of big nasty elephant quite often. Now that I'm on my own and using simpler alternatives to J2EE I'm getting the job done and just plain old having more fun doing it. The only thing to be concerned about when it comes to a great new technology like Hibernate is that fact that it isn't standard (although this is going to change soon with Hibernate). When you start a BIG project you have to ask yourself whether or not this technology will still be alive in 10 years.

    CP
  97. Great article, well said[ Go to top ]

    When you start a BIG project you have to ask yourself whether or not this technology will still be alive in 10 years.CP
    No, you need to ask yourself whether or not this project is "BIG", probably you will find it is a "SMALL" and you do not need any clever technology. Try to drop buzzwords first, it will make project "SMALL" in the most of cases.
    It is not "simple and stupid", it is optimization and I think it must be one of the main IT enginier goals. If I see "BIG" project then I know, me or somebody else failed as enginier to solve this problem, if EJB is a single workaround for this failure then I will use it, but I will not forget it is a workaround in the not "ideal" world of "enterprise hell" and it will be the "legacy" too. I think EJB 3 with "new" ideas and obsolete versions proves my words.
  98. Great article, well said[ Go to top ]

    The only thing to be concerned about when it comes to a great new technology like Hibernate is that fact that it isn't standard (although this is going to change soon with Hibernate). When you start a BIG project you have to ask yourself whether or not this technology will still be alive in 10 years.
    Yes, but the quality and usability of the technology is also important. 10 years of hitting yourself on the head with the same brick might be a bit much... In this case, I think it's pretty clear that Hibernate will be around for a good few years. (10 years is so long in our part of the industry, however, that I won't try any predictions that far out...) OTOH, it's pretty clear that the EJB 2.x entity bean programming model won't be around, except as nasty legacy, for nearly as long.

    Rgds
    Rod
  99. JDO 2.0 Early Draft Published[ Go to top ]

    At last, the Early Draft of the JDO 2.0 specification has been published! I've submitted to TSS a news article which includes the URL from which the draft can be downloaded. Hopefully this will reach the community soon.

    Kind regards, Robin.
  100. EJB security, J2EE security[ Go to top ]

    Bruce Tate wrote:
    <quote>
    For example, take EJB security. Please. More often than not, I needed instance-based security, allowing me to secure a group of invoices based on their memberships in, say, a department or a division. But EJB wanted me to lock down individual methods or classes. This left me in the untenable position of cramming my own programmatic security on top of their mandated declarative version.
    </quote>

    My company found J2EE's role-based security insufficient for our enterprise applications. We decided to build our own instance-level security framework.

    The J2EE 1.4 specification contains a brief note about this topic:

    {{

    J2EE.3.7.2 Instance-based Access Control

    Some applications need to control access to their data based on the content of the data, rather than simply the type of the data. We refer to this as “instance-based” rather than “class-based” access control. We hope to address this in a future release.

    }}

    See also: "Instance Based Security in Java"

    Link: http://www.urbancode.com/presentations/default.jsp