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 [1]:

“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

[1] http://www.prevayler.org/

Reto pointed me to the Jena Semantic Web Toolkit [1] which has some RDF-specific APIs and query language implemented. Jena is part of HP Labs Semantic Web Research [2].

via Reto Bachmann-Gmuer, private email

[1] http://www.hpl.hp.com/semweb/jena.htm
[2] http://www.hpl.hp.com/semweb/index.htm

The Java Specification Request 170 [1], 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 [2]?

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.” [3]

[1] http://www.jcp.org/en/jsr/detail?id=170&showPrint
[2] http://blog.bitflux.ch/p625.html
[3] http://www.serverworldmagazine.com/monthly/2003/01/java.shtml