At 10:27 AM 4/26/02 -0600, Rob Nagler wrote: >Stephen Adkins writes: >> There are going to be an increasing number of cases where >> the P5EE needs a core server, separate from the web server. >> (Similar in some respects to how an EJB server is separate >> from the web server in which Servlets run.) > >I think the reliability/flexibility/security of Apache/mod_perl is >hard to beat. We initially had separate servers in bOP, and we >through them out in favor of using Apache for all RPC. We marshall >requests to mulitpart/form-data, so we get maximum reuse. However, >you might consider SOAP if you want more complexity.
Hi, Yes, I like Apache/mod_perl for everything that can be satisfied within a short period of time (i.e. synchronous calls). However, when I initiate tasks from a browser which take a long time, I think the work needs to be offloaded to another server... one that can stick around and do the work. Our example: We have developed a competitive rate shopping tool for the rental car industry. This is not a site for consumers but for members of the industry who are seeking to set their rates wisely with respect to their competitors. We have a private WAN connection to Sabre (the travel reservation system) and some Sabre interface libraries. We have written the XS interface so that we can use these Sabre libraries from Perl. To request the rates for all car rental companies for a single day for a single car type is a transaction with Sabre that takes about 3 seconds. A report requiring data for the next 30 days for 5 car types would take 7.5 minutes. This is too long for the user to wait (and the browser would most likely time out). Furthermore, requests need to be queued. This is not a good use for a web server. Thus the need for another server. So on my original question, I am coming to the following conclusion. * POE is good if you want to field multiple requests within the same process. Thus, there can be a lot of interaction between requests because they share all of the same data. POE Sessions can keep logically distinct activities from interfering with each other, but they still all run in the same process. POE will not help you take advantage of multiple SMP CPU's (until threading becomes more mainstream), nor will it help if my "handler" needs to make calls to a library which blocks (my Sabre library) and that doesn't have a non-blocking interface. Of course, I could always fork a child process to stick around and do the work (sorry win32 users). * PlRPC is good if you want a separate process to handle each RPC call. This is not good for interaction with other requests, but that is not necessary in my case. I am still looking into whether I can return an RPC result (the request_id) from the RPC subprocess and then remain alive in order to do the work. As above, I could always fork a child. Stephen
