OpenSim Services and Service Connectors
From OpenSimulator
| Line 9: | Line 9: | ||
== Proposal Summary == | == Proposal Summary == | ||
| − | + | [[Image:Connector_Architecture.jpg|600px]] | |
| − | + | 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. | + | 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. |
| − | The | + | == How this maps into OpenSim === |
| + | |||
| + | The benefits of this software architecture are the following: | ||
| + | * All discussions about client-server 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. | ||
Revision as of 15:07, 19 May 2009
|
|
This article or section is a Proposal It does not represent the current state of OpenSim, but is an idea for future work in OpenSim. Please feel free to update this page as part of the proposal discussion. |
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.
How this maps into OpenSim =
The benefits of this software architecture are the following:
- All discussions about client-server 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.
