Abstract: A maximum lag between data stores can be specified that corresponds to a recovery point objective defined in a service level agreement. Lag can be monitored during a data replication between a primary data store and a secondary data store located in geographically different regions. Activity on the primary data store including incoming data transactions can be throttled as a function of the lag and the maximum lag.

Abstract: A maximum lag between data stores can be specified that corresponds to a recovery point objective defined in a service level agreement. Lag can be monitored during a data replication between a primary data store and a secondary data store located in geographically different regions. Activity on the primary data store including incoming data transactions can be throttled as a function of the lad and the maximum lag.

Abstract: A maximum lag between data stores can be specified that corresponds to a recovery point objective defined in a service level agreement. Lag can be monitored during a data replication between a primary data store and a secondary data store located in geographically different regions. Activity on the primary data store including incoming data transactions can be throttled as a function of the lag and the maximum lag.

Abstract: A maximum lag between data stores can be specified that corresponds to a recovery point objective defined in a service level agreement. Lag can be monitored during a data replication between a primary data store and a secondary data store located in geographically different regions. Activity on the primary data store including incoming data transactions can be throttled as a function of the lag and the maximum lag.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters. Accordingly, embodiments herein provide for a sending side with enough intelligence to isolate each command, examine it, perform some levels of validation, and deliver a structured representation of the command to the remote processor before doing any network operations. More specifically, embodiments herein provided for a mechanism of identifying a command and encapsulating the command into a single message (e.g., a SOAP, HTTPS, or other type message), which is then sent to a remote shell for processing as an entire unit. Accordingly, embodiments herein treat the command as a single unit, rather than as a character-oriented transmission.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters. Accordingly, embodiments herein provide also provide for some special cases of asynchronous control signals that change the shell operation flow. For example, signal messages may be used to terminate, pause, resume, or otherwise modify the execution of a command. In other words, if a user wishes to change the execution state of a command, a client can create a signal message and send such message to the shell processor, which can take the appropriate action as desired. Note that by modeling the control or signal commands as discrete messages (as well as other embodiments modeled and described herein), such commands are not mistakenly executed on a command as is the case for current protocols that use a character-by-character transmission.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters. Accordingly, embodiments herein provide for a sending side with enough intelligence to isolate each command, examine it, perform some levels of validation, and deliver a structured representation of the command to the remote processor before doing any network operations. More specifically, embodiments herein provided for a mechanism of identifying a command and encapsulating the command into a single message (e.g., a SOAP, HTTPS, or other type message), which is then sent to a remote shell for processing as an entire unit. Accordingly, embodiments herein treat the command as a single unit, rather than as a character-oriented transmission.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters sent within a message. Accordingly, embodiments herein provide for establishing a remote processing session for commands by using a binding mechanism that binds a series of commands to a remote shell using a message rather than a binary stream of data. More specifically, embodiments herein provided for a mechanism of encapsulating both a command and a binding mechanism (e.g., a shell identifier and/or shell token) into a single message. Accordingly, the binding mechanism can be used throughout the lifetime of the session and allows for modeling the shell processor session (its lifetime) as a series of commands, rather than as a series of characters. In addition, note that because the binding mechanism for the shell sessions is sent within messages, the problems associated with binary or character-by-character establishment of current shell sessions are overcome.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters. Accordingly, embodiments herein provide for a sending side with enough intelligence to isolate each command, examine it, perform some levels of validation, and deliver a structured representation of the command to the remote processor before doing any network operations. More specifically, embodiments herein provided for a mechanism of identifying a command and encapsulating the command into a single message (e.g., a SOAP, HTTPS, or other type message), which is then sent to a remote shell for processing as an entire unit. Accordingly, embodiments herein treat the command as a single unit, rather than as a character-oriented transmission.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters. Accordingly, embodiments herein provide also provide for some special cases of asynchronous control signals that change the shell operation flow. For example, signal messages may be used to terminate, pause, resume, or otherwise modify the execution of a command. In other words, if a user wishes to change the execution state of a command, a client can create a signal message and send such message to the shell processor, which can take the appropriate action as desired. Note that by modeling the control or signal commands as discrete messages (as well as other embodiments modeled and described herein), such commands are not mistakenly executed on a command as is the case for current protocols that use a character-by-character transmission.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters sent within a message. Accordingly, embodiments herein provide for establishing a remote processing session for commands by using a binding mechanism that binds a series of commands to a remote shell using a message rather than a binary stream of data. More specifically, embodiments herein provided for a mechanism of encapsulating both a command and a binding mechanism (e.g., a shell identifier and/or shell token) into a single message. Accordingly, the binding mechanism can be used throughout the lifetime of the session and allows for modeling the shell processor session (its lifetime) as a series of commands, rather than as a series of characters. In addition, note that because the binding mechanism for the shell sessions is sent within messages, the problems associated with binary or character-by-character establishment of current shell sessions are overcome.

Abstract: Embodiments described herein are based on the principle that shells execute commands as units of characters. Accordingly, embodiments herein provide for a sending side with enough intelligence to isolate each command, examine it, perform some levels of validation, and deliver a structured representation of the command to the remote processor before doing any network operations. More specifically, embodiments herein provided for a mechanism of identifying a command and encapsulating the command into a single message (e.g., a SOAP, HTTPS, or other type message), which is then sent to a remote shell for processing as an entire unit. Accordingly, embodiments herein treat the command as a single unit, rather than as a character-oriented transmission.

Abstract: An event management system includes an email consumer for handling email, a paging consumer, an active scripting consumer, a log file consumer, an event log consumer, and a command line consumer. The events in the event management system are represented as objects and each consumer is represented as a class. The system also includes an event forwarding consumer to forward events. The event management system allows the creation of an instance of an event filter which filters events based on event filter properties. The system also allows the creation of an instance of an event consumer which defines an action and creation of a binding between the instance of the event filter and the instance of the event consumer such that the binding includes properties identifying the instance of the event filter and the instance of the event consumer.

Abstract: A template creator creates a template class that stores at least one template parameter. The template creator also specifies at least one additional object to be created when an instance of the template class is created. A template user initiates the creation of a new instance of the template class. If an error occurs during the creation of the new instance of the template class, the template user receives a report identifying the error.

Abstract: Subscription-based notification using event channels that each correspond to a particular scope. Each channel manages notifications through the use of a schema definition. The event subscriptions identify the position and attributes that any desired event notification would take in the schema definition. The channel then receives event notifications in the form of XML fragments. The channel then determines the position that the XML fragment would take as defined by the schema definition. The channel determines whether the position and attributes of the event notification matches the position and attributes of the event subscription. If a match is found, then the event notification is copied and forwarded to the recipient designated in the corresponding subscription.

Abstract: Subscription-based notification using event channels that each correspond to a particular scope. Each channel manages notifications through the use of a a schema definition. The event subscriptions identify the position and attributes that any desired event notification would take in the schema definition. The channel then receives event notifications in the form of XML fragments. The channel then determines the position that the XML fragment would take as defined by the schema definition. The channel determines whether the position and attributes of the event notification matches the position and attributes of the event subscription. If a match is found, then the event notification is copied and forwarded to the recipient designated in the corresponding subscription.