Musing on Object Spaces

I just read a blog thinking about the relation of the as yet unreleased ObjectSpaces api from Microsoft and how it applies to distributed objects. It made me feel out of step with what I now regard as (my) old thinking about how object oriented programming applies to the kinds of programming I do most often, web sites and business integration. First, on ObjectSpaces.

I have to say that both the scheduled talks and the private talks with MS folks about object spaces at the PDC left me wanting. Let's be very clear here. ObjectSpaces is a long ways from being ready as a real live tool. It could change in many ways before it's released. But here are some things I observed.

• It's tied to Sql Server. As the maintainer of the SnapDAL project at SourceForge, I think this was an OK tactical move but a lousy design choice. The reason is that unless the architecture planned well for other databases, it will be much harder to change later. And since MS is pretty tied to Sql Server, I can't see that they would have a lot of incentive to offer other choices, nor could I blame them. Time will tell on this point.
• The object query language is actually implemented in SQL. This one seems like too big of an oversight to have made it that far into the development.  This bothers me most because you have to leave your own process to execute the query, and usually have to leave the maching you're on. That has some potential implications for distributed objects as well. 
• Forgetting the issue of the SQL queries and distributed objects, every time you do a query on your collection, it will have to go to the database and rebuild the whole collection again. So, if the structure of your domain model can't locate the entities you need, you get to throw out your live collections and rebuild. There will be some queries, as I understood it, that this may not be true for, but this is the basic implementation.
• There is some clever behind the scenes work going on in ObjectSpaces to keep track of  “dirty“ objects in your collections.  Since you don't have to implement any sort of interface to put your objects into a ObjectSpaces persistence scheme, it means that only at the time that your code says persist, would it have a chance to figure out which objects have changed.  Think about that. The persist code will have to keep a separate original copy, or go back to the database, and compare to determine which objects are dirty. When talking to one of the MS folks mannng the ObjectSpaces area in the lounge after the presentation, he agreed that this may well be how it works, but wasn't sure. I hope I'm wrong. I want to be wrong, because that seems absolutely deadly to any sort of scalable application written with ObjectSpaces. On the other hand, since your objects themselves have no way to tell the infrastructure that they're dirty, I haven't been able to come up with an alternative.
• That your entities don't have to implement an abstract class (very bad), an interface (lots of factory methods required) or contain a reference to the framework are all great design goals. I just worry that the cost will be to high.
• ObjectSpaces comes at a time when many in the .net world are absolutely drooling for tools like this, many of whom have come from other language and tool set backgrounds. EJB, TopLink, SmallTalk etc.. But ObjectSpaces appears to me to have a much smaller problem domain in mind, and probably the right problem domain. As the earlier mentioned blog points out, ObjectSpaces is supposed to be buried in your application or service layer code. But, for those interested in persistence frameworks, I think that ObjectSpaces will leave them feeling shorted.  For those new to the idea, it may be a simple and elegant tool, providing that issues of scalability are addressed.

Finally, I have to say that I have come to the point of view that transparent object persistence is probably not that important. I think, as is mentioned in Fowler's book on enterprise development, that domain models in reality are domain models within application boundaries. In my current work, I have an api layer, with a somewhat anemic domain model shared between many different applications.  But the ugly truth is that, between applications, and absolutely between enterprises, requirements are different, and as a result the domains models look different. In my applications, which have to encapsulate how individuals, companies, brokers, mutual fund companies, retirement plan administrators and trading intermediaries look at the simple domain concept of a “transaction, there are major differences.  Yet, they share a lot of data. And, the data I'm working with now has survived four programming languages and three databases. As a result, the idea of a domain model is reduced in importance. The correlary: transparent object persistence maybe is less important as each domain model is reduced in scope and size.