Monson-Haefel Column on New EJB QL Functionality in EJB 2.1

Discussions

News: Monson-Haefel Column on New EJB QL Functionality in EJB 2.1

  1. A new column by Richard Monson-Haefel, looks at how EJB 2.1 has addressed certain shortcomings in the EJB query language (EJB QL) with the addition of several new functions and an ORDER BY clause. He describes these new features, and presents a short list of features and failings that he thinks the next version of the specification should address.

    Read "EJB 2.1 Adds New Functionality to EJB QL"

    Threaded Messages (29)

  2. I understand that Oracle Corportation had representatives in the committee that formulated the 2.0 specification, and that they were pushing to make EJB-QL more like (standard) SQL. It seems like the changes in the 2.1 specification are indeed bringing EJB-QL closer to SQL, and I also get the impression that Mr Monson-Haefel would like the distance between the two to become smaller still. Personally, I think that EJB-QL should be a (fairly large) subset of SQL (and it seems like I'm not alone in this), so I'm wondering why this hasn't happened (yet). Perhaps someone can enlighten me?

    Thanks,
    Avi.
  3. Politics :)

    At first, some people wanted EJB-QL to be everything to all people. That always results in a subset that misses tons of functionality. What if you are doing CMP to some old mainframe system that isn't an SQL database?

    However, since 99.9% of the time developers ARE talking to a RDBMS, we should just say "screw it" and make EJB-QL usable (with sub queries and everything else that is needed).
  4. <dion>
    However, since 99.9% of the time developers ARE talking to a RDBMS, we should just say "screw it" and make EJB-QL usable (with sub queries and everything else that is needed).
    </dion>

    I agree. This is reality. However, it's an argument for using SQL or a proven O/R mapping approach, and ditching EJB QL altogether. One of the problems with EJB QL is that it pretends it isn't an O/R mapping solution, whereas it nearly always is in practice. The differences between SQL-based RDBMS systems and legacy systems is so great that trying to use the same abstraction will always lead to an inefficient lowest common denominator.

    Rod
  5. Congratulations to Richard on an excellent article. However, it serves to highlight some of the serious problems with EJB QL and hence EJB 2.0 entity beans.

    <richard>
    Obviously, EJB QL is a lot better off with the ORDER BY clause and the new aggregate functions, but the query language has a way to go before its functionality is complete - if that is even possible.
    </richard>

    So almost two years down the track from EJB 2.0 we'll still be playing catch up. There are many things that EJB QL still can't do efficiently or portably.

    I still have grave reservations about the whole notion of a dedicated EJB query language. The cost of the portable abstraction is very high in functionality and potentially efficiency. The business value of database portability is questionable in most projects. Entity beans in EJB 2.0 are extremely complex, yet they still lack basic functionality. While important features are lacking, the only alternative is to use proprietary alternatives to supplement EJB QL. This is less standards-based than SQL, which is already a familiar skill.

    I think there's a strong case that entity beans have proven a dead end. In my new book, Expert One-On-One J2EE Design and Development, I discuss data access alternatives, including JDO, that I feel are much more promising and workable.
  6. Rod,
    I have pleaded my case for EJBs elsewhere, so I will only say that I do disagree with your assessment of EJBs being a deadend and that such statements mis-represent what you _can_ do with them. Hopefully your book addresses where it is appropriate to use them as well.

    Cheers
    Ray
  7. Ray,

    I suggested that entity beans and EJB QL are a dead end, not EJB as a whole. I think EJB is often used without good reason (it's not always appropriate), but EJB certainly has a place and is a good solution for some problems. In the book I try to examine the arguments for and against using EJB dispassionately. The sample chapter on the Wrox site discusses how to decide when EJB is appropriate.

    Rod
  8. Good job Rod -
    You make excellent points, indeed. My wish list for EJBs (and entity beans in particular) is to replace the persistence mechanism with something that makes more sense (JDO for instance) and/or to add a straight persistence layer to the J2EE spec (again, JDO as an example). Where people make mistakes and where EJB is completely misused is when they attempt to use them as their persistence layer _only_. And as you know, the potential for trouble is great in that scenario.

    Anway - very good points. Perhaps I'll even go buy your book.

    Cheers!
    Ray
  9. I suggested that entity beans and EJB QL are a dead end,

    > not EJB as a whole.

    Java is a dead end too. Hmmm at least that's what I read circa 97/98 :)

    Regardless of individuals' wishes... entity beans will not die - this simply isn't realistic. Rather through the efforts of people like Mr. Monson-Haefel (if only serving as catalyst) they will continue to improve past their current viable state.

    I admit I have never used JDO, however I have noted comments from those who have and it's not encouraging. I think JDO benefits from its relative obscurity, but take the TSS news article posted on November 8th as an example... "db4o has just released the first final of it's JDO competitor".

    JDO competitor?

    My gut tells me once you get into JDO - you see it has compromises as well. What do you do then? Reject it as well? Is everyone who finds JDO less than perfect after ditching Entity Beans then going to start their own little church? Can we not just agree that impedence mispatch is a bitch and that if we want a standardized Object-Relational componentized framework there's going to be some worthwhile pain in maturing it?

    At this point I see no reason to invest in JDO when:
    a) I'm implementing a component (EJB) based architecture already. Yes yes yes - EJB should not be used on all projects, but I think it's interesting that 2 of the four architectures in the sample chapter use EJB outright and I think the web services architecture could be EJB 2.1 based as well (so ~3/4 use EJB).
    b) Entity beans are WORKING WELL.
    c) Entity beans are a central component of the EJB, and therefore J2EE specification - and they aren't leaving the party.
    d) I don't see JDO gaining much traction among the 'big' vendors.
    e) the N+1 query problem (and therefore IMO most of the speed issues) are mitigated by my container's optimizations
    f) I love the container managed relationships... it makes writing business logic at the services tier a breeze. If I'm not mistaken, JDO has something similar though.

    With a mature container CMP is performant and robust. Yes proprietary extensions are currently useful... but is it really a surprise that the next iteration of the spec included an "order by" clause?

    Coding entity beans by hand (sans whiz bang GUI tool... if such a thing exists yet) essentially becomes a copy and paste affair after a few initial beans have been created. And if "I" can efficiently develop entity beans then .... well let's just say there's reason for hope :).

    Entity beans reduce (but certainly don't eliminate) data aliasing concerns within the enterprise and they encapsulate the CRUD lifecycle and PK association in a way that seems pretty straightforward to me.

    Rod - congrats on what looks to be an excellent book. No doubt there will be a couple copies on hand here before long... which makes me a customer. And "the customer is always right"! :)

    cheers,
    Markus
  10. <quote>
    Coding entity beans by hand (sans whiz bang GUI tool... if such a thing exists yet) essentially becomes a copy and paste affair after a few initial beans have been created. And if "I" can efficiently develop entity beans then .... well let's just say there's reason for hope :).
    </quote>

    I'm currently working on a project using the AOP framework Nanning (http://nanning.sf.net) and the OR-mapper OJB (http://jakarta.apache.org/ojb) as a replacement for the entire EJB-component model. Previous to that I've worked with EJB from version 1.0 and onwards on several large projects.

    I can tell you this: You don't know what you're missing.

    I used to be a strong EJB-believer, just like you. But not a long time ago I decided to reevaluate my entire notion of how an architecture for an enterprise system should look like. Instead of just following the industry-standard blindly I decided to add things when I needed them and solve things the simplest possible way. The above architecture (plus Servlets) is basically what we ended up with. We never want to go back again!

    EJB may have been a good idea from the start but it ended up being bloated by large-corporate politics, just like CORBA. It's gonna end up the same way as CORBA too, down the drain. Let it go, it's a dead end. The future lies in open-source and AOP.
  11. AOP: Nanning[ Go to top ]

    Jon, Nanning looks interesting, but is there a download?
    Rod
  12. AOP: Nanning[ Go to top ]

    <quote>
     Jon, Nanning looks interesting, but is there a download?
    Rod
    </quote>

    Not yet, you have to build it from the CVS with Maven (http://jakarta.apache.org/maven). Nanning is very young and some of it is moving to Jakarta as we speak.

    Also you have to code all of your interceptors for yourself. To handle transactions and so on. Incidently these are actually quite easy to build. The stuff we're using is optimized for OJB and will hopefully end up there in the end. Nanning will hopefully also offer a set of reusable interceptors that mirror the functionality of EJB (but without the hassle).
  13. AOP: Nanning[ Go to top ]

    The combination of Nanning and OJB looks promising. So using Nanning interceptors you can build your objects without those "database" specific actions (begin, commit transactions, etc.) what JDO and all those OR mappers require you to do. Your business objects can be implemented in EJB way (descriptive transaction atts.) thanks to Nanning.

    This is not bad, I think ;-) My personal requirements are:
    - Location transparancy of my business components.
    - Descriptive transaction and security atts.
    - For my business component I only have to write *1* Java class for my session object and *1+1* for my entity object and each get *1* deployment descriptor. Not more than this. And *very* easy to understand!
    - Support for syncronous, asyncronous, schedule components.
    - Usable within many containers. No vendors lock-in.

    IMO, EJB (Session and Entity) has reached a lot. They are not perfect, but they can evolute. I hope in the future that the definition of session and entity components can be inserted directly in the Java language specification. The article from Robin Sharp (http://www.softwarereality.com/programming/component_oriented.jsp) gives you a very good explanation about this.

    LoDe.
    http://openuss.sourceforge.net
  14. AOP: Nanning[ Go to top ]

    <quote>
     The combination of Nanning and OJB looks promising. So using Nanning interceptors you can build your objects without those "database" specific actions (begin, commit transactions, etc.) what JDO and all those OR mappers require you to do. Your business objects can be implemented in EJB way (descriptive transaction atts.) thanks to Nanning.
    </quote>

    Yeah, you have your interceptors that does all this infrastructure-management. You code your domain objects like POJOs (plain old java objects, no magic here) and Nanning takes care of the rest. The only requirement Nanning have is you separate interface and implementation, its in between these that Nanning inserts its interceptors. Sort of like EJB but one major difference: The implementation actually has to "implement" the interface so you get compile-time-checking.

    But there's no deployment descriptors either. Nanning supports runtime attributes (sort of like C#, or XDoclet but runtime) which means you just declare transactions and security using JavaDoc-like-tags. The interceptor reads the tags and does what they're supposed to.

    So this is the main goal of all this: Simplicity. No hassle.

    But this also gives you so many other things. Like portability, because you use very little of an application-servers features. And unit-testing, you can execute your "beans" easily within an IDE, or in JUnit.
  15. AOP: Nanning[ Go to top ]

    I really love the idea of attributes (and AOP is the future). However, what should be attributes (tied to code), and what should seperated (e.g. in xml descriptors).

    If we build a component, do we want to force the security and transactional settings in the source file itself?

    In many ways I like this, as how many times do you see people screwing up the transactional settings, and the entire app doesn't work like it should. This can stop "the deployer" from shooting themselves in the foot.

    I wonder if there is ever a need to have multiple sets of attributes though. Of course, we can always allow for both, and set out rules (if really needed for a particular type of attribute)
    When attributes are really part of the system, and then can be changed at runtime we can just go in via reflection and change whatever we want too!

    The future looks bright.
  16. AOP: Nanning[ Go to top ]

    <dion>
     I really love the idea of attributes (and AOP is the future). However, what should be attributes (tied to code), and what should seperated (e.g. in xml descriptors).
    </dion>

    It's fairly easy to distinguish them. One of the many reasons why EJB deployment descriptors are so capricious (besides the fact that they are in XML) is that they mix runtime and deployment settings.

    In my opinion, any descriptor that is tied to Java code (transaction attribute, finder, etc...) needs to be specified in the Java source, as close to the code it pertains to as possible.

    Any descriptor that is related to deployment (JNDI name, datasource, etc...) should be externalized.

    And then there are settings that are neither (e.g. create-tables, client-jar, etc...) that the developer should be free to put anywhere they like.

    In EJBGen, this is achieved by variables: you can substitute any part of your Javadoc tag with a variable such as

    @ejbgen:jndi-name
      remote = ${remote-jndi-name}

    and then specify this variable in a property file, allowing you to share settings across several EJB's or have settings that are common to all.

    Ultimately, I agree that AOP and frameworks such as Nanning offer fascinating possibilities (especially with hacks such as using runtime attributes to get rid of the ugly regexp expression to match the interceptors), *but* -- and it's a big but -- the devil will be in the details. Anybody who has ever implemented a CMP engine will probably agree :-)

    AOP replacing EJB's? Maybe, but it's going to be a long and hard road.

    --
    Cedric
  17. AOP: Nanning[ Go to top ]

    that they mix runtime and deployment settings


    I agree. There should be a distinction.
    E.g. The "linking" of home, component interfaces and bean implementation dont need to be specified externally.

    >> In my opinion, any descriptor that is tied to Java code
    >> (transaction attribute, finder, etc...) needs to be
    >> specified in the Java source, as close to the code it
    >> pertains to as possible

    The only counter-example to this that I can think of is the situation where you actually want to deploy the same EJB more than once - but with different settings...

    While I dont find working with the raw XML DD's particularly entertaining, I have found I prefer them to other generation-style approaches (used by IDE's and XDoclet-type tools).

    -Nick
  18. AOP: Nanning[ Go to top ]

    In my opinion, any descriptor that is tied to Java code

    > (transaction attribute, finder, etc...) needs to be
    > specified in the Java source, as close to the code it
    > pertains to as possible

    Cedric, I've long thought this, and I'm glad to be in such good company. I've never understood how it made sense to separate transaction attributes in particular from source code. It's crazy to imagine that these can be administered in a separate role from the bean developer role...it can completely break business functionality.

    Rod Johnson, author of Expert One-On-One J2EE Design and Development
  19. TX attributes and aspects[ Go to top ]

    I've never understood how it made sense to separate

    > transaction attributes in particular from source code.

    It was a failed experiment, and I think you can trace it back to Mirosoft Transaction Server 1.0, which had the first idea of transaction attributes (though for the whole COM component, EJB generalized this to a per-method level).

    The major reason MS did it extrinsically was because COM didn't have a rich system of metadata, so had to create a very elaborate interception framework. In hindsight, it's a bit interesting that Vlada Matena didn't pick up on this when he wrote EJB 1.0 (but then again, EJB 1.0 didn't even have XML, so in a sense the attributes COULD be in the code :)

    I think the AOP-style approach for certain classes of problems will probably be preferred going forward.


    As for EJB-QL, the main problem with it is that it's just not expressive outside of a domain of relatively trivial queries. It also wades into some murky conceptual waters with its mix of predicate logic and object reference traversal. If they include subqueries some day (and indeed they probably should), it's going to be mental hell to map between correlated predicates and pointer traversal (believe me - i've tried with WL 7 QL).

    So, what's the solution? Perhaps the only one that works that I've seen is the WebObjects EOF or Topolink appproach - give a framework for 70% of basic queries, and allow the developer to write plainjane SQL for the other 30%. Almost all decent CMP containers do this anyway, why not make it spec explicit? (and for non-sql persistence engines, just imply it's a callprogram instead of a stored proc).
  20. A little late to the party[ Go to top ]

    But for those wanting similar functionality to EJBQL but a little more flexibility (not limited to EJB objects) then try: JoSQL (http://josql.sourceforge.net). But you do have to get ALL the objects yourself...
  21. Only someone who has not tried JDO (or similar persistence solutions) could think that: "they (entity beans) encapsulate the CRUD lifecycle and PK association in a way that seems pretty straightforward to me".

    I strongly urge you to give JDO a test drive.

    Personally, if the 'big' vendors are heading one way, I usually look the other. If persistence is a commodity (and so easy that anyone can do it without big vendor tools or support) then where's the money for them?

    It is not in any big vendor's interest to invest heavily in a technology that is simple to use. EJBs, on the other hand, contain endless money making opportunities for vendors to help you navigate the nightmare of (unnecessary) complexity.
  22. It is not in any big vendor's interest to invest heavily >in a technology that is simple to use. EJBs, on the other >hand, contain endless money making opportunities for >vendors to help you navigate the nightmare of (unnecessary) complexity.


    I could not agree more, as the matter of fact it got me thinking and I find it is an essence of J2EE and where it is going and why it has a lot of fear from .Net.

    The corportation are entities designed only to make money. It may or may not align with delivering simple productive solutions.

    There is fundamental difference in the way the ecosystems work. Microsoft is "use it, use it a lot" there is rather small recuring fee that benefits them when if the use is as wide spread as possible - so their objective is to let customers quickly develop applications on as many Windows boxes as possible. So simplicity matters most, scalability to lesser extent.

    In J2EE the runtime fee is not that high compared to complexity (development cost) of the software, but there are endless opportunities to cross-sell top of the line big-iron boxes, sophisticated IDEs for 5k a seat, and tons of CONSULTING.

    This is why Java still runs slow on Linux, the open source is not fully recognized (see JBoss) and the specs allways assume that 'in the future vendors tools will simplify the process'.

    My $.06
    Michael
  23. Hello Markus

    You say you have not used JDO, yet you condemn it.

    However, let me list out some of the problems found in EJB especially Entity Beans (both BMP and CMP) which are not present in JDO. And the nice thing is, you can also use JDO to provide a persistence layer for EJBs.

    Here goes ...

    <b>Issues with using Entity Beans for Persistence</b>
    The following points deal with problems associated with Entity Beans in general.

    1. Entity Beans are best suited for coarse-grained business components; they should not be used to represent fine-grained objects. Unfortunately, Entity Beans are only suited for coarse-grained persistent objects and not for fine-grained persistent objects. According to Sun, "Entity beans are not intended to represent every persistent object in the object model. Entity beans are better suited for coarse-grained persistent business objects." (Source: http://developer.java.sun.com/developer/restricted/patterns/AggregateEntity.html).
    2. Avoid mapping your object model directly to the Entity Bean model.
    3. Avoid mapping your relational model directly to the Entity Bean model.
    4. Entity Bean to Entity Bean relationships introduces severe performance penalties. This often results when you directly map your object model or relational model into an Entity Bean model.
    5. Do not store an object graph of Entity Beans
    6. The semantic differences between local (pass by reference) and remote (pass by value) invocation introduces a lot of issues even if some of the flaws have been addressed in the EJB 2.0 specification.
    7. The lack of any meaningful support for inheritance is also a cause for concern.
    8. Persistence and query functions have to be usually hand-coded (in SQL with JDBC) or described by hand (in Enterprise JavaBeans Query Language -EJBQL- which stems from SQL).
    9. There are concurrency issues endemic to the EJB Threading Model.
    10. Gross inefficiencies are possible when manipulating large datasets.
    11. Inheritance Issues: True inheritance has never been possible with Entity Beans. This is because EJBs were always intended to be self-contained components as opposed to domain objects. Even though code sharing can be accomplished by inheriting from entity bean classes or by inheriting from remote interfaces, true inheritance with the overall component is absolutely not possible. By that I also mean true Java inheritance – a client cannot down-cast or up-cast and entity bean’s EJBObject stub to a parent or subclass, etc.
    12. Managing Object Identity issues: Each Entity Bean has to implement a Primary Key class. If JDO were used, the implementer can have a choice of using either Application Managed Identity like Entity Beans, or Data-store Identity. JDO can also manage Object Identity on its own using the Data-store Identity approach.

    <b>Issues with using BMP Entity Beans for Persistence</b>
    The following points deal with problems associated with Entity Beans that use Bean Managed Persistence.

    1. Data Store Connection Issues: The Bean implementer has to implement code in the Entity Bean that connects to the data store and loads and retrieves data (all the different ejbXXX methods). This happens transparently if a JDO implementation were used.
    2. Portability Issues: Entity Beans with BMP are assumed to be portable if developers embedded their SQL statements into external resources, and used java.sql.DataSource objects provided by the container to access these external SQL statements. However, this overlooks some scenarios where this approach may not be as portable as we were led to assume. One of them is the case where the implementer may want to switch the Bean implementation to use, say, scrollable Prepared Statements to speed-up their implementation. The whole persistence mechanism has to be re-coded. Another scenario is that it doesn’t help very much if the implementer wanted to move from using a Relational Database to an Object-Oriented Database that may not understand JDBC. In such a case too portability is lost as the persistence part has to be rewritten once again from scratch. This is not a problem with JDO because persistence is transparent in JDO, and JDO was intended to persist Java objects in a transactional data store (be they RDBMS, or ODBMS, or flat-files) without the need to explicitly manage the storage and retrieval of individual fields.
    3. No Lazy Data Loading: By virtue of coding an ejbLoad method, we ensure that the whole object is loaded into memory completely when the EJB container invokes this method. However, a JDO implementation would use Lazy Data Loading and would only load those persistent fields defined in the Default Fetch Group (DFG). Other fields get loaded as they are referenced.
    4. Relationship Implementation Issues: Relationships between classes have to be manually implemented. It’s not possible to access other related EJB objects directly. We have to implement code that goes through the Home Interface of the related object to invoke them. This is not a problem with JDO implementations as JDO provides automatic navigation between persistent domain objects in the model. With JDO, there is no extra code that needs to be added by the implementer.
    5. No Caching support: Unlike Container Managed Persistence, there is no guarantee that all database calls go through a singleton layer below. This makes it difficult to implement an efficient caching scheme. This is not a problem when using a JDO implementation as JDO specifies the presence of an object cache associated with each Persistence Manager.


    <b>Issues with using CMP Entity Beans for Persistence</b>
    Even though EJB 2.0 Container-Managed Persistence is touted as the ultimate in Persistence support, it is lacking in many respects when compared to the level of services offered by JDO. The following points deal with problems associated with Entity Beans that use Container Managed Persistence that are not present in JDO.

    1. All the EJB-QL problems pointed out in Richard Monson-Heifel's article.
    2. EJBQL definition in Server-side Descriptors: As all EJBQL queries are defined in deployment descriptors on the Application Server, it is impossible for a client to use client-side query functionality. For example, a method like findObject(Query query) does not exist.
    3. No Lazy Data Loading: With the current specification, it is not possible to configure lazy loading of large result sets from the client. There is no point in using a findAll() method which may return a large result set of beans if you just need to access a couple of them. It is also possible that one may reference a huge collection of other beans from one and access only a few beans from the referenced collection. This will have a very telling affect on performance.
    4. No support for Fetch Groups: It is not possible to tell the EJB Container to selectively load relationships rather than loading everything when a bean is accessed. The only exception to this is BEA WebLogic’s CMP container.
    5. No Raw ResultSets: The resulting Result Set as the result of running an EJBQL query will have to contain EJBs. This is really important as reports will need to access an intersection of bean types, and then select a property from there.
    6. No Access to Statement Generation: ANSI SQL has to be used for statement generation (for INSERT, SELECT, UPDATE, or DELETE operations). The only exception is stored procedures. It is not possible to use other SQL enhancements provided by your data store provider to enhance performance.
    7. Database mapping is too simple: The default CMP implementation mapping of One Bean type to One Table and One Bean Instance to One row is too simplistic. CMP Entity Beans provides no way to customize mapping strategies.

    That does not mean JDO has no problems, but they are not that significant. Here are a couple of them.
    1. Query Language Issues: JDO Query Language (JDOQL) is totally different from EJBQL. Additionally, during query execution, additional parsing processes are required making it more resource intensive than existing object oriented query languages.
    2. Byte-code Enhancement vs. Source-code Enhancement: A lot of people have expressed severe objections to byte code enhancement. They don't like things being done to their code which they can't see in the source. However, the JDO specification itself does not prescribe how the modifications are to be made; only the contract that is to be supported. JDO implementations like hywy’s PE:J (http://www.hywy.com/) that provide Source-Code Enhancement however, address these concerns effectively.

    As for why major App Server vendors have not supported JDO, that's for a whole different reason which I don't want to get into unless I have to.

    Don't get me wrong. I am not against EJB. It's a great technology, and I've been a strong supporter since EJB first came out in '98. I was one of the first to write about EJB (along with others like Tom Valesky, Richard Monson-Heifel, Ed Roman and others), and one of the early evangelists of the technology in JUG meetings and my site has been providing EJB articles to readers for a long time.

    I love both EJB and JDO technologies. There is always a place for each of these technologies. There is no point in condemning a technology outright as has become the trend these past few days.

    Cheers
    Gopalan.

    Co-Author of:
    1. Professional JMS (Wrox Press)
    2. Enterprise Java Computing : Applications and Architecture (Cambridge University Press)
    3. The Awesome Power of JavaBeans (Manning Publications)
     
    ________________________________________________
    Copyright (c) 2002, Gopalan Suresh Raj. All Rights Reserved.
    Visit me at Web Cornucopia at http://my.execpc.com/~gopalan/
     
    Web Cornucopia - The Ultimate Resource for developing Distributed, multi-tier, Enterprise Solutions using Java/J2EE, CCM/CORBA 3.0, COM+/Windows DNA, The Microsoft .NET Framework, and all their related technologies.
  24. Gopalan - come on... I didn't condemn JDO. I stated I had never used it precisely so that it couldn't read as a condemnation on technical terms!

    I did however point out that there are others already criticising it (ie. the JDO 'replacement' news article posted on the 8th).

    My point was essentially 3 fold:
    1) Entity beans ... while not perfect... WORK and I see no point in leaving them.
    2) It's unrealistic to think they will 'die'.
    3) I'm observing a splintering in support outside of Entity bean use for other O/R frameworks. It doesn't matter which one you choose, someone will come along claiming framework X kicks its ass. In the meantime entity beans continue to improve.

    I'm finding your list of 'problems' with Entity beans are more along the lines of discussion points... and none of them change my generally positive experience with them.

    I understand that as a professional I have a responsibility to develop with reasonable attention to which framework I've adapted, and I certainly respect the opinions of my peers - however at the end of the day I need to get some work done - instead of just continually (re)evaluating frameworks. Appropriate use of entity beans - especially CMP 2 on BEA - gets work done... I wish it a long life.

    > EJB 2.0 Container-Managed Persistence is touted as the
    > ultimate in Persistence support

    Who? Where?

    cheers,
    Markus
  25. Hello Markus

    I now understand where you were coming from ;o) I was not professing that you use JDO as opposed to EJB either. Like I said in my original post, I love both these technologies.

    Cheers
    Gopalan.

    Co-Author of:
    1. Professional JMS (Wrox Press)
    2. Enterprise Java Computing : Applications and Architecture (Cambridge University Press)
    3. The Awesome Power of JavaBeans (Manning Publications)
     
    ________________________________________________
    Copyright (c) 2002, Gopalan Suresh Raj. All Rights Reserved.
    Visit me at Web Cornucopia at http://my.execpc.com/~gopalan/.
     
    Web Cornucopia - The Ultimate Resource for developing Distributed, multi-tier, Enterprise Solutions using Java/J2EE, CCM/CORBA 3.0, COM+/Windows DNA, The Microsoft .NET Framework, and all their related technologies.
  26. EJB QL is moving too slowly to be a winner. I'm mystified by the desire to create a portable querying language. Projects are always delivered against a particular database and need to be able to take advantage of the features that it delivers. Sure, some people will win with the portability but re-writing queries is not the biggest deal when switching databases. Meanwhile M$ is laughing all the way to the bank.

    I find Sun takes portability to the extreme and well beyond any sensible limits. EJB QL suffers same problem as people who try to create a single tool for both Swing and web work - the paradigms are different and require different solutions. Lowest common denominator doesn't cut it. People are using EJBs because they want scalability and performance, Dammit! :-)

    Just look at the bunch of compromises that EJB represents. People will use it because Sun and vendors have backed it, but anyone who's used alternatives such as JDO knows where the future lies (for persistence at any rate).
  27. EJB QL is moving too slowly to be a winner. I'm mystified

    > by the desire to create a portable querying language.
    > Projects are always delivered against a particular
    > database and need to be able to take advantage of the
    > features that it delivers.

    I couldn't disagree more. The new CocoBase 4.5 version that was just released today uses the EJBQL as a universal
    querying language. We chose EJBQL as the high level language because it doesn't do 'too much', like OQL tried to, and yet it is quite expressive for querying relationship information.

    The CocoBase version however is based on 'maps', which can under the hood express much more complex underlying behaviors for SQL, and can hide the differences between different databases and sql specific requirements. Your statement doesn't take into account that most enterprises are heterogenous, and the maintenance costs for your approach becomes prohibitive in those environments. A tool like CocoBase that lets you issue an 'abstract' ejbql query that behaves identically data-wise on both Oracle and Microsoft - even when the physical database models and SQL syntax themselves are quite different. This feature is important to lots of enterprise companies who are interested in the efficiency of their developers. At least ones that don't like wasting money like it...

    Your assumption also forgets component vendors and decentralized projects. It also forgets the need to express queries in ways that don't match the physical data model. The approach you suggests requires developers embed the SQL and therefore the physical sql/data model in application code, making applications fragile, and optimizations by DBAs too difficult to be practical. If you're trying to sell more copies of a database because applications run slowly and it's too expensive to fix them, your approach is very valid. An abstract querying model is however VERY useful for separating this physical layer out of application logic, and for re-using both code and mapping information. It is useful for a lot more than you would believe on first glance.

    You might want to have a look at the CocoBase white paper on querying and look at how EJBQL can be used effectively for enterprise development. Oh, and our implementation also includes the OrderBy feature from EJBQL 2.1 even though it was draft at the time we created the system.

    Oh and I almost forgot the most important point, the CocoBase EJBQL implementation works for CMP, BMP, Session beans, JSPs and Standalone java and Transparent application persistence. It doesn't require an app server to be used, and the queries are compiled on the fly for your specific database maps with our high optimized EJBQL parser.

    I hope you'll change your opinion on EJBQL once you've reviewed how CocoBase uses it... In my opinion, the problem is that vendors like those involved with evolving the spec try to place too much in the EJBQL syntax itself, instead of having the vision to do something like CocoBase does, which is to keep the EJBQL syntax very standard, but to still allow all of those features in a lower level mapping design...

    The whitepaper can be found at:

    http://www.thoughtinc.com/dynamic_universal_querying.pdf

    Just my $.02

    Ward Mullins
    THOUGHT Inc.
    CTO
    http://www.thoughtinc.com
  28. You've drawn far too many (mostly invalid) conclusions from what I said. Nowhere have I said you should aim to embed physical model information in source code.

    Look, if you want maximum performance you need to use vendor-specific features. Period. Sure there are projects where portability or heterogenous environments are very important. However, it's a fact that these are in the minority.

    In general, of course it is a good idea to abstract. What I'm saying is:

    1) Abstraction always has a performance cost
    2) EJB QL doesn't have sufficient syntax to express necessary queries
    3) Most projects don't give a damn about portability per-se but _do_ give a damn about performance

    In particular I've observed a massive disconnect between the message from Sun and (some) vendors on portability and what is important "on-the-ground". In practice people don't change their database vendors and data models every few months. Instead they commit to technology agreements and long-term plans and aim to extract the best value from the proprietary technologies they've invested in. That means vendor-specific extensions, SQL, etc. etc.

    Now maybe CocoBase 4.5 is the best thing since sliced bread. I don't know. However, I can't take your word for it as you have a vested interest in it - in other words "you would say that".
  29. <tom>
    I've observed a massive disconnect between the message from Sun and (some) vendors on portability and what is important "on-the-ground". In practice people don't change their database vendors and data models every few months. Instead they commit to technology agreements and long-term plans and aim to extract the best value from the proprietary technologies they've invested in.
    </tom>

    I agree. The assumption that portability is essential can be hugely costly. Database portability is an unusual business requirement, not an article of faith. I've been arguing this in message boards for a while, as well as in my new book. Microsoft must be delighted at how J2EE developers are so eager to take on a tough challenge that is usually unnecessary.

    Also, entity beans *don't* deliver true database portability, as they're often used. If you have one entity bean per table,
    (a) you don't have a true object model, just a fake object model that's really a relational model
    (b) you've tied lots of Java code to your database schema. For example, even session EJBs that use your entities are tightly coupled to the RDBMS schema. If you ever want to change your schema, or change to another database in which a different schema may be advisable, you're in big trouble.

    Rod Johnson, author of Expert One-On-One J2EE Design and Development
  30. Richard, I was suprised to see the absence of Dynamic Queries in your article.

    To my mind, one of the glaring shortcomings of the Stored-Proc-style interface of finder/select methods is the fact that it is inflexible when it comes to making search-like queries (where you dont know up-front what you are going to query on).

    This forces you into writing numerous finder-methods - which leads to the same problem as you have with stored-procs (ie you end up with many of them - all similar). - OR you step outside of CMP for this.

    I know Weblogic have provided a facility for Dynamic queries - but are we going to see something similar in the standard?

    Do you see little demand for Dynamic Queries? Interested on your views.

    -Nick