Professional PHP

Sandro Zic PHP in the Enterprise talk which has spawned much blog discussion. John Lim triggered the discussion by pointing out a slide in sandro’s talk that suggested that PHP is not enterprise ready and rebutting some of the points on the slide. Marco Tabini augments the Pro PHP Enterprise position. I’d like to continue this discussion (I’ve written on this before).

What does Enterprise Mean?

I was already thinking about this post on the weekend, when I went to my cousin’s daughter’s birthday party. Unsolicited, he offered several problems with PHP that prevented it from being used at his organization. The first he mentioned was that they use Oracle and using PHP with Oracle required re-compiling PHP. However, using a custom compiled version of PHP disrupted their Red Hat automatic update process. He had no desire to maintain PHP patches across his organization’s 15 and counting servers. The Java version of the Oracle driver were 100% java and thus the Java runtime could be maintained by an automatic patching process. Additionally, he had the impression that PHP required more security patches that Java. Another point that he brought up was that Java has a standard for authentication and that integrating the authentication systems of various PHP applications required modification of the applications themselves.

I think this conversation highlights some issues that Enterprise development is concerned with versus smaller more problem oriented development. In Enterprise development, integration between heterogeneous applications is a big problem, deployment costs are major concerns, and security is important. My own experience confirms this.

In Patterns of Enterprise Application Architecture, Martin Fowler defines the following general characteristics of enterprise applications:

• Persistent data
• a lot of data
• access data concurrently (Transactional)
• a lot of user interface screens
• integrate with other enterprise applications

Fowler says that he can’t give a precise definition of Enterprise application, but he gives some examples of enterprise applications:

Payroll, patient records, shipping tracking, cost analysis, credit scoring, insurance, supply chain, accounting, customer service, and foreign exchange trading.

He also gives some examples of what enterprise applications aren’t:

automobile fuel injection, word processors, elevator controllers, chemical plant controllers, telephone witches, operating systems, compilers, and games.

The definition of Enterprise is elusive. I am tempted to define Enterprise Application as an application crucial to the day to day operation of a business.

Thus, I think the question of whether PHP is Enterprise ready depends on what kind of enterprise you have and what you are doing. For the most part, PHP is a niche language with a web focus. If you are running a web based business, PHP can be enterprise ready.

Integration

The size of the business makes a difference. The larger the business, the more important integration capabilities are going to be. Tthe need and ability to integrate with other applications is one of the more defining characteristics of an enterprise application.

The book Enterprise Integration Patterns begins:

Enterprise integration is the task of making disparate applications work together to produce a unified set of functionality. These applications can be custom developed in house or purchased from third-party vendors. They likely run on multiple computers, which may represent multiple platforms, and may be geographically dispersed. Some of the applications may be run outside of the enterprise by business partners or customers. Other applications might not have been designed with integration in mind and are difficult to chagne. These issues and others like them make application integration complicated.

The book goes on to define four styles of application integration:

• File Transfer
• Shared Database
• Remote Procedure Invocation: CORBA, COM, .NET remoting, Java RMI, SOAP, XML-RPC, web services, etc.
• Messaging: WebSphere MQ Family, BizTalk, TIBCO, JMS, MSMSQ, etc.

Is PHP Enterprise ready? Perhaps the answer depends on the style of application integration favored by the business. Can PHP work with messaging systems? How about support for transaction based systems, such as CICS?

International PHP Magazine promises a future article comparing Enterprise PHP and J2EE. I am looking forward to this article. I wonder where the PHP equivalent of the JMS API and the JTS API and the integration with the tools that provide these services? PHP has only recently achieved some sort of standard unified DB API in PDO. I am not sure that PHP is ready for this type of integration.

I think that JSR 223 defines PHP’s niche role in larger Enterprise systems. The integration heavy lifting is done by Java, while PHP fills a niche in the larger corporate ecosystem as a web presentation tool.

Is PHP Enterprise ready? For some, the answer to this question will be “is JSR 223 enterprise ready?”

I’ll also add one more integration issue. That is integrating the work of multiple developers. PHP needs namespace support. I got in trouble in WACT for using some common class names like Template and View. This shouldn’t matter. As a framework developer, I shouldn’t have to prefix all my class names with WACT_ just because someone else might use the same name. As an application author, I shouldn’t have to worry about namespace conflicts between different third party libraries or frameworks that I might want to use. autoload does not solve this problem.

Regarding integrating authentication systems. I too feel this pain. What is the solution here?

Deployment

At my last job, we estimated that the cost of deploying a feature change in a client/server environment was an order of magnitude larger than the cost of actually developing the feature. Deployment is a big deal.

In talking to my cousin, deployment of a Oracle capable version of PHP was an obstacle against using PHP. He mentioned having to install a development package from Oracle before the PHP could be compiled. (is this right?). Having to compile PHP is a big deal for some people (for every patch? on how many servers?).

Why can’t PHP have a 100% PHP Oracle driver? I think part of the answer to this is performance. Recompiling such a beast on each request would be bad. Not because of the runtime overhead, which would probably be small, but because of the compile time overhead. Standard default generic installed everywhere PHP needs an opcode cache. APC should be a core part of PHP, not a PECL module. There is no reason why this should not be the case.

How many PHP modules and PECL modules really have to be written in C? With a standard opcode cache, some could be implemented in PHP and thus be far more deployable.

Take as a premise that Enterprise means integrating many third party applications and we go pick out a half a dozen top notch PHP application and integrate them. Ask how many php.ini options could we really change and still keep all of the differing PHP applications functioning? PHP needs a more consistent runtime environment with less .ini variability.

If an ISV offers a PHP application for sale, right now they have to make a tough choice. Sell the software with the source code to a larger market and risk unauthorized modification, inspection and distribution, or sell the software strongly encrypted and protected and require the deployment of an extra runtime component and shrink their market. Worse, there is more than one encryption format and they are not compatible. PHP needs the ability to distribute and execute plain old compiled byte code. This is an important middle ground between these two options.

One of the things my cousin mentioned was that deploying the java Oracle driver was as simple as dropping a .jar file into a directory and changing an XML file. PHP needs a built in standard package format. I should be able to do this:

include “/path/package.tgz/path/file.php”

(Only that the .tgz shouldn’t be necessary. I only put it there for illustration purposes.)

Additionally, I should be able to install a multi-file PHP application by simply dropping the file somewhere into the document root. Another example with the same extension caveat:

http://www.mysite.com/application.tgz/path/page.php

Ironically, JSR 223 defines how PHP files can be bundled into a Java package, yet PHP has no packaging mechanism of its own.

It is important to make deployment in PHP as painless as possible. This means a consistent runtime environment and the ability to package multiple files for deployment.

Deployment is an important issue for enterprises, ISVs, and even open source projects. The easier deployment becomes, the farther PHP can spread.

I have said before, that due to network effects and the need to integrate I think PHP has the potential to dominate as a platform for packaged web applications, both commercial and open source.

Security

I won’t talk much about security, but I will talk a little bit about stability. I want to ask what kind of automated test suite PHP has, how can I run it, and what kind of code coverage does it achieve?

Is PHP Enterprise ready? Definitely, depending on what kind of enterprise and what kind of application you have. Is there room for improvement? Definitely.