Discussions

EJB design: PHP-Servlet-EJB - design choice?

  1. PHP-Servlet-EJB - design choice? (2 messages)

    Hi, I'm looking into implementing an EJB-based service for integration with 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. This processing is to reside on separate server. 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 maintain session contexts? 3. Which is the best way to handle session context on servlet/EJB side? I'm looking at JBoss Seam, but not sure it will do, because of the item 2 issue. I'm looking into manually implementing session context tracking on servlet side, but may be you advise a better solution? Please let me know your opinion on these questions. Feedback is much appreciated.
  2. Why use two server-side technologies? What do you gain from taking a PHP request and re-formatting it as a Servlet request? Why not just request the servlet directly? Both are designed to respond to HTTP requests. If you are looking to re-use the PHP code, most PHP apps are designed to have the business logic and database access right in the pages; wouldn't this be the logic you are implementing with EJB? And why would you serialize data in XML and then use XSLT to deserialize it? Why not put the data into the response and access it directly (e.g. via JSP)? That would be much simpler and easier to deal with.
  3. The reason for two technologies is necessity to add some enterprise-related functionality to the (previously existed) website, while leaving it otherwise intact. Website and enterprise functionality located on different servers and supported by different teams which are loosely coupled. XSLT is used for the reason of separating data and design (naturally) each of which supported by different groups of developers. So the question is not really about design simplicity but more about choice of underlying mechanism.