Discussions

News: SQL Entity EJB Wrapper to Simplify EJB Development

  1. IBM has an article which shares a design pattern that generalizes the use of entity EJBs to simplify EJB development. It involves having a generic SQL EJB Wrapper which has Select(), SelectForUpdate(), Insert(), Delete(), and Update() methods.

    The design pattern retains the intuitive SQL interface, yet delivers the reusability and built-in distributed transaction support of EJBs. Many common cases can be handled. Because it is generalized, it can be used for automatic code generation. Given a database table, the bottom-up approach can generate code from Container-Managed Persistence (CMP) entity beans, session beans, up to a Java Server Page (JSP) or even a Web service.

    Read: Using a Generic SQL Entity EJB Wrapper to Simplify EJB Development

    What do you think about this pattern? Are people doing these kinds of things with Entity beans? Do we want to use simple CRUD interfaces like this?

    Threaded Messages (38)

  2. EJB gone mad?[ Go to top ]

    So we've gone full circle. Why is this approach any better than banging straight SQL to the DB? If you think I'm trolling, think about it this way: what is the container doing for you except exposing the 4 CRUD operation on top a bloated API? Think about it.
  3. EJB gone mad?[ Go to top ]

    I have to admit that I don't see the point either. You end up with a client application with tons of unmaintainable SQL pseudo-code. As I see it, the whole point of EJB is to push you SQL logic down into a single layer where it can be managed centrally.

    If your client developers are in the habit of writing all the SQL themselves, then you need to break them of the habit and provide them type-safe OO access to the database, not build some weird pseudo-SQL layer over your EJBs.
  4. Now this is a good argument...[ Go to top ]

    Keep the EJBs, but provide an interface to a well known domain concept.

    User - getName(), setName(), addRole(), createWrittenWork(), etc.

    Not c.r.u.d. That should be hidden from the client.

    John C. Dale
    Down in the Desert, Inc.
  5. EJB gone mad?[ Go to top ]

    I totally agree with you. Why would you bother using a whole CMP layer if you are just going to convert everything back to a relational type interface? Is these a design for people who can't be bothered to learn SQL?

    Also as a side note I would suggest this person buys a good OO book and learns it.
  6. Please take the time to read the article and study the diagrams a bit more. I think there are some valid points you, Paul, and David missed here:

    1) How the client interacts with the business tier doesn't change one bit. All client-business tier interactions are through Session EJBs (current best practice).

    2) This new layer is really for simplifying the interaction between a session bean and the one or more entity beans it depends upon. If you look at the Session EJB code, you'll see that the EJB Wrapper helper object reduces the amount of hand-written code, as well as making it easier to follow.

    3) The "bloated (J2EE) API" is still required to handle security and transactions as opposed to having to do it yourself by "banging straight SQL to the DB". None of that changes with this pattern.

    Since we have local interfaces for our Entity EJB's the best practice has been changing to have one EJB per relational table. For the most part the functions required on each EJB are pretty much the same, which lends itself to code generation. If, as the article asserts, we can genernate the Entity EJB's and the EJB wrapper, then the hand-coded business logic (in the session beans) becomes much simpler to implement.
  7. RE: EJB gone mad? - Not really[ Go to top ]

    It all comes down whether its worth using entity beans. If you have a session bean that is benifiting from transaction and security services and its using a business domain that implements database access through the DAO pattern or some O/R mapping framework, then this is not necessary (i think).
  8. as a victim of 1) its complexity and 2) its non-scalability.

    Read the Blueprint and start playing with EJBs. When applied correctly, they are KILLER.

    John C. Dale
    Down in the Desert, Inc.
  9. RE: EJB gone mad? - Not really[ Go to top ]

    The reason I am trying to get at here is why is the design using Entity Beans?

    George here are my direct answers to your points.

    (1) Implementing a facade layer is generally good practice. The amount of busines logic you place in this layer is debatable. I am not sure why you think I missed this point.

    (ii) The issue here is once again people are simply using Entity Beans as glorified Data Access Objects. This design even goes further by mapping a relational CRUD interface on top of them. So is the only reason of using Entity Beans in this design that my IDE can pump out the code. Not a good reason in my opinion.

    (iii) One of the reasons to have a Facade layer is to organize Security and Transactions. I don't think anyone who say banging SQL into the database would work for this. Also I am not sure why you think I missed this point.

    David
  10. RE: EJB gone mad? - Not really[ Go to top ]

    I believe Laurent Fontanel missed the point of the article and the first line of your response to his message was "I totally agree with you". That is why I say you missed the point. Guilty by association? :-)

    He asks "what is the container doing for you except exposing the 4 CRUD operation on top a bloated API" and I answered transaction and security.

    Then Paul Strack says you, "end up with a client application with tons of unmaintainable SQL pseudo-code". I said this misses the point because none of the changes the author talks about ends up affecting the client at all.

    I say you missed the point because it was obvious that you only skimmed parts of the article. Even suggesting that "this person buys a good OO book and learns it" shows me that you are more interested in being a nay-sayer than reading the article to see if any of it could apply to a current or future project. If that is true, you miss the whole point of this website (idea sharing), much less this one article.

    The article was not debating the merits of Entity EJBs versus other persistance mechanisms. It was about creating a EJB Wrapper around one-to-one Entity beans to make the business code in the Session beans clearer.

    The article specifically talks about using a bottom-up approach to development. This usually means that the database tables already exist and that you are trying to create J2EE code to access it. One solution, which works well on a lot of projects, is to map the relational tables one for one to an EJB. Perfect in all cases? No. But the author is not trying to claim that.

    Because of this approach, the data needs to be tied together inside the session bean. To make this easier, the author came up with a wrapper that handles a lot of the common code you'd use for working with Entity beans (home lookup, create, etc...). Since the author is choosing to put his business logic in Session beans, it makes sense to keep those methods as short and clear as possible.

    This is not specific to you but overall I am bothered by the ton of instant negative feedback that occurs on this site. Lambasting an author's choice of technology or methods without evidence of any real critical thought about the new ideas presented in their article is just self-serving, shallow, and boring.
  11. RE: EJB gone mad? - Not really[ Go to top ]

    I am sorry you feel that way about me George. I do tend to come of strong sometimes and I have been involved a lot in debates recently about the whole "What are Entity Beans meant to be used for?" discussion.

    "The article was not debating the merits of Entity EJBs versus other persistance mechanisms. It was about creating a EJB Wrapper around one-to-one Entity beans to make the business code in the Session beans clearer."

    IMHO you can not expect to write an article which uses a very specific architecture approach to demonstrate a pattern without people getting into if they feel the whole approach is valid. Yes in the writers architectural approach the pattern has merits but if you do not agree with the architecture the article is based on are you just meant to be silent? If you are silent do junior people not get the idea that everyone thinks this general approach is gospel?

    Peace
  12. RE: EJB gone mad? - Not really[ Go to top ]

    <quote>
    Then Paul Strack says you, "end up with a client application with tons of unmaintainable SQL pseudo-code". I said this misses the point because none of the changes the author talks about ends up affecting the client at all.
    </quote>

    OK. I will conced that the article does advocate only use the SQL Wrappers in the Session bean layer. But I feel that my argument still stands. You just end up with a bundle of unmaintainable SQL pseudo-code in your Session EJBs instead.

    My real objection to the pattern is that your are putting a non-type safe layer on top of a type-safe Entity EJB, with no obvious benefits (at least, not obvious to me).

    IMHO, the main advantage of EJB (and Object-to-Relational Mappings in general) is that you replace non-typed SQL strings with type-safe object wrappers. If you misspell a field name in your SQL logic, replacing "NAME" with "NANE", the Java compiler will ignore your error, and you won't recognize your problem until run time. However, if you misspell "setName()" as "setNane()" in calls to your Entity bean, the Java compiler will catch it immediately.

    More significantly, if your field name changes from "NAME" to "CUSTOMER_NAME" for some reason, all of your pseudo-SQL becomes invalid. You run into the same problem with your Entity EJB, but again, the compiler catches this problem.

    I *do* see some advantages to putting a Wrapper layer between your Session and Entity EJB to simplify development. I just think that an SQL abstraction layer is the wrong choice. If you are going to do code generation anyway, which not generate type-safe POJO wrappers use those in your Session EJB? Something like this:


    Session -> POJO Wrapper -> Entity


    // In your session bean
    AccountData account = AccountData.findAccount(id);
    account.setName(name);
    account.setBalance(balance);
    // Calls propogate to corresponding Entity bean
  13. RE: EJB gone mad? - Not really[ Go to top ]

    PS

    "Since we have local interfaces for our Entity EJB's the best practice has been changing to have one EJB per relational table. For the most part the functions required on each EJB are pretty much the same, which lends itself to code generation."

    Firmly disagree here. The reason we map one Entity Bean to one database table is that generally that is all most containers support so if you did CMP you were stuck with it. Weblogic now supports multi table mappings and there are a lot of good Object to Relational mappings tools out there.
  14. The ability to normalize data...[ Go to top ]

    and transform it in the Container's caching facility (the EJB container) is paramount. If you go one EJB per table, you're dead.

    John C. Dale
    Down in the Desert, Inc.
  15. RE: EJB gone mad? - Not really[ Go to top ]

    Since we have local interfaces for our Entity EJB's the best practice has been changing to have one EJB per relational table. For the most part the functions required on each EJB are pretty much the same, which lends itself to code generation. If, as the article asserts, we can genernate the Entity EJB's and the EJB wrapper, then the hand-coded business logic (in the session beans) becomes much simpler to implement.

    It makes sense to add this in a future specification of EJB.
  16. RE: EJB gone mad? - Not really[ Go to top ]

    Why does it make sense?

    It is only best practice to have your entity beans map directly to the database tables if you have a simple domain model and your relational database structure maps pretty closely to your object oriented domain model. People do the one entity bean per table approach because up to recently most containers supported no other option.

    It makes more sense to try and fix the mess that is the Entity bean specification and support multi-table mappings and inheritence structures. Otherwise I would suggest using an O/R tool to support your mapping requirements.

    Adding such stuff to the spec is moving backwards.
  17. Since we have local interfaces for our Entity EJB's the best practice has been changing to have one EJB per relational table. For the most part the functions required on each EJB are pretty much the same, which lends itself to code generation. If, as the article asserts, we can genernate the Entity EJB's and the EJB wrapper, then the hand-coded business logic (in the session beans) becomes much simpler to implement.

    >
    > It makes sense to add this in a future specification of EJB.

    As I understand programming language is designed for programmers, not for code generation tools. If I need to autogenerate source code, I know it is something wrong with my design. I am not a very big EJB fan, I think "code generation" is overused idea with EJB "For the most part the functions required on each EJB are pretty much the same" external XML files looks like a maintainence problem for me too. I like transaction and authorization management in EJB, but looks like persistence is not the best part of this technology. The most of developers trust everything from j2ee and this stuff is overused, is not it ?
    I am trieng to find a better ways myself, it looks like this:

    <pre>
    public interface UserManager {
        /**
         *@update INSERT INTO _USER_ (username,password)VALUES( $1.id, $1.password )
         */
        public void addUser(User bean);
        
      }
    </pre>

    I think data access code doe's not need code generation and external files, does it ? I prefer testable out of box code too.
  18. RE: EJB gone mad? - Not really[ Go to top ]

    It makes sense to add this in a future specification of EJB.

    Oops, I mispoke. I didn't mean to say that IBM's wrapper is worthy. The wrapper is claimed to reduce a session bean's hand code slightly. I like this since most of EJB's hand code is session procedures. IBM is implying that the local interface of an entity bean has suboptimal ergonomics. This could be remedied directly in the EJB specification. The spirit of IBM's proposal is good.
  19. OK, I'll bite...[ Go to top ]

    You'll get the throughput of middle tier caching. Your EJBs are supposed to be a distilation of RDBMS data, the result of which is a refined view of the data that took some resources/time to produce. The idea is that you give this some unique identity, then cache it in a container via that identity, thus obviating the need to go and reread the data. Furthermore, something the EJB paradigm forces you to do is decompose the problem into components. Low Coupling and High Cohesion should be the result. When it comes time to refactor and adapt your application while maintaining the interface, you'll be thankful for this approach.

    So, straight out of the blueprints (which you probably didn't bother to read), the three primary reasons for using EJB are:

    Declarative Configuration.
    Throughput due to 'intelligent' middle-tier caching.
    Reuse through high Cohesion and appropriate decomposition of the problem.

    Hope this helps.

    John C. Dale
    Down in the Desert, Inc.
  20. The rise of the anti-patterns! We need more levels of indirection? A R/O/R mapper it you will. The source of the anti-pattern is denying all other solutions in order to promote EJB CMP and indirectly app server licenses.

    This may be relevant. I recently went to a talk by John Crupi who is one of the authors of "Core J2EE Patterns." A fundamental trend I came away with was the demand for more levels of web-tier indirection to support web services and traditional MVC. Astonding were the new patterns on the app/integration tier that add *more* indirection to distance architectures from the EJB container. The 2nd edition proposes a "pattern" that would standardize an access strategy to wrap CMP, JDO, DAO, or O/R mappers. While it shows a lot of thought it's really an anti-pattern. He also presented the "Business Object" pattern which could be implemented by a session bean or, yes, even a POJO.

    My take was that it seems even Sun is distancing itself from EJB while saving face. Look smart with a Sun pattern so you don't look stupid choosing not to go with entity beans. It seems Sun's work with EBay prompted some thought about an entity bean-less world. Some truly bad mojo for app server vendors and good news for the likes to Tomcat.

    The authors also worked closely with Martin Fowler so that that they could all standardize terms.
  21. Oh please...[ Go to top ]

    are you for real?

    "Trying to distance itself from EJB?"

    If you take a closer look, EBay really just reproduced an EJB-like caching tier and spend gobs and gobs on their database tier, probably because they were afraid of the current EJB implementations (which, by my own admission, were pretty bad just 2-3 short years ago).

    So tell me, if there is no need for a middle-tier normalization cache and component reuse model (basically EJB), why did they build one?

    John C. Dale
    Down in the Desert, Inc.
  22. Oh please...[ Go to top ]

    ..."(basically EJB)" but not. Well, it's 2-3 years later and you mean to tell me that the only viable solution is EJB? There is more than one way to persist to a database. And don't forget databases have caching strategies too. Yeah, I read Core J2EE Patterns and thought it was great when it came out. The new book (online) is pushing it a bit although I appreciate how it reacts and addresses to new trends.

    It sounds like there is no scenario where EJB is inappropriate to some. Short sighted.
  23. I can't say that I knew EBay was not using EJB's but we made the decision to abandon them about 6 months ago. We couldn't be happier with the results. We're running straight POJO's for our business logic with DAO for data access. All of it runs on top of Resin.

    It is truly a beautiful thing, getting rid of EJB's that is. Development and deployment are vastly simplified. We can use more OO type application architetectures. We wrote thin layers for security and transaction managment and they work great for us. It wasn't difficult at all. When you make the switch and see how much nicer the dev cycle is without EJB's you realize that you don't need all that extra cruft that comes along with them.

    I think I'd rather work on a .Net project before using EJB's again.
  24. "I think I'd rather work on a .Net project before using EJB's again."


    Wow, Microsoft has your number, look folks just because you don't know the ways and means of EJB - doesn't make EJB a bad thing.

    You mentioned .NET, why? If .NET provides you with solutions that satisfy your requirements then "make it so".

    Please, .NET is an implementation, which works only on Windows - J2EE is a specification, which works everywhere. Stop comparing apples and oranges and just apply the best technology for your business needs.

    My take on why so many people are bitter with EJB is because it does not offer a point-n-click solution. With J2EE you have to think about architecture and this is where the problem lies. I've worked with many developers throughout my career and only a tiny fraction could conceptualize some sort of design before hacking away.

    I wonder how many developers working on large scale "distributed" software projects before J2EE, find J2EE complex?

    I wonder how many Unix developers writing their own custom transaction engines find J2EE complex as well?

    I'm assuming the 2 above scenarios are projects based on domain objects, not embedded 4GLs inside databases...
  25. "J2EE is a specification, which works everywhere"

    "My take on why so many people are bitter with EJB is because it does not offer a point-n-click solution. With J2EE you have to think about architecture and this is where the problem lies."

    Paradoxically, the specificationness of J2EE is what's holding it back. Why don't we have point-and-click solutions for EJB-like solutions? Why don't we have a better solution than entity beans? Why is web development so messy?
    We are forever bombarded with the aplhabet soup of junk -- "All you need is Tomcat, JBoss, Struts, Ant, XDoclet, Maven, Ford, GE, DVD, LMNOP, etc."

    The vendors are trapped by the specs - they can't really distinguish themselves with proprietary technology.

    Even Sun, in my opinion, has hurt itself more than helped with J2EE. Had they come up with a jam-up development environment (based on Java, or C++, or VB, or whatever) they could have distinguished themselves from competitors.
    As it is the technology moves at a glacierly pace.........yawn
  26. "I think I'd rather work on a .Net project before using EJB's again."

    > I wonder how many developers working on large scale "distributed" software projects before J2EE, find J2EE complex?
    >
    I have worked with DCOM before to use J2EE, it was not a very large scale "distributed" software, but client software was "integrated" with server software running on UX later. It is possible to use some bridge implementation and to integrate DCOM with CORBA, but proxy server + plain socket was used for this integration :) I do not think j2ee is mutch simple for development, but it is mutch more simple for maintainence. As I see the most of .NET/DCOM developers love mouse, but .NET is nothing more than experiments + JAVA clone without mouse at this time, is not it ? JAVA is not a religion for me, but I have saw a lot of worse stuff before to use it.
  27. My take on why so many people are bitter with EJB is because it does not offer a point-n-click solution. With J2EE you have to think about architecture and this is where the problem lies. I've worked with many developers throughout my career and only a tiny fraction could conceptualize some sort of design before hacking away.

    >
    > I wonder how many developers working on large scale "distributed" software projects before J2EE, find J2EE complex?

    J2EE is a complicated solution for the complex problem of distributed computing, persistence and transactions.

    But it's this complexity which is a major productivity bottleneck for development teams, regardless of whether they have done large-scale distributed software programming before. And the Tools don't take take away the complexity - they just hide it.

    Another problem is that the complexity of the J2EE solution puts it beyond the reach of small and medium businesses. Which is why they have traditionally been Microsoft shops, and will flock to .NET in droves.

    I think it will be beneficial to everyone if J2EE sheds some of it's complexity.
  28. cross-network DB navigation[ Go to top ]

    What bothers me about the IBM proposal and other O/R mappings that match one table per class is that they foist DB navigation off on the class layer. Even worse, they imposes a round-trip delay for every row fetched from the database. If your app includes many-to-one relations, this is a performance killer.
  29. Comments[ Go to top ]

    This article is a suggestion of one or two individual within IBM and not a general proposal or direction that IBM is proposing to follow.
  30. cross-network DB navigation[ Go to top ]

    "Even worse, they imposes a round-trip delay for every row fetched from the database. If your app includes many-to-one relations, this is a performance killer."
    Actually, this is where the power of CMP EJB comes in. WebSphere can be configured to fetch data and instantiates EJBs in blocks, rather than one at a time. For groups of EJBs with container-managed relationships, it can even be configured to get the data for an EJB instance, and all (or some) of its related instances ( you can go N levels deep) with a single SQL query, and then cache the data so that related EJBs can be instantiated very quickly. Since there are times when you don't want to extra data read (if the related EJBs are not frequently navigated to) the rules for when the container does a "read ahead" can be configured on an application-by-application basis.
    Another thread commented about the limitations of EJB QL. WebSphere goes significantly beyond the spec to allow things like ordering/sorting of result sets, dynamic queries, method calls in a query, and aggregate functions in a query.
    These features are just a few examples of the CMP optimizations that collectively add up to higher performance, reduced DB overhead, and more deployment flexibility for EJB applications.
    I work for IBM, so I am only discussing WebSphere, but all the popular EJB servers offer advanced features for tuning the EJB container, and the competition has lead to better EJB performance, and more configurability for all the major servers.
    Clearly there are times when EJBs (or entity EJBs) are not needed, and/or not appropriate for an application. EJB 1.0 and 1.1 had significant and well-known limitations. EJB 2.0 is a new game however. It really opens the door for vendors to implement all kinds of optimizations for CMP. It would be a mistake not to at least consider the use of EJBs when architecting new applications.

    Tom
    "I work for IBM but the opinions are my own"
  31. IBM? common man[ Go to top ]

    Hey, your Websphere app doesn't even support JDK 1.4 and thus denying us all the garbage collector performance enjancements.
    We don't even know, when IBM will come up with support for JDK 1.4, J2EE 1.4 features, etc.
    Just having pretty looking wizards in WSAD for CMP code generation is not going to help...going with Tomcat instead sounds like a better option.
  32. Can your work be done with simple MVC pattern. ?
    Can you stop at session beans ?
    Do you really really need Entity beans ?
    Can you / your team handle the EJB project and maintain it in future ?

    I have never got convinced as to why people use Entity beans ? Its soooo restrictive. Anyway thats not the whole point of this article. So i do understand to some extent the "simplicity " tried to be addressed in this article, but I have to agree with some people here that its kind of a full circle to where we started.
      Happy coding !!
  33. Really, how this approach is better than using a good object-relational framework, like Hibernate?

    In my EJB projects, I use Hibernate for persistence behind a Session Facade. I used CMPs before Hibernate, and found it inflexible (no autogenerated primary keys, no dynamic EJB queries, EJB QL is too simple) and hard to develop and maintain. The only tool for CMPs/BMPs I like is JBuilder 7 Enterprise (or newer), but it's so expensive. Hibernate has no similar tools, but IMHO development for Hibernate is much simpler and more maintainable.

    Sincerely,
    Sergei Batiuk.
  34. Hi all,

    I have a very general question. I am wondering in what cases (like certain functional or non-functional requirements) one should use a Persistentcy layer like Entity beans, Hibernate or JDO within the application. I sort of figured out when to use Entity beans (or most of the time when not to use them :) ) but I´m curious at the concept of Persistency as part of your application ...when should you use it?? and when should you rely on a DB and DAO and stateless session beans? what do you guys think of this?

    Regards
    Wouter
  35. Hi all,

    >
    > I have a very general question. I am wondering in what cases (like certain functional or non-functional requirements) one should use a Persistentcy layer like Entity beans, Hibernate or JDO within the application. I sort of figured out when to use Entity beans (or most of the time when not to use them :) ) but I´m curious at the concept of Persistency as part of your application ...when should you use it?? and when should you rely on a DB and DAO and stateless session beans? what do you guys think of this?

     CMP/BMO was not a very good idea for DB programming.
     I think the most simple way for EJB + DB is to use single session bean with single method "invoke(String command, Object args[])" and use proxy on client.

    >
    > Regards
    > Wouter
  36. To EJB or not to EJB[ Go to top ]

    I know there is tons of discussion on this subject in internet. But I could nevr get a final conclusion. My conclusion is that there is no mature alternative than to use EJBs for a new project (who gets to do a project from scratch these days :-).

    (1) Do you guys truly believe there is a more mature alternative than to use EJBs.

    (2) Also I dont think one should use EJBs for OLAP systems, but only use it in OLTP systems. But nowadays most big projects end up as OLAP though they start as OLTP :-).

    What do you gusy think on these two points?

    -Sanjay
  37. To EJB or not to EJB[ Go to top ]

    I know there is tons of discussion on this subject in internet. But I could nevr get a final conclusion. My conclusion is that there is no mature alternative than to use EJBs for a new project (who gets to do a project from scratch these days :-).

    >
    > (1) Do you guys truly believe there is a more mature alternative than to use EJBs.

    There are a lot alternative, but it depends on use case.

    >
    > (2) Also I dont think one should use EJBs for OLAP systems, but only use it in OLTP systems. But nowadays most big projects end up as OLAP though they start as OLTP :-).

    I do not think it is a good idea to use CMP for OLTP. You are talking about something like trade system on stock exange or "transactions" in telecom, do not you ? It depends on use case and I see the most of EJB usecases are web applications, but there are a lot of simple ways to implement web application like theserverside without "superservers".

    >
    > What do you gusy think on these two points?
    >
    > -Sanjay
  38. To EJB or not to EJB[ Go to top ]

    Thanks for your views. Appreciate it!

    (1) Yes. I know there are a lot of alternatives, but when I think from the perspective of (a) Industry backing (b) maturity (c) Less unknown problems and more known problems I think EJB is the only option I have. For example, I myself has good success stories with Hibernate, but could anyone give me some solid points to crack the 3 "high level management" attacks that I have put as a,b,c above.

    -Sanjay.
  39. To EJB or not to EJB[ Go to top ]

    Thanks for your views. Appreciate it!

    >
    > (1) Yes. I know there are a lot of alternatives, but when I think from the perspective of (a) Industry backing (b) maturity (c) Less unknown problems and more known problems I think EJB is the only option I have. For example, I myself has good success stories with Hibernate, but could anyone give me some solid points to crack the 3 "high level management" attacks that I have put as a,b,c above.

    I agree with (c), experts can implement good systems with any kind of tool and all of EJB problems are known for them. But the same I can tell about any kind of technology/framework and it is more philosofy/religion than technical stuff, is not it ?
    Sorry, but it seems I do not understand (a) and (b) + EJB.
    I have used a lot of ways for server side programming, I do not think I know the best way, but I am sure EJB is not the best way for all of use cases.

    >
    > -Sanjay.