Scriptiing The Enterprise With Java And PHP

jontr writes "There are many benefits of using PHP together with Java. In an article about JSR 223, Dejan Bosanac looks at origin of each language and describes future benefits for PHP and Java developers."

Comments

JSP

[cloudless.net]

If you want to do some quick and dirty job, use PHP. For larger projects, JSP and J2EE make more sense. I don't see any valid reason to mix PHP and Java together at all.

PHP doesn't scale?

[trompete]

I didn't know that PHP didn't scale well. Then again, I just use it for hobby sites.
How does Yahoo! use PHP? Do they generate static HTML snapshots or something?
The article was really short....what will PHP5 do to help scalability?

Re:PHP doesn't scale?

[tangi]

PHP is a very performant and handy language but it misses a shared memomy model which is the most important source of scalability.
The rule #1 of scalability is to avoid doing the same thing twice but rather to store the result where it can be reused (by other threads here).

One may call this a "limited support for object-oriented programming" because it's indeed impossible to implement most of the common OO design patterns in pure PHP but this has in fact very little to do with OOP: shared memory is a system notion and storing intermediate results is what variables exist for! Storing data for later reuse by another thread is not fundamentally different from introducing a variable before a loop to store a constant expression used within this loop instead of recalculating it at each iteration.

You can't do the former in PHP unless you use a RDBMS (not as fast as direct memory access) or... C/C++ extensions which is what Yahoo does (Making the Case for PHP at Yahoo!). Through such extensions, PHP enables the implementation of something similar to a servlet instance member.

But that's much more complicated than in Java, even more if you're trying to implement a generic extension because of type mapping issues between PHP and the extension (C/C++ being stronly typed). Yahoo can of course afford the effort but the result is light-years away from common PHP usage: most of us can't just say they are doing like Yahoo because they also use PHP.

This to say that PHP is a wonderful language. It simply has some drawbacks like all others.

Re:PHP doesn't scale?

[tangi]

More than anything I was curious about server side Java in particular, which you claim is more scalable because it shares memory. I'm interested in hearing some more details about this - why you think it's so and any references to back it up.

Java is not more scalable than PHP by its own because it shares memory. Java enables/simplifies the design of scalable applications, which is not exactely the same. If there is nothing to share, then the execution model doesn't matter. If you can capilize on stuff created once for all, or at least reusable several times, then being able to share memory has a big impact.

"Java-based SEDA Web server outperforms Apache and Flash (sld12)" because of a design aimed at limiting object reinstantiations and context switching. These two pains obviously occur when you do the same things on many concurrent threads: you'd better do it once and share the result.

There is really nothing special with Java and multi-threading about that. The same is true for multi-process Apache C modules programmed to use shared memory.
In fact all four components of the LAMP architecture internally make extensive usage of shared memory (for i in linux apache mysql php; do google "shared memory" $i ; done) simply because cpu cycles and memory allocations are expensive and high performance objectives imply not to waste them. If PHP had a higher level API than its existing one for managing shared memory, web programmers would be able to easily prolong the benefit of using shared memory to the application itself.

I shouldn't end my post with a flamebait but I believe that if a web developer suffers from Java's drawbacks (bytecode/JVM, performance cost of native UTF-16 strings, garbage collection, ...), he's 99% likely to under-use its strengths (great thread API, servlet model, great librairies, ...). Well used, they enable really performant designs. I've seen so many times applications refactored from C to Java performing several times faster, just because it was easy to do things smarter in Java, while very risky in C (Never had a SIGSEGV in a large multi-threaded C application ? Happy debugging and next time you'll keep it stupid!).

Scale is such a broad word...

[quinkin]

I think "scale" is a slightly misleading term.

With regards to caching, server farms, execution speed etc. PHP does indeed "scale" quite reasonably within its limitations.

However, if you are ever involved in building an enterprise level application using PHP alone you will become intimately familiar with its limitations, particularly it's semi-OO implementation (ie. no provision for protected members or private variables).

Compared with the equivalent Java based business logic, the PHP code is a nightmare to maintain. This isn't helped by it's restrictive OO model...

Q.

Avoid when possible

[one9nine]

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.

What freedom and what was making it more time consuming than PHP?

I have to agree with the previous poster that JSP offers the same functionality as all of those nice libraries PHP comes with. I don't see where PHP offered such a significant advantage over JSP that you would choose it over JSP when developing a web client. I have used both JSP and PHP on several project and both worked very well but I wouldn't mix them together unless it was absoultely necessary. If you are starting a new project with Java, I would highly recommmed using JSP instead of PHP. JSP has come along way especially since the advent of JSTL (which I continually praise on Slashdot everytime a Java article is posted ;-) ). Mixing technologies should be done only when absolutely necessary (i.e. integrating C and Perl for necessary performace gains) as it's generally much more difficult to debug and maintain by a group of developers. Although there are alot of developers that are very skilled in more than one language, there are many who are experts in one language and are remedial in a few others.

