Discussions

News: Opinion: EJB 3.0 - Is it going to solve our problems?

  1. Michael Nascimento Santos has been very vocal on his thoughts on EJB. He has added some more ideas to the many that came out after some knowledge of EJB 3.0 came about at TheServerSide Symposium.

    Excerpt
    So, now it's time to explain why I think we can simplify EJB 3.0 even more and give tremendous flexibility for the hardcore developer without making any EJB look cluttered or ugly (some people said Linda stated it still will be necessary to use the "old model" for some hard stuff; this sounds extremely unpleasant to me, I must say). The new programming model for EJB 3.0 seems to rely heavily on annotations. This certainly is a good thing compared to the deployment descriptor hell, but there are two things missing that would make turn this idea into something really powerful:

         
    • Annotation processors: what do you do when the security capabilities of your app server are insufficient or inadequate for your needs? Change vendors? But what if the first vendor has a feature you need, but that the second one doesn't offer something similar? That's one of the flaws we're still keeping: vendors will implement the spec in some way that may not be what you need/want. And what can you do about it? Almost nothing, besides throwing your app server away or relying on a non-standard solution - sometimes, it means not using EJBs for a part of your project they'd be the perfect fit if only that feature had been implemented in a better way by your app server vendor. What if you could write implementations for the services an EJB container should offer? You may now say: "hey, but that's exactly what I've paid for", but it's often needed. Vendors are not capable of foreseeing every need you'll have. It'd be even better if we had a standard spi for all the services an EJB container is supposed to provide. In that way, you could swap small components or, even better, write a decorator around a app server specific implementation so that you could only provide the one missing functionality you need - instance-based security for entity beans, for example - and delegating the other features to your app server default implementation. Imagine how many problems you would be able to solve if you could change or augment the functionality provided by an application server in a standard way! I can tell you it would solve around 80% of my issues with EJB. The other 20% would be solved as shown below:
    •     
    • Support for custom, user-defined annotations: frequently, we need to add services to our components that are not part of the EJB spec. If this feature is not so domain-specific, chances are some vendor has provided support for it. And then, welcome to vendor lock-in! You are left with two choices: go for vendor lock-in or write terrible code just in order to have a portable application. Wouldn't it be nice if you could solve it in a elegant, portable way? Custom annotations and custom annotation processors could be the answer. Imagine if you could write an small session in an deployment descriptor declaring a custom annotation and an implementation of an interface, AnnotationProcessor, that's capable of handling it. You could define your own implementation or simply delegate the processing of your custom annotation to a class provided by your container of choice. You could get portability and still benefit from non-standard features your vendor offers you. Annotations without properly-configured processors would be simply logged at deployment time, since they could be there for a nice reason - for example, you might want to "tag" your methods for some functionality first and implement it after; or maybe that annotations are meant to provide enhancements during runtime and don't represent essential services, like caching, for example.
    I am pretty sure some people will say: "Spring (put your favourite lightweight? container here) can do that" or "this is a case for an AOP-based container". I totally agree with the first and I think an AOP-based container would be a good implementation, but the real point is: these are not standards. There is only one Spring - some people might be writing a few implementations for its interfaces, but they are just some people, not major vendors with hundreds or thousands of experienced employees working full-time on that - and AOP frameworks I know are completely different from each other. If we could come to agreement on what basic services an EJB container should provide, a SPI for them and a way to plug custom annotations and to process them, we could get ease of use with maximum flexibility and ability to choose without limiting you to rely on a single vendor for the rest of your life. Vendors would have to provide amazing implementations for each EJB container service and offer a lot of high-quality custom services if they wanted to keep up. A new market of service providers would arise and we'd see a constant increase in the quality of each comercial container out there.
    Read Michael Nascimento Santos thoughts in EJB 3.0 - Is it going to solve our problems?

    Threaded Messages (29)

  2. how can it?[ Go to top ]

    It may fix lots of exising issues with EJBs, but how can it solve the problem completely if it requires a container to run in?

    -jp
  3. how can it?[ Go to top ]

    It may fix lots of exising issues with EJBs, but how can it solve the problem completely if it requires a container to run in? -jp
    It must be possible to implement current EJB specification as library too, I am not sure about current OpenEJB status, but it was designed this way. I think it is a good idea, unit test or web application can host EJB container if it is designed this way, but probably home made library can do it better without standards.
  4. RE: how can it?[ Go to top ]

    It may fix lots of exising issues with EJBs, but how can it solve the problem completely if it requires a container to run in? -jp
    It must be possible to implement current EJB specification as library too, I am not sure about current OpenEJB status, but it was designed this way. I think it is a good idea, unit test or web application can host EJB container if it is designed this way, but probably home made library can do it better without standards.
    Portability and flexibility are serious issues, and I'd say more: they're maybe the major issues nowadays. Since EJB 3.0 is making things simpler and more POJO-oriented, we just need more power to augment container's functionalities in a portable way. Then, we would have a standard that's flexible, extensible and portable. Getting rid of the container would be the only issue left, but I don't have a problem with that, since it'd become possible to write a JUnit specialization for supporting EJB 3.0 out-of-container testability.
  5. RE: how can it?[ Go to top ]

    It is usefull for IDE too, It is not a very big problem to setup remote debugger and to add deployment directory to project classpath,
    but it must be a better way to use container as library.
    It is not a very big problem to implemet this kind of library or to strip some open source container, but all of containers have native features and people need it too.
  6. There is widespread recognition now of the fact that not all J2EE projects
    need to go with EJBs, at least to begin with.

    However as applications evolve and mature and need to scale up (need
    support for transactions, distribution, clustering, multiple client types
    etc.), they may need to migrate to EJBs. Thus anything in the spec that eases
    this migration could be a big help. It may also help with unit-testing business
    logic outside the container.

    One specific area that I can think of to have a persistence approach that
    works both inside and outside the container (whether based on Hibernate
    or JDO).

    One argument I have seen against it is that big vendors may see it going
    against their interest. I, however, feel that this would only ease migration
    to app servers without throwing away too much code.

    Any thoughts on the above or suggestions along similar lines?

    Thanks,
    Kalyan
  7. how can it?[ Go to top ]

    It may fix lots of exising issues with EJBs, but how can it solve the problem completely if it requires a container to run in?
    Maybe I'm just dumb but I'm unclear as to how some J2EE services can be provided without a container such as Clustering and creating distributed applicaitons?

    Perhaps all we need is the ability to deploy EJBs in a lightweight manor. Is there anything in the spec that is disallowing this?

    I could argue that even Spring isn't "containerless". Spring still manages, creates and destroys all of it's beans inside of an ApplicationContext. Couldn't it be argued that the ApplicationContext is some type of container as well?

    I guess what I'm thinking is that many people seem to equate the term "container" with a server. However, does the EJB specification really require ejbs exist in a seperate server from the application that's using them? Obviously not since this is the case for many Web applications that use EJBs. Couldn't an EJB container be made lightweight enough to deploy ejbs with limited functionality in the same manor Spring does? By moving ejbs out of a server they would inherently lose their clusterability and distributed natures basicly becoming what a spring bean is. Maybe I'm wrong but it would seem that if spring wanted to provide all the same services EJBs provide wouldn't it have to create a server for its container as well. Anyway, just some thoughts.

    Mike
  8. how can it?[ Go to top ]

    Yes, it is more implementation decision, but container is more about server than library, it hosts components (manages life cycle) and EJB specifies deployment procedure, probably it doe's not conflict with container implementation as library too, but I see no problems to host library with services like clustering on server or to manage application life cycle in "main" method.
  9. how can it?[ Go to top ]

    Actually, I don't believe the EJB spec doesn't say anything about deployment. So it would seem that if one wanted to they could create a serverless EJB implementation that simply deploys one or more ejb-jars by simply calling a method and specifying the location of the ejb-jar. Just like how in spring you specify the location of an applicationContext file. The EJB implementation would have to be able to provide services through JNDI but that would be mitigated by EJB3 with it's dependency injection.

    Anyway, I think you're right Juozas. The fact that EJBs are generally deployed in standalone servers is more of an implementation desision rather than a specification limitation.

    Not to say that Spring doesn't provide many different features from EJBs, however, I don't think that the fact that Spring doesn't require a server isn't necissarily one of them.

    Mike
  10. how can it?[ Go to top ]

    Maybe I'm just dumb but I'm unclear as to how some J2EE services can be provided without a container such as Clustering and creating distributed applicaitons?
    Ok, explain to me what you want to cluster that can't be clustered in a servlet container? Why do you NEED distributed applications? Do you REALLY need that? If you really need to separate some logic out to use as a remote service, wouldn't Web Services work better (as it can allow any type of client to access it)?

    Don't fall for the trap of assuming you need what an EJB container is providing.
  11. how can it?[ Go to top ]

    Good point. However, do web services currently easily provide services such as distributed transaction unification and security propogation? Some of the many services a EJB container now provides? I have no doubt that web services will evolve to provide these services and as all of these services get piled onto a servlet container at what point does this servlet container become something more than a simple servlet container? Is a Servlet container really all that different from an EJB continer? Fundamentally they both provide services to remote clients. They just do so at different abstractions.

    I'm not saying that we NEED in ALL situations seperate servers and service containers distributed all over. In fact my point was that I didn't see why people seem to believe that EJBs REQUIRE a seperate server. I don't see anywhere in the EJB spec that says EJBs must be deployed in their own server in a different process from the application that is using it.

    I am, however, open to believing that more than one kind of container can be of some value. Servlet containers are good at creating web content. When configuring web services on top of a simple servlet container becomes too much I'm open to abstracting that complexity into another kind of server that may simplify configuration of the services provided by web services. A servlet container may be all that we need now but why limit ourselves?

    Mike
  12. Hi Michael
    ... It'd be even better if we had a standard spi for all the services an EJB container is supposed to provide. In that way, you could swap small components ...
    This is an excellent idea. They could define an spi for a persistence service for example. Or maybe even integrate the persistence API that already exists: Java Data Objects (JSR12 and JSR243). Imagine that! JDO works well in application servers today but the JDO vendors have to do a lot of work to make that happen.

    I don't think there is a lot of incentive for the vendors involved to make EJB containers pluggable at the level you are suggesting. That would make it easier for new competitors to enter the market by providing a really good implementation of one spi. People would want to pay less for an app server if they were only using the best parts of it.

    Cheers
    David
  13. Hi Michael
    ... It'd be even better if we had a standard spi for all the services an EJB container is supposed to provide. In that way, you could swap small components ...
    This is an excellent idea. They could define an spi for a persistence service for example. Or maybe even integrate the persistence API that already exists: Java Data Objects (JSR12 and JSR243). Imagine that! JDO works well in application servers today but the JDO vendors have to do a lot of work to make that happen.I don't think there is a lot of incentive for the vendors involved to make EJB containers pluggable at the level you are suggesting. That would make it easier for new competitors to enter the market by providing a really good implementation of one spi. People would want to pay less for an app server if they were only using the best parts of it.CheersDavid
    That's exactly what Orion did: they provided a custom persistence layer a while back and guess how many people are known to use it? None. That doesn't mean nobody's using it, but I would be willing to guess that the number would be absurdly low. You don't buy a wheel so you can build your own. You buy it so you don't have to build it.
  14. Importance of SPIs[ Go to top ]

    That's exactly what Orion did: they provided a custom persistence layer a while back and guess how many people are known to use it? None. That doesn't mean nobody's using it, but I would be willing to guess that the number would be absurdly low. You don't buy a wheel so you can build your own. You buy it so you don't have to build it.
    Hi Joseph,
    I had to do some hacks myself to implement some security and persistence requirements for a few applications and I must say it was a painful experience. Although these containers were "designed for extensibility", you have to know a lot about the implementation details of your app server to get things right and you still end up with a non-portable solution.
    The total lack of portability for this kind of services is what blocks people from taking advantage of the support for extensions some vendors provide. What is the point of writing tons of code to get something done if it won't work for other application servers - and maybe what you want to achieve may be impossible to do in other containers. People who need these features are mostly framework or product developers and portability is a must for them, unless they work for a specific vendor. Maybe that's why (nearly) nobody has used this feature in Orion: they needed something portable. If it just works in Orion, it has no value at all for them.
  15. a *standard* api[ Go to top ]

    If you reread David's post, he is suggesting that *standard* SPI's be defined for services such as persistence. NOT proprietary API's like the one you described. Of course nobody is going to roll their own persistence API these days. There is already a POJO standard (JDO) with many compliant implementations. I believe David is suggesting that it would be fruitful for the EJB spec to consider and be inclusive of the existing SPECS that are out there for persistence. This would be of great value not just to the user, but to the vendor who could bring his app server to market faster.

    -geoff
  16. It'd be even better if we had a standard spi for all the services an EJB container is supposed to provide. In that way, you could swap small components ...
    That's how Globus works. Instead of a monolithic container, the framework is defined as a collection of standard service interfaces that allows the infrastructure to be componentized, distributed, and pluggably reimplemented.
  17. Why do we need 3.0 ? Also is there going to be a draft of ejb 4.0 by the time ejb 3.0 is released ? Then we better wait for 4.0.

    Too many versions are not a easy thing to manage in big companies. There is a cycle of about 3 to 5 years when big changes are made like Appserver version change etc.

    And before anyone from the forum try to tear this thought apart, just a FYI - i work at #3 bank in the US and know things inside out here.
  18. Why do we need 3.0 ? Also is there going to be a draft of ejb 4.0 by the time ejb 3.0 is released ? Then we better wait for 4.0. Too many versions are not a easy thing to manage in big companies. There is a cycle of about 3 to 5 years when big changes are made like Appserver version change etc. And before anyone from the forum try to tear this thought apart, just a FYI - i work at #3 bank in the US and know things inside out here.
    Great point Sean. We seem to endlessly argue academics on these threads and overlook operational and management considerations to software engineering. IT managers aren't going to expend budgets because EJB 3.0 or Hibernate or XYZ is cool. The firms I work for have a 18 month cool off period for any new technology to be put on a "Development BluePrint" never mind be considered for production.
  19. Why do we need 3.0 ? Also is there going to be a draft of ejb 4.0 by the time ejb 3.0 is released ? Then we better wait for 4.0. Too many versions are not a easy thing to manage in big companies. There is a cycle of about 3 to 5 years when big changes are made like Appserver version change etc. And before anyone from the forum try to tear this thought apart, just a FYI - i work at #3 bank in the US and know things inside out here.
    Great point Sean. We seem to endlessly argue academics on these threads and overlook operational and management considerations to software engineering. IT managers aren't going to expend budgets because EJB 3.0 or Hibernate or XYZ is cool. The firms I work for have a 18 month cool off period for any new technology to be put on a "Development BluePrint" never mind be considered for production.
    Thanks for sharing your experience with me. I dont feel alone in this thread.
  20. You are not alone, it is just not very interesting to talk about this :)
  21. Too many versions are not a easy thing to manage in big companies. There is a cycle of about 3 to 5 years when big changes are made like Appserver version change etc. And before anyone from the forum try to tear this thought apart, just a FYI - i work at #3 bank in the US and know things inside out here.
    The firms I work for have a 18 month cool off period for any new technology to be put on a "Development BluePrint" never mind be considered for production.
    That's why we should start fighting now. Imagine if the EJB spec version you'll be using in 2008-2010 still doesn't support those things. I feel sad it doesn't support them now! If we start thinking like that, those technologies will never evolve. That's definitely a bad thing, imho.
  22. Too many versions are not a easy thing to manage in big companies. There is a cycle of about 3 to 5 years when big changes are made like Appserver version change etc. And before anyone from the forum try to tear this thought apart, just a FYI - i work at #3 bank in the US and know things inside out here.
    The firms I work for have a 18 month cool off period for any new technology to be put on a "Development BluePrint" never mind be considered for production.
    That's why we should start fighting now. Imagine if the EJB spec version you'll be using in 2008-2010 still doesn't support those things. I feel sad it doesn't support them now! If we start thinking like that, those technologies will never evolve. That's definitely a bad thing, imho.
    Even if we ask for features, it may not be implemented. I would like to see somehting which will migrate my ejb 1 to ejb2/ejb3.0 etc without many issues. Most of the people out here dont know the cost of just regress testing financial applications, forget about the cost of coding and building etc. So I know its good to contribute to some JCP JSRs etc, but its just too much to think into when someone isnt upto the current version yet.
    And IN MY opinion its EJB 3.0 will also leave out a lot of features due to lack of time and other politics at higher level and developer community will suffer for sure. So I will let it go. I m just looking at ways to get away from EJBs. It doesnt offer me that many services compared but more complexity and version issues. And before bashing my opinion, please read that its my humble opinion :).
  23. I presume, it's not called enterprise for nothing. It's intended for enterprises. If you ever had the 'pleasure' to work for a Global 200, 500, whatever company, you know those companies move slow. Very slow. And if they decide to move a little bit, they tend to make just careful adaptations in the direction they move, in order to protect past investments. Does the word 'legacy system' ring a bell? Those systems are still around exactly for the reason of protecting past investment, and of course the cost of setting up something brand new, polished, state of the art in place of the old. Hibernate, JDO, who cares? Let me tell you what questions are raised when you want to use your fav (framework, technology, product, etc). Is there support for it down the line? How much would it cost to roll out? Staff needs to be retrained? And then: what are the benefits? And if the potential benefits don't add up to the cost of the other factors, nothing will change. It is frustating from the developers' point of view, who just want to press ahead with the latest and greatest, but this is how it works.

    You can fight in the evory tower for whatever you please, just don't expect the enterprises move as fast as you do.
  24. Let me tell you what questions are raised when you want to use your fav (framework, technology, product, etc). Is there support for it down the line? How much would it cost to roll out? Staff needs to be retrained? And then: what are the benefits? And if the potential benefits don't add up to the cost of the other factors, nothing will change. It is frustating from the developers' point of view, who just want to press ahead with the latest and greatest, but this is how it works.
    You are right, most innovations are sold like new cool toy for monkey, I am not marketing expert, but I thing marketing must answer your questions first. I see no problems in "legacy systems" , we are trieng to find new ways, but they can be wrong too. If marketing can ansver your question then you can decide to accept the risk or not. It is out of developer competence and as I said it is not very interesting to talk on this forum.
  25. Pluggable Annotations with AOP[ Go to top ]

    The author says "a way to plug custom annotations ". We've been saying this for awhile now that annotations + AOP are a great way to express and apply pluggable functionality.

    We have this ability with JBoss AOP as annotations are built into our pointcut expression language. Also, we have the ability to introduce annotations to existing classes as well. We have also written an Annotation Compiler for JDK 1.4 so that you can embed annotations with JDK 1.4 classes and use them with a JDK 1.4 compiler.

    See our website and WIKI for more details:

    http://www.jboss.org/products/aop
  26. Hi Bill,
    I do use JBoss in my daily work and I like it a lot - besides that nasty bug with rollback for timed-out transactions :-D. JBoss AOP does seem nice, although I am a AspectWerkz user. Most AOP frameworks are capable of processing annotations. However, as I said in my blog, it's definetely not enough. We need a standard way to process any annotation in a pluggable way and even to process EJB 3.0 "core" annotations. There should be a standard API for that and a standard SPI for specific built-in services.
    In most companies and for lots of other situations, you simply don't want to deal with JBoss AOP, AspectWerkz, AspectJ or dynaaop APIs; you want portable code, that runs in any container, no matter what - or whether - you are using an AOP framework.
  27. no matter what - or whether - you are using an AOP framework.
    Ooops, should read things first before pressing Reply :-D
    I actually meant: no matter which AOP framework you're using (if any).
  28. Hi Bill,I do use JBoss in my daily work and I like it a lot - besides that nasty bug with rollback for timed-out transactions :-D. JBoss AOP does seem nice, although I am a AspectWerkz user. Most AOP frameworks are capable of processing annotations. However, as I said in my blog, it's definetely not enough. We need a standard way to process any annotation in a pluggable way and even to process EJB 3.0 "core" annotations. There should be a standard API for that and a standard SPI for specific built-in services.In most companies and for lots of other situations, you simply don't want to deal with JBoss AOP, AspectWerkz, AspectJ or dynaaop APIs; you want portable code, that runs in any container, no matter what - or whether - you are using an AOP framework.
    AFAIK, we're the only AOP implementation that supports annotations at this time. Also, JBoss AOP does work in any container.
  29. AFAIK, we're the only AOP implementation that supports annotations at this time.
    AspectWerkz can handle its own custom annotations right now.
    Also, JBoss AOP does work in any container.
    You missed my point. Is JBoss AOP an implementation of a JSR? No. Does JBoss AOP let you augment your container functionality in a standard way? No. In fact, no AOP framework has these properties. That's something I mentioned in my original blog entry.
    The main issue is: we need a way to change/augment the functionality provided by application servers in a standard way. It must be a standard; otherwise, it might not be portable.
    Please, don't get offended. I do like JBoss, the app server, and the AOP framework has some pretty nice good features (it could be less xml-ized, I think). But I'm talking about standards and they may not even have to require AOP to work - AOP is an implementation strategy in this case.
  30. Most AOP frameworks are capable of processing annotations. However, as I said in my blog, it's definetely not enough. We need a standard way to process any annotation in a pluggable way and even to process EJB 3.0 "core" annotations.
    Maybe, in addition to working on a stardard API for AOP frameworks, AOP Alliance should also work on standard AOP annotations.

    -talip