Discussions

News: The State of The J2EE Application Server Market

  1. The State of The J2EE Application Server Market (24 messages)

    Floyd has published an article about the Application Server Market. The article is a look back at the year 2000. "The server side java industry has gone through a whirl wind of change, this article will walk you through the years events and explain the trends and the players that will change the server side java landscape in 2001."

    Read Article Here

    Threaded Messages (24)

  2. Hi Floyd,

    A little correction on some facts:
    "only three vendors dominate the database arena: Oracle, IBM and Microsoft".

    Do you mean technically, on the number of installed versions, or technically ?
    I guess you know that there are other vendors out there who have a significant market share and especially in some specific markets.
    Anyway at least you shouldn't skip Informix, and Sybase, and there are others too.

    If you consult sites like www.tpc.org and http://www.wintercorp.com/VLDB/
    you'll also find other surprising powerful solutions for database systems.

    "and Oracle is now the undisputed leader in the database industry".
    Wow! Where did Oracle get that title ?
    Nomatter how biased I am on Oracle side, I wasn't really aware.

    Anyway the conclusions you draw from SQL world are a little bit wrong since the database technology is surpisingly more diverse and colourful than you try to suggest.

    And about Interbase and SAP, well, Interbase is a nice database and that's all, when did it happen that they were "once powerful".

    Though I guess that althoug you started from wrong premises you reached pretty good conclusions, so it doesn't matter that much.


    Cheers,
    Costin
  3. Costin,

    some analysis of the DBMS market can also be found at
    http://www.zdnet.com/intweek/stories/news/0,4164,2585343,00.html

    where it discusses the market penetration on the various platforms as at June 2000. In short DB2 reigns on mainframes and Oracle on most other platforms except Win NT/2000 where SQLServer is neck and neck. IBM are aggressively marketing DB2 on Unix and Oracle's pricing policies are playing into IBM's hands...
  4. Market share numbers[ Go to top ]

    As regards market share... Click on the following link see a view on the market share. http://cyberatlas.internet.com/big_picture/hardware/article/0,1323,5921_353701,00.html
  5. Floyd,
    You have conclusion as;

    "In 2001, J2EE will be used as the underlying platform for developing vertical niche applications and frameworks for specialized applications such as Web Services, Wireless, Customer Relationship Management, Process / Workflow automation and EAI. The job of the ISV and component developer will be to write these niche frameworks to be as portable as possible. An explosion in the J2EE component market is thus likely for 2001."

    What do you think about the utilization of J2EE with custimization for enterprise infrastructure projects? If we do not choice the server side java technology today for development of enterprise projects, won't it be a fault at tomorrow?

    Regards,
    Ghari

  6. Ghari,

      If I understand your concern correctly, you are suggesting that my conlusion implies that J2EE won't be used for custom development, infrastructure, even developing websites. I think it will definitly be used for such custom coding! The difference is that soon we will have a larger library of components to choose from, which will help simplify our custom development.

    Dennis,

      Thanks for pointing out that Gemstone is J2EE certified. That article was written over a month ago and is thus a bit dated. I will put a date into it to avoid conclusion.

    Regarding Oracle,

      Thanks for pointing out these marketshare figures guys. I will modify the text of the article accordingly. :)

    Floyd
  7. I guess I'll add some more discussion to the subject.

    First of all it will be hard for vendors to implement niche application such as CRM , Process/WorkFlow and the likes.
    Most likely established vendors like SAP, PeopleSoft, Siebel, Oracle and the likes will not port their packages towards J2EE, or those who would try will face a similar experience as Corel did when ported their Office to Java.

    Probably they will be satisfied with providing connectors (using JCA or whatever necessary) for some part of their clients.

    Another thing that happened to the relational database world and it doesn't seem to happen in J2EE market was the scenario:
    - First there was research and development (Dr. Codd at IBM)
    - Then there were the first implementations (IBM, Oracle, later Tandem, Sybase, Ingres etc ...) almost twenty years of implementations
    - Then the first major standard in 92 to which most vendors conform only to the entry level.
    - Each vendors has several particularities so that major applications are not portable "as is" from one vendor to another.

    Now we have to think that J2EE standards happened in a totally diferent scenario:
    - first there came the standard
    - second implementation
    - research in very, very limited amounts if any
    - the standard is looked upon like the wholy bible by vendors

    Well, now one has to consider which is better and what are the implications.

    From my part, I do expect that at some point in time one or more Java App server vendors will break the monothony and provide a better proprietary model.

    Costin
  8. Costin,

    First of all you need to recognize that academia is much different today than it was in the 1970's. Database systems and transaction processing was an active topic with a flurry of interest. These days we see continued interest in advanced / exotic TP models, but relatively little academic interest in the value that J2EE/EJB provides, namely a standard for re-usable applications.

    Let's also not forget that RDBMS' for years were ridiculed for being slow and useless in the real world (until later versions of Oracle changed that).

    Most research on J2EE is comparative in nature, not really in expanding the use of the spec, since the spec does not really contain any innovation beyond standardizing default component contracts and deployment models.

    So I would think you're performing an apples vs. oranges comparison for the sake of stirring controversy :)

  9. Stu,

    Sure it crossed my mind that I might be stirring controversy,
    but I didn't do it for the sake of controversy, it is only what I honestly believe it is a big problem today, at least for those of us who program Java, I guess it is a big bonus for MS camp.

    Do you honestly think that one can blame academic world
    for not showing interest in EJB "component contracts and deployment models" ?

    Or more specific with regards to Entity EJBs which are supposed to be the cornerstone of J2EE revolution,
    because everything else in J2EE is repackaging in Java context of already existing models , do you feel you have a sound programming model that will stay for another 30 years like the relational model did without any major change?

    If you don't, then perhaps there is a need for a little research to provide a solid foundation, instead of drafting more versions of the spec.

    Costin
  10. "Do you honestly think that one can blame academic world
    for not showing interest in EJB "component contracts and deployment models" ?"

    I'm not blaming them for anything, I'm just suggesting that it's not of academic interest, and rightfully so.

    "Or more specific with regards to Entity EJBs which are supposed to be the cornerstone of J2EE revolution,
    because everything else in J2EE is repackaging in Java context of already existing models , do you feel you have a sound programming model that will stay for another 30 years like the relational model did without any major change?"

    Which technology has lasted for 30 years without major changes?

    Not relational databases, certainly. (Unless you want to discount views, stored procedures, security, replication, outer joins, correlated sub-queries, nested tables, VARRAYs, etc.)


    COBOL has had at least 2 _major_ revisions (COBOL-85 and COBOL-2000).

    And why does a technology require academic roots to be successful?

    Speaking of COBOL, this was a standard that provided quite a bit of utility for decades without any academic support.

    "Or more specific with regards to Entity EJBs which are supposed to be the cornerstone of J2EE revolution"

    Says who? Is this meant to be provocative in some way, because I just don't get what you're implying other than being purely cynical.

    "If you don't, then perhaps there is a need for a little research to provide a solid foundation, instead of drafting more versions of the spec."

    This is easier said than done. Contract based programming and components have been a topic of research for quite some time, with absolutely no clear answers -- mainly because the problems with componentized software have little to do with computer science and a lot to do with politics, social issues, and communication. Academia doesn't care about those things, they've moved on.

    EJB's major benefit is that it is _standard_. It is something that lots of people agree upon, and doesn't suck so badly that it's impossible to use. Is it the foundation for the future? I don't honestly know. Part of me hopes not. But it is a start.

  11. "Who says that Entity EJBs are the cornerstone ... "

    I guess everybody, except a few people.
    I wasn't exactly saying are, I really meant "are supposed to be", and you probably also don't like them, and other people too.
    I guess it is a simple fact of life although unfortunate indeed.

    "Which technology has lasted for 30 years without major changes?"

    Again maybe I wasn't clear, but I wasn't exactly saying product, I was saying the "relational model".
    And almost everything you mentioned was not exactly a change in the relational model.
    You're right that relational databases do change, query language changed, but they are only the implementation of the model.

    "And why does a technology require academic roots to be successful? "

    I wasn't saying "academic", I was saying research, as was the case with the relational model.
    However , it would be nice indeed if the specs would borrow at least the "academic" rigor and style, instead of "because spec says so" and "let me show you how" approach.

    <example>
    Do they ever tell us why a ejbFind should return a collection of Primary Keys ?
    Because they say so and it is standard.
    </example>

    I guess I'll have to agree with you, it is a start or it can be a start.
    But I don't see the direction yet, it is a start if it spurs greater debate and more mind storming effort.

    Up till now, my perception is that the J2EE standard was used primarily with these effects on the server market:

    - great marketing tool, especially with mobilizing virtues in bad vs Evil, Sun vs microsoft approach

    - Annihilating real innovation and annihilating competition on technical merits.
      A lot of java app servers which were fine products either said "yes, sir" or they were practically annihilated by J2EE marketing machine. You say of WebObjects, I would mention also NetDynamics and there are many more

    - put a lot of projects into trouble by introducing unnecessary complexity (like what is fine grained and what is coarse grained and many more)

    And the list continues, but to avoid another agree to dissagree with you, I'll take your point that we're missing tools.

    So how can one really talk about Component Based Development when there are no tools ?

    Even the smallest definition of components has to include tool support, and at least two states: design-time and run-time state.

    Otherwise nothing differentiate a "component" from a library, framework, package you name it.
    It is the way VB and Delphi and ActiveX and JavaBeans work very effectively.
    The essential feature of components is that they work with little or no code.

    Where in the specs do we read about tools (I mean like IDEs not wizards to generate deployment descriptors) and design-time ??

    That's only an example where we do need research.
    What is so political after all, about "design-time" tools?
  12. Costin,

    As we've discussed in the past, I'm in full agreement with you that we definitely need more research in the enterprise Java arena.

    I just don't think that the people that normally do research (academics) are interested in what we're doing, and most companies won't (admittedly anyway) call their projects "research" (though usually they are playpens for toddler develoers).

    Codd's model evolved until the early 1980s as System/R and Oracle explored the implementation aspects of the model.

    One has a difficult time providing a mathematical reasoning model around something like EJB because it breaks a lot of the consistency models that map well to mathematical reasoning: side-effect free programming, true functions, etc.

    So the only real "research" we can do with EJB's is to develop real systems with it, note the problems, and fix. Unfortunately what we're seeing is that the majority of developers are still learning to tie their shoe-laces, and of those that know what they're doing, many aren't very introspective or observant of how things can be done better.

    Usually I see criticism without a clear possibility of a "better way".

    There have been practical research efforts lately trying to rectify that: the Sun Java Center's J2EE patterns is a start, for example. This site is a growing community of practitioners trying to hammer out what works. I am contributing my J2EE research experiences in the Codenotes series of books (www.codenotes.com) coming out within the next 6 months, etc.

    The EJB expert group could really serve us better if they opened up their meeting minutes. I guess JCP members don't have this problem, obviously, but sometimes the general community may have interest in the proceedings. I.e., what are the current problems on the EJB 2.0 agenda? The final draft has been collecting dust for 6 months. We've heard lots of rumblings about dependent objects / CMP being gutted -- are these rumors true? What will the alternative be? A once-a-year chance to talk to them at JavaOne isn't enough.

    Regarding things like findBy methods: definitely one has to wonder what they were thinking about.. but obviously someone had a good idea behind it, probably the ODBMS or O/R mapping vendors back in the EJB 1.0 days. These considerations have only been communicated in the expert group & to other JCP members... not the community at large.

    So, while you say research is needed, and I agree, I think the kind of research needed really isn't what you would traditionally think of as research... it's *hardcore* experience developing enterprise systems with transactions, re-usable components, etc. People with such experience (and the communication abilities to pass their experience on) are rare indeed.
  13. Stu,

    Well, this time we seem to agree on "what" but very little on how.
    I definitely agree that we should not expect someone from the academic world to come and rescue us, as they usually have different kinds of concerns than us.
    But I'll be first to admit that a little help from their part may have very positive effects.

    There are usual two aproaches on what regards breaking new grounds in various domnains.

    The first one is research first, experiment later and the other one is to do experiments first , and do the final model/theory later.

    Both of them are valid, and usually applies to different set of problems so no one can say which one is better but which one is better for a paricular situation.

    Having been a strong chess player, I tend to incline for the first one because in chess you can't "experiment", you don't get a second chance.
    So I try to first think deep and try see the consequences of my coding before I start coding, I'm not sure if this approach works well for software development and sometimes I try to escape from it.

    As to what regards the repproach of "empty criticism", I'll submit to it partially.
    But the fact is that being critical is first important, and second you won't solve a problem until you know you have one.
    If I don't come with alternate solutions it doesn't mean that I don't think about, or experiment with, it's just that not every one is to be expected to come up with well rounded solutions, and especially my employer doesn't pay me to come with the next revolutionary model in this particular area.

    I guess one other ideea of doing "research" is trying to develop an alternative, preferably open-source model for 3-tier applications.
    I have some ideas, I suspect you also have some, I'm pretty sure that if we send them to ejb-comments at sun dot com it won't matter.

    What do you think ?
    If you feel like it, send me an email at costin.cozianu at cis.canon.com

    Costin
  14. General comments for Floyd:

    Overall a good analysis and set of predictions.

    What needs to happen in 2001:

    - Tools support! Most deployment assistants out there are train wrecks. Inline software got transformed into JFX which have something out in beta that I haven't looked at. BEA doesn't even have any EJB configuration tool in 6.0! Security management (key store management), component assembly tools, etc. are all non existent.. It took Sun to write a Forte J2EE IDE framework to foster any restarts to this industry segment... perhaps there's no money to be made?

    - Documentation! This is noticably given back-burner status by most vendors. I still see out-of-date words from GemStone 2.x in their 4.x documentation. BEA is pretty good, admittedly.
    - I think add-on services will be a must. J2EE and EJB by themselves provide minimal value-add for developer productivity. Most add-ons are "mile wide / inch deep" marketecture solutions and nothing of major value. This needs to change. SOAP bindings, B2B workflow roating, EAI tools, are all emerging, thankfully.

    - People need to get this "standards and only standards" mantra out of their heads and realize that to deliver a solution we sometimes need to embrace a vendor's technology. I've seen a government group reject TOPLink because they don't want to be tied to a vendor; yet their custom persistence framework took 6-8 months to build and sometimes breaks!

    - Find a good way to foster adoption of container managed persistence. Some vendors have come up with usable, fast solutions (TOPLink). Others are on the way (WebObjects 5)...

    Things I differ on:

    - HP/Bluestone has a ways to go. I give it 18 months before it moves up in marketshare. I really think i-Planet and Oracle 9i App Server are the two growth servers for 2001, with i-Planet taking a solid #3. I would really like to see Borland retain their foot hold too, they have an excellent offering.

    - I think we'll see further fading of the ankle-biter app servers... ATG Dynamo, Silverstream, Gemstone, Persistence, etc. Persistence is being kept alive by its few but large clients, but otherwise has no market share. Brokat/Gemstone can make it if they refocus around their object database and integrate with other servers (though Object Store and Versant have had limited success in this arena from my understanding).

    Gemstone's main failing is that it needs new tools and frameworks to solve the basic problems of getting up and running with its cache (indexes, ad hoc queries, basic business object features like relationship management and change tracking), and maybe even a [wildly risky but innovative] shot at asynchronous RDBMS synchronization (targeting Oracle at first, moving on to others later.)

     Orion and jBoss, while excellent, will probably remain niche systems. Orion in particular is suffering from its closed-source model as the two authors are so swamped...

  15. Hey guys, before I respond to other comments, I wanted to point out that there IS a reason for why ejbFinders return primary keys.

    The reason is to support caching. By returning a primary key, the application server can check its internal cache to determine if an instance of an entity bean with this primary key has been cached, if so, it just serves that, if not, it ejbLoads it from the database.

    So you see, if the alternative were true (ejbFind returned pre-loaded entity beans), then this would mean entity bean data was loaded each time a finder is called, and caching would be impossible.


    Now, onto other comments:

    Stu, I agree with you on your vision for 2001. Tools and documentation are fast maturing. One year ago, ejb tools were still in development (remember Persistence?), today, most major application servers have shipping (and reasonably mature) development environments - Visual Age, Visual Cafe, Web Gain, etc). Together, WebGain and rational are both have shipping UML modelling tools for EJB, with time these tools will continue to mature.

    Add-on Services. Here we completely agree. As my article points out, 2001 will be about value adds on top of EJB. EAI/Workflow tools are finally getting the attention they deserve. The most mature EJB integrated Work flow product is probably WL Process Integrator. HP and Silverstream will both have Workflow products out by Java One, its only a matter of time until that side of the market matures.

    Adoption of Container Managed Persistence? Once EJB 2.0 becomes widely supported hopefully this dream will be realized.

    Floyd
  16. Folyd,

    You could have given us credit that we knew what were the probable intentions of the specs with regards to findXXX.

    However this thing may help in some situations while in the general case is bad, sometimes is quite ugly, and the probability of this being bad exceeds by a large margin the probability of being good over the space of general situations that are encountered in typical database access programs.
    A more flexible approach allowing for alternatives would have been far better.

    I give you credit that you know why it is bad, but it wasn't exactly the point that this particular way of doing things is bad.

    The point was that it is mandated by the spec without any consideration and without any argmunet on why anyone should program in this manner.

    I guess the danger with the wide adoption of EJb 2.0 CMP at least in the way things are right now in PFD2 is that more and more developers will fail to judge with their heads and adopt blindly the EJB twisted way of accessing relational data.

    I hope we won't come to that, and I'm already eagerly waiting for the EJB 3.0 to fix things .

    >Once EJB 2.0 becomes widely supported hopefully this dream will be realized.
    Watch out for the nightmares to come :)

    Cheers,
    Costin
  17. Costin,

    "But the fact is that being critical is first important, and second you won't solve a problem until you know you have one. "

    Oh, I recognize the value of criticism, and your presence here as Her Majesty's Loyal Opposition is greatly valued. I just find that the more valuable approach is to provide leads/hints of solutions when proposing a critique.

    Obviously getting the critique out there is important, but I think as an example, entity beans have been a dead &beaten horse since the 1.0 days... we now need to find out where the value lies and how to make them better (vs just not using them).

    Floyd,

    Regarding caching, I must respectfully say that this is no excuse for finders to be so poorly designed in the case of BMP. Don't screw the 95% for the 5%. Cross-transaction caching implies commit option A, which means A) fully synchronized beans in the conatiner, and B) needs database ownership . Both are horrible tradeoffs to make.

    Only CMP with proprietary extentions can provide accurate caching.

    Think of the following BMP scenario:
    Order -> 1:M <- OrderItem <- 1:1 -> Item

    If two orders contain the same item, and they're cached, and an Item is updated in one bean, the other bean's data would be out of sync (assuming commit option A) because there's no global-uniqueness amongst dependents.

    The only solution is to use fine-grained entities... and the only way to make fine-grained entities scale is non-spec hacks like a) pass-by-reference semantics, and b) use fat keys or a stateful session as a "data cache" between your findXXX and ejbLoad call.

    Coarse-grained BMP entities also break down when your dependents have "hot spots" of contention, because commit option A forces the container to lock the *whole bean*.

    So entity beans with BMP become effectively useless
    except for trivial cases.

    With some CMP products, at least you can get dependent object uniqueness in the cache (TOPLink does this, as does WebObjects). EJB 2 pfd2 is a positive step at potentially fixing some problems... need to look further at it.

  18. "I guess the danger with the wide adoption of EJb 2.0 CMP at least in the way things are right now in PFD2 is that more and more developers will fail to judge with their heads and adopt blindly the EJB twisted way of accessing relational data. "

    Costin, please provide an alternative to this "twisted way". I've suggested a query-API instead of EJB QL. What do you suggest?

    The goal is to maintain conceptual simplicity between the relational & object models. Not to kill either model.
  19. Stu,

    I guess you should have given credit to Floyd after all, even if he pretends he's not aware of certain inconvenient things :)

    I'm with a terrible migraine today and certainly far from me the idea to provide alternatives.

    But one alternative has been provided as early as 1992, the research has been there for a little longer.
    There might be other that I don't know of.

    Take a close attentive look at his URL:
    http://hpdrc.cs.fiu.edu/library/books/datades-book/

    Too bad the industry doesn't pay attention to research.

    Costin
  20. Don't worry, I have a migraine today too (honestly), which is why I won't chide ya for the cop out <grin>

    I'll look at the link.

    Stu
  21. Some comments[ Go to top ]

    Just some comments guys(are you still there?),

    The biggest advantage of EJB2 is that all middleware services and component glue (relationships, finders, references) in EJB2 are declarative. You might think EJB2 relationships are late and have nothing innovative. Well, yes, but when in EJB1 declarative transactions were introduced you wouldn't say something like "yet another transaction programming API". (May be relationships and navigation in EJB2 would be better when layered over ODB relationships like declarative and JTA transactions were build upon CORBA OTS, but relational storage doesn&#8217;t have this layer)
    IMHO today the biggest gap in J2EE overall in the first place is tools imperfection (with some exceptions like Togethersoft), not pure spec. imperfection. Having a good tool, EJB20 declarative model will provide you with better productivity over all programmatic propriately models. ( Of cause I like that Versant ODB provides me with advanced services like long transactions, session control, nested transactions, multisessions, different locking models ect.(It is a big deal comparing with Oracle that gives you only savepoints.) But the ordinary project will probably do not need
    them at all)
    Today the trend is raised complexity of big applications consisting of components (the big picture) not the complexity of advanced services and algorithms. So this declarative model is worth all those architecture imperfections. Again do not forget that J2EE and EJB were designed to be RAD architecture.

    Costin,
    As of theoretical foundation, J2EE specifications are only contracts between developer and container, they do not introduce any new architecture models as relational QL did. So where to do research? There is no Codd's model speaking SQL analogy. BTW there is OO architecture itself which in it's turn has theoretical foundation and there were a lot of researches in this area. Some of them resulted in things like UML. OO does not depend on any implementation be it language or extensions like J2EE. So you better compare relational vs OO but not J2EE.
    The way that things in J2EE should be done can't be defined through theoretic modeling.

    As of EAI, I agree that pluggable enterprise services implementation will remain mostly proprietary. But these services will be able to talk each other through connectors (Otherwise they will not be pluggable). So you could build your stack of services from different ISV. This seems to be a compromise between complete propriately solutions and fine-grained services supplied by ISVs as EJB components. The last approach will remain to be for building you own services and applications, though it could be usefull in some other cases as extensions to general middleware services like data mining ( As MS&#8217;s OLE for data mining .)
  22. For deployment, try ant my freind...

    jakarta.apache.org/ant

    It truly kicks ass.
  23. Floyd,

    It is a great article on J2EE appserver. I think
    it is the best so far.

    You mentioned about Borland Application Server
    and its press release on Dec 15, 2000.

    The fact is that Borland Application Server
    (former known as Inprise Application Server)
    was released on DEC 1999. And it was the
    first Application Server fully
    Integrate EJB 1.1 and CORBA
    http://www.borland.com/about/press/1999/appserv4ships.html

    Just FYI

    TuyVanC
  24. Interesting article :)
    But there are some inaccuracies though
    Brokat Advance Server(Gemstone/J) IS J2EE certified!

    See http://www.brokat.com/en/news/pr_en20010410.html
  25. Great article Floyd! Article presented good information on trends in server side java from ISV perspective.

    Bye for now,
    Reema.