Re: Object-relational impedence
From: Yagotta B. Kidding <ybk_at_mymail.com>
Date: Sun, 16 Mar 2008 03:49:45 +0100 (CET)
Message-ID: <Xns9A62E8607AF3Fvdghher_at_194.177.96.26>
>
> I expect you like the idea of distributed OO, orthogonal persistence,
> location transparency and so on. However the literature is hardly
> compelling. There is the problem of
>
> - finding a consistent cut (ie that respects the
> happened-before relation)
>
> - the contradiction between transactions and orthogonal
> persistence
>
> - the contradiction between rolling back a transaction
> and orthogonal persistence
>
> - the impossibility of reliable distributed transactions
>
> - the fact that synchronous messages over the wire can easily
> be a million times slower than in-process calls
>
> - the fallibility of distributed synchronous messages which
> contradicts location transparency
>
> - the enormously difficult problem of distributed locking
> * how to avoid concurrency bottlenecks
> * when to release locks in the presence of network or machine
> failures
> * distributed deadlock detection.
> * rolling back a distributed transaction.
>
> - how to schema evolve a distributed OO system assuming
> orthogonal persistence and location transparency.
>
> - how to manage security when a process exposes many of its
> objects for direct communication with objects in another
> process.
>
> Persistent, distributed state machines raise more questions than
> answers. Persistent distributed encoded values provide a much better
> basis for building a system.
>
> 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.
>
> The easiest way for distributed applications to communicate is
> indirectly via shared data rather than by direct communication. This
> is implicit with a data-centric approach.
>
> 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.
>
Date: Sun, 16 Mar 2008 03:49:45 +0100 (CET)
Message-ID: <Xns9A62E8607AF3Fvdghher_at_194.177.96.26>
David BL <davidbl_at_iinet.net.au> wrote in news:b0d58bd3-e70e-4609-aa96-4b73f0d36184_at_i29g2000prf.googlegroups.com:
> On Mar 15, 12:16 am, "Dmitry A. Kazakov" <mail..._at_dmitry-kazakov.de>
> wrote:
>> On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote: >> >> > That's why the OO camp has such problems with making a good ORM. If >> > SQL would have been low-level, compared to the network model, the >> > task would have been much easier. >> >> Not necessarily. Certain architectures are difficult to translate >> into, for vector processors. It is related to the presumption of >> computational equivalence. A difficulty or impossibility to translate >> can come from weakness of a given language. SQL is pretty weak. >> >> Clearly when SQL is used as a intermediate language for an ORM, then >> to have it lower level and more imperative than it is would be an >> advantage. >> >> But I agree that ORM is wasting time. In my why other architectures >> are needed (like WAN-wide persistent objects). In short DBMS to be >> scrapped as a concept.
>
> I expect you like the idea of distributed OO, orthogonal persistence,
> location transparency and so on. However the literature is hardly
> compelling. There is the problem of
>
> - finding a consistent cut (ie that respects the
> happened-before relation)
>
> - the contradiction between transactions and orthogonal
> persistence
>
> - the contradiction between rolling back a transaction
> and orthogonal persistence
>
> - the impossibility of reliable distributed transactions
>
> - the fact that synchronous messages over the wire can easily
> be a million times slower than in-process calls
>
> - the fallibility of distributed synchronous messages which
> contradicts location transparency
>
> - the enormously difficult problem of distributed locking
> * how to avoid concurrency bottlenecks
> * when to release locks in the presence of network or machine
> failures
> * distributed deadlock detection.
> * rolling back a distributed transaction.
>
> - how to schema evolve a distributed OO system assuming
> orthogonal persistence and location transparency.
>
> - how to manage security when a process exposes many of its
> objects for direct communication with objects in another
> process.
>
> Persistent, distributed state machines raise more questions than
> answers. Persistent distributed encoded values provide a much better
> basis for building a system.
>
> 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.
>
> The easiest way for distributed applications to communicate is
> indirectly via shared data rather than by direct communication. This
> is implicit with a data-centric approach.
>
> 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.
>
Your points are refreshingly well taken, but I fear you are wasting your breath with people who can say with a straight face someting like "WAN-wide persistent objects). In short DBMS to be scrapped as a concept". They are simply unable to understand the problem complexity due to lack of education, or experience, or intellingence, or all of the above. Received on Sun Mar 16 2008 - 03:49:45 CET