Enterprise Java Beans 2.1 specification Public Draft Available


News: Enterprise Java Beans 2.1 specification Public Draft Available

  1. The Enterprise JavaBeans 2.1 specification Public Draft is now available for download at http://java.sun.com/products/ejb/docs.html.

    EJB 2.1 includes the following new features: support for the development, deployment, and utilization of Web services; generalization of message-driven beans to support additional messaging types; enhancements to EJB QL to support aggregate and order-by operations; and a container-managed Timer Service.

    What do people think of 2.1? Is it enough for now?

    Threaded Messages (37)

  2. Timer Feature sounds good, will look for details in draft. WebServices addition into specs is welcome addition.
  3. Component inheritance would be nice.
  4. I haven't read the spec yet, so I could be saying this out of ignorance, but it seems like Timer functionality should be available outside of the context of EJBs as well as from within.
  5. "Generalization of message-driven beans to support additional messaging types" sounds good.
  6. Before anyone gets too excited/upset about the final EJB 2.1 release, remember that a Public Review Draft is one of the very early steps in the Java Community Process. Before a final release can be made they have to publish a Proposed Final Draft. There can actually be several Proposed Final Drafts before a Final Release is made.

    In the case of EJB 2.0, it took 10 months to go from the first Proposed Final Draft to Final Release. The EJB 2.1 is just now Public Review Draft, Proposed Public Draft is a ways away yet, so who knows when the EJB 2.1 spec will be in Final Release.

    This does mean something important to the average programmer, whether you are now using EJB or will be using EJB in the next few years. THIS IS YOUR CHANCE TO VOICE YOUR OPINION...as well you should.

    Don't forget, whatever goes into that spec is what you'll be expected to use a year or two from now. Don't underestimate the power of your own voice, people can delete emails, but they'll still remember what you wrote. A few things were torn out of the EJB 2.0 even after it went into a Proposed Final Draft.

    Now's the time to grab the wheel of the great J2EE marketing machine. Download the spec, visit the EJB JCP page and send your ideas/comments to jsr-153-comments at jcp dot org.

  7. "A few things were torn out of the EJB 2.0 even after it went into a Proposed Final Draft."
    A few? The entire dependent-object mess was ripped out and replaced with a whole new "local interface" concept, all in the transition from PFD to PFD2. I would bet this is the biggest set of changes to a PFD that has ever been seen in the JCP. If one can quantify such things...

    As for the time frame, it is true that the process of this JSR is not over yet. But don't expect it to run as long as the EJB2.0 JSR for instance. The JSR itself states that one of the main goals is quick release. So if you have comments, better send them quick :)


  8. I think some sort of Timer interface would be a good thing within J2EE. Whether or not it belongs within EJB is another debate, I think.

    If it's part of the EJB spec (and I haven't read it yet so this may be how it's currently proposed) I would think that you'd have some sort of deployment descriptor element that would allow you to schedule events that would be sent to an MDB when it's time.

    That's just the first approach that I thought of, though. It'll be interesting to see what ends up happening with it.

  9. The EJB 2.1 Timer spec allows for stateless session beans and entity beans to be invoked on some regular interval expressed in milliseconds. The docs say that they're leaving open the door for invoking MDBs in a similar fashion.


  10. If the spec allows you to programatically set a timer. i.e. In 30 minutes invoke this method on session/entity A then I can see having timed events on a session/entity bean but otherwise I don't see the point.

    I think for hard scheduled events (ala cron jobs) an MDB or SLSB is probably the most flexible solution. Entity beans however I have a hard time accepting since they really should just have data in them. I supposed if you increment something or set the time or something like that but normally you need to have some logic execute at that time. Also, what entity bean would you invoke on? You'd have to supply a primary key to specify which entity bean you'd invoke on at the scheduled time as well. I think to make it simpler I'd just require the recipient be either an MDB or SLSB. The SLSB can figure out what entity bean to update if the person really needs that kind of functionality. Or am I just missing a bigger picture at the moment?

    I think I'll go read the spec now (or at least that part of it) so I can respond a little more intelligently to these posts. :)

  11. I absolutely agree with Mike, but I would be even more restrictive and let timers to notify only MDBs (that is what they are meant to be used for, to receive asynchronous events).

    I think that would be much cleaner and simpler solution,
    let session and entity beans receive only synchronous calls.

    If someone needs to call some method on session or entity bean, he/she could write a simple MDB wrapper.

  12. From what I remember them saying at the conference, a lot of the Timer has to do with workflow mechanisms that developers wanted in their systems, such as "if an order is in a particular state for x hours we want it to move to a different queue". Of course there are numerous other examples, this one just stuck out in my mind from one of the Sun architects.
  13. The most importent feature (for me :-)) is that an
    EJB QL IN expression now supports input parameters,
    so that you can specify an "findByPrimaryKeys()" finder
    (not the "s") in a product independent way.

    I'm still missing the following features:
    o a CMR field can't be part of the primary key of the
      entity on the "n" side of an 1:n relation
    o a "startup" support in the lifecycle (a method that
      is called once when you deploy a Bean class)
    o support for DB sequences (auto generated keys)


  14. "a CMR field can't be part of the primary key of the entity on the "n" side of an 1:n relation"

    If you are just trying to use a schema where the foreign key is part of the primary key, then this is a database mapping issue outside of the scope of the EJB 2.0 or 2.1 specification. The MVCSoft Persistence Manager allows this mapping, and is available for JBoss, WebLogic, WebSphere(!), HPAS, and Orion. So you can use this mapping with any of these EJB containers.
  15. Hello,

    I haven't read the spec yet, but I think that the following features could be useful enhancement to the EJB:

    1. EJB-QL/ejbSelect should have support for functions other than the 6 listed in the EJB 2.0 spec (CONCAT etc. ). For example COUNT() function would nicely fit into EJB CMP model, i.e. it would be nice to have a count() method in the home interface for an entity bean:

    public interface PersonHome extends EJBHome {
      public Person findByPrimaryKey( PersonPK key ) throws RemoteException, FinderException;
      public int countAll() throws RemoteException;
      public int countByMinimumAge( int minAge ) throws RemoteException;

    A countXXX() method could call an ejbSelectCountAll() method in its implementation. This would make a 'Person' component more functional and powerful. As for now, you need to use JDBC to count entities.

  16. Hello friends.
       What do you think about the need of inheritance structure persistence. Why sun ignores this issue? I think, this is importand feature. CMP isn't comlete without it. And the because of lack of it I haven't used CMP in my projects.
  17. Most of the enhancements in this new release pertain to CMP. Reading the comments I am under the impression that few bother asking whether using entity beans at all can be considered a best practice. I for one try to avoid entity beans with relational databases like the plague for different reasons:

    - They are very complex to implement compared to other solutions and require expensive IDEs most of the time;
    - They take more time to develop than other solutions;
    - Due to their inner complexity, they're not as easy as claimed to maintain;
    - They have poor performance;
    - Most of the times, they have to be used with some very expensive O/R-caching-persistence software like TopLink.

    It's probably another debate, but overall, it seems to me that many people spend a lot of energy on specifying, implementing and tuning entity beans for quite disappointing results. I also find that more and more J2EE architects I speak with diss entity beans as a solution to fix the O/R impedance mismatch and prefer SLSBs or MDBs used with plain SQL wrappers.

    On the other hand, a few recent surveys show that best performance is surprisingly obtained using BMPs with object databases like Versant used as a data caching layer. That could be the future direction of entity beans (and object databases above all) but specifications (until 2.0, I haven't read the new draft) show that those are mostly designed for relational databases, which is quite normal considering that relational databases are by far the most widely used when it comes to managing data.

    And there's also JDO in the picture that wants to hide the details of the O/R mapping but that is not yet accepted in J2EE.

    Typical arguments in favour of entity beans always mention maintenance. Even Ed Roman recommends this. But is EJB-QL really better to use than SQL in real life ? In case of a database schema change, you'll only need to change the deployment descriptors, which is easier than changing SQL in the Java code yes. But by putting all the SQL in Java wrappers, you can happily apply the changes and reflect the new database structure and it is not too painful. I'm asking this genuinely (no troll intended) as I would like to know whether entity beans are really that favoured in the J2EE community or whether more and more architects/designers start to resort to other solutions.

  18. First of all, I think that lots of people consider entity beans evil. In fact, this subject is being beaten to death here on TSS (look for some of the hottest discussions to sse lots of people who share your view). I don't, as long as we're talking about EJB 2.x, not 1.1 (because EJB 1.1 CMP was, to my view, definitely unusable).

    What I think some people have not yet realized is that an EJB 2.0 CMP engine is just a persistence layer conforming to a standard. There's nothing in the spec that prevents vendors from implementing EJB 2.0 CMP engines that are just as fast and efficient as other solutions. This is a big difference from 1.1 CMP (e.g. because entity beans no longer need to be remote objects).

    So IMHO, the only alternative worth considering is JDO. But because of the much tighter integration of entity beans into the J2EE standard, I tend to use them for enterprise apps and plan to use JDO for the smaller stuff.
  19. I am also referring to EJB 2.0 CMP and BMP. It's actually the whole concept of persistence layer with entities that looks flawed to me. There is no way the best implementation of CMP as an O/R layer can even reach the worse implementation of SQL in terms of performance. But that would be ok if maintenance was that easy with CMPs which is not the case. Entity beans exist to avoid people the burden of SQL, supposedly unmaintainable, and propose the use of an object model that is supposed to be much cleaner. But in CMPs it is replaced by some pseudo SQL with very limited features. And to reach an acceptable level of performance, you need to pay huge money.

    I can only see CMPs being really useful if the data is stored in object databases kept on the same machine as the application server, which almost defeats the whole n-tier concept. That's sort of coming back to PL-SQL, we keep the business methods in the same place as the data but this time it is not on the database but on the application server. However hard the EJB specification team may work to improve the CMPs, SQL will always be better for the relational model though.

    I really feel that I am a fool to refute CMPs when the whole community seems to be blindly following the specs 100%. In my working environment, I have to deal with many people who do not work in Java and J2EE and are really skeptical about J2EE because it is costly and it is so complex that most developers are unable to grasp best practices and develop performant applications. Entity beans are really not helping in that sense.

    Don't get me wrong though. I'm a big big fan of the J2EE architecture (apart from entity beans and SFSBs) and I recommend it as much as I can. However, I can't adhere to the concept of entity beans and I don't mind if they are new EJB-QL features in 2.1. And I just would like to know from other people's experience if others reached the same conclusion as I did.

    Maybe JDO will be easier to use and maintain in such case it should be part of the J2EE but I don't think it is going to happen anytime soon.

  20. <quote>
    really skeptical about J2EE because it is costly and it is so complex that most developers are unable to grasp best practices and develop performant applications.
    1.It's not "costly" - you don't need to buy Weblogic/Websphere: JBoss is free, JRun under the $1000, etc see App Servers matrix
    2.I don't feel EntityBeans to complicated - yes it took some time to learn it. But every new technology takes time to learn. I think in a while develop EJB will be as simple as client/server etc.
    You don't need expensive tools to create EJB: there are a lot of free ones.
  21. The license cost is only part of the expense. Developing with EJB is slower than it could be, because of the complexities and time spent in deployment and so on.

    Also, because the the complexities of the EJB2.0 spec, each server implementation has it's own peculiarities which you have to learn to work around. This all adds time, and time is what costs the real money.
  22. I agree. But:
    Developing with EJB is slower than it could be, because of the complexities and time spent in deployment
    Because I'm using JBoss I don't have problem with deployment. Just copy .ear :)
    Also, because the the complexities of the EJB2.0 spec, each server implementation has it's own peculiarities which you have to learn to work around. This all adds time, and time is what costs the real money.
    You are right.
    I hope there will be better specs in a while.
  23. <RAVE>
    Re Entity Beans not up to scratch

    I don't see what all the fuss is about. You have to know how to use Entity Beans but once you do they work great and provide a nice abstraction layer over your data.

    My company has built a J2EE Content Management system using WebLogic with CMP 2.0 and relationships on top of Cloudscape (for development) and Oracle for Depoyment. The Entity Bean implementation keeps track of fragmented, versioned web content and metadata as well as content and metadata schemas, queries and more.

    We have no problems with development using Entity Beans. We use NetBeans/Forte for developmnet, EJBGen/XDoclet when we want to have just one source file per bean and JUnit for testing. Works great. For our typical customers, the Entity Bean part of our solutions probably represent 20-30% of the total functionality but would probably account for about 10% of the total development effort.

    We have no problems with performance. We carefully choose between local and remote interfaces, use EJBQL queries across relationships judiciously and take care to think about many performance issues including isolation levels and read-only behaviour. Having done that we get great performance. One customer has 50,000 fragmented HTML documents with substantial metadata and the system flies under faily demanding load on a medium-size Sun configuration and doesn't go too badly on my Intel laptop either.

    Anyway, getting back to the original thread:

    Things I liked:
    + finally making EJBQL usable with ORDERBY and aggregate functions (MIN, MAX, COUNT, SUM etc) - now if only there was support for case insensitive LIKE queries across all databases
    + if I read it correctly I could have an MDB triggered by e.g. an incoming SAP call through the J2CA - that would be useful
    + I like the timer functionality - we already have tools like flux but this gets right down to what the semantics should be for e.g. transactions when a timeout is invoked
    + standardising Web Services is great

    I was dissappointed at some of the things they deferred:
    + subqueries, multi-valued results, dynamic queries for EJBQL
    + standardised read-only CMP Entity Beans
    I have just started playing with these features in WLS7 and they seem very useful.

    There also seems to be a trend in the J2EE specs to move towards XML Schemas instead of DTDs. I would like to see this happen with a major J2EE release rather than over half of the J2EE APIs. Does anyone know if this is indeed what is happening?
  24. Leonard,

    What I mean by 'costly' is not the price of the application server. It's the total cost of the whole J2EE project. Costs include application server but this is almost marginal when it comes to development costs. I really believe that J2EE is very good to build performant, scalable, secure, transctional, blabla Internet/intranet applications. But in order to be able to develop that kind of project, you need to be really skilled and it takes quite some time to be skilled at J2EE. Actually, many designers and developers learn by cut/paste/modify-like experience and never read the specs. In the end, you end up with architects/designers that use EJBs for any kind of project irrespective of the real needs and programmers who struggle with entity beans using costly IDEs, even for very small projects. So you get many simple projects that should or could have been developed in a month with JSPs and SQL wrappers that are developed using overkill JSPs/Struts/SFSB/SLSB/CMPs/TopLink in a year (and this is not a joke, I've seen it happen many times and still see it happen). In that sense is J2EE more costly than ASP/VB. I think many people advocate EJBs and entity beans because everyone else does it or because it's what Sun recommends. I don't think many people recommend entity beans because they tried them, compared them with other solutions and liked them. That's only my point of view of course.

    Regarding entity beans, anyone can learn any technology so nothing is really complicated. Entity beans are only complex if you compare them with Java SQL wrappers for instance. I think the benefits you get by using entity beans is so small compared with the costs they incur that I cannot understand why so much energy is devoted to trying to promote them.

  25. This is new technology... Is there anybody can share memories what was when SQL just started :)
  26. Leonard,

    The glitch is that this new technology is not only accepted but also very widely used without much prior experience with it. Many people seem to be happy to blindly adopt this new technology and spend millions to develop Petstore-like applications that use the whole J2EE shabam with XML and that can hardly support 10 transactions/second on 4-processor machines. That's the unfortunate reality. Didn't I read somewhere that only one J2EE project out of six is a success ?

    I for one, still prefer to recommend or use older but proven technology when I'm not sure the new technology is better. I have fully adopted J2EE 1.3 except SFSB and entity beans. But I'm willing to use them for critical applications if they can prove more performant in the future.


  27. Yann,

    >>Many people seem to be happy to blindly adopt this new

    Firstly, dont assume that people are "blindly" following anything. Perhaps some new technology has some benefits that you havent yet recognised... (its possible)

    >>When an access to the relational database is needed, plain
    >>SQL is definitely many times faster than CMPs (again from
    >>benchmarks I've come across) because SQL is far more
    >>flexible than EJB-QL

    From your post, I get the understanding (perhaps wrongly) that you equate EJBQL with CMP2 and therefore because EJBQL has some limitations it must follow that CMP2 is pants.

    I think you would find it interesting to pull apart the SQL/JDBC code that a decent CMP container genererates (and you can easily do this BTW). You will find it remarkably similar to what you would write yourself. The difference being that you didnt have to write it yourself.

    Add caching, tuned updates, lazy loading, eager-loading, optimistic locking, pessimistic locking, bulk reads, batched updates/inserts and you have a level of performance thats not trivial to implement when you write it yourself (let alone change it at the flick of a switch). Also, what the container generates is far, far more likely to work first time and not require debugging (at least thats my experience).

    Its true. The whole Entity Beans are bad, Stateful session beans are evil "debate" is a well-thrashed dead horse. Choose the correct tools for the job and sometimes you will find yourself using direct JDBC/SLQ access - that doesnt make it a rule though.

    As for the IT project success ratio - the 90% failure rate has established itself as a trend well before J2EE ;-)

  28. " Add caching, tuned updates, lazy loading, eager-loading, optimistic locking, pessimistic locking, bulk reads, batched updates/inserts and you have a level of performance thats not trivial to implement when you write it yourself (let alone change it at the flick of a switch). Also, what the container generates is far, far more likely to work first time and not require debugging (at least thats my experience). " -- Nick Minutello

    Hi Nick,

    If you've found that CMP worked well (which does not seem to be everybody's experience) then I think we'd all be very interested to hear what container(s) it is that you have used so successfully (and what other associated tools).

    Was this a large project? High concurrency? Complex transactions? Was the O/R mapping complex (domain model very different from data model) or fairly straightforward?

    (hey, I hear all about the failures of tools, it's nice to hear about the successes too).


  29. hi all

    I found this debate very interesting, but i've been suprised with few sentences. :) It seems that some people have been thinking, that programming is work for well trained monkeys. I think that from programers view, study is the MOST IMPORTANT part of his/her work and the final application should be product of his/her knowledge, not only fingertips. I've been working with some of those "COPY/PASTE" sort programmers, but they are like kids. The neverending supervision is needed. Once again. I'm suprised that many programers dont' study. There was old good times when one learns turbo pascal and it suffices. But today it doesn't. There are many APIs, many solutions that can fit very well together, but thay can be very easilly misunderstand and missused. For example I don't think, that use of CMP is good idea when your database structure is unstable and is generated on runtime. It's extreme, but it shows clearly that programer who decides for EJB+CMP for this kind of project will be very frustraded of it.

    I wrote this article because I seen some reactions that appears like my own from times when I was lazy to study.

  30. The container that I have used so far that supports the features I mentioned is Weblogic 7.0. Also, you can use Toplink's CMP engine (which supports cursored collections) - but there are other choices no doubt (WAS5, when its released).

    Insofar as projects: - most CMP2 ones are still underway.

    How large? Well, how do you "size" a project - by headcount, lines of code or money it earns...?

    High Concurrency. Not hugely so... (though, not sure how that affects CMP - its the database that will see the concurrency)

    Complex Transactions? What makes a complex transaction?

    O/R mapping complexity? Not overly so. Heavy use of relationships, but thats all.

    I dont believe I am stating that CMP is the *only* solution - its just that CMP is probably good enough for 80-90% of applications if people know what their container can give them.

    Most of the negativity I encounter is from people that made up their mind that CMP was shite when all they know (or have heard about) is CMP1.1 - they havent had the opportunity or the inclination to look further into it.

  31. <quote>I really feel that I am a fool to refute CMPs when the whole community seems to be blindly following the specs 100%.</quote>

    Yann - nice post. I too try to avoid statefull session beans. I really don't see the whole community supporting Entity beans though, but I have often spoken out in favour of them. One of the nice things about CMP 2 is it's ability to handle relationships between the entities - if you want to do this manually (JDBC I'm assuming) there is a lot of work involved. From my experience (have not used it professionally yet) CMP 2.0 is very fast - and once you have a few beans written, adding more becomes mostly a matter of copy and paste for both the code and the deployment descriptors.

    <quote>There is no way the best implementation of CMP as an O/R layer can even reach the worse implementation of SQL in terms of performance.</quote>

    I think the opposite: because of the container's ability to manage caches, CMP should be able to beat straight SQL in many situations. Also there is talk of containers batching queries together, which I don't understand how that could be implemented with overhead that still results in time savings... but if this is actually possible it is another reason for optimism.

    OO Inheritance would be interesting to play with in entity beans, however I haven't really missed it up till now. There is the ability to do some inheritance with bean interfaces as well.

  32. Markus,

    What most CMP 2.0 implementations do is actually trying to create a cache of object graphs that looks like an object database (hence the relationships) and that is arguably faster than SQL in some cases. In most times, data on a local object database is faster to fetch than data in a remote relational database. Some benchmarks I have come across seem to prove that (but it's only benchmarks). But an EJB cache is different from an object database in that you cannot cache all data so you'll eventually be accessing your database doing complex work behind the scenes. When an access to the relational database is needed, plain SQL is definitely many times faster than CMPs (again from benchmarks I've come across) because SQL is far more flexible than EJB-QL - at the cost of complexity but you can gain huge performance by optimizing your SQL queries yourself.

  33. I have been looking into JDO recently. Everyone seems to be building frameworks around entity beans to make them work better. It is nice to have design flexiblity, but the large number of files and deployment issues creates more maintenance headaches than it is worth. Tools should take care of all of it, but they don't. Deployment is also very slow. If you make a small mistake, you depend on vendor's software to give you good messages about the problem. Most of my experience is with Websphere and I can say that it is a black box. If there is a deployment problem, you may spend much time guessing what caused it. Very fragile environment.

    JDO deployment is simple. No JNDI lookups except for getting the PersistenceManagerFactory. JDO is also built for transparent persistence. There is also an object query language that you can use to retreive objects. It is a good thing to have a JDO alternative. Deployed within an app server, you still use session beans as remote components, but that is simple to deploy and maintain. The JDO stuff sits behind the session beans. This solution does not solve everything, but is still worth trying because of faster development and deployment.

    I know this post was a little off topic, but I wanted to share with others what I was doing.


  34. What i wanted to know is if the bad reputation of CMP is based on experience of CMP 1 or based on CMP 2. The second edition of the CMP is only a few month old and only a few application server support it. I doubt that many projects have been done with it, yet.

    If i look at best practices, patterns etc. there asumptions are right only for CMP 1. For example using DAOs with local interfaces doesn't make sense. I think it's time now to rewiew patterns and best practice and give tool and app server vendors some time to optimize their products.

    What wonders me is the speed the version 2.1 is "released". Shouldn't they have waited for implementations and experience of the standard before announcing a new one? I think it's not a good idea to "release" a standard to get into a discussion.

    I would really like to read some experiences with CMP 2.

  35. <quote>
    What wonders me is the speed the version 2.1 is "released". Shouldn't they have waited for implementations and experience of the standard before announcing a new one? I think it's not a good idea to "release" a standard to get into a discussion.

    2.1 hasn't been "released". This is a public review draft. It's more like a "what do you think?" than a "here you go".
  36. EJB Spec is rather limited?[ Go to top ]

    I frequently hear valid criticism of the use of Entity Beans and Stateful Session Beans. Heeding this advice, an architect/developer is left with just Stateless Session Beans and Event-driven beans. Event-driven beans are ideal for solving certain specific problems, but stateless session beans would be left to do most of the work in the average project.

    I have found that the resulting applications tend to be rather procedural (unless OO features are shoehorned into the internals of some EJBs). Procedural JSP pages calling some kind of procedural fascade, invoking other stateless session beans in a mostly non-oo manner, invoking a DAO or suchlike to access a relational database. In such projects, the advantages of using EJBs are diminished - container-managed pooling of resources, and an infrastructure for facilitating remove invocations (load-balancing/failover). While these advantages are not to be sneezed at, I feel there is so much missing (particularly in the OO area) that a great opportunity is being lost, and that there will be a temptation to phase out EJBs at some stage (in the not too distant future) in favour of some other form of component technology.

    Despite the above, I still feel J2EE as a whole is the best general platform available today for delivering complex server-side apps.

    Am I being too harsh?
  37. I just send a few comments to sun - here an extract which takes a look at the TimerService.


    - Timer Service -

    The EJB Spec defines a standard for a component architecture for distributed business applications. Often I missed due to the EJB restriction "no user threads" a cron-like functionality or some kind of timer (to expire data and such). I have seen several workarounds to model those needs: direct cron daemon usage or user threads on servlet level and JMS to distribute events. Pretty ugly solutions!

    I was very pleased reading about the new feature "container managed timer service" in the draft. The three supported kinds of time-based events "after a specified time, after a specified elapsed time and at specified intervals" reflect typical requirements. A pretty straight forward solution. Well, almost. So why do I think the current spec doesn't cover the requirements I have seen in previous projects?

    First of all this draft satisfies the needs of one EJB role only - the bean provider. In my experience at least two other groups - system administrators and application assemblers - need to be supported too. Often within J2EE applications you need to support cluster wide scheduled events which might be vary depending on the type of application or on customer needs. A typical scenario: Revalidate in a transaction safe manner DB caches at a fixed time through the application (and avoid caching problems on application level by doing so). As usual the interval is changed or a unplanned validation is needed. I guess most container provider will address those needs - with a vendor dependent solution. A Sun preferred solution?

    The current draft enforces access to the TimerService through EJBContext only. This might be enough for a bean provider - it definitely does not satisfy customers needs such as management and monitoring of components. How do I support these timers within a cluster wide vendor independent JMX infrastructure (as my company provides it for all our components)?

    Two other minor issues:
    In my opinion there are timers which do not need to be durable/persistent (e.g. revalidation of in-memory caches). Please provide persistent and non persistent timers.

    Next point seems to be security: Who is allowed to alter existing timers?

    Finally I believe the Timer Service is too EJB biased. Usually there is a need for timers on DB, EJB and JSP/Servlet level (not to talk about standalone applications). The current draft would leave a lot of areas uncovered. Therefore I think the TimerService should be moved to a separate specification and should be a requirement for EJB 2.1. equal to JMS. This would enable EJB and non EJB components to use a common infrastructure for time-based events (especially important for JSP/Servlet containers). A lot of other ideas for a TimerService come to my mind (scoped timers, grouping, JMX support a requirement ... ) but certainly leaves the scope of this feedback.

    If you can't wait for another community process rename ejbTimeout() e.g. into onTimerEvent() to leave enough room for a separate specification and change it's signature to onTimerEvent(timer:Timer).

  38. Lists? Maps? Sets?[ Go to top ]

    I had secretly hoped for some support wrt. Container Managed Lists and Maps, which are still "expected in a later version" (p.144). Instead of using a native Java interface for a Map, currently you have to call a finder for each (conceptual) map access, which is much more difficult for the container to cache efficiently, and more cumbersome to program. When storing a list or a map using a keyed join table, you have to materialize each entry as an individual bean, which again is far from optimal. And lists and maps actually occur in a domain model, just think of representing discussion group entries (list) or a directory structure (map).

    As a side note, the semantics of java.util.Set container managed relationships still seems to be a bit flaky: the semantics of the java collections framework is based on equals() - but equals is not defined for EJBLocal references! This also means you cannot use EJBLocal references in your own collections, maps etc. Is there any reason for not defining the semantics of equals(), at least for local objects? Determining equality is obviously possible, since we have "isIdentical".