Discussions

News: J2EE Year in Review

  1. J2EE Year in Review (25 messages)

    2002 is marked by the release of J2SE 1.4, final drafts of J2EE 1.4, the opening of the JCP licensing policies to open source, web services support by J2EE vendors, tighter integration within vendor product stacks, critical mass for the eclipse project, petstore bechmarks, and the fall of WebGain and HP Bluestone. An article on SDTimes reviews the year.

    Read Maturing Java Gives Developers a Respite.

    They also have an article reviewing web services in 2002.

    Threaded Messages (25)

  2. J2EE Year in Review[ Go to top ]

    Instantly discredited, TMC vowed to rerun the benchmarks, despite Java Pet Store’s unsuitability as a benchmark application.


    Huh, that's such a correct assessment. I think that TMC made a bad job serving its partner MS, it discredited itself completely in eyes of J2EE developers. I doubt anybody would make deals with them anymore.
  3. J2EE Year in Review[ Go to top ]

    I hope nobody will again start the Petstore catfight here. I think everybody had enough.

    Cheers
    Zulfi
  4. J2EE Year in Review[ Go to top ]

    But another thing is not mentioned in this article is petstore bechmark let a lot of Java developers to rethink about EJB and entity bean, it seems entity bean is being thrown out of window by more and more developers, I believe it's a good thing for J2EE as well.
  5. J2EE Year in Review[ Go to top ]

    Marco, I agree. Although the benchmark was terrible PR for J2EE, which got a kicking it didn't deserve, it did demonstrate that some "classic" J2EE idioms have poor performance. So at least something useful came out of it (or will come out of it so long as the J2EE community doesn't simply try to ignore the whole thing). I'd already commented on the performance characteristics of BMP entity beans in my book.

    Btw, although the benchmark has mishandled, the fact that Floyd posted a link to an article critical of TMC tends to disprove the theory that TMC is a sinister Microsoft front.

    A couple of other highlights of last year for me:
    - Two excellent app server releases: WebLogic 7.0 and JBoss 3.0. I'm sure other excellent products were released, but I've worked a lot with both of these and I'm impressed.
    - Microsoft finally released .NET, which proves to owe a lot to J2EE. It's healthy for J2EE to have competition. Hopefully some of the good ideas in .NET will feed back into J2EE.
    - People getting wiser in how they use J2EE. Less naivety than in the past: more wariness of marketing hype from Sun and app server vendors.

    Rod Johnson, author of Expert One-on-One J2EE Design and Development
  6. J2EE Year in Review[ Go to top ]

    Marco, I agree. Although the benchmark was terrible PR for J2EE


    It was a terrible PR for TMC. I don't think that there was any damage to J2EE. Everyone knows what happened, and who was behind.

    > - People getting wiser in how they use J2EE. Less naivety than in the past: more wariness of marketing hype from Sun and app server vendors.

    I agree with this. It's also very natural. J2EE came out just few years ago, it took time to gain experience and understand our tools better. It was naive to expect that people would make perfect apps from the first day.
  7. J2EE Year in Review[ Go to top ]

    Rod,

    After reading your posts on TSS, I bought your book from Amazon. Great material.....everyone involved in J2EE development should read that book!

    We are currently transitioning our website / app to JSP from ASP. Your book, Bayern's JSTL book, and Ted's Struts In Action are the 3 tech books that have really proven themselves.

    Best Regards,
    Tom Pridham
    I.S. Director
    Matrix Healthcare Services
    Tampa, FL
  8. J2EE Year in Review[ Go to top ]

    I just checked amazon.com.
    The rating for the book is 5.0/5.0.
    Good work Rod.
    I can't wait to find out what's in it.
  9. J2EE Year in Review[ Go to top ]

    My copy arrived the other day and I'll agree that the book is very comprehensive just browsing through it so far. It's going to take a little time to absorb the material but Rod brings out the technical know-how to question your archicture decisions/deployments.

    Not pimping books but this came along with my amazon order, "J2EE Performance Testing with BEA WebLogic Server" appears to nice addition to the collection. Pretty much enough information to fry your remaining brain cells if you finish Rods book.

    I think petstore would have been different if these were books were referenced.
  10. J2EE Year in Review[ Go to top ]

    I am not sure that I agree. In the end, J2EE essentially is about EJBs. There is not much reason buying a whole J2EE APP Server, if you do not intend to use EJBs is there? And if you plan just to go for session beans -fine. But just using session beans is a bit like using servlets (possibly as web services) in the first place.

    True there are other nice infrastructure things, but they seem minor compared to EJBS. I'd rather say entity beans should be only used in a certain way and flavour, like local interface, CMP only etc. (that is also dependant on the EJB container to some extent, ugh). But the fact that they can provide very high developer productivity alone is a good reason not to throw them out of the window.

    Karl
  11. J2EE != EJB[ Go to top ]

    <karl>
    In the end, J2EE essentially is about EJBs. There is not much reason buying a whole J2EE APP Server, if you do not intend to use EJBs is there?
    </karl>
    This isn't really a technical argument. Architecture should be driven by what proves most effective for the given application, not want we happen to have in our toolset. There isn't much point buying a car with airbags unless you crash, either. Just because a feature is there doesn't mean you should use it. (It's equally arguable that there's no point buying a modern RDBMS unless you make heavy use of stored procedures and triggers. But that doesn't mean that we always want to do so.) Consider the following areas of app server functionality that aren't unique to EJBs:
    - JTS/JTA: two phase commit etc.
    - Connection pooling, thread pooling etc.
    - JMS
    - JNDI
    - JCA
    - Support for clustered servlets

    These all represent real value in.

    <karl>
    True there are other nice infrastructure things, but they seem minor compared to EJBS
    </karl>
    No, EJB is merely one way of interfacing with the overall infrastructure of the app server. It's not always the best way.

    Regards,
    Rod
  12. J2EE != EJB[ Go to top ]

    <Rod>
    This isn't really a technical argument. Architecture should be driven by what proves most effective for the given application, not want we happen to have in our toolset.
    </Rod>
    You are right, it is not a technical argument. However, most J2EE appservers are complicated system that take a lot of work to run in a production environment and to develop into. In my opinion, *if* you choose to use a J2EE app server you should have good reason for it. Not only because buying it is expensive, but developing for it and running it can be expensive, too.
    For me, this boils down to using EJBs. The analogy with the airbag is wrong: EJBs are not a passive fallback feature (like, say SNMP, JMX etc.) but an active feature. It makes good sense not to buy a stationwagon if your single and parking is an issue in your neighborhood. Although, of course you might decide to buy one if it looks good - granted a lot of people get J2EE in their projects based on this train of thought.
    <Rod>
    - JTS/JTA: two phase commit etc.
    - Connection pooling, thread pooling etc.
    - JMS
    - JNDI
    - JCA
    - Support for clustered servlets
    </Rod>

    True, they are useful to some extent. But they have their problems - conceptual or because of immaturity (JTS/JTA, JMS) - or are available in much more lightweight systems that are a lot easier to manage (JNDI, Connection pooling, thread pooling) and to develop for.
    <Rod>
    No, EJB is merely one way of interfacing with the overall infrastructure of the app server. It's not always the best way.
    </Rod>
    EJBs are active framework components in the app server. As such they are of another class than JNDI, JMS, JTS, ConnectionPools etc.

    Regards, Karl
  13. J2EE != EJB[ Go to top ]

    <Karl>
    [JTS,JNDI etc.] are useful to some extent. But they have their problems - conceptual or because of immaturity (JTS/JTA, JMS) - or are available in much more lightweight systems that are a lot easier to manage (JNDI, Connection pooling, thread pooling) and to develop for
    </Karl>
    If you consider these technologies to have serious problems, how will EJB help? After all the most important EJB services are related to transactions (JTS/JTA). EJBs are one way of leveraging all these container services. And the underlying technologies are pretty mature now.

    <Karl>
    Most J2EE appservers are complicated system that take a lot of work to run in a production environment and to develop into. In my opinion, *if* you choose to use a J2EE app server you should have good reason for it. Not only because buying it is expensive, but developing for it and running it can be expensive, too.
    </Karl>
    This is a circular argument. You're saying that J2EE is complex, so you shouldn't use an app server without good reason, the reason being that you must always use the most complex features of J2EE.

    Most of the complexity you complain of in J2EE relates to EJB. If you don't need to use the EJB, you'll find deployment and development much easier. J2EE can be a lighter weight approach, in many applications.

    Also, the expense is optional. You don't need to buy an app server unless you can see the return on the money you spend...JBoss works pretty well. (And deployment to JBoss is very easy.)

    I'm not saying don't use EJB, just don't automatically use EJB in every application. I discuss how to make the choice in chapter 1.

    Regards,
    Rod
  14. J2EE != EJB[ Go to top ]

    <Rod>
    If you consider these technologies to have serious problems, how will EJB help?
    </Rod>
    Oh, dear, because they *isolate* you from the problems, of course. Take transaction management, for example, something that is not easy to handle by hand....

    <Rod>
    This is a circular argument
    </Rod>
    Sigh :-) ....it is not a circular argument. Extending the argument to the project management and production planning domain is not circular. Also note that I did not say you should not use the more complicated (and eventually powerful!) feature of the app server, but that you should make up your mind about if you really need them. If you don't management and development issues - in my opionion - will not vanish. In fact the extra effort is not reflected in any extra gain.

    <Rod>
    Also, the expense is optional.
    </Rod>
    Again, it is not. License fee is optional. Running a J2EE environment has its cost. Also, J2EE development cycle is expensive because of
    - deployment issues - though of course not as expensive as it used to be in the days before "hot deployment".
    - complexity of the environment itself
    <Rod>
    I'm not saying don't use EJB, just don't automatically use EJB in every application.
    </Rod>
    Absolutely, what I am saying. In addition, if you do not use EJB, what I am saying is, you might be better off without a full blown J2EE app server, in the first place...
  15. J2EE != EJB[ Go to top ]

    Hi,

    we are using CMP EJBs for a large banking application since two years now.

    We are very happy with our solution and its performance (Borland Appserver).

    And due to the fact that we are using the integrated jBuilder as well and its EJB designer our productivity is quite good.

    I've also used EJBs (BMP) 4 years ago with iPlanet and the former one. That was a really cruel thing but today I believe and know there are some good reasons to use EJBs...and in special Entity Beans with CMP...


    Oliver.Lauer@sk-koeln.de
    Department Manager
    Software Develoment
    Stadtsparkasse Cologne
    Germany
  16. J2EE != EJB[ Go to top ]

    <Karl>
    if you do not use EJB, what I am saying is, you might be better off without a full blown J2EE app server, in the first place...
    </Karl>

    Hi Karl,

    It seems that there is a diversity of interpretation concerning the terms "J2EE" and "app server" in your discussion with Rod. Rod considers J2EE a bag of associated technologies that you can choose from - a view that I absolutely share. You tend to treat it as "take it all or leave it all, it's always complex", considering EJB the main element and subordinating the rest.

    IMHO J2EE has lots to offer besides EJB, especially for web applications. If you want to avoid the inherent complexity of a full-blown app server, in terms of configuration, deployment etc, why not use a more lightweight app server like Resin or Tomcat 4 (+ Tyrex, if needed)? I tend to call the latter "J2EE web app servers", but essentially they are J2EE app servers too, just without EJB and JMS.

    Why do you consider transaction management hard to handle without EJB? EJB allows for declarative transaction demarcation, but programmatic demarcation via JTA UserTransactions is fine too. The UserTransaction and the XA-capable resources are available via JNDI, just like in an EJB, of course.

    In my experience, development and deployment are significantly easier without EJB. Configuring and running a web app server like Resin 2.1 or Tomcat 4.1 is simple and straightforward, even for production sites. Just compare running a Resin environment with running a WebSphere environment - there is a tremendous difference in terms of effort and hassle! Note that I consider JBoss 3 and JRun 4 lightweight too, although to a lesser extent - despite them being "full" J2EE servers.

    In his book, Rod uses the analogy of choosing between a truck and a car. Of course a truck has its merits, but why use a truck - which is more complex and harder to handle - if you just need a car? IMHO this applies both to the EJB (technology) and the app server (product) issue.

    Personally, I use IDEA 3.0 with local Tomcat 4.0/4.1 and Resin 2.1 installations. Configuring them for ease of use is a breeze: Mounting the same project directories allows for just changing a file resp. compiling a changed class and waiting for the restart if one is necessary - no dedicated deployment steps. I really love the simplicity of J2EE web apps :-)

    Regards,
    Juergen

    P.S.:
    Great book, Rod! I've just read it during my holidays. Maybe the biggest difference between your views and mine is your preference for Eclipse and JBoss in contrast to mine for IDEA and Resin... ;-)
  17. J2EE != EJB[ Go to top ]

    In my experience, development and deployment are significantly easier without EJB. Configuring and running a web app server like Resin 2.1 or Tomcat 4.1 is simple and straightforward, even for production sites. Just compare running a Resin environment with running a WebSphere environment - there is a tremendous difference in terms of effort and hassle!


    I doubt it.

    1. EJB provides you with component framework. It's easy with it, rather than without it. Actually, the main complain against EJB is performance, not difficulty, I believe.

    2. Try to integrate Tomcat with all sorts of legacy stuff. It's easier to deploy WebSphere in the enterprise environment, in my opinion.
  18. J2EE != EJB[ Go to top ]

    Argyn,

    Juergen spoke of his experience, so "I doubt it" isn't relevant. Juergen's experience also tallies with mine and that of many other J2EE developers. Tomcat 4.x and JBoss 3.x are very easy to install and run, unlike some high-end products.

    1. EJB isn't always easier. It depends on how much value using EJB adds to what you're doing. Unless you really need EJB services, you won't get a payback for the initial complexity. Sure, if you can get a lot of use out of EJB CMT, things may be simpler with EJB. But if you have unusual transactional requirements, or simple transactional requirements, EJB won't help very much.

    2. Of course high-end products such as WebSphere have their place. But we're not always talking about systems that involves lots of "legacy stuff". It's a question of choosing the right tool for the job.

    Rod
  19. J2EE != EJB[ Go to top ]

    1. EJB isn't always easier.


    Neither EJB is always more difficult. My point was that for many enterprise applications, it's easier to develop with EJB. Also, we'd better distinguish between Stateless and other EJBs. What about MDB? Aren't they nice and fast? EJBs have specific performance characteristics, we gave to take them in account.

    It's kinda considered cool these days to say "EJB sucks" :)


    > 2. Of course high-end products such as WebSphere have their place. But we're not always talking about systems that involves lots of "legacy stuff". It's a question of choosing the right tool for the job.

    WebSphere is the right tool for many jobs, that's why it has 35% market share (as well as WebLogic), despite its price. Otherwise everybody would switch to jBoss.

    My point is that "easy" has many meanings. I've been dealing with apps which are integrated into enterprise environments. For a variety of reasons, it's "easier" to integrate WebSphere or WebLogic.
  20. J2EE != EJB[ Go to top ]

    <Argyn>
    I doubt it.
    </Argyn>

    Well, I've worked with both kinds of setup, and I absolutely prefer a Tomcat or Resin environment. I still shiver when I think of the WebSphere installation and administration workshops I attended...

    Of course, I talk about web-based systems without direct legacy integration. But on the other hand that's exactly what many WebSphere and WebLogic environments are used for - unfortunately not only their "entry" editions...

    BTW in one major project, we had quite heavy AS/400 integration - via a shared database. Resin did the app server job nicely.

    <Rod>
    Of course high-end products such as WebSphere have their place. But we're not always talking about systems that involves lots of "legacy stuff". It's a question of choosing the right tool for the job.
    </Rod>

    Yep, exactly. Don't choose a truck if you just need car aka don't break a fly on the wheel. So many internet and intranet projects don't a heavyweight app server, no matter if "entry" or "enterprise" edition. IMHO in most cases, they are far better off with a handy J2EE web app server like Resin 2.1 or Tomcat 4.1.

    BTW in my experience, you normally don't need a classic HTTP server like IIS or Apache in front, as most J2EE web app servers have fast and adequate HTTP servers built in. So simple to setup - just unzip, change 1 or 2 config settings, and off you go... We even use Tomcat and Resin standalone in case of CGI integration, as Tomcat's CGI servlet works nicely with Perl, for example.

    Juergen
  21. J2EE != EJB[ Go to top ]

    So simple to setup - just unzip, change 1 or 2 config settings, and off you go...


    It sounds like an Intranet site with low load and no security requirements administered by developers in the company without strict IT installation policies.

    I'd love to work in such an environment, a paradise :)
  22. J2EE != EJB[ Go to top ]

    <Argyn>
    It sounds like an Intranet site with low load and no security requirements administered by developers in the company without strict IT installation policies.
    </Argyn>

    Actually, we do far more Internet than Intranet sites. In either case, many configuration issues can be handled by preparing a suitable Tomcat server.xml resp. resin.conf and adapting it on location.

    But that's not what I was talking about in the first place: I meant that setting up the web app server itself comes down to unzipping and changing a few settings in a config file, right after installing a JDK on a blank OS. Unfortunately this cannot be considered usual in the app server space!

    Of course, setup of web applications and necessary security settings take additional time. But this is straightforward too and can be dealt with in very few simple config files with easily manageable documentation. With MySQL, database setup is a breeze too, but that's a different topic.

    Things can get a bit harder when XA-capable resources are involved, as this means manually adding Tyrex to the Tomcat installation and setting it up. In this area, Tomcat's documentation resources are rather scarce. But such a setup can be prepared too, when figured out once.

    I don't want to oversimplify things. Complex requirements will lead to complex setups, and integrated full-blown app servers definitely have their place. But rather simple requirements don't require complex setups, if you choose the right tools.

    Juergen
  23. J2EE != EJB[ Go to top ]

    Jürgen, I agree absolutely. BTW, I use exaclty the same environment you do and I like it very much. I also think there are very valid reasons to use EJB (or "full blown J2EE servers") in various cases.
  24. J2EE != EJB[ Go to top ]

    I think we all agree. I didn't say "EJB sucks"--my point was that there is a lot of value in J2EE without EJB. EJB has both advantages and disadvantages, so we shouldn't automatically use it unless it helps us solve problems that would result in greater complexity if tackled without EJB. The Pet Store--unduly complicated and with very poor performance--illustrates the danger of using EJB inappropriately. On the other hand, it's nearly always wrong to hand-roll RMI frameworks etc. when EJB does a better job out of the box.
  25. J2EE Year in Review[ Go to top ]

    It seems to me that Java developers would be looking to extend functionality of their J2EE applications by taking advantage of new Web Services specifications, such as BPEL4WS.

    Cheers.

    Jill.
  26. The release of Rod Johnson's book: "J2EE Design and Development" and the framework it contains. By far, it is the best book I have ever read on J2EE and how it can fit in real-life environments. A great little helper to put back focus on deliverables rather than on technology.

    I placed a bet with a friend here that the framework it contains will be as successful as Struts in a year from now! You've heard it first! :))

    It's worth a review of its own here. Time to revamp your web site Rod!

                    Yann