Tuesday, December 11, 2007

Building Yakkle (Part 5: Object Implementation and Notification)

In our last discussion "Building Yakkle (Part 4)", we described some of Yakkle's distributed objects and touched on our development process. This post will cover object implementation and notification.

We could write a book ( http://www.amazon.com/o/ASIN/0201657937 ) on how to implement such things, but this is a blog. What we will do is talk at a high level on how we implemented our Voice object and how User objects are notified. It should be understood that the following discussion will be a bit techie, so non-programmers beware.

If you have experience writing traditional client/server or peer-to-peer applications, you'll understand that network sockets sooner or later get involved in the design. If your experienced in procedural programming ( http://wikipedia.org/wiki/Procedural_programming ), you've probably sent data over these sockets to be processed in subroutines ( http://en.wikipedia.org/wiki/Subroutine ). Well, in a distributed object world, your sockets and procedural functions do not exist.

In a distributed object world, you use objects to communicate between applications. Now in reality there are sockets and functions under the hood, but as a programmer, they are never seen nor part of your design. In an active Yakkle ( http://www.yakkle.com ) session, we create a Yakkle voice object per Yakkle user. When a user speaks, methods ( http://en.wikipedia.org/wiki/Method_(computer_science) ) are invoked on the voice object which stores the audio data. Once stored, all other users can access this data.

Distributed object method invocations work well for design patterns like voice. Where get methods can block and put methods can throttle. Very symmetric. However, there are design patterns where you want arbitrary object information, but do not want to continuously invoke methods to access it. Our Yakkle user object has such information.

The user object, for instance, has status that can change from “Available to Yakkle” to “Do not disturb”. Instead of continuously invoking methods to see if status has changed, the Yakkle application registers and listens for object change events. This way, the framework ( in our case MyOODB ), notifies the Yakkle application that the user object has changed ( Remember what your teacher said “An Event driven model is better than a polling model”. )

We hope you enjoyed a peek into our development process and the Yakkle architecture...

blog comments powered by Disqus