J2EE, Democracy, and Sausage

Discussions

News: J2EE, Democracy, and Sausage

  1. J2EE, Democracy, and Sausage (45 messages)

    Bill Roth, former Product Line Manager for J2EE at Sun, has published an article where he comments on common J2EE criticisms. To J2EE complexity, he responds that the specs were written for server developers not app developers. To J2EE being hard to use, he says that the tools industry was to have responded to fill this need. "The progress we've made is substantial, but we have much more work to do."

    Read J2EE, Democracy, and Sausage.

    Threaded Messages (45)

  2. A nice quick light article. Not much meat, but makes good points. Probably not convincing to those who level criticisms, but that's OK.

    Personally, I think the main criticism to make wrt J2EE is the state of development tools from vendors. Vendors focus heavily on features and add-on products ("stack" creep), but features geared towards development on their platform seem way behind where they should be. When vendors DO address this issue, it's usually bundling some horrendous and expensive IDE to their product, which really doesn't integrate well into many environments.

    EJB development, in particular, is cumbersome. Couple this with the lack of high-quality dependency analysis tools for Java, and ant, and J2EE development is years behind your average C or C++ project, in terms of tools. Even tools that support these things (like non-Sun compilers) are rarely supported by the app server vendors, so you really can't use them.

    What is needed is:

    o Advanced and CORRECT dependancy analysis of .class files that are either part of the compiler or integrate with make or ant. This should handle .jar files as well, and be EJB aware (it should be able to take an ejb jar and figure out what classes it depends on)

    o Vast improvements to ant, or a new build tool altogether. ant feels clunky and is difficult to use for development. It's a mediocre scripting language at best, and we can do better (check out http://www.a-a-p.org/ for a REAL next-gen build tool)

    o Better tools from vendors to allow complete control of hot deployment and updates to EJBs. I shouldn't have to create an EJB jar in development, ever. I should be able to update a .class file and not have to recreate stubs and skeletons if the interface didn't change. And I shouldn't have to use some GUI tool to do it.

    Not to be too harsh on the vendors or volunteers working on this stuff, because great strides have been made, and there's a lot of good stuff out there, these 3 things are very important to making life in J2EE easier.

    As for people who say it's too complicated, maybe it is, but that doesn't mean it's bad! A jet engine is complicated, because it is! J2EE is flexible and gives you control over most aspects of the behavior of the system you are building, so of course it will be complicated. That's why we all get paid the big bucks!
  3. When people talk about "bad things in EJBs" in my experience they mean entity beans.

    Entity beans are a bad mistake - not because what they are, but what they are used for. A mechanism for persisting a state of a component is different from a generic peristence mechanism and that's yet again different from O/R mapping mechanism. And that's what entity beans are being used for - and are entirely unsuited for.
    Java is OO language. As such, we should create our models using the OO part of the language. With EB you are severely limiting it, because you can't handle polymorphism (especially polymorphic collections) nicely and must do various ugly and inefficient things.
    Also, with persistence come things like knowing the "dirty state" of object (new, clean, update, deleted ...) for things like auditing etc. You cannot do this with EJBs easily again.

    My main complaint against all of the beans was that you had to go with "all-or-nothing". You got persistence, you got transactionality, you got remotness etc.. All of these are croscutting concerns, of which I might want to have just "some". It's not just implementing them by interceptors or what, it's the entirely different thing where I might want to mix and match. Marc F. seems to get it now with JBoss, but Sun's loath to admit mistakes (understandably. if you say that you were going to save the world and failed would you want to admit it to everyone?)

    Tools won't really help with some major common mis-uses of EBs (and trying to stop the misuse is even worse, since the misuse was originat by Sun as well..)
    I use IDEA and can create a CMP field with just a few keyboard actions. That doesn't help me with my inheritance tree at all though.
    Regards,
    Vlad
  4. Hey Vlad,
        You hit the nail on the head with that one.
  5. I think you are narrowing the problem. It's true, EJBs ARE usually an over-kill and maybe even a bit too bloated. But the discussion is the entire J2EE complexity, not just EJB. Today one has to define a descriptor file for the web module, a server-propriety descriptor file, another one for the entire application, another one for the server-propriety application (roles, users, etc). In addition, I need to manage various configuration files for the server itself usually, and I probably forgot a few. (And don't even think about saying that only the standard XML files are needed ;-))

    After doing all that stuff of course we have to start generating the JARs (probably via Ant, which means another XML file to maintain), WARs, EARs, ETC...

    Now don't get me wrong - even though it took two whole paragraphs to describe the general process, it's not that hard, and quite easy once you master it and know what you're doing. But the point is that it can be SOOOOO much easier and smoother (again, see COM+) because all of these measures can be done by the server, it doesn't need us.

    Why do we have to maintain XML files and "work hard" and not have an administration software of some sort to do it for us?
  6. Oh, b.t.w - even Meta Group says that "J2EE complexity hold platform back"

    read it right here in the TSS ;-)
  7. Unfortunately though, most of the people out there (managers and a number of developers as well) think that J2EE is spelled EJB. This is to a large extent problem caused by Sun's marketing - and I think it costs Sun in fact.

    As for J2EE complexity:
    Every platform that can do a lot will be complex. The more you want to do with your platform , the more complex it will be.
    You can do some complex things with "simple" platforms, but you're limiting the choices you can make - for example for performance tuning etc. Ask a DBA whether fine tuning up an Oracle db is easy or complex. Configuring a UNIX machine for something is complex as well (especially if you want to do a good job with the security).
    Admittedly, tools help here and there's still some way to go for the industry. But the complexity won't go away, and if you want it to, your applications will suffer. I think the main difference here is between _hiding_ complexity and _managing_ complexity, a distinction I don't see to often.
    Regards,
    Vlad
  8. But the point is that it can be SOOOOO much easier and

    >> smoother (again, see COM+)

    Ah yes, so much easier.

    You now not only have to worry about what dlls are in the path, you have to worry about where they were registered. And if you move them, then you have to remember to unregister them, before trying to re-register them again. When the component runs, you are not quite sure if it is running in the working directory of MTS - or if it is in the same directory as the DLL (you have to write code to specifically determine this before you can load config files etc).
    Then, when you built your DLL, you had to worry about making sure you set up binary compatibility checking (ActiveX). If you forgot to do this, nothing will work, and you wont be quite sure why (the registry entries will differ, should you go do a visual comparison).
    Then, once you have ticked all the check boxes (a manual, error-prone process), and it doesnt work, you are left in the dark. There is no logging (unless you are lucky and you get some message in the event viewer like "error 0xoac674" or, equally usefull "could not load dll".
    Once you get the DLL deployed, then you have to create a "package" and copy that to a floppy so you can take it to the client machine (IIS?) on the other side of the firewall and "install" it. Should you re-deploy your DLL, or break binary compatibility, then you have to repeat that process.
    Then you have to make sure you set up the IIS correctly, or you will get useful errors like "permission denied" (permission to do what? - createObject? make a DCOM call? what?). You have to look at what permissions the IIS user account has, what the application protection level is...
    Should you, by some miracle, happen to make a successful call, then you have to worry about what threading model you should use...
    All this to deploy just one component.

    Yes, I long for that kind of simplicity.

    I will stick to dropping my zipped class/xml files (EAR) in the "applications" directory, thanks.

    -Nick
  9. Thanks Nick,
    you spoke from my heart - COM+ looks easy first but when you start some real work it get's really complicated. That's why Microsoft gave it up - .NET replaces COM+ because of its severe limitations.
    (Have done several big MS projects - no longing back)
    -Walter
  10. I'm afraid you're both quite wrong here. I'm not sure when was the last time you've developed for the MS platform, but the previous project I've led, which used Microsoft DNA (IIS, COM+ written in VB, Oracle DB) was nothing close to the complexity you've described. I think you must be referring to the NT 4.0 days of server development - well with that I can agree ;-)

    Anyway, about .NET replacing COM+ - that's not true by a long shot. In fact, COM+ is the only component except IIS that will NOT be replaced by .NET, but rather complement it. That's the only way Microsoft has been able to provide backward compatibility with legacy Web applications built with COM.

    Now, I'm not saying developing with Microsoft was a joyride - we definitly had problems, and yes - indeed sometimes you have to dwelve in Regedit and search for that damn GUID. I do the same today in J2EE, only with a dozen configuration files scattered across different product installations on my network. In summery, having led projects both in J2EE and MS, I can testify surely that J2EE is both harder to learn (well maybe not harded, just more to learn) and less user-friendly.

    Ofcourse not all is black, and J2EE is a wonderful platform (much better, if measured by quality, than DNA or .NET) and if only we've improved and simplified our servers and development tools, I feel we'de be on the right track.

    B.t.w - I'm in no way a Microsoft employee, or even a Microsoft fan (on the contrary) - these are just my two cents.
  11. Sorry about that - the reply was for Nick's post ;-)
  12. COM+ isn't dead yet[ Go to top ]

    It's a bit of a simplification to say that ".NET replaces COM+". It's probably more accurate to say that the .NET solution for COM+ is not available. COM+ is still the mechanism for handling server side XA style transactions. .NET has helped simplify it to a degree by providing an EnterpriseServices namespace, which is used to create COM+ components. .NET has a new mechanism for communicating with remote objects called remoting (which makes use of 'standard' transports such as HTTP And TCP as well as formatters such as SOAP and their own proprietary binary format, which I suspect in the future will be integrated with COM+.

    In otherwords COM+ isn't dead - yet. If you want XA style transactions across multiple database resources, COM+ is still the way to go in the MS world.

    (btw I'm not a MS proponent, I do work daily with both MS/COM+ and Java/J2EE and deal with integration issues on both sides of the fence)
  13. Nick,

    Yes, we all can understand that it's been a looong time since you did any programming in the MS world.

    But the point is that in the .NET world, you do not have it as default as you need the while enchilada (transactionality, remoteness etc) in every little project.

    EJB is not all that bad really --it is the ridicule overuse of EJB that are killing the cat--
     
    Vic Cekvenich:"Someone on the team, such as the team lead, must know SQL well in order to have a scalable application"

    Exactly. Instead of young inexperienced programmers which turn out tons of auto generated code of which they understand nothing.

    Bill Roth: "EJB were written for (and by) the systems software architects at the roughly 80 companies in the world that build enterprise-class transactional software"

    Hmm..

    <Q>Once in a while you receive some bureaucratic paper written in an almost impossible to understand hogwash. A sign of insecurity in the authors, compensating for some inferiority complex</Q>

    Reminds me of J2EE for some reason.

    Regards
    Rolf Tollerud
  14. Bill Roth: "EJB were written for (and by) the systems

    > software architects at the roughly 80 companies in the
    > world that build enterprise-class transactional software"

    > Hmm..

    > <Q>Once in a while you receive some bureaucratic paper
    > written in an almost impossible to understand hogwash. A
    > sign of insecurity in the authors, compensating for some
    > inferiority complex</Q>

    > Reminds me of J2EE for some reason.

    I have to disagree with both you and Roth on this point, in my experience the J2EE specs are not hard to understand, though I can only vouch for the Servlets, JSP, EJB, JMS, and JSTL specs. Maybe you could give an example of some of the JCP specifications that you dont like, perhaps even with examples of the "impossible to understand hogwash" that you have found in them?

    > But the point is that in the .NET world, you do not have
    > it as default as you need the while enchilada
    > (transactionality, remoteness etc) in every little
    > project.

    Believe me, it is possible to create good applications using just the pieces if J2EE that is appropriate. I have deployed applications built only on servlets and JSP in containers that support EJB´s, JMS and whatever. Just because it is there you dont HAVE to use it. My car has a cruise control - I dont mind that its there - I had to pay for it when I bought the car - but I never use it...I have learned to live with that though.

    > Instead of young inexperienced programmers which turn out
    > tons of auto generated code of which they understand
    > nothing.

    Ironically this sounds like the typical stereotype of a VB programmer, and for tons of auto generated code look no further than MFC, right?

    Br - Johan
  15. <Rolf>
    But the point is that in the .NET world, you do not have it as default as you need the while enchilada (transactionality, remoteness etc) in every little project.
    </Rolf>

    Not entirely sure what you mean by this, but if you are saying that J2EE projects require the whole enchilade - you are flat out mistaken. J2EE is very a la carte. You *can* have everything, but you only *have* to pick and choose what is needed (JSP + Servlets + EJB w/o remoting, JSP only, EJB only, JMS only, etc).

    <Rolf>
    Instead of young inexperienced programmers which turn out tons of auto generated code of which they understand nothing.
    </Rolf>

    Who are you referring to here? This sounds more like VB/PowerBuilder/Oracle Forms developers.

    Ryan
  16. Yes, we all can understand that it's been a looong time

    >> since you did any programming in the MS world

    More recent than you think. I have never done very much of it, thank goodness.

    -Nick
  17. "...Vast improvements to ant, or a new build tool altogether. ant feels clunky and is difficult to use for development. It's a mediocre scripting language at best, and we can do better (check out http://www.a-a-p.org/ for a REAL next-gen build tool)..."

    Have to disagree with you there. ANT is one of the coolest dev tools I've ever seen. ALL that functionality, out of the box, with clear and sensible XML to define the build logic.

    Unlike your suggested AAP which appears to be a make clone, at least for its build files.

    For java builds, nothing beats ANT IMHO. I'd like to know why you think it's difficult to use during development?
  18. ANT is good[ Go to top ]

    ANT isn't so bad. Think of what we used to have...Make. The clear solution for me is ANT and XDoclet or some other attribute based template/code gen tool. Once your build file is setup you rarely need to be concerned with the xml descriptors or dependent classes. "dependent" meaning that many of the classes we write are just based on a formula and depend on what is defined in another class. EJB is what most people think of here but there are many uses for XDoclet besides EJB. One example is you might auto generate Comparators for java beans using a custom XDoclet template. This reduces the need for introspection in some areas.

    Taylor
  19. EJB development, in particular, is cumbersome.

    To get your first bean going, yes. In a serious project, not really.

    >> Couple this with the lack of high-quality dependency
    >> analysis tools for Java,
    Not convinced they are as necessary now that we dont tend to build monolithic c-programs anymore.
    There are tools (free ones) like JDepend - depends what you are looking for.
    I suspect you should also look at the code inspection features in IntelliJ.

    >> and ant,
    Completely baffled by this. Ant is a cracking tool.

    However, for a really impressive build system look out for Maven (jakarta.apache.org/maven). Its nearing 1.0 release - and even now it has replaced Ant as our build system.
    (Actually, its not 100% true - its a superset of Ant - its ant + Jelly + 90% of your old ant targets built in + 200% more that you never had) It takes a bit of getting up to speed (naturally... - its still beta) but its so much more powerful than ant.

    >> and J2EE development is years behind your average C or
    >> C++ project, in terms of tools.
    Now, I am stunned.
    The quality of tools for Java far outstrip any of the tools that were ever available for C++/C.
    Given:
    IntelliJ
    Ant/Maven
    Clover
    Javadoc
    Together (if you want UML)
    JProbe/Performasure

    I cant imagine what else you would need...

    -Nick
  20. As for people who say it's too complicated, maybe it is, >but that doesn't mean it's bad! A jet engine is >complicated, because it is!


    The question is not if something is complicated per se or not, but is it difficult or easy to use. A TV set is a very complicated piece of machinery, yet it is extremely easy to use. So, doesn't mean that if something is complicated, it must also be very difficult to use. And that's what J2EE is guilty of.

    J2EE can stay as complicated as people wish, but, in order to succeed, it must be revamped so that it is extremely simple to use. There is no reason why it should expect its users to memorize so many tiny bits of information scattered around so many different locations in order to use it.

    A good user interaction specialist is required to walk in, revamp the ugly interfaces that J2EE exposes, and thus expedite the rate of adoption of this technology.

    Alex
  21. Alex B.

    >The question is not if something is complicated per se or not, but is it difficult or easy to use. A TV set is a very complicated piece of machinery, yet it is extremely easy to use. So, doesn't mean that if something is complicated, it must also be very difficult to use. And that's what J2EE is guilty of.

    I think you analogy is wrong about comparing a finshed product like a TV. A better comparison is if amy applications developed using j2EE is also complicated to use for the actual end users.

    I think the whole idea that j2ee is complicated is only making everyone to think in a very complicated way for even simple things.

    just my 2 cents worth.

    Manish
  22. For Anyone to claim that somehow J2EE is less complex than .NET is simply hogwash. Yes, J2EE is a great platform, but let's not get carried away. It definitely has it's problems, and one of the biggest hurdles it faces is it's incredible complexity... matched only by the need for developers to maintain a litany of XML deployment descriptors for which there are no good GUI interfaces!

    Any balanced review of J2EE will surely identify this onerous burden placed on programmers as the most serious deficiency of J2EE. Whatever the heck the designers of it was thinking.. they need to understand that the inner workings of J2EE simply aren't the concern of most programmers.

    Simply put, J2EE is far to expensive for me to consider using, given that my teams and budgets are smaller. For me, selling J2EE is an uphill battle with management, and frankly, although I gave tools developers some years to mature their tools, I think they've had enough time, and now I've had enough of their bullshit tools. Enough of having to modify XML by hand.. why the heck must I waste my time doing with this tedious and frankly donkey work, when the real smarts (and time well spent), is in developing solutions for my clients?!

    Is someone seriously trying to convince me that editing long XLM docs are his idea of a modern-day enterprise-class tool?! Do I really have to manually configure ten different tools from various vendors, each with their own quirky XML descriptor, just to get my app to work?! I’m not paid to fiddle, but to build solutions on aggressive timelines.

    As much as one can bash MS, one has to agree that they have consistently built top-notch tools for developers, and have always gone the extra mile (something sadly missing in the Java tools community), to make things easier, faster and more intuitive. Never will you find any stupid XML files to hand-edit in .NET. And just as a sidebar, the DLL-Hell that many of us have been through is happily a thing of the past with .NET. One more reason I think the Java world must do better, because the familiar punch lines are true no more.
  23. Well said, Reuben!
  24. one of the biggest hurdles it faces is it's incredible

    >> complexity

    I see this repeated again and again - however, Compared to what??
    Incredibly complex compared to C++?
    Incredibly complex compared to CGI?
    Incredibly complex compared to ASP?
    Incredibly complex compared to COM/DCOM?
    Incredibly complex compared to CORBA?
    Incredibly complex compared to MQ/TibRV?
    Incredibly complex compared to writing it all from scratch in C/C++/VB?

    What exactly?

    .Net?
    I would agree that .net is simpler than J2EE in the same way that J2SE is simpler than J2EE. They dont do the same things.

    I rarely see any detail in these arguments to back them up. What complexity would you see removable from J2EE - and how do you think it could be done?

    I would agree in part that the manual editing of XML deployment descriptors is a pain in the ass - but what do you think is better? Registry entries? Hard-coding? If you think that .net doesnt have XML deployment configuration, you will be sadly dissapointed. I will concede that language-level metadata support (like in .net) does assist in some cases, but also it has some significant limitations.

    >> Any balanced review of J2EE will surely identify this
    >> onerous burden placed on programmers as the most serious
    >> deficiency of J2EE.
    Again, I would disagree. I would say that if there is an onerous burden, it is placed on the application *designer*. J2EE introduces some significant restrictions to the programming model you can work with. The success of many applications is the designer's understanding of these restrictions and how to design around them. Fortunately you need fewer designers than you do implementers (people who type).

    Rather than endlessly moaning about complexity, complexity, try and suggest some alternatives. If you cant think of better alternatives that fly, then does that perhaps suggest that the J2EE programmers designers have got it right (or at least very close)?

    Despite all this endless complaining about the "terrible complexity" in J2EE, in our corp we seem to have moved developers from C++, VB, COM+ to J2EE without a great deal of trouble.
    We have done this without any training or any need for external consultants. We have done this in a banking/finance environment where we end up exercising just about the whole set of J2EE apis at some point.

    With a little guidance and assistance, largely they have got on with it and like it - and havent hit any situation where J2EE has failed them.

    I think the key factor in this perception of complexity is the understanding of WHY something is done the way it is in J2EE. Understanding why something is done a particular way makes it easy to accept or even appreciate the "complexity" rather than resent it.
    There are some people who obviously do understand, but I have seen a growing trend in people who dont.

    >> As much as one can bash MS, one has to agree that they have
    >> consistently built top-notch tools for developers, and have
    >> always gone the extra mile (something sadly missing in the
    >> Java tools community), to make things easier, faster and
    >> more intuitive

    ;-) I know a legion of (ex) COM programmers that would violently disagree with you here.

    I will agree that MS dev tools have traditionally been better. Having developed C++ on Solaris, VC++ is quite pleasant by comparison. But when you start looking at the more modern development environments, like Ant/Maven, IntelliJ/Eclipse, Together, Clover, etc I would say that Microsoft development tools (like VS.NET) are starting to show their age.


    -Nick

    PS:
    "developing solutions for my clients"
    "I’m not paid to fiddle, but to build solutions on aggressive timelines."

    Clearly your position is unique. For the rest of us, its just a hobby.
    Sorry for the sarcasm, but every time I see this sort of stuff I see red. Its insulting.
  25. Well said, Nick. Well said.

    Ryan
  26. "I still believe that J2EE is the last best hope for

    >freedom from tyranny in the enterprise software arena. "
    >
    >Tyranny? A bit of hyperbole. Does Sun indoctrinate all of
    >their employees with pap like this?

    It's babylon 5, not sun. He was making a joke (I hope).


    As for folks arguing J2EE complexity or not. I vote it is, massively, over complex. The J2EE spec is bloated and contains much rubbish.

    JSP: totally flawed, and the open source community are coming up with fixes.
    Servlets: Nice, simple. But not much good for use by design types....which means a process for decent GUI...rise of JSP...
    JSP/Servlet containers: very nice, simple to understand, start up and close down.
    RMI: very simple. But requires non standard broker processes which opened the door to EJB..
    EJB: really rubbish, they solved 'standard middle tier' but in the process created far more serious problems.
    EJB 1, 2, 3(no doubt): each version evolves rapidly Knowing the current flavour becomes a constant task of reviewing sites such as this..and constant prototyping.
    JAAS: Pretty damn rubbish. Folks just want a login page and end up reading about 50 pages of spec only to discover almost every app server has proprietary extensions, and that the UID is not carried through to the mid tier (often).
    JMS: nice and simple. Powerful, but you now have to understand EJB and the various vendor extensions.
    Swing: took too long for them to get right, and it's still pretty slow. All the tools do it differently as well - in terms of extending the generated GUI.
    Applets: great idea, now dieing.
    Logging: log4j is fracturing the spec. May they die soon.
    Exceptions: They took way too long to solve distributed exceptions.
    XML: good powerful features, but only because of open source - FOP and SAX drove this lot, not javasoft as was.
    SOAP: implementation (as of 4 months ago) was rubbish. Way too hard to set up.
    Internationalisation: The calendering classes are a simple example of his entire point - massively complex for everone, because some few have a real need for the functionality.

    Now, take all of the above and add a brand name, one which adds proprietary features: IBM, Oracle, BEA....

    Then take the churn rate: eg struts, Ant, log4j, JDK

    What you end up with is a massively complex, over speced technology. Which is why you need great architectural consultants to help you out.... anyone hiring?

    I also disagree with folks saying this technology is NEEDED for huge transactional systems. You can use it, but you can also KISS and use the databases as they should be used. In fact, all the really fast systems with massive transactional volumns have very thin layers between the protocols and the databases. And complex business tiers always have had server processes which persist and service message queues, j2ee does this no better than the many in-house systems customised to their business areas - usually in C++ using CORBA as a point to point protocol.

    Jonathan
    ps Notice I didn't mention .Net once.. DOH!
  27. well said jonathan
  28. I vote it is, massively, over complex


    Referring to my previous post.

    Again, I ask:

    Complex, compared to what?

    If you think J2EE is over-complex, it is because you know of a simpler way to do it. So lets hear it!

    >> JSP: totally flawed
    In what way?

    >> RMI: very simple. But requires non standard broker
    >> processes which opened the door to EJB...
    ..And, didnt address threading, security or transactions... hence EJB.
    (are threading, security and transactions important for tranasctional enterprise systems? I think so, no?)

    >> EJB: really rubbish, they solved 'standard middle tier' but
    >> in the process created far more serious problems.
    What problems?
    What would be your alternative to EJB if you have to write a server-side system, accessed by, say, a swing client?


    >> JMS: nice and simple. Powerful, but you now have to
    >> understand EJB and the various vendor extensions.
    What has JMS got to do with EJB?
    (EJB has something to do with JMS at the MDB level (as it does with SOAP) - but the reverse is not true)
    What vendor extensions do you have to understand? I havent personally had to touch one yet in my code. I have to understand the JMS implementation if I am choosing a vendor - but what else would you expect?

    >> JAAS: Pretty damn rubbish. Folks just want a login page
    ??
    Folks want a login page for their swing client?
    JAAS is more than just collecting credentials.

    >> and that the UID is not carried through to the mid tier (often).
    Which appservers?

    >> SOAP: implementation (as of 4 months ago) was rubbish. Way
    >> too hard to set up
    What was way too hard to set up? None of the SOAP implementations I have used have been particularly difficult (Axis, Sun ref, WL. Glue is meant to be even easier).

    >> Logging: log4j is fracturing the spec. May they die soon
    ??
    >> <etc>

    I dont see the rest of the remaining "issues" as iussues of complexity - more of a Sun-gripe list now....


    >> What you end up with is a massively complex, over speced
    >> technology

    So again, complex compared to what - what are your alternatives?

    If this stuff was NOT spec'ed (standardised), you would have the same complaints as above - except multiplied by N vendors' api's and implementations.
    Where is the logic in this argument?

    >> Which is why you need great architectural consultants to
    >> help you out.... anyone hiring?
    You dont need consultants necessarily - but you do need at least one person who actually understands the technology as a mentor. Nothing new here.
    Would it be better (as it was, pre-J2EE) that you require a team-full of highly qualified architect-level developers? And one per vendor?


    >> I also disagree with folks saying this technology is NEEDED
    >> for huge transactional systems. You can use it, but you can
    >> also KISS and use the databases as they should be used
    So what does this mean? (details?)

    How would you apply KISS to reading a message (on Q vendor X), querying some data from a database, exercising some BL, updating the database and writing a message (on Topic vendor Y) - all in the scope of one transaction?

    >> In fact, all the really fast systems with massive
    >> transactional volumns have very thin layers between the
    >> protocols and the databases.
    Again, not sure what this means. Do you mean like mainframes?

    >> j2ee does this no better than the many in-house systems
    I would violently disagree here.
    I have yet to see an in-house built -anything- that was non business domain related, that was not a complete pile of stinky cheese.

    Look, dont get me wrong, I am happy to question J2EE and debate the complexity (if there were some details to talk about).

    However, I see J2EE critics falling into two main camps:
    1) Those that think they are cleverer than the J2EE spec leads and contributors - and think they can write it all from scratch - but in reality, probably cannot. Sadly, there seem to be quite a few of these.

    2) Those that understand the problem, have an answer and HAVE designed and built a better alternative solution - that is in widespread use. Sadly, there are few of these people around (and few of these products around).

    -Nick
  29. This is an excellent discussion. I am glad I found this site.

    To Nick:
    >>Q: Complex compared to what?
    A: To all previous programming experinence that many had.

    Although, I realize that we are doing much more now, than we ever did before. It's just soooooo hard... I am a student working on a J2EE project, and it's just way different from what I learned before. (you know what they teach at college - Visual Studio, Swing, some CGI) ...So this one was a bit of a shocker.
    If I were a manager these days (dreaming :-)))) I would never choose J2EE if I had a chance to use something like PHP, ColdFusion, '.net' or whatever. BUT, for really big, heavy projects I see the long term benefit of J2EE. ...that's why I don't give up, bear with stupid XML editing and 10 different apps, and wade my way through it. Eventually tools will be there, technology will mature and become more accessibe.
    Go, J2EE, Go!!!!!
  30. A: To all previous programming experinence that many had.


    With all due respect, J2EE is more than a web technology (ala PHP, ColdFusion).

    Perhaps this is the problem? Maybe we need a J2WE (Web Edition).

    >> it's just way
    >> different from what I learned before.

    And, also, with all due respect, this is true of any job once you leave university ;-)

    I dont think it is reasonable to expect a student to grasp all the issues of building enterprise systems (and by corollary, J2EE OR .Net) - its highly complex.

    With time, you will learn to love XML configuration (as it can be Source-Controlled, searched, automatically manipulated by such tools as Jelly and Ant) - try that with the Windows Registry (VB:COM)...
    I agree though, there could be better tools in this arena.

    -Nick
  31. With all due respect, J2EE is more than a web technology (ala PHP, ColdFusion).

    >Perhaps this is the problem? Maybe we need a J2WE (Web Edition).

    That would be a good thing. Because so far I've been using J2EE for web-centric applications, and I know many people doing the same.

    >With time, you will learn to love XML configuration

    It's funny, but I am getting there! I started with Sun J2EE reference implementation and their deploy tool, but felt that it's just hiding the stuff from me. Being able to control all the settings at its origin is quite satisfying.

    Thanks for shareing great thoughts on this topic,
    Vic
  32. However, I see J2EE critics falling into two main camps:

    >1) Those that think they are cleverer than the J2EE spec leads
    >and contributors - and think they can write it all from
    >scratch - but in reality, probably cannot. Sadly, there seem
    >to be quite a few of these.
    >
    >2) Those that understand the problem, have an answer and HAVE
    >designed and built a better alternative solution - that is in
    >widespread use. Sadly, there are few of these people around
    >(and few of these products around).
    >
    >-Nick

    So you say that J2EE is great, all of it is needed to build the systems that you need, and you propose that the sun architects are in fact better than free thinking individuals who have been working with IT for at least as long as they have.

    I disagree. I think they invented Java at the right moment. They then focused on making it cover every tech area they could - ignoring GUI's while they shifted to web server side. This process culminated in a server side architecture which they could licence and so make money off. Every other java product they attempted fell flat (Java Safe..that browser stuff etc.). I see J2EE and especially the complexity of EJB as being a purely economic and business technology and not one AIMED at solving real world problems simply.

    You ask how would I service a message queue over multiple databases within a transaction. You could do this many ways - using bespoke roll back, doing it in the database, using 3rd party transaction libs, using sockets with bespoke handling, using messaging products, using soap/binary protocols, using a 60K app server which has built in message queues, and transactional ability. Hang on, that app server uses JMS which is standard, and JTA/JTS... what the heck pay 60K.

    But, let me ask how you would develop a web site which communicates to a database which is fed data every 20 minutes from disparate systems. Tomcat, servlets and JDBC are fine. Or how would you write an application on a desktop which updates customer details - again with data feeds hitting the back end: swing, jdbc with transactions and optimistic concurrency? Or how would you write data feeds: java applications with jdbc, maybe XML and XSLT, with FTP. How would you store users session based information? - in database tables. How would you scale a web site - with a web farm.

    So we now have 5 or 6 examples, one of which fits J2EE very nicely and 4 or 5 which do not need it. They simply don't need the knowledge or the skills or the complexity. But as others have said, j2ee gives you it all at once, and it's too much and too complex (because it is not needed).

    What am I comparing j2ee with? I'm comparing it with Java.

    Jonathan
  33. Jonathon
    <quote>
    So you say that J2EE is great, all of it is needed to build the systems that you need, and you propose that the sun architects are in fact better than free thinking individuals who have been working with IT for at least as long as they have.
    </quote>

    J2EE is great - but the rest of your statement makes no sense, no one has said that at all. However, the architects from sun, oracle, ibm, bea, etc who participate heavily in the creation of the j2ee specs aren't exactly idiots either, which I think is Nick's point.

    At one of our clients, we have a number of backend systems that participate in a variety of distributed transactions to accomplish certain goals - provisioning, bill generation, inventory tracking, order-flow-thru and the like. We need to capture parts of this backend workflow for a data warehouse and for a problem tracking application. Could we have written a bespoke system? You bet! Have we done it before? You bet!

    But guess what, J2EE, despite its flaws (real and perceived) offers the building blocks to handle all of our requirements on a standards-based highly performant system. We have, in fact, spent far less time writing code and we have used a smaller team as well. The result is far easier for the client to maintain and works at least as well as any bespoke system.

    I can't speak to using J2EE in web applications and desktop applications and the like because I don't write them - they aren't really in the realm of what I do. But I do know that in my 17-odd years of IT experience, J2EE is one of the better solutions that offers a realistic alternative to writing my own plumbing for EAI.

    Is it perfect? Nope. But it does improve with age and I, for one, find it easy to understand.


    Cheers
    Ray
  34. Ray,

    I agree that your problem fits J2EE - in fact I said that my examples included that 1 scenario. BUT, j2ee is over the top for the others - it is confusing and over complex.

    So, as I keep mentioning every few months a 'right sizing' activity is needed. You have a wizard which defines your problem domain, staffing, timescale, funds and out drop suitable java component technologies.

    A part of this confusion and complexity is the rate of change. Your current solution is based on released technology which is less than 18 months old (local interfaces?). So in another 18 months when we have generics, jdo, god knows what your current architecture will be described as legacy and you will be touting the new wave - no doubt arguing it remains simple and non complex. Meanwhile the maintenance guys remain stranded with aging specs, and anti-pattern technology ;no doubt ejb will be an anti-pattern within 18 months, and if you don't believe me look at remote EJB's.

    The science of collaborating systems is data modelling, decoupling and standards. A java standard which lasts less than 12 months is not a standard at all.

    Jonathan
  35. What am I comparing j2ee with? I'm comparing it with Java

    Aside from very simple applications, effectively, you are comparing it with writing it yourself.

    I dont think anyone is suggesting you use J2EE to solve simple problems.

    >> and you propose that the sun architects are in fact better
    >> than free thinking individuals who have been working with
    >> IT for at least as long as they have

    As Ray said, I propose that the J2EE spec contributors (from a multitude of companies - not just sun - across a broad spectrum of industries) are not stupid.


    >> I see J2EE and especially the complexity of EJB as being a
    >> purely economic and business technology and not one AIMED
    >> at solving real world problems simply
    I see. Is this linked to your supposition that the spec contributors were stupid? Or is it a conspiracy theory?
    We find J2EE quite useful for simplifying many problems, and the last time I looked, we were working in the real world.

    >> using a 60K app server
    What appserver costs 60K? None I know of.


    >> But, let me ask how you would develop a web site which
    >> communicates to a database which is fed data every 20
    >> minutes from disparate systems. Tomcat, servlets and JDBC
    >> are fine.

    Perhaps it is. Depends on what your requirements are.

    Lets say you have to deploy this application to an internet environment, where your web, application and data tiers must be physically seperated by firewalls. Suddenly, servlets and JDBC are not going to solve this problem at all.

    Lets say that your transactions span multiple operations on the same database - or perhaps you have more than one database and you dont want to manually demarcate your transactions? Then perhaps EJB?

    Lets say that you dont want to handwrite your persistance code (hand-write SQL, manually manage connections/resources) - maybe you want to use OFBiz/Hibernate - perhaps CMP?


    >> Or how would you write an application on a desktop which
    >> updates customer details - again with data feeds hitting
    >> the back end: swing, jdbc with transactions and optimistic
    >> concurrency?

    Again, for noddy applications, this 2-tier approach is fine.

    However, for more likely applications:
    1) What do you do when you start running out of processing power on the client machine? You need a server-side application.
    2) What do you do when you have so many users you start running into database connection limitation problems. You need a server-side application
    3) What do you do when your users are having to connect over the WAN to your DB? You want to keep data transfer to a minimum - do as much of the processing as close to the DB as possible. You need a server-side application.
    4) What if your users now want to be notified if data they are displaying in their UI changes? You need to use messaging (JMS) and you need to make sure the feeding systems are not writing directly to the database (instead, using a queue perhaps). Again, you need a server-side application.
    5) What if the database is stretched to the limit (by the other legacy applications that are hitting it) and 90% of the data your 2-tier app loads is common to all users - you need to cache (looking carefully at invalidations) - again - you need a server-side application.
    6) Lets say its not a Java client (and you therefore you cant use Webstart) and you have a large user base - and you want to avoid having to re-deploy the client every time you make a business logic change. You need a server-side application.

    In these cases, where you have a swing client and a server-side application, what would you use? EJB sounds good to me. You certainly wouldnt waste time writing your own RMI server. You have to write the server, configuration, manamgent utils, monitoring, documentation etc etc. The appserver is the simplest and cheapest option here.

    It all depends on the complexity of the app.
    I am all for keeping things as simple as possible, but in reality, I dont see too many noddy apps where a 2-tier approach will do.

    >> Or how would you write data feeds: java applications with
    >> jdbc, maybe XML and XSLT, with FTP.

    FTP? Certainly not. You might use XML, but you would use messaging, MDB's/Open adapter and whatever persistance mechanism you choose (usually not straight JDBC).


    >> So, as I keep mentioning every few months a 'right sizing'
    >> activity is needed.

    Well, thats not quite the contents of your last post.
    Your last post was along the lines of "J2EE is crap" "its too complex" "its all because Sun engineers are dumb".

    You also say stuff like "no doubt ejb will be an anti-pattern within 18 months, and if you don't believe me look at remote EJB's. "
    What exactly do you mean? Why would you not have remote EJB's (or do you actually mean entity beans?)

    "A java standard which lasts less than 12 months is not a standard at all. "
    And which Java standard lasts less than 12 months?

    Regards,
    Nick
  36. Hi Nick,

    You are playing a nice game :)

    OK, I never said sun engineers are dumb, I simply said that the rest of us are as good as they are: in fact sun has the same mix of dumb and smart as any well paying organisatio. I do suggest j2ee is a licensed technology that sun actually makes money from, as opposed to the rest of their java endevours which failed. No conspiracy there, I tried their other java products, and they are all now dead.

    >Again, for noddy applications, this 2-tier approach is fine.
    This is actually the center of your argument. Every simple scenario I put up, you shatter by adding complexity. You suggest that the client machine runs out of processing power for example....
    Anyway, my perspective is entirely different. Every application developed has far more processor available on the client than will ever be used. Every application (not web sites) has a small concurrent user base. Every application follows traditional GUI principles that result in load/store driven by user events:- possibly with polling for updates. There is never requirement for asynch messaging. And firewalls reinforce a pull architecture - no asynch broadcasts into client sites allowed, ever.

    Every website I have worked on does scale easily to support the several hundred concurrent data driven pages without your complexity. Note that these data driven activities are all sub-second, so even peak load can be handled with acceptable performance. And if not, add a web farm for load balancing, with connection pool for DB throttling. No EJB's in site. And I can still accept updates to the database from other technologies.

    These systems are not noddy: they are business critical internal systems. This is the bread and butter of most of the java community: systems with up to 5000 users, mining and updating data, with feeds to and from other systems.

    Other comments:
    You say feeds will not be in FTP. New feeds may not be, but every feed in existance in every organisation I work with has been done in FTP, usually with CSV files. So your experience does not reflect any of my real world experience over the last 14 years. In your experience it may, but not for me. Finally, soap and xml are starting to replace a very few feeds, but since many are sourced from excel spread sheets it will be a while....

    What appserver costs 60K : well about 18 months ago, weblogic on a two processor box cost that much. What are the current prices?

    >Lets say that you dont want to handwrite your persistance
    >code (hand-write SQL, manually manage connections/resources) Again, you are playing a good game. You suggest I will hand code everything and not use connection pooling. Perhaps you work for microsoft, for you can certainly play marketing games.

    >(or do you actually mean entity beans?)
    Yes I do. Spotted that one just after I posted.

    >And which Java standard lasts less than 12 months?
    OK, I started doing java in 1996...so...
    JDK old AWT event model, lasted about 2 years I recon.
    Then the new AWT event model lasted maybe 18 months before swing came out.
    Servlet spec came in (ie released code), crickey, err, 1999? Then JSP became big news about a year later...bit fuzzy on that one.
    RMI was there pretty much from the start. Then the corba IDL support was added. Then they came up with J2EE 1st version.
    J2EE had remote ENTITY beans, and TSS started up to try to make them work, before they were depricated by all right minded individuals with version 2.
    We are currently seeing entity beans slipping to JDO.

    Is this proof? No, most of these are more like 18 to 24 months. Are they standards? Not officially, but they are best of breed javasoft technologies which are being replaced with the new 'best thing'. Take servlets v's JSP v's struts v's standard tag libs. There has been rapid evolution in the 'best approach'. Even now this continues, with sun trying to match ado.net and code behind as opposed to java bean as an approach.

    This rapid evolution of best of breed solution can also be stated as I did: The standards are lasting less than a year (OK, 18 months).

    Cheers,
    Jonathan
  37. Jonathan,

    I am sorry you think I am playing games. I am not.

    You are arguing that J2EE is both badly designed and unnecessary. You put forward, as evidence, some quite simple applications where J2EE is, I would agree, not necessary.
    However, as I said, building enterprise systems is rarely as simple as that. I just illustrated several real-life examples of how these "simple" apps can easily become complex. However, I have not seen how you propose to address these complexities.

    >> Every simple scenario I put up, you shatter by adding
    >> complexity.

    I add the complexity?? I dont make the complexity up. It just exists. Its there. I am not mentioning complexity for fun.
    So, what would your solutions be in these situations - you havent answered that.


    >> the rest of us are as good as they are: in fact sun has the
    >> same mix of dumb and smart as any well paying organisatio

    My point was nothing to do with the quality of Sun employees - the spec contributors are representatives from a host of organisations. And, I suspect they are not chosen at random - but perhaps, for their expertise? I would guess that the average spec group has a greater concentration of very smart people than the average project team.

    >> Every website I have worked on does scale easily to support
    >> the several hundred concurrent data driven pages without
    >> your complexity.

    Congratulations :)
    Again, the complexity I mentioned is not for fun - it just happens to exist. So what would your solution be in this scenario? How would you tier this web app without EJB?

    >> You suggest I will hand code everything and not use
    >> connection pooling

    It has nothing to do with connection pooling.
    In all your years java experience, have you never had to hunt down some resource leakage because somewhere, under some unforseen conditions, there was some piece of code where a connection/statement/resultset wasnt being closed???
    One of the benefits of a managed persistance - is NOT having to do that.

    >> You suggest that the client machine runs out of
    >> processing power for example....

    If you want an example of a client running out of processing power, try look at front office electronic trading applications.

    >> And I can still accept updates to the database from other
    >> technologies.

    Are you saying you cant if you use EJB?

    >> What appserver costs 60K : well about 18 months ago,
    >> weblogic on a two processor box cost that much. What are
    >> the current prices?

    Nowhere near that I can assure you.

    Cheers,
    Nick
  38. <Alex>
    The question is not if something is complicated per se or not, but is it difficult or easy to use. A TV set is a very complicated piece of machinery, yet it is extremely easy to use. So, doesn't mean that if something is complicated, it must also be very difficult to use. And that's what J2EE is guilty of.
    </Alex>

    Will you say the same about VCR, some folks even believe that VCR programming is more complicated then J2EE :) the difference is state and no persistence for TV. MS does not like state and they are right that it is much easier, but is it always better?

    disclaimer: I have a pretty old VSR

    Oleg
  39. J2EE, Democracy, and Sausage[ Go to top ]

    Thank you, Bill,

    Every now and then someone just has to declare common sense. Before J2EE, developing large enterprise systems used proprietary measures. These were extreme measures like rolling your transaction engines and custom TCP sockets.

    Now, we have all these "application level" developers crying about EJBs. I can understand the frustration of having to create interfaces (Classes not Screens) to access other classes in order to do something. When in VB, all you did was double click on a screen button to "do something".

    Thank God, .NET is almost ready and these people would go away...
  40. J2EE, Democracy, and Sausage[ Go to top ]

    I disagree. It almost seems as if people WANT technology to be "hard" or "complex" just so people would call them Geniouses ;-)

    J2EE is not that complex indeed, its just not integrated well. Different vendors are responsible for different components, and today, its up to the administrator/developer to integrate them, and that's what people complain about - be it a dependency discoverer, user authentication/authorization (JAAS), and so on.

    For example, I'm not a Microsoft fan (nor an anti-Microsoft one) but if you look at the interface of their application server (COM+) you see that ease of use was in the mind of its developers. Want transactions? Just click here ;-)

    Of course, one could easily take the opposite side and claim "But that's because they own/develop all components on their own!". Well, my answer to that would simply be: "I don't care." - from my experience, the average developer on a product development team doesn't care who owns what, or who developed what - he/she simply wants his/her paycheck and go home. It's true, not all developers are like that (I HOPE NOT!) but they are the majority and tools have to suit the critical mass that uses them.

    I'll add that it seems we are in the correct course, just looking at IBM and Oracle and seeing how they try to own the entire product stack so that they can integrate everything to the extent. Oracle starts doing a good job at that, especially in Oracle9iAS 9.0.3, and IBM WebSphere as well.

    The same goes for development tools as well (as noted above).
    I don't complain much about J2EE complexity, but that's because I've invested enough time learning it. The problem is, it shouldn't be like that
  41. J2EE, Democracy, and Sausage[ Go to top ]

    Now that's just not true. Before J2EE there was CORBA (which is most certainly standardized and even interoperable on the server side -- try that J2EE ;-), and before that there was DCE. CORBA is standardized for location, transactions, security, and numerous other "hard" problems.

    J2EE is not by a longshot the first thing to standardize distributed middleware.

    Mark
  42. J2EE, Democracy, and Sausage[ Go to top ]

    J2EE is not by a longshot the first thing to standardize

    >> distributed middleware.

    True. But, by a long shot, its the first successful attempt.

    -Nick
  43. J2EE, Democracy, and Sausage[ Go to top ]

    I don't think J2EE is too complicated , on constrast it is
    so great that make my work more fluent. J2EE is not only a
    platform but also a framework for developing enterprise applications. Helped by the instruction of J2EE we build software with higher quality and faster speed. In my opnion the conception of CMP on EJB is very great, it accelerates
    development for database based application which not cared very much on performance. I ever developed component with Microsoft's Visual C++ in ATL, it nearly make me mad, one is the terrible marco another is its complication(special it's thread model), but when I using Java , using EJB, wow
    everything is so beautiful, everthing is so clear. The other
    reason I like J2EE because of its open specification. From my experience if I occured some problem in development, go through the spcefication on specil spot quicly, you can get the answer.
  44. J2EE, Democracy, and Sausage[ Go to top ]

    When you have complexity there are at least two possible solutions:
    1) use a tool to try and hide the complexity
    2) try and make it simpler
    I think it's a good general principle to go for the latter approach.
  45. J2EE, Democracy, and Sausage[ Go to top ]

    "I still believe that J2EE is the last best hope for freedom from tyranny in the enterprise software arena. "

    Tyranny? A bit of hyperbole. Does Sun indoctrinate all of their employees with pap like this?

    There's lots of other technologies that are not created or owned by evil MS with more technologies yet to be created to come.

    J2EE is a very good platform. But it's not saving us from anything evil.

    Give me a break.
  46. J2EE, Democracy, and Sausage[ Go to top ]

    Howdy All,

    Very interesting discussion. My background is as an academic and consultant with some development using Java (particularly, Apple's WebObjects) whilst also learning as much as I can about J2EE and .NET.

    My comments are:

    When people discuss the complexity of J2EE it appears that they are usually referring to EJB and associated concepts. Whereas when people discuss .NET they are usually just referrring to WebForms (sort of the equivalent of Servlets/JSP) and Web Service development. When we had a MS demo of .NET there was very little talk (none, until I asked) of ServicedComponents etc. It's comparing Apples and Oranges. Of course, front-end Web development is easier than enterprise back-end development. That said, EJB does seem overly complex to me (and that detail should be hidden by the tools), even more complex than the declarative attribute-based .NET ServiceComponents seem to be.

    It's interesting to read how bad EB's are for OO business modelling (difficulty with polmorphism etc). I'm not an Apple employee (although I have done work for them) but their WebObjects offering seems to do all that most people hope for in a mature and elegant way. The WebObjects Framework (WOF) allows you to easily map objects into web pages (so you can take properies of objects and display them in a page, or set properties from a page input, or call a method as a result of a submit etc). The Enterprise Objects Framework (EOF) allows you to build a clean fully object-oriented business model and have that persist in almost any JDBC-driven relational database without, basically, the need to write a single line of SQL (*).

    EOF does seem to lack a little behind .NET and J2EE in its transaction support (ie it doesn't support transactions across multiple databases) and distributed processing is not a part of the frameworks (and there is probably more). However, it goes further in other areas, including, for example, rule-based development of Web front-ends, and even rule-based development of Java client front-ends for three-tier applications. This enables one to developer sophisticated applications with very little code and almost completely dynamic and customisable at run-time (change the application in front of your customer's eyes, or whilst they are off at the rest-room, or better still do it back at the office and charge them for a couple of weeks work ;-).

    You can officially develop with WebObjects on Windows or Mac OS X, unofficially on any OS supporting Java 1.3.1 or higher platform. Similarly, you can deploy on an Java 1.3.1 or higher platform although only Mac OS X, Windows ? and a couple of others are certified. WebObjects does have a learning curve, but it is mostly just learning OO, Java, and how real frameworks work (not just OO class libraries). If you know that, the frameworks are not that hard to learn and the productivity benefits are great. The tools are also good (not excellent).

    WebObjects seems to me to be the solution that most people need for middle-level enterprise applications (but few seem to consider). Of course, it is a proprietary set of frameworks (but it is Java-based) On the other hand, .NET seems to provide a good solution for front-end development but an untested solution for back-end development (with only the promise of an O-R modelling layer), and J2EE seems like a patchwork at the front-end development (Servlets, JSP, Struts, ...) and overkill for backend-development with EJB (with some O-R modelling solutions existing but not a part of the standard, at least, not yet).

    If that sounds a bit like an advertisement for WebObjects, it's not meant to be.

    Best regards,
    Ashley Aitken
    Running Code Productions