Re: Object-relational impedence

On Mar 14, 5:59 pm, David BL <davi..._at_iinet.net.au> wrote:
>
> - the impossibility of reliable distributed transactions

Are they actually impossible? I know that distributed consensus is impossible; Byzantine generals and all. I know little about transactions, but my vague impression was that 2PC was stronger than just an illusion.

> - the fact that synchronous messages over the wire can easily
> be a million times slower than in-process calls

This is *crucial.*

> - the fallibility of distributed synchronous messages which
> contradicts location transparency

This is manageable when you combine synchronous and asynchronous messaging. Synchronous idempotent messaging that does not depend on the identity of the receiver is actually pretty easy; asynchronous messaging should handle as much as possible. Synchronous messaging that does depend on the identity of the receiver should be kept to an absolute minimum, and has to be tolerant of failure. The guidelines I just described might exclude certain classes of applications (I'm not certain) but many, many things can be done this way.

Location transparency as a practical reality is achievable and in fact absolutely tits when done well.

> - how to schema evolve a distributed OO system assuming
> orthogonal persistence and location transparency.

This is one of the things that convinces me of the superiority of structural type systems for distributed computing. My expectation is that languages are going to face evolutionary pressure in the direction of features that are distributed- and multi-core- friendly.

Schema evolution for nominally typed languages has proven to be quite brittle. I am not convinced it is *necessarily* so, but it begins to look like it.

> SOA suggests that a large system should be decomposed by behaviour (ie
> "services") which is basically an OO way of thinking. It is a flawed
> approach to the extent that it is promoted as the main way to build
> enterprise systems. The only proven scalable approach is to remain
> data-centric at ever increasing scales.

Mmmm, I mostly agree but maybe you said it a bit too strong. Datacenter-services as an approach works okay, and even scales, provided you don't need much flexibility and can keep clients and servers closely coupled. Okay come to think of it that's a pretty bad situation to be in. I changed my mind: you have a good point.

> The WWW is data-centric. It is not at all surprising that Http on
> port 80 is *much* more common than RPC, CORBA, DCOM, RMI and SOAP put
> together. Http concerns messages used to access data instead of
> messages used to elicit behaviour.

Interesting point.

My high-level viewpoint: two important success factors for distributed computing turn out to be<drumroll>: logical independence and physical independence, at the (network) protocol level!

Surprise!

(I apologize for the buzzword-density of this post.)

Marshall Received on Sat Mar 15 2008 - 04:14:26 CET