Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for accessor classes, preferably along with actions to be taken in the event an accessor exceeds those limits. A set of accessor “usage profiles” are generated. Typically, a profile comprises information, such as a “request time window,” one or more “constraints,” and one or more “actions.” A request time window defines a time period over which request usage is accumulated and over which constraints are applied. A constraint may be of various types (e.g., number of transactions, defined resource usage limits, etc.) to be applied for the usage monitoring An action defines how the system will respond if a particular constraint is triggered. By applying the constraints to accessor requests, over-utilization of compute resources is enabled.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for accessor classes, preferably along with actions to be taken in the event an accessor exceeds those limits. A set of accessor “usage profiles” are generated. Typically, a profile comprises information, such as a “request time window,” one or more “constraints,” and one or more “actions.” A request time window defines a time period over which request usage is accumulated and over which constraints are applied. A constraint may be of various types (e.g., number of transactions, defined resource usage limits, etc.) to be applied for the usage monitoring An action defines how the system will respond if a particular constraint is triggered. By applying the constraints to accessor requests, over-utilization of compute resources is enabled.

Abstract: Techniques are described above for smoothing peak load in collaborative systems. One embodiment includes, prior to a predicted peak load period, pre-staging user-data associated with one or more users of the collaborative system. During the predicted peak load period, a request from a first one of the users for access to the pre-staged user-data associated with the first user is received. And in response to the request, the pre-staged user-data is provided to the first user.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for accessor classes, preferably along with actions to be taken in the event an accessor exceeds those limits. A set of accessor “usage profiles” are generated. Typically, a profile comprises information, such as one or more “constraints,” and one or more “actions.” At least one constraint is generated by applying one or more parameters of a transaction weighting function such that the resulting constraint represents an actual or estimated cost of executing the transaction. An action defines how the system will respond if a particular constraint is triggered. By applying the constraints to accessor requests, the approach prevents over-utilization of compute resources.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: Techniques are described above for smoothing peak load in collaborative systems. One embodiment includes, prior to a predicted peak load period, pre-staging user-data associated with one or more users of the collaborative system. During the predicted peak load period, a request from a first one of the users for access to the pre-staged user-data associated with the first user is received. And in response to the request, the pre-staged user-data is provided to the first user.

Abstract: Techniques are described above for smoothing peak load in collaborative systems. One embodiment includes, prior to a predicted peak load period, pre-staging user-data associated with one or more users of the collaborative system. During the predicted peak load period, a request from a first one of the users for access to the pre-staged user-data associated with the first user is received. And in response to the request, the pre-staged user-data is provided to the first user.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for tenant applications or application classes, preferably along with actions to be taken in the event a request to execute an application is anticipated to exceed defined workflow limits. A set of application profiles are generated. Typically, a profile comprises information, such as a request defined by one or more request variables, one or more “constraints,” one or more “request mappings,” and one or more “actions.” A constraint is a maximum permitted workload for the application. A request mapping maps a request variable to the constraint, either directly or indirectly. The profile information defines how a request is mapped to a workload to determine whether the request is in policy or, if not, what action to take.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for accessor classes, preferably along with actions to be taken in the event an accessor exceeds those limits. A set of accessor “usage profiles” are generated. Typically, a profile comprises information, such as a “request time window,” one or more “constraints,” and one or more “actions.” A request time window defines a time period over which request usage is accumulated and over which constraints are applied. A constraint may be of various types (e.g., number of transactions, defined resource usage limits, etc.) to be applied for the usage monitoring An action defines how the system will respond if a particular constraint is triggered. By applying the constraints to accessor requests, over-utilization of compute resources is enabled.

Abstract: Techniques are described above for smoothing peak load in collaborative systems. One embodiment includes, prior to a predicted peak load period, pre-staging user-data associated with one or more users of the collaborative system. During the predicted peak load period, a request from a first one of the users for access to the pre-staged user-data associated with the first user is received. And in response to the request, the pre-staged user-data is provided to the first user.

Abstract: Denial-of-service attacks are prevented or mitigated in a cloud compute environment, such as a multi-tenant, collaborative SaaS system. This is achieved by providing a mechanism by which characterization of “legitimate” behavior is defined for accessor classes, preferably along with actions to be taken in the event an accessor exceeds those limits. A set of accessor “usage profiles” are generated. Typically, a profile comprises information, such as a “request time window,” one or more “constraints,” and one or more “actions.” A request time window defines a time period over which request usage is accumulated and over which constraints are applied. A constraint may be of various types (e.g., number of transactions, defined resource usage limits, etc.) to be applied for the usage monitoring An action defines how the system will respond if a particular constraint is triggered. By applying the constraints to accessor requests, over-utilization of compute resources is enabled.

Abstract: Techniques are described above for smoothing peak load in collaborative systems. One embodiment includes, prior to a predicted peak load period, pre-staging user-data associated with one or more users of the collaborative system. During the predicted peak load period, a request from a first one of the users for access to the pre-staged user-data associated with the first user is received. And in response to the request, the pre-staged user-data is provided to the first user.

Abstract: A request is received by a first computer. The first computer delegates the first request to a second computer. The second computer attempts to process the first request and identifies an imminent fault as a result of the attempt. The second computer sends a message to the first computer indicating an imminent fault as a result of the attempted processing of the first request. The first computer sends a message to a third computer indicating that a second request matching the first request should not be processed.

Abstract: A system for providing single sign-on (SSO) user names for Web cookies. SSO access to multiple applications is supported in situations where multiple user information directories are deployed, and users may be known by multiple identifiers. Convenient specification is enabled for which of a user's multiple names is to be used in an SSO Web cookie that is passed from application to application to enable SSO operation. The user's SSO Web cookie user name is fully separated conceptually from the user's effective name for any given application within the SSO environment. The SSO Web cookie user name provided by the disclosed system is specified independently from the effective name by which the user is known when operating in the Web application that writes the SSO Web cookie back to the user's computer system. Use of an administratively supplied user name in the SSO Web cookie is facilitated.

Abstract: Techniques are described above for smoothing peak load in collaborative systems. One embodiment includes, prior to a predicted peak load period, pre-staging user-data associated with one or more users of the collaborative system. During the predicted peak load period, a request from a first one of the users for access to the pre-staged user-data associated with the first user is received. And in response to the request, the pre-staged user-data is provided to the first user.

Abstract: A system for providing single sign-on (SSO) user names for Web cookies in a multiple user information directory environment. SSO access to multiple applications is supported in situations where multiple user information directories are deployed, and users may be known by multiple identifiers. Convenient specification is enabled for which of a user's multiple names is to be used in an SSO Web cookie that is passed from application to application to enable SSO operation. The user's SSO Web cookie user name is fully separated conceptually from the user's effective name for any given application within the SSO environment. The SSO Web cookie user name provided by the disclosed system is specified independently from the effective name by which the user is known when operating in the Web application that writes the SSO Web cookie back to the user's computer system. Use of an administratively supplied user name in the SSO Web cookie is facilitated.

Abstract: The present invention provides a method, system and program product for replicating message status changes across messaging systems. Specifically, under the present invention, when a status of a message for a user is changed on a messaging system, the status change is entered into a log associated with the user along with a clock time of the messaging system. The status change is then replicated to a replica messaging system along with the clock time of the original messaging system. Upon receipt, the replica messaging system will ensure that the status change is the most recent activity for the message. If so, the status change will be entered into a log of the replica messaging system along with the clock time of the original messaging system and a clock time of the replica messaging system.