On Wednesday 05 February 2003 03:56 am, Tom Howe wrote: > All this talk of beans and Java and I start coming out in a rash :)
Yeah, me too. I really hate EJB, but its sort of a religious thing I guess, each to his own and we know we aren't Java lovers here in this list ;o). > > 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 agree totally. In fact I found that MySQL is so fast that in most cases you CAN'T create a cache thats realistically faster than just using SQL to fetch what you need for every operation, crazy as it sounds! > > 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. Well, we have perl on each side, the SOAP::Lite client side which is stubs called from taglibs (or in theory any other perl code that wants to talk to the backend, it doesn't have to be AxKit). On the application server side you have Apache 2 running mod_perl and SOAP::Lite's server side, which simply exports a list of modules as SOAP services. Now since effectively these are just RPC calls our server child instances instantiate a singleton object for each interface at startup time and the server side of the SOAP conversation just routes these calls to the service object instances, which in turn implement whatever API the stub code on the client side was calling. So I guess the short answer is that Apache handles the transport part entirely. We can also handle async SOAP over SMTP by having procmail invoke a perl script that makes direct calls to a service object instance. The SMTP MTA thus provides the message transport and an inbox at the endpoint is the incoming message queue. If we want batch processing we can do that with a perl module that can read an inbox (or it could be foisted off on an IMAP server on a seperate machine). Overall its a pretty powerful infrastructure and to be honest I don't see much practical limit to how much you can scale it. Our object layer allows multiple object stores that each can hold a subset of all the objects, so we don't even need to have our databases synch to each other, we just have an "object distribution layer" that takes care of finding which database a particular object is actually stored in, and that uses the same SOAP protocol between servers as the application server layer does! > > SPOPS and Tangram sounds interesting - im certainly going to look into > them. > > -----Original Message----- > From: Tod Harter [mailto:[EMAIL PROTECTED]] > Sent: 04 February 2003 22:19 > To: Pavel Penchev; Tom Howe > Cc: [EMAIL PROTECTED] > Subject: Re: AxKit for web applications > > > Sounds to me like his system is basically identical in most respects to > the > one I came up with for a virtual private exchange (sort of an auction > server > type system). We used SOAP::Lite entirely, each XSP taglib was just a > thin > wrapper over a stub API that called back to the application server > running on > a seperate set of back-end servers. The back-end servers in turn > implemented > a series of SOAP services that were very "bean-like" in there structure, > > though personally I think EJB is kaka in many respects, still the basic > concept is sound. > > In our case we created our own object system, though there are some > pretty > good ones like Tangram and SPOPS out there for perl already. You might > check > them out. > > I will warn you though, there are some real hairy things to deal with! > Everything at all levels has to be basically sessionless because you > never > know when people are going to come and go. You can't really cache > objects in > memory on the application server since you don't have session affinity > between it and the front-end (and even if you did you'd have multiple > caches, > one for each back-end child apache). Of course you could implement your > own > SOAP server on the backend that was a single process, but even then it > would > need threads and perl threads can't share variables as of yet, so its a > pretty big stumbling block. > > Overall though it was a nice approach and worked well for us, though our > > marketing people were too feeble to actually sell the project properly, > sigh.... > > On Tuesday 04 February 2003 12:25 pm, Pavel Penchev wrote: > > Hi, > > > > I got interested in your post - I'm in the planning stage of a system > > just like yours: AxKit as a front delivery toolkit and a custom > > application server as a business logic backbone. Is Storable fast > > enough for complex data structures returned from the RMI/RPC calls - > > results from database queries, complex hashes, etc? I guess the app > > server servers some bean-like perl modules - do you have a > > standartized skeleton for perl modules turning them into "Perl beans"? > > > > I've met some very old projects in cpan that had done some work in the > > > > bean direction. > > > > Are you planning to release the app server as open source ;)) > > > > Pavel > > ----- Original Message ----- > > From: Tom Howe > > To: Robin Berjon > > Cc: brian wheeler ; [EMAIL PROTECTED] > > Sent: Tuesday, February 04, 2003 5:30 PM > > Subject: Re: AxKit for web applications > > > > > > Here at Deluxe Media Services we use AxKit at the front end (on our > > webservers) and a custom perl application server sitting behind to > > handle > > > all our business logic. All database queries, data munging, session > > handling etc is handled on the application servers. > > > > Every page requested is based on the same fundamental XSP page that > > forges a connection with the application server. Additional XSP > > components are then included where required to provide functionality > > on a web page. These components use the connection with the > > application server to send/receive object/method type requests. We > > have a simple RMI/RPC type interface on the application server that > > now supports SOAP but the default communications is a fast proprietary > > > > message using Storable. > > > > The advantage of such a setup is that > > * we have an additional layer of security (keeping all business > > data/logic away from the front end web servers) > > * we have higher separation of code/content which makes it easier to > > manage > > * we have a more granular means of scaling our website > > > > The connection required for each page does have a performance hit > > but we > > > have not found it to be an issue and the fact that we can scale in a > > fairly linear fashion more than makes up for this. > > > > Feel free to ask for more details if this is a route you are > > interested > > > in. > > > > Tom Howe > > > > On Tue, 4 Feb 2003, Robin Berjon wrote: > > > brian wheeler wrote: > > > > On Tue, 2003-02-04 at 01:29, Kip Hampton wrote: > > > >>I personally favor using something like CGI::XMLApplication > > because > > > > >> the model fits the way I like to work, but nothing that baroque > > is > > > > >> required. Again, as long as it can return an XML document to > > the > > > > >> Provider when needed, it can be as quick-hacky or as > > over-engineered > > > > >> as the situation warrants. > > > > > > > > I've found that using Apache::RegistryFilter and Apache::ASP > > filtered > > > > > into AxKit makes for neat fun. > > > > > > I'm curious as to the performance of that kind of setup, do you > > have > > > > any numbers? > > > > > > -- > > > Robin Berjon <[EMAIL PROTECTED]> > > > Research Engineer, Expway http://expway.fr/ > > > 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488 > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Tod Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