I am not flaming PHP. Dynamic websites can be constructed quickly and easily and it is a nice language in which to develop. if you have an existing Java codebase and you wish to add a web client, I would strongly recommend using JSP instead.

Re:Pffff... overkill?

[BigGerman]

Java/JSP _does_ have all these libraries and HTML/session integration. With JSPs you have the same:
access to rich Java libraries for text processing, XML, LDAP, images, zip, etc
plus easy way out to the enterprise world with J2EE.
So what is the point?

Re:JSP/PHP Compare and Contrast

[Randolpho]

Here, let me rewrite that for you:

Business Logic Java - Good
PHP - Bad.

Presentation Layer (Web)
Java/JSP - OK
PHP - OK

There, that's more in keeping with what I know of both languages. Now, Java is superior to PHP for business logic, as you picked out, but Java has JSP/Tomcat, which is functionally just as good as PHP, at least according to benchmarks I saw recently.

Now.. given the choice of Java over PHP for your presentation, why would anyone choose PHP when they can get the same results with JSP, but have the added upshot of keeping everything together in the same basic syntactic setup? Java code is easier to create and maintain than PHP code, and it's faster.

There's no real need to use a different system unless you get a benefit from it. You claim the benefit is in using PHP for presentation in web applications. Fine, but I don't see it. Now, if you suggested something along the lines of Zope's Page Templates, I might agree. But if you're at the point of using Zope for your presentation, there's no reason to use a different platform for the logic, as Zope is written in Python, and Python is an outstanding programming language, easily heads and shoulders above Java in every respect except raw number-crunching performance and IDE availabilty. At least, IMO. :)

But the question is Java vs. PHP. In that case, the answer is Java.

A reason for Java

[djweis]

One thing I like about Java compared to PHP is that I never have to recompile my servlet engine to add features. For example, I spend too much time getting pdflib to compile/install itself into php, but adding similar features to java requires dropping a single jar file in the correct directory. Same with imap support or anything else. It gets even better when you develop on your x86 desktop and deploy to a Sun machine or something else. The same jar file works everywhere, instead of figuring out how to compile on two platforms instead of one.
Database independence is already there also, you don't need to choose from 4 wrapper layers like PHP has.

Re:A reason for Java

[dhodell]

Well, you know you can make dynamic libraries and NOT compile them into the core language. Then you drop a .so file into the correct directory. And when you want to use it, you type dl('some_extension.so').

Java has many different DBI possibilities, at least as many as PHP has.

Yes you do have more problems with "portability" but that's expected, I guess. However, I don't know any widely used extensions that don't have binaries available for win32, linux, and bsd. Many even are packaged for Solaris on SPARC.

I won't comment on Java's performance, but you really do need a lot of nice hardware to run Java things well. It has lots of overhead.

Re:I disagree with their characterization of PHP

[nicware]

The "separation of presentation from logic" is often overdone in my opinion.

Allow me to disagree. The lack of separation between presentation and logic and/or data cost a lot of time and money.

Example: Think of a business like a bank of insurance company. A lot of their data structures and logic have been proved to work for decades. The last 15 years, companies like these have gone through a number of presentation changes: from console to console graphics to window managed systems (often a few different flavors/versions) to html and maybe to wap and soon to ... (whatever the next big thing may be). The logic and data structures does not have to be touched just because people wants a new presentation - but only if separation was done properly. I've built systems which generated web-pages, pda-targeted pages and FrameMaker documents (for printed publications) - all from the same data. In such systems, mixing presentation and data/logic is a sure way to introduce problems.

