----- Original Message ----- From: Tom Howe <mailto:[EMAIL PROTECTED]> To: 'Tod Harter' <mailto:[EMAIL PROTECTED]> ; 'Pavel Penchev' <mailto:[EMAIL PROTECTED]> 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. I think its great that we can solve similar problems in different ways - we are more likely to progress this way. and I dont think we write tons of code. I think we end up writing quite lean applications with less fluff. A colleague of mine is learning Java at the moment and says his head just gets full of standards and concerns about the best way to do it so everything is "compliant" that he has no idea how/where to start coding. The problem with that sort of thing is that you have to design everything in great detail in advance, endless UML diagrams. Which can be good if you have the people to manage it but often we dont and you just have to get something working that you can improve on as you go. 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. >> Yes definately, in fact Apache 2 has been at the back of our minds as a platform for our application server but at the time the Mod_perl support was rather poor. Once they have mod_perl for apache 2 sorted ill be taking a very close look at it. 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. >> Have a play around with Storable, I Find that sending a recieving a few K of perl data as a storable serial takes hundredths of a second. I normally chop them up into lots of little messages to avoid buffer problems. The first one sent says how many to expect. Its pretty easy. 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. >> Again, we try not to worry about that too much mostly because it takes too much time. We write our classes so that they are as "normal" as possible, ie they may refer to the session object to get session data but they arnt written in any special way to make them work or be 'compliant'. This means that we can later move them to another platform like Apache 2 if we needed to. Admitedly some things are not viable. Its not practical for us to allow "uncontrolled" code onto the system. Our application server cannot take a decision as to whether something is safe or not. And because of this its also not really suitable for use in a multiple user environment in the same way that Apache can serve sites for different independant people in a secure manner. But then I think that is a problem with Perl. The fact that Perl's OO support is pretty loose and doesnt support things like public and private data/methods means that trying to emulate the way Java does things is rather pointless. Its better to use Perl to its advantage. If you want to write complex EJB type applications where everything is highly componentised and tightly defined then expect to spend allot of time designing it. I have to admit I dont think Perl is really suited to that sort of thing. Its much happier when you try not to force it to do something it wasnt really designed for. And dont forget, if you were to devise some standard like EJB, you would have to then go to the trouble of getting everybody else to use it to :) In terms of abstracting SQL stuff, in essence its about managing persistancy and I think thats where things like Tangram and SPOPS, that Sebastian suggested, come in to play. We are lucky that we dont have to deal with that so much since all our business data is held in SAP and we use our own Perl SAP RFC module to handle that. But my view is that you wont save much processing power by automagically analysing an object so you can save it "as is" and avoid having to keep creating the object and loading the data manually. On a website, most dynamic data is of the 'session' type. Search results, basket information, your personal details and preferences etc. So we have a session object that all other objects have access to. At the end beginning of each request the session (a storablized perl structure) is loaded from the database. And objects that are required obtain their data from the session and save to the session. The session is automatically saved once the request is finished. Anything persistant that needs to be loaded from a structured database or some ERM system like a product search or order placement can be done manually using SQL or whatever. Its certainly worth abstracting this to a degree but since people store stuff in so many different ways its not really worth trying to generalise it too much. However, once the data is loaded its good to have a quick and easy way to get that into the session for quick repeat access. Pavel a
