Is Your Application Server Ready for 2002?

Discussions

News: Is Your Application Server Ready for 2002?

  1. Is Your Application Server Ready for 2002? (14 messages)

    While the application server market has thus far been concerned with incorporating basic J2EE functionality in application server products, new end-user requirements are driving the marketplace to new levels of maturity and creating a new high-end segment of application servers. A new article takes a look at the changing face of the appserver market.

    Read Is Your Application Server Ready for 2002?.

  2. Of late, one can lot of application servers coming in the market. And, the existing ones are coming up with the latest versions. On the specifications side, J2EE has new EJB 2.0, JCA taking its shape, etc. Definitely, there's lot of things happening on the development side.

    But, I find there's not much of statistics available, as to who is adopting all these. There might be too many features offered by Pramati or Websphere or Weblogic. Who's implementing all these? You can't keep producing things, unless its consumed.

    Now, you can see the claims as to who first certified in the J2EE1.3. And, as it is known, Java will come up again with 1.4 release and later 1.5 release and 1.6.. and so on within very short span of time. And, again Pramati, IBM, Bea will fight for the slot.

    Its become little bore about the constant changes happening on the development and specifications side without matching the adoption by the companies.

    Java (or JCP) should atleast hold on the newer releases for a year or so to put together all the pieces which did not feature in the earlier versions/releases. Otherwise, this trend will take nowhere.
  3. I agree your points, from developer and real-world perspectives. However, with a competing platform out there(.Net), Java world cannot stop publishing new specs,visions,features etc. , just to show "We are better".
    And to be honest, I like new features:-) and most businessman do like new features.
  4. It is not that I don't like Java. In fact, I currently work on Java integration projects. And, I appreciate Java for easing the integration process. Only thing I don't like is Java coming out with new features every other day and there are vendors who immediately try to implement those features. Take the example of JCA - its not so easy for JCP to come out with a framework which will fit all ERPs. ERPs are not end-products by itself. What I mean is, there needs a lot of customization for each customer. How does JCA address these issues. And, vendors going in JCA support in their application servers at this point of time seems to be too early. Instead, JCA can come out as a comprehensive release, with very little change to be done in future releases. This is what I meant. Otherwise, I'm a big fan of JAVA.
  5. Might be going slightly off topic here on this one but the real problem for me here is the breadth of J2EE. It’s now so large that for any given problem there are several different, often immature, ways that we can address the issue. One can argue that it’s always been this way but I believe it cripples our productivity. Sit 10 of us down to architect anything and we could spend a week knocking wholes in each other entirely within J2EE (EJB v JDO…. Servlets and templates, v JSP, v JSP/Struts etc.). The constant additions to J2EE don’t make this any easier.

    When I speak to my “friends” in the Microsoft community some of this sort of stuff is lost on them. They simply listen to the latest message and go with that. It’s easy to criticise this sort of behaviour but of course it does save them the time spent on debate. In the end a good implementation of a bad idea can beat a bad implementation of a good one. Since the “open” development of J2EE is entirely different to the way MS will do .NET there is always going to be a little less focus. Nevertheless I would argue that there should be an effort spent on rationalising J2EE and deprecating stuff where “better” techniques now exist. Of course we’ll all argue over what should be got rid of, but to some extent it wouldn’t matter to end user productivity if we lost the wrong ones.



  6. Quentin,

      Very well said!. Your two paragraphs are as succinct a description of the status quo of J2EE Application development that I have read. Off topic? may be, but you've hit a real-issue squarely on the head IMHO.

    Thanks
  7. I am quite happy by the way J2EE technology is evolving. we have a wide variety of choices to select from e.g. JSP, Setvlets, JDO, JDBC, EJB, JCA depending on our need. They are necessary for an solid enterprise platform. As we see that most of the specification is coming for integration with other platforms such as databases, mainframes, ERPs etc and to cope with evolving internet standards e.g. XML and Web services and they are really required. This is also a step towards platform independence and avoid vendor lock in. This helps competition between different vendors and customer satisfaction.
  8. I think you are right. ERP/SCM are not end products.
    It is easier to come out with an JCA api, however it is not so easy with RAR implementation due to large amount of customization, unless ERP/SCM vendor are going to provide a RAR per client. In my opinion, EIS complicated like ERP are too difficult to integrate from a manipulation(driver-level) approach. Perhaps only messaging approach that forms the input-output of an ERP system/module is more ideal and realistic. Oops, I`m offtopic, however, how do you think?
  9. Raghavendra: "On the specifications side, J2EE has new EJB 2.0, JCA taking its shape, etc. ... Who's implementing all these?"

    JCA is the "right" approach. It's looking at what's missing across the board and creating an "umbrella" under which existing standards (like JDBC and hopefully JMS) will migrate, tying everything into JTA for example. That's why we're adopting JCA quite early -- it lets us integrate tightly with the application server's transaction manager, or whatever TP/TM is driving the application server.

    I don't like everything about these specs at a technical level -- no one likes *everything* about them -- but once it is a spec, we can stop arguing about the pros and cons of the specs and start making things work better together by meeting the specs ... all in all, it's the right direction.

    Regarding the comments about Microsoft, it's always alot easier to derive the specs from a working product that doesn't have to work with anything else than it is to design the spec up front that will tie multiple existing (and yet to be existing) technologies and products together. Obviously you get faster time-to-market and tighter integration (only to other Microsoft products) when things like specs don't get in the way, but OTOH there is more value in a larger community of technologies, standards, products, and obviously customers ... and that is the true value and the undeniably overwhelming benefit of J2EE.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  10. Cameron,

    With regard to Microsoft/Java you are of course absolutely right. What I was trying to say was that with MS, developers have the “unfair” advantage of the “right” answers being dictated to them.

    For us we have to work that out for ourselves. J2EE to my mind is now mature enough that we are not always adding totally new stuff to it. We are sometimes coming up with better ways of doing existing things. In that case there is an argument to start removing stuff or making it clear that this is no longer considered the way to do things.

    I am old enough to remember deprecated features of FORTRAN. When I wrote code with a deprecated feature I was totally conscious that there really was an agreed better way of doing it (by ANSI that is). In any argument with my colleagues my code would of course be torn to shreds by the use of deprecated features. For J2EE we just keep on adding stuff and arguing amongst ourselves which of the stuff in there is the best. Perhaps formally deprecating some of the stuff in J2EE would help us all get along a little more.
  11. This is really true. We need to depreacte some of the stuff in J2EE. This will help us to concentrate on the Business requirements instead of just finding which kind of arch., we need to use and which is not. I think, with every release of new spec., there should be a need to totally deprecate some of the stuff which is normally not much appriciated by the community/companies. Every day, every one is caliming their app server supports these many number of features. There are doing their job in implementing the stuff. With hundreds of options, selecting or debating (of course.. up to some extenet this is a good culture).. we need to limit this. With MS Products, Blindly u can develp some solutions with out much spending time on debates.
    In our world also, we need to keep mostly appriciated and worked out options instead of keepadding every day with new JSRS or new stuff.
  12. What portions of J2EE do you think need to be deprecated?
  13. Why do we have both servlets and JSPs? Bringing up JDO is unfair but why do we have both CMP and BMP? I think part of the answer to these questions is history. I am perfectly aware that choosing Servlets over JSPs or JSPs over Servlets would not really be practical currently. However for such an important aspect of J2EE would we really come up with both if we were starting again? The reality is that I am not suggesting the Java community pay any attention to my choices of areas where there is overlap. All I am saying is that those who spend time greatly enriching J2EE might also take a little time to simplify and clarify it also.
  14. Ummm ... about servlets and JSP. I don't think you can get rid of the JSP spec. because it is valuable as a simple tool to allow a reasonable separation of duties between coders and HTML designers. But the fact that they haven't met with universal approval (I'm thinking of the Cocoon and Velocity (and Tea and Webmacro &c, &c, &c) crowds here) indicates some short comings. And you can't ax servlets because they do so much more than HTML.
  15. I think u are dead right when u say that new specs should be released with enuff time given for developers or architects to get a hang of the earlier one. The rate at which these specs keep getting churned out makes it very tiring and tedious for developers to keep adapting their design strategies to the newer specs. By the time u have studied and implemented one design aspect from a particular spec, there is another one out in the market and everyone is suddenly talking abt the new one , weather he/she has understood the new spec in its entirety or not. I guess all this is gonna leave a lotta people stranded in terms of understanding technology, 'cos what will eventually happen is that people will only talk abt newer designs and technologies without really taking the pains to test them out or implement them.