Stateless and Conversational VSE Transactions

lvse transactions are classified as stateless or conversational.
transactions are classified as
Stateless Transactions
transactions include no logical relationships between transactions. For example, HTTP and SOAP are stateless protocols.
A stateless transaction always has a static response, regardless of what calls were made previously. Each stateless transaction is independent of the others. For example:
  • What is the current weather in Dallas? (Operation: weather; Argument: city)
  • What is the current weather in New York? (Operation: weather; Argument: city)
  • What will the weather be in Dallas tomorrow? (Operation: weather; Argument: city; Argument: date)
Conversational Transactions
Conversational transactions are
. Conversations consist of:
  • The logical transaction that, if matched, starts a unique session
  • The information necessary to create and identify that session
A transaction in a conversation depends on the context that earlier conversations create.
For example, the following conversation involves using an ATM:
  1. Connect to the ATM. (Operation: logon)
  2. Which account do you want? (Argument: checking)
  3. What is my balance? (Operation: balance)
  4. Response.
  5. Withdraw an amount of money. (Operation: withdraw)
  6. How much? (Argument: amount)
  7. What is my balance? (Operation: balance)
  8. Response.
  9. End session. (Operation: logout)
Conversation Starters
The first transaction in a conversation is the
conversation starter
. When a virtual service environment (
) receives an incoming request, the 
reviews the conversation starters to determine whether the transaction means a new conversation is starting.
Because all the transactions in a conversation are related to each other, the
must have a way of determining this relationship. This determination is typically made by using some kind of special token such as "jsessionid" or a cookie in web transactions, or a custom identifier in message traffic.
The following types of conversations are supported:
  • Instance-based conversations
    The protocol layer is responsible for identifying the unique string, which is based on different instances of the client. The string identifies server-side sessions for both recording and playback of the service image.
  • Token-based conversations
    generates the token by using a string generation pattern that is stored with the conversation in the service image. After the token is generated, it operates the same as an instance-based conversation. Token-based conversations cannot be automatically inferred during recording. To specify where tokens are found, use the VS Image Recorder.