PHP-Servlet-EJB

[nightnic]

Hi,

I'm looking into implementing an EJB-based service for integration into existing web-site. Website is written on PHP and hosted on standard ISP hosting. There is also a dedicated server which is the base for business logic processing.

My goal is to implement business logic processing using high-level language with adequate debugging abilities, e.g. Java, employ HTTP-based connectivity and make little change to existing website code.

Here is design I came up with: there is a PHP class on website-side, which provides business logic methods (i.e. getProductListing(), sendOrder() and such).
This class translates incoming method calls to HTTP requests on socket, which connects to a servlet on dedicated server. The servlet handles requests with help of EJB and sends back an XML response. XML response received by same PHP wrapper class, processed with XSLT and displayed on web site page.
Servlet and EJB running under JBoss AS.

Here go the questions:

1. Is there anything to be improved in this design?

2. There is an issue of handling session contexts. Servlet cannot discern users, since from its standpoint, there is only one connection source - PHP wrapper class. So there is need for PHP wrapper to manually supply JSESSIONID cookie from servlet to the browser and back.
Do you think there is any better way to handle this?

3. Which is the best way to handle session context on servlet/EJB side? I'm looking at JBoss Seam, but not convinced it will do because of previous issue. I'm looking into manually implementing session context tracking on servlet side, but there probably is a better solution?

Please let me know your opinion on this design. Feedback is much appreciated.

[luxspes]

Maybe Quercus PHP can help you (that way you can run everything inside a Java application server, you can keep PHP as a templating language for the views and use java for bussines logic)

[nightnic]

Thanks for your feedback!

Quercus PHP looks rather cool, but I have a constraint of leaving PHP on website hosting, which does not allow using an application server, or any java as well. So there is a separate server for running java, and web-site hosted PHP has to somehow communicate with it.

[luxspes]

And why not run everything in the separate server for running java?

[luxspes]

the constraint of leaving PHP on website hosting, is based on a technical reason? or its more like a political reason (because someone -your boss? your customer?- says so and doesn't like any other idea because only his/her ideas are good? ;-)

[nightnic]

The website and java part are developed and supported by different teams, which are loosely coupled. It is technically possible to run everything on java hosting server, but it is not in interest of involved parties :) So the question is how to do it efficiently.

[luxspes]

And just for curiosity: if running php inside the same host as the java application server is not an option... why bother? I mean, why dont you just write your business logic in PHP? after all it is a high-level language with adequate debugging abilities

[ericjava.eric.chiralsoftware.net]

I agree.  Basically, if Java has to be safely quarantined off on some other server due to political type of constraints, you're going to end up just having a SOAP interaction between PHP and the Java.  That might be worth it, if it's something that Java does really well and PHP does really poorly, such as some of the advanced EJB features, but it's going to be cumbersome.

You should run all your PHP code in a Java PHP environment, such as Caucho's Quercus.  It's a really cool way to go.

[nightnic]

Francisco,
Debugging abilities - yes, object oriented development - not really. Also, development speed is higher in java. One more reason of the design is that this link between php and java is going to be reusable, with java part varying in functionality, with no strict relation to php part.

Eric,
You are right at the point that there are simpler designs, but still, the goal is to provide maximum simplicity having existing constraints. Currently we use a socket in php, using which http requests forwarded to servlet. SOAP interaction you propose might be good as well, but it does not solve session tracking issue as of my knowledge.

So the question still is how to better translate session context from php to servlet, preferable so, that servlet stays unaware that it is contacted from php proxy rather than from user's browser.

[luxspes]

Hi!

Alucard Hellsing wrote on Jul 19, 2008 19:30:


Francisco,
Debugging abilities - yes, object oriented development - not really.

Well PHP5 is object oriented, for example Simfony looks as a pretty object
oriented (and MVC) framework for PHP, don't get me wrong, I particularly prefer java, but I do'nt think saying PHP
is not object oriented is a good argument for java nowdays.

Also, development speed is higher in java.

Now... that is a really unexpected affirmation, I prefer java coding because I think that in general the community
looks for solutions better engineered than those in the PHP community (or maybe they just look better engineered for me because I engineer them in a similar way) but, development speed? I just didn't see that one coming (PHP doesn't event need something like JavaRebel or OSGi to achieve zero turnaround time during development).

