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."
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.
What the hell do you base that peice of tripe on? Why lets compare an incomplete system cobled together on top of PHP to a mature Java based solution which is currently being used in hundreds of thousands of enterprise sites daily throughout the world. Yeah, I can see how LAMP just kicks J2EE's ass on that one.
Seriously, overhype much?
Not provocative at all that. No. Not in the slightest.
I'm sure the flamewar that no doubt follows is merely a figment of our collective imaginations.
ooooooh! What does this button do? - DeeDee, Dexters Lab.
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."
Thats like me saying, "Not to offend you, but check out goatse.cx!"
ITS JUST NOT POSSIBLE TO HAVE IT BOTH WAYS!
time is a perception of a being's consciousness
time is your 6th sense, the wierd ones are 7+
Slashdot tends to put spurious spaces in long URLs making them useless. Please enclose them with the URL tag (note under the Comment text box, it tells you how to do this - just
w w.looselycoupled.com/blog/lc00aa00074.html+lc00aa0 0074.html&hl=en
Example:
http://66.102.9.104/search?q=cache:AXRoWhcH5UIJ:w
Oolite: Elite-like game. For Mac, Linux and Windows
So you are basically saying: Throw more hardware at an inherently slow platform (LAMP) than to use highly optimized J2EE-servers with s state-of-the-art hotspot compiler?
Seriously, is the flame war the new source if income? I mean, it sure increases the number of banner views. Let's report on a new emacs-version, citing it as "far less potent than the newer VI. also notepad K1CK$ aSS".
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.
...but doesn't it seem a little silly to base computational applications on what is essentially a glorified webserver? Sure, use LAMP for your shopping cart, but enterprise applications are more than just shopping carts.
.NET applications were never designed with grids in mind" - well, I can't speak for .NET, but J2EE is designed for clustering and distribution. Have you seen EJBs? EJBs are designed for interaction across computers.
"There is no impedance mismatch, everything talks SOAP/HTTP" - well, yes, that's great, but you shouldn't be talking SOAP/HTTP internally. There are faster means of communication, so use them.
"Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text" - only on input and output. In intermediary stages, you should be using a much more efficient format. If you're doing something clever, it's going to involve much more than just plain old text.
"J2EE and
RTFA and you'll see that LAMP is being pushed for "text-pumping". Why aren't they saying it's any good for anything else? Because it most likely isn't.
Like car accidents, most hardware problems are due to driver error.
Ok, I had already spent a modpoint in this topic, but I realized it is better to speak up to defend your position than to stand on the sides and give out points to "your" team.
Article is Slashdotted, so I can't comment on the content, but just to reply to some of the posts that will defenitely come up, because they ALWAYS come up when Java is discussed-
EJB are bloated etc:
J2EE is does NOT equal Enterprise Javabeans. J2EE contains classes for lots of things. XML processing, messages, web servers, database connectivity, etc. You don't have to use EJB. Lots of Java developers don't like EJB because they are too cumbersome, and there are plenty of alternatives. Check out for instance O'Reillys recent book Better, Faster, Lighter Java.
Java is slow:
Startup time for the JVM is still slow yes. This rarely matters for a web/application server. When it comes to running, it is plenty enough.
It isn't open source:
So what. It's close enough.
Ok, that over with, was this darn topic necessary? I like both LAMP and Java. They have their uses, why did the poster and the article have to turn this into a confrontation?
Being bitter is drinking poison and hoping someone else will die
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.
Substitute Postgres or whatever to taste, but that just fucks up a perfectly good acronym, so we'll pretend MySQL is a placeholder for $REAL_DATABASE of your choice.
Opportunity knocks. Karma hunts you down.
Why "of course"?
Am I alone in wondering exactly what a "next-generation application" is anyway?
What qualities or requirements define a "next-generation application", other than it not having been developed yet?
Anyhow, it was my take on the article that the use of 'P' languages was incidental, it was the grid concept and the horizontal scaling. The 'P' languages just happen to be part of a readily available set of tools for implementing this idea.
"Not to start a flamewar, but you java developpers are a foul smelling, foul tasting bunch!"
I didn't even know there was a PHP and Java flamewar going on! Where do I enlist?
No seriously, it is like comparing apples and oranges. PHP and the wonderous LAMP stack (I have just heard about it, so that is the first stumbling block for its adoption! many companies like to be fast followers) might be able to do what Java does if you look at output, it might even be quick, but that has nothing to do with the costs and development and staffing that real people with real money care about.
Java has a huge demand in industry that is being met with huge interest in terms of capable candidates which is proven by the number of successful and *bearing in mind this isn't a flamewar!* well written open source project out there.
The level of Java competency in the industry is growing enormously as a result, which is a good thing. PHP is also good, and I like PHP, lets not get things mixed up here.
[snip = list of reasons why people choose java, which was boring even me]
Also J2EE is *the* platform for applications running for thousands of users, on machines with 90+ GB of ram, and 24 processors just to handle the data requirements.
Oracle love J2EE. Oracle is a fairly decent enterprise (not just performance, but support and board level confidence) db to say the least.
Now, LAMP might be lovely, but why even pitch it against anything, dear LAMP community, just be, don't try and compare it against anything.
FUD et al.
PS: erm, nerr nerr? u sux0r? pwned? I am loosing my touch at this internet name calling gaff, time to retire.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
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!
J2EE is not about the OS, server or database. It's a specification. JBoss (JBass.. heh), Geronimo, Welogic and many others are implementations of it. Some are certified, some are not, like Resin.
You can run it on many os's, including linux. Apache is making one of the J2EE servers. I'm not sure where databases came into all of this, since it's fairly independent. I.e. w/ jboss, there are data mappings for all of these servers, if you decide to use EJB, which is part of the spec, but not a requirement to use. The last thing is the big ol' P.
J2EE is a set of technology specs. Things like XML manipulations (JAXB, JAXM), communication "stuff", like SOAP, JMS and JMX, database abstractions, like EJB using JDO, CMP, BMP.. "web stuff", though you can do your own protocols, with the servlet spec. Last I checked, the closes to a spec I've seen is p5ee, which had an interesting run. You had options of what to use, maybe too many, in p5ee, but that was about it. It would have been nice to see a tight binding between everything.
Anyway.. the LAM in LAMP is irrelivant in this article. I can use Linux, Apache and MySQL with J2EE if I so desired.
-
ping -f 255.255.255.255 # if only
Grid Application Server based on the LAMP
So does that make it a GAS LAMP?
*ta dit boom*
So let's look at the requirements for today's corporate applications ... Given these requirements, Java does not fare very well. Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text. It should be very well suited for specifying control flow. And it should be a thin veneer over the operating system.
So we came from string programming roots, we developed OOP and AOP, and now... now we go back to string programming because of xml parsing?
I find this a worrying trend, you have to understand, an application is state, and behaviour.
This is trying to tie an application into a 'thin veneer' over an operating system, which seems a bit worrying for an app that will cost a few million to develop in the right circles.
Be reducing all the benefits of OOP (huge and varied, numerous and wonderful) we seek to define our crowining enterprise applications with an approach from the 70's that would pioneer the use of string processing programming constructs over highly developed and structured powerful programming tools.
The program isn't the code, it isn't the data, it is the design, the behaviour, the organisation, the people understanding it. All of this becomes very alien to us when we go this route.
Humanising code is key to developing the kind of applications this company has now touted.
What is looselycoupled? Anyone read it regularly? is it a valid news source? Is this some free advertising for a fad?
I am almost tempted to read more about the LAMP, but I just have a knowing feeling it will be another 'cure all' product.
Yep, tick tick, oops, missed one, back to step 1.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
ah, the eternal dynamic/productive/high-level/slow vs static/unproductive/low-level/fast debacle.
Nice to see the Lisp vs C flame still going strong these days... :)
Nice to see too both have many intelectual descendents which are very good on their own.
And finally, nice to see that both sides of the same coin have seen such widespread adoption to this day, proof that more than one way of thinking is a good thing.
I don't feel like it...
J2EE is overengineered for everything, and darn too complex to learn.
;)
It took me one week as part of a work placement in a summer holiday to learn all about EJBs. Either it can't be that hard, or I'm a genius.
Oh, and I think it's a little contradictory to argue this line, then argue along the lines of just doing some no-brainer form-filling with the application server.
J2EE is about more than just shopping carts, and thus it WILL take longer to learn than a system that's suited to running an online shopping cart.
Java AS suck RAM big time (and CPU too). BEA advises customers to use open-source technology (Apache) to server static content, cuz' it would kill the server.
That's because application servers are not web servers. Sledgehammer and nut spring to mind.
PHP actually is running the internet far more than java has ever been
See above. Java is about running applications that just so happen to have a web front-end. PHP is about hosting websites that just so happen to have some application logic behind them.
J2EE only has it place in big enterprises that are willing to get it becuase the big bucks it costs come with some big name company that offers support.
"the big bucks it costs" - *COUGH*
even in enterprise contexts, the largest part of the majority of apps is pretty stupid form entry and validation
If that's the case, you don't need a big server cluster to manage it...
Like car accidents, most hardware problems are due to driver error.
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.