David Pallmann of Neudesic responded to my comment that “Physically distributed but logically centralized” didn’t make any sense to me at all:

What exactly does this mean? To some this may sound like a contradiction.

This simply means that a bus is physically more like the point-to-point architecture (spread out, no hub) but functionally more like the hub-and-spoke architecture (pub-sub messaging, centralized configuration and activity tracking, easy change management).

Unfortunately, I wasn’t confused about the seeming contradictory nature of these concepts. In other words, I understand the “what” and “how” of David’s physically distributed/logically centralized approach.

I don’t understand the “why”. As in, “why would you want to do this?” or “why do you think this would work at any significant scale?”.

If we check out Neudesic’s page on their ESB product (which David pointed me to) we find the following blurb:

Centralized Management
The distributed nature of service oriented programming can create a management nightmare. Neuron·ESB supports this distributed architecture while simultaneously centralizing monitoring and configuration.

SOA’s “distributed nature” is it’s primary strength. SOA’s not primarily about standards or ease-of-connectivity – though those obviously play a role. It’s about enabling decentralized decision making. Since you can’t be both centralized and decentralized, enforcing centralized management basically negates SOA’s primary strength. This seems like the worst of both worlds to me. All the hassle of distributed decision making combined with all the hassle of centralized management.

Yes, decentralized decision making can create a management nightmare. Personally, a management nightmare is much more attractive anything centralized approaches have ever delivered in the IT industry.

Dare Obasanjo recently wrote “If You Fight the Web, You Will Lose“. He was talking about the Web as a Platform, but it’s good general advice. Can you imagine applying the marketing blurb above to the Internet at large?

Centralized Management
The distributed nature of service oriented programming the Internet can create a management nightmare. Neuron·ESB supports this distributed architecture while simultaneously centralizing monitoring and configuration.

If the Internet can somehow get by without centralized management, why can’t you?

• Doing these morning coffee posts is a lot tougher since I cut back my blog reading. Where I used to have no trouble finding 4-5 coffee-worthy items every day, these days I seem to only get 1-2, if that.
• After starting off 3-0 and 100% on the PK, the Caps dropped four in a row and have been miserable on special teams. The special teams woes continued last night against the Lightning, but they still won. Caps went 0-4 on the powerplay, and coughed up a short handed goal. But they also went 3-3 on the PK, so I guess it wasn’t all bad. Maybe my mother will stop calling for Hanlon’s job now. It’s a long season and as Peerless Prognosticator points out, the rebuild isn’t over.
• Jomo Fisher, who helped Scott Hanselman auto-merge assemblies, has been digging around in F# of late. As it turns out, he’s joining the F# team so I’m thinking it’s not a huge stretch for him. If you’re a C# developer trying interested in getting a handle on this new F# thing, his blog is a good place to start.
• Speaking of F#, Don Syme posts about yet another new F# feature: Async Workflows. Workflow is a bad term here IMO since it can be easily confused with WF. Regardless of it’s name, Async Workflows is about making .NET’s Async Programming model a first class citizen in F#. Robert Pickering has a good post explaining how this new feature works.
• Microsoft sure has a lot of multi-threading / async-programming tools coming out. In addition to F# Async Workflows, there’s the Concurrency and Coordination Runtime, Parallel LINQ and the Task Parallel Library. I would hope all this work eventually coalesces as a coherent product offering.
• Now that F# is being “producized”, I wonder if the language evolution will slow down. Async workflows were introduced in F# 1.9.2.9. Other recent changes include Computation Expressions (v1.9.2), Use Bindings (v1.9.2) and Active Patterns (v1.9.1). F# seems to churn more in minor releases than C# does in major releases. Of course, that’s because F# was a research project, not a “real” product. Now that it’s going to be a product, will the rate of innovation slow?