-
1. Re: PHP-Servlet-EJB
luxspes Jul 16, 2008 11:29 PM (in response to nightnic)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)
-
2. Re: PHP-Servlet-EJB
nightnic Jul 17, 2008 10:32 AM (in response to 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.
-
3. Re: PHP-Servlet-EJB
luxspes Jul 17, 2008 3:37 PM (in response to nightnic)And why not run everything in the separate server for running java?
-
4. Re: PHP-Servlet-EJB
luxspes Jul 17, 2008 3:40 PM (in response to nightnic)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? ;-)
-
5. Re: PHP-Servlet-EJB
nightnic Jul 18, 2008 9:36 PM (in response to 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.
-
6. Re: PHP-Servlet-EJB
luxspes Jul 18, 2008 11:20 PM (in response to nightnic)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
-
7. Re: PHP-Servlet-EJB
ericjava.eric.chiralsoftware.net Jul 19, 2008 12:21 AM (in response to nightnic)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.
-
8. Re: PHP-Servlet-EJB
nightnic Jul 19, 2008 7:30 PM (in response to 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.
-
9. Re: PHP-Servlet-EJB
luxspes Jul 20, 2008 1:57 AM (in response to nightnic)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,
-
10. Re: PHP-Servlet-EJB
ericjava.eric.chiralsoftware.net Jul 20, 2008 4:29 AM (in response to nightnic)
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.
-----------
-
11. Re: PHP-Servlet-EJB
nightnic Jul 21, 2008 7:18 PM (in response to 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. -
12. Re: PHP-Servlet-EJB
nightnic Jul 21, 2008 8:14 PM (in response to 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.