Enterprise JavaBeans 4th Ed. to be Publicly Reviewed on TSS

Discussions

News: Enterprise JavaBeans 4th Ed. to be Publicly Reviewed on TSS

  1. TheServerSide is pleased to announce the public review process of O'Reilly's 'Enterprise JavaBeans (4th Edition)', by Richard Monson-Haefel. The first 8 chapters are available for download. The topics include: EJB Architecture Overview, Developing your first EJB, The Client API, CMP: Basic Persistence, Entity Relationships, and EJB-QL.

    Download and Review the first 8 chapters from Enterprise JavaBeans (4th Edition)


    About the Book
    =================

    Enterprise JavaBeans (4th edition) provides a thorough introduction to working with the new 2.1 version of the EJB Specification, which contains significant changes from the earlier version. With the new specification, EJB extends its support for Web Services and the Java Web Services APIs, expands its asynchronous messaging support, adds XML Schema for deployment descriptors, and introduces a new Timer service which allows for scheduling EJB jobs.


    How you can help
    ==================

    The chapters of the Enterprise JavaBeans (4th edition) book are being made available for the purposes of review to allow the community to participate in the review and editing of the chapters of the book. You can help in the writing of this book, by correcting or enhancing the chapters. The author is looking particularly for comments on the book's technical accuracy, clarity, and appropriateness.

    All feedback can be sent to Richard@Monson-Haefel.com

    Threaded Messages (50)

  2. Missing Footnote[ Go to top ]

    The missing footnote is that EJB it total bloat for a typical database driven website. I'd like to see a new book titled: "EJB - why are we using it for typical web projects?". But seriously, EJB does have a use, it's just not for basic websites. The examples in these EJB books should focus on coordinated transactions. A banking example might be good. It's totally misleading to sell EJB for a typical database driven website.
  3. Missing Footnote[ Go to top ]

    if people are using EJBs where they are not meant to be used, that is their mistake. I doubt a lot of people are using it for basic web sites, as you mention.
  4. Missing Footnote[ Go to top ]

    You guys just raised a good point.
    But isn’t it the intention of a book to teach it’s readers ?
    Would be interesting to see an opening chapter that gives more room for this discussion : when and where use EJB.

    LB
  5. Is java still alive[ Go to top ]

    I thought java/j2ee would be dead by now. There are more productive frameworks around. For example .Net/C#
  6. Missing footnote? I think not![ Go to top ]

    You guys just raised a good point.

    > But isn’t it the intention of a book to teach it’s readers ?
    > Would be interesting to see an opening chapter that gives more room for this discussion : when and where use EJB.
    >
    > LB

    Luiz that is a very important question, but it is a bit laboured at this stage. There have been many an article or book chapters of that have tried to address this question, do we really need another one?

    Personally I feel an article published on the web followed by a discussion is this best way of addressing what is effectively a judgment call. The experience and skill of the developers making the choice is all important since we can't bottle this one.
  7. EJB can be used on some sites[ Go to top ]

    Geoff,

    You are correct that EJB is not needed for basic websites, but it is needed for some websites. EJB is necessary whenever you're scalability needs require a proper 3 tier architecture, where the webservers are on a different machine from those running your business logic.

    There are many high-volume website applications that could use EJB.

    Floyd
  8. agree some, disagree some[ Go to top ]

    Hi Floyd,
        I agree that if you decide you have to have a 3-tier arch, that Stateless Session Beans are the way to go. But I think the community is far from agreement that 3-tier architectures are the best way to go. I think in most cases the best place to keep the business logic is in POJO's that interact with the domain model objects. Shipping domain model objects off to an additional tier will only degrade performance.
        This degredation has been documented in numerous studies (such as RUBIS, posted on TSS). In response to the degredation, we've now got local interfaces. With local interfaces, we needlessly adopt the 3-tier "style" of programming, while the middle tier is local to the same machine as the web server.
       Based on all the performance data against network marshalling to a middle tier, and the nasty obfuscation on the domain model imposed by EJB programming, I don't think it's a stretch to strongly question the use of EJB in almost any project that does not require coordinated transactions. So why not spend time in the literature focusing on systems, like banking/financial, that could really benefit from EJB.
        I haven't even gotten into the problems with Entity Beans, but I'd be happy to discuss that too.

    (BTW, I'm assuming that the three tiers we're discussing are [web server(s), business logic server(s), Database(s)]) ...

    -geoff
  9. ok geoff, i'll bite[ Go to top ]

    what are all the problems with entity beans? if you could, please limit discussion to EJB 2.0 Entity Beans accessed via their local interfaces.

    b
  10. what are EJB problems[ Go to top ]

    what are the problems with entity beans?


    It easy to compare EJB for persistance vs using iBatis, or Hibrenate... (or ADO.net as people pointed out). On a relative scale, EJBs cost (time/effort/resources) to operate/maintain and cost more to develop, and are less scaleable compare to other aproaches. Most senior developers avoid EJB for persistance for larger business applications, ... and sometimes they have to reploy version 2 of their app. sans EJB.

    J2EE!=EJB. I use DAO happily for persistance.

    .V
  11. what are EJB problems[ Go to top ]

    It easy to compare EJB for persistance vs using iBatis, or Hibrenate... (or ADO.net as people pointed out)


    ... or JDO ! :)
  12. what are EJB problems[ Go to top ]

    forgive me, but i don't understand how the following code is expensive to develop or maintain:


    public abstract class PersonBean
    extends AbstractEntityBean
    implements EntityBean, Person
    {
    /**
    * Returns the person's first name
    * @return the person's first name
    *
    * @ejb.interface-method
    * @ejb.persistence
    */
    public abstract String getFirstName();

    /**
    * @ejb.interface-method
    */
    public abstract void setFirstName(String firstName);

    /**
    * Returns the person's last name
    * @return the person's last name
    *
    * @ejb.interface-method
    * @ejb.persistence
    */
    public abstract String getLastName();

    /**
    * @ejb.interface-method
    */
    public abstract void setLastName(String lastName);
    }
  13. what are EJB problems[ Go to top ]

    forgive me, but i don't understand ....

    Where is your SQL ?

    Take a look at ibatis.com PetStore 3 example, and compare to a EJB PetStore blue prints example.

    .V

    (The bad thing is that you can compare EJB Petstore to .NET.... and even .NET wins. But luckily, we have DAO's!!!!)
  14. what are EJB problems[ Go to top ]

    what sql? it is generated by the container.

    i did forget to add the finder queries:

     * @ejb.finder description = "Finds all people"
     * signature = "java.util.Collection findAll()"
     * query = "SELECT OBJECT (p) FROM Person p"
     *
     * @ejb.finder description = "Finds a person by his/her last name"
     * signature = "java.util.Collection
     * findByLastName(java.lang.String lastName)"
     * query = "SELECT OBJECT (p) FROM Person p WHERE p.username = ?1"
     *
    public abstract class PersonBean
    extends AbstractEntityBean
    implements EntityBean, Person
    {
    ...
    }
  15. what are EJB problems[ Go to top ]

    that should have read:

    query = "SELECT OBJECT (p) FROM Person p WHERE p.lastName = ?1"

    b
  16. now we are writing the psuedo queries into text files which are then converted by container to a real sql and then data is writtern in an object / collection.
    So we are sort of mixing DB layer stuff like stored procs into business layer now.
     I m not a expert in EJB - but i feel ejb QL is going too far & making thw whole design strick - hard coded . What if i have some joins while getting the data - ofcource entity beans arent going to help or i have ot do a lot of things to get it. For example - i want to get bank account details and the bank account name like acct number 100 Checking. I m sure a good database designer would put a table to hold all bank accounts and there will be a account_type_id foreign key in this table. So my query will be like this
       Select a.bank_acct_number, b.account_type_description from t_bank_acct a, t_acct_types b where a.acct_type_id=b.acct_type_id

    Any comments !!!!
    That brings up the age old question - besides heavy transactions and session beans - object pooling - why would someone use EJBs ??? Any good link i can look into the reasons - any convincing answers ..
  17. 1. EJB-QL provides an object-based query language that is easy to learn and easily portable to multiple SQL providers. the only gaping hole is support for dynamic queries. how are "hard-coded" SQL commands any different (other than the fact that they are not portable and often need to be tweaked for each database you support)?

    2. if you use XDoclet, EJB-QL (standard and app server-specific) queries are defined at the top of your entity bean class, right where you need them.

    3. joins are automatically navigated via EJB-QL and CMR. For example:

    the finder:
    SELECT OBJECT (a) FROM ACCOUNT a WHERE a.accountId = ?1 AND a.bank.name = ?2

    will return a collection of accounts that you can iterate over:

    Collection accounts = home.findByIdByBank(accountId, bankName);
    for (Iterator iter = accounts.iterator(); iter.hasNext() ; )
    {
       Account account = (Account)iter.next();
       int accountType = account.getType().getName();
    }

    4. app servers (including one which will remain unnamed) allow you to specify lazy and eager loading strategies for your finders.

    5. i agree. besides support for container managed persistence, container managed relationships, database independance, container managed transactions, entity caching, container managed locking strategies, massive productivity boosts (when used with XDoclet) and ZERO JDBC SQL commands, why would anyone use EJB's?

    b
  18. the bottom line is that CMP 2.0 entities combined with local interfaces are a compelling option if:

    a) you have a transactional application with many tables
    b) you have control over the underlying database schema.
    and
    c) you can use commit-option A (i.e. the app server is the only process updating the database)

    b
  19. Brad:
    > the bottom line is that CMP 2.0 entities combined with local interfaces are a compelling option if:
    >
    > a) you have a transactional application with many tables
    > b) you have control over the underlying database schema.
    > and
    > c) you can use commit-option A (i.e. the app server is the only process updating the database)

    I don't see any connection between local interfaces and commit option A, these are orthogonal issues.

    Besides, there are various strategies to use commit options B and C for optimistic locking which still make EJB a compelling solution, so I'm not quite sure what point you are trying to make here...

    --
    Cedric
  20. i didnt quite say the two were connected. the point is was trying to make was that many of the performance problems that are often cited with using cmp ejb's are mitigated through the use of local interfaces (which allow a fine-grained table model that is encapsulated by a service tier) and commit option a (which allows for a useful data caching model). thats all.

    b
  21. 3. joins are automatically navigated via EJB-QL and CMR. For example:


    Unhappily, with the cost of N+NxM database calls, being N the number of objects to be returned and M the number of relationships. Some servers have (i know JBoss just) a read ahead strategy that allows to get more Beans from each DB call, but as you need to navigate through the relationships, you'll still have to make 1+NxM calls. A read-ahead relationship would be nice too, this could stop the complains of DBA's related to CMP's.
  22. N+1 is horrible[ Go to top ]

    Gosh, I thought N+1 was bad enough, but N+N*M...good god.

    The classic Entity Bean N+1 problem is a direct consequence of the design of Entity Beans, which requires that the Key be returned (requires a db query), then the key used to retrieve the Bean (another query). So if you have N beans, you can get all the keys in 1 query (that's the "+1"), but each of the N beans requires another query to populate its fields (that's the "N").

    One of the many hot things about JDO is that there is no N+1 problem, let alone N+N*M. With JDO, a single query can return all the rows that match the query deinition, and the POJO's get populated from the same result set, if the implementation is smart. No round trip required. So if you have N objects that match the query, you get them ALL in a SINGLE query.

    Of course JDO also has the capability to give hints for preloading (PeristenceManager.retrieve), but that's all just icing on the cake. The spec describes a fundamentally efficient mechanism, that ought not to require any hints if the implementation is smart.

    -geoff
  23. N+1 is horrible[ Go to top ]

    any good CMP engine should provide the capability to define read-ahead and eager loading strategies to eliminate the n+1 problem.

    b
  24. n+1[ Go to top ]

    any good CMP engine should provide the capability to define read-ahead and eager loading strategies to eliminate the n+1 problem<

    Actually no. You really need runtime association fetching strategies to fully eliminate the n+1 selects problem (eg. HQL's "left join fetch" construct). I discussed this stuff in my JAOO presentation, I'm not sure if the slides are up on their website yet....
  25. n+1[ Go to top ]

    ok, you got me Gavin. i must be imagining the CMP EJB application that is purring along quite nicely on oracle, sqlserver, mysql, hypersonic, etc, which we managed to write AND unit test (Cactus anyone?) in an incredibly short amount of time. it's just that it seems so real...

    Gavin, how is the JBoss+Hibernate project going?

    b
  26. ...[ Go to top ]

    ok, you got me Gavin. i must be imagining the CMP EJB application that is purring along quite nicely on oracle, sqlserver, mysql, hypersonic, etc, which we managed to write AND unit test (Cactus anyone?) in an incredibly short amount of time. it's just that it seems so real... <

    It all depends upon your requirements, of course. Perhaps you don't -need- inheritance/polymorphism, offline processing, easy unit testing (please don't talk to me about cactus, this might be a reasonable solution for regression testing, but it is not sufficient for "real" test-first development). Whatever works for you. But have you *tried out* the alternatives?

    >> Gavin, how is the JBoss+Hibernate project going? <
    Alex Loubayansky already got a prototype CMP-on-Hibernate engine going. Still lots of work there, but its now looking a lot easier than I thought.
  27. It would be nice to rewrite your post now that you have EJB 3.0. Every single statement is fixed now. What else can you find now?
  28. N+1 is horrible[ Go to top ]

    Geoff:
    One of the many hot things about JDO is that there is no N+1 problem, let alone N+N*M. With JDO, a single query can return all the rows that match the query deinition

    Well, sure, but since this is not mandated by the JDO specification, an implementation is free not to implement this and still be JDO-compliant.

    In short, there is absolutely no difference with the EJB situation as of today.

    And by the way, WebLogic has been offering relationship caching since version 7...

    --
    Cedric
  29. N+1 CMP[ Go to top ]

    Well, sure, but since this is not mandated by the JDO specification, an implementation is free not to implement this and still be JDO-compliant.

    >
    > In short, there is absolutely no difference with the EJB situation as of today.

    Yes, the EB spec has been converging onto something that allows POJO-like performance. But the whole concept of "component" entities doesn't seem widely applicable to systems most of us work on.

    I think the designers of EJB had in mind a world of licensable components that would be sold, and then assembled and deployed with a heterogenous set of other components strung together. I don't think this came to pass. I don't think the "assembler" role really exist (at least I haven't seen anybody hiring ;)

    The strengths of the container (transaction management, role based security) seem a bit lost on Entity Beans when the standard pattern is to use a Session Facade in front of the EB's.

    -geoff
  30. Emerson:
     Some servers have (i know JBoss just) a read ahead strategy that allows to get more Beans from each DB call, but as you need to navigate through the relationships, you'll still have to make 1+NxM calls. A read-ahead relationship would be nice too, this could stop the complains of DBA's related to CMP's.

    If JBoss offers read-ahead but not for relationships, it's close to useless.

    --
    Cedric
  31. Obfuscation[ Go to top ]

    what are all the problems with entity beans? if you could, please limit discussion to EJB 2.0 Entity Beans accessed via their local interfaces.

    >
    > b

    Well, to start with, Entity Beans break many of the standard OO paradigms that are available when you work with plain java and POJO technology like JDO or Hibernate. When you use CMR with EJB 2.0, local interfaces, the finder methods are limited to returning a concrete class. This makes it virtually impossible to build systems that store data in an object oriented way. For example, I built a system on EJB 2.0 entity beans that stored and retrieved geographic map features. Instead of having a single finder method "findRoad" I needed multiple finder methods, one for each subclass of Road. This non-OO ripple propogated all over my application.

    Then, of course, we get to the *obvious* problems with Entity Beans. They force me to extend interfaces and classes. With JDO, there's just none of that imposition. So you might say, "yes, but with XDoclet it's easy to add my additional interfaces and extend base classes", and maybe so, but it's even easier if I have to do none of that at all!

    A year ago, I was loving EJB 2.0 CMP and EjbGen. Then I found JDO. It was tough to accept at first, that transparent persistence was that easy. But quickly you come to see that the Entity Bean emperor has no clothes.

    Think about what Local Interfaces really are ... then have a good laugh.

    -geoff
  32. agree some, disagree some[ Go to top ]

    You have answered yourself by implying that you should only use EJBs when you need the services that they provide, this surely goes without saying?

    One must understand the virtues of the services provided by EJB, and only use them "if the shoe fits".

    Having said that an application that uses a database would most likely need transactional access (if not why use a database, local files will be faster). Also depending on the aplication's deployment requirements do you need remote component model? In this case you are moving towards EJB territory, how to decide if you have arrived there is and has been the subject of much debate for a while.
  33. agree some, disagree some[ Go to top ]

    of course there are times to use EJB (and, also, entity beans) and times not to. this does not make the technology bad.

    it is disturbing to me how many people regurgitate the misbelief that EJBs and entity beans are too complex, too cumbersome, and too slow to be useful. i have built and deployed a large enterprise application (roughly a quarter of a million lines) with CMP 2.0 entities and have thusfar avoided coding a single line of sql. the application ports easily to many popular databases (that is, if you consider changing one word in one xml descriptor "easy") and performs well.

    Geoff makes a good point that the usage of entity beans imposes certain OO restrictions that can be frustrating in certain situations (Geoff's example is clearly one such situation). However, database tables are typically non-object-oriented in nature and entity beans model this characteristic quite well. :) however, these shortcomings can be overcome by wrapping access to entity beans with POJOs, just as you would wrap access to any persistance layer.

    having said that, i also think JDO and Hibernate are excellent technologies. if they work for you then great! use them! i look forward to their official embrace by the EJB specification committee. i also eagerly anticpate the consumation of the marriage between Hibernate and the application server that shall not be named.

    b
  34. ugghh[ Go to top ]

    it is disturbing to me how many people regurgitate the misbelief that EJBs and entity beans are too complex, too cumbersome, and too slow to be useful.<

    Entity beans are not merely complex, cumbersome and slow, but also:

    * incredibly difficult to unit test
    * non-reuseable outside the context of the application server
    * have a "joke" query language (EJBQL) that is useless for real applications (pagination anyone??? projection? aggregation?)
    * are not serializable, necessitating the use of the DTO pattern and associated code bloat (parallel class hierarchies) even in applications where this is otherwise unnecessary
    * do not support basic object modelling constructs such as inheritance, polymorphic association, double dispatch

    Well, thats all I can think of for now. I think me might have mentioned some other things in the book....

    And guys, if you need distributed transactions, you can use a session bean for that. Now that Hibernate supports replicated caching, the only thing that entities offer over POJO persistence are:

    * remoteabililty (useless and unscalable)
    * method-level security descriptors (virtually useless)

    I think I'm being quite fair ;->

    Actually, as Marc F often points out, entity beans also offer some extra concurrency strategies that solutions like Hibernate and JDO don't support (Hibernate + JDO are basically equivalent to commit option C). Now, I'll argue 'till I'm blue in the face that instance-per-transaction (combined with a process- or cluster- level cache) is correct in essentially all situations, especially with databases like Oracle that implement multi-version-concurrency, but entity beans -are- more flexible in this respect.

    But anyway it will still be lots of fun to get CMP running on top of Hibernate (yes, this means with ALL commit options). Kinda ironic, actually!

    peas.
  35. ugghh[ Go to top ]

    Gavin:
    > * have a "joke" query language (EJBQL) that is useless for real applications

    Gavin, you would be surprised to find out what applications are really doing in the real world with EJB.


    > But anyway it will still be lots of fun to get CMP running on top of Hibernate

    But you just said that CMP was unusable, so what's the point of a CMP implementation based on Hibernate then?

    Or are you suggesting that after all, there are indeed a few people using EJB's out there?

    --
    Cedric
  36. surprised[ Go to top ]

    Gavin, you would be surprised to find out what applications are really doing in the real world with EJB. <

    Surprised? You would perhaps be surprised to learn that I've actually used entity beans myself, once or twice. Unlike most EJB container developers, or IT "architects", I've used them to solve non-trivial problems as an actual application developer. ;) I know from experience where they fall over. My frustration with CMP was the reason I started Hibernate in the first place.


    >>
    But you just said that CMP was unusable, so what's the point of a CMP implementation based on Hibernate then?

    Or are you suggesting that after all, there are indeed a few people using EJB's out there?
    <
    Noooo! Really? Are there existing applications that use entity beans????

    Obviously the point is that if you have such an existing application, you might want to run it on top of a "modern" ORM implementation ... and even be able to start to take advantage of some of the extra features of Hibernate. Imagine being able to write finder methods in HQL, or using Hibernate Criteria queries. *Against any legacy CMP domain model!* Cool?

    But relax, Cedric, WebLogic users are of course still able to use Hibernate so no need to get all prickly at me :) Actually just today, Daniel committed some to fixes to Hibernate JCA on WebLogic....
  37. surprised[ Go to top ]

    Gavin:
    Surprised? You would perhaps be surprised to learn that I've actually used entity beans myself, once or twice.

    I'm not at all surprised, Hibernate is an outstanding product and I was certainly not questioning your credentials.

    I am just amused by the regular denial displayed by Hibernate and JDO advocates who spend so much time trying to convince themselves and the rest of the world that nobody uses EJB.

    Plugging your fingers in your ears and chanting "la-la-la" is not going to make this happen :-)

    That being said, I am very happy to see that JBoss' commitment to EJB is not faltering. Which pretty much proves my point.


    Obviously the point is that if you have such an existing application, you might want to run it on top of a "modern" ORM implementation ... and even be able to start to take advantage of some of the extra features of Hibernate. Imagine being able to write finder methods in HQL, or using Hibernate Criteria queries. *Against any legacy CMP domain model!* Cool?

    Definitely cool, but you can achieve the same result without relying on Hibernate (and as a matter of fact, we have). It's just code, after all.

    --
    Cedric
  38. denial[ Go to top ]

    I am just amused by the regular denial displayed by Hibernate and JDO advocates who spend so much time trying to convince themselves and the rest of the world that nobody uses EJB. <

    Naaah, I know they do - I'm just trying to convince them to STOP! For their own good ;-)

    hehe


    peace...
  39. WLS patch in Hibernate[ Go to top ]

    Gavin:
    Actually just today, Daniel committed some to fixes to Hibernate JCA on WebLogic....

    Great. Just don't tell Marc.

    --
    Cedric
  40. woops[ Go to top ]

    Great. Just don't tell Marc. <

    Oh shit. I hope Marc doesn't read TSS....
  41. Curious about JDO or Hibernate[ Go to top ]

    I've written a large application in ejb that just uses session beans and message driven beans (no entity beans) that is used by major Fortune 500 companies. I have to confess I learned to code while writing this application over the last two years and am ignorant about jdo/hibernate etc.. Could someone please recommend a good book/article that could show me the relative advantages of using jdo/hibernate verses session beans and message driven beans.
  42. Curious[ Go to top ]

    Andy said:
    >Could someone please recommend a good book/article that could show me the relative advantages ...

    Vic:
    http://ibatis.com

    Download PetStore, and read the DBLayer PDF, both on above.

    .V

    (also basicPortal.com is DAO based)
  43. An application using "a database" does not need a coordinated transaction. It just needs a regular, plain old transaction as provided by JDBC. COORDINATED TRANSACTIONS are required when you need to propogate a transaction context across two or more transactional resources.

    For example, you need to add a new customer account to your account database, then add the same account into your transactional billing system. In this case, a two-phase commit has to be applied across both resources. If either fails, both must be rolled back. COORDINATING these transactions is what the application server does for you. So you don't have to write XA transanction code yourself.

    I think most people using EJB's don't understand the distinction between a coordinated, managed transaction, and a simple transaction against a single database. COORDINATED transactions are what App Servers and EJB are really good at. If you don't need COORDINATED transactions, or you are not sure what they are, maybe EJB is overkill for your application.

    -geoff
  44. An application using "a database" does not need a coordinated transaction. It just needs a regular, plain old transaction as provided by JDBC. COORDINATED TRANSACTIONS are required when you need to propogate a transaction context across two or more transactional resources.

    >
    > I think most people using EJB's don't understand the distinction between a coordinated, managed transaction, and a simple transaction against a single database. COORDINATED transactions are what App Servers and EJB are really good at. If you don't need COORDINATED transactions, or you are not sure what they are, maybe EJB is overkill for your application.

    A good point, Geoff. More specifically, not only EJB's transaction management may be overkill for your application but also using JTA directly, as this is essentially the container's transaction coordination subsystem. JTA has been designed for distributed transactions and considers local single-resource transactions an "optimization". It's hard to see why typical web apps should need JTA at all, and depend on a container that provides JTA in the first place.

    Single-database apps can be perfectly happy with native transactions. Of course, if there may be future requirements for distributed transactions, you'd need to refactor your data access logic to JTA or even EJB CMT. There are ways to avoid this: Demarcate your transactions in a generic fashion, making the actual transaction strategy a configuration choice. If you might ever need distributed transactions, switch from your native JDBC strategy to JTA.

    I'll take the risk of scolding by Mike Spille again: The Spring Framework provides such generic transaction management with pluggable strategies, using either programmatic or declarative (via AOP) demarcation, and out-of-the-box implementations for JTA, JDBC, Hibernate and JDO. It allows you to defer the choice for JTA until you actually need distributed transactions and stick to a more lightweight strategy else. Declarative transactions on Tomcat, anyone?

    Juergen
  45. EJBs overused[ Go to top ]

    IMHO EJBs are overused.
    Rod Johnson gives good decision making advices. a must read when you consider with which technology to go.
  46. Wow. Monson-Haefel.

    Anyone with a hyphenated last name must be a genius.
  47. What is new in the 4th edition[ Go to top ]

    I was a big fan of the 3rd edition of the book. It seemed one of only a couple of EJB-related titles that got into sufficient depth to really be useful.

    I am curious what new material is going into the 4th edition. Will it just add new information for EJB 2.1 (namely small improvements to EJB-QL, and web services)?

    Hopefully it will go further. Some things I'd like to see are: best architectural practices, how to leverage the J2EE component model, writing for multiple target app servers, optimizing transaction strategies, etc. In other words, more advanced practical topics.
  48. The 4th edition address a number of important new features - not just updates to EJB-QL. For example, the book covers the Timer Service, which allows you to schedule the execution of stateless and entity beans. This is nice for scheduling auditing, batch processing, and other time sensitive operations, sort of like UNIX Cron jobs.

    The 4th edition also covers the expanded definition of Message-Driven Beans (MDBs), which allow you process messages from just about any protocol, not just JMS. For example, if you have a J2EE Connector for an e-mail server, you could process e-mails using MDBs. That's a lot of power.

    The book also covers Web services, a subject I've been emerged in for the past couple of years (I just finished a new book called J2EE Web Services). There are a variety of other enhancements that will make EJB developers more productive, but those are the highlights.

    As far as application architecture and best practices: The last two chapters of the book take on these subjects. I'm pretty excited about adding this content to the book, because it discusses the kinds of real world issues you are going to encounter when deploying EJB applications in a production system. I would love to take credit for this material, but the truth is my new co-author, Keyton Weissinger, is writing those chapters. You'll get to preview them in a few weeks.


    Richard Monson-Haefel
    Author of Enterprise JavaBeans, 4th Edition
    http://www.monson-haefel.com
  49. J2EE Webservices[ Go to top ]

    Hi Richard,
    How could I purchase your J2EE Webservices book? It seems not to be available on amazon or in book stores.
  50. J2EE Webservices[ Go to top ]

    You can order an advanced copy from Amazon.com or BN.com - I'm not sure when it will ship - it just came back from the printer a few days ago.
  51. What is new in the 4th edition[ Go to top ]

    Yes, I was also a big fan of the the 3rd edition of this book and it was an excellent introduction to both EJB and as part of an introduction to J2EE.

    If you are new to J2EE and part of a time constrained project it is too time consuming to get bogged down in the never ending battles of architectural philosphy. The point is that there are different tools for different jobs, but all of these frameworks and tools extensions based on the underlying J2EE platform. If you want to appreciate these philosophical battles, and know which viewpoint is correct for YOUR project, then you must know the basics. I used this book to successfully learn the basics, and in this respect it suceeds where many other EJB books fail <imho>. Another usefull feature of this book, was the possibility of obtaining a sibling book for helping run the examples in a particular application server, and hence also serve as a good guide to app server systems in J2EE.

    I am looking forward to reading about some of the new chapter in this edition. I still use EJB session beans, so I am looking forward to the overview and discussion on Web Services. Then I can add another tool to my toolbox to help get my work done.

    Tem