Abstract: A “trusted service” establishes a trust relationship with an identity provider and interacts with the identity provider over a trusted connection. The trusted service acquires a token from the identity provider for a given user (or set of users) without having to present the user's credentials. The trusted service then uses this token (e.g., directly, by invoking an API, by acquiring another token, or the like) to access and obtain a cloud service on a user's behalf even in the user's absence. This approach enables background services to perform operations within a hosted session (e.g., via OAuth-based APIs) without presenting user credentials or even having the user present.

Abstract: A “trusted service” establishes a trust relationship with an identity provider and interacts with the identity provider over a trusted connection. The trusted service acquires a token from the identity provider for a given user (or set of users) without having to present the user's credentials. The trusted service then uses this token (e.g., directly, by invoking an API, by acquiring another token, or the like) to access and obtain a cloud service on a user's behalf even in the user's absence. This approach enables background services to perform operations within a hosted session (e.g., via OAuth-based APIs) without presenting user credentials or even having the user present.

Abstract: A “trusted service” establishes a trust relationship with an identity provider and interacts with the identity provider over a trusted connection. The trusted service acquires a token from the identity provider for a given user (or set of users) without having to present the user's credentials. The trusted service then uses this token (e.g., directly, by invoking an API, by acquiring another token, or the like) to access and obtain a cloud service on a user's behalf even in the user's absence. This approach enables background services to perform operations within a hosted session (e.g., via OAuth-based APIs) without presenting user credentials or even having the user present.

Abstract: In an embodiment, a test installer is executed that includes woven advice located at join points. The join points are associated with methods in the test installer. When the advice in the test installer is executed, the advice saves identifiers of the associated join points and times of execution. Subsets of the join points are assigned to installation options. Each installation option causes a production installer to execute a combination of methods. In response to receiving an installation option, advice is woven into the production installer at the join points specified by the assigned subset. When the advice in the production installer is executed, the advice reports its join point identifier, and the production installer presents completion progress status based on the time that was saved for the join point identifier during execution of the test installer. In this way, progress status may be provided during the installation of programs.

Abstract: A “trusted service” establishes a trust relationship with an identity provider and interacts with the identity provider over a trusted connection. The trusted service acquires a token from the identity provider for a given user (or set of users) without having to present the user's credentials. The trusted service then uses this token (e.g., directly, by invoking an API, by acquiring another token, or the like) to access and obtain a cloud service on a user's behalf even in the user's absence. This approach enables background services to perform operations within a hosted session (e.g., via OAuth-based APIs) without presenting user credentials or even having the user present.

Abstract: In an embodiment, a test installer is executed that includes woven advice located at join points. The join points are associated with methods in the test installer. When the advice in the test installer is executed, the advice saves identifiers of the associated join points and times of execution. Subsets of the join points are assigned to installation options. Each installation option causes a production installer to execute a combination of methods. In response to receiving an installation option, advice is woven into the production installer at the join points specified by the assigned subset. When the advice in the production installer is executed, the advice reports its join point identifier, and the production installer presents completion progress status based on the time that was saved for the join point identifier during execution of the test installer. In this way, progress status may be provided during the installation of programs.

Abstract: An object oriented framework defines a generic order processing interface that creates an order, and that processes the order and generates requests to one or more fulfillment systems to fill the order. The generic order suitably includes one or more line items. One or more extensible interface classes are provided in the framework, which allows a user to define the order entry protocol for the relevant order fulfillment systems. Once properly extended, the framework is used to generate an executable framework application, which allows a client to enter a generic order, and which then generates the appropriate requests to fill the order with the appropriate order fulfillment system or systems. The framework of the preferred embodiments thus allows the specific knowledge of the back-end order fulfillment systems to be isolated to the extended portions of the framework, while the front-end order entry system has no knowledge of the order fulfillment systems that may be called upon to fill an order.