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 3: MyOODB)

So you've decided to change the world by writing the coolest Internet application and you'd like to hear how we built ours. This and the next several posts will focus on what makes up Yakkle and will be geared towards software programmers.

Nowadays there are so many off the shelf software components to help you implement your idea, some commercial, but many are Open-Source and free. Since most reading this blog will be building their application out of their Garage we're recommending you choose open-source. Open-source software has a large community and can be really good. You just need to know what you need and where/how to look. Yakkle for instance, gets many of its components from open-source. Even our development tools are free and/or open-source.

Like we mentioned in a previous post, Yakkle uses a Distributed Object Architecture. This differs greatly from traditional client/server or even peer-to-peer applications. Distributed object software requires a new way of thinking that changes the very nature of the design. Now such architecture is not the Holy Grail, but it does change the way one approaches design. It puts an emphasis on information theory and data modeling. In fact, it extends object-oriented design across application boundaries; a holistic approach to software design.

The MyOODB Framework
For Yakkle, we based our Framework on the MyOODB project. MyOODB is an open-source, Java based software framework. Some of our Design Patterns were derived from the open-source txObject project.

Both projects provide a framework, design philosophy, and Software Components. It is important when designing your own architecture that you add such concepts into your development.

Distributed Object computing can be seen as Object-Oriented programming without bounds. Therefore our first step was to define the objects a Yakkle application would need to share in its world. For Yakkle to be a collaboration application, it needed things like Users, Voice, Desktop, and Text Messaging characteristics. So our first step was to define theses objects and their behavior. Just like a standalone object-oriented application design, but with the unique understanding that these objects would also be used in a distributed sense.

In Our Next Post
In our next post with will go into detail on how we design and implemented these objects, as well as, their user-interface interactions. 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.