Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Strategies & Market Trends : Gorilla and King Portfolio Candidates -- Ignore unavailable to you. Want to Upgrade?

To: Judith Williams who wrote (44845)	7/23/2001 9:11:55 PM
From: Thomas Mercer-Hursh	Respond to of 54805

For some of us, understanding the technology still qualifies as heavy lifting. :) Believe me, this is true of many CIOs as well; real expertise, particularly balanced expertise that doesn't simply assume that their own product is the best, is rare. The enhancements are not "proprietary extensions" although they are both proprietary and extensions. I think this is an area on which one must keep a clear vision. In the pre-J2EE appservers, they genuinely were proprietary and deciding to switch could indeed be a painful experience. In the J2EE era, supposedly, one should be able to switch. A company may provide added value in the form of EJBs or complete prototype applications or whatever, but in theory one can take the EJB and run so it doesn't provide the same kind of lock-in. Note, by the way, that this can be unfortunate. Forte's initial J2EE product included development tools, deployment tools, and an appserver which, since distributed events were missing from J2EE, provided these through proprietary extensions. With Sun's acquisition they pulled back this product, decided to use the standard J2EE iPlanet appserver and deal with some other issues (like the offensive aspect of having the Java tools actually written in Forte's OO4GL instead of Java!). The revised version coming out this summer is thus missing distributed events, which I consider quite basic to this class of application and the best one can do is to fake them using JMS ... not at all the same thing. To some extent, what constitutes a tornado or a gorilla will always have shadings of difference depending on who is drawing the distinctions. Indeed, that is one of the tricky aspects of the gorilla game since drawing to narrow a market and declaring a gorilla in that market may indentify a trivial gorilla, i.e., a gorilla that is not a real gorilla at all because the market will soon shift and could easily leave that company behind in a way that a true gorilla won't be. Of course, one of the reasons that a true gorilla won't be is that it is in control of the architecture and thus can control the direction of change. This is not something I think you can say of the J2EE era and beyond appserver since everyone is conforming to a shared standard and many companies participate in the definition of the future evolution of those standards (although Sun has a different sort of say than anyone else). One could make the argument that this means, by definition, that there can't be a gorilla of Java appservers.