Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Gyrex/Context Runtime"
m (Gyrex/Concepts/Contextual Runtime moved to Gyrex/Context Runtime: simplify page structure) |
(started revising the concept a bit) |
||
| Line 1: | Line 1: | ||
| − | == Introduction == | + | == Introduction == |
| − | Eclipse is a dynamic and extensible platform. For example, the Eclipse extension | + | Eclipse is a dynamic and extensible platform. For example, the Eclipse extension registry allows for a great extensibility where some component defines an extension point and allows others to provide an implementation for it. Another possibility are OSGi services. There can me multiple extensions as well as multiple instances of an OSGi service. This is especially of interest in a multi-tenant environment because it allow for tenant-specific extensions as well as implementations. |
| − | registry allows for a great extensibility where some | + | |
| − | point and allows others to provide an implementation for it. Another possibility | + | |
| − | are OSGi services. | + | |
| − | + | This flexibility requires some management and processes to handle all the extensions and service implementations in order to pick the right one to use in a specific situation. We refer to this situation as "''execution context''" ("''runtime context''", or just "''context''") in Gyrex. Gyrex allows to put or execute operations within (or on behalf of) a particular context. The contextual runtime is one of the key elements of Gyrex and allows - for example - the development of multi-tenant software offerings. | |
| − | + | ||
| − | particular context. The contextual runtime is one of the key elements of Gyrex | + | |
| − | and allows - for example - the development of multi-tenant software offerings. | + | |
| − | Let's look at an example. | + | Let's look at an example. On an online shopping website inventory information is typically displayed along the items. The inventory information is retrieved from a service. This service is defined in a bundle with a default implementation backed by a database. This will be the default for all shops served by the system. The other day a new client comes along which likes the shopping website to retrieve the inventory information directly from an inventory system instead of a database. With OSGi or the Eclipse extension registry this is a no-brainer. You simply implement the special inventory service and provide it as an OSGi service (or Eclipse extension). But now the shopping website needs to deal with two services implementations (or two extensions). It needs to know which one to use in which shop. Ideally this would be configurable by a system operator. Here comes the Gyrex Context Runtime to the rescue. Using the Context Runtime a shop can be defined as a runtime context. The shopping website simply delegates the call. Instead of asking the extension registry or the OSGi service registry directly, it asks the context which service (or extension) to use. The rest will all be configurable through an administration interface (or via APIs). Your code does not need to implement any filtering or permission checks. The Gyrex Context Runtime takes care of that. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | The other day a new client comes along | + | |
| − | shopping | + | |
| − | + | ||
| − | is a no-brainer. You simply implement the special | + | |
| − | as an OSGi service. But now the | + | |
| − | two | + | |
| − | + | ||
| − | defined as | + | |
| − | asking the extension registry or the OSGi service registry directly, it asks the | + | |
| − | context which service (or extension) to use. The rest will all be configurable | + | |
| − | through an administration interface (or via APIs). Your code does not need to | + | |
| − | implement any filtering or permission checks. The | + | |
| − | of that. | + | |
| − | == The Runtime Context == | + | == The Runtime Context == |
| − | The runtime context is the central element of the contextual runtime. It | + | The runtime context is the central element of the contextual runtime. It provides APIs to get a specific, ready-configured service for the client code base to use. The lookup of the service will be very simple. You simply pass a class object to context and it will return an instance of the class for you to work with. Thus, the context is essentially an object registry. However, it's dynamic, i.e. it can change between invocations. |
| − | provides APIs to get a specific, ready-configured service for the client code | + | |
| − | base to use. The lookup of the service will be very simple. You simply pass | + | |
| − | a class object to context and it will return an instance of the class for you | + | |
| − | to work with. Thus, the context is essentially an object registry. However, | + | |
| − | it's dynamic, i.e. it can change between invocations. | + | |
| − | Contexts are hierarchical organized in a path like structure. There is a root | + | Contexts are hierarchical organized in a path like structure. There is a root context ("/") which typically defines the core pieces of a system. In a single system it's actually possible to just work with the root context. |
| − | context ("/") which typically defines the core pieces of a system. In a single | + | |
| − | system it's actually possible to just work with the root context. | + | |
| − | Context values are inherited. Thus, if a context does not have a value defined, | + | Context values are inherited. Thus, if a context does not have a value defined, it's parent will be queried until a value is found. It's also possible to explicitly undefine (set to "null") a value in a client context. |
| − | it's parent will be queried until a value is found. It's also possible to | + | |
| − | explicitly undefine (set to "null") a value in a client context. | + | |
| − | Note, for security reasons (see below) a context will not allow simple | + | Note, for security reasons (see below) a context will not allow simple retrieval of its parent context. Instead always the context registry has to be used to lookup a particular context (even the parent). |
| − | retrieval of its parent context. Instead always the context registry has to | + | |
| − | be used to lookup a particular context (even the parent). | + | |
| + | <br> | ||
| − | == Contextual Objects == | + | == Contextual Objects == |
| − | The objects ("values") provided by the context are pure Java objects. They | + | The objects ("values") provided by the context are pure Java objects. They can be OSGi services, Eclipse extensions, Eclipse adapters from the IAdapterFactory or other contextual objects. Contextual objects are objects provided specifically for a context. A provider can be registered as an OSGi service which will provide context specific objects. To some extend, this can be compare to OSGi service factories. The only difference is, that the service implementation is not bound to the bundle requesting the service but to the context requesting the service. This allows for a concept of context singletons. |
| − | can be OSGi services, Eclipse extensions, Eclipse adapters from the | + | |
| − | IAdapterFactory or other contextual objects. Contextual objects are objects | + | |
| − | provided specifically for a context. A provider can be registered as an OSGi | + | |
| − | service which will provide context specific objects. To some extend, this can | + | |
| − | be compare to OSGi service factories. The only difference is, that the service | + | |
| − | implementation is not bound to the bundle requesting the service but to the | + | |
| − | context requesting the service. This allows for a concept of context singletons. | + | |
| + | <br> | ||
| − | == Context Registry & Security == | + | == Context Registry & Security == |
| − | The configuration of contexts is persisted and kept across sessions. A central | + | The configuration of contexts is persisted and kept across sessions. A central registry is available of "loading" of contexts. However, access to the registry may be guarded by security constraints to allow only trusted code access to a specific set of contexts. This prevents client code with a lower lever of trust to not execute operations outside of the client context. |
| − | registry is available of "loading" of contexts. However, access to the registry | + | |
| − | may be guarded by security constraints to allow only trusted code access to | + | |
| − | a specific set of contexts. This prevents client code with a lower lever of | + | |
| − | trust to not execute operations outside of the client context. | + | |
Revision as of 03:01, 30 July 2010
Introduction
Eclipse is a dynamic and extensible platform. For example, the Eclipse extension registry allows for a great extensibility where some component defines an extension point and allows others to provide an implementation for it. Another possibility are OSGi services. There can me multiple extensions as well as multiple instances of an OSGi service. This is especially of interest in a multi-tenant environment because it allow for tenant-specific extensions as well as implementations.
This flexibility requires some management and processes to handle all the extensions and service implementations in order to pick the right one to use in a specific situation. We refer to this situation as "execution context" ("runtime context", or just "context") in Gyrex. Gyrex allows to put or execute operations within (or on behalf of) a particular context. The contextual runtime is one of the key elements of Gyrex and allows - for example - the development of multi-tenant software offerings.
Let's look at an example. On an online shopping website inventory information is typically displayed along the items. The inventory information is retrieved from a service. This service is defined in a bundle with a default implementation backed by a database. This will be the default for all shops served by the system. The other day a new client comes along which likes the shopping website to retrieve the inventory information directly from an inventory system instead of a database. With OSGi or the Eclipse extension registry this is a no-brainer. You simply implement the special inventory service and provide it as an OSGi service (or Eclipse extension). But now the shopping website needs to deal with two services implementations (or two extensions). It needs to know which one to use in which shop. Ideally this would be configurable by a system operator. Here comes the Gyrex Context Runtime to the rescue. Using the Context Runtime a shop can be defined as a runtime context. The shopping website simply delegates the call. Instead of asking the extension registry or the OSGi service registry directly, it asks the context which service (or extension) to use. The rest will all be configurable through an administration interface (or via APIs). Your code does not need to implement any filtering or permission checks. The Gyrex Context Runtime takes care of that.
The Runtime Context
The runtime context is the central element of the contextual runtime. It provides APIs to get a specific, ready-configured service for the client code base to use. The lookup of the service will be very simple. You simply pass a class object to context and it will return an instance of the class for you to work with. Thus, the context is essentially an object registry. However, it's dynamic, i.e. it can change between invocations.
Contexts are hierarchical organized in a path like structure. There is a root context ("/") which typically defines the core pieces of a system. In a single system it's actually possible to just work with the root context.
Context values are inherited. Thus, if a context does not have a value defined, it's parent will be queried until a value is found. It's also possible to explicitly undefine (set to "null") a value in a client context.
Note, for security reasons (see below) a context will not allow simple retrieval of its parent context. Instead always the context registry has to be used to lookup a particular context (even the parent).
Contextual Objects
The objects ("values") provided by the context are pure Java objects. They can be OSGi services, Eclipse extensions, Eclipse adapters from the IAdapterFactory or other contextual objects. Contextual objects are objects provided specifically for a context. A provider can be registered as an OSGi service which will provide context specific objects. To some extend, this can be compare to OSGi service factories. The only difference is, that the service implementation is not bound to the bundle requesting the service but to the context requesting the service. This allows for a concept of context singletons.
Context Registry & Security
The configuration of contexts is persisted and kept across sessions. A central registry is available of "loading" of contexts. However, access to the registry may be guarded by security constraints to allow only trusted code access to a specific set of contexts. This prevents client code with a lower lever of trust to not execute operations outside of the client context.