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.


4 responses to “Musing on Object Spaces

  1. Philip,

    Can you elaborate a bit on your second point, about the query langauge, OPath, being implemented in SQL? I’m not sure I understand where you’re coming from on that one and I don’t think you’re assesment is correct based on the content of the bullet-point.

    I haven’t completely dissected ObjectSpaces yet, but I’m pretty certain that, like any good ORM framework, it will execute the OPath query against the in-memory store, as long as the query addresses a unique field, before executing against the underlying data store. Perhaps you’ve dug through the IL a bit more though and can point me at where exactly this fails to take place.



  2. I agree, I would have expected the same thing about how OPath would be implemented. The fact that it was implemented in SQL came from the presentation at the PDC, and I haven’t verified it other talking to somebody at the table in one of the PDC lounges afterwords. What would take some more diving would be to find out when it would use the object store and when it would jump to sql.

    If somebody has other information, that would be great to find out.

  3. I don’t understand your concern about detecting dirtyness. When it is time to persist, you compare the original values of the the object to the current values. If there is no difference then there is no reason to hit the database. Otherwise you attempt an update and report any optimistic concurrency violations. This a basic function of ObjectContext.

  4. On the concern about dirtyness. If ObjectSpaces has to detect changes rather than be notified of changes, it will have to keep a copy of the entire object graph to compare against, or go to the database to compare against original values, or perhaps do something like a hash of the original values. In any case, there will have to be a traversal of the entire object graph. That is expensive, but survivable. If ObjectSpaces keeps a copy of the whole graph, then whatever memory the collection takes, will be doubled. If it has to go to the database, there is a considerable hit to retreive all the data. If it is a hash comparison or something like it, there is still the memory used by the copy. Think about that on a collection of millions of objects.

    I’m just hoping that ObjectSpaces is smarter than any of these options.