Discussions

News: EJB3 in production user testimonial from JBoss

  1. Chris Malan sent an EJB3 success story in to Bill Burke for posting. In it, Chris discusses the deployment specifics of his application, the toolsets he used, and some opinions about usage and scalability.
    What about EJB3? Much, much better than EJB2.1. The ability to extend classes (not used with this application but extensiv ely used with a real estate application I am working on - base class Property, extended classes Residential, Commercial etc) is heaven-sent. I managed something similar with 1:1 tables/classes in EJB2.1, but it was much more work. The thinking paradigm is now almost purely Java (Object Oriented) as opposed to thinking in database terms (tables, columns and rows and relationships). I became aware that things are now different to what it was in EJB2.1 while coding. Maybe one can say EJB2.1 was closer to the database and EJB3 is almost pure Java programming.
    It's not a long write-up, but it does illustrate a possible use of EJB3 fairly clearly. This isn't a large application by any means, and Mr. Malan makes claims about scalability that may or may not be justifiable ("When it went 'on air' I had all the office staff (eight) go on and attempt a transaction without help. There were no problems... In the real world I suspect the network (Internet) will be the bottleneck long before the software falls over.") but it's certainly a good look at how real people will use EJB3.

    What do you think?

    Threaded Messages (33)

  2. Programmer needs thinking in database terms with any EJB version. Probably the best way to break data and domain model is to think about data in programming terms.
  3. 8 concurent users per minute?
    That is a big improvment for EJB-croud to be proud of, a record!

    I assumed people gave up on EJB/J2EE about ... 2 years ago or so.
    PHP, Groovy, Ruby, and others are closer to the metal (SQL based) for commercial scale.
    "Enterprise"(EJB) is just a marketing word for deparmental- small scale. Best used w/ JSF on Sparc 1 gigaherz server ;-).

    If you want to duplicate this 8 users per minute, you should duplicate a credible EJB claim and approach. (yeah, cash it all in a hashmap, if db fits in memory)
    Else ... find and duplicate what people that get millions of concurnet users do.

    hth,
    .V
  4. Sparc??[ Go to top ]

    Best used w/ JSF on Sparc 1 gigaherz server ;-)

    I believe an opteron box will blow that sparc out of the water (although the instruction set is now quite definitely beyond recovery ..)
  5. 8 concurent users per minute?That is a big improvment for EJB-croud to be proud of, a record!I assumed people gave up on EJB/J2EE about ... 2 years ago or so.PHP, Groovy, Ruby, and others are closer to the metal (SQL based) for commercial scale."Enterprise"(EJB) is just a marketing word for deparmental- small scale. Best used w/ JSF on Sparc 1 gigaherz server ;-).If you want to duplicate this 8 users per minute, you should duplicate a credible EJB claim and approach. (yeah, cash it all in a hashmap, if db fits in memory)Else ... find and duplicate what people that get millions of concurnet users do.hth,.V

    Having been on projects that used J2EE to build high traffic sites I must conclude that you are a flame-baiting, knucke dragging, mouth breathing, script kiddy idiot. Yes we used EJB 2.x CMP/CMR Local beans before we knew that Hibernate existed. I've also been on Hibernate projects (EJB 3 like) that had no problems scaling. Where do you get your information?

    PHP and Ruby are far from dominating anything.

    DICE
    PHP 766 jobs
    JSP 3,186 jobs
    Struts 1,527 jobs
    Ruby 42
    "Ruby on Rails" 7

    Besides you talk about JSF as if you actually know how to use it or have actually used it on a project, which you have not.
  6. domination?[ Go to top ]

    Here are some other interesting stats....

    DICE
    ----------------
    .NET 9592 jobs
    ASP 9916 jobs
    VB 3451 jobs
    perl 4008 jobs
    python 461 jobs
    COBOL 1252 jobs

    So, COBOL skills are about as in demand as Struts skills? Could be. Almost noone is looking for (or at least advertising for) python skills? Could be. There are a shitload of python programmers out there, and at conferences the sharp guys all seem to have some python under their belts. The same seems to be happening quietly with ruby. But noone's putting out job offers looking for these guys. What could that mean?
  7. domination?[ Go to top ]

    There are a shitload of python programmers out there, and at conferences the sharp guys all seem to have some python under their belts. The same seems to be happening quietly with ruby. But noone's putting out job offers looking for these guys. What could that mean?

    I suspect that Python simply isn't forming the major part of many applications, and is being used mostly for small scripting jobs; not large applications that need support and on-going development, so you probably aren't going to see it specifically requested as a main skill. This does not mean it isn't widely used.
  8. I think your DICE numbers would benefit from a search for J2EE, I'm not quite sure why you didn't include that number to begin with:

    J2EE 12,714 jobs
  9. Thanks TSS[ Go to top ]

    Thanks TSS for picking this up. Between our blog and TSS, I got a few more references.

    Bill Burke
    JBoss Inc.
  10. What do you think?
    I think, TSS is becoming increasingly bloated with marketing bragging.

    EJB3 is not even published as a final specification, what "implementation" and "production use" are you guys talking about?

    Come on!

    P.S. That aside, yes, EJB3 looks much more promissing than the predecessors and Hibernate is an awesome persistence back-end. So what? What's new in that?
  11. This isn't "marketing" or "bragging." Personally, I thought it was interesting that someone's using EJB3 in production when - as you say - it's not a final spec yet.

    That said, there it is: someone's using it in production, on a low-load application, but still...
  12. More testimonials coming[ Go to top ]

    I've talked to a number of JBoss EJB 3.0 users and customers that are either a) developing a production application using EJB 3.0 or b) deploying it in production. I hope to publish more of these on our blog in the next weeks/months.

    This is a small application, but so what? The testimonial puts a face on the general feedback that I've been getting: That developers love EJB 3.0.

    I've already thanked him in private email and in my blog, but one more time. Thanks Chris! And apologies for your testimonial on reaching TSS. Take negative comments with a grain of salt. TSS posters can traditionally not be the nicest people in the world, myself included. :)

    Bill Burke
    JBoss Inc.
  13. More testimonials coming[ Go to top ]

    I don't see the testimonial being on TSS as a negative. I think Chris did a fine job backing up his statements with data - although I do wonder about actual scalability. But it sounds like his application doesn't have scalability issues (in practice) so actual scalability may not be an issue - and his commentary certainly made clear statements about it.
  14. More testimonials coming[ Go to top ]

    TSS posters can traditionally not be the nicest people in the world, myself included. :)Bill BurkeJBoss Inc.
    *sigh* As a matter of fact, I don't have anything against JBoss or Bill and, of course, nothing against Chris.

    And there is "freedom of speech", of course so - feel free to post anything. I just don't understand how can something be classified as EJB3 if there is no final definition of what EJB3 is.

    If you step aside and forget, for a sec, that you are a JBoss employee, you will see that it really looks like a Chungatwarkumandaharpudenbrahdabadah. Have no idea what it is but, well, there is a spec on anything in JSR so most probably, there will be one on Chungatwarkumandaharpudenbrahdabadah, too - not so far in the future.

    *bigger sigh*

    I am sorry, but it _is_ cheesy. Just wait a little bit more and you will get yuor fame - it's not going anywhere, anyway.

    best of luck...
  15. More testimonials coming[ Go to top ]

    TSS posters can traditionally not be the nicest people in the world, myself included. :)Bill BurkeJBoss Inc.
    *sigh* As a matter of fact, I don't have anything against JBoss or Bill and, of course, nothing against Chris.And there is "freedom of speech", of course so - feel free to post anything.

    *double sigh*. The comment wasn't targeted at you, just TSS in general, so don't take it personally.
    I just don't understand how can something be classified as EJB3 if there is no final definition of what EJB3 is.

    EJB 3.0 is in public draft and it is not like the expert group is going to totally rewrite the specification for the final release! Java EE 5 is slated to be final before Java One next year and sub-specifications like EJB 3.0 have to be done *long before* so that the reference implementation and TCK can be completed.

    As a developer and co-lead of JBoss EJB 3.0 I like to hear that people are using my software to write real-world apps and that they enjoy coding in the new specification. If you step aside and forget, for a sec, that I am a JBoss employee, you'll see that I'm like any other developer and enjoy positive feedback from my userbase and like to share this feedback with others.

    BTW, What's been going on in the expert group is the refactoring of interceptors, packaging, and deployment. I'll be blogging about all of these features as soon as they are finalized in the expert group. Of course, there has been a few tweakings here and there of the API/annotations to fix mistakes in the public draft as well as clarification on certain features like optimistic locking and flush mode.


    Bill Burke
    JBoss Inc.
  16. I just don't understand how can something be classified as EJB3 if there is no final definition of what EJB3 is.

    I think there is such a thing as definition of EJB 3.0 as it stands today.
  17. You people have to make up your minds! If EBJ3 weren't used in real cases before being ready, people would complain that it was not based on real world practical needs. So ok, let's try it before calling it 100% ready, and now people complain about that?! Go figure...

    Better have people trying new technologies before they are set in stone than complain about mistakes and missing features further down the line. Like alpha/beta-testing a spec in a real world situation.
  18. public draft[ Go to top ]

    I just don't understand how can something be classified as EJB3 if there is no final definition of what EJB3 is.

    Obviously, EJB3 "is" the current public draft of the JSR-220 specification available here:

      http://jcp.org/en/jsr/detail?id=220

    Of course, there will be a number of new features and refinements in the proposed final draft which is due very, very soon now. That is of course no reason to avoid development use of EJB 3.0 today - no matter what changes go into the final draft, the current draft is closer to the final draft than any other solution (EJB2, whatever) you might choose to use in the meantime, as all these guys:

       http://jboss.com/index.html?module=bb&op=viewforum&f=221

    and all these guys:

       http://forum.hibernate.org/viewforum.php?f=9

    and these guys:

       http://jboss.com/index.html?module=bb&op=viewforum&f=231

    understand.
  19. public draft[ Go to top ]

    Yeah, I admit:

    we were going to jump into using JBOSS EJB3 for our 35M Tx/day system and then write about it, but were too late.

    This little website beating us with its 8 human testers, really pissed us all off. So, I guess - we won't be using JBoss's EJB3, any more. Sorry...

    Very convincing write-up, though. Found lots of interesting data, especially that there are "totally EJB3 applications" with "pure J2EE EJB3 frameworks" (WTF?).

    Quote: "This application uses the MVC architecture. As far as a framework is concerned, it uses a pure J2EE EJB3 framework as far a s that is possible. No Struts or anything else. Of course, much of the functionality is JBoss specific as the full EJB3 spe cification has not yet been decided upon."

    I am confused how this MVC approach correlates with the next sentence: "All user response pages (only two) are directly generated by a servlet."

    Apparently, according to the new specs, direct servlet-generation of pages is an MVC approach.

    But who cares, what beats me the most is that, it is also clear, that if you use Struts - you are not going to be "totally EJB3 framework, any molre" Oh, well...

    Great write-up. Please, post more like that. Was overwhelmed with the wealth of data.

    IT WAS CHEESY - get over it, please :)
  20. More testimonials coming[ Go to top ]

    This is a small application, but so what? The testimonial puts a face on the general feedback that I've been getting: That developers love EJB 3.0.

    I think this is useful story. This has been a year when Java POJO persistence mechanisms (not just EJB 3.0!) have changed significantly to become far simpler and more developer-friendly. After recent 'Java is stagnant/J2EE is doomed' (to exaggerate somewhat) threads on TSS it is good to see a more realistic and positive view of things, showing how things are improving for J2EE developers.

    As for this being a small application, I don't see the problem either. It is OSS and seems cheap to run - in my view it backs the 'Java/J2EE scales down as well as up' argument.
  21. Embarrassing[ Go to top ]

    What do you think?
    Frankly I'd have to say it's a little embarrassing. Besides, isn't EJB3 obsolete now that OpenToro has been released ? It's time to move on.
  22. Maybe one can say EJB2.1 was closer to the database and EJB3 is almost pure Java programming.
    This is better why?
  23. an opinion[ Go to top ]

    Maybe one can say EJB2.1 was closer to the database and EJB3 is almost pure Java programming.
    This is better why?

    That depends if you want to have an OO model of your problem domain or if you want the relational model be "the model". It's a big debate and I'm definitely on the OO side of it. To me it's a huge bonus to build a model of the problem that encapsulates not just information, but also behavior (not to mention all the other benefits of OO). In addition I have to construct objects representing business concepts that pull data from several databases, mainframes, and 3rd party sofware systems (ERP, CRM, Billing, etc). I can't let the database be the model.
  24. an opinion[ Go to top ]

    Maybe one can say EJB2.1 was closer to the database and EJB3 is almost pure Java programming.
    This is better why?
    That depends if you want to have an OO model of your problem domain or if you want the relational model be "the model". It's a big debate and I'm definitely on the OO side of it. To me it's a huge bonus to build a model of the problem that encapsulates not just information, but also behavior (not to mention all the other benefits of OO). In addition I have to construct objects representing business concepts that pull data from several databases, mainframes, and 3rd party sofware systems (ERP, CRM, Billing, etc). I can't let the database be the model.
    "OO" is about programming and there is nothing wrong in OOP, but I do not understand "OO model" in this context. Do you meen program is a model or some kind of picture in CASE tool is "OO model" ?
  25. EJB3 is excellent[ Go to top ]

    Actually it was sort of a mistake that they named EJB3 EJB, after the bad rep, the really lousy 1.x and 2.x EJB standards got. EJB3 really is excellent and probably one of the best things which could happen to java (that and the Spring framework)

    Given my small testing experiences I got with EJB3 I see no reason why EJB3 should be slower than other pojo systems like spring (unless you remote the beans)
    and given the fact that the orm layer basically is straightly derivced from Hibernate and Toplink but a tad easier to use, this is a good argument pro EJB3.

    Believe me, EJB3 really is a joy to use, but I think giving it the name EJB was a huge mistake, EJB3 does not have too much in common anymore with the old EJBs, it has much more in common with the Spring beans and Hibernate, it actually is close to being a mixture of both without the huge XML overhead both systems have (EJB3 uses rather minimalistic annotations which are only set where absolutely needed)
  26. Believe me, EJB3 really is a joy to use, but I think giving it the name EJB was a huge mistake, EJB3 does not have too much in common anymore with the old EJBs, it has much more in common with the Spring beans and Hibernate, it actually is close to being a mixture of both without the huge XML overhead both systems have (EJB3 uses rather minimalistic annotations which are only set where absolutely needed)

    I have been experimenting with the "javax.persistence" part of the new JSR220/EJB3 specification and I must say that I do like what I see there. Easy to use and the option of choosing the persistence from several available options. I'm not yet sold on the EJB side of things in the EJB3 spec but I'm keeping an open mind.

    The persistence framework is not at all tied in to the EJB layer so most of my testing used only a servlet and non-managed persistence.xml in a Tomcat environment. I think the early "EJB3" use will involve mostly the new persistence spec since there are several mature implementations that are already available for experimentation.

    I was able to use the same code base against both the Hibernate and the Kodo implementations and though there were a few inconsistencies, things mostly worked as expected. I'm not sure I would recommend true production use yet, but as soon as the spec is finalized and the persistence providers move their products out of beta I think production use in non-critical apps is appropriate.
  27. Non EJB Server EJB3 session beans[ Go to top ]

    Well two things sold me on the EJB3 beans

    a) there already are implementations in the works which do not need a dedicated ejb server with all its overhead you probably wont use 90% of the time (jmx consoles etc...)

    b) the annotations are even simpler than with the entity beans, this stuff is really easy to use.

    you simple add an interface to a class, declare it stateful or stateless and you are set,
    if you want remoting add another line...
    IOC is also possible with the @EJB and other annotations

    the client initialisation is equally simple, dump the class name of the interface into jndi and you get a proxied pojo back.

    Thats it, took me five minutes to implement my first session bean and that is what basically sold me on that stuff.

    And given all the foundations which are layed out there, things like adding webservices via ejbs etc... should be possible in the long run I assume. (Currently you have to stub them to get webservices)

    Seam also is an excellent example on what you can to with EJB3 session beans, the whole foundation is built upon it, with ejbs automatically becoming JSF backend beans, using the EJB IoC mechanism for automated jsf artefact injectione etc...

    No EJB spec really looked interesting to me, actually I always thought they were an unmaintainable awfull mess, but this one is not, neither the EJB Session bean part, which just implements the BO Pattern in a very clean and compact way, nor the entity beans which are an excellent ORM mapper built upon a solid well tested foundation.
  28. Thomas. Great job demoing EJB3 at the Philadelphia Spring Users Group last night.
  29. I have been experimenting with the "javax.persistence" part of the new JSR220/EJB3 specification and I must say that I do like what I see there. Easy to use and the option of choosing the persistence from several available options. I'm not yet sold on the EJB side of things in the EJB3 spec but I'm keeping an open mind.

    Session beans + EntityManager have seamless integration and transparent persistent session management. Try it out. Your code will end up a lot cleaner. SFSB's allow you to automatically manage an extended persistence context so that your pojos remain managed even after the JTA transaction has ended. Plus, session/mdbs are extremely easy to deploy. I think if you start using session beans again, you'll find them a pleasure to use.
    The persistence framework is not at all tied in to the EJB layer so most of my testing used only a servlet and non-managed persistence.xml in a Tomcat environment.

    Have you checked out our fully embeddable EJB 3.0 container? You can run it inside Tomcat or even a Junit test. Takes only a few seconds (<5) to initialize and we'll be improving this in the future.


    Bill
  30. Get a load of this ...[ Go to top ]

    From the article:
    All user response pages (only two) are directly generated by a servlet.

    Is TSS going to be the victim of a hostile takeover soon?

    G
  31. Takeover[ Go to top ]

    Is TSS going to be the victim of a hostile takeover soon?G
    You mean it didn't happen yet ? :-)
  32. EJB3 rocks, big time.[ Go to top ]

    I must say, I'm _now_ a big fan of EJB,mainly because of
    1) @Entity
    2) @Stateless
    3) @PersistenceContext private EntityManager em;

    EJB3 is the indeed the best thing that happened to J2EE (or is it JEE).
    It's a boon (at least for me) that vendors like JBoss Inc are having a working/usable EJB3 implementation so early in the process.

    As for scallability, large EJB 2.x applications have been working fine for years, I don't see why the situation would change with EJB3.

    Thanks to Chris Malan for sharing his experience.

    Cheers,
    Dom.
  33. EJB3 + JSP2[ Go to top ]

    We developed our whole application using just EJB3 and JSP2 (on PostgreSQL + Tomcat). As far as database scaling goes, many of queries involve millions of rows in our demo (http://www.gauntletsystems.com). Just change the view to all dates. We have found the the Hibernate 3.1 implementation of the EJB3 persistence specification to be of high quality and generally writes the same queries we would write by hand, though with a much more efficient syntax. In a normalized database schema EJB-QL queries are far more intuitive than their SQL equivalents.

    There are of course always query optimizations that could be done, but those have all been in the database layer. EJB3 has never been an issue.

    All this being said, we also have our own code generation layer that creates our EJB3 source files (with annotations, relations, etc) from our database schema and rarely write EJB3 entity code directly. Interestingly, we prototyped a large part of our code base in Groovy but eventually this tool is the only one that remains in Groovy. One of the nice things about Groovy is that it is relatively easy to move to Java when you want something maintainable.

    For those of you that use Ruby on Rails, you might finish ActiveRecord by making it so you don't have to specify relationships in the classes since that information should already be present in the database, thus completing the DRY principle. At least that is my take-away from investigating it.
  34. EJB3 + JSP2[ Go to top ]

    We developed our whole application using just EJB3 and JSP2 (on PostgreSQL + Tomcat). As far as database scaling goes, many of queries involve millions of rows in our demo (http://www.gauntletsystems.com). Just change the view to all dates.

    Would you be interested in providing a testimonial like the one referenced in this blog? Contact me: bill at jboss dot org.

    Thanks

    Bill