Slashdot Mirror
LAMP Grid Application Server, No More J2EE
An anonymous reader writes "Check out this blog entry in Loosely Coupled about ActiveGrid's new open source Grid Application Server based on the LAMP (Linux, Apache, MySQL, PHP/Python/Perl) stack. Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE."
Slashdotters help me with this; on the right I have an over-engineered J2EE with a dozen of work arounds that are over hyped like EJB facades and dozens of frameworks that are difficult to learn and slow (..and kinky, every one and their mom developed a framework), and there are no free (as in beer) quality servers (I know JBoss but good luck without the documentation), on the extreme left I have LAMP, a loosely coupled system, PHP is popular but lets admit it is an ugly hack just looking at PHP5 reconfirms my believe that PHP didn't handle it fast growth properly, in the middle there is Microsoft which I hate and don't want to consider., I want a decent middle ware, that is cross platform, fast, and well documented, free as in beer (and preferably as in speech also).
For the majority of enterprise projects I've worked on, we wouldn't event consider a platform that didn't perform Two Phase Commits (MySQL) nor supported distributed transactions. This stuff still has a long way to go before it's to be taken seriously.
Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE
(emphasis mine)
Remember, folks, Java is more than just J2EE and J2EE is only a part of Java. There are many enterprise applications written without the cancer that is J2EE. There a great number of alternative frameworks for building enterprise applications.
Personally, I feel that J2EE justifies itself because the bloat of a J2EE server means you have to have multiple instances to support an equivalent load a non-J2EE solution could handle on a single server.
Use Lisp. Seriously. It's one of the oldest languages out there, but it has features that other languages can only dream of (in fact, when other languages improve, they almost invariably get closer to Lisp).
The language is well-documented. Implementations range from simple interpreters to complex, optimizing compilers (they are on par with C, and sometimes outperform it). It has packages for many purposes, enough to implement Yahoo! Store at any rate.
People complain about the parentheses (some say LISP is short for Lots of Irritating Superfluous Parentheses). That's a valid point. In C syntax, at least there's variation. Besides parentheses there are curly braces, straight brackets, commas, semicolons, etc. Seriously, the parentheses make for a very simple and consistent syntax.
Lisp allows you to program in whichever paradigm suits you best (pick the right one for the task at hand). Functional, object oriented, imperative, it's all there. It's macro system is so powerful it lets you basically generate programs, rather than writing them. Add garbage collection, higher order functions, dynamic typing (although static typing can be used for performance), arbitrary precision arithmetic (integers are not limited to 32 bits), multiple inheritance, and tail call optimization (recursion in constant space), and you have a language that blows all others out of the water.
Why does nobody use it? Fear, uncertainty and doubt. People think it died with AI. People think its old, so it won't be up to modern tasks. People can't get over the parentheses. The boss won't approve it. Nobody else uses it, so it's hard to get support. Any number of reasons.
Please correct me if I got my facts wrong.
This month's meeting at my local Java user's group there was an impressive demo on Ruby on Rails. The presenter built a blogging application live in front of the group, literally in 10 minutes or so. Prior to this demo I had pretty much written Ruby off "just another alternative to perl or python" but I have to say that Rails looks really impressive, enough so that I'm taking a closer look at Ruby.
One of the guys in our user's group, Chris Nelson, is building a similar framework for Java - called Trails. He also built a blogging application live during the meeting. It took him a bit longer - perhaps 15-20 minutes. It was impressive as well, although I will say that for Trails you need to know a fair amount about Hibernate and Tapestry. Realize that he's been working on this only for a few months and suddenly you see that this work is very impressive too.
Anyone interested in developing web apps might want to check these projects out - very impressive stuff!
Agreed.
We started using Mason here and have just not looked back. It has so many useful features built-in for site maintenance, and to top it all it allows me to embed Perl. We put all our application logic in Perl modules, then wrap the site around it using Mason.
In fact I hereby propose a new meaning for LAMP:
Linux
Apache
Mason
Postgres
That man tried to kill mah Daddy
I've recently been involved with developing J2EE applications for our company's intranet. Well, it is very difficult to develop distributed web-based applications, simply because there are hundreds of details to take of.
For application servers alone, one has to know the peculiarities of each application server, its custom settings, its XML schemas and option files, its architecture, what databases it supports, how it supports each database, what other persistence options there are, its directories structure, and many other minute but critical details.
For J2EE, one has to know which framework to use, the logic behind each framework, how the framework connects to the database, how the framework is used by the application server and how compatible the two are, how the application server's persistency capabilities can work with the framework, each framework's options and configuration XML schemas, files and location of files, and many other things.
Then, for the client part (i.e. the web page), you have to know all the tag libraries and tags, the parameters of each tag, the syntax of each tag, the attributes, the attributes' value types and ranges, the details of its usage (when you need to use its one) etc.
And if you are gonna use a workflow engine with all that, you need to know how the workflow engine works, what persistence options the workflow engine has, the API, how to manage users (relative to the security of the application server, of the back-end databases, of the framework, of the HTTP connection and of Java), how to manage logons, how compatible the workflow is with the workflow patterns, if the workflow can run under the application server etc...
And beyond all that, one has to know the details of the databases: if and how transactions are supported, if and how row locking is supported, if automatically generated ids are supported, if there are blobs, if there is text search into blobs, how the database separates different instances (either by user or by db name), all the differents between the SQL of one to the other, etc.
Then there is the peculiarities of each IDE, the options available, the Java libraries to use etc.
Well, THATS A LOT OF STUFF.
It is a domain which is far larger than that of desktop applications, even with the same functionality. With desktop apps, all I need is how to know is the language, a few protocols like HTTP and maybe the database details. But with J2EE, the knowledge domain is far larger and much more discontinuous: there are too many details that are totally different between themselves, so it is too difficult for the individual to handle by him/herself.
The difficulty of developing J2EE applications comes from the fact that J2EE is actually no application model, but rather a set of classes to assist towards building web/distributed apps. That is why there are so many frameworks out there (I've counted at least 31).
Does LAMP solve all of this?
Ultimately, the programmer shouldn't have to worry about all that stuff. After all, a web application is just like any other application: there is the view (the HTML client), the model (the database) and the controllers (the business logic). In my opinion, J2EE shouldn't have moved away from the classic MVC pattern.
If LAMP development is easier than J2EE, that it might worth a try.
I don't especially love microsoft products but for what we do at work, MySQL wouldn't be a possible replacement. Microsoft's Sql server doesn't seem to require that much attention here, maybe more than other products but it doesn't seem so bad. And the feature set is very good. MySQL has no triggers, this is something i can't live without. I don't think it has the same level of support for stored procedures and user defined functions and i don't know if it supports authentication thru something like LDAP.
m$ also provides neat tools like a db management tool with a gui and a query tool as well. The management gui seems to be pretty good for the times i've used it.
Microsoft's SQL Server isn't the best database on earth but i really think the SQL server product is quite decent. Please explain why you'd need much more DBAs for the ms product vs mysql ?
100% of statistics are wrong.
For large scale projects, I use Java. It is great Object oriented language that I can use to the fullest extent. I can get very close to that MVC pattern that is soo useful in large-scale projects. I don't use EJBs -- not needed them yet. I use the JMS, WebServices, JSP/Servlets, etc. We connect to a real database (DB2). J2EE offers a completely different scale with work with. You can do everything from simple web applications to clustered app servers at several levels.
For smaller stuff, I like LAMP fairly well. It is simple and easy to get started, although not great for larger projects (code reuse, management, scaleability). MySQL, again, nice and fast for small stuff. I perfer PostgreSQL because of the power and flexibility. I'm trying to move more towards PostgreSQL especially after recent changes in licensing with MySQL. For these projects in general, I like PHP over Perl for webpages. Perl is still great for admin tools on the console or for confusing the heck out of folks not familiar with your code. PHP is simple and made for website based applications. Again, I'm not going down that path if I know it will grow into a huge project.
The deal is, they are tools. The both have their strengths and weaknesses. Evaluate your needs, and choose the best tool for the job. I use both and love both -- but choose wisely.
SPAM solution made easy: 1 spammer, 5 cords of rope, 5 hourses, and fireworks. Be creative.
Java is useful if you intend to treat most developers like lego blocks.
;).
.
;) ). Or they don't care - it's just a job after all - that's what they got the java certification for.
Example scenario: you have one main guru programmer who writes the program in Human Language (e.g. English). And you have the other much cheaper developers (in-house or off-shore) who compile that to Java. After that the guru programmer(s) can move on to other stuff whilst the interchangeable and cheap programmers maintain it.
You appear to NEED a fair sized team for lots of Java stuff, which if done in some other language can be done by just one to three people. This can be considered a minus or a plus. Coz in many organizations if you are a Boss of 20 people, you outrank a Boss of 3 people (and probably get paid more too) - which is why MS has its uses
I find Java stuff to have a lot of "make-work" stuff. You need all these layers and layers of stuff because you have all these layers and layers of other stuff. And often these layers and layers of stuff _don't_help_very_much_ - diminishing returns. Sure it is more "organized", but now you have to change 3 different files to make one change, or something like that (e.g. code, data, metadata)
Whereas the LAMP style stuff is relatively simple - O/S, Webserver, Database, Programming Language. So what if it isn't N-Tier, or have "Enterprise Java Beans" or have built-in caching or some other buzzword, very often you don't need that stuff - you run out of bandwidth, or hit some other limit first. If you keep things simple you can often easily scale the webservers (and appservers) horizontally (keep adding them). So the bottleneck is usually the DB, and there are many known solutions for that.
You probably end up with similar scaling limits with a Java solution anyway (except the Java solution typically has more layers, complexity and work).
The disadvantage of the LAMP stuff is while you only need a very small team (of one sometimes), since after all the guru programmer codes most of it; the problem is if the guru programmer gets bored or wants to do something else, you have a problem - who's there to maintain it? The "lego brick" programmers may not be able to handle the job. So you need to get another guru programmer who costs as much and is just as likely to get bored.
The lego brick Java programmers don't seem to get bored maybe because they get the feeling of satisfaction coz they are definitely doing lots of work and achieving a "lot" - (remember there are lots of layers to glue together- N-tier
Last but not least of all - it may not even matter at all whether you go LAMP or J2EE.
Coz amongst the most important bunch on the team are the graphic design/art people. It doesn't matter to the client or PHB how cruddy the architecture is - if the software _looks_ great, you are more than 50% done. It doesn't matter if your architecture handles up to 1000 transactions a second on an el-cheapo dell server, and scales very well. If the widgets look ugly you're unlikely to win the project.
After all not many can tell whether a software/system architecture is ugly or not. Whereas very many can agree and tell you immediately that a widget/icon/colour/layout is ugly. And that includes the people in charge of approving stuff.
I am lead developer (well, the only developer) for a major website (+half million page views per day).
When the owners of the website first came to me, they basically had a team of developers who worked around the clock to maintain the old website which was running JSP and Oracle on a total of 5 servers (I don't know the proc, mem, etc).
The website ran like a damn pig and the owners were tired of all the problems.
Basically, they came to me and asked me if I could re-create the entire website using FOSS and on two servers or less, while speeding the whole thing up. I'll be honest with you, I agreed to the job, but I was a little worried. Would LAMP live up to the hype?
I settled on MySQL 4.1.3, PHP 4.3.8 and Apache 2.0.50. First, the owner wanted to see what one system (single 2.4GHz, 2 gigs RAM) was capable of before putting the second one online (which was only an additional web server). A few months later, the site was finished. I was sweating bullets when we switched the DNS record and the requests started to pour in!
We've never had to turn the second webserver on. A single processor server (apache + PHP + mysql) handles the entire website, while the load average never climbs over 0.20.
Every page is dynamically generated with several DB hits per page and we're talking about more than half a million page views per day (over 2 million hits per day, over 500GB per month), while the server sits not even breaking a sweat.
Now, what can we conclude from this?
First of all, JSP with Oracle isn't remotely capable of this project with the resources given.
However, I do know from first hand experience that a LAMP design works well for large operations.
All of those are nice, but when I was looking around at solutions for a kind of document management solution, I found all of the Zope sites I tried were kind of sluggish. If your main goal is to satisfy customers then response time has got to be a factor.
Java has everything you listed, and multiple frameworks to boot - if your J2EE people are so far behind, perhaps they should just be writing servlets, or using Tapestry or Spring or IDE's that help you put together standard J2EE components more quickly.
Plenty of people in the Java worls are doing just fine with Agile development practices, thanks - Zope has no exclusivity there.
In the end for my own project I'm using Nukes on JBoss.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
You're right, we (as a group) can't make any solid conclusions from this data. One of the major problems is that I never saw the old code or know anything about the websites previous deisgn.
However, from my experience, in the future I will always recommend the setup I've already explained because I know it works well.
Give me your PHP/MySQL solution and I bet I can bring it to its knees with a few properly placed bad queries and/or data structures.
Of course, bad code will bring anything to its knees, no point there. That's the nice thing about advanced database methods; using stored procedures, transactions and the like can help maintain data integrity even if you've got a couple of bad developers in house, although it can act against you when considering performance.
To make any conclusions about technologies based on your one example would be a crime...
I could site other examples from co-workers or friends, but this is one example that has affected me personally. Do you have any examples of replacing FOSS with JSP and Oracle using weaker hardware and seeing an increase in performance?
"LISP also fails its readers by imposing prefix notation for every operation. If that's how we taught math from the first grade on up, and if talked like Yoda we all did, that would be great."
We do. You just don't recognize it.
You're given operand, operand, operator.
The stacking form in which grade school examples are given doesn't make this obvious, but that's the way the eyes and brain do it.
Zope is too slow to be useful, it REQUIRES you to run an http accelerator in front of it to be even mildly useful. But even then, every dynamic page still has to be requested from zope, which is insanely slow. Using squid and zope makes an iffy, not quite right solution, requiring stupid hacks to get zope to see the IP correctly, and ends up still being slower than just plain old apache+php, nevermind something fast like resin.
> There is nothing in your list that doesn't come with a halfway decent Java application server, like Resin.
You forgot to mention that Resin is god damned fast. Really changed my opinions on Java. Best of all, the "lite" version (which only lacks clustering and some caching code) is now GPL. Strangely I run Resin not for Java, strangely enough, but as a server front-end for some existing perl apps. Reason for this is because the FastCGI servlet it comes with is like the only free FastCGI implementation out there that's more or less drop-in and reliable on any platform.
Zope, however, really does have some innovative stuff that other app servers should look at. The main problem is the piles of crud on top of it -- Zope source is basically unmaintainable, and when you have a basically undocumented Zope product to deal with (a product being the equivalent of a web app), looking at that horrendous code is the only option you have.
they never adapt the lexical model of LISP
Ever heard of something called XML?
As Tim Bray points out, "XML does a lousy job of what Lisp S-expressions could do decades ago."
Value judgements aside, we can at least all agree that it's trivial to interconvert lexically between a LISP expression and an XML expression.
Further discussion on the C2 Wiki.
True for jython, false for groovy. Read about groovy beans.
Among python, perl, and PHP, only python has superior language syntax to Java, and groovy leapfrogs python. Groovy's syntax is probably second only to ruby in term of OO purity and clarity. Perl's CPAN libraries are the only one competitive with Java's libraries (and java wins narrowly even over perl). When you give groovy syntax to java, you will have an absolutley lethal combination.
Goovy's benefits from complete bytecode equivalence to Java cannot be overstated. Groovy simply reuses the entire java class library set.
One other major innovation is the hierarchical syntax using closures that makes it superior to everything else for processing markup like HTML and XML. Java was strong on XML to begin with, with groovy it becomes dominant.
The only big problem with groovy now is that it isn't quite ready. I expect that in a year it will begin to be a compelling solution, especially when combined with the lightweight, containers and frameworks (things like Spring and Hibernate) that emphasize Aspect Oriented Programming, Inversion of Control, and heavy use of XML configuration.
I should have been more specific I should have said you can't build EJB beans with groovy. I would love be wrong though.
"Among python, perl, and PHP, only python has superior language syntax to Java"
Here is an example from the apache merlin web site
"ReferenceDescriptor reference =
new ReferenceDescriptor( Widget.class.getName() );
ComponentModel model = (ComponentModel) m_model.getModel( reference );
model.commission();
Widget widget = (Widget) model.resolve();"
Notice how you have to type everything three times. Just reading that makes me angry.
evil is as evil does
What happens to your object database if you have to add "fields" to some of the objects, and dumping the data, modifying the object structures, and re-importing the data aren't really feasible options?
Hmm...
SOAP and CORBA are data transport protocols. What would stop you from writing a product in python to handle these formats? Message queues are a physical implementation of those protocols. Again, you can implement your own queues in python (or any other language for that matter) This can be handled external to the Zope framework and passed into Zope via external methods.
I'm not sure what you are referring to here. You can index and associate all sorts of meta-data with your zope objects - thereby relating the objects - is that what you were referring to? Additionally, Zope has a unique ability to acquire and use objects and permissions from folders above the current locale - so you could write a general purpose form that displays the contents of a directory for example, and apply it to multiple folders below without having to rewrite code.
Zope's ZODB (object database) does support transactions/rollback. Zope also has relational database plugins that allow you to communicate with all sorts of databases (oracle, sybase, mysql etc) - so if the database supports transactions - Zope should be able to make the database perform that function.
You can write an external method to handle this, if needed, using jython. However, why bother with RMI when you can use sockets or python's Expect module? The benefit of these is not having to load anything special on the other end (I assume you would need Java on both ends of the RMI transaction).
You could write an external method in python to write logs to a standard file - and call it from your applications.
How about cron itself on a *nix system (you don't have to run ZOPE from Windoze - and I wouldn't recommend it anyway)? You can use cron to do certain administrative tasks for the overall system (such as packing the database). You could also write infrastructure pieces using python (or any other language for that matter) and have those modules run in cron (for example, an app to rotate your logs in the previous example).
There is a python-ldap package available via sourceforge.net - you can use this and an X.500 (LDAP) directory to manage your names. You would use an external method (python) to manage input/querying the directory.
I will agree that the documentation for Zope 2.X is not optimal (but there is certainly a lot of it - the Zopebook 2.6 version is 495 pages long). I am hoping the Zope X3 will have better documentation (several books on the subject can be preordered for a December or January delivery). X3 will serve as a testbed for new development paradigms, as well as bringing development tools in-line with some of the issues developers have complained about.
The important aspect that you are missing is you can extend Zope via products and external python/other applications to get most, if not all of the functionality you mention here. If you really want to dig into the code, you can even modify the framework itself - since it is open source. Can you modify other frameworks in a similar fashion, or are you limited to what the vendor has p
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain