SOA: Better Cardboard Delivery!
Have you seen this before? Your architects understand the mechanism that allow services to operate. They get service buses, registries, data service, etc. but when it comes to data, they simply throw the responsibility to the database team. In my opinion, they’re making a big mistake. SOA is not about moving data around the same what a network moves packets. In other words, packets do not equal messages.
Pat Helland thought about this quite a bit. In his presentation “Thoughts on Messages, Data, and Business Process in a Service Oriented Architecture,” he talks about the difference between messages and data. In fact he breaks it down into four specific types of data:
- Request/Response
- Reference Data
- Activity Oriented Data
- Resource Orientated Data
To focus on one aspect of Pat’s presentation, Activity Oriented Data represents the messages that flow within a SOA. In Pat’s “Metropolis” presentation, he refers to XML as cardboard because it wraps up the data into a safe package. This analogy would explain the ubiquity of XML and why it’s so important to SOA.
If you look deeper into Pat’s “Thoughts on Messages…” presentation you’ll see that XML doesn’t work for every single situation (he said this in 2003, I’m surprised he wasn’t shot) and that means that designing a canonical form of data for SOA is not the same as designing a database. So why would an architect ignore such an important aspect of architecture?
I’ll draw the line in the sand and guess that for all the emphasis that is put on XML, architects don’t understand the XML related technologies. XML Schema, WSDL, the WS-Security and WS-* present a real steep learning curve. I’ll also add that REST doesn’t make this any easier than WS-*. REST ans WS-* both require that you understand the data you’re dealing with, more specifically the activity oriented data.
Dan Pritchett points out the fallacy of ignoring the data requirements when implementing services in his blog post “A Real eBay Architect Analyzes Part 3”
“…state style interactions [REST] can actually lead to lower levels of efficiency in the implementation. When a client makes an imperative statement like CompleteSale, we are completely clear on the intent of the operation…But if the client passes back an Item (which consists of over 200 state elements) with some state changed, the first task we have to perform is determining the state transition. This will involve retrieving the item and potentially other state in the system. All of this is a precursor necessary to determine intent. This certainly increases the resource requirements.”
In my own words, ignoring your data will not help you scale regardless of REST vs WS-*. Keep an eye on the data that is being sent across the SOA and won’t regret it because the shape of the data matters.