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

OK, that was not what i was expecting

[Rhinobird]

OK, that was not what i was expecting.
I was sort of expecting auto-generated scripts for star trek...it's time to go to bed.

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]

So Java's answer is just to hoover up all available memory and then share it?;-)

Yes ;-) and no. PHP provides a bit less control on choosing the appropriate trade-off between size and speed: an issue born with data structures and algorithms, much older than Java.

How is this scalable, say, to multiple computers?

Performance is a matter of software design and not of language or bytecode or whatever. It's like the "don't debug, verify correctness" principle of eXtreme Programming. Here it's: "don't optimize your code, design it to be fast and scalable".
On multiples computers, your design should also reflect the same principle: avoid reprocessing the same things again and again. The difference is only about granularity. Caesar's "divide and conquer" principle is very useful too.
You may specialize some machines on some subsets of data so each can have in memory the data they need most of the time, let each work on it, and finally merge all sub-results. That's how Google manage its huge index for instance.
You may also keep databases but use them through Active Objects to "decouple method execution from method invocation to enhance concurrency". I often use a LRU cache to address the issue of what should be kept in memory and what should not.

Can you point to a document that explains some of this stuff without using words like 'enterprise enabled'?

That's a very wide topic covering most of computer science: data structures and algorithms, design patterns, architectures of OS, ...
With some experience, I discover OOP and system programming are very similar. Programmers of both worlds often argue although they in fact agree: they simply don't use the same words for the same things!
I therefore suggest you have a look at Design patterns from Gamma and al., Pattern Languages of Program Design from Vlissides and al., read any good book about the architecture of modern OS (paper on I/O aspect), and for god sake keep off "The ultimate /my-favorite-language/ Programming Bible ;-).

IMHO, every programmer should know about design patterns, even if he doesn't consider ever practicing OOP, and about how wonderfully OS are designed, even if he doesn't consider ever leaving Java to write a device driver or an I/O library in C.
In addition to improving software around, it would also make a true miracle: terminate the weekly Biggest Di*k Contest about languages on /.

Re:PHP doesn't scale?

[Tablizer]

You can't do the former in PHP unless you use a RDBMS (not as fast as direct memory access)

It is a myth that RDBMS *must* use disk. True, the current implementations were built around a disk-centric approach, but they are slowly evolving to make better use of more memory as the prices drop.

By the way, there seems to be a division forming between relational-centric shops and OO shops. PHP shops are probably more likely to use RDBMSs more extensively, while OO shops tend to kind of do database-like things in code. To me, that is too much hand reinvention of the database, plus does not give you the power of relational theory, but relational-vs-OO debates have already raged on slashdot.

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!).

NoooO!

[HaloZero]

I just... cannut... dooo it, kaptain!... the damned server j'st dunnit have the POWAH!!! Filthy cyrix piece of jun'k. I've seen Klingon garbage scows with bet'er processin' units than theeeze. Ah mean, you cannut really expect meh to be able to run a business on THIS kind of processor!

Tho I may be able to give ya' warp three...

Pffff... overkill?

[ptaff]

What makes PHP so nice for web development?

• Is it syntax style? No, it's pretty standard C-like-syntax-with-braces;
• Is it speed? Nah, interpreted like most of them web languages;

What makes PHP great is an impressive set of embedded libraries, easy integration in an already existing plain HTML document and POST, GET, cookie, session management.

Look at this beast: *SQL*, FTP, zip, flash, XML, gettext, image manipulation, LDAP, UNIX process control... all rolled-into-one language. Wow. Perl is, in that respect, with the right CPAN modules, as nice as PHP, but dare I say... easily obfuscated?

PHP had (still has in 5.0?) enormous deficiencies and bugs in its OO model. Works great for quick pages, but as the article says, does not scale well.

So, why insist on keeping PHP for large-scale sites instead of plain java? to use PHP's libraries, HTML integration and web-oriented features, that's it. An artist can draw a page in his favorite application, export to HTML, the coder only has to fill the blanks.

