I desparately *didn't* want to be drawn into this thread, which I felt was initially interesting and useful but had descended into a bit of a bun fight. But this post finally did it.... I have to say, very well put Karl. It's refreshing to see some positive points come out of this discussion. In my opinion, one of the key benefits of J2EE, Servlets, JSP and the whole Spec/RI/CTS mechansim is that it creates a space where smaller enterprises can be commercially viable by providing compatible implementations that compete at various price/feature points. It's great that Oracle, IBM, Sun/Netscape etc. are out there with brand-recognised implementations that PC-Week reading IT managers feel comfortable with. But I don't think they would work as hard at releasing JSP 1.1 and Servlet 2.2 compatible engines if it weren't for people like Apache, Orion, PolyJSP, Resin out there with up to date implementations the moment the spec hits the net. This is where I think real innovation breeds. It's got nothing to do with integrating a browser with your OS... Regard Drew > -----Original Message----- > From: Karl Avedal [SMTP:[EMAIL PROTECTED]] > Sent: Sunday, January 30, 2000 6:03 AM > To: [EMAIL PROTECTED] > Subject: Can you trust a smaller vendor? (was Re: New article: "The > Problems with JSP") > > Dear Kevin, > > We are very happy to see that you like our product. However I am a > little concerned with one of your claims. > > You claim that a company will not dare to invest in a small company's > platform because it exposes them to a risk they do not want to take. > This is a correct observation. > > However, I fail to see how the argument you are putting forward has > anything to do with the Orion Application Server. > > The main point here is that Orion does not specify its own proprietary > platform but provides an implementation of the Java 2 Enterprise Edition > > specification. This means that we do not tell you to develop your > application for Orion but for the J2EE platform and then deploy it in > the application server that you feel is most scalable, most stable, > cheapest or whatever factors are important to you. There is no > investment in a proprietary platform whatsoever. > > I really hope that when you are deploying a J2SE application (a normal > Java application) you do not develop your application for a specific > J2SE implementation. If you develop an application for J2SE you can > choose to deploy it on any J2SE implementation, for example the Sun JVM, > > the IBM one or any other compliant JVM. When you start your project you > are not likely to see it as a big risk that you develop using one or > another JVM even if it is developed by a smaller vendor. The same should > > be true with a J2EE project. Develop your application according to the > specs and the choice of deployment platform can be changed whenever you > like. You can develop using one server, deploy using another one and in > the future you will hopefully even be able to deploy on a cluster of > servers running different J2EE implementations. > > This is in fact the main reason for J2EE to exist at all. By sticking to > > J2EE you gain the following advantages > > * No investment in a proprietary platform (no investment in one company) > > * Best-of-breed implementation. You can select the implementation that > suits your needs best. > > * Price competition between different vendors ensures good pricing. > > * The broad knowledge base that comes with an established standard makes > > it easier to find good developers, good education and everything that > comes with it. > > I would say that these factors should eliminate your fears about relying > > on a small company simply because you are not relying on them when you > select their application server. > > Now you might say that application servers will still not be compatible. > > You might argue that an open specification with different > implementations inevitably leads to bad compatibility problems. This has > > been the case with several earlier specifications. To avoid this several > > measures have been taken: > > * A Compatibility Test Suite (CTS). All J2EE compliant application > servers have to pass a number of tests to guarantee that they work as > the specification mandates. > > * A Reference implementation, the J2EE RI, is available to vendors that > are in the process of building J2EE compliant application servers (and > to everyone else as well). This allows them to make sure that their > application server is truly compatible. > > * Binary compatibility for applications. Binary formats like .war and > .ear files that can be moved between application servers ensure that not > > even recompilation has to be done when moving an application from one > server to another. > > Finally, I would like to point out that there is no reason why we, as a > smaller company, would not keep improving our server for as long as the > larger companies. Unlike a large company with lots of other products, we > > are very focused on the application server and for that reason there is > no chance we will stop developing and supporting it. A big company could > > decide to cancel the product at any time for a wide variety of reasons. > > Also, we might be a small company but what I think is more important for > > a company who plans to survive is the profit and the financial > situation. Unlike other companies who expand their sales force in > express speed we focus our resources on development. Our costs are very > low and sales would have to go very poorly for us to make us show > anything but a healthy profit, and I can't see that changing anytime > soon. And as long as we are operating with a profit (unlike most of our > competitors), why would we stop? > > My conclusion is that the important thing when deciding on your > development or deployment server is the actual application server > product. The size of the company that is developing the server is rather > > irrelevant. However, the companies that are small today might very well > be the ones that are large tomorrow if they can master the market and > provide the best solutions. > > Regards, > Karl Avedal > The Orion team > > Duffey, Kevin wrote: > > > (...) See, I argue the Oroin Application > > Server is FAR better than any other application server. Its only $1500 > per > > server, its 100% JAVA, its extremely simple to setup, it supports ALL > the > > latest specs (already servlete 2.3 and JSP 1.2 is being incorporated > into > > it..well, when the PR1 is released), and it has proven to be a far > faster > > performer than most other app servers. However, the downside is, it is > > > being written by a 2-man team! Pretty darn amazing to me..but still, > > because of this..its unlikely medium to large businesses are willing > to > > risk their company on such a product. > > ========================================================================== > = > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > FAQs on JSP can be found at: > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". FAQs on JSP can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html
