Slashdot Mirror

Absoultely. You're certianly not going to run .NET on Linux (well at least not yet, until Mono is released). J2EE gives you the option of picking an OS. It also works the other way around. If you already have Windows boxes as servers, you don't have to switch to Linux just to take advantage of J2EE.

There are a few more open-source J2EE app servers than just Jboss and Tomcat - and its good that these are targeting different markets (just like the various Linux Distributions target different types of user/server markets )

Yes, different application have different needs. One is allowed to chose which application server the feel will benefit their application to most. Resin is a good example of this, providing a very nice way to do XSLT.

Will the companies that sell J2EE app servers today be in some sort of trouble if J2EE becomes a commodity? No, they're not in trouble at all because they make money from their unique products and services around J2EE.

Exactly. No longer can these companies "shit in a box and mark it garunteed." (Tommy Boy was on cable yesterday). They actually have to work hard to make their product give a signifigant advantage over the OSS versions and be worth the money, unlike some other giant software company we know ...

this explains your previous post as to the technical know-how to get it running - i suppose it took you the whole day to get a hold of mod_webapp.dll?

unfortunately i consider the docs on the web and especially on the tomcat site woefully inadequate when you "have" to install the connectors from source onto a unix system. the modjk2 & webapp's quality is diminished by their docs. in the end i went with resin, which was a good deal easier (their documentation was accurate)

Instead, use the money to license a copy of Resin which is, for lack of a better description, Tomcat on Nitro. It follows the reference implementation of JSP and Servlets just as well as Tomcat does, and even the default configuration, which is tuned for development, outperforms Tomcat.

The configuration of Resin is almost exactly like the config of Tomcat, so I honestly don't see why you'd pick Tomcat over Resin (unless you were having trouble getting the 1.2 or 1.3 JDK installed on your FreeBSD box, something that is historically difficult to do).

If you're going to look at benchmarks, I'd suggest looking at both the Caucho and Chamas benchmarks:

Caucho benchmark
Chamas

It's worth keeping in mind that Resin is Caucho's main product. I'm not claiming that Caucho distorted their benchmark in any way; I'm just pointing out that they have a vested interest in the outcome of their benchmark.

Similarly, Chamas is the originator of Apache::ASP. Again, I'm not claiming that Chamas distorted their benchmarks in any way, but it is always wise to be aware of potential conflicts of interest. Though in the case of Chamas, the potential conflict is respect to Apache::ASP vs. other technologies rather than Java vs. PHP.

Hmm, I use both Java (JBoss) and PHP. Maybe I should make my own benchmark.

I'd say that if you are primarily interested in failover, message queueing, and the other stuff addressed by J2EE, go with JSPs/servlets/EJBs. If you want to build and deploy something quickly, cheaply, and with low performance overhead, go with PHP.

Actually resin is open source but it is non-free. It is not licensed under the GPL but it is still "open source".

Nope, "Commercial and other paid users must purchase deployment licenses" means it isn't open source.

Tomcat is cool, but I find Resin (Caucho.com) to be easier to configure and use, especially with Apache.

I use Resin, standalone, on 7 load balanced web servers for one of my clients. I have been pretty happy with it. I also use it for my tiny Java web hosting biz &ltShamelessPlug&gt(europasystems.net).&lt/Shamele ssPlug&gt

Try any of them. I use Resin. Others are happy with Tomcat. I've never heard of Jetty, but it may be good, too.

The important thing is that you write your application to the servlet spec. If you do that, switching servlet containers will be completely trivial. So if you later decide you've outgrown Tomcat, try something else instead.

We use resin, which is cheap ($500/host) but not free and it performs wonderfully. I've played around with jetty and tomcat but they just aren't as easy to configure and their documentation, speed, and apache integration are lacking. Resin is straight forward, fast and works well. I have also heard good things about Orion Server which recently became the basis for Oracle 9i and is also a pretty good bargain at a few thousand dollars per host.

We are using Tomcat but haven't really put it in any large, production environments, though i've heard complaints about Tomcat not being industrial strength. My understanding, however, is that the next release, which is in 4.1.x beta releases now, is much more focused on performance improvements and we've seen it perform better than 4.0.x and 3.x versions.

Also, I've heard a few people rave about Resin and say that it's really fast.

http://www.caucho.com/

Here are some good reasons to use Resin:

• Fast, reliable, scalable
• Easy configuration
• Full source code provided under a "Developer Source" license, which makes it competitive with "free" products, at least from a commercial perspective
• Development use is free - no licences need to be purchased for development and testing purposes. Runs well on Linux as well as Windows; latter can be useful for test deployments on developer machines
• Inexpensive to deploy: $500 per server for the JSP version, $1000 for the EJB version; additional for priority support options.
• Commercial support - see their pricing page.

