EJB 2.0 final specification released


News: EJB 2.0 final specification released

  1. EJB 2.0 final specification released (31 messages)

    Along with the release of J2EE 1.3 earlier this week, the EJB 2.0 final specification has been posted. Finalized in this version are message driven beans, enhanced CMP, Local Interfaces and more. EJB 2.0 brings major changes to the platform that will impact the way we design EJB apps, but what features do we still need for future versions of the spec?

    Download EJB 2.0 Final specification.

    Threaded Messages (31)

  2. I can think of a couple off of the top of my head:

    -- Order-by clause for EJB-QL
    This is a no-brainer. Who here doesn't use SQL order by in BMP in order to avoid having to spend code and cpu cycles sorting objects? CMP developers should not have to go through this hassle.

    -- Bulk Load Flag for CMP finders
    I think we should have a deployment descriptor flag that toggles whether a CMP engine should bulk load all the entity beans resulting from a finder call instead of resorting to N+1 database calls. Basically, we should have the functionality of Gene Chuang's Fatkey pattern built into the spec. :) Every CMP vendor is going to support this anyway, may as well make it portable.

        More importantly, developers should realize some important changes in EJB design paradigms for EJB 2.0. I write this in hopes that developers beginning new projects won't waste time and code implementing workarounds to problems with EJB 1.X that have already been corrected in EJB 2.0:

    - The Aggregate/Composite/Coarse-grained entity bean pattern is now deprecated. Entity beans can and should be light weight and fine grained thanks to local interfaces.
    - There is no longer such a thing as a dependent object. Creating dependent objects with Composite entity beans is only possible in BMP anyway, at the expense of tons of tedious plumbing code.
    - Relationships between entity beans is now encouraged, not discouraged. Many popular books on EJB design recommend building monolithic entity beans that manage internal object graphs of dependend objects instead of being part of a larger graph of entity beans.
    -Value Objects should no longer be used to read data in and out of entity beans. Instead, they should be used *only* for passing data between the client and Session Facade. Entity beans should only be accessed via get/sets on the Local Interface or if applicable with a Generic Attribute Access interface.

       Many recent books on EJB have been written with EJB 1.X paradigms in mind, and do not translate well to EJB 2.0. In my EJB Design Patterns book (read review chapters online: https://www.theserverside.com/resources/patterns_review.jsp) all the patterns are written from the onset with EJB 2.0 paradigms.

  3. EJB 2.0 final specification released[ Go to top ]

    Excellent comments, Floyd! Also, with the EJB 2.0 CMP relationship, do you see any need for a 3rd party O-R mapping tool like TopLink or CocoBase?

    BTW, when will your and Ed Roman's books come out? I hope it is before the end of the year.
  4. EJB 2.0 final specification released[ Go to top ]

    I think Ed's book will be out before the end of the year. Mine will be out by February.

    >Excellent comments, Floyd! Also, with the EJB 2.0 CMP
    >relationship, do you see any need for a 3rd party O-R
    >mapping tool like TopLink or CocoBase?

       The CMP spec is essentially replicating the features that these vendors implement, but I think there will always be a need for these products. I don't think a J2EE vendor will ever do a better job at OR mapping than Toplink or Cocobase, who have been doing this for years.

       What I see happening is that people will use their app. servers CMP engines for entity beans, since the 2.0 spec is pretty complete. Where people will use the O/R mapping tools is when they don't want to use entity beans, and just want a nice plain java object model behind their session facades.

       I suspect that most people will choose JDO for this, which may end up impacting the sales of Toplink and Cocobase, since they seem havn't announed any plans to support JDO. Oh well, their loss...

  5. EJB 2.0 final specification released[ Go to top ]

    <   I suspect that most people will choose JDO for this, which may end up impacting the sales of Toplink and Cocobase, since they seem havn't announed any plans to support JDO. Oh well, their loss...

    That's not quite accurate. I recently went to a presentation by Craig Russell (the JDO spec lead) and I remember him mentioning that Toplink was going to ship a *partial* implementation of JDO. The partial part comes from the fact that Toplink doesn't seem to agree with everything that is in the JDO spec (they're not the only ones feeling this way).


  6. EJB 2.0 final specification released[ Go to top ]

    > Order-by clause for EJB-QL
    Definitely a no-brainer. This is esp required for select methods.

    Also :

    1) More detail in the area of the spec surrounding message driven beans and destinations.
    Most MDB implementations only support a 1-destination-per-mdb deployment (though this is not limitation imposed by the spec). However, there are quite a few applications (eg market data feeds in the financial market) - where the destinations are not known at deploy time.
    In the market data feed example, the possible number of topics is huge (there are a number for each stock) and you are only ever interested in a subset of them at any one time.

    (NB: It is assumed that in this case, the same MDB is capable of consuming a message from any of the destinations. The grammar of messages at each destination is identical - only the content is different).

    Support for dynamic modification/addition/removal of topic subscriptions/queue connections - as well as the static definition of more than 1 destination should be detailed.
    Dynamic/multiple subscription/connection is possible with regular JMS consumers (e.g as startup classes), but you really want to take advantage of the parallel message processing that MDB's offer you.
    Obviously some simplifying limitations would be required - just adding and removing topics/queues from a subscription would probably be enough. While modification of a message selector is detailed in JMS, it could be sticky with transacted message consumption.

    2) Support for preservation of message ordering for mdb's - essentially opting out of the enhanced parallel message processing capabilities, when message order is more important than raw throughput. (in some appservers, this can be done by setting the pool size to 1, but this not standard)

    3) Support for a "cached object"? (Kind of like an in-memory-only entity bean concept). There is often a requirement for a lightweight, shared-access, in-memory object - that benefits from the ejb threading model. Entity beans are the only state-holding, shared-access object in EJB - but if you are caching, you dont want the overhead of database access (or any other persistance mechanism), required by entity beans. More-over, you want to be able to specify time-outs for the cached data and have the appserver do the sweeping up of expired cache data - as well as the object pool management.
    You would otherwise use regular, singleton, java classes - but then you have to implement the thread-safety related to the shared access yourself. More-over multiple class-loaders and multiple JVM's render a singleton object somewhat of a multipleton.

    This kind of in-memory-only object would help, for example, when you have to deal with out-of-order messages in the current MDB implementation. You need somewhere to cache your received messages while you re-assemble the order so they can be processed.

    4) In-built support for notification. Often a gui is displaying the contents of some entity on the screen when some other user alters the entity. You want to notify the 1st gui that its data is now invalid (rather than wait and throw an optimistic lock exception). This is possible (but, not trivial) using JMS, though you have to implement it all yourself. It would be better if this was some-how treated in a standard way and more responsibility passed to the appserver.

    I will be happy if interceptors arent ever added ;).
  7. EJB 2.0 final specification released[ Go to top ]

    There is definitely a need for an in Memory synchronised
    associative Object cache. Perhaps the pooling mechanism can be separated from connection/resource pooling, made more explicit and used for this purpose.
    This will prevent home brew synchronised static caches.

  8. For findermethods having complexTypes as parameters,the CMP should be able to understand the mapping between the variables in the "where clause" and the complex types attributes.
  9. EJB 2.0 final specification released[ Go to top ]

    A couple of things,

    A lot of the "future desired features" for EJB are really things that vendors should compete on. There's a delicate balance that needs to be achieved to target the majority of features that should be "standard", while raising the "water level" of vendor implementations a certain amount without drowning them. Some of the suggestions for MDB's, for instance, are more appopriate for specialized JMS vendors than they are for the "basic" JMS implementations included in many J2EE servers.

    One note about "cached objects". I'm not sure there needs to be a new definition, though perhaps broader standards for entity bean concurrency management to allow for effecient caching with high-volume servers. For instance, Entity beans with Commit Option A (i.e. pessimistic in-memory beans) are effectively cached objects, but since they're fully synchronized, they have to be really fine-grained unless you want to block writes to large portions of your domain model. Thankfully, local-interfaces make fine grain entity beans very acceptable across vendors.

     But even beyond pessimistic locking, there should be a way to provide a commit option that allows for in-memory optimistic concurrency. This already has been done - in particular, WebGain Toplink with Websphere or WebLogic, Persistence PowerTier, and The Server Previously known as GemStone.
  10. EJB 2.0 final specification released[ Go to top ]


      The in-memory optimistic concurrency you described is currently provided by Borland app. server and JRun - its called Verified Updates. in ejbStore, the update command is appended with a 'where' clause that adds the *old values* of the entity bean, allowing a server to detect whether the underlying database has been modified by a previous transaction. This allows you to run your transactions with isolation level read_committed and still get all the benefits of serializable.


  11. Just to clarify:

    I am not talking a about caching optimisation for reads - I am talking about a completely different in-memory-only object that never goes to the database.

    To describe it, you could say:
    -It looks like an entity bean in that it is a shared object where concurrency is managed by the container - but it never does an ejbLoad or an ejbStore.
    -It looks like a Stateful Session Bean in that it may be passivated and activated behind the scenes - but it is a shared object - the state is shared between all clients.

    The kinds of things this object could be used for:
    1) A network singleton (maybe for handling PK generation and the like) (this would be tricky with some clustering strategies)
    2) Keeping a cache of some data (much the same way a hashmap can - except this overcomes the problems a singleton class has with different classloaders/JVMs)

    One of the main limitations I see with the current look of EJB is that if you want some shared-access data, you are forced to put it in an entity bean - and consequently, you have to invent some database to store the state of this thing in.
    Moreover, the obligatory database trip (for the ejbLoad if nothing else) impacts performance to the extent that it becomes unusable for situations where performance is necessary (eg imagine a message-driven bean expected to process a high volume of messages - hitting the database on the receipt of every message is very expensive).

  12. I dont think a whole new bean needs to be included in the spec for this to be acheived. Enterprise Java is Java after all! And as such we can leverage a pure Java singleton to manage these facilities. The wrapper would be a (stateless) session bean and would get a reference to the singleton and use it's gets/sets.

    The other ninty advantage of this method is that if the bean was never used, the singleton would never be created.

  13. EJB 2.0 final specification released[ Go to top ]

    I might be a bit of beam here (I usually am), but may be there is a need to extend the EJB spec to allow functions like CMP to use plug compatible components.

    Rather than squeeze out tools like TopLink because they only provide a part of the infrastructure rather than a full EJB implementation, change CMP to allow a plugin O-R mapping component. Developers/deployers could then choose the best-of-breed component to go with the best container. We originally avoided CMP because it didn't allow us this choice.

    It strikes me that an EJB container is very much a monolithic wrapper for your beans, you get to chose between one monolith or another. Why can't we build our own EJB container from the best bits around.
  14. EJB 2.0 final specification released[ Go to top ]

    great idea, the role of container provider will eventually divide into several independent roles, such as transaction service provider, security service provider ....etc.
  15. Hi Floyd,
      I agree with most of your comments, but I still see the need for value objects with Entity Beans. Although the RMI/IIOP marshalling is gone, the Local Interface method call still goes through the container for transactions, security, etc... from my understanding. Value Objects can still reduce the overhead of going through the container.

    Roland Barcia

  16. Hey Roland,

      If you front entity beans with a session facade and configure your entity beans to use TX_Supports and don't use any security checks, then I would imagine there is hardly any overhead at the container level, since there is nothing to check.

      I have spoken to various vendors and they feel that the overhead involved there is nill. And if any, it is definitly worth the improvement in maintenance and architecture. Read the Value Object Factory pattern for a good discussion of the problems with using value objects to access entity beans.

  17. EJB 2.0 final specification released[ Go to top ]

    Hi... Just wanted to point out that using local interfaces does not add additional overhead as you suggested with TXs and Security unless you add the overhead. It's just as fast.

  18. EJB 2.0 final specification released[ Go to top ]

    I like the idea of using entity bean itself for managing the relationship between some entity beans (I've done this with ejb 1.1 - I know this is not optimized for 1.1 spec but works great for me). I also use fine grained entity beans without problem.

    What I would like to have is a standard for the "isModified" method for CMP (Container Managed) entity beans. JOnAS implements its own isModified method.

    Hier is the idea of "isModified" extension:
    "In order to improve performance we have implemented in JOnAS the isModified extension. Before performing an update the container will call a method of the bean whose name is indicated in the is-modified-method-name element of the JOnAS specific deployment descriptor. This method is responsible to tell if the state of the bean has been changed. Doing so, the container is able to know if it must store data in the database or if it's useless."

    I use this within JOnAS and the speed is really amazing! Because most of operations I have, are read operations.

    I haven't read the spec 2.0 yet. Does someone know, whether this extension already implemented in spec 2.0?

  19. EJB 2.0 final specification released[ Go to top ]

    isModified methods were used in a few app servers (WebLogic for example).

    There is no need for this now, due to the new CMP model in EJB 2.0. Since the container is building the get/set methods (we only make abstract ones), it is simple for it to have the intelligence on what has been changed, and optimize things (e.g. when doing an update, don't send all the data back if only X has changed).

  20. Does anyone have a good idea why EJB QL introduced the IN() operator? Normally one always navigates from the many's to the one's which is simpler and clearer. For example, why write

    FROM Order AS o, IN(o.lineItems) l
    WHERE l.Product.Name = "foo"

    when one can (or should be able to) just write

    SELECT l.Order
    FROM LineItems l
    WHERE l.Product.Name = "foo"

    The query optimizer might use o.lineItems for some part, just like it might choose to use an index for Name. But that should not have to be part of the query.

    Another issue which I did not see specified (maybe I missed it) is whether the query is applied to uncommitted data as well as the database? For example, if I update X's salary from $100 to $200 but do not commit, and then query Salary > $150, do I see X?

  21. New features that I would like to see:

    Integration with JAAS - for a more flexible interface to the underlying security system. Currently containers provide their own proprietary implementations to underlying security realms - and developers are at the mercy of whatever realms the vendor offers. Integrating with JAAS - which is what JBoss has done - will allow developers to use custom login modules - and the container can be independent of the the underlying authentication mechanism.

    Extensions for the container - similar to a plug-in functionality that is available for web servers. developers should be able to extend the container in a similar matter. I've seen mentions of method interceptors as a feature that was delayed until another version - hopefully the authors of the spec will take this on.

    Interoperability - especially with regards to security. The spec mentions that "EJB containers are required to provide deployers or administrators with the tools to configure trust relationships for interactions with intermediate web or EJB containers". "Trust relationships" is a very loosely defined term - for example - weblogic implements by saying that all servers must share the same password. Now that jdk1.4 has support for GSSApi and Kerberos - I would like to see the spec move in that direction.

    just my $.02

  22. many-to-one relationships?[ Go to top ]

    Hmm, I'm not sure about this, maybe someone could clarify?

    I'd like to see "many-to-one" relationships. I know this is logically the same as "one-to-many" from the other direction, in EJB 2 it doesn't seem to be the same because:
    Imagine two EBs, A and B. A should have a many to one relationship to B which is unidirectional, i.e. I want to have a method in a titled "B getB()".
    This doesn't seem to be possible at the moment as
    *) 1-1 doesn't work, if I have A1<->B1 and A2<->B2 and call A1.setB(B2) I now have A1<->B2, A2, B2, not what I want
    *) If I say "one-to-many" from the opposite side I must create a bidirectional relationship, also not what I want (logically)

    Any comments?

    kind regards

  23. Why EJB-QL cannot be used to build queries at runtime ?
    This is a great limitation for developers who want to give to the user the capability to build its own queries to access and filter data.
    With the lack of this capability JDBC must be used instead, limiting the portability of the application (JDBC works with the DB real schema, EJB-QL with the abstract schema).
  24. Hello,

      EJBs were designed to build a layer over the database, so transparency was obtained.

      Now in EJB 2.0 appears Local Interfaces to improve the performance when the client and the EJB are in the same JVM. So the developer must now if the client will be in the same EJB JVM in designing time. This if a problemm because an application working on a standalone server could not work in a cluster. Apart of that I think the container should be the responsible of this task. This should be done automatically by the containet, for example if the client is in the same JVM using Local Interfaces and if the client is in another JVM using Remote Interfaces.

      This stuff could be done with the creation of a new object stored in the JNDI tree instead of the Home Interface directly, working more less like a proxy. This object could check if the client is in the same JVM or not selecting Local or Remote Interfaces.

      Think about it, is it not a container task?

    yours sincerely,
       Oscar Guadilla JimĂ©nez.

  25. There is a lot of debate regarding location transparency - and there seems to be a growing concensus that location transparency is not a good thing. Location transparency difinitely makes life easier for the developer... - however in reality there are remarkably different problems associated with a remote call that make true location transparency difficult.

    Think what happens when you have a fine-grained interface over the network - the developer has to know this and define the interface accordingly otherwise performance will be terrible - therefore location transparency is blown.

    Anyway... in my opinion, it is better if the developer thinks about what they are designing and makes some decisive decisions up front. It isnt as though you have to make a choice between one or the other - you can have a local and a remote interface to the same bean...

  26. Oscar,

    I really don't think so.
    First of all, there are inherent differences between remote computing and local computing. This was described very well in a paper (by Sun if I remember correctly), cannot remember the link at the moment, maybe someone else knows.
    Because of this the "proxy" approach you are describing won't work, as local interfaces do not throw RemoteExceptions, remote interfaces do.
    However, some good containers (like Borland's for example) do this kind of stuff, but mainly as a "workaround" for the non-existent local interfaces.
    Second, most clusters today are built only sharing the JNDI namespace, but the whole application is instantiated on each and every container (i.e. the database provides the distributed caching/dirty detection, which is no more distributed then ;-). Local interfaces fit this paradigm perfectly.
    If you really want to parition the EJB portion of your application over multiple containers (this means adding one or more physical tiers like:

    instead of

    where W=Wevbserver, A=AppServer, D=Database;

    I doubt this will be any gain, neither in stability, nor maintainability or performance) you will have to think about it in design phase however, as you will want to keep data-transfers between the Ax tiers at a minimum, probably this would mean separate applications as the functionality will be inherently different in each tier... each app using local interfaces ;-)
    So it is IMO impossible to let the deployer draw the lines between the tiers, as he probably will separate the EJBs in a "worst case" scenary, slowing your app to a crawl.
    Alltogether I even doubt this will help you in any way, as in each chain you now have more than one single point of failure, so you need more "chains" to get the same reliability as with ony W-A-D.
    I also guess it would be easier using a bigger machine instead of some smaller for one "chain", and I can hardly imagine _any_ application which wouldn't run with a Sun E15K (or Siemens Primepower, IBM zSeries, whatever) as database server, some nice IBM pSeries 8-way machines (or Sun midrange serves) as appservers and the same as webservers. Can you? It has its price though *gg*

    kind regards

  27. I'd like to see a standard way of defining EJB application-based initialisation and termination, using classes that could be packaged in an EAR and run as part of the application deployment and undeployment process.

    This would be a bit like WLS's startup and shutdown classes, but would be tied to application instances, not server instances. Failure of the startup classes would lead to the application not being deployed, and so on...

  28. There is one other convenience that I have remembered that would be nice in the next version of the spec:

    At the moment, you can define environment parameters for each bean in the ejb-jar deployment descriptor.

    However, what would be nice is if there was a means to set global configuration parameters for a whole ejb-jar - and for an ear.

    At the moment, if you want to specify a log4J pattern layout in the deployment descriptor, you have to repeatedly define an

     <env-entry-value>%d{dd MMM yy HH:mm:ss,SSS} %-5p [%c{1}]: %m%n</env-entry-value>

    for each been - when in fact it will be the same for all beans.

    This would be trivial to add.

  29. what features do we still need for future versions of the spec?

    That's an interesting question. Useful features can always be found, but the question is whether or when they should be added to the spec.

    One feature I would like to see in an app server is evolvability. This is the ability to roll out modifications to the system without interruption of service. I don't know what the state of the research in this area is, and there may not be a perfect solution to the problem, but I think that component transaction monitors are well-positioned to become evolvable systems. It would be nice if the Java Community Process could be used to encourage the industry to move in this direction.

    Another feature, which I think must come eventually, is an EJB Fault-Tolerance Specification similar to the (pretty unknown) CORBA Fault-Tolerance specification. The spec should contain new deployment descriptor fields such as "degree of replication", and others. This is going to become an increasingly important area in the future because hardware is getting faster.

  30. Just about the "evolvability"...
    First, I think this should not be part of the spec... what would it help if it was part of it?
    Second, e.g. HP Bluestone has this feature, and it works very well, even throughout the whole cluster. In most cases, clients do not even see the update, sometimes there is a small delay. Bluestone switches "seamlessly" between the old and the new version.
    Well, one problem still: If the database has to be changed this is quite difficult. We tried two solutions and both work "somehow":
    1) Non intrusive updates of the database: This is quite easy to do and works well, but not always the perfect solution, sometimes impossible.
    2) Use another database which has been updated and is a replication of the "real" db. Difficult though (the replication).

    Hope this gives you some hints, maybe try Bluestone if this feature is important for you (don't know, but think its the only appserver which has at least parts of this feature).

    kind regards

  31. I like to see the new EJB spec has these features:

    -- Entity Bean Primary Key Support to use database?s built-in sequence / counter
    Add the support of entity bean primary key generation to use transparently the database?s built-in sequence / counter. Now, almost every major RDBMS (Oracle, IBM DB2, MS SQL Server and Sybase) supports this feature. This is a simple and viable solution. Weblogic has already provided this way. And primary key generation is always an issue for Entity Beans. Adding this to EJB spec makes it compatible.

    -- Case Insensitive Query for EJB-QL
    In many cases, we need case insensitive searching, such as findByName, findByEmail, ?, but every one has a painful experience with it when this issue is dealt with. It makes almost all EJBs bound to vendor?s database. There is no compatibility if EJB-QL can not deal with the case insensitive query.


  32. Can I know how could we write EJB QL for case insensitive search?