Richard Monson-Haefel's Blog

You can make EJB better

What do you like or dislike about EJB? If it's broke, how should we fix it?

This is an excellent chance for you to make a real difference. All I ask is that you stick to the facts and your own experiences. Please try to avoid flames, zingers, and debates so that I can make the most of your feedback.

Comments

• Problems with EJB...
  The two biggest reasons why people are dropping EJB's are poor performance and overly complex development (lots of config files, interfaces to extend etc). How about taking more of a Hibernate approach - entity beans are normal beans mapped via class reflection?

  Posted by: samnewman on February 01, 2004 at 06:32 AM

• How to make EJB's better
  There are a number of issues currently which make EJB's quite unweildy. I'm not going to mention the usual mantras that everyone trots out whenever there's an EJB's suck thread. Instead I'll answer from the perspective of an EJB user, rather than someone evaluating whether to use EJB's or not.

  One of the biggest holes is the query language. In real life, there are many cases where the QL simply isn't sufficient. There needs to be some allowance for the fact that in reality, EJB's map to databases, and so some form of sql syntax should be supported.

  Secondly, the OR mappings are insufficient in two areas. First, it should be possible to have primitive collections. This requirement comes up far too often, and the current solution of making everything an entity is unweildly and ugly.

  The other deficiency in the OR mapping is the restrictions placed on entities that are to be OR mapped. It should be possible for example to define a mapping between local entities in different modules. Hell, there aren't even strong technical reasons against allowing OR mappings between remote entities. Vendors whining that it's tough for them is NOT good enough. The spec needs more user input and less vendor input.

  Posted by: hani on February 01, 2004 at 11:42 AM

• some small suggestions

  http://www.jroller.com/page/scotartt/20040201#ejb_specification_suggestions

  contains a list of things I think can be improved with EJB generation and packaging.

  Posted by: scotartt on February 01, 2004 at 03:38 PM

• Shaky grounds
  EJB is on shaky grounds. It can be fixed only if it is put on sound theoretical basis, other than that it remains condemend to the ad-hockeries that are well known and documented as example of bad design.

  http://www.c2.com/cgi/wiki?EjbFlaws

  http://www.c2.com/cgi/wiki?EjbTernaryRelationshipExample

  The only reasonable alternative at this point in time is either to deprecate it altogether and start fresh, or possibly hire a real computer scientist to adjust the EJB design either to relational model or to something more "OO friendly" like Higher-order Entity/Relationship Model or Object-Role Modeling.

  Posted by: ccozianu on February 01, 2004 at 04:45 PM

• EJB issues
  While I'm sure there are a lot of areas where the EJB spec could be improved, the most glaring problems I find is with persistence and EJB. Both CMP and BMP are not great solutions to the persistence problem. I think a lightweight approach like that taken by hibernate and to a lesser extent like JDO is a better solution. I think the spec in general would be better if we added support for some newer technologies in the opensource arena such as code generation (like XDoclet) and aspect support (such as we see with AspectJ or JBoss AOP). In general, we need to move EJB in a direction where we are closer to working with simple java objects rather than objects that adhere to strict naming conventions or interfaces.

  Posted by: booleanman on February 01, 2004 at 05:55 PM

• EJB Security
  Security in EJB is too black-and-white and coarse-grained. In my experience, application developers tend to work around it rather than exploit it. Typically, the shortcomings are in authentication and entitlements (access control).

  Authentication: It's not enough to say whether user credentials are valid or not. Special cases such as first-time user, expired password, etc., need to be catered for as well.

  Entitlements: Many developers think that they are following good J2EE practice by controlling access to business logic by defining access rules to EJBs and methods. But real-world business logic applies many more constraints that the declarative logic of EJBs cannot model. E.g., monetary limits on transactions in banking applications.

  EJB should encourage developers to plug in their own frameworks for fine-grained and nuanced authentication and entitlements, rather than give less experienced developers the impression that it is actually sufficient.

  If possible, there should be some standard templates or adapters that provide some default implementations.

  An article I co-authored talks about this, among other issues:
  http://www.onjava.com/pub/a/onjava/2003/09/17/patterns.html

  Thanks and regards,
  Ganesh Prasad

  Posted by: prasadgc on February 01, 2004 at 08:09 PM

• EJB Security
  With regard to the above post, I realise that Authentication is not really an EJB function, but it's something that J2EE containers provide support for.

  The Gatekeeper pattern my co-authors and I describe in http://www.onjava.com/pub/a/onjava/2003/09/17/patterns.html uses an Authentication EJB, but I guess that's not something you'd put in the spec.

  Regards,
  Ganesh Prasad

  Posted by: prasadgc on February 01, 2004 at 08:12 PM

• EJBs are just networking Beans
  I have stayed away from EJBs, not because I cannot code them, but because I did not see added value for them; the complexity always outweight the advantages.

  For me to start using EJBs, they should be nothing more than regular beans being networked.

  In other words, if I have a business model (complete with persistance using JDO) I would like to add a tag to some sourcefiles and have those classes available through their class names.

  Using them should mean changing the "new X()" with an "EJB.new X()". The part of finding a entity bean is totally not interesting, because now I also have an entity manager class with find methods, by making that class "networked" I have implemented all finds I need. And otherwise all I need are the JDO classes networked.

  I understand the complexity and limitations (otherwise I would have coded this myself ;-).
  

  Posted by: tbee on February 01, 2004 at 10:44 PM

• Filter in EJB
  On my opinion it would be useful to have a possibility to manipulate or to observe a request before processing via the EJB. This functionality is already given in the servlet API 2.3 (Filters) for servlets a.s.o. The only one possibility to implement this functionality with EJBs is only possible via using the AOP like AspectJ. In my opinion the container should make this also possible.

  Juraj

  Posted by: nort on February 01, 2004 at 11:01 PM

