OpenSim Services and Service Connectors

Motivation

OpenSim was originally designed with the ambitious goal of becoming the Apache server of Virtual Worlds, while still able to interact with the standard Second Life(tm) client. These two design rules have conflicted all along, but overall OpenSim has been able to find a good balance between revolution and evolution. Compatibility with the LL client has been here all along, while at the same time we have been able to try out completely new ideas that have inspired lots of people to try their own.

The OpenSim framework is becoming so many things to so many people that it has reached the point where the original architecture of the software itself, largely inspired by what the SL Client dictates and by the Linden Lab grid, is hampering progress on all those fronts. We need to rethink the architecture of the software in order to be able to support the variety of things that people want to do with OpenSim without having to go through lengthy design discussions and negotiations for it to do "the right thing", which obviously doesn't exist. For some, "the right thing" is a server infrastructure that is a 100% reproduction of Second Life; for others, "the right thing" is a 3D server infrastructure that is 100% compatible with the Web; for others, "the right thing" is a desktop 3D simulator; and for many others "the right thing" is many points in between.

Proposal Summary

We propose a new software architecture that can easily accommodate all the system architectures that people want to build. The basic concepts of this new software architecture are (1) Service Interfaces; (2) Service Connectors; (3) Service Implementations; and (4) Server Shells. Service implementations are pieces of code that can be loaded into any server shell, along with their "in" service connectors that receive service requests from clients. Clients access services through service interfaces, and by loading the corresponding "out" service connectors that send requests to the service implementations. The figure above illustrates the general concept.

A Service is the collection of its implementation and its connectors, and obeys a certain service interface. The people that implement the service also implement its connectors. Therefore, the details of the protocol between the client-side and the server-side are invisible to the service clients, which only know about the service interface. As long as the interface is preserved, switching service implementations is a trivial matter of replacing the out connector in the client. The specification of all of these elements is done at initialisation time, by loading the specified DLLs and/or by using a generic plugin infrastructure.

Benefits

The figure below shows 4 different system architectures that can be trivially configured if the proposed software architecture is in place.

Note that these are only 4 out of a variety of combinations.

The benefits of this software architecture are the following:

• The dynamic loading of service connectors into the simulator allows a variety of protocols "on-the-wire" between the simulator and the services without having to change the simulator code. (As long as that service implementation can honor the established service interface for it)
• [Corollary of the previous] All discussions about simulator-service protocols become irrelevant to the OpenSim framework itself. Opensim will continue to provide a few service implementations and their connectors out-of-the-box, but anyone can replace those with their own without having to make any changes to the source code of the Simulator.
• All OpenSim servers become server shells of the same type. That is, they are all configured through the .ini mechanism, and they can run any of the services and service connectors. Therefore, it also becomes trivially possible to have system architectures where some resource service uses another resource service directly. For example, the Inventory server may use the Asset server in order to provide a combined IInventoryService+IAssetService interface to viewers.

Implementation of the Proposed Software Architecture