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...

Building Yakkle (Part 4: Object Design)

As stated in our last Building Yakkle post, we (the ZenViva Guys) first outlined four of our primary distributed objects. These objects were derived by using a Top-Down Design approach.

Defining Yakkle's Distributed Objects
We identified the primary components: User, Texting, Voice, and Desktop; and then our secondary or helper components: Supervisor, Operator, and Session (a.k.a actively yakkling).

We separated our objects in two categories to help focus our efforts. First, the primary objects had technology requiring some prototyping and proving out (i.e. was it possible to do). The secondary objects had organizational and managerial responsibility and thus could be implemented later.

Since the “ZenViva Guys” are composed of server and user-interface (UI) guys, the server guys defined the distributed object interfaces (a.k.a our API) to be used by internal services, as well as, the Yakkle UI. By defining the objects and interfaces first, we created a development process that allowed for the guys to work in parallel.

The defining of the User and Texting objects went through some interesting design evolution. One of our fundamental design choices was to integrate with the popular XMPP Instant Messaging protocol. As a result, the User and Texting objects are not distributed objects with state and behavior, but distributed interfaces since XMPP provides all the state and behavior we needed. So our design was to objectify the XMPP services and make them available in a distributed sense.

Our voice and desktop objects needed a bit of prototyping. We had questions on whether the Java platform could be use to create high quality voice and remote desktop services in real-time, whether distributed objects are a good medium for real-time environments, and lastly, whether we could use the UDP connection less protocol for some of our connection oriented services.

In Our Next Post
In our next building Yakkle post, we'll discuss how to write user-interfaces using distributed objects and in subsequent posts we will continue to describe our design by diving deeper into the world of distributed objects. Until then, if you would like to experience the result of our works go to www.yakkle.com and start Yakkling today.

Building Yakkle (Part 2: Design Philosophy)

In our last post we talked about the first steps in building a next generation, Internet based application: finding a problem you feel passionate about solving and picking a software architecture. This post will focus on our belief in object-oriented design and our implementation choices.

Have a Design Philosophy
"Oh wonder! What noble objects these are! It must surely be a brave world that has such objects in it."

Through our experience in building large scale management systems, we have seen the benefit to applying an object-oriented design paradigm. These are well documented so we don't need to repeat them here.

For the development of Yakkle, we developed a new, slightly expanded object-oriented design philosophy: "Don't stop programming with objects when high-performance applications cross computing boundaries."

We believe that distributed object computing should not send developers running for the door, but enable them to build the next network based "killer app" by allowing quicker, more agile development.

We have found that distributed object applications are certainly not impossible, but do represent leading technology that requires some investment in thought. And like all good investments, will pay dividends in the end. Our request is for you to come along with us as we show how Distributed Object Architectures make complex network applications easier to build, understand, and deploy.

Pick a Framework
Having a philosophy is important to guiding your implementation decisions, but in software the proof is in the implementation. To deliver on our idea, we needed pick a distributed object-oriented framework that could provide the high level design concepts we desired with the low level performance we demanded. We started by basing our architecture and design around two open source projects: MyOODB and txObject.

In Our Next Post
In our next post we will talk more about myoodb and txobject and how they can be used to build distributed object-oriented applications. Until then, if you would like to experience the result of our works go to www.yakkle.com and start Yakkling today.

Building Yakkle (Part 1: Getting Started)

Now that we have introduced Yakkle, we would like to share how we built both the application and infrastructure around it. We hope that by sharing our experiences and lessons learned we will help others who also have the desire to participate in what we feel is a golden age of self inspired, self supported software development.

Find a Problem You Feel Passionate About Solving
In our full-time jobs we have been forced to endure many, shall we say, sub-optimal collaboration experiences with existing for-purchase online meeting and desktop sharing products. We also frequently see our peers combining a variety of free tools to collaborate, but still struggling due to the lack of “live” visual interaction.

So we asked ourselves, “Can we combine the best aspects of all these applications and tools to create a best-in-class collaboration product, and can we do it in a way is essentially free?”

We found that the answer to our question is yes, and the result is Yakkle.

Get Started By Picking a Software Architecture
Of course, Yakkle didn’t just happen, it had to be built. The first thing we needed to do to create it was pick the right architecture to create the application. We needed an architecture that would allow us to develop quickly at a high level of abstraction, but yet have the performance to achieve the demanding network centric operations of remote voice communications and desktop display.

With our background in distributed, object-oriented design, we knew that it would give us the agility to quickly develop any application, but we didn’t know if it could give us the performance we needed. With that question left to be answered, we decided to forge ahead.

In our Next Post
In our next post we will pick up with more on our distributed, object-oriented architecture and implementation choices. Until then, if you would like to experience the result of our works go to www.yakkle.com and start Yakkling today.