Browse Prior Art Database

Automated Topology Alerts Based on Scenario Simulation Disclosure Number: IPCOM000212071D
Publication Date: 2011-Oct-27
Document File: 9 page(s) / 292K

Publishing Venue

The Prior Art Database


Disclosed is a method for providing automatic feedback about performance constraint violations when making changes to a related topology and/or scenario model. The disclosed method includes a change impact analysis where the minimal set of affected scenarios is computed. These scenarios are then simulated and data is collected which is evaluated against available performance constraints. Finally, those constraint evaluations that failed are reported.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 19% of the total text.

Page 01 of 9

Automated Topology Alerts Based on Scenario Simulation

Disclosed is a solution to the following problem:

How can immediate feedback be obtained if changes made to a topology and/or scenario cause any performance constraints to become violated for an application?

For example, what will happen if a user:

moved a computer server from one physical location to another

moved a company compartment from one country to another

got a disruption on one of the critical links in the topology (such as a network

    Today it is common to completely neglect such "what-if" analysis during the design of an application. This often leads to unpleasant surprises when the application is deployed for use.

    One way to address the problem is to actually perform the change and measure the effect of it. However, this requires that the application and topology really exist, so this method cannot be used during the design phase which is a big drawback.

    Another solution is to use some sort of computations where critical scenarios are analyzed against the topology. However, a drawback is that such computations are typically complex and time consuming and can usually only be done by experts. Even if tools can help with the computations the problem is that they are not automatically performed when the change takes place. The designer who wants to change the topology or a scenario therefore cannot get any immediate feedback if the change will violate any of the performance constraints that have been defined. When problems are detected later, multiple changes may have been made and it is not possible to know which of these changes caused the problems.

    The idea described in this document uses simulation as the means to collect the data that is required for the evaluation of performance constraints. The main difficulty that has been overcome with this approach is to find a way to limit the number of scenarios that need to be simulated when a topology changes. The solution to this problem makes it possible to provide close to immediate feedback about constraint violations, just after the topology changes have been committed. This makes it possible to implement this idea for realistically sized applications, where the number of scenarios typically is very large.

The following definitions are important to the understanding of this idea:
A topology is a description of how resources are structured and connected

to each other by means of links. Examples of resources are humans, computers, companies etc. Examples of links are network connections, telephone lines etc.

    An application is a coordinated flow of actions performed on one or many resources. Examples of applications are computer programs, business processes etc. Examples of actions are storing data in a database, writing an e-mail, sending an invoice, etc.

    A scenario is a grouping of actions which are related and together form a piece of functionality. Examples of scenarios are open a new bank account, login to...