Ram blogs on abstraction and Simon blogs on intimacy of SOA vs. OO. Here are my two cents on control and process of SOA vs. OO.

I came across this blog entry by Michael Santos who wants to stop the hype about web services. I forwarded his post to my entire team. I feel that it represents the typical old-school, 20th-century, industrial-revolution, application-centric mindset that we encounter regularly when discussing XML Web Services. He talks a lot about using binary protocols instead of XML because of performance. What’s interesting is that his over-focus on performance leads down a path to tight coupling (or intimacy as Simon called it).

So, maybe you intend to keep your systems loosely coupled. I understand that. But let me ask you…Should they be loosely coupled in first place? Sometimes two systems are so tightly coupled that they should be just one system, to begin with. This usually happens in big companies, where political reasons force two groups to buy two solutions from two different vendors to solve two parts of the same indivisible problem that cannot be addressed separately. [Michael Santos : Stop the hype about webservices!]

The thing is, there is no such thing as the “indivisible problem” in the enterprise. Enterprises don’t solve problems per se, they execute business processes. Developers tend to think in terms of nouns, which map nicely to objects, while business people tend to think in terms of verbs. For example, taking the canonical order processing scenario, the developer sees a single object – the order. Business people see the processes that surround that order – placing it, fulfilling it, paying for it. Typically, the developer sees these processes as methods: Order.Place(), Order.Fulfill(), Order.ProcessPayment(). However, these business processes don’t represent things the business object is doing, rather things being done to the business object. It’s a subtle difference, but it’s very important.

In Ivar Jacobson’s Object-Oriented Software Engineering, he talks about how over time objects tend to evolve to have methods that are only used in a single use case. He separated the concepts of the “entity” object – which represents a business object that has persistent state – and the “control” object  – which represents a process that modifies the state of one or more entities. (Note, control objects in this context are different from the controller object in the MVC pattern). In my experience, mapping use cases to control objects is a good first order approximation of your final system design.

However, implementing controls and entities with objects implies an intimate relationship as part of a single autonomous system. In practice, this is very difficult to maintain over time. First off, it’s a bad model of reality. Going back to the order processing scenario, different departments and people are responsible for executing the “fulfill order” and “process order payment” business processes. The departments don’t have an intimate relationship for good reasons, like trust and security. Those reasons should be reflected in the code. Secondly, business process changes much more often than business entities. You never know when you’ll want to change a step, modify the order of steps or completely rethink the process in the face of market and / or technology changes. In other words, you want the connections between the processes and the entities to be loosely coupled. If you tightly couple everything together, then you’ll need to change everything every time something changes. This leads to a stagnation that a customer of mine once compared this to carrying a big pile of cow manure – once you put it down, you don’t want to pick it back up!

If you step back from the OO mindset, you can model controls and entities in terms services pretty effectively. At PDC, we discussed the idea of resource vs. activity oriented data and the idea of service-masters vs. service-agents. These ideas are very similar conceptually to the control / entity separation. Control objects become business process services (also known as service agents or sometimes emissaries). However, when using services instead of objects, you gain power and flexibility that you just don’t get from the OO model.

I found this interview with the BEA deputy CTO Benjamin Renaud via a news post on TSS.NET. BEA’s position is summed up in the following quote:

“Microsoft will standardise at the protocol level, but they won’t standardise at the API level,” he said. “Customers are not that gullible. The real level where integration happens is at the programming level.”

I like Ted’s response to this:

We’re sorry, Mr. Renaud, but integration isn’t necessarily what web services are after–interoperability, in the form of loosely coupled components that know how to exchange messages of data, are the key to truly powerful web services. If you want programmatic integration, you have to standabrdize on programming platform and language, and that’s not what web services were supposed to be for.

As to his complaint that Microsoft is engaged in a huge bait-and-switch, we believe he’s either not putting enough faith in the development community to see this conspiracy, or else he’s trying to cry foul over the fact that BEA has to compete with others in the Java space for the web services dollar, where Microsoft stands relatively alone.

