Now, Rocky: welcome to the club. That's it...
I have to admit that I followed with joy nearly all of your blog entries surrounding SOA or not-SOA in the last few weeks. But now we have it. That's good.

Now on to the more interesting things: transactions and the like... I think Pat refers to transactions to the classical tx he knows best. But there is more in a SOA world. But maybe more on that later.

In many ways SOA simply explains what happens inside the tiers. Many developers understood tiered designs but they were at a loss to figure out just how to structure the insides of the tiers themselves!

I've always told consultants in my company who were aspiring to jump to the business systems architecture practice to think beyond the classic service boundary limits. Imagine your services as organisms floating on a simplified nervous system (the network), just waiting to receive, process and maybe forward "things", like crude synapses. These organic blobs never touch each other, and they speak using a language that all of them can understand although they're all fundamentally different. The language, the contract and the wire (the transport and packing system; TCP, WSDL and WS-* or SOAP for example) are the only well-known things in this system and everyone has to be fluid in them.

This isolation has many levels and facets, but the important thing is that it exists and is actively enforced.

BUT, the architecture itself (whether we're talking about an enterprise-wide system or a localized one) is a single organism - it's the business. Trust is an ancillary consideration unless you are actually leaving the organism (don't kiss any strangers =) - security is just a desirable side effect of the isolation because the protocols often require it.

I've seen too many designs (especially in the integration space) hobbled and crippled by too much security. Yes, you *can* have too much security... or rather you can fall into institutional paranoia very easily.

Isn't SOA just Cobol over the internet?