Richard Monson-Haefel's Blog

13 improvements for EJB

What struck me, after counting and grouping relevant posts, was that the developer community desperately desires a simpler programming model for EJB.

In particular developers appear to be most interested in the following:

1. Ditch CMP or make it simpler like Hibernate or JDO
2. Use a POJO programming model
3. Add support for Interceptors/filters/AOP.
4. Eliminate/Consolidate the component interfaces (remote, local and endpoint).
5. Make deployment descriptors more like XDoclet
6. Instance-level authentication/entitlement.
7. Replace the JNDI ENC with Dependency Injection (a.k.a. IoC).
8. Add a Mutable Application Level Context
9. Support development and testing outside the container system.
10. Define cluster-wide singletons for EJB.
11. Clearly specify and standardize class loading requirements.
12. Standardize the deployment directory structure for EJBs.
13. Support Inheritance.

Some of the items can be grouped together to give more weight to a particular approach. For example, item 1, 2, 4, 7, 9 and 13 all seem to point at a CMP programming model that is more like Hibernate. Hibernate uses a POJO programming model with dependency injection (IoC) and is not dependent on client interfaces. In addition, Hibernate applications can be developed and tested without a container system. A tip of the hat to Galvin King and crew.

Other items were interesting but not surprising like asking for an XDoclet-like vendor-agnostic deployment processes. This is a big concern of mine since EJB isn't really portable in its current incarnation � you can't just drop an EJB JAR into most J2EE servers without adding some vendor specific deployment information. Actually this aligns nicely with the request that EJB define a standard directory structure for deployments similar to Web components.

The mutable application level context was a surprise for me. Standardization and specification of class loading behavior was not a surprise. Requests for instance-level authorization was also expected � it's something developers have been asking for since EJB 1.0.

I was delighted to see so many posts on this subject. Clearly people feel there is much to be done. I was less excited to see the thread wander off into Spring vs. JBoss vs. Mike Spille territory � but I found those posts interesting too.

Obviously, there are better mechanisms for measuring public opinion than a blog. Perhaps someone will take on the task of organizing a more accurate pole, but for me the information and posts were very informative. I read every one of them. I greatly appreciate the time and effort so many put into responding. Thank you.

I'm sharing these findings with the JSR 220 (EJB 3.0) Expert Group and expect your comments will generate a lot of discussion and a great deal of solid action by the group members. Keep an eye on JSR 220, eventually it will make it into public review at which time you'll have something solid to review and comment on. Your feedback is critical to the success of EJB.

Comments

• Blogs are okay
  Blogs (and discussions like TSS) aren't too bad as mechanisms for deciding what people think are important. Most online polls are too simplistic - It is too easy to press a button that says "Make CMP simpler". At least with a TSS thread or a blog post you know someone felt strongly enough about it to take the trouble to post a message.

  Posted by: nicklothian on February 09, 2004 at 05:26 AM

• Why not eliminate the deployer role?
  It seems to me that THAT is what most of the people want, not "fix EJBs." EJBs are "weakened" by assuming that there's a separate deployer role. Imagine the horror - someone who actually knows how the data servers are managed and tiered, someone who connects the dots - who isn't one of the programmers!

  Bleah.

  Posted by: epesh on February 09, 2004 at 05:53 AM

• random thoughts
  design by blog seems an ok what to proceed as long as there is a head that can recognize and kill the really bad ideas no matter how popular they may be.

  Getting rid of having to write a remote and home interface seems like a win in my books. It's clear that if XDoclet can generate them (as well as the declarative transactional settings), then there is really no business to be forcing programmers to code them.

  I like IoC and I hope that EJB can evolve to include it. One must remember that very few people were looking at byte code manipulations when EJB first came out.

  The rise of XDoclet proves that state and behavior really do belong together and thank you XDoclet for letting us get back to whence we came. As for using it for deployment discriptors... lets be careful before we mutate yet another tool into something hideous.

  Posted by: kcpeppe on February 09, 2004 at 06:38 AM

