"Schneider... you ignorant slut!"

Like every other morning... I woke up, made coffee and read my emails. One email caught my attention; it was titled, "Schneider... you ignorant slut". Clearly, this one deserved immediate attention :-) Yes, it was another 'anonymous' WS-CTO laughing at me for getting BlogSlapped by Jef Newsome.

Well, I thought I was going to make it all the way through 2004 without a good whipping. Thank God for people like Jef. Block, block, kick, block, punch... here we go...
======================
Jeff said: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed."

Jef commented: "Boundaries are explicit" is about the fact that you can't see what kind of underpants I am wearing."

Agreed. To me a 'contract' is a combination of the interface and the policies. The contract should black box both functional and non-functional requirements. The failure to block box non-functional requirements was the limiting force of components and the primary driver to move to services. However, neither of us answered the "boundaries are explicit, except for predicates" problem. (Not that I expect us to, but people like MS can't just punt on it either.)
=======================
Jef commented: "I have absolutely no idea what "Runtime changes to code dependencies are NOT allowed" has to do with explicitness of boundaries. In my estimation, nothing. I can think of a number of ways that runtime code dependencies could change in the context of a service oriented system, and everything would be just fine."

It was an example of a constraint - perhaps a bad example, but an example of a constraint. My point was that we need a constraint based description language for the architecture; I wasn't really trying to write the architectural constraint language. The constraints will be probably number in the hundreds, not four or six. That was my real point.
======================
Jef says, "I believe that services *should* be autonomous, that their implementation dependency on other services is an implementation detail (because boundaries are explicit), and part of the responsibility of an autonomous service is to gracefully degrade service when its dependencies have availability or other issues."

It sounds like you believe that a service is autonomous as long as the 'boundaries are explicit' rule is enforced; if that is the case, then this is a duplicate rule and we should remove it. I'm game. I've been game - it sends the wrong message.

I firmly believe that enterprises will eventually be required to migrate to Model 4 services. Yes, their boundaries will be explicit, but their lack of sovereignty or self governance will be more significant. Services will NOT be viewed as single individual entities, but as ecosystems of contracts that need to migrate together.

As we move from noun-first programming to verb-first, we find ourselves dealing with "cross-cutting subjects" (not concerns) that have to be dealt with as a group. What I have found is that the 'verb' holds still while everything else changes (noun, adjective, predicate, context). This isn't to say that you can't have autonomous services; you can. However, I don't believe this approach will work from an economic perspective. I'm probably talking more about the 'development-time' aspect of autonomy than the runtime aspect; however after re-reading the MS description, I have no idea what they were talking about. Their description is largely just a bunch of mumbo-jumbo. They mixed a half dozen concepts under this one tenet that largely don't even relate to each other. If you want to turn "services are autonomous" into a set of constraints, I'd love to see them.

======================
Jef: And I trust he can explain what he means in a way that someone as simple as me can understand. I hope he does, because I don't get it.

My goal isn't to explain it in the simplest fashion, but in the most precise fashion. I want to take the current state of WS-MumboJumbo and bring clarity via a set of constraints. A tenet should be a set of constraints rolled together to satisfy a high-level architectural requirement. Walking into the next paradigm of computing without constraint based design practices is silly, insulting and financially dangerous.