• keep the good, change the bad and forget about the ugly
  Congrats for this fine initiative !

  IMHO, the good part about EJB is the clusterability of applications. No other java technology does better at this point. So that must stay in the goals of EJB3.0.

  The bad part about EJB is its intrusive nature. Meaning that the ejb-programmer has a lot of restrictions (implement interfaces, ...). Tools like hibernate (for persistence) and light-weight containers show how this can be improved. I would definitely recommend EJB3.0 to go the JBoss way : a set of standard aspects that can be used for enhancing POJO's.

  Another suggestion I would like to make is a new way for components (JMX) and services (session ejbs) and the classpath issues. I have written my ideas down at http://jbpm.org/svc4j It describes how I would design a container :
  * with a standardized folder structure that matches the deployed components
  * a simple standardized class-loading-scheme
  * a common mechanism for components and services. Now JMX beans and ejb-session beans are quite different and have a lot in common. It would be nice if a transaction mgr would be deployed in the same way as an application component. That would make the container a lot more transparant and less like a black box (which has proven itself inadequate).
  If you would like to see more about these ideas, there is 15-class prototype.

  Regards,

  Tom Baeyens
  tom AT jbpm.org
  Independant consultant in J2EE and workflow applications.
  Expertgroup-member of JSR207 "Process Definition for Java".
  

  Posted by: tombaeyens on February 02, 2004 at 01:22 AM

• Making EJB Better
  Make the EJB's ordinary POJOs with a user contract and wrap functionality around the pojos, ala interceptors and Aspects

  Posted by: jexenberger on February 02, 2004 at 01:26 AM

• Service layer
  It would be great if I could extend J2EEserver with my services in standard manner, for example cache, timer. These services would be used by specific business logic (EJB). Services should be registered in register in order all EJBs used same service in cluster. Maybe J2EE server = EJB + Jini???

  Sorry for my English :)

  Posted by: gepard on February 02, 2004 at 05:09 AM

• Auto-increment PK
  A mechanism to have auto-incrementing primary keys for CMP would be helpful.

  Posted by: jackhirasawa on February 02, 2004 at 06:38 AM

• Simplify EJB usage for developers
  Entity beans should be replaced with a JDO or Hibernate type programming model.

  There is no reason developers should be concerned with Home and Remote interfaces in order to persist data - the persistence mechanism should deal with POJOs directly (with metadata annotation perhaps?).

  Entity beans are far too (unnecessarily) complicated - it doesn't have to be this way!

  Posted by: khooke on February 02, 2004 at 07:41 AM

• Home Caching And Security
  Today if you cache home stubs (to prevent lookups again); you lose the ablity to pass security context for each user.So a way should be devised to pass security context once home stubs are cached.

  Posted by: vijpankaj on February 02, 2004 at 10:25 AM

• Auto-increment PK
  Hi,

  Foreing keys mapping problem(s) should also be adressed : deferred tx commit, ...

  Posted by: spetrucci on February 02, 2004 at 10:45 AM

• Better Security
  The current EJB security model of controlling access to methods on classes has never helped me. I've always needed to implement some sort of instance based security model. The spec can help here.

  Also, take a clue from Hibernate. I can write POJOs and have them persisted in an OO way. Entity Beans are trying to model the relational model in the OO world. Plus, it forces me to know I'm writing Entity Beans (through use of interfaces and abstract classes). Hibernate is great because it's non-intrusive and it fits great in a OO model.

  Also, try to preach OO development. Developing EJBs reminds me of writing C. That is, I have a bunch of functions (session beans) and structs (entity beans). When I develop EJBs, I don't get OO benefits like subclasses, state, or behavior all combined. EJB was obviously built from a RPC background. Let's lose that baggage and move to world where I can take a set of OO classes (that is, objects that have state and behavior) and push them into a container, thus gaining things like easy lookups, transactions, and object pools.

  Posted by: sethladd on February 02, 2004 at 10:46 AM

• EJB-QL, Finders, EJB-Select
  Some suggestions for EJB-QL:
  - Allow the use of the "like comparator" with %wildcards and UPPERCASE functions over String attributes and with arguments of the ejbFind. Exemple usage: findUsersByName("SuBsTrIng"); (where the argument is case insensitive).
  - An ejbSelect method could return EntityBeans instead of only attributes.
  - It would be very nice to define a query like "select User, Phone, Company from ..." that could return some form of ResultSet containing all the EJBs found (instead of only one class).
  - Make a way of using a Collection as a parameter to EJB-QL (ejbFind and ejbSelect)
  If you like, you can email me so that I can provide actual examples of what I'm suggesting...

  Posted by: soeiro on February 02, 2004 at 11:31 AM

• Access to the filesystem, threads and RemoteLoca lnterface
  - It would help enourmously if there was a standard way to acess the file system. There are many cases in which a problem would be resolved by creating a file and manipulating it in some ways that are not appropriate or desireable for a database. The EJB container could allocate a directory for the application and allow a controlled acesss to the filesystem.
  - It would help a lot if it were possible to start parallel taks. Put some form of API in EJBs to allow the use of thread-like programming. Today if you really need it, you must try to use MDBs or other more complicated workarounds.
  - There could be a way of defining an RemoteLocal interface and having the J2EE subsystem decide which one is to be used. If the object is only remotely found, use the remote otherwise use the local interface for performance (automatically).

  Posted by: soeiro on February 02, 2004 at 11:42 AM