The language in itself has no advantages. If java had all these libraries and "native" web access, why would we consider "merging" these two languages?

Think of it, two interpreted languages joining forces to drain down CPU and memory...

(just my two cents)

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?

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.

OOGG CONFUSED!

[OOGG_THE_CAVEMAN]

OOGG lack much experience in PHP, but have much experience in stone age OO design.

OOGG confused by combined complaint of "restrictive OO model" and "no provision for protected members or private variables."

PROTECTED MEMBERS, PRIVATE VARIABLES ARE RESTRICTIVE OO MODEL. OOGG use simple stone-age example. OOGG HAVE STONE WHEEL. USE AS WHEEL. SOMETIMES, WANT ACCESS TO HOLE IN CENTER. Some programmer say that hole "protected implementation detail." OOGG think OOGG NO CARE WHAT YOU THINK AT DESIGN TIME. OOGG NEED HOLE ACCESS. OOGG NOT WANT BE FRIEND WITH ALL YOUR CLASSES, JUST USE HOLE!!!

OOGG not like restrictive OO model, INCLUDING not like often useless "protection" features. In general, programming languages ineffective tool for preventing stupidity. Should rather use club on head of stupid programmers. Darwinian process then result in smarter programmers, less outsourcing to foreign caves.

Re:OOGG CONFUSED!

[OOGG_THE_CAVEMAN]

OOGG recognize possibility of refactoring, and understand tradeoff involved. Software engineers, however, not changed since stone age. 1.0 API brain-dead anyway, implementor always take advantage of "major version" to "upgrade" API incompatibly, so OOGG change his code in any case. In meantime, OOGG need deliver his app before next ice age start.

OOGG may be caveman, but can read API header comment, see what is internal or not. No need to crack OOGG head with private/protected club.

Re:OOGG CONFUSED!

[drugdealer]

What if the public API does not provide the needed functionality - but a private method or a manipulation of a private variable does?

Options:
1) Request change to public API, then wait for the owner of the code to change it.
2) Add a new method to the public API yourself - then try to merge it in if you are not the owner of the code.
3) Access private method or variable (after changing some keywords).

I think a lot depends on the accessibility and responsiveness of the owner of the public API.

Re:JSP/PHP Compare and Contrast

[Anonymous Coward]

Wrong!

The truth is this:

Business Logic
Java - Good
PHP - Bad

Presentation Layer
Java - Even better
PHP - Good

I used to code in PHP all the time and loved it. But then I learned JSP and realized PHP is a waste of time...after I discovered JSP's tag libraries (both official and open-source ones), amazing amount of templating options, not to mention frameworks like Struts.

The guy who thinks PHP is good for the presentation layer simply hasn't really used anything else...he probably thinks Visual basic is great too.

PHP is cool, but it has so many missing features it's not even funny...and yes, it's SLOW. PHP functions that are built-in are fast (of course...they're written in C/C++), but if you write any of your own complex business logic it falls apart peformance-wise.

I had to write some XML processing in PHP and used the PHP XPath class from sf.net (since my ISP did not enable the built-in XML extensions). In most cases my pages timed out, PHP was not able to complete processing the XML file within 30 seconds (!). Java's JDOM did the same in 3-4 seconds.

but, back to JSP...they're great and make PHP look like a toy. Those who think otherwise have probably never written a real site in JSP. I've written them in both languages and I'm never coming back to PHP again...it's like going back from the full power of Unix to the clunky user-friendliness of Windows 3.11.

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.

Scriptiing?

[Thing 1]

Do the editors have a spell checker? Do they have bosses who care?

Re:JSP/PHP Compare and Contrast

[dismayed]

Regarding not having Zope page templates in PHP or Java...
There are implementations for both:

• PHPTAL
• JavaZPT

JSP vs. PHP

[inertia187]

I know this article is about combining Java and PHP, but has anyone noticed that JSP has overtaken PHP at least from the standpoint of session cookie default names. It didn't used to be like that. PHP always points out the mod_php numbers, but there is no direct JSP Apache module, only mod_jk which is for any servlet container. I think that's interesting.

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"?