However, I’m not sure what Ted’s driving at with his interop vs. integration argument. To me, they seem to go hand in hand – two great tastes that taste great together. Web services are important for both. If I’m not integrating disparate systems, I probably don’t care about interop that much.

Personally, I care much more about integration than interop. Even if I was going to build a system-of-systems all using only .NET technology, I would still use a service-oriented approach and implement those services using web service technology. The service-oriented approach allows me to be more flexible in the way I stitch my services together. Using web service technology allows me to leverage platform technology (ASMX, WSE, Indigo, etc) so I don’t have to roll the whole stack myself. The fact that I get interop “for free” by using this approach is an extra bonus that I don’t really care much about – at first. That built-in interop, even in this single-platform-which-never-happens-in-the-real-world scenario, helps make my systems future-resistant (nothing is future-proof). New customers, new partners, mergers – come what may, I have a better-than-average chance of being able to integrate it into my system. That gives me an real advantage ($$$) in the marketplace.

Of course, back in the real-world where you’re creating a system-of-systems from a series of stand-alone systems that are all built with different platforms, interop is much more important. But that doesn’t mean integration is any less important.

After reading Sam’s slides on Atom, Scoble posted three times about how syndication could evolve. Of course, Scoble has his Longhorn-colored glasses on. Dare pointed out that “The major problems with syndication today have little to do with the syndication format and more to do with it’s associated technologies.” I agree with Dare. IMO, the only thing that the ATOM syndication format has over RSS is a namespace declaration. I care about that because one of the “associated technologies” I care about is SOAP and the lack of an RSS namespace makes it hard to embed an RSS item inside a SOAP message.

I think Scoble should be asking how syndication will evolve in the face of Service Oriented Architecture in general, not Longhorn specifically. Granted, Indigo is going to make Longhorn a great platform for SOA. (If you check out the Longhorn Interoperability and Migration Guide, Chapter 2 is mostly dedicated to describing SOA.) But I think the real change to syndication is going to come from WS-ReliableMessaging. In order to truly evolve syndication, I think we need to break free of the synchronous polling model we have today. Polling only works in scenarios with a central syndication source (like a weblog). However, as the sources of syndicated content get to be more distributed (phones, P2P networks, etc) that polling model breaks down. I need to be able to send messages when things change without regard to network availability. With WS-RM, I can send messages and the infrastructure (i.e. Indigo) can take care of the ugly details of making sure the messages get delivered to their final destination.

SQL Service Broker is probably the least known new feature of SQL Server “Yukon”, but I can’t wait for it. It makes messages a first class object in the database. If you’ve ever had multiple processes banging on your database or you’ve ever used a flag on a row to indicate if it’s been processed or not, you want SQL Service Broker too.

While there is huge disagreement as to exactly what “Service-Oriented Architecture” is, I think there is some general consensus around the fact that it is an asynchronous message driven model rather than a synchronous RPC model. This means that the thread you receive a message on will never be the same thread that you process the message on. In fact, typically you will write the message to a persistent data store (hello, Yukon native XML support) in order to be handled by a thread in a different process and probably on a different machine. Today, kicking off the thread to handle the message is a pain in the ass. You probably want lots of threads across lots of machines to handle the incoming messages (assuming you’re getting lots of incoming messages). In order to synchronize message processing across machines, you need a mechanism to make sure each incoming message is handled once and only once. Today, the closest solution is message queue technology like MSMQ (or MQSeries). However, since that’s a different data store from where the data lives (i.e. the database), now you need two phase distributed transactions to get that done. However, since messaging is going to be such a huge piece of architecture going forward, it makes sense to have the concept of messages baked right into the database.

With Service Broker, when the message is received, it is placed into a service broker queue. (It’ll probably get stored for archival and retry avoidance reasons, but that’s a different blog entry.) Now I can have processes that, within the scope of a local transaction, receive the incoming message, make whatever data changes that message implies and send off any new messages. This is both more productive (manually handling local transactions for async processing is this kind of a scenario much easier than using serviced components) as well as more performant.