One more reason of the design is that this link between php and java is going to be reusable, with java part varying in functionality, with no strict relation to php part.

Eric,
You are right at the point that there are simpler designs, but still, the goal is to provide maximum simplicity having existing constraints. Currently we use a socket in php, using which http requests forwarded to servlet. SOAP interaction you propose might be good as well, but it does not solve session tracking issue as of my knowledge.
So the question still is how to better translate session context from php to servlet, preferable so, that servlet stays unaware that it is contacted from php proxy rather than from user's browser.

Perhaps with some kind of single sign on solution that works for both Java and PHP? something like CAS?

Regards,

[ericjava.eric.chiralsoftware.net]

Alucard Hellsing wrote on Jul 19, 2008 19:30:

Eric,
You are right at the point that there are simpler designs, but still, the goal is to provide maximum simplicity having existing constraints. Currently we use a socket in php, using which http requests forwarded to servlet. SOAP interaction you propose might be good as well, but it does not solve session tracking issue as of my knowledge.

So the question still is how to better translate session context from php to servlet, preferable so, that servlet stays unaware that it is contacted from php proxy rather than from user's browser.

I really would leave the session in PHP-land.  Why even have the session on the Java side?  You're creating an XML API (ie, SOAP) between PHP-land and Java-land.  What is that API going to do?  My guess it will look like EJB-ish function calls like this:

public List<Invoice> findInvoices(search parameters..)

or similar types of interactions that are not actually tied to a session.  I don't think you want to try to maintain sessions in sync between the Servlet environment and the PHP environment.  I think your best place to maintain session-ness is in the spot that is actually acting as a web server, which is PHP-land in this case.

Does this make sense?  Am I responding to the right question?  How do you envision using sessions?  Remember, if your business objects are in Java, and PHP gets them through SOAP, then they are all detached entities within PHP-world.

-----------

JBoss Seam Seminars

[nightnic]

Francisco,
I'm not here to start religious wars about what language is best :) Php has its strengths, just like java does. Also I didn't make my point clear enough. Java shines when you build complex systems, which are multicomponent and handle geterogenious information sources. Such systems probably can be created using php, but it is plainly not its purpose. Hence higher development speed of complex systems.
Regarding facilities like JavaRebel, well, every language environment has niches for improvements like this. No wonder OSGi is not needed for php, its just another scale.
Enough for the languages already :)

The reusability of the java-part is not in functional area. It is envisioned as some kind of framework for such class of systems, where pre-existing component needs to be coupled with enterprise system. The java part will have to operate not only with php sites but also with mobile devices or legacy systems. Current interoperability issue is thus only related to php adapter. I hope this would clarify the choice of java in the first place.

[nightnic]

Eric,

Yes, this makes sense and the question is correct.

The API, as you said, is typical, ie. authorization, listing entities (clients, orders, invoices, prices) etc. Authenticated users have attributes, based on which returned entities vary in content, so java-part has to know who makes which request. More to that, the php-part wouldn't know users, because they are kept at java side. User records automatically routed from an enterprise system to an intermediate tier, with which website is getting coupled. This intermediate tier contains logic of keeping its complete dataset up to date with the enterprise system. So I wouldn't want to transfer any part of this logic to the web site, which is used in a manner of thin client.

All said, sessions per se are not required, as impersonation can be implemented manually. Still, I am wandering, is it possible to make standard facilities, like servlet-based HttpSession, handle it for me. This would provide, for example, for creating stateful ejb instance per session and storing it in servlet session object. It is actually the main point of trying to pass PHP sessions to JAVA servlet.

Same is also the reason for using sockets and not SOAP for relaying http requests to servlet. I understand there are lots of ways and existing technologies to make this link work, like soap, webservices, message queing, etc.
Still, I would really like to limit our intervention into web site config (like additional php modules). And also to keep amount of supporting code at PHP side to a minimum, so java-part keeps all the facilities needed for interoperability with other technologies (such as perl, asp.net, etc.) (see my previous reply for reasons).

Please let me know if you see I'm wrong in some of these points.