The Official Blog of JimmyJames
Sunday, May 09, 2004
Thursday, April 29, 2004
Enterprise PHP?
PHP is no doubt a great web programming platform. It is simple and fairly robust. About 90% of the time I want to find an open source web app for something, there are at least 5 written in php. It seems to have become the de-facto standard for simple web apps.
Currently I spend most of my time writing php because the contract I am currently on started with php as their web platform. I have written some pretty cool apps in php. With my most recent app I built a simple persistence framework in php. My background is Java and there are many great frameworks in Java for doing just about everything; from persistence to ui layout. Java definitely seems to have more frameworks that actual apps. That's interesting and a topic for another day.
Anyways, can PHP really scale to an enterprise level? I discovered something very interesting recently which leads me to answer that question: "Not right now". What I discovered kind-of shocked me. Perhaps I am just not searching Google for the right thing, but it seems to me that php has no mechanism for putting stuff into a global space where all threads / requests can access it. For example when I was writing my little php persistence framework I thought it would be cool to have a connection pool instead of having each request make a new db connection. Well... after searching, playing, programming, etc. for hours, it seems that there isn't a way to do it. Ouch... So there is no way I can have like a true Singleton in php. Now that's a big bummer because it means that things that get done over and over by many different requests can not really be pooled.
Ok, so for me that totally rules out php as an enterprise level solution. At least in Java if you are solely using Tomcat, your servlet can maintain a connection pool or similar services for you. If you are using JBoss you get that, JCA, Session Beans, etc... Lots of options for that kind of thing. So maybe I am just being dumb and there really is some way to do it. If that's the case, please someone set me straight.
My next project will be to research having php connect to session beans so that I could use php for the web tier and java for the business tier. Sounds like fun...
Friday, October 10, 2003
The JCP And Java Standards
My partner Mike came across an interesting wiki on Struts/JSF by Craig McClanahan himself...
Struts - More About JSF
It's an interesting wiki post...
One comment I found interesting is:
Every technology goes through a lifecycle of innovation, followed by popularization, followed (often, but quite often in the Java world) by standardization, followed by commoditization.
As always, there are two sides. And since I am the rebelous one, I'll post the other:
Howard Lewis Ship's View on JSF
One very interesting comment that Howard made was
the JSR concept is fundamentally flawed; you don't innovate by committee
JSF was innovated by a committe. Sure you will say that Struts is the predecesor to JSF, so JSF wasn't really innovated by a committe. And I say, why can't the JCP build JSR's out of existing, proven technologies, instead of taking a bunch of ideas which as a whole have never been proved, and creating JSR's from those ideas? There are a number of places where great ideas turned to JSR's, then to implementations, then to standards, then to crap. All because the the ideas were never proven to work in the real world. So then the minds get back together and try something else. Why does the JCP function like this? Why do they continually think that they can think of a better solution than one that has already been proved? Why does the JCP always have to think of a new and better solution instead of just standardizing an existing one?
I think the JCP would function better if Craig's statement was actually true... That the standardization was made around a proven, popular solution to a problem. I would love it if Struts, Hibernate, Log4j, etc became the standards rather than ideas based on those technologies becoming the standards. Maybe the JCP needs an incubator. A place where ideas can be tried before they become standards. And the ones that actually become popular move out of the incubator into JSR's. Kinda like Jakarta's Incubator. Maybe this begs the question; Are JSR's standards or a way to incubate an idea? If the former, then the JCP needs an incubator. If the later, then the JCP needs a way to move the JSR's that get popular and survive to a "Standard". And there should be one "Standard" solution for a given problem set. This would mean that both CMP and JDO cannot be standards. I think this would greatly help Java's popularity since there are so many "Standards" for a given problem, no one knows which "Standard" to choose. MicroSoft makes this much easier. "Use us and you will always know what the Standard is." Very simple. I guarantee you that Java would be more popluar if user's didn't have to evaluate which persistence, logging, presentation, management, xml, etc, etc framework to use. Am I saying there shouldn't be options? Not at all. There will always be more than 1 way to solve a problem. But the community should decide (based on simple majority) what the 1 standard solution to a given problem is. And that standard should be the most proven and most popular one. And the JCP should say, "The standards are x, y, and z". And when technology w becomes more popular and more proven then x, the standard changes.
