On Smalltalk

The first thing any .Net programmer wants to know, after finishing the toy examples, is how do I connect to Sql Server and do some real work with Seaside.

Yes, I said Sql Server! No other database is in wide use in the .Net community. No one, and by that I mean very few, uses MySql, PostgresSql, Oracle, FireBird, or any other database you can think of. 90% or more .Net programmers use Sql Server exclusively, it’s just what’s done. I’m not against other databases, or object databases, and have used Goods and MySql a bit myself, but if Squeak and Seaside want a foothold in the .Net community, it must play nicely with Sql Server, PERIOD!

This is a problem, a huge problem, because Squeak doesn’t have native Sql Server drivers. Squeak’s only access is via ODBC, which uses Squeak’s Foreign Function Interface (FFI). ODBC works reasonably well, and seems reasonably fast, however, the FFI locks the VM when in use effectively making all access to Sql Server single threaded. Yes, some of these other database have native drivers that don’t lock the VM, but I’m not talking about them. Yes, you could use Visual Works and Seaside, which has native access, but I’m not talking about it either. I’m only talking about Squeak and Seaside, I prefer them, because they’re free.

In Squeak, it’s ODBC or nothing, and ODBC simply can’t scale. You can do small sites in it, but tying a multi-threaded server, the web server, to a single threaded interface to the database (FFI), simply can’t work in production if you expect any sort of heavy load. It’s unacceptable to have one web request waiting for another to finish a query, while blocking the user.

Now, this might seem like a show stopper, I almost thought so myself, but it’s not. If you set your architecture up right, you can avoid the need to access Sql from Seaside, and avoid the issues that ODBC and FFI create. You simply have to change your approach, and consider Seaside as an addition to your existing .Net infrastructure, rather than a replacement.

If you have a site large enough to be too big for ODBC, there’s a good chance you’re going to have multiple web servers load balancing the traffic. If you have a site large enough to need to load balance the traffic, there’s a good chance you may have already broken your application up into tiers. This is the perfect place to combine the strengths of Squeak and Seaside, with the strengths of .Net.

Break your application up into two tiers, a presentation tier, and service tier. Have the service tier consist of .Net based web services, and the presentation tier consist of Seaside based sites that consume those services via Squeaks SoapClient library. You can host the application tier, on the same boxes as the web servers, or on their own boxes, if you have the traffic to justify load balanced application servers as well.

SoapClient has recently been made compatible with .Net after I did a little begging and pleading with the author, Masashi Umezawa, to make a few changes to accommodate .Net’s quirks. He was totally cool, and made the necessary fixes in less than a day, I can’t thank him enough.

.Net is perfectly sufficient, and actually quite nice, for running queries against a Sql Server database and handing it out via web services. .Net’s weaknesses lie in its poor web framework. I shouldn’t even say poor… from the Seaside point of view, it’s simply old fashioned. If you think of Seaside as just the presentation layer, which it excels at, you’ll find it quite a nice division of labor. .Net can hand back real objects to Squeak, which can use them quite easily, either as dictionaries of associations, or if you register a real object with SoapClient, can de-serialize directly to a real business object containing all the necessary rules biz objects contain.

You also gain the benefit of forcing yourself to create services that you will likely find other uses for. Maybe you have other clients who’d like access to those same services. Maybe you can take advantage of this architecture to have your .Net guy building web services while you Seaside guy plugs away building the front end. Your Seaside guy can fake the services and build the front end while he’s waiting for the real ones to be build, should that be necessary.

Be careful when using SoapClient against a service, there are some security issues with Squeak’s SoapClient. Make sure you control the server, and trust all data coming from it, else someone could execute arbitrary code in your image by returning some bad data. For the same reason, I wouldn’t host any web services in Squeak, I’d use .Net, or whatever your favorite provider is. But for accessing in house web services, that you trust, I see no problems using Soap as the leverage point to introduce Seaside and Squeak into the world of .Net. Seaside royally kicks ASP.Net’s ass, and can make building your web applications an order of magnitude faster and easier, and that counts for a lot.

I’ve been using this approach for a couple of months, and so far, it’s working quite well. I will continue doing so, and write about any issues I run into, as I run into them. In the mean time, I’d love to hear from anyone doing anything similar.

Tags: Databases, Seaside, Smalltalk, Sql