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: 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 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 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: 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: Unique identifiers referred to as “keys” are generated for objects stored on each node. When a container object including at least one embedded object is transferred from a sending node to a receiving node, the sending node sends the key uniquely identifying the embedded object to the receiving node to determine whether the embedded object is already stored on the receiving node. If the receiving node indicates that the embedded object is already stored at the receiving node, then the sending node determines that the embedded object does not need to be sent to the receiving node. In that case, if the embedded object has not been sent, the sending node does not send the embedded object. If the sending node has already started sending the embedded object, then the sending node terminates sending of the embedded object.

Abstract: Unique identifiers referred to as “keys” are generated for objects stored on each node. When a container object including at least one embedded object is transferred from a sending node to a receiving node, the sending node sends the key uniquely identifying the embedded object to the receiving node to determine whether the embedded object is already stored on the receiving node. If the receiving node indicates that the embedded object is already stored at the receiving node, then the sending node determines that the embedded object does not need to be sent to the receiving node. In that case, if the embedded object has not been sent, the sending node does not send the embedded object. If the sending node has already started sending the embedded object, then the sending node terminates sending of the embedded object.

Abstract: Unique identifiers referred to as “keys” are generated for objects stored on each node. When a container object including at least one embedded object is transferred from a sending node to a receiving node, the sending node sends the key uniquely identifying the embedded object to the receiving node to determine whether the embedded object is already stored on the receiving node. If the receiving node indicates that the embedded object is already stored at the receiving node, then the sending node determines that the embedded object does not need to be sent to the receiving node. In that case, if the embedded object has not been sent, the sending node does not send the embedded object. If the sending node has already started sending the embedded object, then the sending node terminates sending of the embedded object.

Abstract: Unique identifiers referred to as “keys” are generated for objects stored on each node. When a container object including at least one embedded object is transferred from a sending node to a receiving node, the sending node sends the key uniquely identifying the embedded object to the receiving node to determine whether the embedded object is already stored on the receiving node. If the receiving node indicates that the embedded object is already stored at the receiving node, then the sending node determines that the embedded object does not need to be sent to the receiving node. In that case, if the embedded object has not been sent, the sending node does not send the embedded object. If the sending node has already started sending the embedded object, then the sending node terminates sending of the embedded object.

Abstract: A system, method, and processor readable medium for processing data in a knowledge management system gathers information content and transmits a work request for the information content gathered. The information content may be registered with a content map and assigned a unique document identifier. A work queue processes the work requests. The processed information may then be transmitted to another work queue for further processing. Further processing may include categorization, full-text indexing, metrics extraction or other process. Control messages may be transmitted to one or more users providing a status of the work request. The information may be analyzed and further indexed. A progress statistics report may be generated for each of the processes performed on the document. The progress statistics may be provided in a record. A shared access to a central data structure representing the metrics history and taxonomy may be provided for all work queues via a CORBA service.

Abstract: A system, method, and processor readable medium for processing data in a knowledge management system gathers information content and transmits a work request for the information content gathered. The information content may be registered with a content map and assigned a unique document identifier. A work queue processes the work requests. The processed information may then be transmitted to another work queue for further processing. Further processing may include categorization, full-text indexing, metrics extraction or other process. Control messages may be transmitted to one or more users providing a status of the work request. The information may be analyzed and further indexed. A progress statistics report may be generated for each of the processes performed on the document. The progress statistics may be provided in a record. A shared access to a central data structure representing the metrics history and taxonomy may be provided for all work queues via a CORBA service.