Although PHP boasts of being the most widely used environment for web application development, it has been traditionally considered as not suitable for the enterprise. InfoQ has conducted a virtual panel regarding the evolution of the language/platform and its suitability in enterprise environments.
Taking part in this virtual panel are:
- Zeev Suraski, Co-founder of Zend Technologies which oversees PHP advances,
- Rob Nicholson, Senior Technical Staff Member, Programming Language Runtimes for IBM,
- Derick Rethans, Member of the PHP development team and project leader for eZ components
InfoQ: One of the key elements of enterprise software is interoperability that allows for the exchange of information with other platforms. It is commonly believed that PHP lacks in this area since its WS-* support is relatively new and lacks in features and maturity. What are your thoughts on that? Do you think it is going to change?
Zeev: I think there's much more to interoperability than WS-* - in fact, we're seeing less demand for SOAP based web services and growing demand for other standards - mainly due to the complexity of deploying SOAP. PHP is extremely interoperable, and provides a wide variety of interfaces (REST, excellent XML support, SOAP, ZF components for web services & more). That said - PHP does have very good basic SOAP support ever since 2004, and extensive support for WS-* through the Axis2 extension ever since 2006. I can only say that I've never received complaints from users about lack of interoperability features - if any - quite the contrary.
Rob: I think what we are seeing is somewhat of a meeting of the minds on this. PHP has its roots in simplicity. It's a language to "solve the web problem" without adding unnecessary complexity so PHP programmers typically opt for REST over SOAP if there is a choice. Traditional enterprise software is moving to meet PHP in the middle. For example, many of IBM's enterprise grade software products were enhanced last year with support for RESTful interactions including Atom Publishing Protocol so now there is more of a choice. Use WS-* where it is called for and use REST when simplicity and speed of development are critical. Interestingly we are also seeing PHP used to directly enhance enterprise connectivity. IBM's Message Broker which is used as a software "universal adapter" to connect anything to anything now supports a PHP compute node in its message transformation flows. So now you can use the PHP language's simple but powerful syntax and idioms deep inside enterprise software. We recently released a SupportPac for IBMs CICS Transaction Processor on to support the PHP language. CICS is as "enterprise" as software gets. It runs on mainframes and is used by the organisations such as banks, governments and heathcare providers to process some of the most important transactions that may affect your daily life. I expect to see the opportunities for PHP interaction with traditional enterprise software continue to strengthen in the future.
Derick: I don't see many problems here. PHP has support for all the WS technologies such as SOAP, XML-RPC and JSON.
InfoQ: The last few years there has been a trend for porting scripting languages to the JVM in order to take advantage of its rich features for monitoring, security, etc. This is not new for PHP deployments and there are several real world PHP application that run in the JVM. There have even been many claims about increased performance by vendors. What do you think about this trend?
Zeev: We've seen similar trends with .NET, but they never quite took off in comparison to the original implementation. I believe the same will hold true for PHP on the JVM. We actually see performance advantages to our native implementation - especially around memory requirements, and real-world long-term performance as opposed to synthetic benchmarks. However - the biggest advantage to the standard implementation is its tremendous community support (both in code contributions and usage) - a thing the other implementations lack.
Rob: Its all very exciting and it bodes well for the future. Of the many thousands of languages that have been implemented just a few have survived through a process of natural selection because they are particularly fit for purpose. It is natural that developers should innovate around the implementations of the languages. If we look at the Ruby community there we see at least half a dozen implementations contributing to the success of that language, sharing tests, performance tweaks, contributing clarity to the language specification and competing with each other for the title of "fastest Ruby" I think we are beginning to see the same happening around PHP . We are already seeing some great benefits from the collaboration between the implementations of PHP such as the huge number of new testcases that the community has generated over the last 2 years and efforts to improve some of the APIs and I see this increasing in the future. I work on a JVM implementation of PHP which is used in IBM's ProjectZero incubator and in its WebSphere sMash product, together with the CICS PHP SupportPac and MessageBroker compute node I mentioned. We think that for some kinds of problem, running PHP on a JVM makes a lot of sense. We're seeing our partners and customers use it where they want tight integration with their existing Java based systems, where they wish to re-use existing Java libraries and APIs with the simplicity and ease of use that PHP brings.
Derick: Although performance *could* be better, there are still issues around scalability. The whole idea of PHP is the shared-nothing architecture for easy scalability. Making PHP run on a JVM moves PHP from this shared-nothing architecture. There is unfortunately only one PHP-on-JVM project that is working together with the PHP community as much as they can by contributing tests.
InfoQ: The upgrade from PHP 4 to version 5 far from an easy transition. What do you have to say to companies that are skeptic about their PHP investment with respect to the upcoming release of PHP 6?
Zeev: I would actually challenge the assertion that the 4 -> 5 migration was a very difficult transition. There wasn't a lot of compatibility breakage, and fixing apps was a relatively easy task. Actually taking advantage of new features was obviously more work - but that's expected.
With 6 we are indeed more concerned about compatibility breakage - which presently is more substantial than the one in 5. That is why we're taking our time to get it right.
Rob: I think PHP 5 will be around for a very long time to come. The upcoming 5.3 release has been designed to be a painless upgrade as possible and adds almost all of the features that were slated to be in PHP 6.0 leaving only the removal of some deprecated features and unicode in PHP 6.0. I am very keen to see the unicode version of PHP, not least because it makes compatibility for a JVM based PHP much more straightforward since the JVM natively represents strings in unicode but I suspect the adoption will be slow with PHP5 and PHP6 continuing in parallel for many years.
Derick: People will always be sceptic, but we're trying to minimize issues to move to PHP 6 by introducing forwards-compatible features. It also helps if people could already test on the current development releases to see which issues they run into, and provide this feedback so we can make the transition process easier.
InfoQ: In all established languages there are people in the community that push for the addition of more advanced features. On the other hand PHP has always been considered a language with few features that was easy to learn. Do you think this should change?
Zeev: I absolutely think it should not change. That was a key success factor for PHP. We have a saying in Hebrew which roughly translates to 'the more you add the more you take away' - and I firmly believe it holds true for PHP - at least as far as the language constructs & syntax are concerned. PHP can be extended indefinitely using extensions and frameworks - and these are the right and most interesting 'final frontier' for PHP, in my opinion.
I think the sheer amount of large, complex websites (Facebook, Yahoo, Flickr) based on PHP, sheer amount of complex off-the-shelf apps (SugarCRM, OpenPro, CMS's) based on PHP and enterprises relying on PHP for either their corporate websites or their internal systems - is a testament to the fact that PHP's feature set is mature and that we should continue in the same direction.
Rob: When we set about choosing scripting languages for IBM's scripting product WebSphere sMash we chose PHP specifically because it had such broad adoption. We wanted to enable the millions of PHP programmers to work more closely with the enterprise and with enterprise software and we wanted to support a language that would allow new programmers to get going really quickly. PHP's strength is its simplicity. That said languages need to evolve if they are not to die. PHP would surely have lost a lot of its appeal if it had not moved to support OO programing in PHP 5. With the 5.3 release PHP gets a number of new features which certainly have the potential to add complexity. I think as much as anything its going to be about how they are used and the idioms that emerge. Given the lag in adoption of new releases, its going to be a few years yet before the most mainstream PHP applications move to use the 5.3 features and during this time I think PHP programmers will generate lots of examples of good use of these features to simplify common programming tasks.
Derick: No, it doesn't need to change, and there is place for both types of developers. Adding new features does not necessarily raise the bar for entry.
InfoQ: PHP as a language has evolved over the years by following the dominant paradigms and going from a simple preprocessor to a powerful OO language. With the emergence of the functional style of programming, do you see features from this paradigm going into some future of PHP?
Zeev: No. PHP still supports procedural development and that's unlikely to ever go away; We added OO support ever since we got start with PHP (in PHP 3), although it did leapfrog in PHP 5. lambda is probably as close to the functional paradigm as we're ever going to get. Especially in light of one of my previous answers - we don't want an everything-and-the-kitchen-sink language, but a lean, simple language that gets the job done.
Rob: This is already happening to some extent. Closures, which are present in PHP 5.3 come from the world of functional programming. The PHP community is a great mixture of "classically trained" Computer Science majors together with hobbyist self trained programmers. It will be interesting to see what this diverse community make of Closures and how the common idioms evolve. What I believe we'll end up with is a set of well accepted patterns and idioms to elegantly solve the common problems of web development which programmers use without a second thought to the fact that they derive from functional programming.
Derick: I am not sure, I don't think it would fit too well. But if it would make sense to PHP's applications, it might make its way into PHP as well. PHP is always excellent at integrating interesting and useful concepts from other languages.
What do you think, is PHP a wise choise for the Enterprise?
