User:Infinity Linden/Distributed Object Concepts

Introduction

This is a brief discussion of how we (or at least some of us) here at Linden Lab view distributed applications. We spend a lot of our day knee-deep in code and specific networking issues, but I thought it might be good to take a breather, come up for air and talk about concepts. You may disagree with us on a number of points, but we figured it was a good idea to communicate how we see the world of distributed applications.

Concept 1 : Applications Can Be Represented as Collections of Objects

a typical object graph representing the state of an application

This may sound a bit simple for most people reading this... OO systems are a pervasive part of software development these days. Whether you program in C++, Ruby, JavaScript or even PHP, you've probably run into objects and classes.

But we figured it was worth re-iterating. We like objects, especially when they're coded as... well... objects. It's important to note that just because you're using an object oriented programming language, it's still possible to write code eschews the objectives of object orientation. Conversely, it's possible to write code that is OO-ish in non-OO languages, it's just a bit harder.

What we're talking about with this concept is that it's possible to model an application as a collection of cooperating objects. The figure to the left is meant to represent such an application. Rather than representing the application's state in a global data structure, state is distributed across a collection of smaller objects. Objects are intended to represent a conceptual entity manipulated by the application. Rather than writing routines to manipulate global data structures, we write methods that manipulate the state of an object in response to messages from other objects. Objects maintain references to other objects; the arrows in the figure at the left represent these references. Objects send messages to each other via these references, and it's these messages that trigger code to be executed to manipulate the state of our object friends. Okay.. so now that i've completely bored you with an extremely basic discussion that's so vague it has about zero utility.. let me conclude with the "important bits."

It's easy to get lost in the details of XML parsing and the wild flurry of UDP messages the SL client emits, but at the end of the day, there's this "application" thing that is independent of TCP or UDP or HTTP or whatever. It's a collection of cooperating objects (the mathematically inclined might call it an "object graph".) The object graph represents the "application logic" (escapees from the web 2.0 era may also occasionally use the term "business logic.") It represents the core abstractions of the application, independent of network transport, graphics rendering technology or even functional system architecture. We like OO development environments as they generally support concepts such as Abstraction, Encapsulation and Decoupling that makes maintenance of an evolving system less painful.

Concept 2 : Object Graphs Abound

a client and a server application being represented as object graphs

Still with me? Great! I was worried I was boring you.

So the next concept is pretty straight forward as well: you can represent a server application as an object graph as easily as you can represent a client application with an object graph. The figure to the right is supposed to represent this concept.

You could go on and say that this concept does not require client-server communications, and you would be right. It would be possible to replace every instance of client and server with the word peer and you would still have a very workable conceptual framework. We talk about client-server a lot at Linden cause:

1. we make extensive use of HTTP in our system which uses the Request-Response pattern, thus implying a client and a server, and
2. people sometimes confuse the term "network peer" with the term "peer to peer" and freak out, thinking we're supporting illegal file-sharing or opening an interface that allows "bad guys" to illicitly copy digital assets in contravention of asset permission meta-data. For the record, we go to great lengths to prevent such illicit asset copying.