• Please make a COMPLETE spec this time!
  I read the posts above. I agree with many, but don't think CMP and Entity Beans should be replaced by something else. Honestly, I can't see JDO or Hibernate so easyer and better than CMP.

  Of course they have better query language and OO/Relational mapping, but these are incremental advances that I can't imagine not being on 3.0

  My biggest complain about EJBs is the fact I cannot use them to get WORA. For each container I need to write many specific deployment descriptors. Each container has it's own OO/Relational mapping. It's a mess.

  But XDoclet has shown it's not so hard to have a single "standard descriptor" (javadoc tags) generating all container-specific ones. If EJB 3.0 provided a real, complete OO/Relational mapping descriptor, and a standard way to change JNDI names for EJBs,I could get WORA. Only authentication, which is really a container configuration issue, sould be proprietary. But OO/relational and JNDI names should not container-specific.

  I expected these to be solved on EJB 2.1 but they weren't. I get a feeling EJB specs remain "incomplete" so vendors can tie customers to their app servers. But this is not the reason we all use Java and endorse the JCP. We are part of this community to get WORA, and so far J2EE, better EJB, failed to acomplish that.

  As a minor request, I'd like to see DVCs first-class citzens on Entity EJBs. Today I can declare them but cannot use then on EB-QL queries. That forces me to a "relational", not an OO vision of Entity beans. Why can't I have a field of type Address and query for entities where o.homeAddress.zip = '123456'?

  The same could apply for collection fields (not relationships) and arrays. Something like where o.phone[0] = '1234-5678' or o.phone[HOME_PHONE] = '1234-5678' or '1234-5678' in o.phone

  After all, why should I have to create an EJB just to be able to query on a multi-valuated field?

  This single feature would greatly simplify my Entity EJBs. I really can't uderstand why DVCs where left in such an incomplete, unusefull state on EJB specs.
  

  Posted by: flozano on February 02, 2004 at 03:37 PM

• Singleton, session and application objects, pessimistic concurrency

  
  Singleton support. An Entity Bean with a single instance could be faked into a Singleton but its state replication within a cluster is not supported in this case. We need fast - memory only - singletons with state replication in a cluster.

  The Web spec is so much better suited for application design (in this regard), because it supports the concept of "session" and global "application" objects to which other objects can be attached. Do support these two concepts within the EJB spec!

  We definitely need locking mechanisms to implement pessimistic concurrency behaviour spanning over a user's "think time". The lock must be maintained even when there is no client initiated invocation stack into the EJB container. This cannot be done with the traditional "select for update" under the "connection pooling" paradigm.

  ejbRemove for stateless session beans. Make ejbRemove again mandatory for the container to call as it was in the 1.0 spec. The spec is not to make life easy for container writers but for application writers. The container being written once, applications in the thousands. I understand that ejbActivate() may have to be called before. But one of the few advantages a session bean has over a POJO class is that it serializes automatically in a high volume environment. To "reclaim resources" at passivation time is giving up this advantage. We really had to do much to complex things "on top" of the spec to get along. (The recommendation in the spec is very sketchy.)

  These are just a few bubbling instantly up my mind coming across this page.

  We all like what you are doing. Regards

  Thomas van Husen
  http://www.libra.de
  

  Posted by: vanhusen on February 03, 2004 at 12:37 AM

• Not using them anymore...
  I've spent some time using EJBs, but found them
  to be slow and overly complex.
  I'm now writing apps based solely on hibernate for the data access. If the app is going to be stand-alone, it works nice and I don't need an application server. If I need to build a web interface on top of it, I just get a web container and rewrite the ui, the logic and the data access stays the same, and I can add connection pooling and even clustering if needed.
  Even when the logic should stay on the server side, I find it difficult to justify session beans: its difficult to access to them thru firewalls and there is no callback mechanism. A solution based on SOAP for simple calls works fine, if I need callback I can use some RMI wrapper like cajo, that allows me to stick on fixed ports easily so that remote call and callbacks can pass thru firewall with little configuration.

  Basically, what I need is a solutions that allows me to write the data access and logic once and
  move it easily into stand-alone, web, remote, and
  even wrap it with session beans if needed just by
  rewriting the interface to the outside world.
  Most solutions based on EJB are container dependent (both with a specific brand of container and for the fact that a container, and its overhead, is needed), so they are out of question.

  Just my two cents.

  Posted by: aaime on February 03, 2004 at 01:13 AM

• Not using them anymoe...
  I've spent some time using EJBs, but found them
  to be slow and overly complex.
  I'm now writing apps based solely on hibernate for the data access. If the app is going to be stand-alone, it works nice and I don't need an application server. If I need to build a web interface on top of it, I just get a web container and rewrite the ui, the logic and the data access stays the same, and I can add connection pooling and even clustering if needed.
  Even when the logic should stay on the server side, I find it difficult to justify session beans: its difficult to access to them thru firewalls and there is no callback mechanism. A solution based on SOAP for simple calls works fine, if I need callback I can use some RMI wrapper like cajo, that allows me to stick on fixed ports easily so that remote call and callbacks can pass thru firewall with little configuration.

  Basically, what I need is a solutions that allows me to write the data access and logic once and
  move it easily into stand-alone, web, remote, and
  even wrap it with session beans if needed just by
  rewriting the interface to the outside world.
  Most solutions based on EJB are container dependent (both with a specific brand of container and for the fact that a container, and its overhead, is needed), so they are out of question.

  Just my two cents.

  Posted by: aaime on February 03, 2004 at 01:13 AM

