So all this sounds great but how are you actually going to do this I hear you ask..
Well I'm a big fan of not attempting to drink the ocean; figuratively speaking, so I'm going to start small and build a simple proof of technology first.
Like with all programmes I plan on starting with hello world.
In aid of this I plan on building a simple test framework from which I can work on the larger application.
This framework will be using JFrames for the user interface. This is largely because as JEE architect I'm sick of the web and writing this as a fat client sounds like a bit of fun.
But what is the framework actually testing?
Well in order to have a flexible cloud based crowd sourced application I need to build it arround a communication framework which will support this approach effectively.
As a result it will be testing the framework built around distributing functionality across multiple nodes using P2P.
Of course you probably guessed this when I mentioned JXTA on the previous post.
So my hello world.
I plan on three phases this weekend.
Phase One
The first phase is quite simplistic.
In the test framework I plan on using two nodes; both on local host.
Both have their own listening port that the other knows about.
When one communicates with the other it binds to the listening port.
The connection manager on that node will create a handlers thread for that connection request and pass the connection on to the handler.
The requesting node will then pass its payload on to the handler thread and disconnect.
For the first phase the payload will simply contain the arguments for the method, in this case a string to display on the UI of the receiving node.
Phase two
Once I have setup my two nodes and proven they can message each other effectively phase two will to be to add brokering logic to the framework.
I will programme the nodes to look for annotations on the methods, if a method has the appropriate annotation on it, it and its arguments will be registered against the method broker.
The payload from the calling node will be augmented to include the method it is calling as well as the arguments as name value pairs.
My display method to display the string on the UI will be suitably annotated and the brokerage system can be tested out.
Phase Three
P2P lends itself quite effectively to call backs and call back like logic.
Given it's fabric like qualities forcing it into a request, response type structure would be pointless.
Phase three will be about adding callback support and including logic in the framework to make the application think it is using request, response logic when it isn't.
I'm not sure the best way to talk through how Im going to do this. Its a bit of a chicken and egg issue. So forgive me if this is a bit (more than usual) confusing.
Pure call backs:
When this is a pure call back situation the implementation approach is simplest; the call back method will be a generic method taking in the actual callback method name and arguments as final values to inject them into the method, the signature will be VARGs this will allow the generic callback method to be as flexible as possible. This will connect to the other node in the pair, sending its payload in the same manner the node in question received its payload earlier.
Call backs when the receiving node is using methods with a return:
Of course in many situations its easier to write your methods just to return without worrying about call backs. This will ensure you don't need to worry so much about the stack; also if you are using recursion will make your life a little less complicated.
In the case where the receiving method returns a value, that value will be used to populate the callback by the handler.
If the callback argument type does not match the return value; then the handler will send the sending node an error when the payload is provided.
Call backs when the sending node wants a blocking method with a return value:
The reverse is also true. In many cases you want the code to block and wait for a return value and additionally fragmenting the logic flow into multiple methods linked only by call back would make the code maintainable.
In this case we will implement in the framework a wrapper.
This wrapper will take the expected method name, and the collection of arguments (provided a a VARG) in and return a single Object.
It will then register in method broker a temporary method. It will also create against a special map for the temporary method a look-up value containing the thread details and a play to store the return value.
The wrapper will then invoke the receiving node sending the temporary call back method it its payload and sleep.
When ever it wakes up it will check if the data against the temporary look-up value has been returned.
If it is never returned it will eventually time out, otherwise once it is returned, the wrapper will take the value, remove the method reference from the stack and de-register the method from the broker and return the value to the calling method.
The temporary call back of course will be marked as such. Handler on receiving the method is temporary will not attempt to invoke the method as it would normally. Rather it will store the value against the temporary method in the stack, and use the thread reference to wake the sleeping thread up.
I'm sure to most this may seem like I'm playing it safe and setting my goals low.
However my in-laws are in town so I'm not actually going to have allot of time to spend doing time.
Thus the three easy phases.
Ofcourse once I have this in place I'll be much better positioned to be more adventurous next time
No comments:
Post a Comment