Matt Terski's Blog

Is O/R Mapping Necessary Anymore?

Tue, 25 May 2004 03:29:01 GMT

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?

Service-Oriented Architecture Misnamed?

Thu, 20 May 2004 21:35:53 GMT

You read it here first: The term service-oriented architecture shall be renamed to message-oriented architecture. SOA shall become MOA.

Well, not really. It won’t happen, even though it should.

The entire point of SOA is to achieve loose coupling between applications. That’s it. Loose coupling.

But that loose coupling has important second-order effects. It allows applications to evolve independently. It allows applications to scale independently. It allows applications to change deployment models independently. All without breaking one another.

As many have rightly pointed out, this goodness comes at a price: The only way to talk to a “service-oriented” application is to send it a message. You don’t get to see its types. You don’t know where it is really executing. You get to send it a message. It might send you a message in reply.

So, shouldn’t we call it, “Message-Oriented Architecture?”

Gaining an Appreciation of SOA

Mon, 29 Mar 2004 03:28:54 GMT

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.

Are the Principles of SOA New?

Sun, 21 Mar 2004 21:05:53 GMT

I love Pat Helland. The guy is a luminary. He explains the issue of latency in service-oriented architectures with an analogy of light traveling from the sun to the earth. By the time the sunlight shines on us, it is eight minutes old. So it might not reflect the current state of the sun (the sun might've blown up during this time, for example).

Likewise, by the time we receive a piece of data from a service, it might have changed at the source. But unlike sunlight, messaging in service-oriented architectures is often two-way. If the data we requested was changed before our response gets processed, our response is probably invalid. And that's life; our system has to deal with it. Of course, this problem is not new. It's a common side effect of optimistic-concurrency.

But making the pronouncement that "SOA is like the Night Sky…" is sure way to stoke your critics. And old Pat takes a bit of heat in his comments for re-branding old ideas. SOA is currently going through the negative hype phase common to any paradigm shift in software development.

Since I'm currently enamoured with SOA, I pulled my copy of Principles of Transaction Processing off the shelf to check how much of SOA was actually covered in 1997. It comes down to this: many (but not all) principles of service-oriented architectures are a subset of transaction processing principles. Specifically, they are the principles of queued transaction processing.

In an SOA, transactions do not span services. That is, there are no distributed transactions. But for a system comprised of a collection of services, a logical unit of work will often use more than one service. So how do we perform a logical unit of work in two or more services without using a distributed transaction? The answer is queuing. Queues allow us to perform a unit of work that includes more than one transaction (a multi-transaction workflow).

With queues, an SOA forgoes atomicity and isolation (two of the ACID properties) to gain scalability and reliability.

So it's a tradeoff. In Pat's defense, these concepts are not entirely new, but this is not a tradeoff many of us would have considered as we designed our systems and made the obligatory genuflection to the altar of ACID transactions. But as he says, "it's the only possible computing model in a loosely-coupled and distributed world."