• EJB-QL, Finders, EJB-Select
  Soeiro,

  The parts you are mentioning is actually already available in Borland Enterprise Server. LIKE-clauses, ejbSelect()s that can return ResultSet, Bean instances or Collections and even a way of providing your "user-defined SQL" where EJB-QL is not powerful enough.

  It won't make it easier to port between servers, but there must also be some space for implementers to differentiate themselves. Otherwise, we would only be using the RI for all J2EE applications.

  Posted by: gullet on February 03, 2004 at 01:33 AM

• Lightweight vs intrusive
  I just find EJBs way too intrusive; they distract from clean, simple, even understandable design. I've spent most of the last year working with lightweight frameworks, such as Hibernate, and I wouldn't want to go back in a hurry.

  POJOs have to be the future of enterprise software if we want to avoid getting bogged down in complexity.

  fiddlesticks

  Posted by: fiddlesticks on February 03, 2004 at 01:57 AM

• Improved relationships
  I think what everybody wants is to make the difference between working with a POJO and an EJB to disappear. One of the key places where this difference seems to hinder the beauty of your object oriented design is when dealing with relationships. Having just Collection and Set simply is not good enough. At the very least we need to have standard EJB list relationships and map relationships aswell to avoid the need to think differently when working with EJBs.

  Moreover, support for inheritance is a must. After all EJBs were developed for an object oriented language. If a Person has a relationship with a Car, and two subtypes of Car exist (HydrogeneCar and GasolineCar) it should not require rocket science to write a HydrogeneCarEJB and a GasolineCarEJB and create a single relationship from Person to any kind of car.

  What would really improve the whole EJB concept is if you could in some way easily define new CMR mechanisms yourself, rather than having to rely on the built in ones. In essence meaning, if a Map relationship was not already a part of EJB you could easily define it in some standard way using, for instance XML.

  Posted by: randahl on February 03, 2004 at 05:54 AM

• Improved relationships
  I agree with this. (BTW, WebSphere supports inheritence of EJBs but it should be standardized). Another thought ... I posted previously about the need for auto-incrementing CMP primary keys. But in reality, the EJB (or POJO) object doesn't need a primary key at all, this is required for the underlying relational database. If we could rid the object of the RDBMS coupling we wouldn't need auto-incrementing PK.

  Posted by: jackhirasawa on February 03, 2004 at 06:25 AM

• Enviroment/Configuration parameters!
  Currently it is not possible to set enviroment or configuration parameters per application (ear). You can define them either per EJB or in web.xml but sometimes you want to define parameters for the whole application. A good place would be application.xml.
  

  Posted by: woeye on February 03, 2004 at 08:04 AM

• EJB Security
  I totally agree with this.

  I work on banking application and I need entitlements to be dependant on the bean, the method in the bean, some of the parameters sent to that method (in particular what bank account is involved or what is the amount of the transaction).

  In terms of authentication, expired credentials (either time limit or number of use limit), first time use, password reset et al. are essential.

  What makes it even more difficult is that all the conditions and the logic about authentication and authorisation need to be modifiable through administration screens in the application itself to enable users as much self service as possible, which makes the declarative logic of EJBs based on deployment descriptors too restrictive.
  

  Posted by: brunogirin on February 03, 2004 at 08:45 AM

• Dynamic EJB-QL
  I would like to see the ability to execute dynamically generated EJB-QL statements.

  Posted by: pkorros on February 03, 2004 at 02:23 PM

• EJBs for Highend Applications
  I have been working on huge J2EE based enterprise application. There are few things which limit the enterprise capailities, i feel are

  1. In large enterprise applications we may need to prioritize certain components or business transactions.

  2. Transaction scheduling/Controlling , - especially, control over the thread like , capability to start , stop , and resume a thread of execution etc.

  3. Shared accesspoint such as Application Context in JSP/Servlet

  4. Configuration of cluster wide singleton Bean ( the container should take the responsibility of replicating the configuration across clusters)

  5. Remote Call optimization for intra container calls.

  Posted by: rajeshrv on February 03, 2004 at 09:17 PM

• Lacking component type, implicit context passing, interceptors
  Problems I see with the current EJB model:

  1) Missing component type
  Sometimes one needs long-running behavior, singleton semantics or one needs to violate other restrictions for EJB beans. It is too bad there is no seamless support for such components.

  2) Support for implicit context passing and interceptors
  This is very practical for system agility and to provide some light and safe aspect-oriented programming.
  We added such support in a J2EE framework and use this pratically in every project.

  3) Some design patterns are almost mandatory
  I find it a nuisance that patterns such as Business Delegate, Home Factory or Bean Factory are almost required. It complicates the use of the J2EE.

  4) Potential remote use of a service requires a particular interface
  The mandatory checked RemoteExceptions make it difficult to use a same service interface for a service that is used locally or remotely.

  More details on these (and further points) are in the following EDOC conference paper: http://www.elca.ch/resources/LEAFpaperEDOC2002_final.pdf

  Philipp H. Oser

  Posted by: poser55 on February 04, 2004 at 12:10 AM

• Singleton, session and application objects, pessimistic concurrency
  Concerning Singleton:
  The question is if this is really needed (single point of failure etc). Singletons can usually be avoided. But if really needed, the EB way is cute.

  By the way, many people here seem not to like EBs,
  but these are quite important for caching (eg using BMP and accessing user data from LDAP/EIS
  with a connector).

  The application/session/request(/page) scope
  would be very nice to have. Page scope
  could be like request scope but from the current bean invocation stack position .... if useful. And, if someone can not think of a better way than to use a singleton, it could be stored here in the (application) scope.

  Though the question of synchronization , security, clustering and TX behaviour etc must definetely be discussed first ...

  The Web spec (JSP/Servlets) is not really that good for application design as EJB ... it hardly gives any restrictions (io, threading,...), so it is not really usable for enterprise level/critical applications (thinking of tx/security/resource management/...).

  Just some thoughts ...

  Posted by: speck99 on February 04, 2004 at 02:31 AM