• Directory standards
  Hi, I'm one of those who posted suggestions at theserverside.com. My main idea included a means to completely eliminate deployment descriptors through the use of a directory layout ("directory based exposion"), but I'm afraid I used a somewhat unfortunate verb when describing that idea (using "is" instead of "becomes").

  So, to re-iterate: my idea was that classes put under, say, $SERVER_HOME/published/stateful *become* stateful just by putting them there - and classes under $SERVER_HOME/published/stateless *become* stateless. After putting your classes there, all you need to do is to open up the access to them by adding one entry per host that is allowed to use them (in, say, $SERVER_HOME/conf/access-control.xml).

  The future development model for distributed objects will then be shortened to:

  1. Code POJO classes that implement business logic in a session bean-like way:

  package somepackage;

  public class SomeService {
  public void doSomething(SomeClass object) {
  ..
  }
  }

  2. If you want the "service" to be stateful, put it under published/stateful/somepackage (otherwise, under published/stateless/somepackage)

  3. As access to published classes is restricted by default, open up access to those hosts that should be allowed to access the service:

  
  somepackage.SomeService
  

  
  4. Done. Go ahead and code the clients.

  Hell, I'm actually thinking of implementing such an appserver for personal use, if noone else likes the idea. One thread that awakes and re-scans the /published dir every 5?10? seconds and sockets/RMI to handle the networking. Plain, simple, light-weight. As it should be.

  - c

  Posted by: carniz on February 09, 2004 at 09:03 AM

• Sigh...
  It seems that callbacks are missing. Yet, they
  are an important features when writing applets
  or starndard apps that communicate with an EJB
  server. Callbacks allow the server to report the
  progress of a long server side call back to the client,
  or to enable other kinds of communication, like the
  one needed for a chat application.

  Posted by: aaime on February 09, 2004 at 09:06 AM

• Can We Make a Difference?
  Thanks for setting up the pole! It's nice to know there is an advocate of the programmers out there on the JSR for EJB 3.0.

  Once a JSR spec goes into public review, do any of us mere mortals have a chance to influence it's outcome? I'm not trying to troll, I honestly am curious.
  

  Posted by: sethladd on February 09, 2004 at 10:28 AM

• Can We Make a Difference?
  You bet. That's purpose of the public review, to see what the developer community thinks. We (the EG) is going to be very interested in your feedback - its the developers we are trying to support and their opinions really matter to us.

  If the developer community hates something we've done, well than we'll go back to the drawing board. If someone has a great idea, we'll see if we can fit into the spec - timelines are sometimes a factor.

  You can make a big difference. In fact, I believe the developers who responded to the original blog already have.
  

  Posted by: monsonhaefel on February 09, 2004 at 11:20 AM

• Please don't ditch CMP
  Please don't "ditch" CMP. Many of us who actually *use* CMP and have made significant investments in CMP are 1) very happy with CMP 2.0 2) would like to see only incremental, backwards-compatible changes that would make CMP just about perfect. There are many little things that could be done to make CMP better such as enhancing EJB-QL and standardizing on a inheritance model. What CMP really needs is polish. This would, I think, make a lot of existing customers very happy.

  As for many of the criticisms against CMP, a lot of them are unfounded. People who complain about the lack of "testability" of DB don't seem to understand that entity beans are just dumb data. Since they contain no business logic there is no need to test them. (Though the session facade that hides the entity beans should be tested.) Also, the "intrusiveness" of entity beans is something which is almost never a problem in reality. Anybody who is reusing components at the entity level has bigger problems. I think it's common sense now that reuse happens at the session bean level. Intrusiveness isn't a problem since entities almost always get abstracted away as an implementation detail. All the client ever sees are value objects which are *gasp* POJOs.

  As for these specific 13 suggestions I think a lot of them are just poorly thought out or will already be addressed by annotation support. 3,8,11,12 are good ideas. 7 doesn't even make sense. How do you "inject dependencies" into a bean which is constantly acquiring and releasing resources? For all the hype, dependency injection simply doesn't work in real life systems where resources are constantly going and leaving. At best, you'd have to add another level of indirection, through proxies, where a bean acquired "handles" to many different and these handles were managed by the component. But even if every external resource dependency was declared through annotated getters and setters, would this code really be any simpler than the service locator pattern? I don't buy the testability argument because (and this brings me to 9) testing EJBs outside of the container is just dumb.

  I'm not sure if EJB 3.0 is meant to be a major change but if it is I hope Sun sticks to its traditionally conservative guns. EJB 2.0 got a lot of things right and EJB is on the right track. As somebody who builds relatively large systems on EJB and enjoys the wonders of reuse through session beans, I'm very satisified with it. What really needs to happen now is polish.

  Posted by: ocean on February 09, 2004 at 11:44 AM

• Can We Make a Difference?
  Thanks for the quick reply. I don't mean to sound skeptical. Thanks for letting the developers have their voice heard. Keep us informed on the progress.

  Thanks again, and good luck!
  

  Posted by: sethladd on February 09, 2004 at 02:26 PM

