Glossary

Services core

omni.services.core is, as it name indicates, the extension that sits at the core of the services framework.

It uses several different components to form a framework. When services are ready they are registered with this extension that will make sure they are mounted within the application and accessible via a transport.

This is available from: - omni.services.core.main

Endpoints

Endpoints are the path/location under which the API is exposed. Omniverse Kit does not impose a type of API so users are able to build fully REST based APIs or Interactive, RPC etc. ones. The specification for the API is generated and uses OpenAPI. It can be thought of as the path section of a URL.

Routers

Routers, although not required, allow the grouping and management of multiple endpoints. This becomes increasingly important and useful as services grow. It simplifies the organization and management of services creating a logical object under which endpoints are combined. They also allow the registration of facility type objects.

Routers are available from:

• omni.services.core.routers

Facilities

By default services are stateless, this is something that is critical for services to be distributed and scalable. However, certain objects like DB connections, configuration, task queues are generally stateful and for speed, efficiency can be reused. To do this, facilities are added. They are registered with routers on startup and can be injected into the services that need them. This also allows componentization making it possible to change how services are running depending on the environment they are running in by simply changing out one facility for another. For example a configuration facility can be a simple python dictionary during unit tests or a more advanced configuration file for production use. All that would need to change is the facility that gets registered with the router.

Transports

The core of the services framework is transport agnostic. This means that by just enabling omni.services.core and registering services they could only be used by an in memory transport.

To make these services accessible from outside of Omniverse Kit or between Omniverse Kit instances different transports can be used. Transports can be mixed and matched and the only limitation would be the port the transports would be listening on.

Transports, bundled with Omniverse Kit, are found underneath omni.services.transports but additional transports can be added. They would need to inherit from omni.services.transport.server.base.BaseTransport. It will need to implement a way to translate the incoming requests so it can be passed to omni.services.core.