Slashdot Mirror
Ask Slashdot: Which Java Applications Server?
MistaBobDobalina asks:
I am looking at three open-source Java
application servers for the purpose of
building a database-driven website:
Locomotive
,
Protomatter, and
Enhydra.
I am curious if anyone has experience with
these or any other open source middleware
solutions. I am also looking at commercial
products but prefer an open product. I am
making this query because three-tiered sites
are now the norm for E-commerce and this is
an area that the Open Source world hasn't
addressed as well as operating systems,
web servers, and databases have been."
Please tell me why I should look further.
webmacro.org
It's a template engine that makes servlet programming a breeze. Keeping HTML out of your code is important.
comments?
Please consider:
http://www.w3.org/Jigsaw/
First you should probably fix the broken floating point support... The Cobalt provided version of MySQL can't handle it, yet... In my view, a bit of a problem.
if yor are really looking for a truly free solution.
apache
mod_perl
dbi
pick a database
Another possibility (never used it) Hamilton - http://microstate.com/hamilton/index.htm. Java app server, usual features. And no, it's not a derivative Hamilton95 you wiseass ;)
Yes, I'd highly recommend WebObjects. NeXT was one of the first companies that allowed developers to get away from SQL and deal with objects instead. You really need to take a good, hard look at WebObjects, the Enterprise Objects Framework, and the other frameworks that Apple/NeXT provides. Check http://developer.apple.com and http://www.toodarkpark.org. I don't work for Apple, I just love their product ( work with WO daily ).
Just curious, but why do you call Python's OO support "so-so"? It seems pretty good to me, at least on par with other things I've tried.
In fact, Java is what runs Sun's web site, using Art Technology Group's Dynamo App server which is pure Java.
Borland is adding Java app server functions to Delphi on the next release, too.
Why is everybody willing to wait for this
slow and unstable corporate controlled entity
known as Java?
Sounds like a religion to me.
Wait for your false prophet - I'll continue using
real world products that are responsive and
reliable.
We exclusively use C++ for all our web-based and internal servers and have 10X the responsiveness of any equivalent Java solution - and these servers _NEVER_ go down.
Maybe when Java is up to the task we may may re-evaluate it, but it ain't even close now.
Don't blame C++ for the work of bad programmers, that's a lame cop out.
This is incorrect. Java relies on OS native threads, whenever possible... that means pthreads on Linux or Win32 threads on NT.
Early JVM's for Linux did not use pthreads, since pthreads didn't work well before glibc2.0. Get the latest native thread port from blackdown or the JDK1.1.6 with JIT from IBM AlphaWorks; both will scale on SMP Linux boxes.
I have a quad-PPro here with Linux and can tell you it works. Each thread appears in the process list, and several can run at once (how else can one process, the VM, drive my load average past 4.0?)
http://www.weblogic.com/
Best Java Application server. Does real distributed processing, clustering, failover, and real scalability.
Hey, no opportunity, man...
Houston, we have an opportunity...
This looks like a damn near unsolvable opportunity...
Don't tell me about your opportunities, talk to your analyst, that's what you're paying him for...
Everyone's got opportunities...
TC
A few:
- Automatic Fail-Over
- Distributed Sessioning
- Distributed Load Balancing
- DB Transactions
- Scalibility
- Monitoring
- Decent development environment
- At this point, I'd expect it to support Servlets, JSPs, and EJBs.
Don't blame C++ for the work of bad programmers...
Same can be said for Java... there's a lot of really bad code out there right now. I put every potential Java app server through its paces before we consider it... testing thoroughly for throughput and scaleability. Most of them don't perform up to the potential of the technology.
Earlier we can used Cold Fusion (an app server written in C++) for much of our work... it falls flat compared to Java. I can't even get 10 requests/sec from it no matter how many threads I use.
Let's be fair here... Java and C++ are more alike than they are different. If you don't believe that, go download Cygnus' gcj toolkit... it really blurs the difference.
Class.forName("someclassname") will dynamically load any class in any "Java" jvm
Yes, that's how green threads worked... it wrapped all blocking system calls and did a select() when waiting for I/O. Unfortunately, try it with a few hundred threads (after recompiling your kernel for more fd's) and you see why select() is non-ideal.
I think time slicing was also supported with alarm calls. But I didn't rely on that much... I had better results sprinkling my code with Thread.yield() calls.
One nice feature of green threads was background garbage collection... the JVM would try to use idle time to compact the heap. If a thread became runnable, the collector would abort immediately. Unfortunately, the gc would compete with other processes, at the same priority...
Green threads are basically extinct (Sun doesn't use them anymore on their Solaris ports). With them good riddance.
...by Bell Labs?
Its being pushed very hard by a big company.
Come on, most big language initiatives have commercial backing. Java is no different. Now with open specifications and several clean-room implementations, Java has a life of its own, and will continue to thrive whether Sun "does the right thing" or not.
Apache jserv does not have a jvm built into the apache process. It uses a specialized protocol to communicate with a jvm in a seperate process or on a seperate machine(s). This allows you to distribute your servlets across multiple machines transparently to the apache process. It also has failover and loadbalancing. There is work underway to embed a jvm into the apache process but that is to tackle a different set of problems. Jakarta and Jserv will eventually merge into one project. Their goal is to implement a servlet engine that is compliant to the Servlet Api (kinda has to be since they are going to be the reference implementation for jsp's and servlets)
Er, I dunno. I see lots of posts about alternative
java middleware products including several posts
about Apache JServ and several commercial products. Also, the creator of one of the original products in question posted a bunch of information about his product.
Seems to me like there's a lot here. Did you maybe scroll through this list looking for something to complain about? It's always best to avoid preconceptions since they only serve to distort our conceptions...
Squishdot is better than Slashdot. And it's written using Zope!
Oh, wait...
A the traditional, totally useless AC post to boot!
I have been using this combination succesfully in 3 projects (session http -> session ejb).
I find the stack to be very compeling and useful.
I wish Apache went with EJBoss to get an application server, at least I would like to see the jserv/ejboss integration for sure
tom kamper
www.ejboss.org
ejb server onlinux... GNU oriented fun/small/smart crowd
cheers
will
I use the combination of both and you can see your request going faster and faster and faster... it's very interesting to see dynamic optimization kick in. One thing taht is interesting is that EJB server reuse a lot of code (at least EJBoss seems to ) so that the code is always running quite fast.
matt poter
(sorry no passwd)
promises...promises
We have looked at Jserv and EJBOSS.
Both use classes jitted in memory so that the invocation actually trigger native code execution.
The server is java and jitted the classes they server are java and jitted. We found it faster than many commercial options.
move on, he doesn't know what he is talking about..
karl
I use webMacro to build my servlets. I have 10 production servlets running with it, and it's great. webMacro separates your HTML from your code cleanly, and unlike JSP it's open source.
I've done a fair amount of Perl with the Apache/mod_perl combination, IIS / ASP, NetDynamics (a commercial app server product now owned by Sun), and now java servlets being run with Jrun. I haven't worked with EJB, though.
I think the biggest thing an application server provides is a layer of abstraction between an application's primary functions and the administration necessary to support those functions. Sure, we all try to be good developers, but sometimes you're in a you don't bother to comment a magic number, or you define a constant somewhere in the middle of a really hairy bit of Perl code, and now your CGI will only run on one machine, or in a certain directory.
A good application server makes it possible for the developer to be completely unconcerned about what machine the application is running under. One machine or five, NT or Unix, the developer is just writing applications.
Why do you find the removal of templates to
be a problem?
Instead of a template, I just set my stuff
up using the base object class. That way
any object will fit into that in C++ i would
have made into a template.
just wondering.
XML-based applications can provide a very consistent way to build dynamic content. However, currently there is no good alternatives for a XML-based logic processing language, and even XSL (that deals with separation of presentation and content, but does not deal with logic) has not a final specification. Those guys from apache/cocoon have been developing something to fill this gap, XSP, but that is very immature yet. Given these facts, and the timeframe to have XML-based logic/presentation/content solutions usable to be in the range of 1 year, there is nothing to do but asp/jsp/coldfusion crap.
Sure.
Does your mod_perl app support automatic fail over? For instance, if it crashes or gets an error in the middle of a DB transaction, will another server transparently be able to take over your shopping cart data and assign it to a new database without the user knowing anything?
Or, will the user get an error message or have to rebuild his cart?
Do you support distributed transactions across multiple DBs?
How about being able to cache results and session oriented data across a server farm of 20 web servers?
>
3 words: static type checking. ~k.lee
Languages like Perl let you do specific things very efficiently and easily, without worrying much about resource management, mostly because they have a lot of special cases hardcoded in native code. Once you exceed what they can do efficiently in native code, however, you are pretty much stuck.
Java, on the other hand, is a general purpose programming language. It's harder to program in and you do have to worry a lot about resource management to get good performance. In return, you get a lot more error checking, support for software engineering, and better performance in the general case.
If you don't know why you need Java or how to make Java programs run fast, you probably don't need Java. But, then, don't complain about it either.
2. The bulk of the client-side development is being done is in VB or C/C++. Java is slow. The write once, read everywhere premise is bogus. Fitting everything into an OO model is overkill.
Unix is 30 years old, yet we use it every day. So when something new comes along, it's not guaranteed to be better.
XML won't catch on as a web template model until HTML as we know it disappears. I know this first-hand: we built a huge XML-based app server, and when the designers saw what they had to do now to build their pages, they blinked and said no thank you. And they were right: the contortions required to generalize the kind of messy table-within-table-within-table typical of visually striking sites were insane in XML/XSP -- not to say unbelievably verbose. At some point check out the DOM tree for a real-world web page. One of HTML's strengths is that it allows non-methodical people to build complex pages without explicitly thinking of the element hierarchy. And wysiwyg HTML editors still aren't up tp snuff.
What did we do? We retreated back to JSP. Everyone now is sort of happy, except people like me of course who still think the whole mechanism is too ad hoc and error-prone.
But guess what? People in general aren't interested in suffering for a principle. If they have something that kinda works and lets them finish their work before the local bar closes, they'll stick to it. Which is right.
Slashdot I think simply proves the argument for using a fast java-based app server -- you can model yourdomain entities as beans, keep them all nice and cached in memory, retrieve them quikly using servlets and compiled pages (jhtml/jsp), and use the DB only for persistence.
Maybe you've never worked on really busy sites where you simply can't rely on a single machine to do all the work, and yet you have real global state in memory that you require all servers to share -- for example, for performance reasons. What would you do: use the database? But then the DB becomes an excuse for IPC. It's much easier to distribute tasks and objects across several VMs than to rig up, say, RPC calls in Perl.
Ok, some of you people really have got to get off of this Java app servers over everything else kick. Lots of clueless people seem to be implying "Well, some sites use lowly scripts to run their sites but we're special. We need JAVA for our super-duper, highly-scalable, object-oriented, five-tier, dynamic xml-parsed 'solution'." Grow up. Many of the most trafficked sites use Perl, PHP, Python, Tcl, and sometimes C. Is your site going to be more popular than any of these?:
www.deja.com
www.imdb.com
www.hotmail.com
www.yahoo.com
www.photo.net
www.digitalcity.com
www.villagevoice.com
www.metacrawler.com
slashdot.org
Telnet to port 80 on these sites or use Netcraft's "What's that server running?" feature to see what these guys are using if you don't believe me.
Don't believe the hype and marketing around application servers. They are for corporate IT departments who don't know better and want to appear sophisticated (and I say this because I work in said clueless environment). Don't believe your hack CS205 professor who pimps OO as the end-all be-all of programming. OO is nice but it's not a panacea for bad design. You can program just as brainlessly with Java as you can with Perl. And for those of you who bitch about Perl's syntax. What exactly is it about Perl that bug's you? Lack of typecasting? Gosh, "use strict;" is hard to type. Messy syntax? Yes, you can write ugly code with Perl but the same can be said for any language. Perl is just more lenient than most. I can't understand people who don't appreciate leniency in a language when you are trying to release a dynamic functional site in a couple of weeks. Sure, we'd all like to make pretty programs at work but sometimes we need them to get out there ASAP and with as little overhead as possible (those of you who can't appreciate this are still in school and haven't dealt with competitive deadlines or you just don't see what a competitive advantage being first and scalable on the web gives you).
Name one commercial app server that scales as well as the open-source combos. Kiva server was a complete piece of doo-doo. Oracle Application Server? Yeah, right, it was so good that Oracle stopped using it for their own site. Some will argue that app servers are necessary because they support transactions, failovers, etc. You can encapsulate most of this in the db without burdening your web developers. If you really need these features then you should consider looking at your design again and seeing if you can simplify it. In my opinion they are not necessary for 99% of the problems you'll run into.
For people who would like another opinion on why commercial app servers suck read this:
www.photo.net/wtr/application-ser vers.html
For those who'd like to read about one possible open-source solution (the same one that slashdot uses and my personal favorite):
perl.apache.org/stories/
Other good environments:
www.php.net
java.apache.org
www.aolserver.com
www.python.org
For those of you who push Java app servers over everything else: why don't you write down a list popular sites (your intranet or school projects don't count) which are using them and give examples of the hardware necessary to keep it going. I'm excited about the Apache Java project (look at above link) but everything else is just marketrdroid talk until there are results.
Ok, I work for one of the largest investment banks in the world in NY and I think I'm qualified to comment on this. Yes, Java is being used by these companies but only because they failed miserably with their other attempts in C++, SmallTalk, PowerBuilder, VB, COM, etc. Java is the new silver bullett and none of these companies want to look stupid by not using it. It's a classic case of keeping up with the Joneses. Sure, Java could offer most of these companies some improvements over their present environments but it doesn't matter because the process which these companies have implemented is totally screwed. What's the process?
1. VPs dictate all of the decisions no matter how long it's been since they've touched a single line of code. These guys might have been cs majors in school but they probably only programmed for a year or two if that before becoming "project managers". They were most likely mentored by the same sort of person that they've become.
2. Company hires fresh-faced kids out of school who don't know any better and won't complain when they're forced to work long hours with little recognition. Never mind future career because once you've forgotten (or moved over into middle management) how to code, the only other companies who will hire you are just like the one you're presently stuck in.
3. Hire a bunch of expensive consultants to do the real work. Tell them that they are every bit as equal full-time employees but never fully accept them because they don't fit the image of the firm.
4. Institute lots of process which will make sure to split people into warring camps. Make people sign and adhere to ten documents so that they will never be able to do solid work.
5. Go to tradeshows. Get training for your employees in such important topics as learning MS Visual Studio. Get presents from vendors who are trying to sell you their crappy overpriced middleware solution.
6. Make sure nothing ever works because if it did then you'd have problems. People would start to have all sorts of expectations which could never be met. Talk about how you're going to use the best new language, architecture, paradigm, methodolgy, whatever. This will be sure to confuse the hell out of users who will go back to their cubicles and leave you alone.
You think I'm joking? This is exactly how it is at the place I work. I'm sure it's a common story in many corporate IT departments across the land (Dilbert does exist for a reason you know). So the next time you read about some big company's Java plans you should think twice about their motives for using it. It's rarely for the reasons that Sun promotes Java.
Um....but they don't support Enterprise Java Beans. Do they? This is just Java layered on top of their pre-existing technology....or am I missing something?
.
Web Macro has been mentioned above. I'd like to add that I'm using it, and it's pretty cool.
* It's surprisingly fast (providing you avoid the slow include file directive, which they say will be fast in the next version as well)
* It's easy to make templates
* It's easy to write the back end code too because Web Macro uses introspection to analyze your object--no need for an adapter class.
* Full separation of content and presentation. JSP claims this, but it's actually real in Web Macro
It's open source. The only downside is that 1.0 has not yet been released yet I don't know when that's coming out, I think a few months or something. However the current beta seems very stable to me.
Also you have to be careful with your classpath when installing it. However once I got it installed correctly, it was a blast.
Web Macro
Apache-JServ.
Simple, light, easier to develop for than WebSphere from all reports. Hell, I find it pretty easy to develop for, and I hate Java (who needs strong typing when all you're really dealing with is strings?), but like the people developing it.
I may end up writing some of the x509 classes for Jakarta simply because I like working with the code these guys produce. Perl and PHP are butt-fucking-ugly and I'm beginning to see where their scalability (in terms of developers-per-project, not in terms of hardware/OS scalability) can be a bit limited. Of course, because of the nature of the Web, I always end up writing stuff in Perl first; but I'm finally beginning to see what the point of this whole Java/XML racket is.
Sun still sucks, though. I'd rather run on stuff they had no control over -- Kaffe or whatever. Bill Joy rules, and many of their engineers are wonderful people, but somehow they still make sucky decisions. Must be marketing or MBA trolls.
From what I see here, you don't care about performance. On a high-traffic site with complete personalization, where the content must be generated dynamically, your approach would fail miserably.
But have you used anything SINCE version 3.0? ATG is on version 4.1 now, with 4.5 in beta test. I wonder if some of the problems you saw have gotten better since version 3.
I've read about Saxon, an XSL compiler which,
instead of interpreting the XSL template each time, actually translates it into a java class, which sounds like JSP to me. This I would think greatly increases the speed! I hope that either lotusxsl goes in this direction or saxon supports javascript because I'm using a few javacsript functions in my lotusxsl templates to translate ugly element names into nicer names, (saxon does support java extensions and I could probably convert them to java anyway)
The point is, I think compiling xsl templates into java classes it the way to go if speed is needed. So, check out Saxon
I'm a little worried about java.
Its being pushed very hard by a big company.
We've been down that road a few times before.
Am I wrong to worry?
The usual reason is that you are building something more durable than a "Personal Home Page".
Java is a real, general purpose programming language. PHP code won't do you much good if you want to migrate your work to some other, non-HTML environment.
Examples: opening up your business objects for use by other people over the network; moving some of the processing to the browser; writing generic accounting software which isn't necessarily web-driven.
Java, as a general purpose language, is suitable for all this. PHP is suitable only if you are working strictly with web-based code, and promise you'll never, ever want to do anything else.
Java's also cleaner, in my experience; and allows for better project management if you have more than one team working on a project (OO benefits).
Where I work, we don't even have "problems." They're called "opportunities."
So I guess a giant asteriod on collision course with Earth is just a really big Opportunity for everyone!
Well, there are a few free "Java Assemblers" such as "Jasmin", which we used to write a compiler in Java that compiled into Bytecode.
I'd guess there are commercial ones as well, but I really don't know.
Finally, someone else who's doing this...
.92) Blackdown 1.1.7 v3, va2.2.7-1smp kernel, and JDBC (classes111.zip). We haven't started stress tests yet, but I'm curious to see what other folks are seeing in terms of performance numbers with JServ on Linux w/Apache.
- What kind of load are the Apache/JRun installs seeing? Specifically, how many max concurrent users?
- What kind of machines are the installs using (CPU and memory)?
- What kind of DB (if any) connectivity are you using (JDBC?) How many of your servlets do DB lookups?
- What version of Apache and JRun are you using?
- What JVM are you using?
- What kernel are you using?
We're using VA boxes each with 2 CPUs and 512M RAM. Redhat secure server 2.0 (Apache 1.3.3)/Apache 1.3.6 w/JRun 2.3.1 build 143 (jsp
I had really horrible experiences with Java as a server engine/db layer on Solaris (not JServ/Apache), so I'm really worried about a third party port to Linux. Basically, we ran into a ton of JVM (1.1.7) threading bugs which required on site support from Sun's JVM group. This is trying run a JVM with hundreds of concurrent HTTP users going through a web server plugin for days in a row doing db lookups.
So if Sun's JVM on Solaris was that much of a pain, I have serious doubts about the JVM on Linux, which has only recently started supporting threads and SMP.
webmacro
Not true by any stretch. I do quite a bit of my mysql db maintenance scripts/code in php and just run it via the command line version (for cgi instalations). The apache compiled version along with the cgi implementation do wonders for both realms.
Granted, I wouldn't classify it as a GP language, but it's damn close to the extent that I often have to decide between it and perl. Would I use either for writing a full and local app with UI? Probably not. But on the server it's handy as hell.
rodent...
Tactical nuclear weapons are a viable alternative!
Posted by smsilver1:
We use Apache JServ 1.0 in a standard 3/4 tier environment. Right now we don't need state migration or complicated fail over/load balancing. (We will soon). We modified Jserv to do JDBC connection pooling, thread pooling, and probably will do socket pooling. I should have some benchmark numbers next week if anyone is interested.
We use a handful of jsp's and servlets for dynamic content.
It will start to be tricky when we need proper state sharing/persistence/failover. We probably won't ever use any remote method invocation mechanism.
So we're in the boat of needing about 1/2 of the complexity of an application server...given the complexity of debugging these things, i feel more comfortable with access to the source.
What the heck is Java Assembler? Do You hack directly in the Bytecode?
Greetz
Konrad
There is also ejboss.org and dasein.org. The former has a very active developers list and everyone is really sharp. The latter is George Reese's baby (the author of the O'Reilly JDBC book) but he's working on the second edition and so the dasein project hasn't moved for a while. Recently the two projects got together for a brief exchange on the ejboss list. George seems interested in working together with them. (P.S. I've been following gamora with great interest, and like what I see. I don't think Scott is interested in making it an EJB container, though.)
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Java multithreads, but all the threads are running in the same process (the VM). So while all the threads are running concurrently the whole thing runs slower as the threads fight for process time. Not a big deal if you have a single CPU, no threading implementation can do anything different. But with some you can get additional performance with multiple CPUs. That is if the OS(or threading implementation) can run threads for the same process on any CPU.
I just wanted to point out that if you are running on a big enough machine and speed is still very important, you get easy concurrency with java, but it is all on one CPU.
I program in java and love it. The multithreading is SO much easier then other languages. I just really want to see a VM that can run across multiple CPUs distributing the threads. It would be really cool. :)
--
?
Thanks for pointing that out to me. I haven't looked at the how JVMs handle threading in alittle while and I guess it changed. And "green threads" does seem to spark a memory.
Didn't most of the early VMs handle their own threading? With these green threads? I seem to remember a lot of discussion about threading implementations in the various JVMs. Like Sun's Window's JVM threading versus the MS JVM's threading. I'm glad to hear the JVMs are using native threads now.
--
?
Well, the company that I'm contracting for is going to be using Enhydra for 3 out of 4 of our major services so if it doesn't work we're screwed (put another way, if there are bugs that would keep it from working for us they will be fixed by us). However, from what I've seen so far Enhydra looks like a solid system and the design is very impressive. The people who developed it did so over the course of several years as part of their real-life contracting work so that alone would strongly encourage it to be highly stable with a pragmatic design. My experience with it is limitted to a few weeks so I'd be interested in what experiences others have had, but so far I've only been really impressed with it.
Not only is it well built, but their web page also looks very professional. That may be a really good selling for your boss as it's something you can't say about a lot of open source projects.
-----
Free P2P Backup, Windows & Linux
PHP is nice for simple apps, and I use it myself for a lot of things. However, I wouldn't want to use it for a large project as I have tried it before and most of my time was spent being really frustrated with things not working right. The majority of the time the frustration was due to typographic errors on my part, which made me realize what an incredible amount of time strong type checking in languages like Java save me. PHP's slut-like view of casting also caused me infinite grief - when "" can be interpretted as "", 0, null, or false it makes database queries (among other things) a royal pain. I also found a lot of the functionality of the methods counter-intuitive, but I suppose that wouldn't be a problem if I were more experienced with it. The other thing, which I know has been mentioned already, is that PHP mixes code and HTML quite thoroughly which can be a real problem if you have a software team working on the functionality of the web page and a graphics design team working on the look and feel and they won't necessarily be working closely (this is common).
Anyway, I don't mean to be down on PHP because I still like it and use it. I just wanted to give you some ideas of why it's not right for every job.
-----
Free P2P Backup, Windows & Linux
I'll have to agree with what's being said elsewhere. We've been using Java for two years to run some fairly high-use sites (http://highwire.stanford.edu/ and all the sites linked from there), and although it's not perfect, it has given us very acceptable performance even when under heavy load.
Our system is currently using only Apache with mod_jserv (running on Solaris 2.6); we will probably be moving some of the code to an application server environment within the next year.
The most important thing for getting good Java performance is to use the right VM. We were using the Javasoft reference VM when we first started our switchover, and the performance was terrible. When we switched to the tuned Solaris production VM, everything magically started working acceptably.
I expect we'll get another speed boost when we upgrade to HotSpot sometime soon.
Make sure that your VM has a JIT. If you're on Linux, I'd recommend looking at the new IBM JDK; I don't believe the standard Blackdown JVM has a JIT.
I am Jack's complete lack of surprise.
My biased response is that the Locomotive is a good option.
We have been using this for a while now and are part of the development team.
It is stable, fast and easy to develop for. It also has a history of use for large sites.
In a less biased view I expect to see a fair bit of merging between the various projects over the next few years.
Regards
Dave
Did it ever occur to you that some of the largest banks are developing their backoffice systems with Java?
Java currently handles large-scale systems for Nike, FedEx, JCPenny, the Home Depot, VISA International, and several North American banks.
I think you really need to take a closer look at what is being done with Java *today*.
-Stu
I understand that you're not joking. "Silver bullet" syndrome is rampant in IT departments everywhere.
:)... This is probably a good thing, as it will hopefully pave the way for even better technologies down the road ...
However, Java is yet another attempt at bringing banks ahead in the technology curve. Smalltalk attempted to replace COBOL as the business systems language du jour - it failed, unfortunately, due to its fragmented market, inability to compete in the mainstream with C++, and a huge lack of experience in designing/building object oriented systems.
This doesn't mean that objects were useless - they're not a silver bullet obviously, but they're a good step forward in how we program systems. Java is another attempt at bringing this paradigm to the large-systems world.
I guess you can look at Java two ways: either it's another snake-oil product being peddled by the OO industry (i.e. IBM), or it's another attempt at pushing modern programming practices on the large systems of the world (which run on IBM servers... notice a trend here?)
IBM is pushing Java hard because it integrates their whole product line WHILE providing a language to effectively supercede COBOL in the long run.. (though COBOL will never cease to exist...:)
They tried doing this with Smalltalk, but failed due to the fragmented market.. that's also why a unified Java front is so important to IBM & Sun. We can't see the mistakes of yesterday repeated.
So will they succeed? With so much support & weight behind Java, it will be at least a moderate success (Smalltalk is considered a "small" success in most people's books
-Stu
When I switched to my current job, I was a Java, Perl, C-C++ programmer, mostly. Over here we use a lot of PHP3 which is rather cool. I still prefer perl cgi's, but PHP3 is quick, easy and rather dirty. Which I like.
Our next project we researched using Zope, as it seemed to be similar. As I see the two languages, I believe Zope is only for what I call dynamic HTML. It will change web pages, but if you need a large program that does a million and one things, but uses the Web as an interface, it seems to be lacking. PHP seems to be a stronger language and more powerful.
We hope to utilize Zope sometime here, but I think the reality is that it is just not powerful enough to fit our needs.
Good luck!
Its being pushed very hard by a big company.
We've been down that road a few times before.
Am I wrong to worry?
A company's great idea isn't necessarily evil just because it was originated there. What would all of us be doing if someone at AT&T Bell Labs hadn't thought "Hej, Brian, why don't you go check this MULTICS thing out?"? Hm...
At the end of the day, there is no Open Source object-oriented, portable, widely available programming language that has the same acceptance of Java. C++ is too complicated and doesn't enforce the OO paradigm well. Smalltalk? Too fragmented, though I'd much rather program in it than in Java if it were as widely available. PERL and Python are great, but so-so for OO (besides, if I wanted a language that resembles my other 10 favourite ones I'd program in Ada). That leaves Tcl... which could be a good option, but it also originated at The Big Company and hasn't had as much acceptance as Java.
(Before the flames start, I should let you know that I've been programming in C since 1984, C++ since late 1988, Smalltalk since 1990, assembler since 1983 and that I've delivered many products under all those languages including Java running on all kinds of hardware, from embedded to mainframes. So I'm not shy about using these tools when they make sense. In fact, we're currently developing a Big Project mostly in Java assembler because it makes business and technology sense)
Like UNIX and C, Java will probably grow out of Sun's tight control at some point in the future. Transvirtual is walking that path, and so are a few of us who want to separate good ideas from politics and make some money in the process.
Cheers!
Eugenehttp://eugeneciurana.com | http://ciurana.eu
Python seems to suffer the same problem as C++ when it comes to OO: It supports it but doesn't enforce it very strenously. Java is somewhat better, but you can still do Stoopid Things like defining pseudo-global public variables. Also, these languages support primitive types, which tend to be a no-no because they violate OO concepts by letting people write code that deals with them even in high-level objects.
I have nothing against Python as a language; I actually like it quite well compared to PERL. My point was OO and availability, not technical elegance. From this latter point of view, Python rocks!
Cheers!
Eugenehttp://eugeneciurana.com | http://ciurana.eu
OK, here's the scoop. I *DO* servlet programming for a living. We've pulled together webmacro, IBM WebSphere AppServer and MySQL on Linux. But if I had a choice, I wouldn't be using IBM WebSphere. We got lucky, and didn't have to pay for it. It's mostly fast, and does everything we need it to - for now. But it's got it's flaws, and it's a resource pig - 30Meg of Memory to run two servlets? And It's the only app I've seen to Max out CPU Utilization on Linux. Hell, it's the only thing I've seen *KILL* apache deader than a doornail. We're still looking at the OpenSource Servers because they look smaller, faster, and just as feature rich. Please Tell me which one you choose, and why. I want to take it to my boss as an alternative.
--- Kevin "The Alchemist" Sonney --- --- http://www.darkcanvas.com/~alchemist ---
So, is the term Application Server just some sort of marketing slang?
I've gone from developing CGI in a variety of languages to Java Servlets, both with tight integration to a DBMS, and including such features as load banancing, connection pooling...etc...etc. Since I stay mostly with Open Source software, I haven't come across the term 'Application Server' very often. What does the combination of existing technologies lack that an Application Server provides?
Is it somewhat analagous to building a linux based workgroup server from an old PC, or going out to buy a Cobalt Qube (or similar product) in that to obtain a particular functionality, one you have to put together yourself from surplus parts and free software, and the other is a turnkey solution?
The URI is http://gamora.org
From the Gamora readme:
EJB Servers are complex beasts to do properly, I spent most of last year fighting with a buggy Sybase EJB server to discover that management decided that it was too expensive...
I hope your goes better
DWR is Ajax for Java
From their site: As of now we have about 60% of the functionality outlined in the spec. Namely we have the containers in place and the managing infrastructure. However we are missing the entity beans (which are optionals right now). The latest build is 0.04 and is the first public release of ejboss
From the web site The XS Server (eXtensible Server) is a framework into which a multitude of different services can be put. These services can then make use of each other in order to implement a certain function. For example, an EJB-service would require JNDI- and JTS-services to be available. By building the server in a modular way implementations can be replaced on the fly.
From their web site: Briefly, Gamora is intended to be a server to end all servers. The idea sprung from a late night coding session of a server for a Java app when I realized (As I had probably many times before) that I was writing the same code every time. So, I thought, why not provide a framework for building servers that drastically slashes the time it takes to create servers.
DWR is Ajax for Java
I recommend you confine the 'app server' to:
1. managing state between http requests
2. connecting legacy stuff to HTTP responses
3. mapping HTTP requests into a transaction space.
If you can architect thusly, you can use this recipe:
apache
mod_jserv
mod_php, mod_perl, etc.
mySQL
gnuJSP
jWebForm
And remember, none of the above are mutually exclusive. Don't pay enterprise-class java grinders to hack html, and vice-versa.
How can they feel the rain but not know of the flood?
The company I work for used Enhydra to deploy a WWW e-commerce solution, when it was Lutris Business Server. The problems we have had were based around Java (Sun JDK). The consensus is that Java 2.0 is required if any stability is required. I wrote the database layer we use, on top of Jconnect from Sybase. I also spent a lot of time babysitting the system. Since the Java 2.0 upgrade it seems to be very solid and the performance acceptable. As far as the architecture of Enhydra/LBS goes, I thought it to be fairly good. The major issues I had were the lack of a good procedural database API library and a good email library. The implementation of an email sender uses command line Sendmail rather than a Java based SMTP client. The server Java stuff isn't a blazing whack of speed, but it's decent. After having used server side Java, my opinions have greatly changed. I personally think you're better off using Perl, especially if you use mod_perl. YMMV
These products seem to be 'pure' Java (ie they use no non-standard native code). That means you can run them on any compliant runtime you like. HotSpot and GCJ ain't finished yet, but when they are you can just use them.
Hi there,
:)
I'd suggest anyone interested in web application servers also take a look at Zope:
http://www.zope.org
It's not in Java but in Python. It is open source, very dynamic, uses some wonderful design ideas that really make life easier, and has a very nice user community. New features are being created at a rapid pace.
Some random hype:
* Manage it through the web! You can manage almost all of Zope through a web interface. No clients are needed, no server access other than web access is needed.
* object database; publish objects, not files, to the web. Objects can have properties and can talk to each other.
* acquisition; a concept somewhat like inheritance that has very powerful implications. (we have inheritance too; acquisition is inheritance around another axis, so to speak, so they are complement each other)
* Very configurable security system.
* If you don't know Python yet; a wonderfully clean, powerful, flexible, object oriented interpreted language.
* Zope is continuously being developed by Digital Creations, who are very responsive to the user/developer community. Open source not just in name, but done right.
* Okay, so I like it.
Regards,
Martijn
For more information, go to the Jakarta web site.
- Sam Ruby
"E*Trade is all Java (v1.1.x) running on top of Netscape App Server (formerly Kiva)."
I've used NAS. It sucks. Terrible API. Inflexible. Lousy performance. You'd be better off writing your own from scratch.
"Cars.com is all Servlets and JDBC."
And they have serious problems because of it. I've seen their design and it's not very scalable.
There's nothing magic about JavaBeans. You can program a perfectly good, scalable app using simpler stuff like Gnu Server Pages from http://www.bitmechanic.com/. This won't prevent you from using JavaBeans, but it won't force you to use a certain methodology for your development, and I like that.
You should also keep in mind that Java on Linux is dog slow and probably will be for a while. Java is solid on Solaris and NT, but Perl is currently in better shape on Linux, IMHO.
"And actually, an Apache (and asumably mod_perl) mySQL combination is never going to give you the scalability that a commercial appserver and ORACLE combination can give you.
The clustering features of most decent app servers combined with the massive parallelism features of ORACLE just can't be beat if you have the money to spent."
That's completely untrue. I've used Netscape's "application server" and it's just junk. We were running on big Sun hardware with the latest optimized JVM, and it still didn't perform well or reliably. The clustering features are no replacement for a load-balancer in front of the webservers, and it's not difficult to share session/state information between machines using a database. There is no reason to buy this stuff. Just use the good open source stuff (mod_jserv, mod_perl, PHP) as a base and write your app on top of it. Most people end up hacking lots of stuff onto these app servers anyway to get them to work.
Jakarta is just the code name for what the jserv community is becoming - the repository and reference implementors of the Servlet specs.
Same developers, same codebase, merging the Sun code with the jserv code to create a killer engine.
Not to nitpick, but Tcl & Tk originated at UC Berkeley (GO BEARS!). Dr. John Ousterhout was the man behind it.
Scuttlemonkey is a troll
Java Server Pages (JSP) has been recommended in a few posts. Although JSP has some good things going for it -- open specification vs. proprietary markup, easy integration with Java objects, Beans, standard and 3rd party Java APIs -- it also has some serious problems. The main problem is that JSP is a clone of ASP a 3(?) year old technology.
JSP, ASP, and Cold Fusion, they're all the same model. Your content is managed in files. Those same files also manage your code. I'm aware each platform has facilities for marshalling external objects. And I'll even pretend that everyone in your orginization is going to be good and code business rules in seperate objects. Even then, you're still mixing presentation with logic. Worse, you're managing content with files, unless you have a handfull of master, super dynamic templates that don't even dictate presentation. But then, you're implementing a content management engine that could be more easily written as a Java Servlet or your own app server.
There are some alternatives to using middle-webbish (ASP, JSP, CFML) for dynamic content:
A group at java.apache.org are working on the Server Pages Foundation Classes. One of the problems they address is the loose coupling between "templates" when you're developing a workflow that takes place accross many screens (like account creation, shopping cart, etc.).
Also at java.apache.org is Cocoon, a Java Servlet (or standalone Java app) that use XML and XTL (XSL:T) to serve pages where content is seperate from presentation.
More on the XML front -- which is, IMO, the current best approach to develop highly dynamic, content driven sites -- IBM Alphaworks has a lot of XML tools available. The two I've found the most usefull are xml4j and lotus XSL. The source is available for both, but I haven't reviewed the licenses. No matter, other OS XML projects -- like Cocoon --- are capable of utilizing the commercial APIs by defining their own API, then implementing wrappers around IBM's classes.
And there's many more...these are just the ones I know enough about to comment on. The reality is, middle webbish is proving insufficient. This has produced an area bubbling with ideas and new approaches to developing and managing dynamic Web sites.
ASP is 3 years old. It and it's clones have enabled the Web to grow, but those technologies are bursting at the seams. XML is new, perhaps too new, and it's debatable if XTL (XSL:T) will catch on. But one thing is certain to me: XML is where it's at.
I've been using a proprietary Java app server for about a year now (Dynamo from Art Technology Group), and I've had mixed luck with it. It supports a bunch of useful web-oriented stuff quite well, but it's overly complex, and the proprietary nature has caused a lot of problems.
As I've looked around for other possibilities (Open Source preferred, proprietary considered), I've started to ask the question above: what exactly do we expect an App Server to do?
If you read the marketing materials and press releases, all app servers seem to do everything. However, my sense is that each product is trying to solve one particular problem, and, if you get something which doesn't solve your problem, it's going to be painful to use (at best).
For example, for the database-backed, community-oriented site (like this one, say), what do you need from an app server?
My personal vote:
- Fast but flexible HTML templating
- Database Connection Pooling
- Possibly, session management (possibly not)
What else? From my experiences with Dynamo, I feel very strongly that you want your app server to support close to the minimal feature set you need, because that will make it simpler, which will make it stable (and easier to use, and all sorts of other good things).
For commerce, you'd need some other things. I haven't built a commerce site. What other things would those be, anyone who has?
Sometimes I think having an App Server for a database-backed web site is setting up a big, complex piece of technology simply to get around the CGI process-spawning performance hit. This seems to me like a Bad Idea, which is why I'm wondering:
What are we looking for from an app server?
Incidentally, this site, which was written by a small group (of how many?), serves an incredible number of pages, supports all kinds of collaborative trafficking of information, and is just in general an example of what The Web Should Be, doesn't have an app server at all -- unless you consider Apache and mod_perl to be an app server, which I'd be perfectly willing to do.
I have written a truly remarkable operating system which this sig is too small to contain.
I use Java servlets combined with Apache JServ on Apache connecting to mySQL. It's great!! It's really fast. Hopefully the Linux HotSpot stuff will be done soon, along with Java1.2 support in JServ...
RateVegas.com - Vegas Reviews
I'll drink to this... Too bad you can't deploy WebObjects on Linux yet... Solaris, NT, MacOS X, HP-UX only... Still, a great platform!!
Just gotta get rid of the Objctive-C zealots...
RateVegas.com - Vegas Reviews
Why not try WebObjects. It is the best App server out there and you can write the whole thing in Java if you want to.
Runs on Solaris, HP-UX, NT and MacOS X
Maybe you shouldn't.
On the other hand, if you're interested in a language that actually enforces object integrity and type safety, maybe you should give Java (or half a dozen other OO languages) a look.
And if you're interested in finding a DB which supports foreign keys or rollbacks, maybe you should look beyond MySQL too.
Don't get me wrong: I use both PHP and MySQL nearly to the exclusion of everything else. But that's just because it happens to be suitable to everything I need to do. Remember the adage, "When all you have is a hammer, everything starts to look like a nail." Well, when all you have are nails, you start to wonder why you'd need anything that isn't a hammer.
High Performance Java:
+ E*Trade is all Java (v1.1.x) running on top of Netscape App Server (formerly Kiva).
+ Cars.com is all Servlets and JDBC.
+ I have personally load tested a single Sun UE2 (2x300MHz) running Java Web Server and Servlets (with db access) up to 315,000 transactions/hour. This was done with JDK 1.2b3.
+ There are many others....
HotSpot:
+ HotSpot is a replacement VM, not a compiler. I spoke with some of the guys from the development team, and they are very near 100% Java2 compatability. If something uses a Java2 VM, you will be able to replace it with HotSpot.
TowerJ:
+ I have first-hand knowledge of a large European auto company using TowerJ to compile a client-side Java(CORBA) application. It worked as intended, and sped things up quite a bit.
So there you go,
jason
What are the 'serious problems' that Cars.com has as a result of using Servlets? A few months back they switched from using the JWS to using NES as the web server, but that's the only change I've seen lately. Was that the problem? Also, how was the architecture not scalable?
I'm not defending NAS, per se, but the fact is ETrade get boatloads of traffic, and they handle it reasonably well.
I don't suppose you've single-handedly built an app server and run a site on it that gets in excess of 10M hits/day, have you? How'd you do it?
Can someone with real-world experience with both application servers and more standard technologies (CGI, Perl, JSP, servlets, etc.) compare what advantages app servers and/or EJB really bring to the table? I am developing my first app server project now (Enhydra), and see some definite advantages, but not a huge number of them, at least for now.
BTW, please don't mention MySQL, or database comparisons... the database backend doesn't matter in the discussion of app servers/EJB vs not.
----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
If you aren't stuck on the idea of having an open source product, I've also found that WebSphere is pretty good, although I haven't really given it the once over in Linux yet (just installed the beta yesterday).
We did some speed comparisons a month or so ago comparing various servlet engines under Solaris. Using Netscape's incredibly slow java engine as
a baseline, we found that ServletExec, and JRun
provided about 3 times the performance and WebSphere gave about 5 times the performance (if I recall correctly). Apache was not a possible webserver choice for this experiment though, so I didn't get to see how JServ would handle the test.
Hope that's of some help!
---
This sig has been temporarily disconnected or is no longer in service
call the classes and get the information out of them.
---
This sig has been temporarily disconnected or is no longer in service
Locomotive
Protomatter
Enhydra
this space intentionally left blank (oops)
Please help the rest of us and don't use the word "solutions". Of any word that marketing types can latch onto and overuse, "solutions" is the worst. I know I'm not alone in wondering what the world did before we had "solutions" to solve our problems.
If you can eradicate this scourge from our lives, please do. The public thanks you.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
How about widening the box for /. posts? (Or telling newbies they don't have to hit return overly much?)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Actually, you can use Apache JServ as the servlet runner to operate Enhydra under. If used in this configuration, Enhydra offers extensions and additions to what you would normally have with plain servlets. You might want to look at this for some info on why a few people have chosen to stick with Enhydra. BTW, if you don't have JServ (or a web server for that matter) you can run Enhydra apps directly with the built in web server functionality.
- You don't have to use the whole app server. There are many different parts (jddi, xmlc, standarddatabasemanager, data object design studio) that can be used separately with any Java project you are working on.
- Data access couldn't be much easier. A graphical tool is provided for doing object/relational mapping on existing databases, as well as constructing new databases from an Object design standpoint.
- EJB support is on its way. The Enhydra team is working on a demo of EJB support in Enhydra. This will most likely tie into EJBOSS
I've been very pleased with Enhydra, and I feel that the Enhydra community is only in the beginning phases. With a little more involvement, it is set to take off in a big way. It's certainly worth a download, just to check out the various components and determine their usefulness to you.Can someone explain to me why an appserver is more scalable than a solution like mod_perl. Providing I code my application to maintain no state on the web servers, I can just keep adding web servers if I run out of horsepower. Eventually the bottleneck becomes the database. Isn't the same thing true for app servers. You keep adding more of them and eventually the database becomes the bottleneck? Just seems a more complicated way of getting to the same answer.
Alexium - open source software and articles for web publishers
Here is my number one reason why Java is the right way to go for server apps. Unless you use OS hooks and kludges and the like, there is no equivalent in C/C++. (Perl is a different ballgame, and here I'm making the assumption that top speed is critical.)
// Tell programmer to be more careful...
String stringToPrint;
void saySomethingNifty() {
httpWriter.println(stringToPrint);
}
void doSomethingButForgiveStupidProgrammer() {
try {
saySomethingNifty();
} catch (Throwable t) {
}
}
Do you see how great that code is? If the programmer accidentally references a null pointer, runs out of memory, or even deletes a class file by accident, there is still an elegant way to recover. Of course this is oversimplified, but now that I have written a server app in Java I can't imagine how the same stability could ever be achieved with C/C++. When I add new code and it generates a NullPointerException, a very minimal disruption of service occurs. I've even found ways to recover from infinite loops.
Well there's Obj-C. If only GNUStep were complete, it's the only OO programming environment you would ever want.
I think the trick here that Netscape uses is that the most important libaries: Database, templating, i/o, caching, etc, are all written in c++. Also, we are using a JIT compiler, and the classes are cached between sessions.
Now, if only there were a open source version of this. All the speed of native, and yet I can code in Java!
-- these are only opinions and they might not be mine.
I'm using Apache JServ with great success (or should I say that it's the most stable, most problem-free piece so far). I think that it's termed more of a 'servlet engine' than an 'application server' but I'm not crystal clear on the differeneces anyway. Speed has not been an issue AT ALL - it generates and serves some dynamic pages faster than similar static ones elsewhere on our intranet. The servlet solutions take a hit on the first instantiaion, but are blazing fast thereafter.
In our environ, it's part of a 3-tier (or is it 4?) system (apache-jserv-openlink middleware-ms sql & db2) that's in partial production. The earlier beta version were a b*tch to configure and get active, but are very stable once you do. I'll be trying out the 1.0 versions this week.
Feel free to email questions.
I've done some fairly extensive research into many of the commercial players (Apple WebObjects, ATG Dynamo, BEA WebLogic, Bluestone Sapphire/Web, Gemstone/J, IBM WebSphere, Persistence PowerTier, Sun NetDynamics, Sybase EA Server) with a focus on their viability as a platform for Java development and here are a few (perhaps not very insightful) thoughts:
0. What is an "application server"? The way that I've come to use the term is a middlware product that provides a development framework; addresses functionality like failover/redundancy, database connectivity and connection pooling, and state and session management; provides reporting and management tools and generally a development tools and wizards. That's pretty generic and different people definitely us the term to mean different things.
1. There aren't any astoundingly bad products in the bunch, though some are obviously better than others.
2. They've got different strengths so there isn't a single product that is best for everyone in every situation. (Examples to follow)
3. They are also all quite pricy. 10K-30K/CPU + 2K-10K/developer seat tends to be the range.
My observations about some of the specific products:
1. WebObjects has a very complete, well-thought out development environment, however, its Java support is somewhat incomplete (e.g, no EJB support) and it pretty much restricts you to doing development under NT. I also have reservations about whether Apple, much as I love it, is serious about and capable of playing in the enterprise computing market. It's certainly a proven technology, though somewhat proprietary. Good for RAD development, if you don't have to worry about migrating an existing code base or about potentially migrating to another platform later on.
2. Dynamo is probably best suited if you're interested in using their whole suite of products (personalization, ad serving, etc.). It's really only suited for web sites, so if you are looking for a more generic middleware product for non-web applications, it's not a good fit. It does have reasonably good support of Java standards. Since they are a smaller company, as the app server market consolidates they might get squeezed out or acquired.
3. WebLogic is the product that was the best fit for us. A pure Java product with the most complete support for Java standards, including a comparatively robust EJB implementation. It doesn't come with a development environment although it does have some nice hooks into third-party IDEs and a nice EJB wizard. Whether you prefer this approach to the included IDE route is pretty subjective.
4. Sapphire/Web has an elegant, robust architecture and has the added benefit of also being an XML server. Java support is pretty complete. I really didn't like their development environment or the way that pregenerated code and custom code live together. Same concerns about market consolidation.
5. I didn't get a very good feel for Gemstone/J although it seems to be most similar to Sapphire/Web. Fairly complete Java support, some oddities in actual development. Those familiar (and happy) with their SmallTalk product might want to go with this.
6. WebSphere seems very much like a work in progress. IBM is certainly making progress, but it still feels incomplete. I really can't recommend it yet, but it's worth keeping an eye on. It inherits IBM's heavy Java focus.
7. PowerTier is another product that I don't have as much of a feel for. Pretty complete Java support and with some interesting database stuff going on. It's not a Java product itself though, for better and worse.
8. I looked at NetDynamics a generation back and it seemed to be distinctly behind the curve in Java support - ironic, huh? They seem to have made strides towards addressing that, but I don't think anyone really knows what's going to happen with NetDynamics and Netscape Application Server now that Sun owns them both. I'd be inclined to stay away from both until the picture becomes more clear.
9. Sybase EA is much improved from it's earlier incarnation (Jaguar), but it about a generation away. Probably a good fit for shops looking to go Sybase across all tiers.
A bit of background - perhaps this should have gone at the beginning - I've used PHP fairly extensively and while I like it as a product, it doesn't really provide the facilities for stateful sessions which is important to the work we do. For the last year we've been using servlets+JServ and a custom built Java app server, with the servlets talking to the app server via RMI. For those following along at home, building an app server is a serious undertaking...
JServ is a nice servlet engine as are commercial competitors like JRun and ServletExpress. If you're just looking to do servlet work, this should be fine. If you're looking to build EJBs and server side Java objects beyond servlets, you'll want something more.
I should also point out that there are obviously lots of other languages that work perfectly well for building database driven, dynamic content sites.
Finally a couple thoughts on EJBs - It's worth noting that EJBs in general are very much a work in progress, so it behooves you to know the issues before selecting them as a development route. It is really a different way of doing things. Tools for EJB development aren't very mature. Also, entity EJBs really don't span multiple tables well and stored procedures are basically out of the picture if you use container managed beans. So, it means that you lose database transparency and distribution of load, both of which are good things in my mind. There are some products in the works to address this (e.g., TopLink for WebLogic), but this is a very new market. Don't work on the cutting edge if you aren't willing to lose some blood...
Finally run out of things to say. Hope this helps...
Their product is really very nice, but a little expensive (like $10K). If you're doing enterprise Java work, it's great though. It supports (or plans to support in the near future) all the "enterprise" java APIs and services.
-nate
Hey,
;-)
;-)
I wrote the protomatter stuff, and so I'm pretty biased. PAS (Protomatter Application Server) is a good tool if you're doing simple data-driven site with servlets or JSPs.
It's really designed to only work with Apache JServ, but *should* work with pretty much any web server that supports servlets (it is a servlet itself).
It's main features are:
- Full-featured JDBC connection pools
- Simple JNDI implementation
- Startup/Shutdown classes
- Hierarchical event trees
- Cron-like scheduling
- Robust logging
If that's what you need, then use it. It doesn't support EJBs (and probably never will). It's been used on several production sites, and seems to be quite nice (IMHO
One caveat is that there is exactly one developer for it: me. I've recently taken a new job where I travel about 99% of the time, so I may not have much time to devote to it in the future, but what's there works and works well.
It's also worth noting that the connection pools and logging system are both easily usable outside of PAS, so you could just use those packages in some other app server.
Anyway, it's just kinda cool to see my stuff show up on slashdot
see ya,
-nate
I have built a java middle tier as well as an
applet front-end for connecting to a mSQL database. In my experience the middle tier has
been plenty fast enough. As for the applet front
end, yes it's a bit slow to load in the beginning,
but once it's loaded it's more than capable of keeping up with user input.
AFAIK Jakarta hasn't been started yet - they are still waiting for the reference code from Sun.
However, the Java Apache project is going strong, the final build of JServ (a servlet engine) was released recently, along with mod_jserv (Apache hooks to JServ).
They also have produced Cocoon, which is a XML transformation engine, and rather good too. Version 1 is just a proof of concept but still works well, version 2 which is being designed now looks like it will be amazing, the groundwork going into it is amazing.
well...i'd like to keep my logic separated from presentation. php actually seems (havent used it) to be really cool from what little i know but im not sure if it has advanced features like pooling which are generally needed if you want to scale well
p.s. sorry for the fscked up links, coulda wsore i did them correctly
-- your knees hurt, don't they?
Just FYI, Apple's WebObjects won the Java Developer's Journal Reader's Choice Award for Best Application Server. Definitely worth a look.
None of known to me data processing application works on a "naked" hardware, so even if we assume that Java is not used for a middle tier application, but for a deeper digging "100% Java" application server, it still stands on a very high foundation of a native code. A typical data-application server will spend most of it's time waiting for IO completion here and there and not cranching what it retrieved from disks. Why do you think all those PL/SQL at al applications survived and even prosperred?
One may argue that Java based app.server will create more load on a processor that native-code compiled application. While to some extent this is true, the difference is not that significant with a JIT, when Java can come a little closer to the hardware. On the other hand, despite all the deficiencies in the language itself that can only be abhored (like elimination of multiple inheritance, inability to overload operators, absence of templates - IMHO the last one is particularly painfull) it still provides today unmatched environment for programmer productivity with it's garbage collection and extensive standard library.
The only visible prblem today for Java based app.servers - besides those mentioned above language constraints - is memory consumption, which is quite significant. But again, a typical hardware for app.servers today has more than 64M of RAM (you have to run your database somehow and it loves to cache pages), so it's usually not a real problem.
In my carrier as a software engineer I have been involved in several quite large projects that targeted application servers. Some of them where written in C++, and some, more recent, in Java. We never experienced performance problems with Java servers, but it's worth to mention that our development productivity has increased and noticeably.
One more comment - about "green" threads JVM: though the entire process is executed by a single CPU, provided properly implemented, JVM should be able to let threads run when one/several of them are waiting on IO completion. It would take careful design with non-blocking I/O, but it's doable, and I would guess that Sun's green-thread JVM uses something like that.
I think that I see your problem. I had assumed that you were working with applets and that's why you were complaining about speed. In reality, its probably just your expectations.
In an NT world you are using at least 32 MB just for the operating system. Add another 16 for application server overhead, and another 16MB for web server overhead and caching, and that means that you are going to be paging to disk constantly even with low system usage. Assuming ten thousand concurrent users, you have just 6.4 KB per user, not even counting the overhead.
Yes, an Apache/mod_perl system will run better under these kinds of conditions. Linux has a much leaner footprint, and Apache can be tweaked for low memory footprints.
On the other hand, if you are going to be paying six figures for application server software (Tengah, now called WebLogic after being bought out by BEA, isn't cheap) why don't you invest some money in hardware? Most application servers require at least 128MB per processor and most recommend a quarter gig to a half gig per processor. (Application servers tend to be much more memory intensive than CPU intensive. I've even seen some systems perform much better with 1GB per processor.) You can get 128MB SIMMS for $300-$400 these days.
The bottom line being: if you have an existing low-end piece of hardware that you need to get the most bang for your buck from, you should be looking at PHP or something similar. If you are looking for something that is scalable to tens of thousands of concurrent users, and is easy to develop and maintain, you should be looking at Java application servers. But if you do, you should expect to have to scale your hardware appropriately.
I know that the hype around Java says that it's slow, but it just isn't true in the app server world. Java is what most of the major commercial projects use as their development language. A lot of major e-commerce sites run on Java based deployments.
Some tests that I've seen indicate that Java only runs 10-15% slower than C/C++ on a good application server. And considering that Java is so much easier to develop in, I think that this tradeoff is worth it. And that was before HotSpot. Once HotSpot is integrated into application servers that performance gap may not even exist. (Yes Java is slow when used for applets, but that's a much different environment.)
And actually, an Apache (and asumably mod_perl) mySQL combination is never going to give you the scalability that a commercial appserver and ORACLE combination can give you. The clustering features of most decent app servers combined with the massive parallelism features of ORACLE just can't be beat if you have the money to spent.
That being said, there are lots of great open source solutions, both for high scale and moderate scale deployments. I just wanted to dispute the claim that Apache/mySQL will be more scalable than any Java-based solution. I've worked with both, and the Java-based solutions were able to scale much further.
I'm just putting this out as a choice and am not going to give any opinions. I have not personally used it.
SCO Tarantella
---- "It is never too late to give up our prejudices." --Henry David Thoreau(1817-1862)
In your place, I would reconsider whether you really schould use a Java-based solution, solely for the reason of speed. (In fact, I see many other problems in Java, but speed is what websites are about).
We have seen a lot of benchmarks for Webservers and it is a tight race. Using a RDBMS written in native code reduces response times, but its a database you want and these are the fastest you get.
I have programmed Java for half a year in an internship, hab a pII/300 and 256Megs of Ram, and it was only just bearable. Imaginig some Java-based huge Database-backend to a highly frequented site is nothing I can imagine.
No 'solution' using Java (be it as a means of Data Storage or even a highly used servlet) would be able of the figures that, say Apache and mySQL give you. I actually believe that you would need a really really big machine to manage this for a site that would be fine with some Cobalt RAQ and mySQL.
Ben
There are two Apache/Java integration projects that I know about; one was already mentioned, the Jakarta project (jakarta.apache.org), "dedicated to providing a high quality, world class 100% Pure Java Servlet and JavaServer Pages implementation", and the Java Apache project (java.apache.org), which has a JVM built in to the Apache daemon, and inlcudes JSSI and full servlet support.
Though I haven't personally used either of these creations, I do know people who have had great success with the Java Apache modules. This project includes mod_java (similar in function to mod_perl or mod_php), client applications, and a document publishing framework as well as server extensions, so for a large scale solution, this may be worth checking out.
Also, I believe, the Java Apache project is more mature than the Jakarta project (although I may be mistaken about this).
darren(darren)
I've built lots of big systems in PHP, and earned a considerable amount of living doing it; so I'm really grateful to Rasmus and his team. However, I'm gradually moving all my systems away from PHP now, over to Java servlets.
Why?
Well, first is engineering. PHP is a neat hacky tool which does what it does very well. But it's not a well thought out general purpose programming language (it's not meant to be). And unless used in it's guise as an Apache module it's highly inefficient. Although I use Apache on all my servers, many of my customers don't.
Also, PHP versioning is a real problem -- it's very difficult to convert things written for PHP2 to PHP3, and PHP2 as distributed does not work with Apache 1.3 as distributed.
Whereas Java is a really elgant language which I use for most of my non-Web based stuff, and it's reasonably efficient, and the Servlets I write to plug into my Apache server will plug just as easily into my customers' Sun and Netscape servers, and even run on (hiss) (spit) NT without recompilation.
I'm old enough to remember when discussions on Slashdot were well informed.
Could someone please fix the URLs for proper clicking? (Then delete this post)
FunOne
FunOne
I too am looking for a Java app server... we're leaning towards WebLogic, though we haven't ruled out Sapphire. However, my boss came to me on Friday and said, "you know, we're a MCSP and have lots of $$$ invested in MS training and blah blah blah so you better give us all a good explanation as to why you're risking our largest contract on Java technology...." He has somewhat of a point, given that we are mandated to run on NT.... however, the DNA architecture is a load of unreliable, unscalable, stateless, single-threaded garbage, IMHO. But, I still have to drill down on the MS BS with him... does anyone have their reasons for using a Java app server over the DNA architecture?
I think I've got a good case, but I need more fuel, lest I end up sleeping with VB books for the next few months.
-MVK
Actually, most compilers do/will not support dynamic loading of classes. I'm not certain that you can't work around this restriction, but I'd caution against just assuming that these compilers will work with, say, EJBs out of the box.
I'm pretty sure they won't actually. EJB containers automatically generate wrapper classes at "deployment" time. These classes are created after you've compiled your app, and thus the app won't be able to use 'em.
You can work up a fix for this fairly easily, I'd imagine, but still it needs fixing, I think.
Johan
I'm too lame^H^Hzy to attribute and reply to this post properly... sue me
Several good points made here... I think the most important one being that yes, at some point Sun will lose the iron grip on Java that they now have. Don't know if I will personally like it any better then, but a lot of others probably will.
Separating good ideas from politics should become part of the core curriculum for anyone who wants to hack profitably [1] in the world in which we live today. The source of a good idea does not make it less good. It may make it less accessible to some if the source wants you to pay for it, or control how you use it, but it is still good (else why would you care whether you could use it at all).
[1] don't even flame me on this... you like to eat and have a home stocked with unlimited Mountain Dew and Coke Classic just as much as I do
"We're an apex predator with the fecundity of a base level herbivore... We're a virus with shoes..." RazorJAK
Can we put a lid on the elitism at least when we're answering Ask Slashdots?
grep -ri 'should work'
We built our site with their stuff, and it's quite good. they've got a page syntax that completely separates Java from HTML, so your graphics people can focus on the appearance of the site, and your programmers can focus on backend, and delivery of the data. They've also got "PersonalizationStation", which allows you to immediately create user profiles out of the box -- and dynamically target your site based on those profiles. (In other words, counting the number of logins that a person has to your site, and changing the front page from "Welcome to our site" to "Welcome back" is about a one-liner.)
Remote admin? No problem. The "component browser" uses bean introspection, allowing you to look at -- and change! -- any object in the system, dynamically.
I've been looking lately at the new JSP spec from Sun, and I'm not thrilled with the high integration of Java into the pages. Our html people are supposed to concentrate on their speciality, using html tools and such to make the pages look their best. With JSP all of our html people would also need to be java programmers (and contrary to popular opinion, the number of people who really are expert in both areas is very small. I know HTML, but I won't claim to be an expert UI designer).
For folks that are saying "Don't use Java because it's too slow" -- speed only ever increases. Ten years ago I wouldn't have said "Don't use a 286 because it's too slow." As products like Hotspot and TowerJ become popular, Java's speed increases drastically.
Disclaimer: I don't work for ATG, just for one of their customers. We're happy with their product.
It's not Java, but in our current project we've found the Perl system Mason (available from CPAN as HTML::Mason) to be very good. There are a couple of annoying bugs, but supports a scalable rapid prototyping model better than anything else I've seen.
Aside: The project we're working on is a University intranet/extranet, designed to support about 40,000 users across two continents. All pages are dynamically generated, written in Perl with Oracle and LDAP helpers. HTML::Mason handles the task extremely well on sufficiently grunty hardware.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
If you don't want to mix up HTML and PHP, use FastTemplates. I've written some apps for clients using that thing, it completely seperates code from HTML. The average size of these apps is about 10000 lines (wc -l) of PHP code. Maintaining and enhancing it would be a nightmare, if I would have to deal with the designer's HTML stuff.
FastTemplate Tutorial
And yes, of course, PHP is not the right tool for every job. The same is true for Java.
PHP isn't limited to MySQL. In fact, it supports about 15 RDBMs, can talk via ODBC and access several non-relational databases. So, the question isn't about choosing a database.
Define 'real' programming language. PHP4, the successor to PHP3, is completely backwards compatible while increasing the speed of scripts and compiled binaries (not stand-alone) considerably. In fact, it's often magnitudes faster than the current PHP3.
There are discussions going on on the php developers list to make JNI accessible from within PHP. In effect, you could write your Java beans or whatever as usual and use them from PHP. That way you could take full advantage of the rapid prototyping capabilities of PHP.
Bull's EJB server is easy to set up and works well, as far as I can tell from the limited experience I've had with it. It seems to be significantly faster than EJBHome, for instance.
But perhaps I missed your point?
I have discovered a wonderful
Not having used either, perhaps I shouldn't comment :-)
But what I'd worry about are:
-- Does mysql handle concurrency? Remember that you may have several requests being processed at once by your web server.
-- Is PHP3 a 'real' programming language? That is, are you going to reach a point where it is not powerful or efficient enough to do what you want? When you reach this point can you easily use a third tier written in a different languiage? Note that PHP3 & a database doesn't count as three tier IMHO -- I don't think the browser is really a tier any more than a VT100 is.
Java application servers can provide a 'solution' (there's that word again) using Servlets/JSP in the first tier, Beans (or Enterprise Beans) in the second and the relational database of your choice in the third.
That second tier contains most of your 'business rules' expressed in a good programming language, the first tier handles presentation.
Compared to PHP3/mysql you've separated the programming from the presentation more cleanly, and only need one language.
I have discovered a wonderful
Even though IBM WebSphere is commercial you might want to look at it's features to see what one can do with a Web Application Server. You might also compare IBM WebSphere with simply a webserver that supports servlets. Keep in mind how large your application may grow. While things like simplicity, reusability, security, and good performance are very important pick a architecture that allows your app to be extensible as well.
A blip from the IBM web site:
IBM WebSphere(TM) Application Server is a Java(TM)-based application environment for building, deploying and managing Internet and intranet Web applications. This complete set of products expands to fit your Web application server needs, ranging from the simple to the advanced to the enterprise level.
http://www.software.ibm.com/webservers/
Enhydra is very cool. It's getting a real user community and it's improving very fast. The XMLC compiler allows a real separation of work done by designers and programmers.
By the way, Bull is open-sourcing it's EJB application server. It supports Enterprise JavaBeans(tm) and transactions.
Best regards
Ismael Ghalimi
ghalimi@exoffice.com
mySQL is way cool but does not support them.
And if you need scalability and fault tolerance, distributed transactions may be a good idea. Then you will need some kind of transaction monitor. The Java Enterprise(tm) platform offers a model for such transactions called JTS (Java Transaction Service) and the application server from BullSoft supports them.
Best regards
Ismael Ghalimi
Php and Zope are two different sort of things. I would call Zope an application server. I wouldn't call PHP an application server, although you can do a lot of the same things with it.
I use PHP, and I am looking at using Zope, and I can see places where both have strengths. In a lot of ways, it is a difference between some sort of templating system/server-side scripting system (Php, Perl-with-your-favorite-modules, SSI, etc.) vs. an integrated serving package like Zope.
Whether you prefer the former or the latter I would think depends on a) how much you enjoy programming and b) whether the content development is being done by one person, or is heavily distributed. Packages like Zope tend to insulate you from coding (at least until you need to go beyond the basic packages), and are usually built to facilitate heavily distributed content management.
I have used this on Solaris and also on NT, and I like it. Look closely at the design, JServ could be used to make REALLY big sites. Multiple JVM's, context separation, Many Web server to Many JVM's, load balancing...
I was under the impression that ETrade ran on BEA's TUXEDO, and TUXEDO does not support anything other than C, C++ or COBOL (yeech!) for server side applications. Yes you can write TUXEDO clients in Java using Jolt, which is horrid.
Are you talking about E*Trade's web interface or their trading engine or both (it wouldn't surprise me if the web interface is nice Java, while the trading engine is cold-hard C or COBOL in TUXEDO!).
The unfortunate thing is... it is very hard to convince people that Java is ready for enterprise OLTP... I'm not convinced myself! We're writing a product using TUXEDO / C and embedded SQL, I would dearly love to write it in Java, but until someone can prove that it won't run like a dog (or at least, not run so slow that the hardware upgrades bankrupt our customers!) AND it will sensibly support XA/2pc (ob this is the responsibility of the Java app server) then we have to stay with the tried and true proven technology!
Egads!
jrw
Folks,
I think the proliferation of Java app servers, esp open-source ones, is great... but how ready are they for high-performance apps? Do any of these open source app servers support integration with HotSpot, Tower J, the IBM java hpc or for that matter, Cygnus' gcj project?
jrw