OpenSim Services and Service Connectors
From OpenSimulator
Contents |
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.
This proposal comes in the sequence of an email thread on the -dev mailing list: https://lists.berlios.de/pipermail/opensim-dev/2009-April/006325.html A large part of what's described here is already in place in trunk, but the only connector in place is the one for the Asset Service.
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 a 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:
- We move away from the current boolean architectural choices given by the variable "gridmode=true|false", and into a model where simulators can be configured in a variety of hybrid modes.
- 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 (HTTP vs XMLRPC vs ...) 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, by making the corresponding connector DLL available to the simulators.
- 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
The implementation is illustrated using the Asset Service as an example.
Service Interfaces
OpenSim.Services.Interfaces: This DLL contains all the service interfaces know to OpenSim.
Here is how IAssetService looks like:
public interface IAssetService { // Three different ways to retrieve an asset // AssetBase Get(string id); AssetMetadata GetMetadata(string id); byte[] GetData(string id); bool Get(string id, Object sender, AssetRetrieved handler); // Creates a new asset // Returns a random ID if none is passed into it // string Store(AssetBase asset); // Attachments and bare scripts need this!! // bool UpdateContent(string id, byte[] data); // Kill an asset // bool Delete(string id); }
Connectors
The direction of a connector is determined by the direction of the connection being made, not by the direction of the data flow. Therefore, an OUT connector is always a client, while an IN connector is always a server. Conversely, an OUT connector will provide an interface, while an IN connector will consume an interface. Interfaces are consistent across the entire chain of connectors, therefore IN connectors can be directly connected to OUT connectors, which would create a proxy server.
Out Connectors
An OUT connector primarily exposes its interfaces, it may have a secondary interface to be able to load as a region module. Here is a snippet of the RemoteAssetServiceConnector, which, as the name says, connects to a remote asset server:
public class RemoteAssetServicesConnector : AssetServicesConnector, ISharedRegionModule, IAssetService { private bool m_Enabled = false; private IImprovedAssetCache m_Cache; public string Name { get { return "RemoteAssetServicesConnector"; } } public override void Initialise(IConfigSource source) { IConfig moduleConfig = source.Configs["Modules"]; if (moduleConfig != null) { string name = moduleConfig.GetString("AssetServices", ""); if (name == Name) { IConfig assetConfig = source.Configs["AssetService"]; if (assetConfig == null) { m_log.Error("[ASSET CONNECTOR]: AssetService missing from OpenSim.ini"); return; } m_Enabled = true; base.Initialise(source); m_log.Info("[ASSET CONNECTOR]: Remote assets enabled"); } } } public void AddRegion(Scene scene) { if (!m_Enabled) return; scene.RegisterModuleInterface<IAssetService>(this); } ... }
The above code is just the region module, which is enabled or not depending on configuration variables (described further down). Two things are noteworthy:
- This module registers with Scene as the simulator's IAssetService. In other words, this modules is the direct provider of that interface within the simulator. All asset operations go through it first.
- This class extends AssetServicesConnector, which is the class that has the 'meat' of the service. A small part of it is presented below:
public class AssetServicesConnector : IAssetService { private string m_ServerURI = String.Empty; private IImprovedAssetCache m_Cache = null; public AssetServicesConnector(string serverURI) { m_ServerURI = serverURI; } public AssetServicesConnector(IConfigSource source) { Initialise(source); } public virtual void Initialise(IConfigSource source) { IConfig assetConfig = source.Configs["AssetService"]; if (assetConfig == null) { m_log.Error("[ASSET CONNECTOR]: AssetService missing from OpenSim.ini"); throw new Exception("Asset connector init error"); } string serviceURI = assetConfig.GetString("AssetServerURI", String.Empty); if (serviceURI == String.Empty) { m_log.Error("[ASSET CONNECTOR]: No Server URI named in section AssetService"); throw new Exception("Asset connector init error"); } m_ServerURI = serviceURI; } public AssetBase Get(string id) { string uri = m_ServerURI + "/assets/" + id; AssetBase asset = null; if (m_Cache != null) asset = m_Cache.Get(id); if (asset == null) { asset = SynchronousRestObjectRequester. MakeRequest<int, AssetBase>("GET", uri, 0); if (m_Cache != null) m_Cache.Cache(asset); } return asset; } ... }
In Connectors
IN connectors listen for requests and decode them for processing. They are typically bound to a HTTP server, although other transports are possible. An IN connector will acquire an instance of a class exposing the target interface and send all received and decoded data to that class, which may be a consumer (database, etc.), a forwarder/broker (HGBroker) or an OUT connector, which would create a proxy server. IN connectors can share the same HTTP server, so all services can be contained in a single server process, or split among several processes or hosts. The proxy configuration is of particular interest, since it allows load balancing and write request routing. For instance, in SQL clusters it is possible to route write requests to different hosts than read requests.
