Discussions

News: Article: New features in EJB 3.1, Part III

  1. Article: New features in EJB 3.1, Part III (35 messages)

    In "New Features in EJB 3.1, Part III," EJB 3.1 expert group member Reza Rahman discusses asynchronous invocation of session beans - much like JMS without the JMS configuration - and EJB 3.1 "Lite."
    Asynchronous processing is a surprisingly common requirement for many enterprise applications. Some of the most obvious use cases are triggering fire-and-forget background processes, handling long-running tasks while keeping the user interface receptive or simply increasing application throughput by utilizing the benefits of parallel processing. The easiest way of implementing asynchronous processing in Java EE applications today is using Message Driven Beans. In fact, the first Message Driven Bean example in EJB 3 in Action is used to implement asynchronous order billing. More precisely, a Message Driven Bean (OrderBillingMDB) asynchronously bills the customer after the order is confirmed and updates the order information with the results of the billing attempt once it is completed.... While using Message Driven Beans for asynchronous processing certainly works, it also forces you to deal with messaging and JMS, even for relatively lightweight functionality. This is precisely the problem asynchronous session bean invocation is designed to solve. With this enhancement, you can do asynchronous processing simply by annotating a session bean method with the @Asynchronous annotation.

    Threaded Messages (35)

  2. Guido Anzuoni posted:
    It is really disappointing to see that we (well, not me) had to wait 3.1 edition of the spec to realize some basic needs that other technologies provides since a very long long long time. And, I would bet, a lot better.
    Sorry, Guido - I had to delete the comment to be able to correct the timestamp on the newspost.
  3. EJB 3 was first to implement annotations for configuration, instead of the dreaded XML config hell. Then, with the latest Spring 2.5, the Spring crowd finally got around to using annotations. But is was the Spring DI, POJO model that forced the vast improvement of EJB (from the 2.x abomination to the very nice 3.x implementation). So, the existence of both is fantastic for developers! And both the Spring pluggable, more lightweight model, and the JEE/EJB 3.0, everything in the app server, model, have there places - Spring is arguably better for small to medium sized projects, where only certain API's and capabilities are needed, that might have scale up over time. And a full JEE/EJB 3.0 app server is arguably better for a big enterprise app that needs all the various APIs and capabilities that are "just there" in the app server and activated with a simple annotation, and you don't have to do extra plugging/wiring to get all the parts together.
  4. Not to nit, but I think people were using XDoclet (though not exactly the same implementation-wise) approach prior to EJB3
  5. So, the existence of both is fantastic for developers!

    And both the Spring pluggable, more lightweight model, and the JEE/EJB 3.0, everything in the app server, model, have there places.
    I am actually working to provide yet another robust option for developers (this is hinted in the article). I have preliminarily spoken to Rod Johnson of SpringSource about implementing EJB 3.1 on top of Spring. This project could be hosted as a Spring module and allow developers to fully utilize the benefits of EJB inside a pluggable Spring container. This would allow for the ease-of-use, ease-of-configuration and standardization benefits in EJB while still natively supporting all features in Spring including DI, configuration flexibility, integration with non-standard APIs like Hibernate, Acegi and TopLink as well as support for Spring templating for JDBC or JMS. I'd love to hear some thoughts on such a project. Cheers, Reza P.S.: Incidentally, one approach I have seen a couple of folks take is integrating EJB with Spring inside a full Java EE container. Yet another option is mixing and matching Spring and EJB 3 using an embedded container like OpenEJB inside Tomcat.
  6. Yet another option is mixing and matching Spring and EJB 3 using an embedded container like OpenEJB inside Tomcat.
    We're definitely interested in pursuing that. Early in the OpenEJB 3.0 lifecycle we actually had support for making OpenEJB just a bunch of Spring beans. You could build your Container and EJBs completely via your own Spring xml which could of course include all your other app stuff too. It was pretty neat, but we shelved it to focus on Java EE 5 Certification. Now would be a good time to revisit it. A second thing we've wanted to do is create a Spring Container -- all our containers such as Stateless, Stateful, MDB, etc. are pluggable and you can add more. The Spring Container would do things like expose beans from a Spring Context as EJBs as well as allow Spring objects to reference and have injected EE things like JTA EntityManagers, Topics, Queues, etc. If anyone thinks that sounds like something you'd like to work on or something you need, hop on the dev list, we're happy share in the fun.
  7. A second thing we've wanted to do is create a Spring Container -- all our containers such as Stateless, Stateful, MDB, etc. are pluggable and you can add more. The Spring Container would do things like expose beans from a Spring Context as EJBs as well as allow Spring objects to reference and have injected EE things like JTA EntityManagers, Topics, Queues, etc.
    I believe JBoss has a very similar initiative going on too. Cheers, Reza
  8. I agree that the EJB/Spring compition has been great for developers. What I love about the Java ecosystem is that there is compition among technologies and to large degree it has become a meritocracy.
  9. Guido Anzuoni posted:
    It is really disappointing to see that we (well, not me) had to wait 3.1 edition of the spec to realize some basic needs that other technologies provides since a very long long long time.
    And, I would bet, a lot better.
    Sorry, Guido - I had to delete the comment to be able to correct the timestamp on the newspost.
    Never mind. Anyway, it is still there, even if quoted :-)) Guido
  10. It is really disappointing to see that we (well, not me) had to wait 3.1 edition of the spec to realize some basic needs that other technologies provides since a very long long long time.
    Guido: I have to admit I am hesitant to respond to this because it looks like flame-bait. I'll give it the benefit of the doubt and field it the best I can anyways... By this very general statement, if you mean the ability to unit/integration test EJB components, that's actually been possible for more than two years now (David mentioned just one of these existing mechanisms). All that this particular enhancement really does is make it even easier by applying some service/API guarantees at the spec level (no meager accomplishment by any means). Also, it's easy to get too carried away with marketing hyperbole, negative rhetoric and over-competitiveness (of the nasty kind) when it comes to Java EE technologies. Taking an objective view of things, it not difficult to observe that the Java EE standard actually evolves quite quickly and the rate of evolution is actually well sustained and predictable over a period of time. That's an exception, not the rule, even considering the frenetic pace of the software industry as a whole... Just something to keep in mind while discussing some of this...too often I see a dangerous tendency to throw away the baby with the bathwater too rashly only to realize the the damage done later...let's try not to do that to EJB/Java EE please. Cheers, Reza
  11. It is really disappointing to see that we (well, not me) had to wait 3.1 edition of the spec to realize some basic needs that other technologies provides since a very long long long time.


    Guido:

    I have to admit I am hesitant to respond to this because it looks like flame-bait. I'll give it the benefit of the doubt and field it the best I can anyways...
    I am sorry for that. It was not my intent.


    By this very general statement, if you mean the ability to unit/integration test EJB components, that's actually been possible for more than two years now (David mentioned just one of these existing mechanisms). All that this particular enhancement really does is make it even easier by applying some service/API guarantees at the spec level (no meager accomplishment by any means).

    Also, it's easy to get too carried away with marketing hyperbole, negative rhetoric and over-competitiveness (of the nasty kind) when it comes to Java EE technologies. Taking an objective view of things, it not difficult to observe that the Java EE standard actually evolves quite quickly and the rate of evolution is actually well sustained and predictable over a period of time. That's an exception, not the rule, even considering the frenetic pace of the software industry as a whole...

    Just something to keep in mind while discussing some of this...too often I see a dangerous tendency to throw away the baby with the bathwater too rashly only to realize the the damage done later...let's try not to do that to EJB/Java EE please.

    Cheers,
    Reza
    I was referring to the new asynchronous invocation feature. I could agree to not throw away the baby but you have to admit that even in 2001 other technologies had well-standardized asynchronous invocation capabilities. I think that other babies have been thrown away in the past instead. And the water was not so dirty. No regrets, just facts. Cheers, Guido
  12. I could agree to not throw away the baby but you have to admit that even in 2001 other technologies had well-standardized asynchronous invocation capabilities.
    Guido: What in particular are you talking about? I have to admit other than some app-server specific async invocation features, I can't recall any other major initiative in the Java space other than JMS/Message-Driven-Beans (and arguably the Messaging functionality in Spring)? Are you talking about some variation of Java Threads? Thanks in advance, Reza
  13. I could agree to not throw away the baby but you have to admit that even in 2001 other technologies had well-standardized asynchronous invocation capabilities.


    Guido:

    What in particular are you talking about? I have to admit other than some app-server specific async invocation features, I can't recall any other major initiative in the Java space other than JMS/Message-Driven-Beans (and arguably the Messaging functionality in Spring)? Are you talking about some variation of Java Threads?

    Thanks in advance,
    Reza
    As someone else said, messaging is different from async invocation. Now, if you are talking about intra-jvm async call, OK, I can agree that there is no explicit implementation available (is it really useful ?). But in the case of remote call you have AMI CORBA spec since 2.4 (I could be wrong but it should be around 1996-1998). Without mentioning ICE (www.zeroc.com) AMI/AMD. Beware, I am not comparing technologies, I am just saying that this kind of problems/needs have been addressed and solved since a very long time. Welcome EJB to the async processing SW community ! Guido
  14. JEE Profiles[ Go to top ]

    I'm very happy to see the Async methods added. There have been many times I have had to use JMS just to run things async, and find an async method a much more simple and clean solution for those circumstances. I'm very happy to see the development of JEE 6 profiles, and I think the features you outlined for lite version of EJB are right on the mark. At the company I just left EJB Lite would have word for all, but one of our JEE applications. My 2 cents on on your "Still on the table issues": - Stateful session beans and web services are probably best in full blown EJB. I can't understand how the web services might be a bit of a gray area. - Standardize JNDI Mappings - Don't add EJB 3.1 to Java SE. It is great to have JPA in the SE, but adding EJB for the sake of testing doesn't make sense.
  15. Re: JEE Profiles[ Go to top ]

    - Don't add EJB 3.1 to Java SE. It is great to have JPA in the SE, but adding EJB for the sake of testing doesn't make sense.
    Wow, I've never heard someone *not* like the idea. I'm really interested in what you think the negatives are. We can definitely make sure their addressed. Aside from Session Beans, from my experience people really like that they can test/use TRANSACTION and EXTENDED persistence contexts in their unit tests or Java SE environment. Java SE usage of JPA is otherwise restricted to the EntityManagerFactory approach to creation of the EntityManager and the limited EntityTransaction API for transactions.
  16. Re: JEE Profiles[ Go to top ]

    Wow, I've never heard someone *not* like the idea. I'm really interested in what you think the negatives are.
    Sorry I was crossing my thoughts on this one. For some reason in my mind I assumed this meant adding EJB 3.1 to the JRE, when I see how you are only talking about the JDK. Never mind my objection.
  17. Re: JEE Profiles[ Go to top ]

    Wow, I've never heard someone *not* like the idea. I'm really interested in what you think the negatives are.


    Sorry I was crossing my thoughts on this one. For some reason in my mind I assumed this meant adding EJB 3.1 to the JRE, when I see how you are only talking about the JDK. Never mind my objection.
    The article says:
    Support for using EJB 3.1 in Java SE environments. This is primarily geared towards unit testing.
    I think/hope that means that they want better support to run EJB 3.1 outside the container and that it doesn't mean they 'll try to cram the jars into the JRE or JDK installation. There's no need to bloat the JRE or JDK bootclasspath with EJB 3.1.
  18. Re: JEE Profiles[ Go to top ]

    I think/hope that means that they want better support to run EJB 3.1 outside the container and that it doesn't mean they 'll try to cram the jars into the JRE or JDK installation.
    That's exactly right. Whether or not you call that inside or outside the container is subjective as container has an ambiguous meaning. But the long and short of it is that by including a few jars of your chosen vendor into your classpath, you'll be able to run EJBs in your app. There are several examples of it for EJB 1.1-3.0 via embedding OpenEJB which was founded on the idea of an embedded EJB container. There was a nice series of TSS articles on it a few years back. The recent additions of JBoss Embedded and EasyBeans make two more EJB containers that can be used today in plain Java SE apps. All of them usable in plain unit tests despite not having the word "Mock" in their name or claiming to "pretend" to implement the EJB API :)
  19. Async side effects.[ Go to top ]

    The interface is cool indeed... but I wonder what kind of side effects one buys with the "Async" mode. In fact, because of the parallel usage scenarios on any EJB container, the async method must be a wrapper around something put on a transient implicit queue and a (number of) workers, reading from the queue. Most likely, when using the Future interface, one would also need an automated asynchronous result delivery mechanism (usually called a queue). I think this is quite important to spec out to make sure that the interface behaves consistently across its implementations. Consider what happens if a lot of clients do a lot of asnychronous calls on my stateless EJB? How will you be able to do that properly without a full messaging system under the hood? You will most likely need throttling, control the maximum number of parallel workers and so on.
  20. Re: Async side effects.[ Go to top ]

    Consider what happens if a lot of clients do a lot of asnychronous calls on my stateless EJB? How will you be able to do that properly without a full messaging system under the hood? You will most likely need throttling, control the maximum number of parallel workers and so on.
    Well, we kind of have this in place for remote EJB calls: The container has a queue and worker thread group which you can parameterize. Is there a difference if you start using async EJBs? But if you want more control then you probably will be better off using a real messaging system.
  21. Re: Async side effects.[ Go to top ]

    Well, we kind of have this in place for remote EJB calls: The container has a queue and worker thread group which you can parameterize. Is there a difference if you start using async EJBs?
    I think there is some difference. Of course this is somewhat dependent on when and how the asynchronicity starts. I would always want to decouple message delivery from actual execution, in other words, I would not want to be dependent on the availability of a concrete worker to handle my request before I carry on working. Also, some client side way of listening to server side notifications must be built into the interface to allow for the Future interface to be used.
  22. Re: Async side effects.[ Go to top ]

    Consider what happens if a lot of clients do a lot of asnychronous calls on my stateless EJB? How will you be able to do that properly without a full messaging system under the hood? You will most likely need throttling, control the maximum number of parallel workers and so on.
    We're very carefully ensuring that JMS/MDBs can be used under the hood and I suspect most vendors will do exactly that for the remote/persistent side of it. I like to think of this as the Simplified MDB API.
  23. Re: Async side effects.[ Go to top ]

    But, an async call is not messaging. Messaging may be asynchronous, but that doesn't mean asynchronous calls are messaging. For example, with a local session bean, there's no requirement for a parameter to be Serializable. Now, one can certainly implement an internal message queue, but JMS per se can't send a message with simply a message pointer. Also, messaging has no implication of actually "running" a "background process". A message is a message, an async call is more of a process. The Future return type gives the async caller some access the actual process. For example, you can "cancel" a Future. But, interestingly enough, the actual async method call seems to have no access to this at all. Since we know that you can not safely "kill" a thread in Java, the suggested mechanism for stopping threads is to set some kind of thread status that the thread itself monitors so it can effectively stop itself. But I don't see in the (obviously) short snippet any access to such a monitor that the method can use. I understand the desire to leverage messaging for this process, but in truth I think you should perhaps be leveraging the EJB Timer service, as I think it provides a better model to represent a background task.
  24. Re: Async side effects.[ Go to top ]

    Will:
    But I don't see in the (obviously) short snippet any access to such a monitor that the method can use.
    The way to stop processing would be to return from the method or throw an exception. Are you looking for something more?
    I understand the desire to leverage messaging for this process, but in truth I think you should perhaps be leveraging the EJB Timer service, as I think it provides a better model to represent a background task.
    I can't see why that won't be a perfectly valid implementation. JMS is just one implementation possibility. Thanks, Reza
  25. Re: Async side effects.[ Go to top ]

    The way to stop processing would be to return from the method or throw an exception. Are you looking for something more?
    Historically, the background task itself would monitor some flag to determine whether it should return or throw the exception. The task has to be a first class participant in the exchange in order to be able to be "cancelable". [code] for(Thing t : listOfThings) { if (taskMonitor.isCancelPending()) { break; } ... do task stuff ... } if (taskMonitor.isCancelPending()) { ... clean up premature cancel ... return; } [/code] Thread.interrupted() and Thread.isInterrupted() could perhaps be used, but that exposes a little too much low level functionality for my tastes over some first class monitoring object.
  26. Re: Async side effects.[ Go to top ]

    bah, my bad, I meant to hit preview sorry for the bad code snippet -- if an editor can come in and clean that up, that would be great.
  27. Re: Async side effects.[ Go to top ]

    Historically, the background task itself would monitor some flag to determine whether it should return or throw the exception
    Very good point. This is one aspect that needs more detail. One of the proposals was to add a method like the one you mention to the EJBContext.
  28. Re: Async side effects.[ Go to top ]

    But, an async call is not messaging.

    Messaging may be asynchronous, but that doesn't mean asynchronous calls are messaging.

    For example, with a local session bean, there's no requirement for a parameter to be Serializable. Now, one can certainly implement an internal message queue, but JMS per se can't send a message with simply a message pointer.
    You're very right that the local case has a different set of guarantees completely. There was a lot of discussion on whether or not local interfaces would be supported at all because of the differences. Also a lot of discussion on whether or not serialization would be required for all async calls regardless of the view (remote vs. local). In the draft you're allowed to ask for a persistent guarantee on an async call to a bean's local interface. In this scenario your params and return value will be serialized and a possible vendor implementation will be that a JMS broker with a persistent message store will be involved supplying the persistent guarantee. In the no-guarantees scenario of not-transacted and not-persistent, I'd suspect JMS is less likely to be used, though it's still possible. You wouldn't put the arguments/return value in the message, but a serializable key to a static map where the arguments/return value are temporarily stored. Some brokers have good "local" transports which are optimized for in-vm usage so it may or may not make sense. As far as the Future returned to the caller of the method (not the Future returned from the bean), the "cancel" method will likely be a best-effort sort of thing and not guaranteed to actually cancel the async invocation.
  29. This comment is really about Part II of the article on the Timer Service: I would like to suggest a special keyword "EndOfMonth" for the Day Of Month field, so that the method can be triggered on the last day of the month. This will save the effort of the developer to calculate/find the last day of the month. cheers romen
  30. This comment is really about Part II of the article on the Timer Service:
    I would like to suggest a special keyword "EndOfMonth" for the Day Of Month field, so that the method can be triggered on the last day of the month. This will save the effort of the developer to calculate/find the last day of the month.

    cheers
    romen
    We are actually discussing this. Thank for the feedback, though. Reza
  31. Re: EJB-lite[ Go to top ]

    Joe, Can you get a bug order in to fix the scrolling necessity of this thread? I will write in haiku-like sentences to avoid this problem: EJB-lite and EJB-regular - are they portable between them? What drives the EJB-lite requirement? Is it Spring-noise? Though a topic of a previous discussion, what impact does the concept of Web Profiles actually have for JEE? - is it to appease the folks that have limited download speeds, in order to acquire an app server platform? - is EJB-lite really addressing a problem that developers face, which is lower configuration requirements than EJB-regular? - what benefit does "light-weight" really imply? see above... I am at a loss for a good reason other than to throw Spring a bone, but the portability issue remains... Reza, I think u r doing a great job with these articles and discussions... I think ur efforts to find common ground with Spring developers is admirable and welcome... EJB 3.1 is an incredible reason to feel optimistic about the JEE specification... But, I feel that community unanimity has the potential to come at the cost of delaying truly innovative enhancements, such as: - SFSB for JAX - further JSR 299 integration - app server standardization and component portability this would be my feedback to the expert group: though Spring is a presence, there is no rule that apologizing to them for EJB is a mandate... execute on the standard, and let the competitive marketplace work its own way through the process...
  32. Re: EJB-lite[ Go to top ]

    Seems to me the promise of EJB-Lite is this. With little more than a mostly empty web.xml, and a simple JNDI data source definition (via some container mechanic) you can create a transactional web app consisting of two files: a servlet and a session bean. What you get for that is a database pool, and free transaction demarcation at the SSB boundary. Throw in a simple persistence.xml file, and an annotated entity bean, and you get instant ORM. That all comes "for free" with the container, your application has no jars, and almost no xmls. The ones you do have are very short (10 lines each or so?). If you use a JSP instead of a servlet, you can eliminate the web.xml (you'd need to look up the SSB yourself tho). If you think about it, those four components: presentation, data pool, transaction demarcation, and ORM, cover a WHOLE LOT of web app use cases. 80%+ And you get all that with effectively zero configuration. I think the minimal set is, what, @Entity, @Table, @SessionBean, @PersistenceContext, and @EJB for the servlet? That's a lot of power, IMHO. That's what I think they mean by lightweight. The container takes the brunt of it, but your application is (can be) pretty simple.
  33. Will, I plodded back to March for your thoughts following Reza's 2nd article: http://www.theserverside.com/news/thread.tss?thread_id=48684#248758 Strong analysis, against apparent conventional wisdom on this issue, and potentially not-in-line with JCP intentions.... in other words, i like it... i understand that we have all endured a very well publicized p.r. campaign against EJB's purported usability... so, if i was on the "java gulag" (a.k.a. the JCP), i would be sensitive to the marketing dimension of a new EJB spec. but this race-to-the-bottom in the form of Tomcat (apologies) means that we are addressing the needs of: - developers hostile to JEE - management hostile to JEE - Spring Source - All of the Above In other words, I agree with your March post and add that modularity, whether on OSGi or not, means that EJB-lite is perhaps nice... but it is not a priority at the expense of building out: 1. Portability 2. Innovation of EJB components 3. Ease-of-use for all constituencies I understand what u r saying in the most recent post above, and your support of some of EJB-lite's 'features'... And I am not going to implement a flame-campaign to deride the JCP's work to make EJB more 'accessible'... But i am still trying to figure out where the discussion on JAX, WebBeans, and stateful fail-over is, thats when i get interested... That's why i think this rev. of EJB is so important, even in the face of SpringSource critique, it really has the opportunity to: - simplify JEE web services development - create true component portability - win.
  34. Re: EJB-lite[ Go to top ]

    Will:
    That's what I think they mean by lightweight. The container takes the brunt of it, but your application is (can be) pretty simple.
    That's exactly right. Cheers, Reza
  35. Re: EJB-lite[ Go to top ]

    Doug: Wow! That's quite a list of questions...let me try to do them justice:
    EJB-lite and EJB-regular - are they portable between them?
    Yes and no. It's pretty easy to "upgrade" from EJB Lite to the full version. Conversely, you'd lose features going the other direction.
    What drives the EJB-lite requirement? Is it Spring-noise? What impact does the concept of Web Profiles actually have for Java EE? What benefit does "light-weight" really imply? I am at a loss for a good reason other than to throw Spring a bone...
    This is obviously a thorny issue. Let me try to explain my own viewpoint... Lightweight container advocates (that includes folks other than just hardcore Spring users) make a valid point IMHO. Imagine that all you are really doing is creating a database driven web application for a small to medium sized company that is very unlikely to grow in size, usage or complexity in the near term. Now consider the fact that additional features in any piece of software are usually accompanied by configuration complexity, administration overhead, information overload, a higher learning curve, performance implications and bugs (let alone an often larger price tag). If you could avoid dealing with the above, wouldn't you? IMHO, in the recent past, some app server vendors have made things worse by adding yet more "add-ons" on top of already large full-scale Java EE implementations. As far as I can see, Java EE "Lite" implementations that are likely to implement EJB Lite fully recognize these problems and look to be providing lightweight implementations that would have minimum feature bloat, work right out-of-the-box, allow super easy download, installation, configuration and management as well as optimize heavily for performance. I think these are very wise goals to pursue going forward if Java EE is to have greater general adoption.
    I think u r doing a great job with these articles and discussions...I think ur efforts to find common ground with Spring developers is admirable and welcome...
    Thanks for the kind words :-). Thankfully it isn't just me and there are a lot of folks in all parts of the Java EE spectrum who see the wisdom in being a little more collaborative going forward.
    But, I feel that community unanimity has the potential to come at the cost of delaying truly innovative enhancements.
    I understand the sentiment. I assure you, people working inside the JCP EGs are focused on pro-active innovation and not just deflecting criticism (although listening to valid criticism is always important). I think the genuine innovations in specs like Java EE 5, Java EE 6, JPA 1.0, JPA 2.0, JSF, WebBeans, EJB 3.0 and EJB 3.1 speak volumes to this.
    SFSB for JAX
    - I think this is stalled with the JAX-WS folks. It might be a good idea to send them your feedback directly.
    Further JSR 299 (WebBeans) integration.
    - They've done a pretty decent job so far. I've been struggling to get the attention of this EG lately. Your direct feedback might help :-). I plan to write my thoughts on this soon, but you can use the current WebBeans published draft as a basis for feedback yourself...
    Though Spring is a presence, there is no rule that apologizing to them for EJB...execute on the standard, and let the competitive marketplace work its own way through the process...
    I agree with you wholeheartedly and I think that's what everyones focus is one at any rate :-) Thanks for the support and thoughtful comments... Cheers, Reza
  36. Congrats Reza, Spring & JBoss. Impressed to see some alignment towards **easy** jee.