• Suggestions
  While you have done a very good job of distilling the major suggestions from the TSS debate, and granted most posts were broad ( "Kill EJBs" ... ), I believe you should rather not distill at all at this stage but rather list each and every sensible suggestion and then classify / consider / reject it on merit. Though many concerns with EJB are common, by trying to distill some very good suggestions buried in the long discussions may be overlooked. If the JCP was leaving people discontented, the flaming war on the TSS thread has left a bad taste about the OS stalwarts.
  Good suggestions in response to your call getting lost may discourage people further from making suggestions at all.

  Posted by: sumitkishore on February 09, 2004 at 05:11 PM

• Eliminate deployment descriptors
  Sure, we can do that!

  - We only will have to agree that an application will have to use single connection pool, named, as we're about to agree, "connectionPool". Those who use more than one connector may go hang themselves.
  - Also, who needs references to other EJBs? We'll globally assign names, keeping a global register. Lookups may take longer, but there'll be no need to deal with these confusing deployment descriptors!
  - We'd have to agree that all EJBs deployed in a current instance will have the same transactional attribute, set once and for all in the server instance itself.
  - We will grant access to all EJBs for all clients of the server.

  OR

  we could use directory structures.
  - We'll have the number of top-level directories, as we have the number of databases to connect to.
  - Subdirectories will signify transaction isolation level
  - third-level subdirectories will specify access control...

  
  People, if you come with suggestions like those, your universe is very simple. I for one want nothing of what you ask. POJO persistence? No, thanks, if it requires for three entities instantiated in different contexts (but sharing the same readonly transactional attribute) to borrow three database connections from the pool, shove those POJOs you know where! Can you spell "scalability"?

  I see where it all goes. In addition to local interfaces some in the community would like also to have "NonClusterable", "NonTransferrable", and otherwise "SingleServerDeployableOnly" interfaces. Forget it! This is not improvement you're suggesting.

  Posted by: denka on February 09, 2004 at 10:33 PM

• Why not eliminate the deployer role?
  Brevity is the talent's sister (or something like that). Thank you, you said it better!

  Posted by: denka on February 09, 2004 at 10:36 PM

• Standard Vendor Neutral Way to Referenence EJB's from outside the App Server
  some app servers make it easy to use the JNDI resources such as SessionBean and Entity Beans and even Datasources from plain old stand alone java clients, some make it next to impossible.

  This should be easy to do regardless of vendor. Websphere is a major offender in this light! There is a valid need to run "batch" like processess from outside the server but still use all the valuable workflow and business logic constained in the StatelessSessionBeans from a remote server!

  This really needs to be addressed.

  Posted by: jarrodhroberson on June 05, 2004 at 10:15 AM

• wow power leveling
  wow powerleveling
  wow power leveling
  wow gold
  wow items
  feelingame.com
  wow tips
  Most Valuable WOW Power Leveling Service
  wow power leveling faq
  cheap wow power leveling
  wow power leveling
  wow powerleveling
  wow power lvl

  Posted by: wowleveling11 on December 14, 2007 at 07:27 PM

• 网络营销软件
  网络营销软件
  网络营销软件
  群发软件
  群发软件
  ---
  群发软件
  网络营销软件
  论坛群发软件
  网站排名软件
  群发软件
  推广小助手破解版
  论坛群发软件
  网站排名软件
  群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件
  推荐给你很好的群发软件和信息群发软件和供求群发软件博客群发软件网络营销软件网络营销软件
  网站排名软件网站排名软件网站优化软件信息群发软件信息群发软件信息群发软件论坛群发软件网站推广软件网站推广软件博客群发软件博客群发软件
  群发软件
  网络营销软件
  网站推广软件
  群发软件群发软件博客群发软件论坛群发软件网络营销软件论坛群发软件
  信息群发软件推广软件网站推广软件网络营销软件网站推广软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件群发软件网站排名软件网站推广软件博客群发软件论坛群发软件
  网站排名软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  网站推广软件

  群发软件
  博客群发软件
  网站排名软件
  网站推广软件
  群发软件信息群发软件
  免费论坛群发软件
  论坛群发软件
  网站排名软件
  免费博客群发软件
  博客群发软件
  信息群发软件
  论坛群发软件
  信息群发软件
  博客群发软件
  qq群发软件
  邮件群发软件
  博客群建软件
  企业名录搜索软件
  信息群发软件
  邮件群发软件
  论坛群发软件
  博客群发软件
  网站推广软件
  网络营销软件
  全能营销破解版
  网络营销软件
  论坛群发软件
  论坛群发软件
  论坛群发软件
  网络营销软件
  信息群发软件
  信息群发软件
  信息群发软件
  群发软件
  论坛群发软件
  

  Posted by: sun98989 on December 30, 2007 at 05:48 AM

This work is licensed under a Creative Commons License.