There have been several internal email threads here at Microsoft about how ObjectSpaces will fit into the world of SOA. Below I have included my internal reply to one such post on the subject. Note – my reply is not intended to be a manifesto on the subject, but more a conversation starter.
Posted Question – “How is ObjectSpaces designed to work in a distributed architecture like in SOA architecture? Is it possible today (with the PDC whidvey bits) and how would you do it? The problem in my mind is that the “Object Model” programming idea kind of belongs to client side, but ObjectSpaces seems to be so tightly connected to database so it more or less becomes a server side technique. And also if you use it in server side, it’s not a trivial thing to “serialize/deserialize” ObjectSpaces objects and move them to client and back. You would be more or less forced to use MarshalByRef objects and remoting techniques.
Are there any future plans in this area? Like setting up a “DataAcces Provider Pattern” so that you could build a Service/DA layer of your own and use ObjectSpaces in client side to build a nice object model to use with client side apps?“
My answer –
ObjectSpaces is designed to be a low level component (think DataSet) that allows the user to map their clr objects to a persistence relational datasources. The goal is to replace all of the plumbing code users typically have to write to accomplish this sort of task and to provide data access services (querying, persisting changes, identity management) in terms of the objects and not the underlying relational data store thereby completing the OO abstraction.
I have no doubt in my mind that developers of SOAs will be using relational datasources for persistence storage and in a lot of cases will want to use clr objects for business logic. This is the place where ObjectSpaces can save that developer a significant amount of time and effort. Bottom line, this is plumbing code that a lot of people write by hand today and will have to continue to do so in the future. From the point of view of ObjectSpaces as a data access commodity, the question of “How is ObjectSpaces designed to work in a distributed architecture like in SOA architecture?“ almost becomes absurd as asking the same about the Dataset or even the System.String class.
That said – I believe there are some interesting questions to ask:
1. What happens to ObjectSpaces objects when they cross web service boundaries?
To be an ObjectSpaces object, there is no requirement to implement any interfaces or abstract classes. So in effect, any clr object can be an ObjectSpaces object and thereby is not at all tightly connected to the database. That is, once ObjectSpaces materializes the object the user is free to do what ever they want with the object. In other words, this is the same programming exercise as a typical object remoting scenario and is already solved by a number of features in the frameworks.
2. Will ObjectSpaces provide mechanisms for managing the context (mapping information, change history, object identity) of an ObjectSpaces object traveling between autonomous web services ?
In my opinion, this is where the problem starts to get really interesting. The answer is no and yes. The ObjectSpaces product is not intended to be a distributed object architecture and will not provide any sort of infrastructure to do so. However, a number ObjectSpaces features are designed to facilitate building a distributed architecture which utilizes ObjectSpaces. In fact, the MBF team is doing that very thing. If anyone is interested, I can post some details of what we are working on and thinking of.
3. Will ObjectSpaces work over non-relational data sources, e.g a bunch of web services?
The short answer is no, at least for V1. ObjectSpaces will only work over relational data sources – and at this time the only promised support for V1 is Sql Server 2000 and Yukon. However, this problem space is very interesting and something that has been discussed as possible future plans.