My friend Bill points out that ObjectSpaces has been delayed until Longhorn. I could be wrong, but I sense the initial enthusiasm for ObjectSpaces is waning. So now I’m pondering:

Do we need O/R mappers anymore? Did we ever?

At the risk of sounding like someone who thinks SOA will solve all of the world’s problems, I want to spend some time testing the following hypothesis:

Does a service-oriented architecture diminish the need for an O/R mapper?

SOA changes not only the way we build our back-end services, but also the way we build our front-ends. In a recent conversation with Rocky Lhotka, he made the point that in an SOA, the client and the service are really separate applications – separated by a trust boundary. He also pointed out that invoking a service is a lot like invoking a stored procedure: 1) construct a request by filling in some parameters, 2) invoke a named operation, and 3) handle the response.

Clemens has posted recently about something he calls data services. In short, he makes the case for accessing your data through a service.

Continuing these thoughts, I’m now asking, “Can a service be akin to a smarter stored procedure?” If you look at it this way, you can write your ‘stored procedures’ in C# without Yukon

In an SOA, the client has its own layers (presentation, business, data) as does the service. But the client’s data layer does not necessarily connect to a database, It might just connect to a service. This gets to my reasons for asking whether we need O/R mappers:

·       The client’s business layer no longer needs to map to a relational database. Instead, it needs to map to service requests and responses.

·       If the service itself is a ‘smarter stored procedure’, does it need a rich domain model? If not, it doesn’t need to map this domain model to a relational model.

I’m writing more questions than answers in this post, but here’s one more:

·       If we really needed O/R mappers, wouldn’t we already have them? Yes, I know a number of vendors already sell O/R mappers, but if they were so vital, wouldn’t they be built into the fabric of every platform by now? I mean, saving objects into a relational database is something we’ve been doing for a long time. If O/R mappers were really the answer, wouldn’t this be a solved problem by now?

I’ve seen a lot of procedural code written in an object-oriented language. Particularly, I’ve seen this done with C++ in the days when object-oriented design was first gaining familiarity in industry. I attribute this to the fact that most of us C++ programmers were first C programmers. We wedged our old design approach (procedural programming) into a new programming model (object-orientation).

I suspect we’ll see an analogous situation with service-oriented architectures. In fact, I’m beginning to see it already. It is possible to construct a service-oriented system with currently available technology. But technology isn’t our biggest roadblock, our experience is. We must design differently if we expect our SOA to work.

As a software engineer who was once inexperienced with object-oriented design, I could still understand encapsulation. But until I’d built a non-trivial system that made good use of object-oriented principles, I could not appreciate encapsulation. There is an indescribable pleasure that comes from being able to modify part of your software while having the rest of it go on working beautifully. It’s the result of encapsulation and it’s also a bit of a high. And the pursuit of my next fix is what drives me to apply object-oriented principles with all the more rigor.

In the short-term, it’s usually more work to do the right thing. It’s not easy to find the right abstraction or to make the right design trade-off. It’s faster and easier to just write some code that solves the problem at hand. But I work hard at finding that abstraction because I know in six or twelve months, I’ll be glad I did. I know this from my own experience. Without this experience, I might say, “Why bother?”

As practitioners, we’re at a point with SOA where many of us were with OO about 10-15 years ago. We understand the tenets of SOA, but we don’t yet appreciate the benefits. And until we do, we won’t choose to incur the cost.