Bringing PHP into a J2EE project

Discussions

General J2EE: Bringing PHP into a J2EE project

  1. Bringing PHP into a J2EE project (8 messages)

    I recently kicked off a new web-based enterprise product with the intention of using a pure J2EE solution - as per my mandate when I joined as Architect. But because of the skills of the team I was given, and my growing frustration with Java based web tier technologies (tried Struts, Tapestry, simple JSPs...) the architecture took a different course.

    The server side of the architecture is good solid Java - with Hibernate providing our object-relational mapping, running on Jboss behind a web services facade (packaged as a WAR file, provided by the free standard edition of [Web Methods] Glue at this stage because we haven't time to fiddle with Axis). The client for that soap interface is in fact PHP 5 - which now as a very elegant and simple Soap client built into it. You just construct it with the address of the WSDL file and call methods like any other object.

    This use of Apache and PHP5 on the web tier and Java with web services on the business tier has proven really appealing and very fast (both in performance terms and development velocity terms). PHP is simply much better at handling the "mushiness" of the web tier (where human beings get to meddle with their browsers). We're using Smarty to provide templating and with a few choice PHP classes we've got the MVC pattern on our PHP web tier. Very nice.

    The other interesting piece in the puzzle is Memcached. This is a really good lightweight cache that can be invoked from either PHP or Java (or Perl if you really want to). We're using it from the PHP tier as a distributable cache for conversational web state. This allows us to keep the PHP stateless and light and gives us more control over the caching than the traditional http sessions (in Java or Apache land) permit (e.g. in terms of an LRU strategy to avoid memory explosion etc.).

    If anyone has any thoughts on this, perhaps on how we could improve things further, then let me know. We're still early enough in the project to take on a bit of steering - especially because of our JUnit test coverage ;)

    Sean.

    Threaded Messages (8)

  2. persisting sessions[ Go to top ]

    i too am exploring various web frameworks for developing applications whose back ends are java/ejb. i've tried a php client but am having trouble using the php soap client. can you tell me how you got your axis sessions to persist across SOAP calls using the PHP SOAP client?
  3. PHP SOAP CLIENT[ Go to top ]

    May be this could help you?
    http://www.devx.com/Java/Article/21707
  4. Sessions[ Go to top ]

    Hi,

    Sorry I haven't replied sooner, I've been very busy on this project. We aren't using Axis as it happens but the standard [free] edition of Glue (formerly by the Mind Electric). All our conversational state is in the web tier - in the Memcached daemon as it happens, although our PHP session client is pluggable so we can use MySQL, PHP Session etc. if we wanted.

    We use the PHP 5.0.2 SoapClient to make remote method calls to our Java application tier but don't attempt to persist any state on the application tier other than our core Hibernate domain objects.

    I have to say its working out really well. I've used all kinds of Java based web tiers over the last few years and I've never been pleased with any of them (Struts and Tapestry included). Java is fantastic as a server side transactional language but not so hot for the web tier.

    So I suppose I would turn your question on its head and ask you what state you need to store conversationally (rather than in long term persistence) on the application tier?

    Sean.
  5. EJBs[ Go to top ]

    Oh and just out of interest, are you using EJB entity beans? I've used EJBs since version 1.0 and to be honest with you I wouldn't use entity beans anymore, not with the richness of JDO and Hibernate - especially when you bring level 2 caching into play. I think there is a role for message driven beans if your business architecture requires it and stateless session beans are still a decent remoting technology, if your client is Java based but on the whole I am glad to put them behind me.

    Sean.
  6. Security[ Go to top ]

    Hi!
    This looks very interesting.
    ...but what about security? Is authorization and authentication of users enabled in your application? If so, where does the authentication take place? Have you seen any possibility to use JAAS mechanisms in JBoss and in the web tier, and have you got them to work together?
    I am currently looking at security issues in an application using both PHP and J2EE, and I have failed so far in my attempts to find anything that would work the same way as a java web tier connected to JBoss would.

    Regards,
    Fredrik
  7. To be honest with you I have found JAAS to be a pain in the neck - unless you intend to authenticate/authorise against some kind of LDAP repository or using biometrics its a bit overkill (in my opinion). We are using the PHP layer to provide authentication (by accessing a separate authentication database from the main business databases). Remember as well that by deploying our web tier on Apache we could also use the authentication plugins that it uses (the PAM modules). As for authorisation, we propegate the authenticated username to the Java web services/business layer. The Java tier can then do the usual role-based access control check. This approach gives us a good degree of flexibility and ease of use.

    The authentication is done by having a checksecurity.php page that is included by all secured pages. It checks for logged in user credentials in the session (either the PHP session or Memcached currently). It picks up a cookie from the browser (hashed of course) and checks the session as I said. If no authentication details are found in the session the user is re-directed to a login page. From that page authentication to the authentication database takes place. On successful authentication details are stored both as a hashed cookie of the username and an entry in the session. We believe this provides sufficient security with a very simple, easy to maintain solution.

    Our Java web services layer is actually not currently exposed directly - only our PHP layer can access it, hence we don't need separate authentication at that layer, just authorisation. This trust basis may change in the future but for now it suits us well.

    Hope this helps,

    Sean.
  8. Looking for about project news[ Go to top ]

    Hello sean,

    I have to study on a php webapp.
    It's a global CRM.
    The boss is very intersting about J2EE platform.
    He doesn't want to rewrite all the CRM.
    Your project is very intersting but i'm looking for some infos about your project.

    What were your adv/cons on this project .

    Bye
  9. Info on Project[ Go to top ]

    Hi,

    Sorry not checked this account for ages, been very busy at work.

    The big advantage of this architecture is the fact that we have very strong best-of-breed elements now. PHP with Smarty has proven (over the last 12 months) to be very reliable and very quick to develop with. Our lead developer has introduced custom smarty tags for things like authentication, role based access, language translation {l}prhase_code{/l} in your HTML etc. Its very elegant and very simple.

    On the Java side we have a good service oriented, command backed architecture connecting to Hibernate to provide ORM and database independence. Again, a very fast architecture to develop on with a strong element of JUnit testing.

    The disadvantage is really in the connection between PHP on the web tier and Java on the server tier. We've used SOAP, which is fine, but Java is not as advanced in providing transparent SOAP as PHP is, so there was quite an initial outlay on this side of things.

    I just spoke with representatives from Zend (the PHP Company) today about their latest Zend platform which offers JSR 223 support for PHP-Java integration. I like the idea of using this to call simple EJB Stateless Session beans instead of using SOAP between the tiers.

    I recommend this architecture if you have a mix of skills or an existing Java application you want to rejuvinate with some PHP elegance.

    Sean.