Location transparency involves the assumption that it is useful to write code that can access objects in the same way, whether or not they are in-process.
More specifically, there is a local proxy which stands in place of the remote object without caching any of its state. Every access to the proxy involves remote method invocation and turns into I/O (messages sent/received over the network).
There are two massive differences between remote and local calls:
Making an object remote when it could be local is an anti-pattern, that is why data replication and data caching are such fundamental and useful patterns, and location transparency is an anti-pattern.
This pattern was promoted in middleware technologies such as CORBA []and DCOM []
The objects in question are sometimes called distributed objects []. This wikipedia article states:
Distributed objects were popular in the late 1990s and early 2000s, but have since fallen out of favor
This is not surprising, location transpancy is an anti-pattern, similar in nature to the orthogonal persistence anti-pattern, and suffers from the same significant drawbacks, such as greatly complicating the problem of recovering back to a consistent cut.
Location transparency ignores the fallacies of distributed computing.
Any time there is an emphasis on decomposing a large system into smaller pieces that exhibit behaviour and that interoperate by the exchange of messages over a network, is essentially the distributed objects anti-pattern.
The intrinsic differences between local and remote objects is discussed in A Note on Distributed Computing by Waldo, Wyant, Wollrath and Kendall (1994).
Martin Fowler calls it the First Law of Distributed Object Design: don't distribute your objects. See his blog article Microservices and the First Law of Distributed Objects (2014).
SOA [] is essentially the distributed objects anti-pattern for the Internet. Indeed SOA was first termed Service-Based Architecture in 1998 by a team using CORBA to implement the distributed objects. Although Martin Fowler rightly points out that SOA is a very ambiguous term, there is no doubt there is an emphasis on messaging between applications/services - i.e. SOA implies a message-oriented architecture.
What's the right way? The data-centric principle. Applications are concerned with reading/writing data in databases, not with sending or receiving messages. Applications interact through data replication and synchronisation which is implemented by the DBMS. In CEDA all access to data is in-process. Applications don't need to send or receive messages.