US20150205702A1 - Service modeling and virtualization - Google Patents

Abstract

The systems and methods described herein can be used to provide virtual service environments. In one embodiment, a virtual service model is generated by detecting one or more transactions, each of which includes a request sent from a requester to a software service and a response sent from the software service to the requester; storing information describing the detected transactions in a virtual service model, where the information describing each transaction includes information identifying a command included in the request and information identifying a response attribute included in the response; and generating information describing an unknown transaction, where the information describing the unknown transaction includes information identifying a first command and information identifying a first response attribute. The first command and the first response attribute are copies of a corresponding command and a corresponding response attribute associated with a corresponding one of the detected transactions.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This Application is a continuation and claims the benefit of priority under 35 U.S.C. §120 of U.S. application Ser. No. 13/341,650 filed on Dec. 30, 2011 and entitled “Service Modeling and Virtualization”, which application is a continuation of U.S. patent application Ser. No. 12/242,783, filed Sep. 30, 2008, now issued as U.S. Pat. No. 8,112,262 and entitled “Service Modeling and Virtualization”, naming John J. Michelsen as inventor. The disclosures of the prior Applications are considered part of and are incorporated by reference in the disclosure of this Application.
FIELD OF THE INVENTION
• This invention relates to testing and, more particularly, to systems for testing software that depends on and/or interacts with a constrained service that may not always be available for use during testing.
DESCRIPTION OF RELATED ART
• As software becomes more sophisticated, it becomes more difficult to quickly and easily perform thorough software testing. One such difficulty arises when software testing involves testing the ability of a program or application under test to interact with a constrained software resource, such as a database, metered partner service, or the like. For example, an airline may be reluctant to test a new reservation application against the airline's live production database in order to avoid negatively impacting (e.g., in terms of database response time) actual consumer transactions that will be taking place at the same time as testing. Similarly, in order to reduce costs, a financial institution may wish to minimize interactions between a new credit card application system and a partner service due to per-transaction fees, such as those that are charged for each credit check, charged by the partner service. In yet another example, the constrained service may still be in development and thus not yet available to interact with the application under test. As the above examples show, it is desirable to be able to test the application under test in a manner that avoids interacting with the actual constrained service, while also obtaining test results that indicate whether the application under test will ultimately be able to properly interact with the constrained service.
BRIEF DESCRIPTION OF THE DRAWINGS
• A more complete understanding of the present invention may be acquired by referring to the following description and the accompanying drawings, in which like reference numbers indicate like features.
• FIG. 1 is a block diagram of a system that generates a model of a service, according to one embodiment of the present invention.
• FIG. 2 shows information that can be maintained as part of a model of a service, according to one embodiment of the present invention.
• FIG. 3 is a flowchart of a method of generating a model of a service, according to one embodiment of the present invention.
• FIG. 4 is a block diagram of a system that presents a virtual database service, according to one embodiment of the present invention.
• FIG. 5 is a flowchart of a method of presenting a virtual service, according to one embodiment of the present invention.
• FIG. 6 is an illustration of a data model that can be used to store information representing both stateful and stateless transactions, according to one embodiment of the present invention.
• FIG. 7A shows an example of several stateful conversations that can be observed and recorded by a service model generator, according to one embodiment of the present invention.
• FIG. 7B is an example of how several stateful conversations can be merged into a single conversation, according to one embodiment of the present invention.
• FIG. 8 is a block diagram of software that can be stored on a testing client, according to one embodiment of the present invention.
• FIG. 9 is a block diagram of software that can be stored on a testing server, according to one embodiment of the present invention.
• While the invention is susceptible to various modifications and alternative forms, specific embodiments of the invention are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the invention to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
DETAILED DESCRIPTION
• Various embodiments of the systems and methods described herein can be used to provide virtual service environments. These virtual service environments can be used for various purposes, including development, testing, load testing, integration testing, and training. In many situations, the services to virtualize within virtual service environments can be identified during the software design phase, and then the identified services can be virtualized and implemented within virtual service environments during the development phase. The virtual service environments can then be used throughout the development and testing phases.
• The virtual service environments operate to present one or more virtual services. Each virtual service responds to requests in a manner that is structurally consistent with the service being virtualized. Providing virtual services allows an application (e.g., an application under test or an application being used for training purposes) to interact with a virtualized representation of a software service that might not otherwise be readily available (e.g., due to constraints associated with that software service) for testing or training purposes.
• FIG. 1 is a block diagram of a system that generates a model of a software service. This system includes arequester10, aservice model generator20, andsoftware service30. In many embodiments, these components are each implemented in software that is executing on a computing device (e.g., a personal computer, server, personal digital assistant, telephone, or the like). The components shown inFIG. 1 can all be implemented on the same computing device. However, in many embodiments, at least some of these components (or portions thereof) will be implemented on different computing devices, all or some of which can be coupled via one or more networks (e.g., a local area network, storage area network, and/or wide area network such as the Internet).
• Service30 can be any of a variety of different services and can be implemented as any one or more of a variety of software components. For example,service30 can be a database server that is configured to respond to requests to access information stored in a database. Alternatively,service30 can be a web service (e.g., having an interface defined by a web service definition language (WSDL) file), a web site (e.g., as implemented by one or more web pages provided by a web server), a legacy application operating on a mainframe, a data service, an order manager, a transactional data store, an enterprise resource planning (ERP) system, an enterprise application integration (EAI) system, or the like.Service30 can be implemented as an object or other component (e.g., an enterprise service bus (ESB) construct, an Enterprise JavaBean (EJB), a web component such as a JavaServer Pages (JSP) page or Java servlet component, other standalone Java component, or Java applet), as an application that includes any of the previously-mentioned components, or the like.
• Requester10 can similarly be implemented as any of a variety of different software components (or a combination of such components). In some embodiments, there may be multiple independent requesters present and generating requests at substantially the same time. In such embodiments,service model generator20 can detect requests being generated by more than one requester, as well as the responses provided in response to those different requesters' requests.
• As shown inFIG. 1,requester10 generates a request, which is sent toservice30. In response to receiving the request,service30 generates a response and returns the response to requester10.Service model generator20 is coupled (e.g., logically and/or physically) betweenrequester10 andservice30, such thatservice model generator20 can effectively observe and record the traffic (i.e., the requests and responses) being exchanged betweenrequester10 andservice30. For recording purposes, each request and its corresponding response are grouped together, and a group containing a request and its corresponding response is referred to herein as a transaction. The recorded transactions are stored as aservice model40, which will be used to implement a virtual service environment that virtualizesservice30, as will be described in more detail below with respect toFIGS. 4-6. An example of the information that can be stored as part of a service model is provided inFIG. 2.
• A user can also provide information describing transactions toservice model generator20 for inclusion inservice model40. Such transactions are referred to as user-supplied transactions, in contrast to the observed transactions that are recorded in response toservice model generator20 actually observing traffic being exchanged betweenrequester10 andservice30.
• Service model generator20 can also generate and store information identifying one or more characteristics of the transactions. Such information can include timing information identifying times at which particular requests and/or responses are detected or sent (e.g., in order to identify the delay between when the request was detected and/or sent and when the associated response was detected and/or sent), information identifying current bandwidth usage of a network on which the traffic is being conveyed, information identifying current processor and/or memory usage on one or both of the computingdevices implementing requester10 andservice30, and the like.Service model generator20 can store such information as part ofservice model40.
• Service model generator20 is configured to detect and record traffic at the network and/or communication protocol level. The particular communication protocol can vary according to the type of service provided byservice30.Service model generator20 can be configured to identify requests and responses in each of a variety of different protocols and to extract and record the pertinent information from each. Thus,service model generator20 can include configuration information identifying the basic structure of requests and responses for each of several supported communication protocols. When generatingservice model40,service model generator20 can access the appropriate configuration information in order to process the observed traffic. Depending upon the protocol in use, requests can take the form of method calls to an object, queue and topic-type messages (e.g., such as those used in Java messaging service (JMS)), requests to access one or more web pages or web services, database queries (e.g., to a structured query language (SQL) or Java database connectivity (JDBC) application programming interface (API)), packets or other communications being sent to a network socket, and the like. Similarly, responses can include values generated by invoking a method of an object, responsive messages, web pages, data, state values (e.g., true or false), and the like.
• In order to be able to detect and record traffic,service model generator20 is configured to logically insert itself into the communication pathway betweenrequester10 andservice30. In some embodiments, insertingservice model generator20 into the communication pathway can also involve modifyingrequester10 and/or software (e.g., such as a driver) with which requester10 interacts. For example, ifservice30 is a web site or web service,service model generator20 can be configured as a web proxy or gateway, and requester10 can be modified to communicate withservice30 via the proxy or gateway implemented byservice model generator20. In such a situation, whenservice model generator20 receives a request being sent to the proxy,service model generator20 can generate and store information identifying the request and/or any desired request characteristics, and thenservice model generator20 can send the request toservice30. If needed,service model generator20 can modify the request before sending the request toservice30, so that the response generated byservice30 will be returned toservice model generator20.
• Various other configurations ofservice model generator20 are possible. For example, ifrequester10 andservice30 communicate via messaging,service model generator20 can be configured to monitor the appropriate queue(s) and topics for new messages being exchanged betweenrequester10 andservice30. Ifservice30 is a database, the driver manager used by requester10 can be modified to indicate thatservice model generator20 is the driver for the database, such that requests sent to the database will be provided toservice model generator20, and such that responses provided by the database will be returned to the requester viaservice model generator20. Ifservice30 is an object,service model generator20 can be configured to intercept method calls to the object, generate information identifying those method calls to be stored as part ofservice model40, and then to pass the method call to the object being called. Similarly,service model generator20 can intercept responses from the object being called, store information identifying those responses as part ofservice model40, and then provide those responses to requester20.
• In some embodiments, the functionality provided byservice model generator20 is distributed throughout a networked system. For example, a component ofservice model generator20 that is configured to monitor requests and responses sent according to a particular transport and/or data communication protocol can be deployed on each client system that includes a requester10 and/or each system that implementsservice30. This component can be configured to communicate requests and responses to another component ofservice model generator20 that is configured to manipulate such information and/or to store such information with aservice model40.
• Each request includes a command. The command can be the operation included in a SOAP message, the method being invoked on an object, a database command, a particular command or operation specified by a communication protocol, or the like. Wheneverservice model generator20 detects a request,service model generator20 can identify the command contained within that request (e.g., using configuration information associated with the type of protocol in use in order to identify which portion of the request contains command information) and store information identifying that command as part ofservice model40.
• Requests may also include attributes. For example, the request can include a command to perform a login operation as well as attributes that include the user name and password to be used in the login operation. Accordingly,service model generator20 can also parse requests in order to identify whether any attributes are present and, if so, to extract and store information identifying those attributes. Thus, information identifying a request inservice model40 can include information identifying a command as well as information identifying any attributes present within the request.
• Responses can include one or more attributes. Wheneverservice model generator20 detects a response,service model generator20 parses that response (e.g., using protocol-specific configuration information in order to determine how to locate the attributes within the response).Service model generator20 can then store each attribute detected within the response as part of the information identifying the response withinservice model40.
• Whenservice model40 is used to virtualize service30 (as will be explained in greater detail below), the virtualization process will involve comparing new requests generated by a requester to the request information stored inservice model40. For example, if a new request containing a particular command and attribute is received,service model40 can be searched for a matching request that contains the same command and attribute. If a matching request is found, the virtualization process returns the response (as identified by information stored in service model40) associated with the matching request to the requester.
• In many situations, the requests provided to the virtualized service will not be exactly the same (i.e., containing the same request as well as the same attribute(s)) as the requests identified inservice model40. For example, a request provided to the virtualized service may contain the same request but a different attribute or set of attributes. Accordingly,service model generator20 is also configured to generate information usable to handle these requests and to store that information as part ofservice model40.
• In order to generate this additional information,service model generator20 can identify each unique type of transaction that has been observed or specified by a user. For example, in some embodiments,service model generator20 can be configured to identify all transactions containing requests that specify the same command as being of the same transaction type. Alternatively,service model generator20 can be configured to identify a set of transactions as being of the same type if all of those transactions have requests that include the same command as well as the same number and type of attributes. The particular technique used to identify whether two or more transactions are of the same type can be protocol specific, in some embodiments (e.g.,service model generator20 can use different techniques to classify transactions depending upon the particular communication protocol being used between the requester and the service).
• For each unique type of transaction included in service model40 (e.g., obtained either via observation of communication or via user specification),service model generator20 can generate additional information that can be used tomodel service30's response to a similar transaction of that type that contains an unknown attribute (i.e., an unknown attribute in this context is an attribute that was not observed as part of the monitored traffic or specified by a user during the model building process). For example,service model generator20 can observe and record three different simple object access protocol (SOAP) requests that include the “getUser” command, and a user can specify a fourth “getUser” transaction for inclusion inservice model40. In response to identifying that these transactions are the same type of transaction,service model generator20 generates information describing a fifth “getUser” transaction that will be used to handle transactions of that type that specify unknown attributes. This information for the fifth transaction can include information identifying the request by the “getUser” command as well as information identifying the appropriate structure, if any, of the request (e.g., by identifying the number and/or type of attributes that can be included in the request, as determined from the other four transactions of that type). The information describing the attributes of the request of this transaction can be wildcard information or otherwise indicate that any unknown attribute(s) (i.e., attributes that are not the same as the attribute(s) in the observed and user-specified transactions) should match this request's attribute information.
• The information describing the fifth transaction also includes information identifying an appropriate response. In one embodiment,service model generator20 generates this response information by simply copying the response portion of the information describing one of the other four “getUser” transactions into the information describing the response portion of the fifth transaction.Service model generator20 can also or alternatively prompt a user to select the particular transaction from which this response information should be copied.
• Similarly,service model generator20 can also generate information describing a transaction that is used to modelservice30's response to an unknown request (i.e., an unknown request in this context is a request that contains a command that was not observed as part of the monitored traffic or specified by a user during the model building process). The request portion of this generated information can indicate (e.g., through the use of a wildcard command identifier) that all unknown types of requests that are not otherwise identified inservice model40 should match this request. The response portion of the generated information can include an appropriate response. In some embodiments, the response is protocol-specific and can be obtained, for example, from protocol-specific configuration information accessed byservice model generator20. Alternatively,service model generator20 can prompt a user for the appropriate response to include in this transaction.
• In some embodiments,service model generator20 can provide (or otherwise be configured via) a user interface (e.g., such as user interface480 ofFIG. 4) that allows a user to configureservice model generator20 to generate a particular service model. Such a user interface can be a graphical user interface, command line interface, or the like.
• The configuration process forservice model generator20 can involve the user selecting, via the user interface, theparticular service30 to be modeled. As part of the configuration process, the user can be prompted to enter information identifying a specific service to be modeled (e.g., service30), as well as information identifying or indicating the protocol(s) used to communicate with the identified service. For example, the user can identify a specific service by indicating the network port used to communicate with that service, as well as that hyper text transfer protocol (HTTP) and SOAP are used to communicate with that service. In response to this information being provided,service model generator20 can insert itself in between the requester and the service to be modeled. For example, an instance of an observation module (not shown) that is configured to obtain request and response information for the specified transport and/or data communication protocols can be instantiated. This observation module is part ofservice model generator20 and performs the functions needed to obtain information describing the requests generated by the requester and the corresponding responses generated by the service.
• Service model generator20 can also provide a user interface that includes one or more controls that allow a user to configure, start, and stop the model building process. Another control can allow a user to save a model generated byservice model generator20. Yet another control can allow a user to modify a model generated by service model generator20 (e.g., a user can be allowed to modify or delete all or some of the information generated by service model generator20). Similarly, a user can be allowed to modify a model by adding additional information (e.g., identifying new types of requests and associated responses, identifying new attributes for a particular type of requests and associated responses, and/or identifying responses to be used for unknown requests).
• Thus,service model generator20 can begin and end the model building process in response to user input provided at the time that modeling should begin and end. Alternatively, instead of selecting a “start” or stop” option, the user can specify a time and/or conditions under which model building should begin, as well as a time and/or conditions under which model building should end. For example, a user can specify that model building should begin at 1:00 AM on a particular date, and continue until 3000 transactions have been recorded. Similarly, a user can specify that model building should begin when a particular type of request is detected, and continue until the user selects to end the model building process.
• Furthermore, the model building process can be restarted. For example, a user can causeservice model generator20 to generate a model of a particular service. At a future point in time, the user can restart the model building process for the same service, causingservice model generator20 to generate additional information to include in the service model for that service. Similarly, a user may select to edit an existing service model in order to add additional virtual functionality (e.g., in the form of new types of transactions and/or additional transactions of an existing type) to the model.
• In some situations, instead of creating at least a portion of a model based upon actual observed traffic,service model generator20 can create a model based only upon user input specifying particular transactions (information describing additional observed transactions could be added at a later time). For example, if such information is not already available,service model generator20 can prompt a user for information identifying the service to be modeled, as well as information indicating the protocol used to communicate with the service to be modeled.Service model generator20 can then prompt the user for appropriate information (e.g., given the type of service being modeled and the communication protocol(s) used to communicate with that service) identifying one or more transactions. This information can include information identifying a request (e.g., by identifying the command contained within that request, as well as any attributes provided as part of that request) and a corresponding response (e.g., by identifying one or more attributes contained within the response), as well as information identifying a characteristic of that request and/or response. In situations in whichservice30 is not available (e.g., becauseservice30 is still being developed), all of the transactions identified inservice model40 can be obtained via user input instead of via traffic observation.
• In one embodiment, a user can specify multiple transactions at once. For example, when prompted, a user can select a file (e.g., a spreadsheet file) that contains information describing many different transactions. Such a file can be, for example, a production log that describes the activity taking place in a production system during a normal period of operation. In response to the user specifying the file,service model generator20 can access the file, extract the relevant information, and store the extracted information in the model. In some embodiments,service model generator20 can access an appropriate configuration file that indicates how particular fields in the production log (or other file specified by the user) map to the different types of information maintained in the service model (e.g., the particular configuration file to access can be specific to the service, the protocol(s) used to communicate with the service, or the like).
• As noted above, a user can also modify the information describing one or more observed transactions. In some embodiments, a user can relax the matching criteria associated with a transaction. For example, an observed request can include a command requesting for flight information from a particular origination city to a particular destination city, and the virtual service model may default to matching only requests that include the same command and attributes. A user can select to modify the information describing this command and can replace one or more of the request attributes with special values (e.g., wildcard values) and/or select a matching setting (e.g., specifying exact matching, regular expressions, “starts with” matching, “contains” matching, or the like) for one or more particular request attributes. Thus, the user could modify the transaction requesting flight information to indicate that all requests for flight information that include the same destination city attribute as the observed transaction should match the observed transaction, regardless of whether such requests also specify the same origination city as the observed transaction. Users can also modify information describing observed transactions in order to replace observed attributes with user-specified attributes and the like.
• In many situations, transactions are stateless, such that each transaction is independent of any transactions that have taken place beforehand. In other words, for a stateless transaction,service30 will generate the same response to a given request, regardless of whether any other transactions have already been performed. In such situations,service model generator20 generates information identifying each observed transaction in the same manner, regardless of whether any other prior transactions have been observed and regardless of the attributes and commands contained within such prior transactions.
• In other situations, transactions are stateful, such that the response included in a given transaction may differ depending upon what transaction or transactions have already been performed. In these situations,service model generator20 is configured to generate additional state information for each transaction. This additional state information identifies the preceding transaction (the state information for the preceding transaction can also be modified to identify the subsequent transaction). More information regarding stateful transactions is provided in the discussion ofFIG. 6.
• FIG. 2 shows information that can be maintained as part of a model of a service. Such a model can be generated by a service model generator such as the one shown inFIG. 1. In this example,service model40 includes a row for each of several transactions. Each row ofservice model40 identifies a command, zero or more attributes, zero or more characteristics, and one or more response attributes. This service model can be stored in a spreadsheet, table, database, or any other data structure.
• In this example, transaction201(A) is an observed transaction. In other words, transaction201(A) is a transaction that actually occurred between a requester and the service being modeled, as detected by a service model generator. The information describing transaction201(A) includes request information, which includescommand211 and zero or more observed attributes221(1). The information describing transaction201(A) also includes response information241(1) describing the observed response that corresponds to the observed request. This response information241(1) can also include one or more attributes. Observed characteristics231(1) can include zero of more observed characteristics of transaction201(A). These observed characteristics can include timing information describing when the request and/or response were observed or the like, as described above.
• Like transaction201(A), transaction201(B) is a transaction that actually occurred (i.e., an observed transaction). Transaction201(B) is of the same transaction type as transaction201(A), since both transactions included a request that containedcommand211. Transaction201(B) is described by observed attributes221(2) (which can have values that differ from those attributes observed in the request of transaction201(A)), observed characteristics231(2) (which can again differ from those observed for transaction201(A)), and observed response241(2) (which can also have a value that differs from the response observed for transaction201(A)).
• In this example, information describing n (an integer number) known transactions of the same type as transactions201(A) and201(B) is stored inservice model40. These known transactions are transactions that were either observed or specified by a user. As part of the model building process, information describing an n+1th transaction of the same type has been added toservice model40 by the service model generator. This n+1th transaction, labeled transaction201(n+1), describes an “unknown” transaction of a known type of transaction. Such an unknown transactions is of a known type because it has the same command,command211, as the other transactions of this type. However, unlike the other known transactions of this type, unknown transaction201(n+1) can be used to respond torequests containing command211 and “unknown” attributes that do not match those known (i.e., either observed or user-specified) attributes stored for transactions201(A)-201(n) (not shown). The information describing transaction201(n+1) thus includes information (e.g., wildcard information) identifying unknown attributes221(n+1), such that any request that includescommand211 and an attribute that does not match the observed attributes stored for the actual transactions (e.g., such as transactions201(A) and201(B)) will match the request information for transaction201(n+1).
• The information describing transaction221(n+1) also includes default characteristics231(n+1) and default response241(n+1). These default values can be copied from the corresponding fields of an actual response of the same type. In some embodiments, the service model generator prompts a user to select the actual transaction from which these values should be copied. Alternatively, a user can be prompted to enter these values directly.
• Information describing another set of transactions of a different type is also stored withinservice model40. As shown, m+1 transactions, including transaction202(A),202(B), and202(m+1) of a type of transaction in which the request includescommand212 are stored inservice model40. Like transactions201(A) and201(B), transaction202(A) is an observed transaction, and thus the information describing this transaction includes the observedcommand212, observed attributes222(1) (if any), observed characteristics232(1) (if any), and observed response242(1).
• In contrast, transaction202(B) is a user-specified transaction. This transaction was thus not observed and did not necessarily ever even occur. Instead, a user entered the information describing this transaction via a user interface. The information describing transaction202(B) includescommand212, zero or more user-specified attributes222(2), zero or more user-specified characteristics232(2), and a user-specified response242(2). In some embodiments, the user is prompted for entirely new information for each of these user-specified fields. In other embodiments, the user can be allowed to select an existing field (e.g., of another user-specified transaction or of an observed transaction) to copy into one or more of these fields. It is noted that a user can also create a user-specified transaction by modifying information describing an actual transaction. AsFIG. 2 shows, user-supplied transaction information can be stored in the same model as transaction information captured by observing actual traffic exchanged between a requester and the service being modeled.
• A final transaction,202(m+1), is an unknown transaction. The information describing transaction202(m+1) was added toservice model40 after m (an integer number, which does not necessarily have the same value as n) known transactions were described by the model. The information describing this unknown transaction202(m+1) can be used to handle requests of the same type (e.g., containing command212) that specify unknown attributes. Accordingly, the information describing transaction202(m+1) includescommand212, unknown attributes222(m+1) (i.e., attribute information that will match any attributes not identified in the known attributes stored for the other m transactions of this type), default characteristics232(m+1), and default response242(m+1).
• Afinal transaction203 is also described inservice model40.Transaction203 is an unknown transaction of unknown type. In other words, the information describing this transaction can be used to respond to any request of a type not already described by another row ofservice model40. Accordingly, a request containing a command other thancommands211 and212 could be responded to using theinformation describing transaction203.
• As shown, theinformation describing transaction203 includesunknown command information213, which is configured to match any command not already specified inservice model40,unknown attribute information223, which is configured to match all attributes (if any) associated with unknown commands,default characteristics233, and adefault response243. As with the default characteristics and responses associated with unknown transactions of known type,transaction203's default characteristics and response can be user-specified.
• FIG. 3 is a flowchart of a method of generating a model of a service. This method can be performed by a service model generator such as that shown inFIG. 1 in order to generate a service model like that shown inFIG. 2. The method is performed in response to model building being enabled, either in response to direct input of a start command (e.g., by a user selecting a start button in a graphical user interface) or in response to occurrence of a trigger (e.g., a prespecified time and/or date, or the occurrence of a prespecified event or series of events).
• The method begins at300, where a service model generator determines whether a request has been detected. As noted above, detection of a request can vary depending upon the particular transport and/or data protocols in use between the requester(s) and the service being modeled. For example, detection of a request can involve monitoring a queue, intercepting method calls to an object, intercepting requests being sent to a web server or database application, or the like.
• If a request is detected, information identifying the observed request (e.g., information describing the command included in the request, the attribute(s) included in the request, if any, and information describing one or more characteristics of and/or associated with the request, if desired) and the associated response (e.g., information describing the attribute(s) included in the response, as well as information describing one or more characteristics of and/or associated with the response, if desired) is stored as part of the service model, as indicated at305.
• Operations300 and305 can repeat indefinitely, until a user selects to end the model building process (or at least the portion thereof that generates information describing observed transactions) or until prespecified ending conditions are met.
• At310, a determination is made as to whether user input specifying a request has been received. This determination can be made, for example, by detecting whether a user has selected an option (in a user interface) to add additional transactions to and/or modify existing transactions in the service model.
• If user input specifying a request has been received, information identifying the user-specified request (e.g., information describing a command and/or the attribute(s) included in the request, if any, and information describing one or more characteristics of and/or associated with the request, if desired) and the associated user-specified response (e.g., information describing the attribute(s) included in the response, as well as information describing one or more characteristics of and/or associated with the response, if desired) is stored as part of the service model, as indicated at315.
• Whileoperations300 and310 are shown as taking place serially, these operations may be performed in parallel or in the opposite order shown in other situations and/or embodiments. For example, a user can initially enter information describing several user-specified transactions (e.g., by selecting a production log file), before enabling the service model generator to begin observing and recording actual transactions taking place. Similarly, in some embodiments, a user can select to enter information specifying a user-specified transaction while the service model generator is observing and recording actual transactions. In other embodiments, a user may not be allowed to enter user-specified transactions into the service model while transaction observation and recording is taking place. In still other situations,operation310 may be performed andoperation300 may not, or vice versa.
• At320, a determination as to whether the model building process is complete is made. This determination can involve detecting whether the service model generator has stopped observing and recording actual transactions and/or whether a user has finished entering information describing user-specified transactions (e.g., as determined by the user selecting a “finish” option or other appropriate option from a user interface). Such a determination can also be made using other stimuli. For example, in one embodiment, this determination can be based upon whether a user has selected to save a service model (e.g., when the user saves a service model, that service model is assumed to be complete).
• If the model building process has finished, the service model generator can perform additional processing. For example, the service model generator can store information identifying an unknown transaction of a known type, as shown in330. This information includes information identifying a known type of request that includes one or more unknown attributes, as well as an associated response. Similarly, the service model generator can store information identifying an unknown transaction of an unknown type, as shown at340. The information identifying the unknown transaction of unknown type can include information identifying an unknown command, information identifying unknown attributes, as well as information identifying default characteristics and a default response.
• In addition to adding information describing unknown transactions of known and unknown types, other processing can also take place after the basic model building process completes. For example, in some embodiments, the service model supports time sensitive responses. In these embodiments, the service model generator processes the response information in the model in order to substitute time sensitive attributes for actual observed attributes, as shown at350. Thus, an actual attribute “10:59 PM Oct. 1, 2009” can be replaced with a time sensitive value such as “[SYSTEM CLOCK+11 HOURS]”. When the model is used to generate responses for the virtualized service, the time sensitive value is used to calculate the appropriate attribute to include in each response. Thus, if the model is being used to virtualize a service and the response attribute includes the time sensitive value [SYSTEM CLOCK+11 HOURS], the response generated based upon the model will include the value generated by adding 11 hours to the system clock value at the time the request was received. In general, time sensitive values specify an observable time, such as a time value included in a request or the current system clock time, and a delta, such as an amount of time to add or subtract from the specified observable time. Time sensitive values can be included in the response information for all types (known and unknown) of transactions.
• To generate the appropriate time sensitive response values, the service model generator can (as part of observation and recording of actual transactions) record information in the service model indicating the current system clock value (e.g., a time and/or date) at each time that a response is received by the service being modeled. Thus, for a given transaction, the characteristics for that transaction can include the system clock value (at the service being modeled) at the time that the request was received by the service being modeled.
• After the model building process completes, the service model generator identifies which responses in the model, if any, should be modified to include time sensitive values. If there is no time value in the observed response, there is no need to modify the information describing the observed response to include a time sensitive value.
• If instead there is a time value included in the observed response, the service model generator can then determine whether the corresponding request includes a time value as one of its attributes. If the corresponding request does include a time value, the service model generator can calculate the difference between the time value in the request and the time value in the response. This difference is then used to generate the time sensitive value, and the time value in the response is replaced with the time sensitive value. Thus, if the request includes the time value “Sep. 1, 2000” and the response includes the time value “Sep. 14, 2000”, the response's time value can be replaced with the time-sensitive value “[REQUEST DATE+13 DAYS]”.
• If the corresponding request does not include a time value, the service model generator compares the time value in the response to the recorded system clock time in the transaction's characteristics. This difference is then used to generate the time sensitive value, and the time value in the response is replaced with the time sensitive value. For example, if the response includes the value 6:01 AM and the characteristics indicate that the service received the corresponding request at a system clock time of 5:59 AM, the time sensitive value is “[SYSTEM CLOCK+2 MINUTES]”.
• If there are multiple time values in the same response, the above procedure can be repeated for each different time value. Thus, if there are three time values in a response, three different time sensitive values can be calculated, and the existing time values can each be replaced by a corresponding time sensitive value.
• In some embodiments, a user can modify an observed response to include a time sensitive value (e.g., by selecting to add a time sensitive value via a pull-down menu) or add a user-specified response that includes a time sensitive value. In such embodiments, the user can specify whether the time sensitive value depends upon a time value in the request or the system clock value as well as how the observable time (i.e., the system clock value or time value in the request) should be modified (e.g., by specifying an amount of time to be added to the observable time).
• Another type of post-model building processing that the service model generator can perform involves replacing attribute values (e.g., strings) in the response information associated with unknown transactions of known type with request sensitive values, as shown at360. The request sensitive values link an attribute included in the request to a value included in the response. For example, the information describing an unknown transaction of known type can specify that there are three attributes included in requests of that known transaction type. The response information for that unknown transaction can be modified to include a request sensitive value that indicates that the value of the third attribute of the request should be used as the value of the first attribute of the response, instead of an actual observed or user-specified value.
• When the model is used, the response generated by the virtualized service will include the value indicated by the request sensitive value. For example, the model can include three known transactions of a given transaction type, as well as one unknown transaction of that type. The information describing the unknown transaction can indicate that the single response attribute is a request sensitive attribute that should be the same as the first attribute of the request. A request of that type that contains an unknown first attribute (i.e., an attribute that does not match the attribute(s) stored for the three known transactions of that type in the model) can be sent to the virtualized service. In response to receiving this request and accessing the request sensitive value specified in the response information for the unknown transaction, the virtualized service returns a response that includes the value of the first attribute that was contained in the received response.
• To generate request sensitive values, the service model generator compares each request attribute in each known transaction with the response attribute(s) for the same transaction. If a match or other dependency is found, the service model generator can create a request sensitive value that identifies an attribute in the request and a dependency (if the dependency is one other than identity). For example, if the information describing a known transaction of type A indicates that the request includes the string “UserID” as the first request attribute and that the corresponding response includes the string “UserID” as its second response attribute, a request sensitive value specifying “[REQUEST ATT 1]” (first request attribute) can be generated. The service model generator then replaces the second response attribute for the unknown transaction of transaction type A with the request sensitive value.
• In some embodiments, all known transactions of a given type are processed before the corresponding unknown transaction's response information is modified. The request sensitive value is used to replace one of the unknown transaction's response attributes only if all of the known transactions of that type exhibit the same dependency. In other embodiments, less stringent requirements are imposed (e.g., a replacement may be made if some but not all of the known transactions exhibit the same dependency).
• A service model generator can perform other types of processing in addition to those described above. For example, service model generator can process information stored as part of the characteristics of each transaction in order to identify availability windows for the service, load patterns for the service, and the like. If patterns are identified, the service model generator can update the service model to include information identifying such patterns. For example, if an access window is identified for a particular type of transaction, the service model generator can modify the unknown transaction of that type to include a characteristic indicating that a response (or a particular type of response) will only be generated if the request is received during the identified access window.
• Additionally, if the service model generator is recording stateful transactions, the processing performed after transactions are recorded can involve identifying and merging transactions into conversations, as is described in more detail below with respect toFIG. 6.
• It is noted that a user can restart the model building process for a particular model subsequent to performance of processing operations like operations330-360 (e.g., by restarting the observation and recording operations or by selecting to edit an existing model). In such situations, the processing operations, such as processing operations330-360, may be repeated, if needed, after the restarted model building process completes (e.g., if a transaction of a new type is added to the model, a corresponding unknown transaction of that type can be added to the model by repeating operation330).
• FIG. 4 is a block diagram of a system that presents a virtual database service. While a virtual database service is described in this example, it is noted that other types of services can be virtualized in a similar manner.
• As shown, the system ofFIG. 4 includes an application undertest410, adevice manager450, atesting driver425, adatabase driver435, adatabase430, atesting module460,virtual database service470,service model generator20, user interface480, anddatabase model440. These components can be implemented on the same computing device in some embodiments. However, in many embodiments, various components can be implemented on different computing devices. For example, application undertest410,device manager450, andtesting driver425 can be implemented on one computing device, whiledatabase driver435 is implemented on another, andtesting module460 is implemented on yet another. Thus, the various components can be configured to communicate via a network.
• In this example,testing module460 includes both aservice model generator20 to generatedatabase model440 ofdatabase430 and avirtual database service470 that usesdatabase model440 to virtualizedatabase430. User interface480 can be used to configure and control the model building process performed byservice model generator20, as described above, as well as to deploy thevirtual database service470.
• In order to deployvirtual database service470, a user selectsdatabase430 for virtualization and causesdatabase model440 to be generated. The user then selects to deploy the virtual database service. Deployment involves starting a request processing module that is configured to use the appropriate service model to process requests. The request processing module can be deployed within a software container (e.g., aJava 2 Platform, Enterprise Edition (J2EE or JavaEE) container) devoted to providing virtual service environments. If desired, several instances of the request processing module, each of which uses the same service model, can be deployed at the same time. The executing request processing module accessesdatabase model440 in order to presentvirtual database service470.
• Arelated testing driver425 or other testing module can also be deployed (e.g., if application undertest410 is not executing in the same container as the request processing module) on the client system (i.e., the system that includes the application under test) as part of the deployment process. This testing driver can be configured to provide requests generated by the application undertest410 tovirtual database service470, as well as to provide responses generated byvirtual database service470 to the application under test. A similar driver (or even the same testing driver) can also operate as part ofservice model generator20 during the model building process described above.
• In the illustrated embodiment,testing driver425 causes database requests generated by application undertest410 to be provided tovirtual database service470 instead ofdatabase430.Testing driver425 first communicates with thedriver manager450 on the same system as application undertest410.Testing driver425 has thedriver manager450 update the driver management information for that system to indicate that requests being sent todatabase driver435 should actually be sent totesting driver425.Testing driver425 can then provide those requests tovirtual database service470.
• As requests are received from application undertest410,virtual database service470 can usedatabase model440 to select responses to return toapplication410.FIG. 5 provides an example of how a service model such asdatabase model440 can be used to select responses.
• During the deployment process (or during ongoing use of the virtual database service), the user can interact withtesting module460 via user interface480 in order to control howvirtual database service470 operates. For example, in one embodiment, thedatabase service model440 includes characteristic information for each transaction that controls how quickly responses are sent after requests are received. The user can use a slider bar or other input mechanism within user interface480 to specify at what percentage speed thevirtual database service470 should operate, relative to the observed speed ofdatabase430. For example, a user can select to havevirtual database service470 operate at 110% of observed speed in order to identify the effect of speeding updatabase430 on application undertest410.
• FIG. 5 is a flowchart of a method of presenting a virtual service. This method can be performed by a testing or training system in which a virtual service has been implemented. The virtual service includes a request processing module (e.g., as implemented as a process executing in a container) and a service model (e.g., such asservice model40 ofFIG. 1) representing the service being virtualized. Several request processing modules can be deployed at the same time, and thus the various operations ofFIG. 5 can be performed by different request processing modules operating at substantially the same time to virtualize the same service.
• At500, the request processing module waits for a request. If a request is detected, the request processing module then determines whether the virtual service is operating in pass-through mode, as shown at505. In pass-through mode, the virtual service is not actually responding to requests. Instead, the virtual service is simply receiving requests and then forwarding those requests to the actual service being virtualized. In some embodiments, while the virtual service operates in pass-through mode, a service model generator can observe and record such requests by adding information describing those requests (and their corresponding responses) to the existing model of the service. A user can select whether to operate a virtual service is pass-through mode by selecting an option in a user interface. In some embodiments, the user can dynamically change the mode (pass-through or non-pass-through) in which the virtual service is operating while operation of the virtual service is ongoing (e.g., without having to stop and restart or undeploy and redeploy the virtual service).
• If the virtual service is currently operating in pass-through mode, the request detected at500 is provided to the actual service being virtualized, as shown at540. A response can then be received from the actual service, as shown at545. The received response can then be provided to the requester, as indicated at550. In many embodiments, the same mechanisms used to send and receive requests and responses while generating a service model are also used to operate the virtual service in pass-through mode.
• If the virtual service is not operating in pass-through mode, the request processing module determines whether the request is part of a transaction of a known type. In this example, this determination is made by determining whether the request contains a known command, as shown at510. A known command is a command that was included in an actual observed or user specified transaction that is part of the service model for the service being virtualized. If the request does not contain a known command or is otherwise not part of a transaction of a known type (e.g., if the request does not contain the appropriate attributes), a response associated with an unknown transaction of unknown type is selected, as indicated at510 and515.
• If instead the request is part of a transaction of a known type, a determination is made as to whether the request is part of a known transaction. This determination can involve detecting whether any of the attributes included in the request are unknown attributes (i.e., attributes having values that were not included in the actual observed and/or user-specified requests included in the service model), as shown at520. If the request includes one or more unknown attributes, the request processing module selects a default response associated with the appropriate unknown transaction of known type in the model, as shown at530. Otherwise, the request processing module selects the appropriate actual observed or user-specified response from a known transaction of known type from the model.
• In some embodiments, determination of whether the attributes of the new request match the known attributes identified in the model is performed using an exact matching process. For example, regular expressions can be used to match a received request to the requests identified in the service model. Alternatively, less precise matching can be performed. For example, “starts with” or “contains” type matching can be performed as part ofoperation520. These types of matching can thus identify that the new request matches an actual, known transaction, even if the new request's attributes differ somewhat from those in the actual, known transaction.
• The request processing module can optionally manipulate the selected response in a manner indicated by the model, as shown at535. For example, if the selected request includes a time sensitive value, the request processing module can use that time sensitive value to calculate an actual time value. The request processing module can then replace the time sensitive value in the response with the calculated time value. Similarly, if the selected response includes a request sensitive value, the request processing module can calculate the appropriate response attribute, as indicated by the request sensitive value, and then replace the request sensitive value with the calculated response attribute. Likewise, if the selected response is associated with a characteristic specifying an access window, and if the request was received outside of the specified access window, additional manipulation (e.g., to replace the stored response with an appropriate error message) can be performed. Many other types of manipulation can also be performed in response to information contained in the service model. Once the response has been manipulated, if needed, the final response can be returned to the requester, as shown at550.
• FIG. 6 is an illustration of a data model that can be used to store information representing both stateful and stateless transactions. Service model information such as that shown inFIG. 2 can be stored in such a data model. As shown, the data model includes five data patterns:traffic pattern610,conversation pattern620,transaction pattern630,request pattern640, andresponse pattern650.
• Traffic pattern610 can be used to store information identifying a particular service and the transactions that have been observed or otherwise added to the model of the identified service. Each service model can include a single instance oftraffic pattern610. As shown,traffic pattern610 includes createdfield611, which stores date information identifying when the service model of that particular service was initially created.Traffic pattern610 also includeslastModified field612, which stores date information identifying the most recent time at which any of the information in the service model of the particular service was modified.
• Traffic pattern610 also includes anunknownResponse field613.UnknownResponse field613 stores information identifying the particular instance of the response pattern that stores information identifying the response to use for unknown transactions of unknown types. Accordingly, in embodiments employing the data pattern ofFIG. 6, if an unknown transaction of unknown type is detected by a request processing module, the request processing module will use the response pattern instance identified inunknownResponse field613 to generate a response.
• Traffic pattern610 includesconversations field614. Conversations field614 can identify one or more instances ofconversation pattern620.Conversation pattern620 stores information representing a set of two or more stateful transactions. Such a set of stateful transactions is referred to herein as a conversation. The instance(s) ofconversation pattern620 identified in conversations field614 identify all of the observed and/or user-specified conversations for the service being modeled. If the particular service being modeled does not include any stateful transactions (e.g., if a user has specified that the service only performs stateless transactions, or if no stateful transactions have been observed or specified by a user), conversations field614 will not identify any instances ofconversation pattern620.
• Traffic pattern610 additionally includesstatelessConversation field615. This field can identify one or more instances oftransaction pattern630.Transaction pattern630 stores information representing a transaction. Each instance oftransaction pattern630 identified instatelessConversation field615 stores information identifying a stateless transaction that was either observed or specified by a user.StatelessConversation field615 can identify instances oftransaction pattern630 associated with both known and unknown transactions of known types. If the particular service being modeled does not include any stateless transactions,statelessConversation field615 will not identify any instances oftransaction pattern630.
• Type field616 can store one of two values: INSTANCE or TOKEN that identifies the type of stateful transactions, if any, provided by the service being modeled. Instance statefulness occurs when the communication protocol used by the service is itself stateful. When instance statefulness is used, each interaction between the service and a particular requester is handled by a separate instance of the service executing in its own memory space, such that interactions involving different requesters are handled by different instances of the service executing in different, independent memory space. Token statefulness occurs when the communication protocol used by the service is not itself stateful. When token statefulness is implemented, a single instance of the service interacts with all requesters. In token statefulness scenarios, each request and response can include tokens (e.g., such as “cookies” used in HTTP) that identify the particular requester that sent the request or should receive the response. In some embodiments, the value of this field is set automatically (e.g., by a service model generator) when a user selects the communication protocol(s) used to communicate with the service to be modeled.
• As noted above,conversation pattern620 stores information identifying a set of stateful transactions. A given service model can include n instances ofconversation pattern620, where n is an integer that is greater than or equal to zero.
• Conversation pattern620 includes astarter field621. This field stores information identifying an instance oftransaction pattern630 associated with a starter transaction. The starter transaction is a transaction that acts as the first transaction in a stateful series of transactions (e.g., a login transaction). In at least some embodiments, all starter transactions are unknown transactions of known type, as will be described in more detail below. The particular transaction type to use as a starter transaction can be specified by a user during the service model configuration process.
• Conversation pattern620 also includesreset field622.Reset field622 stores information identifying one or more instances oftransaction pattern630, each of which is associated with a reset transaction (such a reset transaction can be a known or unknown transaction). The value ofreset field622 can be provided by a user (e.g., the user can be prompted to identify the reset transaction(s) for each conversation). A reset transaction is a transaction that, if detected, causes the flow of the conversation to return to the point just after performance of the starter transaction. For example, if a conversation includes four sequential transactions (where the starter transaction is the first of the four sequential transactions), and the reset transaction is detected just after performance of the third transaction in the conversation, the state of the conversation will return to the state that exists just after performance of the first transaction.
• Conversation pattern620 also includes agoodbye field623. This field stores information identifying an instance oftransaction pattern630 associated with one or more goodbye transactions (of known or unknown type) for the conversation. A goodbye transaction is a transaction that causes the conversation to end. To reenter the conversation after a goodbye transaction is performed, the starter transaction for that conversation would need to be reperformed.
• Transaction pattern630 stores information identifying a transaction.Transaction pattern630 includesrequest field631,responses field632,parent field633, children field634, andmatchTolerance field635.Transaction pattern630 can be used to store stateful and stateless transactions (in some instances, the same transaction can occur both within a conversation and in a stateless situation where no conversation is currently ongoing). Transactions that are always stateless will not include values ofparent field633, children field634, ormatchTolerance field635.
• Request field631 identifies the instance ofrequest pattern640 that stores information identifying the request (e.g., by command and attributes) portion of the transaction. Similarly, responses field632 identifies one or more instances ofresponse pattern650 that store information identifying the response(s) that are part of that transaction. Each instance ofresponse pattern650 stores one response attribute (e.g., like those shown inFIG. 2), and thus if responses field632 identifies multiple response patterns, it indicates that each of the identified response patterns should be used to generate a response when the corresponding request is received.
• Parent field633 stores a value identifying the instance oftransaction pattern630 associated with the transaction that occurs immediately before the current transaction in a conversation. Thus, iftransaction pattern630 stores information identifying the second transaction in a conversation (where the starter transaction is the first transaction in the conversation),parent field633 can identify the instance oftransaction pattern630 associated with the starter transaction.
• Similarly, children field634 can store information identifying each instance oftransaction pattern630 associated with a child transaction of the current transaction. Thus, iftransaction pattern630 stores information identifying the second transaction in a conversation, children field634 can store information identifying the instance oftransaction pattern630 that stores the third transaction in the conversation. It is noted that children field634 can identify more than one transaction.
• In some embodiments,parent field633 and children field634 only identify unknown transactions of known type. In such embodiments, known transactions are identified as properties of corresponding unknown transactions of the same type that occur at the same point in a conversation.
• MatchTolerance field635 stores one of three values: STRICT, CLOSE, or LOOSE. The stored value indicates the match tolerance for a request received immediately subsequent to the current transaction. Strict tolerance indicates that, if a conversation is ongoing, the request received immediately after the current transaction is only allowed to match transactions identified in the current transaction'schildren field634. If a received request does not match one of the children transactions and is not a goodbye or reset transaction, the received request will be handled as an unknown transaction of unknown type, even if the service model does contain a matching transaction elsewhere.
• If instead close tolerance is specified, the request received immediately after the current transaction can match any of the current transaction's children, as well as any of the current transaction's sibling transactions. Sibling transactions are all transactions that are identified in the children field of the transaction identified by the current transactions parent field. If the next request does not match any of these children or sibling transactions and is not a goodbye or reset transaction for the conversation, the next request will be handled as an unknown transaction of unknown type.
• If loose tolerance is specified, even more transactions are candidates for matching the next received request. In one embodiment, loose tolerance indicates that the next request can match any of the current transaction's children transactions, sibling transactions, or parent transactions and parents' sibling transactions. In another embodiment, loose tolerance indicates that the next request can match any of the transactions included in the conversation, other than the starter transaction. If the next request does not match any of the transactions allowed by the loose tolerance and is not a goodbye or reset transaction for the conversation, the next request will be handled as an unknown transaction of unknown type.
• Thus, thematchTolerance field635 effectively identifies a subset of the transactions within the service model that are candidates for matching the next request received after the current transaction. The value of thematchTolerance field635 can be set by a service model generator (e.g., based upon user input, a default configuration associated with the communication protocol used to communicate with the service being modeled, or the like). Different transactions within the same service model, as well as different transactions within the same conversation, can have different levels of match tolerance.
• In some embodiments, only unknown transactions of known type have values inmatchTolerance field635,parent field633 and/or children field634. In such embodiments, one or more known transactions of known type can be identified as properties (not shown) of a corresponding unknown transaction of the same known type. In such a situation, the parent, child, and/or match tolerance of the corresponding unknown transaction will be used when processing a request received subsequent to one of the known transactions of known type.
• Request pattern640 includes acommand field641, attributesfield642, andcharacteristics field643. Each instance ofrequest pattern640 stores information identifying a particular request. A service model generator can allocate an instance ofrequest pattern640 for each observed transaction, user-specified transaction, and unknown transaction of known type.
• Command field641 stores a string that identifies the command contained in the request. Attributes field641 stores a parameter list that includes zero or more parameters, each of which represents an attribute of the request. The parameter list can include observed, user-specified, and unknown attributes, as discussed above with respect toFIG. 2.
• Characteristics field643 stores a parameter list identifying zero or more characteristics associated with the request. Each parameter in the list can identify a different characteristic. Examples of characteristics can include the time at which the request was sent, the system clock time at which the request was received by the service being modeled, network and/or system conditions that were present when the request was received, and the like. The parameters stored in characteristics field643 can be used to generate time sensitive values, as well as to model actual conditions such as response timing and availability windows.
• Response pattern650 includes anattribute field651 and acharacteristics field652.Attribute field651 stores a string that represents a response attribute. As noted above, a given transaction can have multiple response attributes (e.g., responses field632 oftransaction pattern630 can identify multiple instances of response pattern650), and thus generating a response can involve accessing multiple response patterns in order to include the string identified in each of the response patterns'attribute field651 in the response.Attribute field651 can store a user-specified or observer response attribute, as well as values, like request sensitive values and time sensitive values, generated by the service model generator.
• Characteristics field652 stores a parameter list containing zero or more parameters. Each parameter identifies a characteristic of the response, such as the system clock time when the response was sent to the requester by the service, network and/or system conditions that were present when the response was sent, and the like.
• Whenever a service model generator is observing and recording stateful transactions that are part of a conversation, the service model generator can first act to store information identifying each observed transaction (e.g., by storing information identifying each transaction in atransaction pattern630,response pattern640, and one ormore response patterns650. The service model generator can also store information identifying the order in which the recorded transactions were observed.
• After the observation and recording process is complete, the service model can begin generating information identifying one or more conversations and updating the conversation-related fields of one or more transaction patterns. If the service supports token statefulness, the service model generator can then prompt the user to specify the starter transaction(s). For example, the service model generator can provide a list of all observed transactions to the user, and prompt the user to select which, if any, of those observed transactions are starter transactions.
• The service model generator can identify all transactions that were part of the same conversation. When instance statefulness is implemented, a conversation will include all observed transactions for a given instance of the service; when token statefulness is implemented, a conversation will include all observed transactions that include the same token (e.g., as a request and/or response attribute), where each conversation begins with one of the user-specified starter transactions. Once transactions that are part of the same conversation have been identified, the service model generator can used the information identifying the order in which transactions were observed to place those transactions in temporal order.
• The service model generator can then attempt to merge one or more conversations into a single conversation. For example, the service model generator can determine whether more than one of the conversations includes the same starter transaction. If so, the service model generator can merge those conversations into a single conversation that begins with the same starter transaction. If the starter transactions of multiple different conversations are not identical but are structurally similar transactions of the same type (e.g., if two conversations begin with start transactions that include the same command and the same number and type of attributes, but the actual attribute values differ), those conversations can also be merged into a single conversation.
• For each conversation identified in this merging process (this includes conversations created by merging multiple other conversations, as well as independent conversations that cannot be merged with others), the service model generator can allocate an instance ofconversation pattern620 to store information identifying that conversation. As noted above, the starter transaction for each conversation is an unknown transaction of known type. Accordingly, if the service model does not already include an unknown transaction of that type, the service model generator can allocate an instance oftransaction pattern630 to store that unknown transaction. Once the unknown transaction acting as the starter transaction is included within the model, thestarter field621 of theconversation pattern630 is updated to identify that unknown transaction.
• If any known transactions of that type were observed (e.g., such as those that were merged in the above example) as the first transaction in the conversation, those transactions can then be added to the conversation as properties of the unknown transaction of that type. Adding these transactions to the conversation involves updating a properties field (not shown) of the unknown starter transaction to identify each of the known transactions of that type that were observed as starter transactions of the merged conversation.
• This merging process can be repeated at each level of the conversation. For example, if four conversations, each of which includes at least three sequential transactions, are merged, the merging process can continue for each of the next two transactions within each conversation. Thus, after the known starter transactions are added as properties of the unknown starter transaction, the service model generator can observe the next transactions to occur within the merged conversation, and determine whether any of the next transactions can also be merged. The service model generator can also insert unknown transactions for each type of known transaction encountered in the conversation, and then add the known transactions as properties of those unknown transactions. Even if no merging is performed, an unknown transaction of known type will be included for each known transaction observed in a conversation. Parent and children fields are updated to indicate the flow of the conversation.
• For example, assume three conversations have been observed, as shown inFIG. 7A. These conversations all include commands that can be used with a computer reservation system used to reserve flights with one or more airlines. The first conversation includes transactions 1.1-1.4. Transaction 1.1 includes a request to “getFlightInfo” specifying an origination city CityA and a destination city CityB. The response (not shown) to this request includes a list of flights, if any, scheduled between CityA and CityB. Transaction 1.2 includes a request for the capacity of one of the flights provided in response to the “getFlightInfo” request, and a response (not shown) indicating whether that flight has any available capacity. Transaction 1.3 includes a request to reserve that flight, and a response (not shown) indicating whether or not the flight reservation was successful. Transaction 1.4 includes a request to hold a specific seat on the flight, and a response (not shown) indicating whether the request was successful.
• The second conversation includes transactions 2.1-2.2. Transaction 2.1 includes a request to “getFlightInfo” specifying an origination city CityC and a destination city CityD. The response (not shown) to this request includes a list of flights, if any, scheduled between CityC and CityD. Transaction 2.2 includes a request to reserve one of those flights, and a response (not shown) indicating whether or not the flight reservation was successful.
• The third conversation includes transactions 3.1-3.4. Transaction 3.1 includes a request to “getFlightInfo” specifying an origination city CityA and a destination city CityD. The response (not shown) to this request includes a list of flights, if any, scheduled between CityA and CityD. Transaction 3.2 includes a request for the capacity of one of the flights provided in response to the “getFlightInfo” request, and a response (not shown) indicating whether that flight has any available capacity. Transaction 3.3 includes a request to hold a seat on that flight, and a response (not shown) indicating whether or not the request was successful. Transaction 3.4 includes a request to reserve the flight, and a response (not shown) indicating whether the flight reservation was successful.
• The service model generator then processes the observed transactions in order to build a tree representing the conversations, as shown inFIG. 7B. Initially, the service model generator identifies that the three conversations can be merged because all three start with the same type of known transaction: getFlightInfo, despite the fact that the observed attributes differ among each of the three starter transactions. In response to this identification, the service model generator identifies the unknown transaction of that type, getFlightInfo, as the starter transaction for the merged conversation and adds this unknown transaction to the service model (while a stateless unknown getFlightInfo transaction or other stateful unknown getFlightInfo transactions may already exist in the service model, none of these other transactions occur at the same point in the stateful conversation as this one, so a new unknown transaction will always be added). The service model generator then updates the unknown getFlightInfo transaction's properties to identify the known transactions 1.1, 2.1, and 3.1 that were observed at the same point in the conversation. These properties are shown in brackets inFIG. 7B.
• The service model generator then examines the second transaction in each conversation to see if any of those transactions can be merged. Here, the first and third conversation each include a structurally similar second transaction of type “capacity.” Accordingly, these two conversations can again be merged at the second transaction level. To do so, the service model generator creates a new instance of an unknown transaction of type capacity. The children field of the unknown getFlightInfo transaction is updated to identify the new unknown capacity transaction, and the parent field of the new unknown capacity transaction is updated to identify the unknown getFlightInfo transaction. The two known transactions 1.2 and 3.2 that were observed at this point in the first and third conversations are then added as properties of the unknown capacity transaction.
• The second transaction in the second conversation, which is of type “reserveFlight,” cannot be merged with the second transaction of the other two conversations, however. Accordingly, the service model generator will create a new unknown transaction of this type and update the children field of the unknown getFlightInfo to identify this new unknown reserveFlight transaction. Similarly, the parent field of the new unknown reserveFlight transaction is updated to identify the unknown getFlightInfo transaction. The single known transaction of this type (transaction 2.2) is then added as a property of the new unknown reserveFlight transaction.
• Thus, after processing the second transaction in each of the three conversations, the service model will indicate that the unknown getFlightInfo starter transaction has two children, an unknown capacity transaction and an unknown reserveFlight transaction.
• The service model generator then processes the third transaction in each conversation. As shown inFIG. 7A, only the first and third conversations include more than two transactions, and each conversation includes a different transaction at this point in the conversation. Accordingly, it is not possible to merge the transactions at this point in the conversation. As such, the service model generator creates a new unknown reserveFlight transaction to correspond to transaction 1.3, and a new unknown seat transaction to correspond to transaction 3.3. The children field of the new unknown capacity transaction is updated to identify both of these unknown transactions as children, and the parent field of the new unknown reserveFlight and seat transactions are updated to identify the unknown capacity transaction. The observed known transactions are added as properties of their corresponding unknown transactions, such that the unknown seat transaction identifies transaction 3.3 as one of its properties and the unknown reserveFlight transaction identifies transaction 1.3 as one of its properties.
• It is noted that there are now two unknown reserveFlight transactions in the same conversation. Despite being unknown transactions of the same type, these two transactions have different values of their parent and children fields and properties. These differences reflect the fact that these transactions occur at different points within the conversation.
• The service model generator then processes the final transactions 1.4 and 3.4 in the first and third conversations in the same manner as the previous transactions. Since the transactions that preceded these transactions could not be merged, these transactions also cannot be merged (furthermore, in this example these transactions can also not be merged since they are of different types. Accordingly, the service model generator adds a new unknown transaction for each of transactions 1.4 and 3.4. The new unknown reserveFlight transaction corresponding to transaction 3.4 lists transaction 3.4 as one of its properties, and the new unknown seat transaction corresponding to transaction 1.4 lists transaction 1.4 as one of its properties. The parent field of the new unknown reserveFlight transaction is updated to identify the preceding unknown seat transaction (“seat [3.3]” inFIG. 7B) and the parent field of the new unknown seat transaction is updated to identify the preceding unknown reserveFlight transaction (“reserveFlight [1.3] inFIG. 7B). Similarly, the children fields of the preceding unknown transactions are updated, such that the children field of the preceding unknown seat transaction (“seat [3.3]”) identifies the new unknown reserveFlight transaction (“reserveFlight [3.4]”) and the children field of the preceding unknown reserveFlight transaction (“reserveFlight [1.3]”) identifies the new unknown seat transaction (“seat [1.4]”).
• To use a service model that is implemented using the data pattern ofFIG. 6, a request processing module can process each received request in the following manner. If no conversations are currently taking place, the request processing module can first determine whether a received request is part of any starter transaction by comparing the received request to the requests included in the starter transactions identified in each instance ofconversation pattern620 identified inconversations field614. If so, the request processing module can select the appropriate instance of conversation pattern620 (i.e., the instance whosestarter field621 identifies the transaction that matches the received request) in order to process subsequently received requests. The request processing module can also identify the appropriate instance oftransaction pattern630 associated with the transaction matching the received request in order to generate an appropriate response to be sent to the requester. Identifying the appropriate instance can involve examining each known transaction identified as a property of the starter transaction, in order to see if the new request matches a known transaction. If the new request matches a known transaction, that known transaction is used to respond. Otherwise, the unknown transaction is used to respond.
• If the received request is not part of a starter transaction and no conversation is currently taking place, the request processing module can identify whether the request is part of one of the transactions identified instatelessConversation field615. If a match is found, the request processing module can use the information associated with the matching transaction to generate a response to be sent to the requester. If no match is found, the request processing module can access the instance ofresponse pattern650 identified inunknownResponse field613 and use the information stored within that response pattern instance to generate a response.
• If a conversation is already taking place, the request processing module can determine whether the received request is a goodbye or reset transaction for the conversation (as identified bygoodbye field623 or resetfield622 of the instance ofconversation pattern620 associated with the ongoing conversation). If so, the information describing the matching goodbye or reset transaction can be used to generate a response, and the request processing module can update its state accordingly (e.g., to indicate that no conversation is currently ongoing if the request matched the goodbye transaction, or the move the state of the conversation back to the point after handling the starter transaction if the request matched the reset transaction).
• If the received request is not a goodbye or reset transaction for the ongoing conversation, the request processing module can determine whether the request matches any of the transactions that are allowed to occur at that particular point in the conversation (e.g., as specified by thematchTolerance field635 of the last transaction handled in the conversation). If so, the request processing module can use the matching transaction to generate a response. If a matching unknown transaction is found, the request processing module can first determine whether the received request matches any of the known transactions that are properties of the matching unknown transaction. If so, the request processing module can use the known transaction to generate a response. Otherwise, the request processing module can use the matching unknown transaction to generate the response.
• If a conversation is already taking place, the received request is not a goodbye or reset transaction for the conversation, and the received request does not match any of the transactions that are allowed to occur at that particular point in the conversation, the request processing module will generate the response identified inunknownResponse field613. This response will be generated even if the received request would have matched one of the other transactions included in the service model, since the request was received during a conversation. Reception of such a request may also cause the existing state of the conversation to be discarded, such that the next request received from the requester will be handled as if there is no ongoing conversation.
• FIG. 8 is a block diagram of software that can be stored on a testing client. As shown, the testing client is acomputing device700 that includes a processor702 (e.g., a microprocessor, programmable logic device (PLD), or application specific integrated circuit (ASIC)), one ormore interfaces704, andmemory706. Instructions executable byprocessor702 are stored inmemory706. These instructions are executable to implement application undertest410,device manager450, andtesting driver425.Computing device700 can be a personal computer, server, personal digital assistant, cell phone, laptop, workstation, or the like.Memory706 can each include various types of RAM (Random Access Memory), ROM (Read Only Memory), Flash memory, MEMS (Micro Electro-Mechanical Systems) memory, and the like.Processor702,memory706, and interface(s)704 are coupled to send and receive data and control signals by a bus or other interconnect.
• Interfaces704 can each include an interface to a storage device on which instructions and/or data (e.g., such as data implementing a service model) are stored.Interfaces704 can also each include an interface to a network, such as a local area network (LAN) or wide area network (WAN) such as the Internet, for use in communicating other devices. Such an interface can allow application undertest410 to send requests to services via a network. Similarly, such an interface can allowtesting driver425 to communicate with a testing module implemented on another computing device.Interface704 can also include interfaces to various peripheral Input/Output (I/O) devices, such as a monitor, on which a graphical interface (e.g., allowing a user to configure and control the model building and/or model deployment process) can be displayed.
• FIG. 9 is a block diagram of software that can be stored on a testing server. As shown, the testing server is implemented usingcomputing device800, which includes a processor802 (e.g., a microprocessor, programmable logic device (PLD), or application specific integrated circuit (ASIC)), one ormore interfaces804, andmemory806. Instructions executable byprocessor802 are stored inmemory806. These instructions are executable to implementtesting module460, which includes user interface480 andservice model generator20, as well asvirtual service environment850 which includes virtual service880(1) and virtual service880(2). The two virtual services can be different instances of the same virtual service or different virtual services. Each virtual service can be implemented as a request processing module executing in a container, where the request processing module is configured to use a specific service model to determine how to respond to requests.
• Like computingdevice700,computing device800 can be a personal computer, server, personal digital assistant, cell phone, laptop, workstation, or the like.Memory806 can each include various types of RAM (Random Access Memory), ROM (Read Only Memory), Flash memory, MEMS (Micro Electro-Mechanical Systems) memory, and the like.Processor802,memory806, and interface(s)804 are coupled to send and receive data and control signals by a bus or other interconnect.
• Interfaces804 can each include an interface to a storage device on which instructions and/or data (e.g., such as data implementing a service model) are stored.Interfaces804 can also each include an interface to a network, such as a local area network (LAN) or wide area network (WAN) such as the Internet, for use in communicating other devices. Such an interface can allow virtual services880(1) and880(2) to receive requests and send responses via a network. Similarly, such an interface can allowtesting module460 to communicate with another computing device in order to, for example, deploy a testing driver.Interface804 can also include interfaces to various peripheral Input/Output (I/O) devices, such as a monitor, on which a graphical interface (e.g., allowing a user to configure and control the model building and/or model deployment process) can be displayed.
• InFIGS. 8 and 9, program instructions and data implementing various software components such as application undertest410,device manager450,testing driver425,service model generator20, user interface480,testing module460, virtual service880(1), and virtual service880(2) can be stored on various computer readable storage media such asmemory706 and806. In some embodiments, such program instructions can be stored on a computer readable storage medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), hard disk, optical disk, tape device, floppy disk, and the like. In order to be executed by a processor, the instructions and data are loaded into memory from the other computer readable storage medium. The instructions and/or data can also be transferred to a computing device for storage in memory via a network such as the Internet or upon a carrier medium. In one embodiment, the components used implement a service model generator, testing module, testing driver, and the like are implemented using LISA (Live Interaction Service Architecture)™, available from iTKO, Inc. of Dallas, Tex.
• It is noted that the above figures illustrate specific examples. In other embodiments, different components can be used to implement the testing functionality described above. For example, while specific software components have been described as implementing specific functionality, this functionality can be implemented by different components than those depicted herein. For example, the functionality ofservice model generator20 can be subdivided into multiple other test management components or integrated into another component withintesting module460. Furthermore, the specific components depicted in the figures herein can be combined or subdivided into fewer or additional components.
• Additionally, other components can be used instead of and/or in addition to those shown in the figures presented herein. Such other components can provide different or additional functionality instead of and/or in addition to the functionality described herein. Furthermore, some of the functionality described herein can be eliminated in some embodiments.
• Although the present invention has been described in connection with several embodiments, the invention is not intended to be limited to the specific forms set forth herein. On the contrary, the present invention is intended to cover such alternatives, modifications, and equivalents as can be reasonably included within the scope of the invention as defined by the appended claims.

Claims (26)

What is claimed is:

1. A method comprising:

monitoring, using a processor device, transactions involving a particular software service;

detecting, during the monitoring, a particular transaction comprising an observed request of the particular software service and an observed response to the request from the particular software service;

identifying a time-sensitive attribute of the particular transaction; and

generating a virtual service model comprising transaction information describing the detected particular transaction, wherein the virtual service model models a response of the particular software service based on the time-sensitive attribute.

2. The method ofclaim 1, wherein the transaction information describes a plurality of transactions involving the particular software service.

3. The method ofclaim 1, wherein the time-sensitive attribute defines a delta time value between a first time value of the observed request and a second time value of the observed response.

4. The method ofclaim 3, wherein the first time value is a system clock time value corresponding to the observed request.

5. The method ofclaim 3, wherein the first time value is a system clock time value corresponding to the observed response.

6. The method ofclaim 3, wherein the second time value is a time value attribute of the observed request.

7. The method ofclaim 3, wherein the second time value is a time value attribute of the observed response.

8. The method ofclaim 3, wherein the first and second time values are captured during the monitoring.

9. The method ofclaim 3, wherein the second time value comprises a user-defined value.

10. The method ofclaim 3, wherein the second time value is a time value in a plurality of time values of the observed response and the time-sensitive attribute defines respective delta time values for each of the plurality of time values relative the first time value.

11. The method ofclaim 1, further comprising determining whether the observed response is a time-sensitive response.

12. The method ofclaim 11, wherein determining whether the observed response is a time-sensitive response comprises attempting to identify a time attribute in the observed response.

13. The method ofclaim 12, wherein a system clock value corresponding to the observed response is identified in the absence of a time attribute in the observed response.

14. The method ofclaim 1, wherein the time-sensitive attribute is an at least partially user-defined.

15. The method ofclaim 14, wherein the observed request comprises a time attribute in the request and a detected system clock value corresponding to the request and the time-sensitive attribute comprises a user definition that the time-sensitive attribute is dependent on one of the time attribute in the request and the detected system clock value.

16. A computer program product comprising a computer readable storage medium comprising computer readable program code embodied therewith, the computer readable program code comprising:

computer readable program code configured to monitor transactions involving a particular software service;

computer readable program code configured to detect, during the monitoring, a particular transaction comprising an observed request of the particular software service and an observed response to the request from the particular software service;

computer readable program code configured to identify a time-sensitive attribute of the particular transaction; and

computer readable program code configured to generate a virtual service model comprising transaction information describing the detected particular transaction, wherein the virtual service model models a response of the particular software service based on the time-sensitive attribute.

17. A system comprising:

a processor device;

a memory element; and

service model generator adapted to:

monitor transactions involving a particular software service;

detect, during the monitoring, a request of the particular software service;

detect, during the monitoring, a response by the particular software service to the request;

determine a time-sensitive attribute of the response relative to the request; and

generate a virtual service model of the particular software service based at least in part on the detected request, detected response, and time-sensitive attribute.

18. The system ofclaim 17, wherein the time-sensitive attribute defines a time delta between the detected request and the detected response.

19. The system ofclaim 18, wherein a particular observed transaction involving the particular software service comprises the detected request and the detected response and the system further comprises a request processing module adapted to:

receive, from a requesting software component, a request of the particular software service;

identify, from the virtual service model, that the particular request corresponds to the particular observed transaction;

return to the requesting software component a particular response to the received request, the particular response generated from the virtual service model and applying the time-sensitive attribute.

20. A method comprising:

receiving, from a requesting software component, a request of a particular service;

identifying a virtual service model corresponding to the particular service, the virtual service model modeling the particular service and adapted to model a time-sensitive response of a particular transaction of the particular service; and

using a processor device to return to the requesting software component a particular response to the received request generated from the virtual service model.

21. The method ofclaim 20, wherein returning the particular response comprises:

identifying that the received request substantially matches a particular request of the particular transaction;

identifying a time value of the received request; and

applying a time-sensitive value of the time-sensitive response to the time value of the received request to generate a time attribute of the returned request.

22. The method ofclaim 21, wherein the time value of the received request is a system clock value detected as corresponding with the receiving of the request.

23. The method ofclaim 21, wherein the time value is an attribute of the received request.

24. The method ofclaim 21, wherein the time-sensitive value is a time delta value between a time value corresponding to the particular request of the particular transaction and a time value corresponding to the time-sensitive response of the particular transaction.

25. The method ofclaim 20, wherein the request is received in a virtual service environment comprising one of a development, testing, load testing, integration testing, and training environment.

26. A computer program product comprising a computer readable storage medium comprising computer readable program code embodied therewith, the computer readable program code comprising:

computer readable program code configured to receive, from a requesting software component, a request of a particular service;

identify a virtual service model corresponding to the particular service, the virtual service model modeling the particular service and adapted to model a time-sensitive response of a particular transaction of the particular service; and

return to the requesting software component a particular response to the received request generated from the virtual service model.

Images