|
Loose coupling and data integrity
Patrick Logan has written an excellent riff on my essay on loose coupling. He bravely points out that maybe the emperor has no clothes:
What is loose coupling in an enterprise information system? The term is often used without any definition at all. Its meaning is supposed to be obvious and you're supposed to act as if you know it. Often it just seems to mean "goodness itself". [Patrick Logan]
I agree we need more explicit definitions. Patrick makes a great start. He defines the term in a number of useful ways, and -- very importantly -- talks about the costs of different kinds of loose coupling. I'll add one to the list: the cost of maintaining data consistency and integrity.
In an intertwingular way, this relates to another of Patrick's items that caught my eye. He called it "Poster Child for Shared Nothing Message Passing." I might have entitled it "Multithreading Considered Harmful":
A beginner's guide to threading in C# [Sam Gentile's Radio Weblog]
The guys who invented shared-memory multi-threading in the late 60s, early 70s discovered these problems early on. Which is why they went on to develop higher-level, shared-nothing mechanisms in the mid/late 70s.
Why Java and subsequently dotNET adopted this troublesome 1960s technology at the core of their architecture is curious if the intent is an efficient but widely applicable language for developing concurrent Internet applications.
It's like managing your own memory allocation, only worse. [Patrick Logan]
Peter Drayton, meanwhile, has a different take on the "beginner's guide to threading" that Sam and Patrick refer to:
For an article aimed at beginners, why on earth is it suggesting use of the Thread class over one of the other threadpool-serviced mechanisms such as async delegates, one of the three (yes, three!) timers in the FCL, or the ThreadPool class? [Peter Drayton]
This notion of asynchronous delegation seems to map well to the loose coupling design pattern. But it's not, so far as I can see, the kind of shared-nothing style that Patrick mentions. At this level, in .NET, thread safety still seems to be an issue, e.g.:
The runtime ensures that there is a separate thread to make the call and provides synchronization objects to allow your calling code to test when the call has completed. Asynchronous calls involve multithreaded code, so you need to take this into account when passing shared object references. [MSDN Magazine]
In Java, asynch delegation happens further up the stack, in JMS, and so would qualify (I guess) as a shared-nothing style. The best Microsoft analog here might be COM+ events.
All this leaves me wondering whether web service orchestration, which is one of the prime motivations for the loosely-coupled design pattern, will:
- find native programming language support (and if so how, and at what level)
- be expressed outside programming languages (e.g., in XLANG, WSFL, or a successor)
- combine both of these techniques
Is Edwin Khodabakchian right to suggest that this event-driven asynchronous loosely-coupled style is -- when enacted at Internet scale -- fundamentally new? Or is Patrick Logan right to suggest that there's nothing new under the sun, and it's just a matter of adapting known patterns to new conditions?
In my usual contradictory way I think they are both right.
9:11:31 AM 
|