• My new EJB
  Future EJB : If i have a javabean-like pojo, then I can just one click on a button and all my classes are generated by a tool. And this tool is my hand made one. The new spec should facilitate it ;)
  (ejb should be more WORA than now, single deployment descriptor. Isn't that just say that the spec must standardizes more of app nowadays server vendor's specific implementation)

  Posted by: jmonn on February 04, 2004 at 05:05 PM

• Singleton, session and application objects, pessimistic concurrency
  state"full" session beans of course - sorry

  Posted by: vanhusen on February 05, 2004 at 08:22 AM

• Singleton, session and application objects, pessimistic concurrency

  >>The Web spec (JSP/Servlets) is not really that good for application design...
  agreed... but (in this regard) the concept of session and application objects to which other objects may be attached would be helpful to application builders in the ejb layer

  application scope could fully replace the need for singeltons

  agreed that session and application objects would challenge thorny new questions (synchronization, transaction, clustering) but the mechanisms are needed anyway... and the container can much better take care of it as the poor application writer by his blunt weaponsbtw... could not synchronization and transaction aspects be solved the same way as for entity beans?
  
  The misfortune of BMP EBs is that their state replication is so badly supported by containers in clustered environments

  the "ejbRemove()" remark targeted, of course, stateFULL sessionbeans
  

  Posted by: vanhusen on February 05, 2004 at 09:20 AM

• no vendor specific fles for mapping from abstract schema to the base

  
  One of the problems with ejb2.0 (1.1 too) it's that in the jar file we have the vendor specific files.

  To have a endor specific file for mapping from abstract schema to the database it's not a good thing; it would much simpler do develop ejb's with a standardized set of xml files
  
  Thank's

  Posted by: citu_adrian on February 05, 2004 at 12:53 PM

• why are entity beans serializable?
  got nothing personal against any of the emearging/emerged technologies.. also i confess i havent read all of the stuff available on java/j2ee. it has become an ocean out there for a slow reader like me.

  anyways, back to the subject, why should entity beans be implementing serializable? ejbStore is the way to persist these and i havent realized if the beans are ever tranferred over wire? is this to enable code from ejbStore to be able to serialize itself and save it in files maybe? if thats the case, then its an incidental requirement.. maybe a SerializabeEntityBean can be derived from EntityBean for this purpose. But i guess i am missing somthing obvious. Would request a kind soul to help me.

  
  But.... the still more interesting question is: WHY NOT SERIALIZE THE ENTITY BEANS AND SEND THEM OVER THE WIRE! They say all the time that calling methods on entity beans is expensive then why no just send the whole bean at one go? Infact dont we start doing something similar when we create Transfer/Value Objects and send those over the net. Then the client uses the TO (transfer object) to get/set values and then finally send it to the bean on the other side to read values from there and update the bean data. Well this whole paradigm of using TOs defeats the selling point of "pooling" the Entity beans. Because finally we end up using TOs that are not pooled (at least not by a middleware!). So why do we go thru this additional layer of TO and why not just Serialize the Bean and send it to the client? Well a reason can be that lazy loading cant be supported with this. how would it have worked anyways with TO pattern? I guess you'll fetch more TOs from the TO you got in hand and that code to fetch more TOs will use Entity Bean's remote interface... i guess you'll so sth similar.. or there is sth more to it? Well this sounds like a valid justification for not blindly serializing a Bean instance. But NO! I guess we are approaching the actual problem that needs to be solved. The issue was that the a connection (e.g. to a JDBC data source) cant be fetched from the client. well then shouldnt the problem be solved by the Connector Architecture? I think, IMHO, what is needed is to enhance the Connector architecture (already being a critical part of middleware) to reach the "Home" of the "Connection to the DataSource" instead of forcing the whole entity bean to become immobile!?! So, what i am sugegsting is: serialize the bean and alongwith it somehow carry the information of the connections to datasources that it depends on. Now when a method call on a entity bean that was tranfered to a client tries to open a connection or get/set data using a connection it is the connector architecture that locates the Home of that Connection and then redirects the command made on the connection to the home of that connection (maybe the place where the bean was originally created) to mafally execute it. Well proceeding on this line of thought will raise issues like where is a bean created first? Or how is the connection's home detected got the a newly craeted bean? I think these problems are solvable if we focus on the Connector Architecture and using JNDI for lookups. As a side effect, this architecure will give more flexibility for entity bean composition, better distribution of load and cleaner code. All this becasue we solve the problem where it actually is?
  

  Posted by: vsharma4321 on February 06, 2004 at 02:45 AM

• Singleton, session and application objects, pessimistic concurrency
  There are situations when singleton is necessary, for example chat application. You need shared room in memory without slow database. Another example, shared cache with objects which cannot be serialized.

  Sorry for English.

  Posted by: gepard on February 06, 2004 at 05:17 AM

• Packaging of EAR files
  Ok, this doesn't relate to EJB in general but still I would like to bring in this point. What I would like to see is a _defined_ support for packaging support libraries into a EAR. Why not use the following layout:

  ear/
  META-INF/lib/ <- suport libraries which can be seen both by web and EJB modules
  META-INF/classes/ <- same for class files
  webapp.war/
  WEB-INF/lib/ <- support libraries which can be seen only by the webapp module
  WEB-INF/classes/ <- same for class files
  ejb.jar/
  META-INF/lib/ <- support libraries which can be seen only by the ejb module
  META-INF/classes/ <- same for class files

  Though it is possible to define support libraries in the MANIFEST.MF in ear/META-INF it isn't supported by all application servers. Besides it's easier to drop some JAR files into a folder thant keeping MANIFEST.MF up-to-date.

  Posted by: woeye on February 06, 2004 at 07:48 AM

