Home

News: New Article: New Features in EJB 3.1 - Part 5

  1. New Article: New Features in EJB 3.1 - Part 5 (10 messages)

    In this last article of the series, Reza Rahman will talk about standardized global JNDI names for Session Beans and EJB 3.1 Embeddable Containers for Java SE environments. All of this is just a peek into the inner workings of the JCP so that you have a chance to provide feedback. Read article
  2. I think that getting REST embedded in to the EJB tier, in the same way that SOAP web services are part of the EJB tier will be a great benefit to the EJB platform. Here's why. Simply put, in the 90's, we had classic Client/Server with Power Builder and its ilk talking to a central Database. Today, instead of Power Builder and Database being the Client and Server pieces, respectively, it's now becoming the RIA and App Server making up those components. The most popular RIA platform by far (in varying levels of sophistication) is the modern browser with JavaScript. Most RIA browser apps talk back to the server using, typically, just HTTP POSTs and GET with multi-part Form, XML, and JSON as payloads. Notably, most of these apps are NOT using SOAP unless they have to, because at the moment, the Browser isn't a particularly easy SOAP client. So, instead developers ad hoc an API and protocol using more Browser friendly artifacts, and that's the GAP that "REST Style" back end services are supplying. Currently, that's all implemented, in Java at least, in the web tier using Servlets, a REST framework (e.g. Jersey), or a common action framework (Struts, Stripes, etc.). And from there, classic web tier programming takes over. The problem here, at least in the EJB environment, is that the Web tier is on the "wrong side" of the transaction barrier. Whenever you call a Session Bean, you cross a transaction demarcation line, within which Magic happens. We see in many web tier idioms, notably those use ORMs, how developers have contrived mechanisms to move that transaction barrier up to the HTTP request level (typically with a Filter or somesuch thing). While imperfect, and fiddly, it's a workable solution. Now, we have Seam, and one of its great claims to fame is that it pushes the "action logic", which would normally be done within the web tier, back in to the EJB tier and in to a Session Bean, back behind the transaction wall. If you use an EJB backed Web Service, its logic, being a Session Bean, is also on the inside of that transaction barrier. So, what we're seeing is all of the mechanisms designed to really push the transaction barrier offered by the EJB container farther up the request chain. REST based EJB Web Services would fill that need very nicely. With EJB 3.1 "lite" coming up, where we can deploy SSBs in to WARs directly, we can see how the "web tier" is getting thinner and thinner. Eventually, it will be reduced to little more than Filters and Listeners, with all of the actual logic being in Session Beans behind the transaction barrier. Having REST based EJB web services will make the EJB server a really "killer" platform for the RIA domain, offering a clean solution without all the gimmickry and plumbing that the current idioms require in order to leverage transactions. And if this can be done with EJB "Lite", then all the better.
  3. Will, I agree with you a 100%. The debate is whether JAX-RS integration belongs with WebBeans or EJB. Some folks are arguing that JAX-RS is too HTTP-centric to be integrated with EJB. Since WebBeans much more closely mirrors the HTTP life-cycle, JAX-RS really belongs there, the argument goes. As I see it, I think the distinction is tenuous and JAX-RS integration belongs in *both* places, as to give developers the option to use either technology as their JAX-RS powered back-end and not have to use both. Cheers, Reza
  4. Hi Will, It will certainly be possible for JAX-RS resources to delegate to session beans. The no-interface view and .war packaging simplifications in EJB 3.1 will make that very easy to do. Given that, how important do you think it is that the JAX-RS resource itself be an enterprise bean class? In that case, how would you expect a container-managed transaction failure to be handled for a JAX-RS POST method performing a db update? Wouldn't you need to know the result of the tx commit before producing the returned content? It's fine for a JAX-WS client to receive an exception but that wouldn't work well for a browser.
  5. Ken, Great to see you on TSS and discussing these issues with the greater community beyond the EJB 3.1 EG as spec lead! I saw your overview of EJB 3.1. Nice job on it. I hope folks will read the spec and provide us comments just as Will has. Personally, my answer to the question you posed is that the developer should have the flexibility to let simple JAX-RS cases to be handled by EJB alone. As to the exception handling, couldn't we mirror what's in JAX-WS? How about returning an appropriate HTTP error code? Cheers, Reza
  6. Standardizing JNDI names is necessary and I'm glad to see it being done. My initial impression is that the long name and even shortened name are too long. I'm used to "AccountService" bean, or "AccountsDAO" bean in Spring XML config. I can see Spring users complaining about the long names for EJBs when most of the time they will be in the same .war file as the rest of the app. The long name will be necessary in some cases, but it would be great if I could just lookup "AccountService". Yes I would expect to be able to expose EJBs as JAX-RS endpoints in addition to JAX-WS and JAX-RPC. I also want to be able to use JAX-WS, JAX-RPC and JAX-RS endpoints in the same EJB, or at least in the same project. In one of my apps I expose the service layer as JAX-WS for use by other applications. One of the applications could not use it because it only supported JAX-RPC. I had a real hard time trying to expose the same methods as both JAX-WS and JAX-RPC in NetBeans and wasn't sure if it was a restriction of NetBeans or EJB 3. I'm also surprised that Embeddable EJB 3.1 only requires the feature set of EJB 3.1 Lite. That means there will be some things I can't unit test unless my EJB 3.1 embeddable container provider went over and beyond what was required. However the EG probably chose to do this because of the lowest common denominator: EJB 3.1 Lite app servers. I'd like to see a more complete unit test example. Show me a unit test of an EJB using JPA with transactions, show me the persistence.xml for production that uses JTA and JNDI data source, and probably a different persistence.xml for unit testing that uses local transactions and inline JDBC connection information. Do you recommend we choose local transactions instead of JTA for all EJB's that use JPA except when we need to use multiple transactional resources in the same transaction? Is there such a thing as local transactions for JMS, or only for JPA?
    One possible feature that is closely related to embeddable containers is support for injecting EJBs into non-managed unit test classes. However, this enhancement will need to be specified at the Java EE 6 level and is difficult to achieve solely in the EJB 3.1 expert group. Do you think that would be valuable? @RunWith(EmbeddableEJB3Runner.class)
    Yes I love it!! I was wondering how we were going to do this since Spring offers something similar. One of the things Spring offers is an AbstractJpaTests class that you extend, and one of the overridden methods returns the path to Spring config file(s). It injects beans into my class and rollsback transactions after each test. It has one big problem: it's stuck on Junit 3. I can't use it with JUnit 4. I am concerned that a standardized EmbeddableEJB3Runner will get stuck behind the times over the next 3-4 years, and people will be wanting Junit 5, Test NG, or the next big thing. I would like to see some examples of how I can take any class from any library, turn it into an EJB using ejb-jar.xml, inject dependencies it needs, then use it as a dependency in one of my EJBs. I'd like to see you do this with several instances of the same class, configured differently, and with different bean names so I can choose the one I want. An example of this in Spring is DataSource objects. Without adding annotations to the source I can configure multiple instances of this object and inject the instance I want into other beans. I'm also wondering about about more advanced injection techniques like in constructors, factory methods, etc. Will I need WebBeans for this? Will webbeans support container managed transactions or will it require EJB for that? Regarding RIAs, I think once JavaFX applet developers realize that applets have built in support for accessing remote EJBs, they will try EJB 3.1 and discovering how powerful it has become. Regarding Spring integration, I figure they are going to support EJB 3.1 anyway for WebLogic and for their own Java EE 6 Web Profile certified platform. I only wonder if this support will become built in, or will always be an addon. What can EJB 3.1 do for Spring? Will it natively support Spring's applicationContext.xml format, AOP pointcuts, etc? Keep up the great work, I'm looking forward to Java EE 6 and EJB 3.1.
  7. Ryan, First of all, many thanks for the kind words and your excellent comments. Here are some of my thoughts on your points:
    My initial impression is that the long name and even shortened name are too long.
    Point taken and I will follow this up with the EG. Other folks have made the same comment. An issue to consider here is the potential performance problem at deploy time while scanning for naming conflicts across the application. Keep in mind, Spring applications do not have to take this into account because registered components are not sharable across applications (a key EJB feature IMO that lead to better modularization for larger applications). Also, vendors will still maintain the current short names, so GlassFish, etc will probably still have "ProductService", "ProductDao" style very short names in JNDI. Finally, remember that look-ups are an edge case anyway. Using DI, at best you'll need to specify the short @EJB 'name' attribute, along with the EJB class to resolve a bean.
    Yes I would expect to be able to expose EJBs as JAX-RS endpoints in addition to JAX-WS and JAX-RPC.
    Obviously, I agree :-)
    I had a real hard time trying to expose the same methods as both JAX-WS and JAX-RPC in NetBeans and wasn't sure if it was a restriction of NetBeans or EJB 3.
    Can't comment on this off-hand - haven't tried it. I didn't have any trouble having RMI remote and JAX-WS interfaces for the same bean. Remember, currently you cannot have the same interface for both RMI remote and JAX-WS. This is overly restrictive IMO, but this is pretty minor I think, particularly since the counter-argument is going to be that interfaces should be protocol specific. It's hard to offset arguments that are very rooted in pedantic ideas :-).
    I'm also surprised that Embeddable EJB 3.1 only requires the feature set of EJB 3.1 Lite.
    As I mentioned in the article, most of the vendors you probably will be using likely will implement the full spec.
    I'd like to see a more complete unit test example.
    Remember, unit testing is not the sole focus of the embeddable container enhancement. However, the goal is to provide all the correct infrastructure for vendors and third parties to develop effective unit testing tools. For example, if you look at the spec, there are facilities to provide resources such as ejb-jar artifacts programmatically to the container at runtime, effectively providing the capabilities you mentioned. BTW, we are devoting an entire chapter of the second edition of EJB 3 in Action to unit and integration testing.
    Do you recommend we choose local transactions instead of JTA for all EJB's that use JPA except when we need to use multiple transactional resources in the same transaction?
    This is an interesting topic since one of the things I intended to push for in EJB 3.1 is standardizing the use of local transactions for EJB. Since my primary motivation for this was performance, I did a home-made benchmark. To my surprise, I could not find a discernible performance problem. After talking with a few vendors, what I found out is that these days most JTA providers heavily optimize the two-phase commit protocol when they detect a single resource, effectively "downgrading" to local transactions. I think the smartest move is to standardize this optimization when there is a maintenance release of JTA.
    Spring...injects beans into my class and rolls back transactions after each test.
    You can do this very easily in EJB by injecting the session context in the unit test and doing a roll back on unit test tear down. Again, this can be handled by specific unit test tools built on top of embeddable containers and through best practices. My EJB 3 JUnit runner example, is in fact intended to be a third-party unit testing tool built on top of embeddable container infrastructure. Other things that can be built around the embeddable container is tools for tighter integration with Tomcat or Jetty.
    I'm also wondering about about more advanced injection techniques like in constructors, factory methods, etc. Will I need WebBeans for this?
    Yes, this is squarely in scope for WebBeans, along with a host of very cool stuff around DI, AOP, annotations meta-programming and application glue-code. IMO, it doesn't make much sense to replicate this again in EJB 3. As I outlined in the previous article in the series, it's trivial to use EJB 3 and WebBeans together.
    Will WebBeans support container managed transactions or will it require EJB for that?
    There is no plans for transactions support in WebBeans. Again, it's trivial to combine WebBeans and EJB 3 for this purpose, especially with EJB 3.1 Lite (simply placing one annotation?).
    Regarding Spring integration, I figure they are going to support EJB 3.1 anyway for their own Java EE 6 Web Profile certified platform.
    I'm actually involved in doing this. This is indeed the plan. What's still not clear to me is whether EJB 3 will be supported in just the platform or the framework as well. I would like to see it supported both places. It's very easy to do technically.
    What can EJB 3.1 do for Spring? Will it natively support Spring's applicationContext.xml format, AOP pointcuts, etc?
    That's the idea. I've just started work on this and hope to make the process as community centric as possible. I am trying to do this as a SpringSource initiative, I'm hoping that's going to be workable. So far so good... Cheers, Reza
  8. Hi guys,
    One possible feature that is closely related to embeddable containers is support for injecting EJBs into non-managed unit test classes. However, this enhancement will need to be specified at the Java EE 6 level and is difficult to achieve solely in the EJB 3.1 expert group. Do you think that would be valuable?

    @RunWith(EmbeddableEJB3Runner.class)

    Yes I love it!! I was wondering how we were going to do this since Spring offers something similar. One of the things Spring offers is an AbstractJpaTests class that you extend, and one of the overridden methods returns the path to Spring config file(s). It injects beans into my class and rollsback transactions after each test. It has one big problem: it's stuck on Junit 3. I can't use it with JUnit 4.
    I'd like to share a few things about Spring's integration testing support with regard to JPA and EJBs:
    • AbstractJpaTests was added in Spring 2.0 to provide explicit support for integration testing JPA based code which uses a JPA provider that requires shadow class loading.
    • In Spring 2.5 we introduced the Spring TestContext Framework which can also be used to write integration tests for JPA based code with JUnit 3.8, JUnit 4.4, or TestNG.
    Both of these options provide support for configuring the path to Spring config files, transactional test methods, and rollback or commit after test completion. The primary difference between the two is that the TestContext framework does not provide out-of-the-box support for shadow class loading; however, load-time weaving can also be enabled with a VM agent. So if you start your tests with "javaagent:spring-agent.jar", JPA tests will run just fine as long as the LocalContainerEntityManagerFactoryBean is provided with an InstrumentationLoadTimeWeaver as "loadTimeWeaver". The main benefit of shadow class loading is that different class transformers can be used on a per-test basis. This allows the use of multiple persistence providers in the same test VM. However, this is something that mainly Spring's own test suite benefits from. This is not necessarily of much use for typical application test suites - where there is only one actual persistence provider to test against (at any given time). In many cases, however, you won't need instrumentation, and you can simply convert your AbstactJpaTests-based classes to use JUnit 4.4 and @RunWith(SpringJUnit4ClassRunner.class), and the tests will just work. In summary, although it's true that AbstractJpaTests is based on JUnit 3.8, you're not stuck on Junit 3: you can write integration tests for JPA based code using JUnit 4.4 and the Spring TestContext Framework.
    I am concerned that a standardized EmbeddableEJB3Runner will get stuck behind the times over the next 3-4 years, and people will be wanting Junit 5, Test NG, or the next big thing.
    SpringJUnit4ClassRunner already supports annotation-based DI from a Spring ApplicationContext via @Autowired and @Resource. When coupled with Spring's support for accessing EJBs (e.g., via or ), integration tests can be automatically injected with references to EJBs without the need for @EJB. The following Spring TestContext Framework based example would therefore work nicely in conjunction with an embeddable EJB 3.1 container. @RunWith(SpringJUnit4ClassRunner.class) public class PlaceBidTest { @Autowired private PlaceBid placeBid; @Test public void testAddBid() { placeBid.addBid(new Bid("rrahman", 10059, 200.50)); } } Furthermore, the Spring TestContext Framework supports the exact same style of integration testing in JUnit 3.8/4.4 and TestNG and will most certainly be upgraded to work with future releases of those testing frameworks as well. So hopefully that addresses the concerns you raised. Regards, Sam Brannen (author of the Spring TestContext Framework)
  9. Sam, Thank you very much for taking the time to comment. Indeed, I do think leveraging existing Spring testing tools for EJB 3 is a great idea. I have to admit I overlooked it, so thanks for the reminder. Cheers, Reza
  10. Holy crap...there's a part 5 to this...
  11. Amin, Not sure what you mean exactly, so I'm having a hard time figuring out how (and if) to respond...the changes in EJB 3.1 are quite significant and I barely scratched the surface in terms of features. From all accounts, they seem to be quite well received so far as well. At any rate, this is the *last* in this series. Cheers, Reza