Another example is the misuse of the RAD tools. RAD tools seem to tempt programmers to skip separation. Why? Well, you can just doubleclick on a button to end up in a "onButtonPressed" method where you can write code. This ease of this is of course good, but what is not good is that way too often the programmers seems to stop thinking and actually writes the logic code there instead of the call to the logic code (which is what should be written in such methods). So, what happens when the vendor stops supporting the tool? Or when a new important presentation technique shows up? Rewite the presentation? Yes, if separation was done properly. If not, you can look forward to rewriting it all.

It often results in having to make changes in TWO places instead of one when you add or alter UI elements, and you cannot switch from say desktop-targeted-HTML to PDA in a one-to-one manner anyhow.

Of course one needs to write new presentation code if you want to present your data in new ways. But logic for business rules and all the data and data structures does not have to be touched if the separation exists. That is truly important if stability of the system is of high priority and wasting time/money is of low priority.

Some of us think that OOP is oversold.

Since I became a bit curious about this opinion I visited your website (http://www.geocities.com/tablizer) and found a lot of interesting reading. In some ways I agree with your point altough the discussion seems to be very database-centric. I do agree that if the application layer only builds an OO-version of the data just to put it up and down to a relational database - then nothing is gained. If the applications are very db-centric and does not do much with the data except for presenting it to users and letting them add/edit/remove blocks of data - nothing is gained. That, however, does not make OO any less useful for a wide area of problems. But that is a discussion of its own. OO is a lot about encapsulation. Encapsulation promotes separation. Separation can definately be done without OO - but lack of separation frequently ends with disaster.

> Also, there was no system support for transactions

Isn't that the database's job?

Not always. If there is only one database or the transaction only has to span over interaction with one database - it could be the database's job. If the transaction involves more than one database and/or something else, i.e. an accounting system or a credit card system, then it can not be database's job.

Hasn't MVC been discredited? There are a lot of complaints about it in techie forums.

(Is there anything that hasn't been discredited?) MVC is about separation of concerns. The Model changes due to changes in the business, the View may change due changes in the business, but major View changes is often the result of either fashion or technical evolution. These concepts are held toghether by the Controller so they can remain separeted. MVC is useful when the need for separation exists.

To sum it all up: Don't forget separation. It is one of the most important things in software development.

Re:I disagree with their characterization of PHP

[nicware]

I find that usually the language used changes also. Often a new GUI fad is used as a justification to start over, for good or bad. Things went from COBOL to VB to Web, etc. Perhaps this is not rational, but that is what is often done. The UI "feel" is often too different to just plug in one-to-one anyhow. Plug-and-play drop in of UI paradigm requires either too much indirection, or too strong a crystal ball.

I think (or rather worry) that the reason that they change language often is the reason I gave. Too coupled code made it cheaper to rewrite it all. Using a new language for the presentation and keeping the current working logic is not a problem if there is a separation.

A colleague was working as an architect for a bank. They had running (business critical) systems written in 25 (yes, twenty-five) different languages. Some of these languages was actually unknown to the all the currently employed developers (which to my surprise didn't really hurt them since they could communicate with these systems, get the data they needed from it and continue the processing elsewhere).

But to take a mainstream bank example: When you are internet-banking, the systems that are used are not rewritten. The html producing code communicates with other systems, most of them written in COBOL. More often today, some Java Enterprise middleware seems to end up in the middle of all things, mainly to encapsulate older systems and make it easier to communicate with them. But the COBOL code is still running in the bottom. 24/7. It just has to.

An easy way to see that this is the case is that with the Euro introduction in many European countries, COBOL programmers are (again) back on request.

Most transactions I face are done by the database. Sure, there are exceptions, but that is the case for anything. Show me that OO works better than procedural for such exceptions.

I never said that OO would do that better. And OO per see doesn't. I just answered your question if transaction handling wasn't the databases job. In many systems, it is some (OO or non OO based) middleware products job. And I personally would not go as far as calling the use of these products exceptions.

> OO is a lot about encapsulation.

Other OO fans will probably disagree. There is no consensus on what OO is "really about".

No, there is probably not any consensus (although I think most OO language designers would tell you that there was a good reason they added two or more access levels for the data). There are as many ways of treating OO as there are developers. But there are also as many ways of treating procedural code as there as developers. At least when I was doing all my development in procedural languages, there were huge differences in what things people valued and the practises they used. If that hasn't changed, I guess the situation is the same in both "camps"?