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."
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?
Could not RTFA ... site is jammed...
But I guess to each his own. Only time will tell which architecture was worth its own salt.
Meanwhile, I do confess that I have more experience with a LAMP stack, which IMHO is easier to install and develop on.
Your Opinion Will Vary
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".
Some muppet posts a blog and immediately hundreds of millions of dollars investment and countless man hours of work on a mature, strongly adopted platform become irrevelevant. This is pure flamebait.
The only thing this indicates to me is that Grid/LAMP is going to struggle to gain acceptance in the enterprise because it proponents are idiots.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Can you use Postgres instead of MySQL in LAMP, without extreme pain?
--
Wiki de Ciencia Ficcion y Fantasia
Java is well suited for middle-ware too. You don't have to install a big heavy duty J2EE server and enterprise level DB server. Tomcat & MySQL does the job just fine for smaller operations.
Take a look at O'Reillys "Better, Faster, Lighter Java"
http://www.oreilly.com/catalog/bfljava/
IMHO Java scales very well, from small prototype projects right up to enterprise level apps. PHP is fine for the smaller stuff but I'd rather poke my eyes out with a white hot needle than develop and enterprise app with it.
"hehe, website" - Homer Simpson
...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.
But with any scripting language, you have to run the application to catch even trivial bugs like misspelled methods and incorrect argument types.
I'm sure scripting languages have their place, but I've NEVER written a large script, without eventually wishing that I'd originally used a strict language. Scripts are great for fast turnaround, but only if you don't mind chasing trivial bugs that a compiler should have caught. I want a language that's tighter than a straightjacket.
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
Slashdotters help me with this;
Allright then...
and there are no free (as in beer) quality servers
Apache Tomcat.
(..and kinky, every one and their mom developed a framework)
Doesn't mean you have to use them all.
I want a decent middle ware, that is cross platform, fast, and well documented, free as in beer (and preferably as in speech also).
That's Java.
Being bitter is drinking poison and hoping someone else will die
LAMP is great for what it does, but MySQL has no place in the enterprise. There's way too much important stuff that it lacks. I'm sure the nice folks who run /. can tell you of their many misadventures with MySQL, if they chose to...
Now if you'll excuse me, I have to go find my asbestos suit.
How am I supposed to fit a pithy, relevant quote into 120 characters?
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 does nobody use it? Fear, uncertainty and doubt. [...] People can't get over the parentheses. The boss won't approve it. Nobody else uses it, so it's hard to get support.
;-)
You know, I think those were all pretty valid reasons.
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.
Ummm, last time I saw that I called it development.
The reason for using an OO language is to get you to work with objects and encapsulation. There's a really good reason to do any large enterprise level application using objects. That is that the app is being designed to last longer than one year. That means that during it's life back-end systems are going to change, customer requirements are going to change, and new requirements are going to be introduced.
If you haven't properly separated out all of the portions of your code then when they come back and say "can you give us these two functions running on PDA's?" you're gonna be SOL.
(I spent a year building a system and they promised to transition one of the back-end systems to a whole new platform by the end of the job. They never succeeded but we developed against the old system and the new so it didn't slow us down one bit. THAT'S why you take the time to do OO work.)
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
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
Your assessment is unfortunately a common one. Class, repeat after me, J2EE does not mean you have to use EJB. The "dozens of frameworks" is a growing problem, caused by picking bad/inappropriate ones and/or weak architectural management.
In my experience, as a developer and as a web user, a simple non-EJB java webapp running a relatively mature framework (or not), on something like Resin is capable of tremendous performance, but I'll state that as opinion to try and avoid baiting some PHP flametard into posting how many views his anime forum can handle.
If you are developing for something that isn't going on a server you run, with a nice simple Java webapp all of a sudden you (or more often someone else) can choose your OS (Windows, Mac, Linux, Solaris, etc), your DB server (MySQL, PostreSQL, Oracle, etc), AND your web server (Apache, IIS, none, etc). Thats something that MSFT and LAMP-heads don't offer (without compromising their acronym) and something that client IT departments will very much appreciate. A "pure" admin (i.e. one who doesn't consider him/herself a developer), HATES being told by some outside developer to patch their systems, or run something they don't know or don't like.
This is not the greatest sig in the world, this is just a tribute.
You can prototype - or simply develop - most things as quick in Java as in any "P" language; the only exception I can think of being a GUI interface, in that respect Tk kicks Swing's butt. Personaly I don't like the Ps much, I prefer the T - as in Tcl - for scripting. That language kicks any Ps ass when it comes to design, though it can't win on available libraries. (which I never missed yet, all the important ones are there if you know where to look)
Besides, rapid prototyping is overrated for all but impressing your manager or client. If you need to protoype you clearly do not understand the problem at hand and if you do prototype for the above given reason, you manager will make you use the prototype as base for production development. This means you spend the same amount of time as if you'd started properly straight away (and told him/her and their required demos to get lost for a few weeks) but end up with an inferior product because you are contantly hacking around the shortcuts you took to make that rapid prototype.
The two are just very different beasts and there is a clear case when a proper OO language with clear contracts and inheritence is the best tool for the job. Unfortunately, web apps aren't the best example of such a case and that makes this comparison flawed, not the language in question itself!
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
Personally I think you're wrong. J2EE is great if you need the features it supports: JMS, distributed transactions, database connection pooling, jsp/servlets etc etc.
Now if you'd said "EJB", which is only a part of J2EE: and by far its worst part, then I'd have agreed with you. EJB is the epitome of what happens when something is designed by committee.
Bad analogies are like waxing a monkey with a rainbow.
Tomcat is great, but it's not a complete J2EE application server, only a servlet container. You still need JBoss (or one of it's commercial counterparts) for EJBs and the like.
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
> be amazed how much you can achieve if you don't tie yourself to the EJB dead horse.
EJBs do have their place. They are good for distibuting your objects across servers when the data processing is so costly that it outweighs the cost of remote invocation.
The problem with EJBs is that everyone tried to use them for everything, and later realised that they were using an expensive (processing wise) hammer to crack a nut.
JMS and MDBs also shouldn't be ignored...they too have their place.
To claim that EJBs are a p-o-s is to ignore the applications where they do work...
Apache
Mason:HTML
Postgresql
That's how I like my fire. Much more capable than MySQL or PHP.
So who do people compare LAMP to J2EE? Because they are both application development approaches that are crawling with cheap plentiful labor. Any dweeb can set up LAMP with a minimal understanding of reliability, security, or fundamental concepts. Please do not construe this as a statement that all LAMP developers are dweebs. But the entry barrier is low.
Similarly the entry barrier to J2EE can be artificially low because all you need is a certificate to wave around and some PHB will hire you. My work has hired a series of J2EE developer contract houses and they are without question the dumbest bunch of assholes I've ever worked with in my life. They are fundamentally clueless on how to write good code, but they are just so cheap!
The entry barrier to Mason and Postgresql are much higher. Not because they suck, but because of what they can do and what they can't do. Once you get started it's pretty amazing what you can do.
It's the higher entry barrier that helps insure that the developers you do get are better qualified in terms of fundamentals, security, and reliability.
Oh yeah, PHP and J2EE are different beasts. You would be better off comparing J2EE and mod_perl variants for a more similar architecture.
The "light" part of the application is the user interface. That should always be as light as possible.
The "heavy" part of the application is what does all of the back-end work. Database manipulation, messaging, legacy-system communication and integration, calculations, life cycle management, etc.
The fact is that customers hardly ever know what they want when you start developing. Development is a continuous feedback cycle where you show some, get new requirements, and show some more.
So, maybe you save a week or two of development time using one of the P's instead of good OO design and Java. What happens when they come back a month later and say can you hook in system X to this? What happens when the small system unexpectedly takes off and they need to add in 150+ more concurrent users?
Strong design should not be looked at as an extra expense. Strong design should be looked at as future proofing.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
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.
"LAMP" is marketing-speak and not a platform, and anyone posting to /. should know better. What are they really talking about?
Linux (well, you could just as easily use BSD)
Apache (well you could use another free webserver or an appserver like Zope)
Mysql (well you could use Postgres)
Php/Perl/Python (well PHP is just plain awful and there are other alternatives anyway).
Firstly, mysql may be fine for small applications, but is pretty rotten as databases go. When I have used it in the past it really begins to suffer from lock starvation as you scale to more and more read and write contention. As free databases go, postgres has been superior in my experience.
Really what people mean when they talk about "Lamp" is "open source n-tier architecture" or "open-source middleware with a database".
Lisp needs an application server like Zope. Zope has driven many to learn Python so they can create Zope products.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Or why not insert tags instead? Ok, so it's not valid in later dialects of (X)HTML, but since when has slashdot's code validated as anything?
Seriously - <WBR> tags either don't render at all, or render as "\n" (if a long string needs to be broken at that point). I've never understood why slashdot uses spaces (which muck up URLs), instead of <WBR>s (which generally don't).
Anyone?
Everything in moderation, including moderation itself
The main advantage of EJB as I see it is declarative security on a per method basis ...
Yes, and when your security needs are more complex than the simplistic EJB model, you have to either use no declarative security (and write your own) or to apply ugly hacks around the deficiencies...
Lots of flames here, but through the burning embers I just want to point out that using Hibernate and Spring is not supposed to be an excuse to use XML - it just so happens that XML is the glue that these packages use to do their work. I personally could care less if it were a binary format or a CSV file. Love it or hate it, .net uses a lot of XML metadata as well. Arguably in the Java community, XML probably gets a worse wrap simply because it doesn't have the tools that .net does to obsfucate the XML glue from the developer as they desire. XDoclet and AOP is a step in the right direction. I can definitely empathize with your complaints about XML from a Java background. But I think when looking at Spring, Hibernate, Struts, or any Java tool that uses XML metadata for configuration/persistence of application state - that unless you are looking to do some serious hacking of the package that would require that you denature the glue it uses, blissful ignorance is probably beneficial. The aforementioned packages work as advertised by their development teams - even if they do use XML.
Just like you don't use Oracle to handle a simple little db holding some responses to a recent questionnaire or for a quick little conference, I would not use MySQL for a big data warehouse or SAP deployment. Silly db admins have gotten it into their head that DBs at all levels should be compared equally. That is simply not true. Use what's appropriate where it's appropriate. Don't use C for a quick data analysis tool (try Excel first), and don't develop full enterprise apps using cobbled together MS-Office solutions.
...tizzyd
And these are bad things?
I do agree with you, however, that PERL (the only P language I have experience with) is great for quick applications. But there is no way on G-d's Earth I would use it for enterprise (50 000+ LoC) worthy applications. I'll stick with Java.
But that's just my opinion...
--- "We've always been at war with Eastasia."
While Oracle does seem to be the most powerful database out there, I see no reason for it to be near as complicated as it is. My theory is that Oracle is trying to mainting the artificically high salaries of Oracle DBA's. (Don't get me wrong, a decent Oracle DBA earns every penny he's paid, but why should they even be necessary?)
If I don't put anything here, will anyone recognize me anymore?
What I don't understand is the love for MySQL when there is a better alternative available which is just as free and just as easy to use. PostgreSQL is a joy to use, and it actually does what one would expect with regards to referential integrity &c.