Despite any appearances above, I'm not associated with Resin, except as a customer. I first heard about it here on Slashdot, a couple of years ago. We evaluated it and eventually switched a number of applications from both Tomcat and commercial servers and have never looked back.

Other servers that might be worth looking into are Orion and JBoss, but I don't know how they compare on some of the points above. The availability of commercial support from the vendor can be a clincher, and the source code provides some insurance against the vendor disappearing.

I agree with all the cautionary comments about Tomcat, although we haven't worked with it for some time now.

Here are some good reasons to use Resin:

• Fast, reliable, scalable
• Easy configuration
• Full source code provided under a "Developer Source" license, which makes it competitive with "free" products, at least from a commercial perspective
• Development use is free - no licences need to be purchased for development and testing purposes. Runs well on Linux as well as Windows; latter can be useful for test deployments on developer machines
• Inexpensive to deploy: $500 per server for the JSP version, $1000 for the EJB version; additional for priority support options.
• Commercial support - see their pricing page.

Despite any appearances above, I'm not associated with Resin, except as a customer. I first heard about it here on Slashdot, a couple of years ago. We evaluated it and eventually switched a number of applications from both Tomcat and commercial servers and have never looked back.

Other servers that might be worth looking into are Orion and JBoss, but I don't know how they compare on some of the points above. The availability of commercial support from the vendor can be a clincher, and the source code provides some insurance against the vendor disappearing.

I agree with all the cautionary comments about Tomcat, although we haven't worked with it for some time now.

Here are some good reasons to use Resin:

• Fast, reliable, scalable
• Easy configuration
• Full source code provided under a "Developer Source" license, which makes it competitive with "free" products, at least from a commercial perspective
• Development use is free - no licences need to be purchased for development and testing purposes. Runs well on Linux as well as Windows; latter can be useful for test deployments on developer machines
• Inexpensive to deploy: $500 per server for the JSP version, $1000 for the EJB version; additional for priority support options.
• Commercial support - see their pricing page.

Despite any appearances above, I'm not associated with Resin, except as a customer. I first heard about it here on Slashdot, a couple of years ago. We evaluated it and eventually switched a number of applications from both Tomcat and commercial servers and have never looked back.

Other servers that might be worth looking into are Orion and JBoss, but I don't know how they compare on some of the points above. The availability of commercial support from the vendor can be a clincher, and the source code provides some insurance against the vendor disappearing.

I agree with all the cautionary comments about Tomcat, although we haven't worked with it for some time now.

Here are some good reasons to use Resin:

• Fast, reliable, scalable
• Easy configuration
• Full source code provided under a "Developer Source" license, which makes it competitive with "free" products, at least from a commercial perspective
• Development use is free - no licences need to be purchased for development and testing purposes. Runs well on Linux as well as Windows; latter can be useful for test deployments on developer machines
• Inexpensive to deploy: $500 per server for the JSP version, $1000 for the EJB version; additional for priority support options.
• Commercial support - see their pricing page.

Despite any appearances above, I'm not associated with Resin, except as a customer. I first heard about it here on Slashdot, a couple of years ago. We evaluated it and eventually switched a number of applications from both Tomcat and commercial servers and have never looked back.

Other servers that might be worth looking into are Orion and JBoss, but I don't know how they compare on some of the points above. The availability of commercial support from the vendor can be a clincher, and the source code provides some insurance against the vendor disappearing.

I agree with all the cautionary comments about Tomcat, although we haven't worked with it for some time now.

I've got no experience with Resin and not too much with Tomcat. (I've used JRun and Websphere in the past and I like them both.) Anyways, there is a company at my local Java Users group that really speaks highly of Resin - I think this is the link.

Obviously it's not open source which isn't exactly what you're looking for. On the other hand, what I hear is that it is fast, stable, and inexpensive. ($500 per deployed server.)

BEA's a good server, if slow, once you get around the absolutely awesomely bad management tools they tout as being so good. (Hint: they're not. If they work for you, great. We've found that we end up deploying the same applications multiple times, with restarts, in order to get the thing working correctly; this is with BEA support riding alongside to make sure we're not doing something stupid. We weren't.

WebSphere... IBM, IBM, IBM. The best compliment I've ever heard about Websphere was from a fan, a developer who loved it: "It's not that bad..." (Yes, it is. In IBM's sales meetings, they crow about how they helped design the entity aspects now-hopelessly-muddled EJB spec... and then later in the meetings they denounce using entity beans altogether because WAS can't give you any good performance with them. Plus, being tied to WSAD isn't my idea of a good time.)

JBoss is really pretty nice - it's built entirely around a component architecture, so you can swap out the Tomcat crap if you need to and replace it with something that actually works. (The default servlet container that comes with JBoss is Jetty, which you should replace with the current version of jetty if you use JBoss. The Jetty that ships with JBoss has a jasper error, jasper being a component from Tomcat.) The only issues I have with JBoss are related to its strengths: the component architecture means that each component chooses how it's administered, so you end up not only learning how to handle JBoss itself, but you have to learn how to configure Jetty, or this product, or THIS product, or THIS OTHER product... I prefer one ring to rule them all, etc.

