This post originated from an RSS feed registered with Java Buzz
by Talip Ozturk.
Original Post: Interfacing with using data, not procedures
Feed Title: Shared Memory
Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark
Feed Description: about java, jini, javaspaces, programming, aop and a little bit of me and life.
Two parties communicate with each other through a common interface. Most of the time, interfaces are defined as interface classes that defines the methods you can invoke. Think about EJBs, you write home and remote interface classes for your bean so that client can interface with your bean. Client can only use the methods defined in the interfaces. You are interfacing with using method calls. JavaSpaces brings another way of defining interfaces between two parties willing to communicate. Interfacing with using data. Here is how it works. Let say application A needs to interface with a math application B to have it calculate a factorial problem. A creates a FactorialProblem object 'writes' it into JavaSpace, then JavaSpace notifies B to handle it. B 'takes' the FactorialProblem object and calculates it and 'writes' the FactorialSolution object into JavaSpace. JavaSpace then notifies A to get it. A then 'takes' the FactorialSolution object from JavaSpace. As you see A an B only used data objects to communicate with each other. Meanwhile JavaSpace is used as a intermediary guy. voooww it looks like a lot of work. Don't worry processor works faster than you read.
so .. what is good about it?
1. There is no RPC involved between A and B. A doesn't even know the party who answered the call. Perfect decoupling.
2. Scalability. As you see more FactorialProblem being written into JavaSpace start up more Bs to handle it.
3. Asynchronise messaging so better resource utilization.
You complete the list... JavaSpaces is not the only way to accomplish this. I wish to see somebody else listing the alternatives and the side effects of this approach.
Previous Topic
