Abstract: The resources needed by an application to execute are declared by the application. When the application is activated, only the declared resources are made available to the application because only the declared resources are connected to the execution environment. Accessibility to resources may be controlled by the operating system by making the resource visible or invisible to the executing software by mapping a local name used by the executing software to a global resource, possibly limiting the type of access allowed. Because the executing software relies on the mapping function performed by the operating system for access to resources, and the operating system only maps names declared by the software, the operating system can isolate the software, and prevent the application from accessing undeclared global resources.

Abstract: Applications, such as cloud services, may be deployed within a network environment (e.g., a cloud computing environment). Unfortunately, when the applications are instantiated within the network environment, they have the ability to compromise the security of other applications and/or the infrastructure of the network environment. Accordingly, as provided herein, a security scheme may be applied to a network environment within which an application is to be instantiated. The security scheme may comprise one or more security layers (e.g., virtual machine level security, application level security, operating system level security, etc.) derived from an application service model describing the application and/or resources allocated to the application.

Abstract: The operating system organizes software so the set of extensions for an extendable application can be dynamically discovered and the extension can be run securely. Extensions are run as separate applications instead of within the extendable application's process. Extensions are discoverable to an activated extendable application by querying a category catalog. A category provides at least a partial description of a contract between an activating software entity and a software entity that is activated by the activating software entity. The category may enumerate a set of configuration settings associated with the contract that may be used to set up an isolated execution environment for the activated software entity. The category may also specify one or more extension points to be used for communication between the activating and activated software entities. The category may also include a list of software entities that implement the category.

Abstract: Embodiments described herein are directed to updating the various software associated with a distributed application in a piecemeal fashion. All instances of the software are analyzed and separated into different portions, called “roles.” Each instance of a role is strategically assigned to an update domain based on the structural information included in the service model of the distributed application. The distributed application is upgraded one update at a time by selecting an update or host update domain, bringing the roles assigned thereto offline, updating the offline roles, bringing the roles back online, and repeating for other update or host update domains.

Abstract: The operating system manages software entities by creating a construct called a context that organizes and manages software-related state and configuration settings of applications. A context may comprise an installation service, a configuration service and an activation service. Contexts can be linked or arranged hierarchically to form parent-child relationships. Hierarchies may be used to affect accessibility of software items, to satisfy dependencies, to control the visibility/invisibility of software items, to provide access to configuration settings and to override software availability, dependencies and configuration settings. An override may be applied to set policy when more than one context has a configuration setting, dependency or access to a software entity.

Abstract: The database (namespace) for storing component metadata for an application that is to be run in an isolated environment is isolated by an operating system by storing the component metadata in a local set of information associated with the isolated application instead of in a global namespace. The operating system utilizes this local metadata instead of the global database when components are employed. Registration data for components is placed within a manifest, enabling the operating system to determine the relationship between an application and a component or set of components used by the application.

Abstract: The operating system manages software entities by creating a construct called a context that organizes and manages software-related state and configuration settings of applications. A context may comprise an installation service, a configuration service and an activation service. Contexts can be linked or arranged hierarchically to form parent-child relationships. Hierarchies may be used to affect accessibility of software items, to satisfy dependencies, to control the visibility/invisibility of software items, to provide access to configuration settings and to override software availability, dependencies and configuration settings. An override may be applied to set policy when more than one context has a configuration setting, dependency or access to a software entity.

Abstract: Software typically changes over its useful lifetime. New versions of software are created to change or improve functionality, to add functionality, to correct coding errors, improve performance, to adapt to new hardware and for many other well-known reasons. The process of delivering new versions of software to users is called servicing the software. The operating system decides which version(s) of a piece of software satisfy dependencies of other software by creation of a context. The context may be used to organize and manage versions of software, to declare activation policies concerning the use of different versions of software and to service the versioned software. The context may include an activation service that maintains and manages resolution polices, resolves dependencies, constructs the environment in which an application runs and initiates the running of the software.

Abstract: The operating system manages software entities by creating a construct called a context that organizes and manages software-related state and configuration settings of applications. A context may comprise an installation service, a configuration service and an activation service. Contexts can be linked or arranged hierarchically to form parent-child relationships. Hierarchies may be used to affect accessibility of software items, to satisfy dependencies, to control the visibility/invisibility of software items, to provide access to configuration settings and to override software availability, dependencies and configuration settings. An override may be applied to set policy when more than one context has a configuration setting, dependency or access to a software entity.

Abstract: Applications, such as cloud services, may be deployed within a network environment (e.g., a cloud computing environment). Unfortunately, when the applications are instantiated within the network environment, they have the ability to compromise the security of other applications and/or the infrastructure of the network environment. Accordingly, as provided herein, a security scheme may be applied to a network environment within which an application is to be instantiated. The security scheme may comprise one or more security layers (e.g., virtual machine level security, application level security, operating system level security, etc.) derived from an application service model describing the application and/or resources allocated to the application.

Abstract: A type server on a first machine assigns a sequential small integer identifier of fixed length to lengthy information. Identifying information using a small integer identifier provides efficiencies in communication between processes on a single machine as well as efficiencies in communication between processes on different machines. Storage of this information is also more efficient. The information so identified may be, for example, interface type. The small integer identifier assigned to the interface types may be assigned in a set enumeration scheme, that is the first interface type encountered when generating a list or table of interfaces types may be assigned the integer identifier “1”, the second “2” and so on. Similarly, the small integer identifiers may be assigned whenever a new interface type is encountered during execution. A translation table including interface type name and interface type identifier for may be generated.

