Bruce Badger is the current chairman/admin of the OpenSkils group, which promotes the skills and availability of people who want to find various kinds of consulting work. The talk is covering the application server that Bruce has written to support the website. So first off, he's doing a few definitions for the benefit of non-Smalltalkers in the audience - the Image. Apache, while running, has a footprint (an image). A Smalltalk image can save its running state and be started up again - possibly on a different machine/OS altogether.

To demonstrate, he's showing a quick workspace demo of a printIt operation. "A demonstration is like TinkerBell - it only works if people believe in it" :)

So one architecture has Apache at the top, CGI between that and VisualWorks, which is the server. The application logic is in VW, and the data is stored into a PostgreSQL database. What Bruce advocates is the smallest number of components possible - because it simplifies configuration and deployment. With most J2EE servers, there's an impressive number of XML files to get properly set up. On the other hand, having too few components can be just as bad.

The smallest possible? Run the HTTP server right in the Smalltalk image, and use the database for persistence. Again, a demonstration using the Swazoo web server (a contributed piece from the community that you can load into VW). The cool thing? Inserting a breakpoint into the handler that takes the request, and we can poke around in the guts of the HTTP server and see what's going on. Not that you have to; like any other HTTP server, you can treat it as a "black box".

There's still a bit of an "impedance mismatch" between objects and database tables. This consumes both developer time and runtime resources (re-assembly of the object when taking out, and disassembly when storing in). The analogy Bruce uses? An OO database is like parking your car in the garage and heading to bed. An RDBMS is like taking it apart and hanging the parts on the wall first - and then re-assembling it in the morning.

So what if your back end is Gemstone? Gemstone is actually more than just an OODBMS; it's a full Smalltalk environment with a multi-user image. It's also transactional and highly scalable.

So using GBS (the interface between GS and VW), the persistence layer between the application and the db has shrunk. Like any database, there's performance tuning that you have to deal with. What they could do is run the entire Skillsbase system in Gemstone - no app/persistence separation. There are two issues:

• The Gemstone VM is slower than the VM for VW
• The class library for GS is less extensive than VW's

Next issue - one instance of the application isn't enough.

• Option 1: Many threads per process - involves semaphores and locks, hard for developers to follow - and if they are native threads, you get big differences between development time and production time, because the native threads are non-deterministic
• Option 2: Many processes - simpler for developers, but each process does use more resources.

In Smalltalk, an image tends to be one process, where the threads are managed by Smalltalk. A Gemstone image supports multiple processes called Gems. You get separation by transaction. Changes to objects are local to a Gem until you do a commit.

So with Gemstone, the impedance mismatch goes away - you simple #commit the objects when you want them to be stored. Sometimes, you do need to work with an RDB. It can be simpler if it's not being used for ongoing application persistence, but instead as a "read-only" resource.

With multiple processes, each requires the whole application, and you may well have shared data across them. This can lead to memory waste. You can have the multiple processes use shared memory for the code and read-only data. Making some of that data writable is harder, but possible - Gemstone does this with a shared page cache. There's no developer effort for using this. This becomes invisible to the developer. With this approach, you don't need session affinity (the shared page cache deals with that problem).

What about developer efficiency? They use VisualWorks because it's the best development platform available. They express everything in Smalltalk that can move between VW and Gemstone, and it's all versioned into the Public Store Repository. So they develop in VW, and deploy on Gemstone. This allows them to focus on the problem at hand - no XML configuration files, no differences between runtime/deployment time. Or as Bruce puts it -

Stuff Just Works

The shared page cache makes their application essentially stateless (which helps with scaling). The Gems run as OS Processes, so they make use of multi-processor machines nicely. A commenter points out that the way hardware is going, the shared page cache might well help less - due to blade farm type deployments and the need to start replicating the cache. On the other hand, deploying multiple non-shared images in that setup would be less expensive - I think it depends on the problem you need to solve, and the available hardware resources.