As far as performance reviews, use google! :) I've done some informal performance reviews, and I've found the two best performers were Resin and Orion, with Resin being a few milliseconds behind Orion in terms of servlet and JSP performance.

Try Resin, a non-free open-source servlet/JSP server. It can run standalone or as an Apache plugin and absolutely screams. It works great with the IBM JDK under Linux and has very cheap licensing fees and incredible developer support. I myself am not partial to the whole Java phenomena, but if I had to use a web server for serving up such code, I wouldn't hesitate to use Resin.

Sometimes, one has to step back from the plethora of big-name projects and realize that people are making considerable effort righting the mistakes made by the early pioneers of that medium.

And sometimes, paying a little for a server engine ain't such a bad thing. Most companies with budgets can afford cheapo licenses.

I'm a J2EE developer. I mostly use JSP/Servlets, but I have a couple EJB container apps where it makes sense. I've made a selection of books I think people interesting in getting into this market should own.

Go to http://www.starvingmind.net/tech.php and check them out.

Changing topics, I have been experimenting with a servlet container called Resin, which people in the industry seem to regard as the fastest for JSP/Servlet apps. Development License is free, production license is $500 IIRC. Worth looking into once JSP/Servlet performance becomes an issue for you. It is not Open Source, but it looks to be a very high quality product, which runs fine on Linux.

-Pete

Well, if you don't want to listen to me, let the nnumbers speak for themselves. Resin+Apache pushes out twice as many pages/sec on a database-backed site than PHP can.

Apache is a web server... iPlanet is a J2EE implementation. Apache is a great web server... iPlanet is a shitty J2EE implementation. True, iPlanet will serve up web pages, but if you aren't developing an enterprise-level web application, then it's like using a hammer to push the thumbtack into the wall. A broken hammer, but a hammmer. (I've done this by the way, and the plastic part of the thumbtack will break before the wall gives.)

I use weblogic 5.1 at work, and I guess it's okay. I mainly deal with the servlet side of things, as opposed to EJBs or JMS or any of that, and the servlets that it generates are not that efficient. Nor is the generation itself efficient (which doesn't impact runtime, but does impact my sanity as I reload pages). Anyway, wl5.1 feels like molasses in January in Greenland, but I'm sure it's not as bad as it feels.

At my previous company, we used Resin, which was pretty nice, but it's not a complete J2EE solution, it's just a small and fast servlet container.

If I were to start a new project, and I needed JMS/EJB/etc, I would probably investigate JBoss, which is OSS. If needed just a servlet engine but MIGHT need the other stuff in the future, I'd use Tomcat (also developed by our friends at Apache)... if I just wanted a servlet engine and that's it, I'd probably stick with Resin, which has the source available and is free for non-commercial use.

Maybe it's not OSS, maybe it's just Apache that kicks much ass. Xerces/Xalan/Tomcat/Struts/Apache. Damn, you have everything there for web application development (in Java anyway), and it's good and you can read the code, which I've used many times before. I've cursed weblogic many times for not being able to read the code (of course JAD helps for that sometimes).

My point is, iPlanet is not the counterexample to Apache, or Tomcat, or JBoss... iPlanet is horribly broken and bad. Which is strange, since it emerged from Netscape Application Server, which has been around for, well, since before I knew what the hell an Application Server was. Weblogic (maybe 6.1 or 7.0 is much better, we need to upgrade) works and is popular, but is horribly, HORRIBLY expensive for a production license.

-If

Dont Use JRun. You can use Resin for the just about the same price, its faster and you can evaluate for free ( no thirty day gimped development versions).

This was my final year project thesis. Just remember the golden rule unstructured 2 structured == convert 2 XML I wrote a [very bad] program in C++/Perl/tcsh IPC=pipes to add XML tags to English, and then index them into a search engine which would use the lingual data stored in the XML tags to help the search.

NIST does a MASSIVE competition on this annually. I don't want to be an XML-buzzword whore <Arnold Schwarzenegger accent> (XML commando eats Green berets, C++, Java, Perl, COBOL for breakfast)</Arnold Schwarzenegger accent> but you can't beat XML for easily converting anything that you can make sense out of into computer readable format. Real h3cKoRs use SGML, but us underlings have to stick with things we can understand like XML. As for expandability, if we want to encode something else into the document, then just tag-it-and-go

It took me 200 hours to fish out all these links (before the Google days), I don't want anyone to have to waste as much time as I did feeding the search engines exotic foods. It's a year old so pardon me for the odd broken link, armed with these you could probably turn jello into XML ;-)