• My wishlist
  I've written at least 7 different EJB systems from scratch and maintained about the same number. Lately I've desserted EJB entirely because I frankly do not believe it adds enough value for the pain you have to go through to create them.

  These are the areas that EJB needs to be approved:
  1. Testability, at the moment there's no standard way of writing (fast-running) unit-tests of an EJB outside the container. It should be possible to just instantiate an EJB without requiring an entire container.
  2. Ease-of-use. It should be possible to write an EJB without using code-generation techniques such as XDoclet or an IDE. The fact that an architecture relies on these work-arounds is a sure smell that something is not entirely right.
  3. Extensibility. EJBs currently offer a limited set of services: security, transactions, persistence, distribution. But there's no way of adding new services in a standard way.

  These are some "action-points" that could remedy some of the problems:
  1. No more deployment descriptors, with the birth of JSR-175 meta-data that should no longer be necessary.
  2. No more intf/impl-separation for local EJBs (the app-server is in control of the class-loader and could use that or deployment time transformations to do bytecode injection).
  3. No more JNDI. Okay, maybe not that drastic, I realize some other specs like JMS, JDBC rely on JNDI but maybe some more easy-to-use lookup mechanism (sorry? did you say "dependency injection"? oh, that'd be an excellent idea!).
  4. No more home-interfaces. The home-interfaces are a pain to maintain or generate but on the other hand I'm not sure how you would do factory/lookup/queries without them. In the case of stateless session-beans (the most useful part of EJB) they are certainly not needed.
  5. Interceptors. This is perfect way of adding extensions and has been explored a whole lot currently in the AOP-community and previously in CORBA. I'm really surprised it's still not in EJB. (I suspect political reasons behind this and not technical.)
  6. Just drop the whole Entity-beans/CMP part, or at least have the decency to replace it with proper OR-mapping (like... JDO?).

  Ok, can't come up with anything more at the moment. ;-)

  Posted by: tirsen on February 07, 2004 at 03:28 AM

• You can make EJB better
  Here's my wishlist:

  I am sure that you have received a number of suggestions to remove Entity beans completely from the specifications. I agree to these suggestions. Entity beans in their current form continue to be heavy weight objects which cause a high performance penalty and have limited object oriented design. An option is to incorporate JDO as a persistence layer and completely remove entity beans. In case complete removal of Entity bean is not possible, an option should be made available to remove features such as security and method level access validation which are rarely used.
  Irrespective of the strategy used for object persistence, there a need to have a standardised method for mapping the object's attribute to the underlying database. Currently this is vendor dependent and making a mockery of portability.
  Provide a standard dynamic object query language that is independent of the entity bean layer similiar to JDO query.
  The best practices of J2EE such as home reference caching, data object usage could be made part of the specifications thus making a vendor neutral best practice implementation possible.
  Currently vendor provide a number of non-standard optimization options. E.g. Option to update the database within a transaction as compared to the normal optimization of updating the database on commit. From a developer's perspective if this is available as a standard, the developer need not worry about the application server implementation.
  

  Posted by: vinraj on February 11, 2004 at 07:34 PM

• must issues.
  my wish list for EJB 3.0 is mostly about Entity Beans ability and strength:

  1) dynamic query , I would like to ejb.execute(STRING EJBQL) exactly the same as I can execute in JDBC.

  2) filetered relationships , the method getRelationship will get a where clause (i.e getEmployees("salary > 10000") )

  3)There should be an EJB reflection mechanism (that will be able to retrieve information from the deployment descriptor) ,for example
  there will be EntityBeanClass that haave the methods: getCMRFileds() ,getCMRMethods() ,getCMPFields() , getCallbacksMethods and much more...
  
  4)Paging shoukld be part of the EJB-ql , select t from test t Page 1 order by o.order , in the deployment descriptor there will be a page parameter
  for how many rows(EJBS) per page...

  5) ORDER BY in EJB-QL should get a parameter (ie select t from test t order by ?1)

  6) EntityBean should be able to automaticly parse HashMap in order to home.create() new bean... (all the cmp fields will be keys in the map)
  and of couse there will be the oppsite method entityBean.getMap() with all the fields already inside...

  Posted by: ohadas on February 15, 2004 at 11:22 PM

