Forrester: The J2EE appserver market still up for grabs

Discussions

News: Forrester: The J2EE appserver market still up for grabs

  1. According to Forrester Research, application server vendors are claiming victory in a market they haven't won. In fact, if BEA Systems, IBM and Oracle don't buy development help soon, they risk losing customers to Sun, Microsoft and the open-source community. The special report debunks vendors marketshare claims and recommends that vendors focus on beefing up productivity tools.

    Read Commentary: An app server winner? Not yet.

    Threaded Messages (58)

  2. I think this article is absolutely right -- while the J2EE vendors are bickering about who's the fastest and who's the most compliant, they're failing users by not also being the most user-friendly. No app server should require users to tinker manually with a single line of XML deployment descriptors, or manually assemble WARs or JARs.

    In any event, WARs, JARs, deployment descriptors.. all these are nothing new, and have been implemented countless times over the last 30 years in one way or another. For J2EE Vendors to expect one to manually tinker with such mundane items shows their utter failure to learn from past lessons, and grasp the direction in which the software industry as a whole is heading. One doesn't need to know the codes for Rich Text Format to write a Word Document, so there's no reason to know the XML Tags for a correct deployment descriptor either. It should be automatically generated.

    More importantly, deployment should be made seamlessly integrated for users, with generic declerative code auto-generated. I can't imagine one still has to wait for vendors to realize the importance of this.
  3. I agree with the previous post.....manually editing xml files to get things running is not my idea of fun.....I remember working for an Internet startup in late 2000...they paid 100k for Bluestone and then we spent tons of time manually editing the longest ini file I had ever seen (for those of you that worked with it, remember the sajava.ini file?).
  4. No app server should require users to tinker manually with >a single line of XML deployment descriptors


    it means by the way, that the concept of entity beans should be changed. Data base itself should be responsible
    for object oriented interface knowing all the descriptions
    for tables. .NET & ADO rules again ? :)

    Dmitry Namiot
    Coldbeans
  5. Unless your persistance is not a 'database'.
  6. I'm somewhat familiar with .net, could you please explain what you mean. I am un-aware of the features you are referring to in .net. I find .net persistence quite primitive, but since it's very large, I may not know what features you are talking about.



    thank you
  7. .Net .Schmet[ Go to top ]

    it means by the way, that the concept of entity beans should >be changed. Data base itself should be responsible

    >for object oriented interface knowing all the descriptions
    >for tables. .NET & ADO rules again ? :)

    Sorry to break this to you but you are referring to has nothing to do with Objects, its simply an OO API for representing and accessing a relational database, Microsoft does not really promote O/R mapping and believe that stored procedures are good design patterns, Entity beans abstract the application from the data source, you don't even really care about the Database or it's data structures

    PS: JDBC provides pretty much the same access to DataBase Meta Data that .Net & ADO does, I suggest you go do some homework.
  8. RDBMS are not evil thins[ Go to top ]

    <quote>
    Sorry to break this to you but you are referring to has nothing to do with Objects, its simply an OO API for representing and accessing a relational database, Microsoft does not really promote O/R mapping and believe that stored procedures are good design patterns.
    </quote>
     
    IMO: There is a bit too mush push to declare RDBMS as evil things. And they are worth careful studying if we need to create real robust and performant system.
     
    I have to confess: I like Stored Procedures. Even more: I think that OO has limited applicability (still). There are pretty good non OO systens around: Unix, Mainframe, etc. They are designed with layers and responsibility chains in mind and they run pretty well!
     
    There are many systems (especially big ones) that use "data sharing", it means that different clients exist in the same time and might work on the same data. It such circumstances DB(and RDBMS) might be considered as unmovable part and good design dictates use of SP/views/triggers/constraints, because it allows to share business logic/validation among all kind of applications: EJB, VB, Delphi etc. Database itself(and data in it) has the biggest value for enterprises and applications are just servans.
     
    I still design DB first, and then design applications, because DB clients are much more volatile than DB itself.(I try to avoid SP usage, but they are so damn effective. Sorry, not everybody rush to rewrite everything with using J2EE and CORBA).
  9. RDBMS are not evil thins[ Go to top ]

    There are many systems (especially big ones) that >use "data sharing", it means that different clients exist >in the same time and might work on the same data. It such >circumstances DB(and RDBMS) might be considered as >unmovable part and good design dictates use of >SP/views/triggers/constraints, because it allows to share >business logic/validation among all kind of applications: >EJB, VB, Delphi etc. Database itself(and data in it) has >the biggest value for enterprises and applications are >just servans.


    That's is exactly the purpose of EJB/Corba/WS
  10. <No app server should require users to tinker manually with a single line of XML deployment descriptors>

    True. Why not pay $0 for the app server, and write xdoclet tags in the Ejb beans to handle generation of all xml deployment descriptors. The JBoss Way.
  11. <True. Why not pay $0 for the app server, and write xdoclet tags in the Ejb beans to handle generation of all xml deployment descriptors. The JBoss Way.>

    Because with xdoclet you will merely end up with a modularized application and not a set of components. I understand why people use xdoclet and ejbgen - they are great tools and stop you tearing your hair out. But the problem is that by removing the complexity you are also removing the deployment-time configurability.

    What I want is something that allows me to annotate Java files with what properties, beans and resources the EJB is expecting from the ENC and then has another file that specifies the values of these things. Anything less and and you *do not* have components.

    There's a happy medium somewhere and we haven't found it yet.
  12. <ian>
    What I want is something that allows me to annotate Java files with what properties, beans and resources the EJB is expecting from the ENC and then has another file that specifies the values of these things. Anything less and and you *do not* have components.
    </ian>

    Very true, and that's why EJBGen allows you to specify variables/values in a property file and then use these variables in your source:

    @ejbgen:jndi-name
      remote = ${remote-jndi-name}

    And in a property file:

    remote-jndi-name = AccountEJB

    There is more to this feature, see http://beust.com/ejbgen/#substitution-variables for the gory details.

    What this enables is exactly what you are looking for: users tend to separate their annotations in two parts:

    - Those that are tied to Java code, and which belong in the source (such as transaction attribute, security mappings, etc...)

    - Those that pertain to deployment are typically specified in property files that can be shared across EJB's and modified easily by administrators.

    --
    Cedric
    http://beust.com/weblog
  13. <cedric>
    Very true, and that's why EJBGen allows you to specify variables/values in a property file and then use these variables in your source:

    @ejbgen:jndi-name
      remote = ${remote-jndi-name}

    And in a property file:

    remote-jndi-name = AccountEJB

    There is more to this feature, see http://beust.com/ejbgen/#substitution-variables for the gory details.

    What this enables is exactly what you are looking for: users tend to separate their annotations in two parts:

    - Those that are tied to Java code, and which belong in the source (such as transaction attribute, security mappings, etc...)

    - Those that pertain to deployment are typically specified in property files that can be shared across EJB's and modified easily by administrators.
    </cedric>

    I used EJBGen earlier this year for a project and found it to be an excellent tool - it made it practical, and pleasurable, to use CMP. Including EJBGen with Weblogic is one of the best things BEA have done.

    The mechanism you describe is one I used and is a good solution given the current limitations of EJB, but it is very much a build-time mechanism - you need the source code to make it work.

    What I'd like to see is a system where I can define all my beans with the properties, beans and resources they are expecting to be present, compile them, jar them and then at deployment time create a single file that specifies how these beans are all configured together. At the moment I can ship a bean with an environment entry defined in the ejb-jar.xml but at deployment time I have to effectively *edit* that file, i.e. I am changing the jar file I was provided containing the compiled bean. I don't like that.

    I suppose the bottom line is that at the moment the ejb-jar.xml is too much of a mix of development-time and deployment-time attributes - I think they need to be split.

    Ian.
  14. <ian>
    What I'd like to see is a system where I can define all my beans with the properties, beans and resources they are expecting to be present, compile them, jar them and then at deployment time create a single file that specifies how these beans are all configured together. At the moment I can ship a bean with an environment entry defined in the ejb-jar.xml but at deployment time I have to effectively *edit* that file, i.e. I am changing the jar file I was provided containing the compiled bean. I don't like that.
    </ian>

    So this tool would crack up the ear open, do a bunch of search/replace on the deployment descriptors for the values you specified, rejar the ear and then deploy it?

    That's an interesting idea, let me think about it (feel free to expand on what you'd like to be able to do exactly).

    --
    Cedric
    http://beust.com/weblog
  15. Wasn't this the original idea? I.e. that you don't need the source code of your .jar/.war/.ear to configure some of the properties?
    V.
  16. <quote>
    True. Why not pay $0 for the app server, and write xdoclet tags in the Ejb beans to handle generation of all xml deployment descriptors. The JBoss Way.
    </quote>

    This would still require you to learn x-doclet wouldn´t it.

    I agree, the new api for deployment tools should give us a way to do this in a GUI.
  17. I agree that in the past app server vendors were slow to realize the usefulness of tools such as deployment descriptor editors but that's no longer true. Weblogic 7 has Weblogic Builder with which you can edit any J2EE module DDs - while the IDE doesn't shine as much as BEA's Web service tool, Weblogic Workshop, it is very effective and does its job nicely. WAS 5.0 has a DD editor too. So, we are getting there.
  18. BEA WLS Workshop[ Go to top ]

    Can't you imagine creating your J2EE modules from within a Workshop-like tool? Why just edit descriptors when you can hide all that complexity.

    That's where BEA should go with their dev tools.

    First Workshop should leverage the high-quality webservices framework found in WLS7... it currently has it's own webservices frameworks, which should go away. Smells like politics, though.
  19. BEA WLS Workshop[ Go to top ]

    <quote>
    Can't you imagine creating your J2EE modules from within a Workshop-like tool? Why just edit descriptors when you can hide all that complexity.

    That's where BEA should go with their dev tools.
    </quote>

    One of their engineers told me that this is exactely where they are going. Point and click/drag & drop app development using a simple high level language to create business rules. They even hired the guy who created VB at MS.
  20. BEA WLS Workshop[ Go to top ]

    I think it's definitely encouraging that BEA has realized the necessity for simplicity in J2EE tools. I think the ex-Microsoft guy (who created VB), that you're mentioning was first put to work on BEA's workshop tool, and from what I've seen and heard, it's quite a hit. No one's complaining that they miss writing any XML deployment files, or cannot find excuses to waste time doing mundane and donkey-work, and the tool works quite well.

    From a manager's perspective, having such a tool that makes the IDE handle the mundane tasks is a great boon. Firstly, you can get away from projects staffed only with gurus, which usually means bloated budgets as well. You can also bring in more junior people, and have them be productive quicker, thereby allowing more projects successfully exploit J2EE.

    Right now, J2EE is the domain of the experienced and very skilled Java Programmer, who is also undaunted by command like confuguration and seemingly inexplicable problems which may end up being a mere deployment error. You'll agree with me, that this is certainly not the kind of technology that one can expect will permeate the entire industry, over a wide variety of programming talents.

    Therein lies the problem. It is only a matter of spending the required amount of money and time to develop a fail-proof point-and-click deployment and configuration application, which affords gurus all the tinkering they want, and lets greener hands get the job done as well.

    Why must we J2EE developers prove our skills by the way in which we configure our solutions, rather than the way in which we implement the business rules. Isn't that the very essence of reuse?
  21. point-n-click[ Go to top ]

    <quote>Firstly, you can get away from projects staffed only with gurus, which usually means bloated budgets as well. You can also bring in more junior people, and have them be productive quicker, thereby allowing more projects successfully exploit J2EE. </quote>

    Fool with a tool is still a fool. _Really_ complex applications cannot be done with poin-n-click tool. Overuse and misuse of EJB is the biggest problem.

    IMO: X-Doclet merge points + Ant features (external property files) + proper development techniques (_true_ version control, separate property files for dev|qa|release environments, etc.) do the trick; EJB development becomes a piece of cake.
  22. point-n-click[ Go to top ]

    Some people drive BMWs to compensate... others like to think that doing the same repetitive and generic tasks over and over says something about them.

    The rest of us have gotten over the dot-com bust, have real projects to work on, real timelines to meet, and realistic budgets that don't allow for countless unshaven gurus.

    You are right, that a "fool with a tool is still a fool." But to follow your argument, does a good writer need to know Rich Text Tags to write well? Or perhaps a good writer according to you must write his book in XHTML, on vi of course. And perhaps good architects should use pencil and paper as well?
  23. point-n-click[ Go to top ]

    _Good_ architects do use paper and pencils in a right time. As a Pragmatic Programmer I do value and use all kind of productive tools. I just found from my experience that nonvisual tools are much more productive for repetitive tasks than mouse clicking.

    Vi for source editing is a nonsense when there is IntelliJ IDEA for doing that. With JBuilder, Eclipse or NetBeans as source editor and debugger we could be almost equally productive.

    I even use extended abilities of visual tools like WSAD, but usually only once: when I need to know quickly: what exactly should be in a vendor specific descriptor. Since that it is easier and faster to create them with XDoclet templates. I really spend a bit more time initially instead of wasting it over and over again.

    Yes, there are applications (90%), which can be done with point-n-click. It just does not mean that rest of them can be done in the style. I guess that 70% of point-n-click applications should not be developed at all because they reinvent the wheel, but that is a separate topic.

    Fun to drive BMW cannot be used on farm or battlefield.


    PS: Gurus should not go unshaven, they should be bearded.
  24. point-n-click[ Go to top ]

    <Fun to drive BMW cannot be used on farm or battlefield>
    Tell that to James Bond. :)
  25. J2EE market...[ Go to top ]

    The success of this in many an Enterprise has more to do with high level effort, than with the nature of the tools. The tools are already well evolved, and will get better. And there is no more developer shortage!!

    Who has the reputation and who can do the sales talk is the question?? IBM is well placed in lot of traditional IT's where their mainframes already exist - financial, insurance etc. BEA is popular in the tech IT industry like telecom etc, which have successfully hired better talent during the boom years - so they don't need the consultancy push to understand the nature of this new technology.

    Usability is not an issue !! Developers can edit XML files or fill in wizards both as much easily.

    But the development effort, atleast in places I have worked, has not been directed with commitment and a good high level architecture work from the top. It always looks like a piece meal effort at the bottom, with the result that ROI is still low in many places.
  26. point-n-click[ Go to top ]

    "Fun to drive BMW cannot be used on farm or battlefield. "

    I have to say it again - go visit Germany and on every second farm in Bavaria you find a BMW. It just is a redneck car :)
  27. point-n-click[ Go to top ]

    <quote>
    IMO: X-Doclet merge points + Ant features (external property files) + proper development techniques (_true_ version control, separate property files for dev|qa|release environments, etc.) do the trick; EJB development becomes a piece of cake.
    </quote>

    Hmm. That's a pretty good summary of a pretty effective technique. Now it would great if I'd an IDE that "completely" (and transparently) automated that.

    Sandeep.
  28. point-n-click[ Go to top ]

    "Fool with a tool is still a fool. _Really_ complex applications cannot be done with poin-n-click tool. Overuse and misuse of EJB is the biggest problem."

    I can't agree more. You can create a "skeleton" app using point and click, but then reality comes into the picture (a'la "I want this field green if that value in the db is 0 and we didn't get cancelation within 1hr 30mins"). Software Development is still an art.

    I have a bunch of experience with apps written with "drag'n'drop" tools. It's a maintanace hazard. These tools are good to bye an IT manager but they don't buy a working, extensible and maintanable app.

    And I agree with the point re: XDoclet. It's just a matter of two hours reading and your deployment "problems" are gone.
  29. BEA WLS Workshop[ Go to top ]

    "It is only a matter of spending the required amount of money and time to develop a fail-proof point-and-click deployment and configuration application, which affords gurus all the tinkering they want, and lets greener hands get the job done as well."

    The problem is that (at least as far as EJB are concerned) the configuration of the application also has impacts on the functionality. I'd like to see a "greenhorn" configure a transaction-centric application that avoids phantom-reads, dirty-reads, unrepeatable-reads, deadlocks, etc.

    One statement here in this forum was something like "A fool with a tool is still a fool". I _totally_ agree with that.


    Best Regards,
        Dirk
  30. <quote>
    I agree that in the past app server vendors were slow to realize the usefulness of tools such as deployment descriptor editors but that's no longer true. Weblogic 7 has Weblogic Builder with which you can edit any J2EE module DDs.
    </quote>
    As memory serves me right, the older WLS versions (5.1 and before) has such a tool. For 6.0 existed a tool called builder too. It was however a web-application. With the advent of 6.1 it dissapeared. BAS (or IAS or whatever borland calls/called it) had/has a tool to edit deployment descriptors. When I started with EJB on this app server 3 years ago I never messed manually with deployment descriptors. You could even create CMP beans using a join query of two or more tables.
  31. <sven>
    As memory serves me right, the older WLS versions (5.1 and before) has such a tool. For 6.0 existed a tool called builder too. It was however a web-application. With the advent of 6.1 it dissapeared.
    </sven>

    Your memory serves you right, but the WebLogic Builder that was shipped with 7.0 is a brand new beast that covers all of J2EE (jar, war, ear, rar) and also adds features such as

    - Smart compilation (run ejbc from tne tool and if it fails, Builder will take you to the panel containing the offending descriptor)

    - Deployment from the tool

    ... and more.

    --
    Cedric
    http://beust.com/weblog
  32. <quote>
    -- while the J2EE vendors are bickering about who's the fastest and who's the most compliant, they're failing users by not also being the most user-friendly. No app server should require users to tinker manually with a single line of XML deployment descriptors, or manually assemble WARs or JARs.
    </quote>

    I agree completely with the first thing you said. Screw fastest app server. If I want high throughput I'll build a highly scalable app and cluster the sucker.

    User friendly, yes, I agree, this is vital. An app server that is well documented, ROBUST, and easy to set up and configure is needed. Ability to monitor easily what happens in production and test (everything from heap size to transaction counts to analysis of connection pool usage) is important because it aids maintenance. But the biggie is that any junior developer should be able to take the manual in one hand and set up the damn thing and have it run and work and run the java code they're writing.

    But I think second sentence quoted above is on the wrong track. Many people seem to complain about the time taken to generate the trivial infrastructure for EJBs: writing xml files, handcoding Remote Interfaces and EJBHomes, manually assembling WARs and JARs. And tools that do this stuff for you are hailed as providing create productivity gains.

    Really! These tasks are trivial, and they take up hardly any of my time. An EJB is a component. Typically components have many classes (several dozen classes per component if you're using a Session Facade). Another half hour of fiddly trivia for each component is annoying, but it's hardly a big productivity issue. And maintenance is the big cost, not development - adding a new method into my xml file is hardly difficult.


    Sean
  33. I don't agree that editing DD XML files is thta easy. OK, maybe the editing itself is easy, but you need to know what you are editing. Especially when it comes to transaction configuration (trans. attriubutes, isolation level) with respect to performance, deadlocks, etc.

    And I haven't seen any tool yet that can _generate_ these configurations for me. Also I don't see that doing it 'The JBoss way' with xdoclets is a solution for that, since there _is_ a clear difference between development and deployment. I cannot emphasise that enough!

    Best Regards,
        Dirk.
  34. <quote>
    Also I don't see that doing it 'The JBoss way' with xdoclets is a solution for that, since there _is_ a clear difference between development and deployment.
    </quote>

    Agree, that's why the Xdoclet people implemented "merge points", to separate design-time attributes from deploy-time ones.

    see http://xdoclet.sourceforge.net/merge.html

    -- Andres
  35. I agree but I disagree.

    Yes - we need tools to package stuff and create the
    deployment descriptors.

    But no GUI's please. It should be script-based. And
    since most are using Ant then it should be Ant tasks.

    And that also means no proprietary tools. We need tools
    that work with multiple/all app-servers.

    If the app-server vendors would commit to providing
    compatible ant tasks for their app-servers then fine.
  36. People, if you are editing XML deployment descriptors manually to configure your apps when you install them, you are not in the 21st century. From WebSphere 4.0 on you have not had to do this. Use the tools. Now we're at WebSphere 5. Get with it.
  37. I can't understand your concern about tinkering with XML DD files. If your using tools such as AAT or WSAD, the ejb.jar files and DD are taken care for you. The easy export of an EAR to import to WAS is as simple as 1,2,3. I agree WAS 3.5.4 was most difficult but with WAS 4.0 EAR and WAR is a no brainer. I agree open source gives us options, (Struts, Apache, Linux), but to take a chance for enterprise solutions with loadbalancing and object Session persitence, are you gonna trust JBOSS? In fact, we don't even want to get into Security frameworks and persistence (Container Management).
  38. It amazes me more and more every day how many things can .net dollars buy. From instigating reports, to clueless programmers that all they want is to have a little IDE tool to write macros and for things to magically happen.

    Can anyone see that this site is now an M$, anti-ejb dump ground?
  39. I think both BEA and IBM are well positioned in the App server market.

    I create my ear file using ant script but I have done that also with JDeveloper and IDEA to deploy in Weblogic 7.0. The best thing is that you know what you are putting in ear/war file and since the deployment descriptor and ear/war is a part of specs this makes easy on the developer side

    In case of Websphere 4.0 I have used AAT (application assembly tool ) to create my war/ear file. Websphere App developer can also be used to create the ear/war file and edit deployment descriptor.


    I would like see what is in the deployment descriptor and ear/war file before I deploy. The worst will be not to know what is going on when your app breaks down. The beauty of Java is that it has a standard which gives us the independence of using any IDE we choose I bet .Net cannot do this in a million years.

    Here is difference of Java and .Net :

    .Net is proprietary

    Java is an open standard

    thanks
    Sarwar
  40. Sarwar,

    <The best thing is that you know what you are putting in ear/war file>

    While I respect your opinion, I cannot agree with that. You don't generally care what you put into an .exe file, right? It's a packaged stuff that should simply do its job. If you have a good source, if you have tools to debug it and quickly see the results, you are happy. If you have programmed in c++, what would you think if they told you to pack all .obj files together with manually written module dependency files into a zip to get a ready to run application?

    The point here is that there is quite some amount of unjustifiable complexity in the mechanics of deployment in J2EE. So there is a long way to go to improve that. After all, the simplicity is the key.

    Eugene Belyaev
    JetBrains, Inc
    http://www.intellij.com
  41. Hello Eugene,

    I acknowledge your point but in JDeveloper 9.0.3 and Websphere App Developer 4.03 creating war file is very trivial. I am sure in JBuilder 7.0 it may be easy too.

    I am just tired of these experts always saying java lacks this and that but they have not looked at ever aspect of the platform. What my point was there a lot of flexibility in Java and its tools, you can make your choice. If IDE's where specific to vendors app then a great ide like IDEA will have no viability . By the way IDEA 3.0 looks great :).


    thanks
    Sarwar
  42. Sarwar,

    <The best thing is that you know what you are putting in ear/war file>

    While I respect your opinion, I cannot agree with that. You don't generally care what you put into an .exe file, right? It's a packaged stuff that should simply do its job. If you have a good source, if you have tools to debug it and quickly see the results, you are happy. If you have programmed in c++, what would you think if they told you to pack all .obj files together with manually written module dependency files into a zip to get a ready to run application?

    The point here is that there is quite some amount of unjustifiable complexity in the mechanics of deployment in J2EE. So there is a long way to go to improve that. After all, the simplicity is the key.

    Eugene Belyaev
    JetBrains, Inc
    http://www.intellij.com
  43. Sarwar:

    "The beauty of Java is that it has a standard which gives us the independence of using any IDE we choose I bet .Net cannot do this in a million years."

    Actually, it could take a little bit less, see for example:

    http://community.borland.com/article/0,1410,28649,00.html
  44. Not to mention:

    http://www.icsharpcode.net/OpenSource/SD/default.asp
  45. Actually its the other way around. .Net is open (see ECMA) and Java is still owned by Sun.
  46. ...before I start a flame war let me be clear that I only
    am just responding to the statement that Microsoft "will never in a million years (release .net as a standard)." The ECMA standards I am referring to are: ECMA-334 (C#) and ECMA-335 (the CLI). That is all.
  47. Value of limitations[ Go to top ]

    Do you recall that Java was young too? (And I think it is not quite mature yet.)
    Java as a platform has only one advantage over .NET from theoretical perspective: Java's limitations. .NET looks as yet another operation system (like Linux, Solaris or Windows). So, I suspect that too broad goal cannot be easy achievable despite all promises.
     
    And contrary: clearly defined goal within narrow scope can be achieved relatively easy.
    I position Java as OS for business applications (advanced CRUD + Search applications of different flavors). In this sense Java+J2EE+all patterns create perfect match for all business needs.
     
    And I think that even this scope is quite broad and there are many controversy around (EJB or not, CMP/JDO/CORBA, etc.)
     
    One size does not fit all. There is no silver bullet - Never ever will be.
     
    PS: there is separate discussion(s) about .NET on theserverside : http://www2.theserverside.com/home/thread.jsp?thread_id=16656&article_count=79 for instance
  48. "The ECMA standards I am referring to are: ECMA-334 (C#) and ECMA-335 (the CLI). That is all."

    Well, two "point'n'clicks" and you've got nice IMyFancyExcel greed in your app. Since this moment you're completely bound to beloved MSWin. How'd CLI help with it?
  49. .net has ECMA but I will bet Microsoft will ditch it as soon as it is inconvienient for them. Java is much bigger than just Sun. The opposite is quite true for MS .net.
  50. A decent article by Forester, but missing some key points/understanding of the market. Sadly, it seems like they interviewed customers but didn't really dig into *how* people are using application servers.

    Their biggest mistake is misstating the impact of open source. Reality is that two distinct app server markets exist: a Quick-Dirty segment and an Enterprise segment. The quick-dirty guys will use Jboss (much like they embrace Apache or Linux) b/c they don't care about things like vendor service and are doing a non-mission critical application. The enterprise segment will always buy an IBM or a BEA, just as they haven't replaced Oracle with PostGres or MySQL. (Using the same corrollary as the Forrester argument, one would assume that the RDBMS vendors would now be replaced wholesale by open source b/c they new offer ACID tx's. BullS**t.)

    Second big flaw is the Sun thing. Here are some things to remember about Sun:

    1) Sun is a hardware company. They will always be a hardware company. It's in their nature. You speak with people on their software side (non-Solaris) and you understand where the real talent is.

    2) Giving away software is a graceful way to exit the market. That's what Sun is doing. People aren't going to buy that crap. If Forester really did good customer interviews, they'd understand that.

    In the end, Forester has done a decent job here, but they ain't no Gartner. :D
  51. <quote>1) Sun is a hardware company. They will always be a hardware company. It's in their nature. You speak with people on their software side (non-Solaris) and you understand where the real talent is. </quote>

    Can't be more wrong. Look at j2se (hotspot, libraries,...), sun one directory, and other software products from Sun. There's a general misconception in the industry but historically Sun has produced better software than hardware. Sparc is not in itself a superior architecture, but Solaris makes the platform a Ferrari.

    Sun's future lies in the integration of its diverse software portfolio.
  52. <quote>
    Can't be more wrong. Look at j2se (hotspot, libraries,...), sun one directory, and other software products from Sun. There's a general misconception in the industry but historically Sun has produced better software than hardware. Sparc is not in itself a superior architecture, but Solaris makes the platform a Ferrari.

    Sun's future lies in the integration of its diverse software portfolio.
    </quote>

    I agree.

    The UltraSPARC 3, used in SunFire servers, is really inferior compared to IBM's Power, the Compaq Alpha, HP's PA-RISC, or even Itanium 2.

    Despite that, Sun is second in the high-end server space. THAT's not due competency in the hardware arena - that's the power of some pretty well engineered software.

    So all this balderdash about Sun not being a software company is just rot. They may not be a terrific software company, but they are pretty good.

    Sandeep.
  53. Half the problem with Sun is that McNealy seems to be obsessed with what everybody else (esp Microsoft) is doing, as well as trying to manage the company.

    For a company as big and in the thick of things like Sun, that's not a very good thing. That's where they lose track of things and don't deliver enough value.

    What's the value that Sun provides the J2EE community in terms of actual enterprise quality software? You'd think they'd have the best (or aleast #2) app server. You'd think they'd have enough expertise with high-end systems to come up with the best J2EE clusters.

    Hmmm....

    Sandeep.
  54. Their biggest mistake is misstating the impact of open >source. Reality is that two distinct app server markets >exist: a Quick-Dirty segment and an Enterprise segment. >The quick-dirty guys will use JBoss (much like they >embrace Apache or Linux) b/c they don't care about things >like vendor service and are doing a non-mission critical >application. The enterprise segment will always buy an IBM >or a BEA, just as they haven't replaced Oracle with >PostGres or MySQL. (Using the same corrollary as the >Forrester argument, one would assume that the RDBMS >vendors would now be replaced wholesale by open source b/c >they new offer ACID tx's. BullS**t.)


    If your analysis of the quick and dirty market includes multi-billion dollar companies you are correct. However, these days, very large companies are starting to move away from BEA and IBM to JBoss. Why? Real architecture not constrained by licenses, avoiding vendor lock-in, and push to save money. No more designing around license costs, but purely designing around what hardware you have to run your systems. The reality is that a lot of IT budgets continue to shrink. As they shrink, more people look for ways to cut costs. When they look at their app server investments, they see something that was bought during boom times and that is not really delivering the true value they believe they should have received. I think the days of assuming poeople will buy IBM or BEA are over, people want something that works and that is supported. JBoss fits that bill.



    >Second big flaw is the Sun thing. Here are some things to >remember about Sun:

    >1) Sun is a hardware company. They will always be a >hardware company. It's in their nature. You speak with >people on their software side (non-Solaris) and you >understand where the real talent is.

    >2) Giving away software is a graceful way to exit the >market. That's what Sun is doing. People aren't going to >buy that crap. If Forester really did good customer >interviews, they'd understand that.

    >In the end, Forester has done a decent job here, but they >ain't no Gartner. :D

    Your analysis of Sun is incredibly accurate. I would add a few more things to this. They are so arrogant to believe that their N1 vision which hinges on better software will manage the complexity out of computing. While IBM and HP are investing heavily in services, Sun is saying SunONE is the future of a easier to use enterprise connecting large grids of computers, etc. I bet my money on HP and IBM as people will always play a key role in making sure systems do and behave the way they are supposed to. Sun is a hardware company that has spent the last 4 years trying to innovate their software in the court room.
  55. Ben,

    You have not heard of IBM's SMART project which relates too DB2, WebSphere and probably many other future offerings.


    William Louth
    Product Architect of JDBInsight
    www.jinspired.com
  56. A decent article by Forester, but missing some key points/understanding of the market. Sadly, it seems like they interviewed customers but didn't really dig into *how* people are using application servers.

    Their biggest mistake is misstating the impact of open source. Reality is that two distinct app server markets exist: a Quick-Dirty segment and an Enterprise segment. The quick-dirty guys will use Jboss (much like they embrace Apache or Linux) b/c they don't care about things like vendor service and are doing a non-mission critical application. The enterprise segment will always buy an IBM or a BEA, just as they haven't replaced Oracle with PostGres or MySQL. (Using the same corrollary as the Forrester argument, one would assume that the RDBMS vendors would now be replaced wholesale by open source b/c they new offer ACID tx's. BullS**t.)

    Second big flaw is the Sun thing. Here are some things to remember about Sun:

    1) Sun is a hardware company. They will always be a hardware company. It's in their nature. You speak with people on their software side (non-Solaris) and you understand where the real talent is.

    2) Giving away software is a graceful way to exit the market. That's what Sun is doing. People aren't going to buy that crap. If Forester really did good customer interviews, they'd understand that.

    In the end, Forester has done a decent job here, but they ain't no Gartner. :D
  57. Forrester thinks:

    "Someone should buy Borland/Macromedia"

    I think the kind of people who fork out big dollars for an application server would be more likely to for out big dollars for Rational Rose type development software, than something that made developers more productive.

    Brendan
  58. Great IDE's for Java[ Go to top ]

    People who are not familiar with Java keeps on posting that there are no good IDE's out there (Forrester Research)...well here are some I have looked at and strongly recommened to try them out

    I think these IDEs are better than Visual Studio. Some of these will generate WAR files and deployment descriptor for you favourite App server.


    a. IDEA
    b. Websphere App Developer (Eclipse)
    c. NetBeans.
    d. TogetherJ
    e. JBuilder
    f. JDeveloper
  59. Seems like linux and Java will kill the MS beast

    http://www.vnunet.com/News/1137229

    IBM is greatly positioned for their Java IDEs and WAS runs great in linux