On Smalltalk

Here’s an interesting post from a Java guy trying to decide between Ruby on Rails and Seaside. He has quite a few interesting things to say concerning the shortcomings of Ruby on Rails, and how well Seaside handles that complexity with ease.

He also has a few complaints about Seaside, most of them valid. Seaside still isn’t the full stack solution that Ruby on Rails is. We still have to handle object relational mapping, something Ruby on Rails gives you for free. Nor does Seaside deal with object validation and errors, I use Magritte for this. Magritte rocks, but I’m not sure the average guy trying out Seaside will find it, or learn how to use it. From an outside point of view, Ruby on Rails looks like a much more complete solution.

We have Glorp, which can do this, but only against Postgres Sql in Squeak. Nothing against Postgres, but seriously, in the real business world, it’s either Microsoft Sql Server or Oracle; and it’s also usually a legacy database, so we really need something like Glorp for those databases, because something like ActiveRecord is just too brain dead to work.

Most of the schemas I have to work with suck, and can’t be changed because people used the database as an integration point for multiple apps (God I’m tired of seeing people make this mistake). Doing a simple class = table, object = row mapping just doesn’t cut the mustard for legacy development against existing databases.

Seaside is far more advanced than Ruby on Rails, and is a much better web framework for doing anything complex, but we’re still missing the market on CRUD apps. CRUD against a popular business database is still far too difficult using Squeak. I’m sure Visualworks has far better database support, but I want something free… I want Squeak, I want Squeak to work with Sql Server, I want a Pony… :(

Featured Resources…

There are different programming languages for different purposes. For advertising the one that has the best features becomes bit difficult as they usually have their own purposes to fulfill. Similar competition applies to the hosting companies, like ipowerweb, or another best one would be dot5hosting to choose from. With the cheap internet phones comes the cheap call rates. Taking a 350-001 test got easier with preparation guides available online.

Tags: Databases, Magritte, Programming, Ruby, Seaside, Sql

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