• CMP
  I saw in the weblog (http://weblogs.java.net/pub/wlg/997) that most people would like to ditch the CMPs...
  in my opnion if CMPs will have more power ,abilities and flexibility people wouldn't want to ditch it.

  suggest how to improve the CMPs instead of eliminate it

  Posted by: ohadas on February 16, 2004 at 01:13 AM

• EJB
  In my desire for earlier EJB improvements, I hope to see lesser pages of those PDF pages and more of simplicity in coding and deploying the bean.

  I remember when I wrote an app using Servlets. Without even knowing the depths it could let me do something which was fulfilling the needs of 200 people using it.

  Its been more than 6 months that I am struggling withe my beans to get deployed without me sitting for more than an hour.
  

  Posted by: goldylukka on February 17, 2004 at 04:33 AM

• Venter neutral remote invocation
  EJBs are a joke as network services if each vendor is using a different JNDI protocol to obtain their home interface. This absolutely needs to become vender neutral. I should be able to call a remote EJB without knowing or caring what vendor server it is implemented in so our services are accessible to all clients.

  In general, I'd say that the only thing we MUST have is increased vendor neutrality in EJBs in all areas. Supporting multiple vendors is a major decrease in productivity that really makes .NET look appealing.
  

  Posted by: erik777 on March 08, 2004 at 02:55 PM

• Back to what is essential
  I used EJB's since version 1.0 and recently I started with .NET and COM+. As in the CORBA vs. COM wars, if the non Microsoft world does not take into account developer productivity, tool and product pricing and focus on solving real problems most people will go for Microsoft - again.

  What I like very much about EJB:
  - Program to the interface
  - Standardised configurability
  - Services: connection pooling, J2C, JTA, Security
  - Session beans and Message driven beans
  - The container and interception principle.
  - Scalability, fail over.

  What I dislike (very much):
  - (CMP or BMP) Entity beans. Only useful for updates or small read only operations anyway. Seen originally as persitency mechanism independent, now they are useless for almost anything: J2C replaces back-ends, JDO or other are much better for RDBMS, etc. Resource pooling has been taken over by J2C.
  - Generating deployed code is very visible and time consuming
  - Message driven beans only work with JMS (unless that has been fixed in 2.1?). I would like this for any async protocol to work.
  - Why is bean pooling necessary? It confuses lots of people. I do no longer believe it is useful since resource pooling is in the DataSource or J2C.

  Why not concentrate on the essential? To my opinion the essentials are:
  - J2EE services (JTA, Security, J2C, ...).
  - Programming to the interface.
  - The interception mechanism (container managed and descriptive services).

  An EJB describes what services it needs, what interception 'filters' are used, and a facade interface.
  We have Session beans for sync operations, MDB for async operations.
  And EJBs should be much more lightweight.

  I feel this is what COM+/.NET tries to achieve, and much bettern than EJB now. Still, J2EE can do better since COM+ includes everything (also libraries, visual components etc.), where EJB has made a good choice by only concentrating on the business.

  Posted by: dvaneynde on March 29, 2004 at 04:58 AM

• A single business interface instead of remote/local
  When I'm writing my beans I 'd like to define only a single business interface that has nothing to do with the way the component gets called (remote/local). This business interface would contain methods that implement the bean's business logic. I hate the schizophrenia related to remote and local interfaces. Why should I care in my source code, whether the bean is going to be called locally or remotelly? Why should I care about RemoteExceptions in my business interface. Methods in my business interface should throw only exceptions related to the business logic (checked exceptions) or exceptions that signal system errors (runtime exceptions). The fact that the component is local or remote or both should be specified outside the source code (perhaps in the deployment descriptor). I think that the way we have to define business interfaces with EJB 2.0 is a big design flaw of the specification.

  Posted by: mpalicka on April 05, 2004 at 10:58 PM

• J2EE design patterns
  If you are thinking about improvements of the EJB specification, then you can find plenty of ideas in J2EE design patterns. Many of these "patterns" are just attempts to fix problems and flaws of the technology (specification).

  Posted by: mpalicka on April 05, 2004 at 11:04 PM

• Back to what is essential
  >>- Message driven beans only work with
  >> JMS (unless that has been fixed in 2.1?).

  this is already supported in the 2.1 spec

  Posted by: giovanisalvador on April 06, 2004 at 01:33 PM

• EJB QL
  I think EJB 3.0 must improve the funcionalities for EJB QL. For example, to compare dates and times we need to use time in miliseconds. It could exist some comparison baed on objects like Calendar.after....
  That´s a simple example, i think ejb ql must be better. SQL is the limit :)
  

  Posted by: giovanisalvador on April 13, 2004 at 10:14 AM

• batch applications
  I really do not know if this is important :)
  but when a j2ee application needs to make job procedures, it stays away from ejb. Could you imagine inserting 250,000 records and instancing 250,000 entity beans in the container´s memory? Is there a plan to solve things like this? For example, to mark a cmp entity that it must persist the data but not stay in memory for some client? Is this madness? :)
  

  Posted by: giovanisalvador on April 13, 2004 at 12:19 PM

• EJB 3.0 Spec
  Hello!

  Before making any comments and to avoid duplicate
  submissions, would it be possible to review what was
  already proposed and what did make to the spec?

  Many thanks!

  Posted by: jbin on June 21, 2004 at 08:51 AM

• it can be a simple thing to use EJB.
  We have just finished a project using EJB.
  This project is based on a framework provided by SUN in Japan.
  This framework integrates such technologies and design patterns as ANT,XDoclet,reflect,proxy,facade and so on.
  It is something like struts and based on struts.
  The structure of this framework is showed in the following figure.

  jsp jsp
  | |
  | |
  ________|_________ |
  | | | |
  | struts | |
  | | | |
  | ServiceAction | ActionServlet
  | | | |
  | SessionBeanProxy | |
  |________|_________| |
  | |
  | |
  Session Bean Action
  | |
  | |
  VO/CMP/Hibernate model....

  
  With the help of ANT and XDoclet and a tool I developed, most programers need not know what is JNDI,what is EJB interface, what is ejb-jar.xml,even what is EJB.Now I understand why there are so many people liking EJB.

  Posted by: hiit on July 01, 2004 at 06:05 AM

• batch applications
  I am very interested in guidelines or design patterns regarding the development of J2EE services to be used by both batch and on-line clients.

  How to architect the packages, how to share core functionality , and how to expose the service for both interactive and batch applications.

  Thanks

  Posted by: cmanjarr on July 27, 2004 at 08:36 AM

