Partager via

ObjectSpaces in an SOA world

  • Article

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.

Comments

  • Anonymous
    December 12, 2003
    About 1) I don't think you'll be able to use the same CLR ObjectSpaces-mapped objects as WebServices parameters, and it's because of the object-loading issues.

    If you use delayed loading, then your CLR object is not really as simple as any CLR object, because of the ObjectList/ObjectHolder thing.

    If you don't use delayed loading, then you are in danger of sending an uncomplete object (with null references for not-loaded data) or a very big object graph.

    For exchanging data in a SO-world you will probably have a different set of classes that will aggregate data from different classes from your ObjectSpaces-mapped model. This means that there will be another 'mapping layer' between your ObjectSpaces classes and your SO classes.



  • Anonymous
    December 12, 2003
    I like this, pretty key point:

    "The ObjectSpaces product is not intended to be a distributed object architecture."

    I believe the confusion over this probably comes from the fact that so often a persistence framework is bundled with a distributed object framework...

    For example, its so common to inherit from a single base class that provides all this infrastructure... Perhaps this is a key reason why ObjectSpaces doesn't require subclassing? It seems as flexible as possible to integrate with other frameworks..

    Oh, I'd be very interested in seeing what the MBF team is doing related to ObjectSpaces support for distributed architectures...





  • Anonymous
    December 12, 2003
    Also see the thread about this in the Objectspaces newsgroup on the Microsoft server, with some spin-off thread about and featuring mr. Fowler himself :)
  • Anonymous
    December 12, 2003
    In my opinion it would be quite dispappointing if OS would not fit in an SOA. Ofcourse using delayed loading would not make sense in a webservice scenario. I agree sending uncomplete objects is not nice, but at this point that's the only issue I see at this point?

    I'd love to hear more on this subject.
  • Anonymous
    December 12, 2003
    O/R Mapping and Web Services fill very different roles. O/R is used within an application to get the effect of a persistent heap . The key thing to remember is that web services, or multi-application architectures built around web services for inter-application communication (SOA being the term du jour for that) are about application communication.

    Web services, or any other service (I get a feeling from .Net bloggers that Service == Web Service in their eyes) are just coarse grained mechanisms for IPC across machine boundaries without knowing or caring about the client (or endpoint) platform. They are for communication between applications, not fine grained control. The same type of thing you have been using MOM for except synchronous.

    Within the application boundary O/R mapping allows you to keep your domain logic and persistence logic more cleanly seperated. A good O/R tool (I haven't played with ObjectSpaces -- anyone want to donate a VS.Net or MSDN license to me so I can try it?) is designed to allow you to seperare persistence concerns from domain concerns. These are concerns within the application, not concerns to clients of the application (me on a web browser, you on a fat client, or another application via an exposed web service).

    -Brian
  • Anonymous
    December 12, 2003
    The comment has been removed
  • Anonymous
    December 12, 2003
    So how does ObjectSpaces support distributed architecture? Would that be ValueRecord?
  • Anonymous
    December 12, 2003
    In the Enterprise Objects Framework and WebObjects when you pass an EO (Enterprise Object) into or out of a web service the service is actually passing around the object's EOGlobalID. This is actually a true global identifier for an object that can act as a token for the object in a distributed system. The reason is the same reason it's simple to get an object locally given its EOGlobalID - it contains the object's entity name and primary key attributes. (In other words, an EOGlobalID is derivable from and fully identifies an object, it isn't a mapping.)

    ObjectSpaces looks like it's modeled on the original Enterprise Objects Framework (ten or so years old at this point), so the same technique could probably be used. I'm not sure whether ObjectSpaces supports any sort of global ID for an object though.
  • Anonymous
    December 12, 2003
    Chris,

    I think the mechanics of that might be tricky in a non-message-passing environment. Auto generating proxies could probably do it, but... Ruby.NET?

    -Brian
  • Anonymous
    December 15, 2003
    I hadn't written about my reaction to ObjectSpaces at the PDC, and a recent blog made me think of it again.