----- Original Message ----- From: Tom Howe To: 'Tod Harter' ; 'Pavel Penchev' Cc: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 10:56 AM Subject: RE: AxKit for web applications
All this talk of beans and Java and I start coming out in a rash :) I agree to Tod that EJB as a concept is good and makes sense. The good thing Java did is they standartized the way an application should work. Of course we are in the Perl world and I just love that I can do anything, but IMHO it is stupid that all of us are solving similar problems in different ways, writing tons of code. I admire AxKit for having both a standart way of doing thing (the easy way) and a TIMTOWDI behaviour. As for the application server implementation, since perl threading is rather limited, attempting to do object caching/brokering is not really worthwhile. It's better to have application servers that are essentially stateless, throwaway boxes. Trying to replicate session data across them and then keep track of which request went to which server is just too much to deal with and only really an issue when you have Very high traffic sites. I'm sure you have developed your applications before apache 2.0 was out and you had to deal with tons of connection pools problems, etc. Now apache 2.0 gives a wonderfull way of doing your own thing - a raw socket connection. It gives you a perl interface to a pure TCP connection and you do whatever you want with it. This sounds to me like just the basis I'm looking for and you have already created - a server taking care of the connection pools for me and I just have to write the remote connection handling and object structure. In fact this way larg portions of the EJB2.0 spec can be ported to perl with less problems than you can imagine. Im curious to know how you combined SOAP::Lite with your own application server - did you use the provided HTTP Transports or write your own? For our SOAP interface we just catch the raw XML and allow Apache to to the HTTP side of things. This is why it isnt particularly quick for us and is there moslty so we can speak to the outside world when required. I'm curious too - I had doubts that Storable is fast enough, now SOAP just doesn't sound like the right tool for the job. Instead of a binary like protocol you have a heavy XML floating in the RMI calls. SPOPS and Tangram sounds interesting - im certainly going to look into them. There are nice things my I'm more concerned how a piece of code that is going to be deployed in the app server is described. Again Java but.. as an example the EJB is described by a interfaces (Local, Remote), the code that really does the job, and descriptors in xml format that specifies the abstract shemas for SQL tasks. As I do not want to copy the way Java did it (I just like the idea of EJB) I wonder some of you (Tod,Tom or anyone else who has dealt with these matters) have defind a sertain skeleton that works well for him. Pavel
