Disadvantages of Remoteness and problems with Space

One problem that almost all the Distributed applications suffer from is the concept of Remoteness and lookup. One of the toughest problem in Software Engineering is to design a system with a single Interface. The Remoteness of an application should be hidden from the client application. How many components have we worked on where we need to do a "Lookup"? EJB, JMS, JINI and they all suffer from the javax.rmi.Remote interface. Even though powerful but these technologies expect not only the managed domain object be of type Remote but also to do the discovery to find them. The Remoteness is a behavior of the container not of the application. The Application should behave exactly the same way with or without a specific infrastructure. Of course I don't consider JVMs to be an infrastructure, some may disagree. Isn't Serializable interface enough to tell the container(?) that the application could be Remote?

EJB3.0 addressed this issue to some extent. At least the annotations remove the requirements to have some specific remote interfaces implemented. The EJB classes can then be used in a standalone applications too.

Even JavaSpaces suffer from the same problems. JavaSpace expects the Object to implement net.jini.core.entry.Entry interface. Of course the Space has to identify an Object type. But what else does the Entry interface contribute to?

1. Its a Marker interface that extends Serializable. This architecture pretty much blocks users to make the Serialization any more efficient than what the default provided by the JVM is.
2. The operations read and write on a Space works similar to the get () and put () operations on a Collection. take () is a little different but can be categorized as a specialized get (). The "Space" is made logically more close to a Collection. The use of a Space should be like a Map not a Collection. A space with houses, have defined addresses. Template based lookup is inefficient. It should have been a much better design if net.jini.space.JavaSpace had extended java.util.Map interface and read () and write () were renamed as get () and put () respectively.
3. The third problem is the concept of Discovery or Finding the Space. Why? Why should the client application know that there is a Space out there that needs to be found? Isn't the discovery a role of the container and not of the end-client's?
4. At last what does it take to migrate your existing application to a distributed environment? Not easy with JavaSpaces. That will require a lot of changes to your application. If JavaSpace extends Map then migrating could have been a trivial task as to just replacing your HashMap, TreeMaps etc with JavaSpace.

Oracle Coherence has a better approach. Its NamedCache is not only based of java.util.Map but there is no concept of Discovery. Coherence is infact a distributed application, but by replacing the discovery by a Consensus protocol the product has made the entire architecture much easier. Even though NamedCache and JavaSpace are designed to function the same way but the design approach makes NamedCache much scalable.

PS: Of course APIs can be built on top of JavaSpace to address these issues.