I just found that my article entitled PHP 5 Enterprise Edition is now available online. It has initally been published in the
International PHP Magazine.
From the introduction:
Today, J2EE could be named the de facto industry standard for the development of distributed multi-tier architecture applications. It is backed up by industry leaders like Sun, Oracle, BEA, and IBM. This article will compare PHP’s software stack with what’s available in (and for) J2EE, to overcome the typical Java versus PHP discussions that usually focus on language features, but do not take into account the overall picture. Basically, this article assembles a PHP5 Enterprise Edition (PHP5EE).
Although this article is almost 3 years old, it is still very interesting to read. Especially when reading the following sentence or projection in the article’s summary:
In no way should this article be a dispraise of all the good volunteer work that happens in the PHP community, but it definitely needs more successful companies in the PHP market who continuously climb up the ladder and extend the PHP software stack.
Considering that since the article has been published, two companies (eZ systems and Zend) have started to create their own libraries aka frameworks to extend the PHP software stack (eZ components and Zend Framework), I would say that PHP is on the right way and that my article was quite influential 🙂
Yes, Sebastian is right, it would be great to have something like Apache Maven. It was really impressive to see how useful it is for rapid prototyping in Java at a related OSCOM session some weeks ago.
But I would not say “let’s clone Maven and port it to PHP 5” – that would not take into account PEAR, especially it’s installer, which is like the little sister of Maven, seen from a conceptual perspective. Just like the PEAR installer’s online repository, the
maven CLI allows to donwload Java packages from an ibiblio package repository. The definitive plus of Maven is that it is not library-centric, but application-focused: It also creates a default application directory structure and performs pre- and post-installation processes based on a plugin interface.
This is something which is missing in the PEAR installer, I would even go so far that something like the Jakarta project in total is mssing for PHP. Maybe it is now a good point to start something like this as an official PHP community effort, given the recent discussons on Enterprise PHP.
One more point about the Maven/PEAR issue: The ZZ/OSS Installer tries to overcome the deficiencies of the PEAR Installer when it comes to applications. Unfortunately, the interest has yet been low and the main problem I see is that PHP developers don’t want to drop the benefits of a scripting language (edit the script -> execute it in the browser -> fix bugs) in favour of a more flexible application design which has a source2built tree installation process. In fact, it seems like a trade-off: either you have a rather monolithic application that allows for quick fixes or your application is modeled with packages that need to be edited in the source and installed to the built tree (as PEAR does). Due to these problems, simply porting Maven would not help PHP application developers – it would need some more thought and education on the source/built tree issue.
What? There’s already a problem with PHP5 although a stable release is not even out yet? Yes, there is – and I am not talking about technical problems, rather about business problems.
Don’t get me wrong: I love PHP and I am very excited about the new features of PHP5. With PHP5, no doubts, PHP is really ready for the enterprise – at least when it comes to PHP as a programming language.
But what about PHP5 in a business environment? I am sceptical on the business success of PHP5 in the enterprise market:
- Java is already there,
- there’s no global player providing professional services for PHP applications development,
- there are too few really good PHP programmers,
- where are those professional (Open Source) PHP tools, frameworks, and applications that minimize the risk of enterprise application development?
I will shed a light on these 4 questions and probably some more in forthcoming postings to my Weblog – and I will also tell you, why I still see a future with PHP5 in the enterprise market.
Jack Herrington is brave: he argues that PHP is at least as scalable as Java, and he does it on O’Reilly’s ONJava Website… His arguments are quite obvious:
Still not convinced? Consider JSR 223, the effort to turn PHP into the front end for J2EE by porting it to Java. If PHP on top of Java is scalable, then why isn’t PHP on top of C?
Some postings have emerged that discuss the implementation of threads in PHP. John recently referred to an article published in the English PHP Magazine and Georg wrote some valuable comments.
Shane did some work on a threads extension available in PECL a couple of months ago. The extension is very experimental.
There’s no plan to incorporate multithreading into PHP5 – if we believe the experts 🙂
I am not sure about how SRM can help with multithreading. At least it provides persistency across requests which allows to emulate a multithreading environment yourself in PHP (left aside if it’s a good idea e.g. to implement priority management of “threads” in PHP itself and not the Zend engine). Comments are welcome.
What’s missing is a threads implementation similar to Java or Ruby, especially with features like:
– set and manage the priority of threads
– define threads as daemons
– allow for synchronized threads (see Ruby’s Mutex Class)
From the Prevayler Web site :
“Prevayler is the most reliable Free Software Prevalence layer we are capable of providing for Java.”
“With Prevalence we are finally free to create true object servers and use objects the way they were intended all along.
We are able to use any algorithm, data-structure and query language we please. We are no longer constrained to the ones provided by database and application servers which must run on disk data-blocks.
We believe the whole OO community is finally free to recover from the atrophy caused by database and application server restraints. We no longer have to distort and maim our object models to satisfy their limitations.
We no longer have DBAs imposing us database layout restrictions. We have freed them to do something more useful.
We have set fire to the table-models on our walls. We have deleted our database creation scripts. We no longer have to keep them updated.
We no longer have to license, install, configure and maintain a database and application server every single time we want to develop, demonstrate or deploy our systems for any of our clients. Give us a Java VM and we are good to go.”
via Reto Bachmann-Gmuer, private email
Reto pointed me to the Jena Semantic Web Toolkit  which has some RDF-specific APIs and query language implemented. Jena is part of HP Labs Semantic Web Research .
via Reto Bachmann-Gmuer, private email
The Java Specification Request 170 , which defines a uniform application programming interface (API) for access to content repositories, might be a way to go for Open Source Content Management interoperability ?
Some analysts say that “June 2003 will see a reshuffling in the content management industry with final adoption of the Java Specification Request 170 (JSR 170) standard” because it addresses the main problem of CMS:
” Web applications such as Web sites, portals, shops or catalogues interact with content. These are held in content repositories, which are generally part of a content management system. The e-business sector has been faced with major challenges, because each CMS manufacturer uses its own repository API. It is not easy to exchange applications (for example, a database conforming to SQL), so integrators are forced to master various APIs, work with different application developers such as portal manufacturers, and adapt their products to a very wide range of APIs. This situation is not satisfactory for customers either – once you’ve decided on a content management system, it’s not easy to change your mind.”