Seaside, ODBC, and Sql Server for the .Net Developer
By Ramon Leon - 3 October 2006 under Databases, Seaside, Smalltalk, 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.
Comments (automatically disabled after 1 year)
Hey Ramon I'm trying to call a .NET web service
|call |
call := (SoapCallEntry tcpHost: 'ws.textanywhere.net' port: 80) newCall.
call targetObjectURI: 'http://ws.textanywhere.net/ta_sms.asmx'.
call methodName: 'CheckNumber'.
call addParameters: {
{#Number. '07908856934', 'xsd:string'}.
}.
call invokeAndReturn.
It doesn't seem to work could help us out when u got time?
You need to make sure the services are marked with the either the SoapRpcService or SoapRpcMethod attributes, the Squeak Soap client does not support document encoding, the .Net default.
thanks for ur quick reply, you said in your post "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" i thought this would allow squeak client to support document encoding. the service i'm calling is a 3rd party service which i have no control over, any ideas on how i can make Squeak Soap client to talk to it
Unfortunately, no, as far as I know there is no way to access a .Net document encoded web service in Squeak.
Great blog Ramon, as a .NET/C coder at work and a Smalltalk coder at home, I can definitely relate to your perspective.
I too have been very curious about working with databases in seaside. It seems to me for something SQL Server aka Enterprise Level to the .NET developer, Gemstone is the way to go in the Smalltalk world to keep things nice and object oriented. My problem is it seems to be impossible to get good info about Gemstone. On the one hand there is all this info about working with Gemstone and Smalltalk, but then I don't see much to download/actually work with it. I know there's all that GLASS stuff supposed to be released, but is it actually available for setup? You mentioned wanting to try it, any luck yet? I looked at MAGMA and others, but I'm not really satisfied.
I guess my hesitation with bringing Smalltalk into my work more is I would hate to consume web services like this (sometimes not possible with my clients and security policies). I know inevitably I'll hit some annoying problems (bad enough with .NET and COM already) like the .NET document encoded web service. What do I need to download/setup to get going with what is available for Gemstone so far? Maybe this is a better question for the gemstone guys, but no help on that front so far. I saw your GLORP implementation and considered it with Postgres, but I'd like to move away from the relational model if I'm going Smalltalk. Any more thoughts? Thanks.
Gemstone isn't currently publicly available, but it's so very very close, they're just finalizing some issues with the Squeak tools and they have a few beta testers banging on it, all seems to be going really well. The coolest part is that you'll basically hook up to the gemstone service with your normal Squeak tools. I think Gemstone will ultimately be the best route, if you can start fresh. Until then, my preferred solution is Glorp and Postgres, which work really well for me so far.
If you really needed to, it wouldn't be too much trouble writing a Glorp driver for the ODBC adapter and connecting to Glorp to Sql Server for legacy stuff. I didn't used to think using ODBC was OK, because if it being single threaded, but this doesn't really matter when you roll out 20 images in a 2 server farm, it'd probably scale OK. Currently I just connect to .Net via web services and that's worked fine for me.
If I had to use relational for legacy Sql Server stuff, if possible, I'd use Glorp and Postgres and just replicated the necessary data between Sql and Postgres, using ODBC against Sql would be the final option.
Gemstone of course is the best solution, nothing can top an ACID compliant Smalltalk image that can scale to thousands of servers without requiring manual partitioning like a Sql cluster would.
Thanks Ramon. I think our view on persistence is more or less the same. I have been toying with GLORP and Postgres and while it's ok, I had hoped to get out of that RDMS box with Smalltalk. I've spent years learning how to tweak the heck out of SQL Server, Oracle, etc. I'm perfectly comfortable writing complex SQL, spending time in query optimizers, doing partitioning, tablespaces, etc., but I feel like it takes up way too much time. I've worked with Python, Ruby, etc. and found most of the frameworks available do nothing for me.
As I am sure you know, everyone wants their software "yesterday." My aim bringing Smalltalk into my work place which is about 90% MS right now (Gold Partner no less) is to save myself as much time as possible while making it interesting to write code again. Frankly I am tired of the select ORM or write stored procedures, then build MVC/MVP framework on top of .NET, then add a million layers of patterns, IOC, etc. It all seems so taped together at this point and it gets to the point where sometimes the code complexity of apps that do essentially nothing astounds me.
Other web frameworks such as Rails seem more of the same to me, especially since they often treat data like a second class citizen (Rails) which is just wrong (data ALWAYS outlives apps, evidence DBs I'm still interfacing with from 20 years ago). Smalltalk with Seaside on the other hand feels so much more interesting to me, but it just seems to need a good kick in the web world as far as widely available and affordable persistence mechanisms that have support behind them. My customers aren't going to start using a persistence engine written by "some guy" no matter how good it is. Furthermore, they need something they can understand. I think the ability to truly save object state with transactions and query for data effectively under heavy loads is going to be awesome.
Yup, sounds like pretty much what I think as well, I'm just waiting patiently for Gemstone to release and give me an out.
Why should anyone support "sql server" only because it is mainstream?
I am against sql server because it does not fit my view of how software should be, but seaside, squeak does. It is a completely different world.
So in the end the whole seaside should be adapeted to all the microsoft way of thinking?
I prefer support for some nice cool databases, let it be via odbc or natively, say mysql, postgres, oracle, firebird.
And of course the oo solutions.
Don'T jump on a microsoft train only because of it's power on the market.
Sorry for my bad english, hopefully someone understands the point
Claudio
As I said in the article, "for a .Net programmer". If you expect to do business in the corporate world, you have to deal with Oracle and SqlServer, period. That doesn't mean I prefer them or like them, I actually prefer Postgres myself for a relational database, mysql sucks. By the way, if you didn't notice, I'm not telling anyone to jump on the Microsoft bandwagon, rather the opposite... I'm giving those on the bandwagon a path out by showing them how to step off it one foot at a time, or did you not notice that this is a Smalltalk blog?
[...] Ramon Leon presents Seaside and SqlServer for the .Net Developer posted at On Smalltalk. [...]