• Venter neutral remote invocation
  What an interesting concept because EJB are not completely vendor neutral (and this is a bad thing) we should go completely vendor specific?.

  What I would like to see in EJBs are a mechanism to obtain faster bulk data access.
  DTOs should be a standard access mechanism and you should be able to add a finder which instead of returning a collection of EJBs it returns a collection of possibly imutable DTOs without instantiating EJBs for each DTO to give fast read only access.

  This should be further extended to allow bulk database inserts by having a create method on the home interface that takes a collection of DTOs to ceate many database etries at a time without the overhead of creating many EJBs when they may not be needed at this time, similarly an update method on the home inteface could take a collection of DTOs and where the key contained in the DTO already exists then the coresponding database entry will be updated. (What you do when the given key does not match an existing entry I dont much care - it coudl do an insert or it coudl do nthing or it could raise an exception - it just must be specified)

  The readonly bulk data access is the most important, I have seen many situations where tables of data are displayed or read from the database for some external processing where subsequent database update is likely only for a small but possibly ill defined subset and the most important action is to efficienty get a large bulk of data accross to the client.

  Posted by: philiprobinson on August 16, 2004 at 07:00 PM

• DTO Bulk transfer
  Need to improve efficiency of bulk data transfer. we need to be able to generate Data Transfer Objects (DTOs) as all fields in an EJB or any specified subset of the fields in an EJB (see XDoclet) it should then be possible to specify finders to return

  EJB references (when many updates are likely or where the number of updates are similar to the number of data detail reads)
  A specified DTO for ead only (or read mostly data).

  DTOs should be imutable but give simple access to the coreponding EJB for when update is required or full data reads where the original DTO only contains a subset of the EJB to which it relates.

  Posted by: philiprobinson on August 16, 2004 at 07:26 PM

• Primary key auto geberation
  Often I dont care about the primary key, I don't want to generate it or tink about it. EJB creation should just take care of it - perhaps I want to specify the field name.

  Posted by: philiprobinson on August 17, 2004 at 02:30 AM

• You may have a look at the following discussion regarding "EJB or Not-to-EJB", where a developer is annoyed with some staffs of EJB.

  http://jpgroup.blog-city.com/read/888490.htm

  -- Ashik

  Posted by: ashikuzzaman on January 11, 2005 at 09:05 PM

• query limit! I hope that it is not too late to contribute. I think it would be extremely advantageous to be able to be able to limit the number of rows returned in a query. If you could choose the position (row number) that it starts and ends at that would be even better. This is something that I have always needed in my applications, when handling a large amount of data this always hounds me. I think that including this feature would be a great leap forward.

  Posted by: mrswadge on April 15, 2005 at 02:30 AM

• I read the EJB 3 public spec, and it is very good. But pagination is not dealt with, please create Annotations to inform pagination properties.
  This solution has several advantages, and 1 big problem:
  - one can annotate anything with pagination information (usually it will be lists)
  - no weird Page object to wrap query results
  - NO CURRENT suport for acessing annotations in JSP, Velocity, Freemarker, anything else that you can think (OGNL, BeanShell...)
  I believe the problem will be corrected, so there is my sugestion (later I will have more:-)

  Posted by: levmatta on June 30, 2005 at 02:32 PM

• A simple solution/alternative to entity ejbs:

  Create an “entity manager” session bean for each coarse-grained entity.
  Implement the entity as serializable not ejb.
  Implement the “entity manager” session bean to handle persistence of the entity and transaction processing involved in the persistence.
  This eliminates the need for transfer objects and the problems with transfer objects: redundancy, separation of behavior and state.
  This maintains the benefits of ejb: distribution of services/scalability, locating remote services via home interfaces and transactional processing

  Another benefit is that functionality and distribution concerns can be separated.
  Distribution can be turned on and off with a switch.
  Access to “entity manager” instances is encapsulated in static methods on the “entity manager” class.
  The “entity manager” class (factory) can determine if distribution is on or off.
  If distribution is on a remote “entity manager” instance is returned. If distribution is off, a local “entity manager” instance is returned. Whether the “entity manager” is remote or not is transparent to the client. The client can then access the entity via the “entity manager” (local or remote)

  The development team can focus on the functionality of the system independent of distribution concerns.
  Upon stabilizing the functionality, distribution can be turned on and the development team can focus on distribution concerns.

  Having a distribution switch is not necessary. However, separating the concerns of persistence and transaction processing from the entity to the “entity manager” creates a more robust and understandable architecture. For example, the system could be developed not to be distributed. Later, distribution could be added by simply modifying the entity managers. The impact on the overall system would be minimal.
  

  Posted by: wade0t on July 04, 2005 at 08:57 AM

• wow gold
  wow gold
  wow gold
  wow powerleveling
  wow powerleveling
  wow power leveling
  wow powerleveling
  wow power leveling
  翻译公司
  性病
  性病
  尖锐湿疣
  尖锐湿疣
  wow power leveling
  wow powerleveling

  wow power leveling
  wow powerleveling
  wow power leveling
  powerleveling
  power leveling
  powerleveling
  power leveling
  power leveling
  powerleveling
  wow powerleveling
  

  Posted by: sunwicce on November 18, 2007 at 08:53 PM

• 
  wow power leveling
  wow powerleveling
  world of warcraft power leveling
  wow powerleveln
  wow power leveln
  world of warcraft power leveln
  world of warcraft powerleveln
  ffxi power leveling
  coh power leveling
  cov powerleveling

  wow power leveling
  wow powerleveling
  world of warcraft power leveling
  ffxi power leveling
  ffxi powerleveling
  lotro powerleveling
  lotro power leveling
  wow gold
  world of warcraft gold

  wow power leveling
  wow powerleveling
  world of warcraft power leveling
  ffxi power leveling
  ffxi powerleveling
  ffxi
  ffxi gil
  lotro powerleveling
  lotro power leveling
  lotro gold

  Posted by: bibiy34 on November 27, 2007 at 03:09 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: wowleveling3 on December 13, 2007 at 09:48 PM

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

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

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

This work is licensed under a Creative Commons License.