Discussions

News: The Future of EJBs: Are tools catching up?

  1. The Future of EJBs: Are tools catching up? (87 messages)

    As the EJB specification, and server implementations mature, we are finally seeing the growth of tools. A new article on TheServerSide addresses the maturity of EJB from our perspective as EJB developers, including: What development tasks we have to do, how IDE's can help, and what other tools are out there.

    Read Future of EJBs: Tools are finally catching up?.

    Feel free to discuss this article here.

    Threaded Messages (87)

  2. We just finished rolling out phase I of our first J2EE project so I speak from practical experience. We used VisualAge for Java as the Java tool and Websphere as the J2EE container.

    It was *really* tough getting started. J2EE is a great platform but we spent 4 weeks just reading books and pouring over TheServerSide forums trying to "get it". It was really, really tough and I've got 18 years of development experience.

    The other nasty part was dealing with the container (Websphere). Figuring out how to 1) Configure it 2) Deploy to it - just about drove us crazy.


    The tools have a LONG way to go. There is just too much to figure out. I guess the problem in the nutshell is that there is no **guidance** from any of the tools about how to 1) Architect the system 2) Pull it all together.

    In all other paradigms I have programmed in, there was an immediate framework and context from which to begin working in. Not so with J2EE. It's like Sun pulled up to a vacant log and dumped a mountain of lumber, nails, and woodworking equipment and then yelled as they were driving away, "Please build a house". We just didn't know where to start.

    The average programmer probably would just give up.
  3. ...and while we're on the subject (may not be the appropriate place though),,, I am deeply indebted to Floyd for his Value Object pattern. You have no idea how many miles I got out of that Floyd! It is a crucial centerpiece of what we just did.

    I knew we needed someway of "trucking" data from the backend to the frontend but didn't know what we needed. We needed Value Objects.

    God bless Floyd!
  4. Hey Dave,

      As much as I would love to take credit for the Value Object/Data Transfer Object patterns, I didn't invent them, I just wrote it up all nicely in my book. :)

      Glad you found it useful though!

    Floyd
  5. Your experience is not an uncommon one. I completely agree with you.

    Tools are often an after-thought in the industry, but they really can make the difference. Microsoft focuses heavily on the tools. If a developer can get up and running, working with the technology, you have already won a battle. Does it matter if "your technology" is really more elegant under the hood? Not to everyone.

    We have a long way to go, but hopefully we will get there!
    EJB really is still a new technology.
  6. Dave Miller is right - and he's wrong!

    I did a POC project last fall with EJB's and have been doing evaluations on Application server products recently. The POC I did with BEA Weblogic last fall was shockingly difficult. More recently I've had horrible experiences with Sybase EAServer 4.0 and HP Bluestone 7.3.

    But it seems these tools are on the cusp of some major improvement, particularly when considered in conjunction with integrated IDE's. When one uses PowerJ (the Sybase IDE) most of the nasty corners of developing EAServer are hidden from the developer. Recent reports of HP Bluestone 8.0 sound very promising, and I was impressed with the little I've seen of Oracle 9i AS version 2.

    In short, I think things are going to be a lot easier from here on in....
  7. I think that Dave Miller is right on the money. It is challenging to get going with J2EE. That is in fact one of the reasons why we started The Middleware Company--to shave months off development cycles by getting people productive today.

    I urge you all to consider training rather than just browsing TheServerSide.com or reading books. The time and money invested in training is only a drop in the bucket compared to the total cost of ownership of a project.

    -Ed Roman
    edro@middleware-company.com
    www.middleware-company.com
  8. Ed Roman writes|:

    >> I think that Dave Miller is right on the money. It is challenging to get going with J2EE. That is in fact one of the reasons why we started The Middleware Company--to shave months off development cycles by getting people productive today. <
    I think that the specific point Dave made, which was that the deployment tools need a lot of work remains true but is less true than it was as little as 2 months ago. The architectural part of your argument remains as strong a point as ever. How to design systems to make the best use of EJB Containers is an important problem.

    What DOES seem to be going away is the 'How do I configure the "£^%&£! deployment descriptors (and compile the stubs and skeletons) to make the flaming thing WORK issue......

    Which is the whole point of the thread I submit.....

    Ed again:

    >> I urge you all to consider training rather than just browsing TheServerSide.com or reading books. The time and money invested in training is only a drop in the bucket compared to the total cost of ownership of a project. <
    From your keyboard to my management's ears. They are so busy cutting deals to have us do Tibco integration adapters that they cannot grok the meaning of stuff like messaging EJB, JMS, XLST, SOAP/Web Services, etc. Cutting the economic basis of expensive tools like the Tibco suite right out from under.....

    So I'm researching this stuff on my own time and my own resources trying to do the evangelist bit to them.....


  9. "From your keyboard to my management's ears. They are so busy cutting deals to have us do Tibco integration adapters that they cannot grok the meaning of stuff like messaging EJB, JMS, XLST, SOAP/Web Services, etc. Cutting the economic basis of expensive tools like the Tibco suite right out from under.....

    So I'm researching this stuff on my own time and my own resources trying to do the evangelist bit to them....."


    I live in that world as well. We're so busy that finding the time much less the budget for training is difficult. It's a very hard sell!
  10. The Future of EJBs: Are tools catching up?[ Go to top ]

    "It was *really* tough getting started. J2EE is a great platform but we spent 4 weeks just reading books and pouring over TheServerSide forums trying to "get it". It was really, really tough and I've got 18 years of development experience.

    The other nasty part was dealing with the container (Websphere). Figuring out how to 1) Configure it 2) Deploy to it - just about drove us crazy. "

    Holy COW! You've got to be kidding? It took about a week of reading to learn EJB. And as far as confiruging the app server... man, it sound like you guys should have chosen WebLogic!! We wrote batch files to do all that stuff in about a week.

    Remind me never to buy websphere.
  11. The Future of EJBs: Are tools catching up?[ Go to top ]

    "Holy COW! You've got to be kidding? It took about a week of reading to learn EJB. And as far as confiruging the app server... man, it sound like you guys should have chosen WebLogic!! We wrote batch files to do all that stuff in about a week."


    Tracy, we exult in your brilliance and loathe our own inadequacies.

    We await your next thought in fervent anticipation. ;-)
  12. The Future of EJBs: Are tools catching up?[ Go to top ]

    "In all other paradigms I have programmed in, there was an immediate framework and context from which to begin working in. Not so with J2EE. "

    What are you TALKING about??? There's a framework for almost everything you could possibly want to do! Just look at the different components of j2ee:

    jsp's - presentation layer, everything you need.
    ejb's - middle tier business logic - everything you need
    Java language itself - a FANTASTIC oop language -e verything you need
    jdbc - everything you could ask for for database access
    jndi - naming services

    What else do you want - for Sun to code your application for you???
  13. No Immediate Framework[ Go to top ]

    These are all low-level. When creating a couple of webapps, you'll quickly notice that there is a lot common functionality that you have to implement. Thus the many many frameworks created in the last couple of years including struts and WebObjects.
  14. The Future of EJBs: Are tools catching up?[ Go to top ]

    "The tools have a LONG way to go. There is just too much to figure out. "

    Sounds like you need VB.
  15. The Future of EJBs: Are tools catching up?[ Go to top ]

    "The average programmer probably would just give up. "

    Lol, I don't think so. I would say "the average VB programmer would just give up."
  16. It's certainly better than when I started w/ EJBs 3 years ago. Back then everyone was trying to figure out the proper granularity of entity beans. Like another poster mentioned, I was surprised that the EJB architects didn't provide a whitepaper on how they expected EJBs to be used. Even now, all of the EJBs I've seen focus more on explaining the EJB spec than talking about how and when to use EJBs. The Pet Store "demo" project is far more complex than is needed and so doesn't make a example.
  17. A few people have described how difficult J2EE is to get started on.

    No surprise. *Distributed systems are difficult to develop*. J2EE actually makes it a lot easier. Try developing a significant distributed system in C++ using CORBA and you'll know what I mean.

    J2EE actually provides an excellent framework compared to previous technologies. You get transactions, security, database access, standard configuration files, logging ... the list goes on.

    Sure, it's a steep learning curve if you're not familiar with distributed systems and enterprise design. But compared to what we had, it's fantastic.

    If you're finding it tough, get some decent training as well as reading books. I wouldn't design a million dollar system using architects who had no experience with the technology other than reading *Mastering EJB*.


  18. Once IDEs get EJB2.0 compliant, I think they will be much more useful. If you want to use the latest bleeding-edge technology, the IDEs will always have to play catch-up. That's why I think the more modular IDE platforms (such as Eclipse and Netbeans) will have the upper hand in keeping up with the contstantly moving target of code-generating functionality.

    <shrug>
    Steve
  19. Hire micro$oft[ Go to top ]

    What is wrong with Java tool (IDE) providers? Why are they so cumbersome and difficult to use. Why can't IBM, Borland, WebGain etc. learn from micro$oft? Borland use to do a good job ..they still do...but there is no comparison to the ease and increased productivity and intuitivity when it comes to using Microsoft tools. This is one reason we are loosing market share to micro$oft not.net.

    MAYBE NOW WE NEED TO HIRE micro$oft TO BUILD A GREAT JAVA TOOL
  20. Hire micro$oft[ Go to top ]

    Have you tried WSAD lately. It is extremely easy to develop for WebSphere.

    And it's easy to develop .NET with Microsoft.

    Java developers usually have portability in mind when comparing tools and give it a bad grade when it works best with the same vendors App Server. However, when comparing tools with M$, this portability issue goes out the window, it is fair to compare the features that are not portable.

    Tools like Visual Basic, COM, etc.. were always easy to develop, however, once they got into production, they failed to meet the grade. .Net has alot to prove as far as performance. Especially with the heavy dependence on XML.
  21. Hire micro$oft[ Go to top ]

     I truely agree with your argument. Everyone knows J2EE is a great server side Architecture but the fact that the very end users(Application Developer) find it difficult to use the tools to make or deploy the EJB not make sense at all.
    Its like having food infront of a hungry person but he is not able to eat it. Though we accuse MicroSoft in every respect there's great deal to learn from our them.. and that is making things "simple"...


    Prasanna Tuladhar
  22. Hire micro$oft[ Go to top ]

    "Though we accuse MicroSoft in every respect there's great deal to learn from our them.. and that is making things "simple"... "

    Sometimes simple is NOT the way to go, if there's good reason. And there is: sure, m$ apps are easy to "throw together" but that's because they are horrible end products.
  23. This is a great thread. Where we (Wakesoft) come from is a recognition that EJB/J2EE, etc. is extremely difficult both for first time users from a learning curve perspective as well as for experienced programmers from a "getting it right" perspective.

    The app server companies do a good job of implementing the specs and providing key services. What they are not good at is helping developers and architects successfully build scalable and extensible applications.

    Dave Miller makes some great points about the lack of architecture guidance and advice for "pulling it together", and he's right about the serverside being a great place for the info.

    There are whole slew of tools, platforms, frameworks, etc. that are rapidly coming to market in the J2EE space to help make companies successful with what is clearly the technology of choice for the future. When we set out building our product - the Wakesoft Architecture Server - we asked ourselves (Java architects and developers), what we needed to be successful with J2EE. We settled on a ready-to-deploy framework that was built using OO design patterns and also provided implementations of the J2EE BluePrints Design Patterns as well as other J2EE patterns out there. Developers become better developers by being exposed to these patterns and organizations get better apps by using a pre-built, tested, supported and documented framework.

    We had in mind exactly the pain that Dave M. and others in this community often voice. We're dedicated to making companies and individuals successful with J2EE.

    As this thread discusses, we all know that EJB/J2EE is tough even more the most experienced among us. We all want the technology to succeed and we're all excited to see the maturation of the tools and platforms that can insure this success.

    When you find yourselves frustrated with EJB/J2EE I urge you to take a second look around at the new tools and platforms (Wakesoft included :) ) and see what is now out there to help.

    My .02

    Harley

  24. First of all,
    I am just a junior programmer here, and most of my development experience was VB & ASP stuffs. Recently I've taught myself JSP, Servlets, and EJB, to be hornest the concept of J2ee are powerful, and the learning curve for me wasn't that bad at all. However, I spend 80% of my time for the tools configuration, and I did learn a lot too. I've tried JDeveloper IDE, and I've found that JDeveloper import their own packages into the class file, which would make the EJB bean not 100% portable, and version 3.2 doesn't support EJB2.0 so I end up using textpad to edit the code by manually which is good for learning experience. Well I think if we have some kind of tool that's pre-configure at installation time then we would be alot easier for the developer, because they don't have to spend more than half of their time to figure out how to set up the environment.

    Thanks,
    Duc
  25. The Future of EJBs: Are tools catching up?[ Go to top ]

    ". I've tried JDeveloper IDE, and I've found that JDeveloper import their own packages into the class file, which would make the EJB bean not 100% portable"

    Welcome to oracle "tools."

    Jdeveloper is a joke. I used to work for an oracle-centric company that got that ide for free so they pushed it hard. God, am I glad I don't work there anymore.
  26. The Future of EJBs: Are tools catching up?[ Go to top ]

    Tracy,

    I am just an average VB programmer here, and I have a very good background in Design concepts which I picked up while I was in school. I actually found it's harder to set up the environment to start learnning J2EE. And just to be clear I am not here to argue about VB and J2EE technologies, I am saying that people should not attitude toward any one because they're diffrent from you. And to be hornest I've found that J2EE is interest me because it's make me keep trying at it.

    Duc
  27. The Future of EJBs: Are tools catching up?[ Go to top ]

    "I am just an average VB programmer here, and I have a very good background in Design concepts which I picked up while I was in school. I actually found it's harder to set up the environment to start learnning J2EE. "

    Of course it's easier to "whip" something up in vb; I could draw it on paper too, but that doesn't get me a good solid product. Few things worth having are easy.
  28. The Future of EJBs: Are tools catching up?[ Go to top ]

    ". I've tried JDeveloper IDE, and I've found that JDeveloper import their own packages into the class file, which would make the EJB bean not 100% portable"

    Welcome to oracle "tools."

    Jdeveloper is a joke. I used to work for an oracle-centric company that got that ide for free so they pushed it hard. God, am I glad I don't work there anymore.
    -------------------------------------------------------
    I've tried the Jdeveloper 9i IDE and actually like it (other than being bloated and slow). I have had no problems at all porting my ejbs to other app servers. Only if you use oracle specific stuff does it import oracle specific class files. I use SAP DB, and it deploys like a charm - though my app server of choice is Orion - but going to JBoss and EA Server has been no problem either.
    Cheers
    Ray
  29. The Future of EJBs: Are tools catching up?[ Go to top ]

    "I've tried the Jdeveloper 9i IDE and actually like it (other than being bloated and slow). I have had no problems at all porting my ejbs to other app servers. Only if you use oracle specific stuff does it import oracle specific class files. "

    One problem though, is that using wizards they "automatically" import things fo ryou, and you have no idea what's portable and what isn't unless you know what to look for.

    JDeveloper is a joke, and shouldn't be usedin lieu of something like JBuilder, not even close.
  30. The Future of EJBs: Are tools catching up?[ Go to top ]

    "One problem though, is that using wizards they "automatically" import things fo ryou, and you have no idea what's portable and what isn't unless you know what to look for. "

    Luckily I know what to look for. And for what I do, it doesn't import extra classes - you can also control what it uses and doesn't use.

    "JDeveloper is a joke, and shouldn't be usedin lieu of something like JBuilder, not even close. "

    Actually, its not a joke at all. I can't think of an IDE that is worth a couple of grand. I don't find JBuilder worth the absurd cost for the enterprise version (if I worked at a company that had it, sure) - I can get other free tools to create entity templates and method calls. And there are certain occasions when JDeveloper fits the bill. I often just use a product like EJBCreator or Forte with J2EE API plugged in or some similar product, in combination with Ant and vi/ultra edit. I am quite productive and it doesn't cost an arm and a leg to purchase the product.

    Cheers
    Ray
  31. My two cents coming from a development environment in a non-English speaking country (Mexico)...as its obviosuly known to every reader here J2EE is a powerful concept,even though managers and executives know its underlying power, it s the developers ("in the trenches") who still lack a firm grasp on J2EE as a whole.

    As a consultant/trainer I have seen companies the "pour" money on glitsy/turn-key tools like JDeveloper or Visual Age, and developers that use them and have but the vaguest idea of what an EJB is!. From what I have seen the tools for J2EE currently available are more than enough, for the greater part of the developers...what good is an O/R mapping tool or an "Abstract Schema" generator for a developer when he can barely understand "Entity Beans"...I would still go with the old software adage: "Its the developers not the tools"..

    The ServerSide may bring out the autodidact in all of us, but you cant beat a one-one practical conversation with an expert...I may be biased on the previous note though as I am also pushing for a ServerSide/EJB Training in spanish...my self-promotion as some previous post'ers: http:/www.osmsosislatina.com/index.in.htm
  32. Focus[ Go to top ]

    Recently I was told about TogetherSoft, which IMO is the kind of tool the industry _really_ needs: design-tools.

    I believe that the greatest power EJB has to offer is its concept: on the one side you have your domain entities, course-grained modelled with Entity Beans, and on the other side, you have Session Beans, consolidating the use-cases.

    This allows us to keep our focus on the design of the application. As written in "Design & Use of Software Architectures", by J. Bosch, an explicit defined software-architecture alows an early assessment of the quality attributes of the SW-system.

    In this way, the real value of the application-implementation can be assessed without wasting precious time and effort on writing code of a product the customers didn't ask for.

    The art is in the design. The design is where you address the customers requirements. As I see it, this is what EJB is all about...

    With this view on EJB, I am currently writing a thesis (http://win-www.uia.ac.be/~s985012/thesis/ provisionally in dutch) which assesses the value of EJB on three issues:
     - flexibility through changing requirements
     - development time
     - reuse
  33. Well, I think there are really good tools for EJB 1.1 development out there, I know WSAD, JBuilder and TogetherSoft (though I only used the first for a short time).
    When it comes to EJB 2 development things are looking much worse though...
    *) The tool I think is currently best is JBuilder (6) though it still has so many glitches and bugs regarding EJB2 development it cannot be used "seriously"; Still, it is IMO the best you can get at the moment
    *) Together/CC is second... but also here: There are so many bugs, serious bugs; Its not that some things simply don't work and you have to do them manually, no, it destroys your work...
    *) All other IDEs have no EJB2 capabilities as far as I know...

    It seems companies (IBM, Borland, ...) were more concerned getting a good J2EE 1.3 AppServer and "forgot" to update their tools... currently I think if you want to develop EJB2 the only way is really coding by hand and using the J2EE RI DeployTool to generate the DDs :-(

    regards

    Messi
  34. Messi,

    Have you tried XDoclet? It will do all the grunt job for you, and without much pain too.

    It's what I use myself :-) Don't need much more. Except Ant of course.

    /Rickard

  35. Thanks for mentioning it Rickard! You rock!

    As I was reading through the above *painful* comments on J2EE IDE tools, I couldn't help but wonder about the contents of my own toolbox: XDoclet, Ant, JBoss w/ Tomcat or Jetty. I get by with the latest Netbeans IDE for code editing and it all it has to do is integrate with Ant and CVS nicely (and it does). It all works so well together and I can't believe I'm not being as productive as someone in a enterprise IDE.

    Alas, I've never tried a so-called enterprise version Java IDE. They have been prohibitively costly -- even for smaller companies. I'd be keen to compare them (or see a comparison of them) against with my toolbox though.
  36. The Future of EJBs: Are tools catching up?[ Go to top ]

    "Alas, I've never tried a so-called enterprise version Java IDE. They have been prohibitively costly -- even for smaller companies. "

    It seems like they would be MORE prohibitively costly for smaller companies.

    Anyway, I agree with you, they're very expensive. But if you can't afford them, work with what you have. And I think instead of using netbeans, I'd use free JBuilder first.
  37. Hi Matthew,

    Matthew: "Alas, I've never tried a so-called enterprise version Java IDE. They have been prohibitively costly ..."

    I'd rather give up a $100k engineer than give up a good set of tools and a small team that actually knows what they're doing. Good tools are not expensive when you consider what it costs you to _not_ have the right ones.

    Peace,

    Cameron.
  38. Cameron:
    "I'd rather give up a $100k engineer than give up a good set of tools and a small team that actually knows what they're doing. Good tools are not expensive when you consider what it costs you to _not_ have the right ones. "
    --------------------------------------------------------
    On the other hand, the most expensive tools are not always the best be it an IDE, app server or what-have-you. The team is the key. If you give a bad team expensive software, they are still going to fail. If you give a good team cheap software, they will still have a reasonable chance of succeeding.
  39. Rickard,

    Sorry for the late reply, but I dislike XDoclet too because (as I understand it) you put your DD/remote interfaces inside the bean class via javadoc comments... Hmm, don't like this approach ;-)
    Mainly because I don't see any need for this, Together is able to display my classes with relationships etc., so what _I_ want is a graphical design tool for EJB2 (which should be easier than for simple Java classes because of the more "formalized" approach) like JBuilder 6 has; But though I think (and as I said) JBuilder 6 is the "most advanced" tool the designer simply has too many bugs and is very close to useless because of it. Same with Together (hell, I cannot select a different EJB 2.0 Entity Bean field!!! It won't display its properties. Besides it is soooo slow... I wonder how _this_ could slip through QA... or was it released though they knew? Never, if you ask me ;-).
    Its also simply ridiculous generating this monster of DD for EJB 2.0, the IDE has all the info to do it, and still cannot do it.
    Okay, enough of this ;-) Just wanted to say I don't really like the approach of XDoclet.

    regards,

    Messi
  40. Well, you don't *have* to use XDoclet for everything if you don't want to. If you want to write the DD yourself, then go ahead. If you want to wrote the remote interface yourself, then go ahead. XDoclet can do as much or little as you want, and what is actually generated can be tweaked since the output is template based. And even if you choose to use XDoclet to do the DD there are so called "merge points" in the templates that allow you to integrate static portions of the DD with that which is dynamically generated.

    /Rickard
  41. Are tools catching up?[ Go to top ]

    Hi there,

    talking of tools, here is one you could look at... a few ideas that have been put in place include:

    support for all the tasks mentioned by Dion in his article & more

    completely standards compliant (no proprietary code) IDE thats fully supports J2EE 1.3/ EJB 2.0 (including CMR, MDB etc.)

    built specifically for J2EE development with no baggage of pure Java development

    Integrated for development & deployment on Weblogic 6.1, Oracle 9Ais & Pramati Server (automatic generation of vendor specific XMLs)

    Do try it out and provide your comments/ thoughts: Pramati Studio 3.0 @ http://www.pramati.com/products/index.htm

    s c
  42. My team has finished writing the only (that we know of) J2EE-based account aggregation system and we all feel that the entire process was made less complicated and tedious with the help of the likes of EJB, JMS, EJB-QL,JCE, weblogic 6 etc. This is a fact which even a leading global competitor privately admitted to us. Getting ready to launch by the end of this month, the only hiccups we have had so far are vendor specific, meaning the guys at BEA will do the running instead of us. Thats the beauty of using weblogic as opposed to an open-source server.

    EJB as a technology has a lot to offer but due to its continous transformation, it is very difficult for tools to catch with its capabilities. We used JBuilder 6 to write the code and to be quite frank, if only it did not momentarily crash too often, i would have had no complaints.However, to compile the EJBs, we had no choice but to use ejbc provided by weblogic.

    Wish us luck with our launch....

    Eric Khosa
  43. The Future of EJBs: Are tools catching up?[ Go to top ]

    "Getting ready to launch by the end of this month, the only hiccups we have had so far are vendor specific, meaning the guys at BEA will do the running instead of us. Thats the beauty of using weblogic as opposed to an open-source server. "

    I agree. WebLogic's support is second-to-none. And the product is proven and stable. We've had few little problems with it at all. Overall, we love it. We don't use jbuilder for the bean development, we wrote batch files for all that stuff that you want to do once and "never think about again" and it works fantastic. Very fast, very easy.
  44. The Future of EJBs: Are tools catching up?[ Go to top ]

    Batch files are useful. I think that ant scripts are even better, and more portable (in the past I installed cygwin on windows and used "unix scripts" on both a windows dev box, and Unix production servers).

    However, there are some tasks that tools are great for. After using a good O/R tool, it is hard to go back to manually working with relationships. Having a GUI that hooks up to the DB and visually drawing the relationships is much more powerful and productive IMO.

    WebLogic is a great server, however they spend no time on tools (claiming that WebGain is there for that). The old GUIs were awful, and the Web Console isn't exactly brilliant. The other thing that bugs me about WLS is that there are always stupid bugs in it, and the service packs that come out always break other things ;)
  45. The Future of EJBs: Are tools catching up?[ Go to top ]

    "The other thing that bugs me about WLS is that there are always stupid bugs in it, and the service packs that come out always break other things ;) "

    No argument on that... I've had to revert back once.

    Regarding batch files, again, stuff like deploying, bouncing servers, compiling etc. is NOT what I want to spend my time on. So, I write some kind of script and do that crap once. I'm not sure what the big deal is, we downloaded weblogic after purchasing it, wrote some scripts and in about 2 weeks had everything pretty much under control, including the setting up of a cvs repository along with JBuilder enterprise (ok, yes, JB was expensive). Why the whining?

    And regarding building j2ee apps, the biggest complaint I have isn't that it's hard to understand; to me, if you know Java, reading about the technology and api and looking at some examples is all you need; the concept is fairly simple, I mean, after all there are only four types of beans!

    If there is acomplaint I have, it's that the overhead that comes with EJB's is basically enormous. But with computers getting faster and faster, the pure ideology will become feasible. Right now though, I have to combine entity beans with a framework to extract out the non-transactional read-only features with factorys and data models in order to satisfy performance needs, because 80% of all database access is read-only, esp. on websites. That seems to have worked very well, and judging from what I've seen, doing it this way is probably about 15x faster than using even read-only entity beans.

  46. The Future of EJBs: Are tools catching up?[ Go to top ]

    Sure you can build batch files to do things like bouncing servers. But what about complex CMP relationship modelling?
    I don't think that "we" should have to look at the damn XML descriptors at all. A nice tool should be able to build the descriptors.

    When using JBuilder, I said I wanted x session beans, y entities and configured them (including connecting to the DB to link the entities). Then test clients were created to test these components for me. I now right click on the EJB group and tell it to "Run" and an EJB container is started with the beans deployed. I can now run and debug these via the test clients. I feel that this is productive.
  47. The Future of EJBs: Are tools catching up?[ Go to top ]

    "When using JBuilder, I said I wanted x session beans, y entities and configured them (including connecting to the DB to link the entities). Then test clients were created to test these components for me. I now right click on the EJB group and tell it to "Run" and an EJB container is started with the beans deployed. I can now run and debug these via the test clients. I feel that this is productive. "

    I'm not sure what your point is. I can copy an xml description and paste it into however many directies I want to. I can create one ejb and inherit all its comonalities and change very little. I can click on a batch file to package up a bean and deploy it, then I'm ready to test it. I feel, and know, that is very productive; just a few clicks and I'm done.
  48. The Future of EJBs: Are tools catching up?[ Go to top ]

    I guess some people like an IDE approach, and some like a more "getting in there" approach. I think there is room for both. When you get a complicated large set of EJBs, the XML descriptor gets a little unweildy *for me*. I prefer not having to deal with it at all. This is one reason that I really love XDoclet (or EJBGen). I like being able to work with an EJB in one area... in this case the bean class itself. XDoclet will kindly create the interfaces, deployment descriptors, and more, for me.
  49. The Future of EJBs: Are tools catching up?[ Go to top ]

    "I guess some people like an IDE approach, and some like a more "getting in there" approach. "

    Agreed, still I can't figure out where all the work is coming from that you guys are complaining about so much. Copy-and-past works real nice. MOst of the ejb's we have are fairly boiler-plate and the smarts is in the code, where we use good oop techniques and really don't have to code very much at all, just a datamodel class. That's IT, then we're done. I could whip up and entity bean for a table in about 20min that would perform and scale very well, and present its model to the outside world keeping with the 3-tier architecture. Take care
  50. The Future of EJBs: Are tools catching up?[ Go to top ]

    Tracy writes:

    >> Copy-and-past works real nice. <
    Ah, but you are keeping it simple (re your comment about sticking with Weblogic 5.1)!

    I am very sure that things are just as you say, Tracy. Once I have a working example of a deployment it's easy for me also.

    I am a command line guy myself and prefer build scripts.

    But the documentation of deployment on some of these
    products is either nonexistant (bad) or says things which just ain't so (worse). You NEED an IDE to get the thing deployed at all in that case.

    Training? If I can pry any training funds out of the cheapskates at work, I want to use the money for that fancy EJB Architects course our hosts offer, not a braindead <App Servers> 101 'Hoe to deploy' ripoff 'course'.

    I learned on Weblogic 6.0 with the first book out, 'J2EE Applications with BEA Weblogic', which was (in a word) defective. Serially defective, from getting the license key working to the content of deployment descriptors to wrong build and deployment scripts. It was frustrating as hell.

    Today the way to go is with the O'Reilly Enterprise Javabeans book by Monson-Haefel, which has a downloadable worksheet associated with it (for Weblogic 6.1) which is a thing of beauty.

    I've been doing a comparative study of EJB container servers for my consultancy, which means I get the joy f getting used to new servers (and the 'how the devil does THIS work' experience) repeatedly. I fetched up against two of the undocumented wonders of the industry, HP Bluestone 7.3 and Sybase EAServer 4.0. Or should I say (more accurately) MISDocumented! So I've had to wipe the foam from my chin more than once.

    Sybase in particular was interesting. Missing steps and 'working examples' which plain didn't WORK! I'd get onto the support site and they'd write 'In PowerJ you.....'. PowerJ was their IDE which wasn't available at the time. Turned out the proper version wasn't even released.

    I didn't spend much time with Bluestone 7.3 (thank god).

    Ok, that was the bad news. The good news is that I've seen Sybase PowerJ IDE and it really works well with EAServer. It is utterly necessary that it do so and necessary that you have it because EAServer's deployment documentation is a ranch full of steer flatulence. To be kind.

    The word on HP Bluestone 8.0 is that it's miles ahead of 7.3 on usability. Which is good, bcause what I saw was unusable. If you have to have a Professional Services person in to show you how to make the thing run, the product is basically unusable.

  51. The Future of EJBs: Are tools catching up?[ Go to top ]

    "Training? If I can pry any training funds out of the cheapskates at work, I want to use the money for that fancy EJB Architects course our hosts offer, not a braindead <App Servers> 101 'Hoe to deploy' ripoff 'course'. "

    Exactly! Once you get the initial work done, it's pretty mundane and boiler-plate.

    Also, I learned about j2ee from sun's site and tutorial; perhaps that is the problem, people are buying books when all they needs is a few hours of html.
  52. The Future of EJBs: Are tools catching up?[ Go to top ]

    Also, I learned about j2ee from sun's site and tutorial; perhaps that is the problem, people are buying books when all they needs is a few hours of html. <

    Learning about it wasn't hard. It was getting it deployed without any help which hurt. I was on a 'deployment server of the week' plan for a while, which didn't help at all.

    I think many of our complaints about the last-generation tools derive from insufficient schedules and being under the gun and ignorant.....
  53. The Future of EJBs: Are tools catching up?[ Go to top ]

    "I think many of our complaints about the last-generation tools derive from insufficient schedules and being under the gun and ignorant..... "

    Agreed.
  54. I completely agree. Once you get more than a handful of session beans, or worse, CMP2.0, you don't really want to touch the dd xml file (100K+ in size).

    I am using XDoclet and it's fantastic for Continuous Integration.
  55. The Future of EJBs: Are tools catching up?[ Go to top ]

    "I don't think that "we" should have to look at the damn XML descriptors at all. A nice tool should be able to build the descriptors. "

    Why not? What's the negative? What's the big deal, you don't like xml?? Just click on a field or two you want to change and that's all you have to do. Again, I'm not sure what all the whining is about.
  56. The Future of EJBs: Are tools catching up?[ Go to top ]

    <quote>
    Why not? What's the negative? What's the big deal, you don't like xml?? Just click on a field or two you want to change and that's all you have to do. Again, I'm not sure what all the whining is about.
    </quote>

    Flashback. A few years ago, you saw your first XML file. You could edit it with vi, it looked so easy. You make the changes, save the file, run your software on it, which complains that you forgot a '>' at line 230. You find out that actually, you have an extra '<' at line 110.

    Annoyance.

    Then you learn about XML editors. Sweetness. No more stupid syntactic error, but next time you run the parser, it complains that element <foo> should not appear after <bar>.

    Consternation.

    Then you learn about DTD's and validating editors. Revelation ensues. You write a DTD and use a validating parser. This time, everything works fine except your tool chokes with a "'foo' is not an integer".

    Frustration.

    Then you learn about schemas. You wonder how could anyone ever live without them since DTD's are so braindead. Of course, you have DTD's all over the place, which need to be converted and modified, but it's all worth it. Then you run ejbc which complains that the EJB "Account" is referenced in ejb-jar.xml but not weblogic-ejb-jar.xml.

    Anger.

    At this point, you consider quitting your job and going to grow tomatoes in Thailand.

    Don't be fooled, XML is a binary format cleverly disguised as text. It is not meant for human consumption and anybody who says the contrary is an arrogant geek who probably knows how to write Postscript by hand and brags about it.

    --
    Cedric








  57. Thank you Cedric. You have made the point perfectly.

    "XML is a binary format cleverly disguised as text"
    is perfect .sig material :)

    Tracy, you are not necessarily "the norm". Please accept that there are different types of people out there. It is great that you are productive with copy-n-paste, but that doesn't mean everyone is. I have taught hundreds of students on EJB, and how much time has been wasted in labs, when they have something wrong with their XML descriptor? Too much.

    Cedric has succinctly described the typical annoyances that come up as you work with these files. With schema, we will have lots of rules that we can define, so it will not be "as easy" as it even is now to go in to the file and make changes. I think there is a better way. One of them is Cedric's EJBGen tool :)
    He isn't "whining", he is building a better tool for everyone :)
  58. The Future of EJBs: Are tools catching up?[ Go to top ]

    ""XML is a binary format cleverly disguised as text"


    No, it is not. It's prue text that is interpreted.
  59. The Future of EJBs: Are tools catching up?[ Go to top ]

    "Don't be fooled, XML is a binary format cleverly disguised as text. It is not meant for human consumption and anybody who says the contrary is an arrogant geek who probably knows how to write Postscript by hand and brags about it. "

    I have never, once, made a single mistake copying and pasting text into an xml descriptor file. We're not talking about a big file here guys... yes, if it were a "real" xml file that was large I could see it, but again I think people are making more than it is out of this! And the sarcasm was totally unnecessary... and silly.
  60. The Future of EJBs: Are tools catching up?[ Go to top ]

    <quote>
    And the sarcasm was totally unnecessary... and silly.
    </quote>

    Tracy, the quip was absolutely not directed at you, as I highly respect your technical skills (and wish all our customers exerted the same level of expertise). I apologize if it's how it came across.

    The very fact that you are reading this forum puts you in a very small minority of power users, but you need to be aware that most of the customers of application servers out there are not interested in dealing with such low-level details. And XML is low-level format.

    This whole thing gets aggravated by the fact that intermediate programmers who decide to tackle J2EE expect to face "high-order" problems (DB access, transactions, etc...) as opposed to such little details, and that decuples their frustration when they realize they spend most of their time fighting with XML files.

    I understand that you feel comfortable with XML if all you do is editing Weblogic 5.1 deployment descriptors, but trust me, you're in for a very harsh reality check when you upgrade to WLS 6 (not even mentioning WLS 7 with the multiple table mapping nightmare I am dealing with as we speak ;-)).

    --
    Cedric

  61. Cedric Beust writes:

    >> This whole thing gets aggravated by the fact that intermediate programmers who decide to tackle J2EE expect to face "high-order" problems (DB access, transactions, etc...) as opposed to such little details, and that decuples their frustration when they realize they spend most of their time fighting with XML files. <
    Exactly right. I wanted to learn about the tool as opposed to hacking the xml to get it to work. In my case it was actually worse because I was working with a book which was filled with bugs and incomplete explanations of how to get things working.

    >> I understand that you feel comfortable with XML if all you do is editing Weblogic 5.1 deployment descriptors, but trust me, you're in for a very harsh reality check when you upgrade to WLS 6 (not even mentioning WLS 7 with the multiple table mapping nightmare I am dealing with as we speak ;-)). <
    From his description it sounds like Tracy wasn't working with CMP beans, which aren't an easy thing to work with.

    You say WLS 7 is out and it's worse? I think BEA's decision to go with proprietary DD formats is questionable at best.

  62. The Future of EJBs: Are tools catching up?[ Go to top ]

    " In my case it was actually worse because I was working with a book which was filled with bugs and incomplete explanations of how to get things working. "

    Man, that's not good :)

    "From his description it sounds like Tracy wasn't working with CMP beans, which aren't an easy thing to work with. "

    That's correct; I refuse to work with cmp in wls 5.1 because we would have to dealv into wls' proprietary ebqj language to make them more useful than for a lookup table. We're very happy with what we've done with bmp's. ALl I have to do to throw a bmp together than performs and scales very well is define a datamodel class with the fields in it; that's it. cya
  63. <quote>
    You say WLS 7 is out and it's worse?
    </quote>

    That's absolutely not what I said. The features offered are more and more complex and require similarly complex configuration files.

    <quote>
    I think BEA's decision to go with proprietary DD formats is questionable at best.
    </quote>

    I don't get it. J2EE only specifies a very minimalistic set of deployment descriptors, application servers have no choice but offering their own complement of descriptors which features their added value.

    For example, how would you suggest an application server could offer clustering in a "J2EE portable way"?

    --
    Cedric


  64. The Future of EJBs: Are tools catching up?[ Go to top ]

    "Tracy, the quip was absolutely not directed at you, as I highly respect your technical skills (and wish all our customers exerted the same level of expertise). I apologize if it's how it came across. "

    No problem...
  65. <>> At this point, you consider quitting your job and going to grow tomatoes in Thailand. <
    LOL!

    >> Don't be fooled, XML is a binary format cleverly disguised as text. It is not meant for human consumption and anybody who says the contrary is an arrogant geek who probably knows how to write Postscript by hand and brags about it. <
    Well, it's not quite binary. Closer to reading nroff/troff files. We run into this illusion every few years. Business analysts and managers were supposed to be able to read COBOL for example.

    You were probably lucky at that, because it can get worse, much worse! Defining an XML output in XML without a parser requires that one use escape characters to define many of the most common characters. That REALLY looks like Farsi script!

    But Tracy Milburn makes a good point also. Once you have working examples of the (xml-based) deployment descriptors it is not all that difficult to hack up a new one in a text editor, particularly if you aren't trying to be too ambitious and change anything fundamental.

  66. <quote>
    But Tracy Milburn makes a good point also. Once you have working examples of the (xml-based) deployment descriptors it is not all that difficult to hack up a new one in a text editor, particularly if you aren't trying to be too ambitious and change anything fundamental.
    </quote>

    Our usability studies definitely confirm that people mostly write their XML files by copy/pasting existing ones (mostly taken from the examples we ship). But this is still very error prone because the J2EE model is very fragmented. Both

    - intra-file (need to specify beans in a section and method transactions in another one)

    - extra-file (you specify CMP fields in one file and CMP field mappings in another one)

    What does copy/pasting buy you in this case? Not much. You're going to screw up, I guarantee it.

    Now, rest assured, we are working on making these problems disappear ;-) (I much prefer eating tomatoes than growing them, if you ask me).

    --
    Cedric
  67. Cedric,

    "But this is still very error prone because the J2EE model is very fragmented. Both

    - intra-file (need to specify beans in a section and method transactions in another one)

    - extra-file (you specify CMP fields in one file and CMP field mappings in another one)"

    That's a very good point! I'm more than a little curious why these weren't specified in one file using namespaces. That seems like a much nicer option, and more "XML-ish".

    Any thoughts on that?

    /Rickard
  68. The Future of EJBs: Are tools catching up?[ Go to top ]

    "That's a very good point! I'm more than a little curious why these weren't specified in one file using namespaces. That seems like a much nicer option, and more "XML-ish".

    Any thoughts on that? "

    I agree, I have wondered that myself.
  69. <quote>
    That's a very good point! I'm more than a little curious why these weren't specified in one file using namespaces. That seems like a much nicer option, and more "XML-ish".

    Any thoughts on that?
    </quote>

    The fragmented model has virtues, and having one single file that contains all the deployment descriptors for the various application servers your application runs on doesn't seem the best idea to me either.

    Don't get me wrong: the reason why I don't like the fragmented model is because it makes application server developers' life (like myself :-)) harder. But it's still for the benefit of our customers. My point was not that this model was invalid, but just that it should only be manipulated by very specialized tools.

    But I agree that J2EE should use namespaces and other XML goodies (such as schemas instead of DTD's) more.

    --
    Cedric
  70. <Rickard>
    - intra-file (need to specify beans in a section and method transactions in another one)

    - extra-file (you specify CMP fields in one file and CMP field mappings in another one)"

    That's a very good point! I'm more than a little curious why these weren't specified in one file using namespaces. That seems like a much nicer option, and more "XML-ish".

    Any thoughts on that?
    </Rickard>

    IMHO they tried to separate deployer/assembler/developer roles and in 1999 when they were working on it they ended up creating separate sections and files. IBM in WAS4 uses XMI files, puts id attribute in all element and links to that elements from xmi files, but it ends up being complicated.

    I also think they should adapt a schema-based appraoch, with extension points in it, or even better change the bytecode format a little and put attributes right there in bytecode like .Net. So I think the best solution is to put things like transaction attributes/permissions/etc in bytecode as attributes and use deployment files only for vendor specific things. I've heard java bytecode format supports a limited form of attributes, maybe extend it a bit?

    Ara.
  71. Hi Ara,

    Java byte code not only supports a basically unlimited means of putting attributes in, it even specifies how custom ones should look. The problem, however, is that there is no runtime representation (i.e. reflection) of those attributes.

    Peace,

    Cameron.
  72. "Java byte code not only supports a basically unlimited means of putting attributes in, it even specifies how custom ones should look. The problem, however, is that there is no runtime representation (i.e. reflection) of those attributes."

    Cameron,
    We are developing a product called Jiapi (Java Instrumentation API) which can give you a load time reflection of a Java class. In fact, the project will introduce a read/write reflection API, very similar to java.lang.reflect. The differences are that, whereas Java reflection is read only and operates with classes already loaded into a virtual machine, Jiapi is read/write and it forms an in-memory object representation of a class before it is loaded into a virtual machine. This way it is possible to change the Classes bytecode without touching the code itself. We call this Java bytecode instrumentation and we have developed a framework to define specific instrumentations on top the read/write reflection API.

    The project is open source (LGPL) and hosted at Sourceforge. It is still in a very early steps, contains lots of bugs, missing features, outdated documentation etc., but still we welcome any interested developers to give feedback or join us :)
  73. Joni,

    The project is interesting. I really think we need some of the stuff Objective C had in 80's! But that's something Sun should add to the standard. I really think any serious engineeer should take a look at Apple's Objective C runtime and the webobjects framework, you'll learn a lot, they are damn great!

    Cheers,
    Ara.
  74. Hi Joni,

    We've had a fully implemented library like that since '98 -- you can see the doc online at our website: http://www.tangosol.com. See the com.tangosol.dev.assembler package. Unfortunately (depending on your point of view) we OEM it in various products, so we're not about to give it away for free. ;-)

    Peace,

    Cameron.
  75. Regarding the unreadability of XML deployment descriptors: I really agree with Cedric here (although I've generally been lucky, and I find TurboXML helps a lot...)

    I think J2EE could take a page from .NET here and start looking at "attributes" as a means of annotating the various EJB methods. This is in effect what Cedric's EJBGen utility does -- takes the javadoc-style attributes and parses them to create the necessary artifacts. And the whole reason EJBGen is such a great tool is that it keeps everything in one spot -- the source code.

    Furthermore, the whole aspect oriented programming idea is gaining steam, and we're going to probably want to do it in more complex ways. The current mainstream J2EE way of doing AOP is with these XML deployment files combined with code-generated artifacts... this just is annoying to use, and won't lend itself to further exploitation of this paradigm. Under the covers, the jBoss approach of using dynamic proxies is more in line of what .NET's doing in this area (again with a combination of attributes, though C# delegates + TransparentProxy objects are tremendously more efficient than Dynamic Proxies -- and are type safe).

    I think XML configuration files aren't all that bad, if kept simple (i.e. readable). Struts' struts-config.xml is an example of this (though even that takes a bit to get used to). For certain uses, like annotating code with special features, XML configs are definitely not appropriate.
  76. AOP is going to change the world if it kicks off :)
    I wonder which contain "author" will be first to use
    the Aspect Oriented framework? It seems to be *perfect* for straping on security, transactions, etc etc.
  77. I second the idea that XML is not human readable. Truly, it is much better then binary formats for storage, but to be sure that a change you make to an XML file won't cause problems requires you to really understand what you are doing.. It doesn't somehow remove the learning curve for understanding.

    As far as EJB's go, until the tools get better, and the actual process of using them becomes easier, in many ways they are a 20 lb sledgehammer hitting a fly.. Maybe a newspaper might work better for many projects.. Especially when you don't need many security/transaction bits. (Kinda my plug for Turbine's OR tools)


    Eric Pugh
  78. The Future of EJBs: Are tools catching up?[ Go to top ]

    "to be sure that a change you make to an XML file won't cause problems requires you to really understand what you are doing"

    Ya, like opening the xml file in internet explore.

    "As far as EJB's go, until the tools get better, and the actual process of using them becomes easier, in many ways they are a 20 lb sledgehammer hitting a fly.. "

    I agree with that statement, as seem do many other people. That's why I do things the way I do, so that I have the ability to use ejb's or not on the fly.

  79. <quote>
    Why not? What's the negative? What's the big deal, you don't like xml?? Just click on a field or two you want to change and that's all you have to do. Again, I'm not sure what all the whining is about.
    </quote>

    Then take a look at xmi files of WebSphere 4. Simply saying you hardly understand (or maybe don't understand at all!) what's going on there!! Dealing with xml files is less problem for a server like Orion, simple and effective. But when server adds new features then the dd file starts looking complicated and out of control.

    Another important issue is semantic correctness of a deployment file, the dd file is valid according to the dtd but semantically incorrect. That's what a tool should handle.

    Ara.
  80. Cedric: "Don't be fooled, XML is a binary format cleverly disguised as text. It is not meant for human consumption and anybody who says the contrary is an arrogant geek who probably knows how to write Postscript by hand and brags about it."

    I love you man!
  81. The Future of EJBs: Are tools catching up?[ Go to top ]

    "Sure you can build batch files to do things like bouncing servers. But what about complex CMP relationship modelling? "

    We're using wls 5.1 still, so we don't use cmp's. And as very as complex relationships go, I tend to use database views for that stuff, and it works exceptionally well.
  82. Hi,

    My recent J. Wiley/OMG Press book addresses the
    problems being discussed in this thread
    with an applied Model Driven Architecture
    approach (www.omg.org/mda).

    It also covers the available tool platform -- an Architectural IDE for J2EE/EJB -- that
    enhances Rose-Modeler, JBuilder etc.
    with MDA features. This may be of interest.
    For details see:

    http://www.ConvergentArchitecture.com

    ciao,
    Richard Hubert

  83. This is my first posting...ever....
    Anyway...Simply put I work with WebSphere.
    I've heard a lot of these problems....IDE's are useless, blah blah blah......

    This is my 2 cents worth:

    In my humble opnion (and don't take me the wrong way) the biggest problem is people just jumping on the J2EE band wagon like cowboys. J2EE is a complicated beast, and we haven't even started on the application servers. A company can't just say heck lets do J2EE and run WAS ....there's a whole heap more to it, the J2EE model says you should have your developers, application assemblers, administrator ...etc.... do most companies hire these people? Let alone a designer who knows his stuff???? Designers are a dime a dozen, GOOD designers are the hardest people to come by. A lot of J2EE problems are because of shitty design and coding. Most companies employ their developers to administer those App Servers...and then lets not speak about their abilities to support and scale the damn thing.... your just wasting your time. If you want to join the J2EE space hire yourself GOOD consultants who know the products inside out.....will save you countless hours of tears and frustration....and they're definately worth the money.

    As for the IDE's, I've personally used VAJ and WebSphere Studio Application Developer....WSAD is a fine product and developers are being spolied.....WSAD has everything you need ....but a new apprentice mechanic can't come in and expect to be able to know how to use the tools and fix the car just because he fixed his 10 speed racer at home with his monkey wrench.....they need a mentor.

    At the end of the day gentlemen the learning curve is steep
    so ease the pain and hire someone who knows their stuff.....if you can find them :)

    Good Luck to you all in your J2EE quest......it's hard but it's damn fun.

    if you guys don't already know IBM has a great site with lots of WebSphere stuff on ..... all the manuals are free and are written by some great people.
    http://www.redbooks.ibm.com
  84. The Future of EJBs: Are tools catching up?[ Go to top ]

    Your post seemed to be about nothing more than saying everyone is incompetent.

    "At the end of the day gentlemen the learning curve is steep
    so ease the pain and hire someone who knows their stuff.....if you can find them :) "

    And let me guess... that would be you?

    Yes J2EE is more complicated than, say, vb, but look at its capabilities. The sky is the limit.

  85. The Future of EJBs: Are tools catching up?[ Go to top ]

    Tracy if you read my post carefully, you would not get the sense that I'm telling everyone that they're incomptenant. In fact the opposite is true, people are not incompetant but given the scope and complexity of J2EE it is inherently difficult, and to get it right it takes considerable experience. Also sorry if you did get me wrong, but I'm sure if we were communicating face to face you wouldn't get the wrong impression.

    And your guess was right :) But no I'm not for hire, and am not looking ......but there are many people out there, training courses and books that are a great starting point in learning J2EE and app servers.

    All I'm trying to say is that J2EE and app servers are big and complex, hence they need to be approached in a sensible manner, and hiring the best people and getting the best training will pay it's dividends maybe not at the beginning but later down the track. It's like Y2K, after the many hours that was spent fixing systems we had people who had the gaul to say that it was just blown completely out of proportion and that the money spent was wasted......they'd be singing a different tune if the right people weren't hired and the systems weren't fixed and they couldn't withdraw money from the bank. But why were they fixed? Becuase it was seen as critical and they threw enough money and people to get it fixed.


    Trust me I've seen stuff go wrong, worked with many teams to fix their damn problems and have see countless $$$ wasted. Oh and not to mention people getting chewed out, given no fault of their own becuase management don't have the balls to spend some extra cash.

  86. In my experience, whatever the technology or coding approach, the only way to approach a serious project (ie. anything more meaningful than those "catalog your CD collection" projects and certainly anything involving an App. Server) is to make sure you have a solid design - well thought out, correctly modelled and flexible, enabling you to deal with those inevitable changes and implementation issues... and allowing you to make those changes fast.

    Look how many people there are who've replied to this thread saying they've tried more than one App. Server. I don't want to have to rewrite half my code just to cater for server-specific (ie. vendor-, and even version-specific) "features".

    The OMG Model Driven Architecture (MDA) is the first really complete architectural approach which will allow us all to design, implement/integrate and manage our projects - whether EJB, .NET or whatever.

    If you're looking for a way to adopt this approach, then check out ArcStyler - it's an Architectural IDE for MDA - the only platform available at the moment that supports this approach (+ EJB generation and dev. tool integration) and you can try it out for free:

    http://www.ArcStyler.com

  87. HI,
    Yeph i agree with this discussion. But i guess someone could also share their experience on the database mapping tools such as TopLink and cocobase.

    I tried using toplink and it seems to be very good. But it would be nice if someone could share their experience with respect to the features in these tools so that i /we can have a better understanding.

    Thanks for u'r help
    ~Rao
  88. You should also try Gilder, this is an IDE developed by Ensemble, it is not only IDE developer, but also a IDE user, so it is good for practical project development.