My favourite bookmarx
PROJect[21 links]
Beginners' Guide[13 links]
Berkeley Linguistics Dept. Course Summaries, general stuffzzzzzzzzzzzzzzCryptic IR Vocabulary defined
Explanations of weird words like hypernym zzzzzzzzzzzzzzHow do we produce and understand speech
How Inverted Files are Created - Univeristy of Berkeley zzzzzzzzzzzzzzNLP Univ. of Indiana, very good basics e.g. word sense d
Simple langauge - useful.... zzzzzzzzzzzzzzWhat is Natural Language Processing, links
What is POS tagging........ zzzzzzzzzzzzzzWord Sense Disambiguation defined
Word Sense Disambiguation in detail, scroll down far zzzzzzzzzzzzzzWord Sense Disambiguator - LOLITA (tested at MUC-7 and SENSEVAL competition as best)
XML for the absolute beginner

HTML, XML stuff + parsers[19 links]
Apache plug-in that uhhh does stuff with XML zzzzzzzzzzzzzzConvert COM to XML
convert XML, HTML to Unix pipeable formats zzzzzzzzzzzzzzconverters to and from HTML
expat XML parser zzzzzzzzzzzzzzHTML Tidy - converts HTML 2 XML + source code!!
Parse DB (RDBMS, whatever) to XML zzzzzzzzzzzzzzPerl-XML Module List
PHP Manual XML parser functions - what the hell are they talking about, PHP Virtual M... zzzzzzzzzzzzzzPublic SGML-XML Software
Pyxie - XML Processor for Python, Perl, etc. zzzzzzzzzzzzzzSGML+XML tools.org
The XML Resource Centre - massive number of links zzzzzzzzzzzzzzW4F wrapper - wrapper converts XML to HTML
XFlat - convert flat file into XML zzzzzzzzzzzzzzXML Parsers and other XML stuff
XML.com - Parsers, etc. zzzzzzzzzzzzzzXML-Data Catalog System - uhhhh looks close
XTAL's general converter - convert anything 2 XML

other Background[8 links]
Is Linux ready for the Enterprise, scalable... zzzzzzzzzzzzzzLinux reliability
Linux Versus Windows NT, Mark(sysinternals bloke) zzzzzzzzzzzzzzPC reliability (pcworld)
SPEC - Standard Performance Evaluation Corp. zzzzzzzzzzzzzzSystems benchmarks
TPC - Transaction Processing Performance Council zzzzzzzzzzzzzzUnix Beats Back NT In EDA Workstation Arena
Proper TREC(-8) QA systems[2 links]

pg. 387 LIMSI-CNRS pretty deep parsing[2 links]
More links....
NLP, IR links - lots to corpii, etc.

