First MTS, Next ObjectSpaces

Published 27 January 04 10:19 AM | despos

Let me say it up front--there's no direct and logical connection between MTS and ObjectSpaces. However, the more I think about ObjectSpaces (and the more comments you post--BTW, thanks a lot and keep them coming), the more I feel that a common pattern exists out of the two distinct and different technologies.

It was around 1997 when Microsoft announced MTS, aka Microsoft Transaction Server. Here's a quote from an old MSJ issue, whom author was the excellent David Chappell

MTS isn't magic, but it does let you write simple, COM-based servers that are still powerful and scalable. MTS provides a range of services to those apps, including thread management, efficient object activation policies, and support for transactions.

The MTS programming style was then summarized in a few ad hoc programming rules. The primary and perhaps unique goal of MTS was helping the developers of multiuser enterprise server applications to focus on their own business logic and problem domain instead of spending time and effort solving interesting but off-topic problems like thread management, security authorization, distributed transactions.

Like many other things in this our imperfect world, MTS was probably no ideal for just everyone. For sure, instead, it helped many people to build better applications, faster. (Hey, sounds like the new Wintellect's payoff.) 

Knowing nuts and guts of your app, you could probably come up with a layer of code not as generic as MTS, but more apt to your particular context, and then (maybe) more performant. You need to invest time for this, but if you started this effort long before the advent of MTS you were more than halfway. In my experience, I've seen multi-tier apps successfully built with MTS, and multi-tier apps built with full success without MTS. I can't remember to have seen apps that had to drop MTS support to work better.

I could have been short-sighted, though. Don't take this statement as absolute truth. Did you see an app that MTS slowed down?

So what's up with ObjectSpaces and what's the common pattern I think it shares with MTS?

ObjectSpaces is being built to help people persisting objects to databases. From your comments, the bottom line seems to be that nobody doubts that an OR/M tool is needed. You seem to doubt that ObjectSpaces is the right one. Two good objections I caught here and there are:

  • The efficiency of the tracking system
  • The quality of the SQL code being used under the hood

The tracking system is being revised and I expect custom classes be required to implement special interfaces in the near future.

ObjectSpaces is young. I don't know about you, but I'm working with the PDC bits, that it less (much less) than a public beta...

Goal of ObjectSpaces is adding no more than 30% of overhead. If you think you can do better in the same time it takes to map tables to classes with ObjectSpaces... If this target is hit, I would recommend ObjectSpaces not just for complex and high-scalable apps but especially for medium and small apps. You come up with an easy to use/maintain (and fast to write) data tier in a snap.

Like MTS, I buy the statement that ObjectSpaces is not great for everybody. But it would probably make life easier for more people than I myself thought two weeks ago.

PS: I believe you can replace the word ObjectSpaces with the name of any other good managed OR/M framework. However, having source code (and a good team of experts) is key in this case.

 

 

Comments

# TrackBack said on January 26, 2004 11:16 PM:
# Ian Griffiths said on January 29, 2004 07:25 AM:

Since you ask, yes, I have worked on a couple of applications that were MTS based, but had to drop MTS in order to perform well enough.

Actually in one case, it was sufficient for them to stop using the MTS transaction support and start managing their own transactions. That was enough to get the performance boost they required. (They didn't actually need distributed transactions. And it's a shame that MTS doesn't support TX flow for local TXs...)

But in the other case, their performance was hammered by having gone down the whole stateless design in the first place. The database just wasn't able to cope with vast amount of extra traffic that a stateless design with highly encapsulated objects will tend to lead to. (And since most of the data these stateless objects retrieved each time they were instantiated only actually changed once a day, it was entirely unnecessary traffic.)

# Kathleen Dollard said on January 29, 2004 11:34 PM:

You'll accept a 30% or greater perf hit for simplicity in programming? Sorry, but I think that's nuts. Not because simplicity in programming isn't valuable - its tremendously valuable - but becuase its unnecessary.

ObjectSpaces, in the last incarnation I saw, was based on dynamic programming - it did extra stuff at runtime. But for almost all of us mapping is an issue resolvable at design time. Thus I think a code generation is a much better model for most of us. I don't claim to have gotten to the bottom of ObjectSpaces, but code generation also seems to offer more flexible models for extending business objects - which I think is a critical element.

I'd love to hear what benefits you see in doing extra stuff at runtime.

# TrackBack said on January 30, 2004 05:55 AM:
# Enrico Sabbadin said on January 30, 2004 06:56 PM:

I'm surprised how opinions may differ according to "personal experiences" :) .. In my opinion code generation is the way to an application maintenance nightmare .. how can you evolve you application with those tons of lines of code casted into stone which fit into the yesterday architecture ?
I just love run time dynamic hooking into routines which evolve over time (you just have to get the comunication interface right) .. and who cares about 30% overhead .. I mean, does it makes any sense if next spring CPU is 30% faster than the current one ?

.. you say : I'd love to hear what benefits you see in doing extra stuff at runtime.
just an example, have a look my latest article at vsm .. I hook validaton routines feeding the DS schema with metadata .. I think it's just more robust and less error prone and simply .. quicker to implement





# Enrico Sabbadin said on January 30, 2004 07:02 PM:

ops .. sorry I forgot

IMHO

# TrackBack said on February 18, 2004 10:00 AM:

Leave a Comment

(required) 
(required) 
(optional)
(required)