Scripting the enterprise

In the beginning …

… PHP was designed as scripting language used to develop Web based applications. Because of its flexibility, extensibility and ease of use it became widely popular among developers, and pretty fast the large community was created. As time was passing, people wanted to develop more complex applications with it, but PHP was designed for page centric architecture with very limited support for object-oriented programming. Also, there was no system support for transactions, caching, software components and all the other things that developers of the enterprise applications have used to have. There was no application container that would take care of all the system staff that we need in our applications, so that we can focus on business requirements. As applications are getting larger and more complex scalability becomes a new issue. PHP does not scale well and there is no easy and standard way to make a cluster to achieve better scalability. So, PHP applications (with respectable exceptions) were left in the area of small and middle complex web applications.

Meanwhile …

… Sun’s Java has a totally different story. Originally designed as a language for client applications that would be platform independent, because of a good language concept, many people saw tremendous possibilities that Java could be used for. One of the directions was middleware section and Java on the server side of the story. J2EE platform specification was shipped with all the things that developers needed for enterprise projects. Also, Sun released Servlet API and JSP specifications for development of the web based applications. And this combination was proved to be a real hit in enterprise development domain. But developers didn’t have all the freedom that the PHP (and other script language) developers had and the web development in Java was very time consuming. Many MVC frameworks like Struts and template engines such as Velocity were created but again the problem remained.

Immediate solutions

There are few ways that the developers could use to bridge the two worlds. PHP has a mechanism to integrate into Java servlet container environment using SAPI module and also Java VM could be exposed to the PHP applications, but this wasn’t reliable enough to put mission critical tasks to this functionality. There is no support and no accurate documentation and the first sentence of PHP manual for Java integration describes it well: “This extension is EXPERIMENTAL. Use this extension at your own risk.”. Another way to do it was using Web services and XML-RPC protocol to make this bridge. This works great in some applications but its not natural integration and performance issues of the protocol makes this solution unacceptable in many cases.

The meeting point

As time was passing, people from Sun and Zend became more aware of this situation and they realized that they can make things better. So, PHP 5 will define PHP as more seriously object-oriented language and make it closer to the Java world. At the same time at Sun, JSR 223 was proposed by JCP (with Sun Microsystems Inc., Macromedia Inc., Oracle and Zend Technologies in the expert group) trying to make a standard way for integration scripting web languages in Java platform (using the PHP as reference implementation for scripting language). The specification will describe how to write portable Java classes that could be accessed from scripts, and once you’re in Java world all the doors are opened. Also, specification will define how to package scripts (PHP files in our example) into Java application WAR or EAR files.

Future improvements

As Erik Hatcher said in his weblog, it would be much better if the specification had not focus this bridging only in the web context, but also let Java developers to use the beauty of PHP in whole Java environment for tasks that are, at the moment, very painful to do (such as sending templated emails). Also, it would be nice if we had the flexibility of PHP on the server side in some cases. I know that many will argue about this but in some cases business rules are not so fixed and well defined as we would like them to be, and flexibility of scripting with the power of the Java application servers would be a real step forward. You can find more on this discussion in Bill Venners article and interviews with Java creator James Gosling and Python creator Guido van Rossum. But, one step at the time, I hope that this is only the beginning of the new concept of development.

Waiting for the day …

The draft specification is roughly planed to be done in a year, so in the mean time there’re lot of things that can be done in order to be ready for it. The point is to make a good MVC architecture for our projects, so that every change in one of our layers doesn’t disturb the whole project. So, if you are PHP developer and your project is getting larger and larger every day, and the scalability is your main issue, try to force MVC so that you can leave someday all the backend tasks to the application container (or in better case the cluster of containers). And if you are the Java developer, advice is the same; soon you’ll be able to do your presentation tier in a language like PHP much, much faster than it is now possible. As developers, we must stick to the saying “the best tool for the job” and this move will definitely get the best of the two worlds.