pg. 575 U. of Ottawa and NRL (shit system, got 0%)[1 links]
LAKE Lab
pg. 607! University of Sheffield (crap system, but OPEN SOURCE!)[2 links]
GATE - FREE IE app w`source code
LaSIE - ER, coreference, template (cv)

pg. 617 Univ of Surrey (inconclusive matches)[2 links]
System Quirk - Or is this their search system..... Hmmmmmm
Univ of Surrey - pointers (hopefully this is their WILDER search system...)

SMU - Pg. 65[1 links]
Natural Language Processing Laboratory at SMU

Textract[2 links]
Cymfony - Technology
Textract - State of the Art Information Extraction

Xerox uhhhhh maybe[1 links]
Xerox Palo Alto Research Center
(OVERVIEW) 1999 TREC-8 Q&A Track Home Page
NLP bloke, Univ Sussex


Tcl-Tk[4 links] Tcl tutorial
Tcl-Tk Contributed Programs Index
Tcl-Tk Resources, sources
TclXML - manipulating XML using Tcl-Tk
Artificial Natural Language - Is this what I'm trying to parse into...
Comparison of Indexers - Prise vs. Inquery vs. MG, etc.
Eagles - Language Engineering Standards
Language Technology Group - lots of modules!
LDC - Linguistic Data Consortium, lots of corpora
Lexical Resources
Links 2 resources, indexers.....
Lots of IR stuff, University of uhhh
Managing Gigabytes Indexer
Managing Gigabytes Manuals and stuff
Htdig search system
NLP & IR (NLPIR, NIST) Group
OVERVIEW OF MUC-7-MET-2
Perl XML Indexing - XML search engine type thing
Phrasys Language Processing Software Components (money)
QA HCI bullshit
SIGIR - TREC-type thing, resources
SMART indexer system documentation
Text REtrieval Conference (TREC) Home Page
The Natural Language Software Registry
Thunderstone IE and IR products
WordNet - FREE DOWNLOADABLE lexical English database

Page created with URL+, nice utility for working with internet shortcuts

Be sure to try a newer version of Tomcat. Version 3 was the reference code given to the ASF by Sun and was quite inefficient. Version 4 was a complete refactoring and it shows.

If you still have issue with the speed of Tomcat 4 or don't want to try again with Tomcat in general, there's always Resin.

With regard to EJB, now you've met someone who's used them, likes them, and has found that, implemented correctly, many EJB engines do quite well.

And Cocoon is no longer just a presentation layer. Unfortunately this hasn't been advertised enough and there is still work to be done in the area. But yes, one way of working with Cocoon is through an EJB backend although this is not necessary.

The site seems to work fine to me. Even if it is not "as fast as Perl". If you want more speed than Perl and ASP/VB provide, you should use Java, Resin Benchmark

That's what I use, but not for the speed, I use it because I like a clean OO language, and I am familiar with Java, so coding takes me less time than if I were to use perl or ASP/VB.

When IT people at one of my clients, a company with about 200 employees, were saying that they had heard bad things about Microsoft's Proxy Server 2.0, I reinforced that and explained to them how bad Windows is in general when it comes to Internet-related stuff, and why Unix-based systems are better. I suggested that they could use a Linux box with Squid as their proxy server, and that since it would be a dedicated-function box, it wouldn't have large maintenance overhead. I explained that Squid is used by large service providers and can handle big loads.

They went for it, and have been running Squid on Red Hat for some time now. Pressing my advantage, I suggested that they could switch their use of SourceSafe (version control) to CVS and getting much snappier operation across the Internet when developers are working from home. I demonstrated this to them, and they were convinced. They now run CVS for version control, too, using the WinCVS client.

The same company tried out Jitterbug for bug tracking. This wasn't as successful. There's now some talk of trying out Bugzilla. But I no longer have to evangelize this stuff, they're sold. They've received the threatening license letters from Microsoft, and have even gotten to the point of considering replacing Microsoft Exchange with an IMAP server. The only thing holding them back is good centralized calendar software. Anyone know anything good? It doesn't have to be free.

Another area where this company has moved in a more open direction is switching from Microsoft's ASP for web apps, to Java-based JSP. By now being thoroughly sold on the benefits of Free Software and Open Source (since they have developers and even admins who have been frustrated by Microsoft's lack of openness), they picked the Resin application server. Their intranet and extranet applications are now capable of running on either Linux or NT.

When their Windows-oriented vendor came to them with a $18,000 proposal for a Checkpoint Firewall-1 firewall, the IT manager said no thanks, we're thinking of setting up a firewall on one of our Linux boxes. This vendor was one of those who had been complaining of problems with Microsoft Proxy Server, and guess what, they're now showing interest in Linux also.

This company may even switch their file server. There's been some talk of this, due to Microsoft's per-seat license costs for accessing a Windows file server. It probably won't happen soon, but I have the feeling that it'll happen in the end.

Switching the desktops, though, is not considered a serious option, although it's been discussed more than once.

The important thing is to get a foot in the door. Figure out a reason to install an Open Source package - even if it's Apache on NT. Once people start having some familiarity and comfort with the idea of free/open source software, the possibilities become obvious, and it sells itself.

As already pointed out they are very similar. However I have to say you should check out Orion if you need full j2ee capability in a damn fast server (Oracle licensed it for their own j2ee offerings) or Resin. Resin is cheaper but doesnt include the EJB stuff. Orion/Resin are both free for development use and licenses are $1500/server for Orion and $500 for Resin (I think). give em a look. Tomcat is the reference platform but unless they really did some tweaking Orion and Resin both blow it out of the water.

Just my thoughts.

JBoss Enhydra Jakarta Jetty jUDDI pUDDIng Resin

Just pick a project and start contributing ;-)

I don't know about IBM but I doubt Sun feels fucked by the OSS community. There are several Open Source implementations of the J2EE platform or parts of it available and being developed. It's mostly that the Linux community is somewhat ignorant of them. Plus, of course they have more than 20 commercial companies developing implementations the J2EE platform, including IBM, which guarantees competition in the platform implementation and I doubt we will see in the same scale with the Microsoft platform.

For Open Source J2EE, check the following:
Jakarta
JBoss
Enhydra
Jetty
Resin

We're currently using Resin, because it uses an open source-style license, and we liked its implementation. Also, Resin compiles Javascript to Java bytecodes, which actually outperforms ASP.

I agree, Javascript is nice - small but powerful. In the JSP environment, having full access to the entire suite of Java class libraries makes it even more useful. And we don't have to embed Java code in web pages, where it doesn't belong.

This perspective is based on multiple experiences in which serious bugs in MS products - like memory leaks in IIS/ASP - were never addressed. Being a highly competent developer, it is not acceptable to me to be at the mercy of a company that does not even do a good job of pretending to have my interests as a customer at heart.

Much the same feeling applies to the operating system and OS-level tools. I know experienced Microsoft systems integrators who have had endless problems with Microsoft's tools, Proxy Server being a prominent example. Problems with Exchange are legion and legendary; System Management Server is a spectacular failure; and their DNS server is little more than a joke. MS Service Packs and hotfixes are as likely to break major functionality as to fix bugs - the original Service Pack 6, and the more recent Exchange hotfix are cases in point.

From my perspective, Microsoft peaked at around the time NT 4.0 came out and has been wandering directionless since then, changing acronyms (DNA anyone?) on a regular basis to attempt to hide the lack of any significant innovation.

Two technologies originally led me to be pro-Microsoft: NT itself, and COM. NT was a good product, for its time, when the betas of NT 3.1 came out in 1992 or so. NT 4 made the catastrophic mistake of importing the Windows 95 user interface, and then turning the ever-buggy Internet Explorer into the GUI shell. Since then stability has only deteriorated, and almost no fundamental progress has been made in making NT/2000/XP support some of the more powerful capabilities and configurability long provided by Unix - proper remote administration capabilities not least amongst those.

It seems that any overall vision that had existed at the time NT or COM were conceived have since deteriorated into a mad rush to maintain control in a changing market, driven by the Internet, which is something Microsoft is still trying to control rather than "get". Factions within Microsoft with backgrounds in things like mainframe transaction server systems argue at cross-purposes with advocates of academically pure object-oriented systems. If there's someone with a global vision at Microsoft, I don't know who it is: Nathan Myrhvold left long ago, and Bill Gates has spent too much of his career making billions to be a competent software architect today.

Microsoft has also never quite gotten the hang of TCP/IP - with the possible exception of the core of IIS, its Internet-oriented tools uniformly suck. I've already mentioned Proxy Server and DNS. In Win2K, Microsoft finally gave up the battle in some areas and fell back on pure BSD tools, such as the telnet implementation. The Wall Street Journal's recent story on Microsoft's reliance on open source software gives more examples of this admission of defeat.

But even while they're resorting to open source code, Microsoft seems to completely miss the power of simplicity and interoperability evident in Unix/Internet tools; or this may be a deliberate strategic policy. If tools are too simple, extensible, interoperable, or open, customers will have too much ability to control their own destiny, and thus won't be as easy to suck into a recurring-revenue future in which Microsoft bills its customers annually and provides arbitrarily chosen upgrades in return ("this new dancing paperclip is better than the old one, honest!")

In addition, Microsoft's own insistence on reinventing everything works against it: sucky initial implementations of Winsock led to applications which didn't get the concept of asynchronous communication. You still see this in products like Outlook today: they can lock up for extended periods while doing network access, something that should be completely transparent and in the background. [I'll say one thing positive here though: I/O completion ports are pretty sweet, and I've used them to good effect in some server applications. They've also helped IIS be an excellent performer. But one good API feature isn't enough, especially when the application developers don't understand how to use it.]

It isn't as difficult as one might imagine to convince hard-nosed business-oriented customers of the perspective I'm outlining: Microsoft's threatening lawyer's letters about license compliance, sent blunderbuss-style to all customers regardless of any evidence of lack of compliance, don't win friends amongst IT staff and CxOs. The threat of rental models, browsers which modify the web sites of other companies, and critical coverage of these things from quarters such as the Wall Street Journal, all combine to make you wonder: is Microsoft aware that it will ultimately need to rely on more than its current desktop monopoly, and instead convince customers to buy its products based on their merits, and the quality of service it provides?

There's no long-term strategy there, just an attempt to keep the excessive revenue flowing until the next set of CxOs can take over and inherit the mess. As a profit generator, Microsoft represents an incredible and possibly unprecedented feat, which I can respect from a certain perspective; but that doesn't mean I want to number myself amongst the cattle slaughtered to feed its unholy appetites.

Server software has become a commodity, and Microsoft is desperately trying to tie unrelated components together and avoid standards, so that customers have no option but to accept the entire package, and pay serious money for that which has become freely available elsewhere. This is done at every level of its software offerings, so that in the application area I'm talking about, for example, the operating system is tied to the web server is tied to the transaction server is tied to the template language is tied to the virtual machine is tied to... did I mention the operating system?

Yet you can go and download the source code to systems that do much the same thing - e.g. the Enhydra or Resin application servers - and, as alluded to above, these systems will run on almost any operating system and web server, with no secrets (you have the source), and no lifetime commitment to a development model espoused by exactly one company. And this applies double to commodity products such as file servers, proxy servers, web servers, DNS, email, and the like: the free products are actually significant improvements in terms of functionality and reliablity, over Microsoft's equivalent offerings.

Microsoft has grown too far, too fast, and become way too voracious and greedy. I rode with it to the peak of its wave; that wave has begun crashing, but instead of crashing onto a nice, wide open beach, it's crashing into an inescapable little Microsoft sandbox. I am jumping off to a different wave in which the currents don't work against me as much. I'm don't argue that .NET has no technical merits whatsoever; but the cost of chaining oneself to it is too high.

Society is built on exchange. One particular form of exchange that we're genetically wired for is reciprocal altruism: speculative generosity with expectation of future payoff.

Your comments have made clear to me a fundamental difference between GPL and proprietary software. The difference rests in what the developer of the software expects in terms of a future payoff. Microsoft (or any major software company) develops software will the expectation of monetary revenues. GPL developers write code in the expectation of future software they can use for free. Is it just me or are these two options the extremes of possibility? Isn't there some middle ground where the future payoff could feed the developers stomach, as well as his head?

I much prefer the licensing that Caucho.com has put on Resin. In it, you're only required to pay for the product if you're going to make money off of it. On the other hand, if you're some university lifer who hacks together a great technical document repository, you don't have to pay.

In this scenario, Caucho has decided that their future payoff, either money or free software/services, is determined by their customers. This, I'll call it payoff based licensing (PBL), seems much more pragmatic than the extremist options presented by either Microsoft or GPL. Users of Caucho's software can decide if they want to use it independent of the ideological dogma of the software developer.

Microsoft and GPL are simply sharing opposite ends of the same bed. If you want true altruism, then look towards BSD style licenses that don't impose any restrictions on how you use the software. If you have no restrictions in the license, then you have nothing to enforce. Microsoft and GPL on the other hand, have to be concerned about parasitism (piracy and illegal use) since they are concerned about a future payoff.

Therefore, any large group must evolve a technology of trust. If it doesn't do so, it will fall victim to rampant parasitism, which will cause inefficiency, which will eventually bring stagnation and failure to compete -- that is, death.

The trust you speak of is between the software developer and his/her customer. The developer trusts that in giving the software to the customer, (s)he will receive a future payoff in return. Microsoft and GPL have the same issue in terms of depending on trust and hoping they will see the future payoff. Of course, they diverge some in how they might go enforcing their licenses should the need arise, but the concept is the same nonetheless.

The GPL is similar to proprietary software licensing except that it demands a different future payoff. This and other systems in which the future payoff is rigid and fixed, IMHO, will have a disadvantage to PBL schemes that allow the customer to dynamically determine the payoff based on use. I wouldn't expect any of these systems to die off, but I would expect PBL systems to gain much more market share in the coming years.

Resin beats the pants off Tomcat according to third party benchmarks.

Curious__George

I'm also interested in investigating Enhydra.

For more info on Java servlet tutorials, ect. check out my blog: Brainspatter

Curious__George

I'm a JavaNewbie, but I installed Resin in very little time and have it up and running on a beige Mac G3 LinuxPPC box. Now I'm looking into installing and configuring servlets (like those found at CoolServlets). I'm one of the people who hated Java because it was slow, but don't blame the language for the client-side problems. This URL says it all better than I could: http://www.davidreilly.com/java/java_network_progr amming/#6.

If you are a newbie like me and interested in learning more about Java/Servlets/etc. you'll find lots of links at my blog: Brainspatter.

Curious__George

A few months ago our company evaluated several jsp/servlet engines, including tomcat, and the only one that was even remotely usable was one called Resin

(Disclaimer: Not a paid endorsement.)

-jhp

Check out the Resin JSP/servlet engine - the authors claim it's faster than mod_perl and mod_php. If you're targeting Apache and you believe them, it might be worth looking at.

I've installed it (painlessly) on IIS and Apache and played with it, no real performance measurements but it seemed pretty fast.

You're the one that's coming off sounding like a troll. Did you read the benchmark? Read this one too while you're at it. Perl and PHP are not necessarily faster then JSP/Servlets, that is a myth propagated by people who think that anything Java = applet. While you were off coding in language X technology changed, and guess what, Java has progressed over the past couple years, just like every other programming language. So keep your eyes open and give it a second look.

php, optimized with zend's optimizer will outperform jsp by about 15%

Be careful with that kind of generalization, unless you're going to post references. There's a huge variation in jsp engine performance. This is a vendor benchmark site (so take it with a grain of salt, especially where their product is concerned), but you can see how wide the range of performance can be between JSP/Servlet engines.

Resin is a webserver that can run JSP/Servlets like tomcat, but it can also parse xml (you have to name *.xml files *.xtp in order to parse it) it is located here.

Jakarta is the name of the project, while Tomcat is the product.

I wouldn't touch Tomcat with a 10ft stick. Its performance is really sluggish; and its overall maturity level is remarkably behind the other free/commercial alternatives. IMHO, the best JSP engine you can get for free now is Resin; it also happens to be the easiest one to set up. It's available at Caucho's site. It's still possible to run Resin alongside Apache so Apache takes care of the static HTML pages while Resin handles the JSP. In my experience it was the ideal solution, and I scrapped JServ as soon as I discovered Resin.

HTML::Template might be a place to look, while it doesn't give you embedded code in a page it forces you to separate content from presentation, which is often a bigger advantage down the road.

There have been some unofficial benchmarks of the various technologies (here is one, but it is biased) but most I've seen are nearly irrelevant because the best thing they test is the looping ability and startup time of the various technologies. And none of these covered the very thing you ask, the page embedded solutions for Perl.

From my point of view, most of these technologies are on par with each other, there aren't going to be orders of magnitude differences by switching.

The mod_perl performance pages offer quite a bit of information on tuning your application, I wouldn't be surprised to find that your biggest performance obstacles are in the code itself. You mention 'we', how about breaking up the different embedded solutions and picking a subset of your capabilities to implement and benchmark. Then you can tell us "Which one is fastest?" Better yet, you can give us a clue as to which one is better to develop with, any hidden obstacles to a good design and so on.

Tomcat is a reference implementation that is moving toward being a viable product for small self maintained sites. I use it for testing because I find that its instability and open development strategy are plusses.

There are real commercial Servlet Containers that are much faster and more stable. Resin is blazing fast, includes lost of fun gadgets (but start with plain servlets, please) and is OPEN SOURCE. It's free for small installations, but costs US$500 for commercial licenses. I use it.

What I really like about Resin is that it is rock solid. And nicely supported.

Servlets are at their best with complicated, large, or frequently updated sites. Consider a framework like Turbine or a templating engine like WebMacro or both to build a good quality maintainable site.

JSP is designed to emulate ASP. It's a great transition path. Now some taglibs exist to make it a viable platform for development, too. But a real framework is better, so consider one.

-B. Earl

JSP would've done better if they had used Caucho's Resin. It's lightning fast. I'd be interested to see the results of a more comprehensive test covering more app servers.

I will chime in with my own little opinion that it is far cheaper to buy the hardware to get the performance you need from any technology you choose (within reason) than it is to train a staff to a new technology.

And the best example of tuning a Java web app I've heard was a bank's app running on a 16-way Ultra-Sparc. Not pleased with performance they considered moving to an E10K. Then someone pointed out that they were using green threads. For the non-Java guys, green threads (as opposed to native threads) are managed by the VM and cannot use multiple CPUs. Their app was pegging one CPU and leaving the rest idle. Moving to native threads gave them an instant speed, um, boost would be an understatement.

I will chime in with my own little opinion that it is far cheaper to buy the hardware to get the performance you need from any technology you choose (within reason) than it is to train a staff to a new technology.

And the best example of tuning a Java web app I've heard was a bank's app running on a 16-way Ultra-Sparc. Not pleased with performance they considered moving to an E10K. Then someone pointed out that they were using green threads. For the non-Java guys, green threads (as opposed to native threads) are managed by the VM and cannot use multiple CPUs. Their app was pegging one CPU and leaving the rest idle. Moving to native threads gave them an instant speed, um, boost would be an understatement.

I will chime in with my own little opinion that it is far cheaper to buy the hardware to get the performance you need from any technology you choose (within reason) than it is to train a staff to a new technology.

And the best example of tuning a Java web app I've heard was a bank's app running on a 16-way Ultra-Sparc. Not pleased with performance they considered moving to an E10K. Then someone pointed out that they were using green threads. For the non-Java guys, green threads (as opposed to native threads) are managed by the VM and cannot use multiple CPUs. Their app was pegging one CPU and leaving the rest idle. Moving to native threads gave them an instant speed, um, boost would be an understatement.

As an experienced Java server coder I can vouch that the idea that using Tomcat 3.2 as a benchmark is utter stupidity. Tomcat developers and all benchmarks agree that either Resin or Orion server delivers the best performance for JSP. Tomcat is murderously slow in comparsion (ZDNet tipped it off when they said ASP was faster, which by no means matches my experience or general concensus). I have coded components (Bean) and extensions (taglibs) for JSP a few times and I have yet to come across a better general web scripting technology than this. Now I know that /. is the home of a lot of perl/C lovers but can all those companies who are ignoring M$ solutions and going for the Java solution really be that wrong. Anyway to get to the point a java compiled JSP/Servlet container running a web application of JSPs, Servlets, taglibs and Bean, is a very good and portable solution (I am still forced to develop on Windozer but we deploy on Linux as well as Win2k and WinNT). "Think of something cool and tell yourself it`s my sig" -me adapting a quote from BtVS

and end up with another microsoft that screws its partners by changing the spec so their products can get to market first? NO THANK YOU! i like it better this way. i'm glad that sun is letting companies that can do it better do it. i use jikes almost exclusively. i use jserv and gnujsp for servlets and am now evaluating caucho. i love the amount of choice i have and the idea that if i change app servers, i don't have to change much code. this is the way it should be!

--
And Justice for None