Computer-implemented systems and methods for service provisioning

1. A computer-implemented system for service versioning, the system comprising:

a storage device that stores a set of instructions; and

at least one processor coupled to the storage device, the set of instructions configuring the at least one processor to:

receive, by a host manager process, a query for a service from a client device, the queried service including a class moniker, the class moniker being selected via a navigation menu corresponding to one or more selectable services, and the class moniker identifying the queried service and a class of the queried service;

generate, by the host manager process, a client moniker corresponding to the class moniker, the client moniker identifying a client name and a version parameter of the queried service;

search a plurality of service manifests to identify one or more service manifests corresponding to one or more versions of the queried service, each of the one or more service manifests including one or more associated tags or metadata;

based on an inspection of the one or more associated tags or metadata in each of the one or more service manifests, determine a compatibility between each of the one or more service manifests and the one or more versions of the queried service;

whereupon reaching an incompatibility determination, prevent the client device from using the incompatible version of the queried service;

whereupon reaching a compatibility determination, load the compatible version of the queried service onto the client device in place of one or more prior versions of the service stored by the client device, and determine a context in which to load the queried service by locating, in the service manifest corresponding to the compatible version of the queried service, a class of the service manifest and inspecting a context attribute of a module enclosing the class, the context being at least one of in-process or out-of-process,

whereupon the context attribute indicates the queried service is to be loaded in-process, returning a filename of the service manifest to a service manager object of the client, for loading the queried service; and

whereupon the context attribute indicates the queried service is to be loaded out-of-process, forming a package moniker from service attributes and a version attribute in the service manifest corresponding to the compatible version of the queried service, using the context attribute to determining a service host into which the service manifest is to be loaded, and sending a request to the service host to load the service manifest.

2. The system of claim 1 , wherein the queried service identified in the class moniker matches a name associated with a service folder and a name tag in the service manifest.

3. The system of claim 1 , further comprising receiving one or more queries on the metadata associated with the queried service.

4. The system of claim 1 , wherein the at least one processor is further configured to:

determine whether there is an older version of the queried service when the latest version of the queried service is not compatible with the client device; and

load the older version of the queried service in the client device when the older queried service is compatible with the client device.

5. The system of claim 4 , wherein the at least one processor is further configured to:

return an error to the client device when there is not an older version of the queried service.

6. The system of claim 1 , wherein the at least one processor is further configured to:

store a document object model associated with the service manifest; and

start the queried service in the client device using the object model.

7. A non-transitory computer-readable medium that stores instructions that, when executed by at least one processor, cause the at least one processor to perform service versioning, including causing the at least one processor to:

receive, by a host manager process, a query for a service from a client device, the queried service including a class moniker, the class moniker being selected via a navigation menu corresponding to one or more selectable services, and the class moniker identifying the queried service and a class of the queried service;

generate, by the host manager process, a client moniker corresponding to the class moniker, the client moniker identifying a client name and a version parameter of the queried service;

search a plurality of service manifests to identify one or more service manifests corresponding to one or more versions of the queried service, each of the one or more service manifests including one or more associated tags and metadata;

based on an inspection of the one or more associated tags or metadata in each of the one or more service manifests, determine a compatibility between each of the one or more service manifests and the one or more versions of the queried service;

whereupon reaching an incompatibility determination, prevent the client device from using the incompatible version of the queried service;

whereupon reaching a compatibility determination, load the compatible version of the queried service onto the client device in place of one or more prior versions of the service stored by the client device, and determine a context in which to load the queried service by locating, in the service manifest corresponding to the compatible version of the queried service, a class of the service manifest and inspecting a context attribute of a module enclosing the class, the context being at least one of in-process or out-of-process;

whereupon the context attribute indicates the queried service is to be loaded in-process, returning a filename of the service manifest to a service manager object of the client, for loading the queried service; and

whereupon the context attribute indicates the queried service is to be loaded out-of-process, forming a package moniker from service attributes and a version attribute in the service manifest corresponding to the compatible version of the queried service, using the context attribute to determine a service host into which the service manifest is to be loaded, and sending a request to the service host to load the service manifest.

8. The non-transitory computer-readable medium of claim 7 , wherein the queried service identified in the class moniker matches a name associated with a service folder and a name tag in the service manifest.

9. The non-transitory computer-readable medium of claim 7 , wherein the stored instructions further cause the processor to: receive one or more queries on the metadata associated with the queried service.

10. The non-transitory computer-readable medium of claim 7 , wherein the stored instructions further cause the processor to:

determine whether there is an older version of the queried service when the latest version of the queried service is not compatible with the client device; and

load the older version of the queried service in the client device when the older version of the queried service is compatible with the client device.

11. The non-transitory computer-readable medium of claim 10 , wherein the stored instructions further cause the processor to:

return an error to the client device when there is not an older version of the queried service.

12. The non-transitory computer-readable medium of claim 7 , wherein the stored instructions further cause the processor to:

delete older versions of the queried service in the client device when the latest version of the queried service is compatible with the client device.

13. The non-transitory computer-readable medium of claim 7 , wherein the stored instructions further cause the processor to:

store a document object model associated with the service manifest; and start the queried service in the client device using the object model.

14. A computer-implemented method for service versioning, the method including the following operations performed by at least one processor:

receiving, by a host manager process, a query for a service from a client device, the queried service including a class moniker, the class moniker being selected via a navigation menu corresponding to one or more selectable services, and the class moniker identifying the queried service and a class of the queried service;

generating, by the host manager process, a client moniker corresponding to the class moniker, the client moniker identifying a client name and a version parameter of the queried service;

searching a plurality of service manifests to identify one or more service manifests corresponding to one or more versions of the queried service, each of the one or more service manifests including one or more associated tags and metadata;

based on an inspection of the one or more associated tags and metadata in each of the one or more service manifests, determining a compatibility between each of the one or more service manifests and the one or more versions of the queried service;

whereupon reaching an incompatibility determination, preventing the client device from using the incompatible version of the queried service;

whereupon reaching an compatibility determination, loading the compatible version of the queried service onto the client device in place of one or more prior versions of the service stored by the client device, and determine a context in which to load the queried service by locating, in the service manifest corresponding to the compatible version of the queried service, a class of the service manifest and inspecting a context attribute of a module enclosing the class, the context being at least one of in-process or out-of-process;

whereupon the context attribute indicates the queried service is to be loaded in-process, returning a filename of the service manifest to a service manager object of the client, for loading the queried service; and

whereupon the context attribute indicates the queried service is to be loaded out-of-process, forming a package moniker from service attributes and a version attribute in the service manifest corresponding to the compatible version of the queried service, using the context attribute to determine a service host into which the service manifest is to be loaded, and sending a request to the service host to load the service manifest.

15. The computer-implemented method of claim 14 , the operations further comprising: receiving one or more queries on the metadata associated with the queried service.

16. The computer-implemented method of claim 14 , the operations further comprising:

determining whether there is an older version of the queried service when the latest version of the queried service is not compatible with the client device; and

loading the older version of the queried service in the client device when the older version of the queried service is compatible with the client device.

17. The computer-implemented method of claim 14 , further comprising:

deleting older versions of the queried service in the client device when the latest version of the queried service is compatible with the client device.