Abstract: Embodiments described herein are directed to updating the various software associated with a distributed application in a piecemeal fashion. All instances of the software are analyzed and separated into different portions, called “roles.” Each instance of a role is strategically assigned to an update domain based on the structural information included in the service model of the distributed application. The distributed application is upgraded one update at a time by selecting an update or host update domain, bringing the roles assigned thereto offline, updating the offline roles, bringing the roles back online, and repeating for other update or host update domains.

Abstract: Object invocation may be carried out by one thread in a service which may include multiple executing threads. In a mechanism for implementing a cancellation operation in a cooperative system, a thread identifies an operation to be cancelled. A cancel function has an argument comprising the thread identifier in which the operation is to be cancelled. The cancel function is called by a client process thread to cancel a pending object invocation initiated by the client process. An immediate or hard cancel causes the targeted client and cancel thread to return immediately. A discretionary or soft cancel does not affect the targeted client thread. In either case the server process is notified via a maintenance notification. The target thread of the cancel cannot be reused for other work until the cancel request or notification has returned.

Abstract: Reference counting is shared between an in-process service runtime and a machine-wide service. The service maintains a global reference count, a global export count, and an exports before revoke count. When the global reference count for a resource or object drops to zero, the machine-wide service deletes the table entry for the object or resource and sends an unref message including the value of the global export count to the sharing process. If the local export count is greater than the global export count of the unref, there are committed exports which have not yet been unreferenced. If both counts are the same, the committed exports have been accounted for and a revoke operation can be issued.

Abstract: When a process running in an isolated execution environment is started by a user, the credentials of the user are associated with a naming environment for the isolated execution environment. The isolated execution environment may be implemented via creation of a namespace representing resources available to one or more processes running within the isolated execution environment. The resources available to the isolated processes may represent some subset of global resources. When a request to access a named resource is received, the request is mediated by the operating system. Access, if provided, may be provided via the naming environment associated with the isolated execution environment. The operating system determines whether to grant or deny access to the resource by checking the credentials associated with the naming environment with the ACL of the resource.

Abstract: An operating system architecture is based on a service model in which active entities (services) are containers for objects having a number of interfaces specified through a contract language that is a subset of the language in which the service is coded. Services may reside in the same address space or may reside in separate address spaces, without changing the programming model or compiled binaries. The location of a service is independent of the location of the service's clients and of services the service calls.

Abstract: A type server provides the proxy and stub code needed by client and server programs on demand (dynamically), when the code is needed during execution. When an interface for a resource is defined, the proxy code and the stub code for the type of resource is generated and stored within the type server. The client and server programs each keep a local table of type identifiers/resource type translations for each resource referenced. The local table acts like a cache: when a type identifier is not found in the table, the type server is contacted, and the type identifier for that resource type is retrieved and stored in the cache. Another local table acting as a cache stores type ID and associated proxy and stub code for the resource type. When a program needs the proxy code for a resource type, it checks its cache and it the proxy code is not found the type server is contacted, the proxy (and stub) code is retrieved from the type server and is stored in the cache.

Abstract: One embodiment of the present invention provides a method and an apparatus that facilitates transparent failovers from a primary copy of an object on a first server to a secondary copy of the object on a second server when the first server fails, or otherwise becomes unresponsive. The method includes detecting the failure of the first server; selecting the second server; and reconfiguring the second server to act as a new primary server for the object. Additionally, the method includes transparently retrying uncompleted invocations to the object to the second server, without requiring explicit retry commands from a client application program. A variation on this embodiment further includes winding up active invocations to the object before reconfiguring the second server to act as the new primary server. This winding up process may include causing invocations to unresponsive nodes to unblock and complete.

Abstract: A bit map is maintained by a provider object of a name server to keep track of names cached by a cache object of the client. The bit map is indexed by performing a hash of the name. When a name is looked up by the server on behalf of a client, the server hashes the name, and sets the bit in the bit map indexed by the result of the hash modulo the size of the bit map. The result of the hash is returned to the client and is stored with the entry in the cache. A bit "set" in the bit map indicates that the client caches at least one name that hashes into the bit. When the server invalidates a name, a hash of the name to be invalidated is used to find the corresponding bit in the bit mask. If the bit is set, the server sends an invalidation request to the client. The invalidation request includes the result of the hash, and the size of the provider's bit map. The client invalidates all entries that hash into the specified bit in the bitmap on the server.

Abstract: Transparent routing within the cluster is achieved (without changing the networking code on each node of the cluster) by using a pair of modules interposed appropriately on the networking stack. In a "clustered" system built out of several computers, using the present invention, the networking subsystem appears to applications as if the applications are running on a single computer. In addition, no modifications to the networking code is needed. The present invention is extensible to a variety of networking protocols, not just TCP/IP as the packet filter allows the routing within the cluster to be done dynamically. No modifications to the applications is needed (same binaries will work). A packet filter and remote communication between the modules through IDL enable the modules to do their job. A name server that maintains the port name space is used.