Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:59:06Z

Rvenkat: /* Guidelines for Design Using Object Think [2] */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process [1].

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.[2]

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" [3] suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [8]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

Example of a fusion process is explained in [7].

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] [http://www.phruby.com/publications/Example-Fusion.pdf Fusion Example]

[8] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[9] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:58:25Z

Rvenkat: /* Object Think */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process [1].

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.[2]

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" [3] suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think [2] ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [8]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

Example of a fusion process is explained in [7].

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] [http://www.phruby.com/publications/Example-Fusion.pdf Fusion Example]

[8] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[9] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:55:14Z

Rvenkat: /* CRC Cards */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process [1].

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [8]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

Example of a fusion process is explained in [7].

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] [http://www.phruby.com/publications/Example-Fusion.pdf Fusion Example]

[8] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[9] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:51:33Z

Rvenkat: /* FUSION */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [8]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

Example of a fusion process is explained in [7].

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] [http://www.phruby.com/publications/Example-Fusion.pdf Fusion Example]

[8] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[9] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:51:00Z

Rvenkat: /* FUSION */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [8]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

Example of a fusion process is explained in [8].

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] [http://www.phruby.com/publications/Example-Fusion.pdf Fusion Example]

[8] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[9] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:46:16Z

Rvenkat: /* References */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [6]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.[7]

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] [http://www.phruby.com/publications/Example-Fusion.pdf Fusion Example]

[8] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[9] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:45:35Z

Rvenkat: /* FUSION */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol [6]. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.[7]

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[8] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:36:26Z

Rvenkat: /* CRC Cards */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[8] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:28:25Z

Rvenkat: /* CRC Cards */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card [[1]] Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[8] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:28:09Z

Rvenkat: /* CRC Cards */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card [1] Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[8] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:12:48Z

Rvenkat: /* References */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

[1] [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

[2] Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

[3] [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

[4] [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

[5] [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

[6] Designing Object Oriented Software by Wirfs-Brock et al.

[7] Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

[8] [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T04:10:18Z

Rvenkat: /* Example */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

[[Image:Fig_Seq_Diagram.png|frame|center|alt=Sequence Diagram|Figure 1 ''[[Sequence Diagram]]''.]]

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

* Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

* [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

* [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

* [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

* Designing Object Oriented Software by Wirfs-Brock et al.

* Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

* [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

* [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

File:Fig Seq Diagram.png

2009-11-24T04:01:32Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T03:55:42Z

Rvenkat: /* Example */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

UML class diagram captures the basic properties of the objects and their operations. The information in the UML class diagram is similar to the one in CRC cards. However, Fig.1 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

* Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

* [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

* [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

* [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

* Designing Object Oriented Software by Wirfs-Brock et al.

* Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

* [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

* [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T03:51:15Z

Rvenkat: /* Example */

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

CRC Cards

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

UML

Fig.1 shows the UML class diagram that captures the basic properties of the objects and their operations. This information is similar to the one in CRC cards. However, Fig.2 shows the sequence diagram for a particular use case. Consider the use case customer purchasing a car and getting it registered with DMV.

Sequence diagrams, apart from capturing the interaction of the classes (similar to collaborators in CRC cards), they are also explaining the exact sequence of operations to be performed. Hence sequence diagrams can be used by developers to implement the system requirements with more clarity.

= References =

* Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

* [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

* [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

* [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

* Designing Object Oriented Software by Wirfs-Brock et al.

* Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

* [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

* [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-24T03:40:55Z

Rvenkat:

Topic : CRC cards are useful, but have some limitations. For example, they require that a group be present; it is sometimes hard to get a group together. One alternative technique is "Object Think." Compare CRC cards with Object Think and any other alternatives for the first stages of analysis and design.

= CRC Cards =

CRC (Class-Responsibility-Collaborator) Card Modeling was first introduced by Kent Beck and Ward Cunningham. It is a simple yet powerful object-oriented analysis technique where users, analysts, and developers can work together in a modeling and design process.

CRC Cards are usually created from index cards which contain the following information:
* Class name - the name of the class
* Responsibilities - anything that the class knows or does
* Collaborators - names of other classes with which the class will collaborate to fulfill its responsibilities

The size of the index card forces the designers or participants to limit the class from having too many responsibilities or collaborations with other classes. The designers should consider breaking a class that has too many responsibilities into multiple classes. Class that has too many collaborations with other classes will create high coupling, which does not adhere with the object oriented methodology.

= Object Think =

Simon Horwith defines “Object Think” as an approach to Object Oriented Programming based on the practice of object personification.

Object Think represents a way to think of the domain model in terms of objects, which further helps in developing or designing classes. Object Think was suggested as a practical alternative to CRC cards in 1993 by Coad and Nicola. The primary benefit of Object Think is that unlike CRC cards, it can be done individually and no group is required.

In Object Think perspective, objects are modeled to carry out real world functions. Then the responsibilities are distributed across objects as part of the design. Object Think therefore helps to create an accurate domain model where every object in the domain model handles all of its own responsibilities. The advantage of this approach is that as the software system is initially designed, the designers might start with fewer objects carrying out many functionality. As the system grows over time, Object Think will lead to design a community of objects sharing those responsibilities.

Object Think also bridges the traditional process-oriented thinking with the object mindsets. For example, the real world scenario of communication translates to Messaging in the Object Oriented paradigm.

Object Think perceives Objects as independent entity performing actions and making decisions on its own. Mike Abney, in the article -"Object Think: A Perspective on Objects" suggests that an object's capability to act is one of its three categories of responsibilities: "whom I know," "what I do," and "what I know." Peter Coad and Edward Youdon (in Object-Oriented Analysis, 2nd ed., Prentice Hall, 1990) refers this to object's services. Although technically services refer to an operation or procedure, when an object performs the services they are viewed as actions on the objects. As an example, an account object provides a debit method. So, when the debit method is acted on the object, it is viewed as debit action being carried upon the object. This means the state of the object changes based on the action that is being performed on the object.

== Guidelines for Design Using Object Think ==

1. Everything in the domain model is an object. This means that a class technically cannot have free-floating functions that are not related to an object of the class. Functions generally represent the actions on an object or a concept in the domain model. So, they have to be associated with an object that represent the concept

2. Think like an Object

3. Model the objects of a system using the language of the domain model. This helps designers to focus on the domain model and design a system with a high level perspective instead of bogged down with low level implementation details.The purpose and capabilities of an object has to be designed and stated clearly. Also, the implementation should statisfy the stated goal.

4. Objects should have context free behavior - This really means that Objects should be designed with the object oriented principles like encapsulation, cohesion, coupling, reuse etc. and Objects should be modeled as autonomous agents that perform the operations in isolation.

5. Design using simulation - Simulating a domain model by representing it in terms of various objects will help to identify the details of the design.

6. Design to keep functions and data together - Domain model's operations can be represented as actions on objects. Since these operations affect the state of the object, it is a good practice to tie objects and their operations together.

== Benefits of Object Thinking ==

1. Unlike CRC, Object thinking can be carried out by individuals

2. Design using Object think provides a maintainable code as in a long run, a system will have objects sharing ther responsibilities and collaborating to complete a domain operation

3. Design using object think also results in a reusable code

4. Since Object Think insists on stating the purpose and capabilities of the objects, this will result in a better definition of data and the responsibility on the objects

5. Also, Object Think can be used as a platform to educate developers to become object oriented thinkers

= Alternatives to CRC Cards =
== Unified Modeling Language (UML) ==

UML is a visual language for specifying, constructing, and documenting the artifacts of systems.

Advantages of UML Diagram compared to CRC cards:
# You can use UML with all processes, throughout the development lifecycle, and across different implementation technologies.
# You can easily visualize the relationship between classes or objects.
# The complete structure of the system can be captured in one UML diagram, instead of several CRC cards.

== OMT ==
The Object Modeling technique combines three views of a system and hence three models are used for representing the views.

# Object Model – describes the static structure of the objects and their relationships in the system. This represents the concepts like attribute, operation, inheritance, association, aggregation etc.
# Dynamic Model – describes the aspects of the system that changes over time. This model explains the concepts like states, event, activity, etc.
# Functional Model – describes the data value transformations in a system. This model explains the concepts like process, data flow, and control flow, actor, etc.

During the analysis phase of the design, all these models are developed and delivered. Object Model Diagram provides a formal graphic notation for modeling objects, classes and their relationships with one another. State diagrams and Event flow diagrams will represent the dynamic model of the system. Data flow diagram represents the data transformation within the system due to the events or actions of the actors.
OMT differs from CRCs in the way the system is viewed. Apart from viewing the systems as classes and responsibilities, OMT provides a richer way to view and design the system using the 3 models as described above.

== Booch Method of OOAD ==

Booch Method is a process and notation for developing and communicating the design of an object-oriented software system. Booch method contains proven heuristics for developing quality software that provides effective design and support for development of future systems.
Booch method is a broad methodology that addresses OOAD using object modeling, analysis modeling, application design, implementation design etc.

Booch method uses following types of diagrams to describe the design decisions that must be made when creating an Object-Oriented system.

Class Diagrams: Represents set of classes and class relationships

Class Specification is used to capture all the information about a class in text format. A class specification contains set of fields that define a class

Category Diagrams are used to group logically related classes in to meaningful collection.

State Transition Diagrams represents the dynamic behavior associated of the classes in the system

Object Diagrams show the existence of objects and their relationships in the logical model of the system.

Timing Diagram is a graph that augments an on object diagram to capture information about external events and timing of operations in the object diagram

Module Diagram is used to show the allocation of classes and objects to module in the physical design of the system.

Process Diagrams represents various process flows and their allocation to processors of the system

Subsystems represent the clusters of logically related modules

The analysis and design steps in Booch method will result in class diagrams, class specifications, object specifications, inheritance views, class category diagrams, architectural descriptions.

== Coad, Yourdon and Nicola OOAD ==

In Coad, Yourdon and Nicola method, OOA works with problem domain classes and objects and OOD focuses on human interaction, task management, and data management classes and objects. In this method, each class and its objects fit into one of the four components: human interaction component, problem domain component, task management component, data management component. They differ from traditional CRCs in a way that the approach revolves around the principles of managing complexity. Three most important principles to manage complexity are:

1. Pervading methods of organization – This is similar to how real world people organize the objects via differentiating objects based on attributes, forming a class of objects based on the features.

2. Categories of behavior – This concept is the basis for identifying the actions of an object

3. Personification – This gives a human characteristic to inanimate objects

== FUSION ==

Fusion method was developed by Object Oriented Design Group at Hewlett-Packard Laboratories, Bristol. The method builds on existing Booch, OMT, CRC and provides a direct route from requirements definition through to a programming language implementation.
The analysis phase of this method provides a declarative description of system behavior. The Object model describes the static structure of the objects in the problem domain and their interrelation. The Interface model describes the interface of a system and how the system interacts with the environment.

The design stage realizes the system behavior using various outputs as given below.

1. Object Interaction Graph and visibility graph shows how objects interact with each other to complete an operation that is defined in the interface model. Algorithms, classes and their attributes, method signatures are specified accompanying each object interaction graph. Visibility graph complements the Object Interaction graph as it shows how the references among various objects are implemented.

2. Class description captures the class interfaces, attributes, object reference attributes and method signatures

3. Inheritance Graphs are specified to capture the relationships between the objects that are working together.

==Example==

Consider developing an integrated web based system for car sales and services. Assume that the system will be used by car manufacturers, car dealers, customers who purchase the cars and services (services include buying insurance policy, registering the car with DMV etc).

===CRC Cards===

Main Classes

Class Manufacturer

Class Dealer

Class Customer

Class Insurance Provider

Class DMV

Responsibilities and Collaborator

Class Manufacturer – accept quotes and orders from dealers; deliver cars to dealers – collaborates with dealer

Class Dealer - order cars from Manufacturer; market it to customers; service maintenance for the customer cars – collaborates with Manufacturer, Customer

Class Customer - Buy car from dealer; buy insurance policy; get license and registration from DMV; take car to the service – Collaborates with Dealer, Insurance Provider, DMV

Class Insurance Provider - Make Auto insurance plans; sell plans to the customers - collaborates with customers

Class DMV – Provide appointments to Customers; Provide License to the customers; register cars; - collaborates with Customers

CRC cards in use for this design

In the initial design process each of these five classes get into separate cards with corresponding responsibilities and collaborations. Business stake holders (Business owners representing each of the entities basically Manufacturers, Customers, Insurance providers, Dealers and DMV) get together for design of this system. Though this design looks simple at the outset there are more intricate details hidden in each of these classes and their corresponding responsibilities.

Consider a customer buying a car. He generally requests quote from the dealer then after negotiations they come to an agreement on the price and customer might customize the car which dealer has to provide corresponding services with and then while selling the car the dealer has to generate an invoice (bill) which has to be sent to customers address and there are various ways of payment modes. Number of classes and their responsibilities increases (hard to maintain) and it becomes cumbersome to maintain which class collaborations.

= References =

* Object Think - Common Sense Software Architecture by Simon Horwith on cfunited conference 2006

* [http://www.informit.com/articles/article.aspx?p=25184&seqNum=4 Object Think: A Perspective on Objects by Mike Abney]

* [http://net.educause.edu/ir/library/text/c95/c95-ps04.txt "OBJECT THINK" A Step toward Object Oriented Implementation]

* [http://corfield.org/blog/index.cfm/do/blog.entry/entry/Object_Think Object Think]

* Designing Object Oriented Software by Wirfs-Brock et al.

* Object Analysis and Design : Description of Methods by Andrew T.F. Hutt

* [http://students.cs.byu.edu/~pbiggs/survey.html A Survey of Object-Oriented Methods by Peter Biggs]

* [http://www.softstar-inc.com/Download/Intro%20to%20CRC.pdf Introduction to CRC Cards by David M. Rubin]

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T03:51:54Z

Rvenkat: /* References */

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T03:46:06Z

Rvenkat: /* References */

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-19T03:42:50Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-18T06:00:00Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-18T05:59:33Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-18T05:48:08Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-18T05:47:30Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki3 10 OT

2009-11-18T03:40:58Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-10T15:07:14Z

Rvenkat: /* Double Submit Problem */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission. It is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser Warning Display.png|frame|center|alt=Browser Warning Display|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

[[Image:PRG Pattern.png|frame|center|alt=PRG Pattern|Figure 2 ''[[POST-REDIRECT-GET]]''.]]

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

[[Image:Synch token.png|frame|center|alt=STP Pattern|Figure 3 ''[[Synchronized-Token-Pattern]]''.]]

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was designed with the intention to help developers implement complex conversations within web applications. Spring Web Flow acts as a controller component in the MVC triad and integrates into hosting web MVC frameworks. It serves as an application controller and handles the screen navigation by coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 4 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 5 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 6 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 6 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 7 ''[[Simple Repository]]''.]]

The [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] guards access to the flow execution by changing the flow execution key for every request thereby imitating the use of a synchronizer token. The methods getNextKey(flowExecution, previousKey) always returns a new key that is different from the previous key. A user can no longer access the flow execution using browser navigation since the request is rendered as stale. The use of Back button on the browser to access history is completely disabled and a user may get an error. When the conversation ends the same situation will occur. When the conversation ends Spring Web Flow will clean up the conversation state and prevent the user form resuming the terminated conversation or to cause duplicate submits.
 Pros and Cons - The single most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high.
A downside is that it does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository called as [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository]. It will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request the single key repository maintains a single key for every flow execution and hence it supports the use of Back button. Although, since it maintains only a single snapshot of the flow execution it does not support the use of Back button.
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. This is caused by the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh. Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=12345
</pre>

The browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!
Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submits.

Pros and Cons - Like the simple repository, the single key repository has an important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
Although the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 8 ''[[Continuation Repository]]''.]] Continuation Repository is a powerful execution repository provided by Spring Web Flow implemented by the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/continuation/ContinuationFlowExecutionRepository.html ContinuationFlowExecutionRepository] class. As suggested by the name the continuation repository manages flow executions using a web continuations algorithm which are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. Struts framework required modification in order to support multiple windows on a single conversion. The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 8 shows this graphically.
* The first request that comes into the flow executor does not contain a flow execution key and hence the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to a view state which is the second state and then pauses. The flow execution repository takes a snapshot of the FlowExecution and a unique key is assigned. The control is then returned to the Browser. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key and the response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing and pauses after moving to third state. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. At this point the first snapshot is still present which allows the user to click the Back button and jump back to the previous request to continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 9 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-10T00:24:31Z

Rvenkat: /* Synchronizer Token Pattern */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser Warning Display.png|frame|center|alt=Browser Warning Display|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

[[Image:PRG Pattern.png|frame|center|alt=PRG Pattern|Figure 2 ''[[POST-REDIRECT-GET]]''.]]

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

[[Image:Synch token.png|frame|center|alt=STP Pattern|Figure 3 ''[[Synchronized-Token-Pattern]]''.]]

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 4 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 5 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 6 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 6 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 7 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 8 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 8 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 9 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

File:Synch token.png

2009-10-10T00:18:13Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-10T00:17:49Z

Rvenkat: /* Synchronizer Token Pattern */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser Warning Display.png|frame|center|alt=Browser Warning Display|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

[[Image:PRG Pattern.png|frame|center|alt=PRG Pattern|Figure 2 ''[[POST-REDIRECT-GET]]''.]]

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

[[Image:Synch token.png|frame|center|alt=PRG Pattern|Figure 3 ''[[Synchronized-Token-Pattern]]''.]]

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 4 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 5 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 6 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 6 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 7 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 8 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 8 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 9 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T23:42:12Z

Rvenkat:

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser Warning Display.png|frame|center|alt=Browser Warning Display|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

[[Image:PRG Pattern.png|frame|center|alt=PRG Pattern|Figure 2 ''[[POST-REDIRECT-GET]]''.]]

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 4 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 5 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 6 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 6 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 7 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 8 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 8 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 9 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T04:05:34Z

Rvenkat: /* Server Side Solution - PRG Pattern */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser Warning Display.png|frame|center|alt=Browser Warning Display|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

[[Image:PRG Pattern.png|frame|center|alt=PRG Pattern|Figure 2 ''[[POST-REDIRECT-GET]]''.]]

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

File:PRG Pattern.png

2009-10-09T04:03:56Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T04:00:37Z

Rvenkat: /* Client Side Solution - Browser Warning Disabling */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser Warning Display.png|frame|center|alt=Browser Warning Display|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T03:35:54Z

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser Warning Display.png|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T03:35:02Z

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Image:Browser Warning Display.png|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

File:Browser Warning Display.png

2009-10-09T03:29:08Z

Rvenkat:

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T03:28:16Z

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

[[Image:Browser_Warning_Display|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Display warning message in the browser]]''.]]

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T01:25:51Z

Rvenkat: /* Server Side Solution - Synchronizer Token Pattern */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

<<insert diagram here>>

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern which is explained below can also be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T01:21:44Z

Rvenkat: /* Synchronizer Token Pattern */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

<<insert diagram here>>

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern can be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert diagram here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T01:20:26Z

Rvenkat: /* References */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

<<insert diagram here>>

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern can be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert figure here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] Alur, Deepak, John Crupi, and Dan Malks. 2003. Core J2EE patterns: Best practices and design strategies. 2nd ed. Santa Clara: Sun Microsystems Press.

[2] Redirect After Post, Michael Jouravlev, August 2004

[3] http://www.javaworld.com/javaworld/javatips/jw-javatip136.html?page=1

[4] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[5] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[6] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T01:17:20Z

Rvenkat: /* Synchronizer Token Pattern */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

<<insert diagram here>>

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern can be applied to this problem as a server side solution.

=Synchronizer Token Pattern=

Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to avoid duplicate form submissions.

The Synchronizer Token pattern works as follows: When a conversation starts, the application generates a unique token that is stored in the HTTP session. The token is also embedded in each page generated during the conversation, and every request that is part of the conversation is required to include the token value. When a request arrives on the server, it compares the value of the token in the HTTP session with the value included in the request. If the two values match, the request is allowed to continue processing. If they don’t match, an error is generated informing the user that the conversation has ended or was invalidated. The token is removed from the HTTP session when the conversation ends or the session expires.

<<insert figure here>>

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[2] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[3] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T00:59:53Z

Rvenkat: /* Solutions for Double Submit Problem */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

==Solutions for Double Submit Problem==

Multiple solutions are available to handle these scenarios are discussed below.

====Client Side Solution - Browser Warning Disabling====

User can be warned not to submit again and can be asked to wait for a response after submitting. Web browsers display a warning to the user when the user tries to reissue a POST request. However, refreshing pages loaded using GET request is allowed and no browser warning will be shown.

<<insert diagram here>>

====Client Side Solution - Javascript Control Disabling====

Client based strategy to this issue is to disable the submit button once the form is submitted. Although this could be an easy solution to implement using javascript, it is not as dependable as server side as it is browser based and can be overridden on the browser.

====Server Side Solution - PRG Pattern====

POST-REDIRECT-GET idiom or PRG Pattern (Jouravlev 2004) offers a decent solution to this problem. The idiom suggests that a web application should issue a REDIRECT request internally as a response to the initial POST request. This internal REDIRECT will then cause a subsequent GET request as shown in the diagram below:

<<insert diagram here>>

The web browser that receives a redirect response will then add only the redirected GET request instead of adding the original request to its browsing history. Hence this elegantly solves the double submit problem as the redirected request which is being a GET request can be safely refreshed multiple times.
Also since the navigational history on the browser will now on contain the idempotent GET requests, user can use back or forward buttons on the browser or bookmark the pages without disrupting the control flow.

====Server Side Solution - Synchronizer Token Pattern====

Synchronizer token pattern can be applied to this problem as a server side solution.

=Synchronizer Token Pattern=
How the patten works? Diagrammatic Representation? Theoretical View? Reply on session.

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[2] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[3] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T00:45:17Z

Rvenkat: /* Double Submit Problem */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. Submission of POST data more than once could result in undesirable results and hence the name : Double Submit Problem . Generally POST requests contain input data and could change the state of the server. So, submitting a form twice or multiple times could result the server in an inconsistent state.

This problem can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

=Solutions for Double Submit Problem=
Can be server side or client side. Server Vs Client which one is better?

==Client Side Solution - Javascript Control Disabling==

Briefly describe the approach. Discuss pros and cons.

==POST-REDIRECT-GET==

Briefly describe the approach. Discuss pros and cons.

=Synchronizer Token Pattern=
How the patten works? Diagrammatic Representation? Theoretical View? Reply on session.

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[2] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[3] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T00:32:21Z

Rvenkat: /* Double Submit Problem */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=

Double Submit Problem is a specific instance of the generic Duplicate form submission is a common issue with any web based application that has server side transactions. This can occur due to any of the following reasons

(a) User clicks the submit button more than once

(b) User inadvertently pressing a back button on the web browser and resubmitting the same form, thereby invoking the duplicate transaction

(c) User refreshes the page after successful completion of the transaction. This will invoke the previous transaction again on the server side

(d) User invokes the transaction, but stops the transaction after the transaction is completed on the server side but before the response is rendered on the screen and refreshes the page causing the transaction to be duplicated

For instance, assuming an user is checking out a cart from an e-commerce site like amazon.com. User does check-out after paying through credit card and the transaction is successful. For whatever reasons, if user inadvertently refreshes this page, then user's credit card could be charged twice.

=Solutions for Double Submit Problem=
Can be server side or client side. Server Vs Client which one is better?

==Client Side Solution - Javascript Control Disabling==

Briefly describe the approach. Discuss pros and cons.

==POST-REDIRECT-GET==

Briefly describe the approach. Discuss pros and cons.

=Synchronizer Token Pattern=
How the patten works? Diagrammatic Representation? Theoretical View? Reply on session.

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[2] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[3] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki2 3 pp

2009-10-09T00:17:46Z

Rvenkat: /* Synchronizer Token Pattern - Introduction */

=Synchronizer Token Pattern - Introduction=
Synchronizer token pattern is a well know design pattern (Alur 2003) that is normally used in web application development to control flow sequence.

Normal flow sequence of an application can be disrupted by the following ways like

1. Duplicate Form Submissions

2. Access a page in an out of order fashion via bookmarks

Synchronizer token pattern is listed as one of the "Presentation Tier Refactorings" pattern in the [http://www.corej2eepatterns.com Core J2EE Patterns 2nd edition.]

=Double Submit Problem=
What is the requirement of having this pattern. Some examples such as Add to cart being pressed twice can result in 2 items in the cart etc. The example should provide or demonstrate how devastating this can be. Some financial example such as clicking on Pay button twice could charge credit card twice etc.

=Solutions for Double Submit Problem=
Can be server side or client side. Server Vs Client which one is better?

==Client Side Solution - Javascript Control Disabling==

Briefly describe the approach. Discuss pros and cons.

==POST-REDIRECT-GET==

Briefly describe the approach. Discuss pros and cons.

=Synchronizer Token Pattern=
How the patten works? Diagrammatic Representation? Theoretical View? Reply on session.

Using POST-REDIRECT-GET avoids accidental double submits of a single request but does not help prevent a user from completing the same business process twice. Such a business process is typically composed of multiple pages spanning several requests. Synchronizer token pattern adds additional safety on top of the POST-REDIRECT-GET idiom by preventing a possibly intentional resubmit of a page. Both the techniques should typically be combined to deliver a complete solution.

=Implementations related to Web Control Flow=
The basic idea of Synchronizer Token is to set a token in a session variable before returning a transactional page to the client. This page carries the token inside a hidden field. Upon submission, request processing first tests for the presence of a valid token in the request parameter by comparing it with the one registered in the session. If the token is valid, processing can continue normally, otherwise an alternate course of action is taken. After testing, the token resets to null to prevent subsequent submissions until a new token is saved in the session, which must be done at the appropriate time based on the desired application flow of control. Many web based frameworks provide built-in support for this. However some of the frameworks require serious developer attention whereas some frameworks do provide configurable automatic support. This section will describe Struts and Spring Web Flow provides Web Control Flow.

==Struts==
[http://struts.apache.org/ Apache Struts] provides built in mechanism for handling tokens in [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html org.apache.struts.action.Action] class using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] methods. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method creates a token (a unique string) and saves that in the user's current session, while [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] checks if the token stored in the user's current session is the same as that was passed as the request parameter.

To do this the JSP has to be loaded through an [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]. Before loading the [http://java.sun.com/products/jsp/ JSP] call [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] to save the token in the user session. When the form is submitted, check the token against that in the session by calling [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()], as shown in the following code snippet:

<pre>
class PurchaseOrderAction extends DispatchAction {
public ActionForward load(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
//save the token
saveToken(request)
// rest of the code for loading the form
} catch(Exception ex){
//exception
}
}

public ActionForward submitOrder(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws Exception {
try {
// check the token. Proceed only if token is valid
if(isTokenValid(request,true)) {
//implement order submit functionality here
} else {
return mapping.findForward("failure");
}
} catch(Exception ex){
//exception
}
}
}
</pre>

This actually what is happening behind the scene in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class. [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] has logic as below:

<pre>
HttpSession session = request.getSession();
String token = generateToken(request);
if (token != null) {
session.setAttribute(Globals.TRANSACTION_TOKEN_KEY, token);
}
</pre>

The method generates a random token using session id, current time and a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/MessageDigest.html MessageDigest] and stores it in the session using a key name [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (This is the value of the static variable [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY TRANSACTION_TOKEN_KEY] in [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html org.apache.struts.Globals] class).

The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] class that renders the form (PurchaseOrderAction.load) invokes the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] method to create a session attribute with the above name. In the JSP, the token needs to be as a hidden form field as follows:

<pre>
<input type="hidden" name="<%=org.apache.struts.taglib.html.Constants.TOKEN_KEY%>"
value="<bean:write name="<%=Globals.TRANSACTION_TOKEN_KEY%>"/>">
</pre>

The embedded [http://struts.apache.org/1.2.x/userGuide/struts-bean.html#write <bean:write>] tag shown above, looks for a bean named [http://struts.apache.org/1.1/api/constant-values.html org.apache.struts.action.TOKEN] (which is the value of [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) in session scope and renders its value as the value attribute of the hidden input variable. The name of the hidden input variable is [http://struts.apache.org/1.x/struts-taglib/apidocs/constant-values.html org.apache.struts.taglib.html.TOKEN] (This is nothing but the value of the static variable [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html#TOKEN_KEY TOKEN_KEY] in the class [http://struts.apache.org/1.x/struts-taglib/apidocs/org/apache/struts/taglib/html/Constants.html org.apache.struts.taglib.html.Constants]).

When the client submits the form, the hidden field is also submitted. In the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that handles the form submission i.e. PurchaseOrderAction.submitOrder (which most likely is different from the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] that rendered the form), the token in the form submission is compared with the token in the session by using the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. The method compares the two tokens and returns a true if both are same. Be sure to pass reset=”true” in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method to clear the token from session after comparison. If the two tokens are equal, the form was submitted for the first time. However, if the two tokens do not match or if there is no token in the session, then it is a duplicate submission and handle it in the manner acceptable to your users.

If the form is spanned across the multiple pages, then every time the form is submitted before going from one page to another. You definitely want to validate token on every page submission. However you also want to allow the user to traverse back and forth using the browser back button until the point of final submission. If the token is reset on every page submission, the possibility of back and forth traversal using the browser button is ruled out. The solution is not disabling back button (using [http://en.wikipedia.org/wiki/JavaScript JavaScript] hacks) but to handle the token intelligently. This is where the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is useful. The token is initially set before showing the first page of the form. The [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) reset parameter] is false for all the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest, boolean) isTokenValid()] invocations except in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action] for the last page. The last page uses a true value for the reset argument and hence the token is reset in the [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] method. From this point onwards you cannot use back button to traverse to the earlier form pages and successfully submit the form.

Pros and Cons - Token generation and checking support is built in by struts. Although the above approach is good, it requires application developer to add the token checking method pair – [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#saveToken(javax.servlet.http.HttpServletRequest) saveToken()] and [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html#isTokenValid(javax.servlet.http.HttpServletRequest) isTokenValid()] in methods rendering and submitting the sensitive forms respectively. Since the two tasks are generally performed by two different [http://struts.apache.org/1.x/apidocs/org/apache/struts/action/Action.html Action]s, the pairs need to be identified and added manually.

However there is another problem with this implementation. [http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/HttpSession.html HTTPSession] can be looked as a [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] which holds the key-value pair. No duplicate keys are allowed. Struts uses a fix key ([http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]) to store the token in the session. This means that at any time only one token can be stored in the session. This prohibits users from opening new windows and having multiple conversations at one time. Because as soon the new window is loaded, new token gets generated overwriting previous window's token in the session. So if the first form in submitted, server would not be able to process as the token in the session and in the request would not match. This is a serious limitation. In order to achieve multiple windows using the struts, developers are required to modify the struts implementation and instead of keeping token directly in the session, it would be stored in a separate [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] with key as window_id and value as token and this [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap] needs to be stored in the session with the key as [http://struts.apache.org/1.1/api/org/apache/struts/Globals.html#TRANSACTION_TOKEN_KEY Globals.TRANSACTION_TOKEN_KEY]. All the places where the session is accessed to retrieve the token are required to be modified and instead of token reading directly from session now it needs to read from the this inner [http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html HashMap]. This is not only tedious but extremely problematic because then you can not simply upgrade to newer versions of struts because you have customized it. Before adapting newer versions of struts, same modifications as explained above are required.

Next framework provides automatic support for generating and checking token thus developers do not have to worry about forming the pairs. Also it provides multiple windows feature as well.

==Spring Web Flow==
Spring Web Flow was specifically designed to help developers implement complex conversations in web applications. As a controller component in the MVC triad, Spring Web Flow integrates into hosting web MVC frameworks, serving as an application controller, handling screen navigation, and coordinating the flow of a business process.

Spring Web Flow captures business processes or conversations in modules called '''''flows'''''. A '''''flow''''' is a blueprint for the interaction a user can have with a web application; it reacts to user events to drive the process to completion. You can look at a flow as a simple manifestation of a finite state machine (FSM), consisting of a number of states that define the activities to execute while progressing through the flow. A state can allow a user to participate in the flow, or it can call business services. The flow can move from one state to another using transitions triggered by events. As a common practice business processes are defined using UML state diagrams, and Spring Web Flow flow definitions use a similar model. The following screenshot shows a Spring Web Flow flow definition that mirrors the process definition in Figure:
[[Image:spring_web_flow_process_definition.JPG|frame|center|alt=Spring Web Flow flow definition|Figure 1 ''[[Spring Web Flow flow definition]]''.]]
Given the navigational rules set out in a flow definition, Spring Web Flow automatically takes care of navigational control. Using web continuations, Spring Web Flow can guarantee stable, predictable behavior of a web application even when the user uses the browser’s Back, Forward, or Refresh buttons; revisits bookmarked pages; or opens multiple windows in the same conversation. The '''''POST-REDIRECT-GET''''' idiom will also be automatically applied, without any need for developer intervention.

Typically, a web flow will define a process spanning multiple requests into the web application. While completing the process, the user interacts with the application through several different pages, accumulating data along the way. It is the responsibility of a '''''flow execution repository''''' to maintain all data associated with a flow execution in between separate requests participating in that flow execution.

[[Image:flow_execution_repository.JPG|frame|left|alt= FlowExecutionRepository |Figure 2 ''[[FlowExecutionRepository Interface]]''.]] Spring Web Flow provides multiple types of repository implementations where the control flow behavior is predefined. Depending on the requirements developer can configure to use a particular implementation of a repository. All of these implementations implements [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface.
 
* Line 5: To adequately manage flow executions, a flow execution repository needs to assign a unique key to each flow execution. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#generateKey(org.springframework.webflow.execution.FlowExecution) generateKey(flowExecution)], a new [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] will be generated for a freshly launched flow execution. When an existing flow execution, with a key already assigned, needs to be persisted again, getNextKey(flowExecution, previousKey) generates the next key to use. This implies that a new key can be obtained every time a flow execution needs to be stored in a repository, allowing the repository to potentially change the key every time. [http://static.springsource.org/spring-webflow/docs/2.0.x/javadoc-api/org/springframework/webflow/execution/FlowExecutionKey.html FlowExecutionKey] objects can be marshaled into a string form using their toString() method. This string form will be embedded in HTML pages and later travels back to the server using the _flowExecutionKey request parameter. Using [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html#parseFlowExecutionKey(java.lang.String) parseFlowExecutionKey(encodedKey)], you can unmarshal a string form of a flow execution key back into its object form.
 
* Line 12: To make sure all access to a flow execution object occurs in an orderly fashion, a flow execution repository provides a [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/executor/jsf/FlowExecutionHolder.html FlowExecutionLock]. A flow execution needs to be locked before it is manipulated and unlocked afterward to ensure that all processing done by a flow execution is serialized: the next request is only processed when the previous one completed processing.
 
* Line 15: Finally, the [http://www.jarvana.com/jarvana/view/org/springframework/spring-webflow/1.0.5/spring-webflow-1.0.5-javadoc.jar!/org/springframework/webflow/execution/repository/FlowExecutionRepository.html FlowExecutionRepository] interface provides methods to store FlowExecution objects in the repository (putFlowExecution(key, flowExecution)), obtain them from the repository getFlowExecution(key)), or remove them from the repository (removeFlowExecution(key)). Before using any of these methods, the flow execution needs to be locked in the repository.
 
Figure 3 represents all the built in repository implementations provided by Spring Web Flows. An appropriate implementation can be chosen by using:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry" repository-type="simple"/>
</pre>

In above example simple repository will be used. When using classic Spring bean definitions instead of the Spring Web Flow configuration schema, set the repositoryType property to value SIMPLE:
<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="definitionLocator" ref="flowRegistry"/>
<property name="repositoryType" value="SIMPLE"/>
</bean>
</pre>

[[Image:flow_execution_repository_class_diagram.JPG|frame|center|alt= FlowExecutionRepository |Figure 3 ''[[FlowExecutionRepository Class Diagram]]''.]]

===Simple Repository===
[[Image:simple_repository.JPG|frame|right|alt= SimpleFlowExecutionRepository |Figure 4 ''[[Simple Repository]]''.]] The simplest FlowExecutionRepository implementation shipped with Spring Web Flow called [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/execution/repository/support/SimpleFlowExecutionRepository.html SimpleFlowExecutionRepository] manages a single snapshot of an ongoing flow execution, guarding access to the FlowExecution object using the flow execution key. Figure illustrates this algorithm.
This results in a situation very similar to the use of a synchronizer token. The simple repository guards access to the flow execution by changing the flow execution key for every request. In other words, the getNextKey(flowExecution, previousKey) method always returns a new key, different from the previous key. This ensures that a stale request, resulting from the user using the browser navigational aides (for instance, the Back button), can no longer access the flow execution. The end result is that use of the Back button or the browser history is completely disallowed. A user who tries to go back will receive an error stating that doing so is not allowed. The same is true, of course, when the conversation ends (because the flow reached an end state). At that point, Spring Web Flow will clean up all conversational state, preventing a user from resuming the terminated conversation or causing a double submits. Pros and Cons - The most important benefit of using the simple repository is that it only maintains a single copy of the FlowExecution data. These results in very low memory requirements, making this repository type ideal for environments where memory resources are scarce or load requirements are very high. As a downside, the simple repository does not support use of the browser Back button or navigation history and generates an exception if Back button usage is detected. This kind of strict no-Back-button policy enforcement is typically not suited for Internet facing applications. It can be ideal, however, in intranet settings, where you might be able to deploy a custom browser that can completely disable the browser navigational aids.
 

===Single Key Repository===
The single key repository is a variation on the simple repository. Essentially, the SimpleFlowExecutionRepository will be configured to keep the flow execution key constant for the entire flow execution. Instead of changing the flow execution key on every request, as done by the simple repository, the single key repository maintains a single key for every flow execution. As a result, the single key repository allows use of the Back button. It does not really support use of the Back button, however, since it maintains only a single snapshot of the flow execution (just like the simple repository).
When single key repository is used in combination with “always redirect on pause”, all pages of the flow will appear to have been served from exactly the same URL. The reason for this is the redirect Spring Web Flow issues before rendering a view. This redirect causes a flow execution refresh (that is, a flow execution redirect). Since the flow execution key remains constant for the entire flow execution when using the single key repository, all pages of the flow will appear to have been served from a URL like this:

<pre>
http://server/springbank/flows.html?_flowExecutionKey=ABCXYZ
</pre>

The cool thing here is that the browser will not notice that you are actually navigating from one page to another, because every page of the flow has exactly the same URL. The end result is that the browser does not build up a navigation history, making the Back button useless. If you click the Back button, you end up on the last page before the flow execution started!

Just like all other repository implementations, the single key repository will also remove a flow execution when it ends. This prevents a user from jumping back into a terminated conversation or causing a double submit.

Pros and Cons - Just like the simple repository, the single key repository has the important benefit of using very little memory (since it only stores a single flow execution snapshot). This makes it ideal for high-load or low-memory environments.
While the simple repository completely disallows use of the Back button, the single key repository tricks the browser into not accumulating any browsing history inside the flow execution. This makes going back in the flow using the Back button impossible. This compromise, unlike the strict rules enforced by the simple repository, is typically acceptable for Internet applications.

===The Continuation Repository===
[[Image:continuation_repository.JPG|frame|right|alt= ContinuationFlowExecutionRepository |Figure 5 ''[[Continuation Repository]]''.]] The most powerful flow execution repository provided by Spring Web Flow is the continuation repository, implemented by the [http://static.springsource.org/spring-webflow/docs/1.0.x/reference/flow-execution-repository.html ContinuationFlowExecutionRepository] class. As the name suggests, the continuation repository manages flow executions using a web continuations algorithm. Web continuations are an elegant way to deal with complex navigation in web applications. They allow web applications to respond correctly if the user uses the browser Back button or navigation history or even if the user opens multiple windows on a single conversation against which there is no built in mechanism provide by struts. '''Struts framework required modification in order to support multiple windows on a single conversion.''' The continuation repository will take a snapshot of the [http://static.springsource.org/spring-webflow/docs/pr5/api/org/springframework/webflow/execution/FlowExecution.html FlowExecution] object at the end of every request that comes into the flow execution. In other words, the “game” is saved at the end of every request. Each continuation snapshot has a unique ID, which is part of the flow execution key. When a request comes in, Spring Web Flow restores the flow execution from the identified continuation snapshot and continues processing. Figure 5 shows this graphically.

* The first request that comes into the flow executor does not contain a flow execution key. As a result, the flow executor launches a new flow execution for this simple three-state flow. The flow progresses from the first state to the second state, a view state, and pauses. Before control is returned to the browser, the flow execution repository takes a snapshot of the FlowExecution and assigns it a unique key. This key is embedded in the rendered view to make sure a next request can submit it again. At the end of the first request, the continuation repository contains a flow execution continuation snapshot, snapshot1, indexed by key1.
* The second request coming into the flow contains key1 as a flow execution key. In response to this request, the flow executor restores the flow execution from the identified continuation, snapshot1. The flow resumes processing, moves to the third state, and pauses. At this point, the flow execution repository takes another snapshot of the FlowExecution and assigns it a new unique key, which is embedded in the rendered view. The second request caused a second continuation snapshot, snapshot2, to be stored in the repository, indexed using key2. Notice that the first snapshot is still there. This allows the user to click the Back button, jumping back to the previous request (request two), and continue from that point onward. Opening a new browser window on the same conversation would allow the user to continue from the current snapshot (snapshot2) independently in each window.
* The third request continues from the continuation identified using key2. In this case, the flow resumes processing and terminates by reaching an end state. As a consequence, the flow execution, and all its continuation snapshots, will be removed from the repository. This prevents double submits, even when using web continuations: if the user clicks the Back button to go back to request two, an error will be produced because the identified continuation snapshot (snapshot2) is no longer available. It was cleaned up along with all other snapshots when the third request terminated the overall conversation. To be able to associate continuation snapshots with the governing logical conversation, Spring Web Flow needs to track both a continuation snapshot ID and the unique ID of the overall conversation. Both of these IDs are embedded in the flow execution key, which consists of two parts:
<pre>
flows.htm?_flowExecutionKey=_c<conversation id>_k<continuation id>
</pre>
* The conversation ID is prefixed using _c, followed by the continuation ID prefixed with _k. The conversation ID always remains constant throughout a conversation, while the continuation ID changes on every request.

The continuation repository is the default repository in Spring Web Flow. You can explicitly configure a flow executor to use the continuation repository by specifying continuation as repository type (or CONTINUATION when using the [http://static.springsource.org/spring-webflow/docs/1.0.5/api/org/springframework/webflow/config/FlowExecutorFactoryBean.html FlowExecutorFactoryBean]). The continuation repository has one additional property that can be configured: the maximum number of continuation snapshots allowed per conversation. Using a first-in-first-out algorithm, the oldest snapshot will be thrown away when a new one needs to be taken and the maximum has been reached. Here is a configuration example:

<pre>
<flow:executor id="flowExecutor" registry-ref="flowRegistry">
<flow:repository type="continuation" max-continuations="5"/>
</flow:executor>
</pre>

The same configuration using classic Spring bean definitions follows:

<pre>
<bean id="flowExecutor" class="org.springframework.webflow.config.FlowExecutorFactoryBean">
<property name="repositoryType" value="CONTINUATION"/>
<property name="maxContinuations" value="5"/>
</bean>
</pre>

By default, a maximum of 30 continuation snapshots per conversation are maintained. In practice, this is equivalent with an unlimited number of snapshots, since it allows a user to backtrack 30 steps in the browsing history—more than any normal user would ever do. Constraining the number of continuation snapshots is important to prevent an attacker from doing a [http://en.wikipedia.org/wiki/Denial-of-service_attack denial of service] attack by generating a large amount of snapshots.

Pros and Cons - The continuation repository allows you to have completely controlled navigation, while still allowing the user to use all of the browser navigational aides. This promise is a very compelling indeed and is the reason why this is the default repository used by Spring Web Flow.
The most important downside of the continuation repository is the increased memory usage caused by the multiple continuation snapshots that are potentially maintained for each flow execution. By appropriately configuring the maxContinuations property, you can control this, however, making the continuation repository ideal for most web applications.

===The Client Continuation Repository===
The last type of flow execution repository provided by Spring Web Flow is the client continuation repository, implemented by the ClientContinuationFlowExecutionRepository class. As the name suggests, the client continuation repository also uses a web-continuations–based approach to flow execution management, similar to the default continuation repository. The difference between the two is in where they store the continuation snapshots. The default continuation repository stores continuation snapshots on the server side, in the HTTP session (using the SessionBindingConversationManager). The client continuation repository stores the continuation snapshots on the client side, avoiding use of any server-side state. To make this possible, the client continuation repository encodes the entire continuation snapshot inside the flow execution key. Here is an example of a hidden field in an HTML form, containing a flow execution key generated by the client continuation repository:

<pre>
<input type="hidden" name="_flowExecutionKey"
value="_cNoOpConversation id_krO0ABXNyAGFvcmcuc3ByaW5nZnJhbWV3b3JrL \
ndlYmZsb3cuZXhlY3V0aW9uLnJlcG9zaXRvcnkuY29udGludWF0aW9uLlNlcmlhbGl6 \
lvbi5GbG93RXhlY3V0aW9uQ29udGludWF0aW9ujvgpwtO1430CAAB4cHoAAAQAAAAM- \
...
L3VDqmZZMURBDF7-I73_3g1IND_5AqBLBJQ14z4tUZQRPZFvz_gzBNwW37Z9uff3bRv \
V1SH-1h7xERqN7--u0Td_Y_VVNH6uJkmYYGLgpLzRWn1XHSxuS5tbgYniCt6hNPkGG3 \
OxFhQME1Wdb1B0jLVgMeee364-3eNtM_MW9xgp9c3n8v4NL2FNyjEbHcNZxcvqBbj8i \
7lZtyOSeXy_0XxBYpbwUkAAABeA.."/>
</pre>

The continuation ID is a base-64–encoded, GZIP-compressed form of the serialized FlowExecution object.

Pros and Cons - The client continuation repository is a remarkable specimen. It has the major advantage of not requiring any server-side state. This has important benefits in terms of scalability, failover, and application and server management. Additionally, since this repository uses web continuations, it has complete support for use of the browser’s Back button. There is a high cost to pay however:
* By default, the client continuation repository does not use a real conversation manager. As a consequence, it cannot properly prevent double submits and does not support the conversation scope. These issues can be resolved, however, by plugging in a real ConversationManager.
* Because of the long flow execution key, applications are limited to using POST requests. This also rules out applying the POST-REDIRECT-GET idiom using “always redirect on pause”.
* Exchanging a relatively large flow execution key between the client and server on every request consumes quite a bit of bandwidth, potentially making the application slower for users on slow connections.
* Storing state on the client has security implications. An attacker could try to reverse engineer the continuation snapshot, extracting sensitive data or manipulating certain data structures. The ClientContinuationFlowExecutionRepository was designed for extensibility, however, allowing you to plug in continuation snapshot encryption. The client continuation repository provided by Spring Web Flow is an interesting experiment. Future versions of Spring Web Flow will certainly investigate this idea in more depth, for instance, in trying to manage conversations using state stored in client-side cookies. For now, make sure you understand the consequences of using the client continuation repository before deciding to use it.

===Selecting a Repository===
The matrix shown in Figure makes it easy to pick the correct repository depending on whether or not you need to support browser Back button usage and on the memory constraints of the deployment environment.
[[Image:repository_selection.JPG|frame|center|alt=Repository Selection |Figure 6 ''[[Selecting Repository]]''.]]
In general, though, most applications are best served using the continuation repository. Since this is the default repository in Spring Web Flow, you don’t need to configure anything. Only select a different repository type if you have real requirements or constraints that force you away from the default repository. So unlike struts the complete token management and checking is done automatically without developer having to worry about pairing issues.

=References=

 

[1] [http://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html Synchronizer Token using Struts]

[2] [http://www.java-samples.com/showtutorial.php?tutorialid=582 Struts implementation of Synchronizer Token]

[3] [http://www.amazon.com/Definitive-Guide-Spring-Web-Flow/dp/1430216247 Spring Web Flow]

CSC/ECE 517 Fall 2009/wiki1b 12 testFrmwk

2009-09-29T13:53:29Z

Rvenkat: /* References */

The intent of this document is to list the popular testing frameworks for popular Object Oriented languages.

=What is a testing framework?=

Wikipedia defines a framework as "A basic conceptual structure used to solve a complex issue. Conceptually we can consider testing frameworks as a guidance, infrastructure, tool to facilitate testing. Below is a comprehensive list of popular testing frameworks for popular Object Oriented languages.

=Testing frameworks for object-oriented languages=

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is a very popular object oriented language. It is statically typed, free form and multi-paradigm programming language. The development of C++ began as an enhancement for C.

[http://aeryn.tigris.org/ Aeryn] - Aeryn is a C++ testing framework. It is primarily intended for unit testing. It is adaptable enough to handle integration testing and can be used for other forms of C++ testing.

[http://www.netbsd.org/~jmmv/atf/ ATF] : It was developed as a part of Google Summer of code 2007. It is a collection of libraries and utilities designed to ease unattended application testing in the hands of developers and end users of a specific piece of software.

[http://www.ipl.com/products/tools/pt400.uk.php Cantata++] : It provides ability to modify calls from software under test. It is a commercial tool.

[http://www.cfix-testing.org/unit-testing-framework/windows/ Cfix] : It is a unit testing framework for both C and C++. It is specialized for unmanaged Windows development. It supports the development of both user and kernel mode unit tests.

[http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page CppUnit] : It is unit testing framework. It started as a port of JUnit to C++.

[http://r2.ifs.hsr.ch/cute CUTE] : It is an eclipse plug-in for C++ unit testing.

[http://fctest.wildbearsoftware.com/ FCTest] : It is a lightweight, cross platform, framework for quickly generating x-unit tests in C/C++. The entire framework is available as a single header file.

[http://tut-framework.sourceforge.net/ TUT] : It is a small and portable unit test framework for C++. The inputs to it are based on templaets

[http://unittest-cpp.sourceforge.net/ UnitTest++]: It is a light weight unit testing framework for C++. It makes minimal use of advanced library and language features.

[http://www.visualassert.com/unit-testing-framework/ Visual Assert]: It is a visual studio plug-in. It is based on cfix testing framework.

==C#==
[http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#] is a object oriented language that has a syntax that is similar to C and C++. C# is a part of the .NET framework and it is compiled to Microsoft Intermediate Language(MSIL) which is similar to java byte code. MSIL allows C# to be platform independent.

[http://www.nunit.org/index.php NUnit] – NUnit is an opensource testing framework. It is ported from JUnit. NUnit brings XUnit to all .NET languages.

[http://research.microsoft.com/en-us/projects/Pex/ PEX] – It is an automated white box testing tool for .NET.

[http://www.csunit.org/ csUnit] – It is an open source testing tool for the .NET framework.

[http://msdn.microsoft.com/en-us/library/ms182469(VS.80).aspx MSTest] – MSTest is a unit testing framework that is developed by
Microsoft which is integrated Microsoft Visual Studio. It has a design that is similar to NUnit.

[http://code.google.com/p/mb-unit/ MbUnit]– provides advanced unit testing support with advanced fixtures. It is an extensible unit testing framework for .NET Framework that taken in and goes beyond xUnit pattern testing.

==Groovy==
[http://en.wikipedia.org/wiki/Groovy_(programming_language) Groovy] is a dynamic language built to run on Java Virtual machine. This language has additional features that are inspired by languages like python, Ruby and smalltalk. Groovy simplifies testing by providing unit test (using JUnit) and mock frameworks as part of the built in features.

[http://code.google.com/p/testngroove Test'N'Groove] - 'Test and Groove' framework is the integration of Groovy and TestNG frameworks.

[http://groovy.codehaus.org/Groovy+Mocks Groovy Mocks] - This framework is built in with Groovy and provides excellent support for mocking alternatives while testing Groovy code

[http://gmock.org Gmock] - This is a mocking framework for Groovy. Simple syntax of this framework makes it popular as it makes the tests more readable and concise

[http://www.easyb.org easyb] - This is a behavior driven development framework that can be used to test Groovy

[http://code.google.com/p/spock spock] - Spock is a testing and specification framework for Groovy applications also. This is popular as it has highly expressive specification language and it combines the best features of other tools like JUnit, jMock, and RSPec

==Java==
[http://en.wikipedia.org/wiki/Java_(software_platform) Java] is an object oriented language that derives most of its syntax from C and C++. It has a much simpler object oriented model when compared to C and C++. Java applications are compiled into byte codes and the byte code can be run on any JVM regardless of the underlying architecture.

[http://junit.sourceforge.net JUnit] – It is the most oldest and most popular java testing frameworks available, JUnit has become the de facto standard for unit testing.

[http://jtiger.org/ JTiger] - It is a JDK 1.5 annotation based testing framework that leverages many of the new features that JDK 1.5 introduced.

[http://testng.org/doc/download.html TestNG] – It is a combination of JUnit and NUnit but it also includes several new features that make it easier to use.

[http://jakarta.apache.org/cactus/downloads.html CACTUS] – It is a simple test framework for unit testing server side java cod

==LISP==

[http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] is one of oldest and a multi-paradigm, reflective programming language. The name is said to be derived from "List Processing" as the language features linked list as a major data structure. The language also features dynamic typing and functional programming support.

[http://www.ancar.org/CLUnit/docs/CLUnit.html CLUnit] is a unit test tool for defining and running unit tests for common LISP language

[http://common-lisp.net/project/lift LIFT] is another framework for testing LISP based applications. LIFT supports interactive testing and is inspired by SUnit and JUnit.

[http://www.cs.northwestern.edu/academics/courses/325/readings/lisp-unit.html LISPUnit] is a popular framework designed for beginners of LISP programming and has common LISP library that supports unit testing

[http://common-lisp.net/project/bese/FiveAM.html FiveAM] is a unit testing framework similar to LISP and does hierarchical, composable test suites

[http://common-lisp.net/project/stefil Stefil] features a more interactive approach to testing as it provides report on test failures and the conditions that caused the failure

==Objective C==

[http://en.wikipedia.org/wiki/Objective_c Objective C] is designed to provide C language , the full object oriented programming capabilities based on Smalltalk style messaging.

[http://sente.epfl.ch/software/ocunit OCUnit] is a XUnit style testing framework for testing Objective C language based applications.

[http://oops.se/objcunit ObjcUnit] is another testing framework based on JUnit, adapted for Objective C

[http://wincent.com/a/products/wotest WOTest] is an unit testing framework for Objective C which integrates fully with XCode

==PHP==

[http://en.wikipedia.org/wiki/Php PHP] is a general purpose scripting language which is widely used for web development

[http://phpunit.sourceforge.net PHPUnit] is a unit testing framework for PHP programming language based on JUnit framework

[http://www.simpletest.org SimpleTest] is an unit testing framework for PHP programming language and it supports mock objects which is used to regress the web-applications. This framework is based on JUnit/PHPUnit

[http://code.google.com/p/snaptest SnapTest] is a unit testing framework compliant with JUnit type of test harness and also provides test output that is complaint with TAP

==Python==
[http://en.wikipedia.org/wiki/Python_(programming_language) Python] is a general purpose high level programming language. It supports multiple programming paradigms. It is often used as a scripting language.

[http://www.python.org/doc/current/library/unittest.html PyUnit] – It is the standard unit testing framework module for python. It is the pythons version of JUnit. It is a part of the pythons standard library.

[http://docs.python.org/library/doctest.html Doctest] - It is a module included in Pthons programming language standard library that allows the easy generation of tests based on output from the standard Python interpreter shell.

[http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ Nose] - It is a unit test based testing framework for python that makes writing and running tests easier. It provides an alternate test discovery and running process for unit test.
Py.test – py.test is a command line tool to collect and run automated tests. It is a distributed testing tool.

==PERL==
[http://en.wikipedia.org/wiki/Perl Perl] is a high-level, general-purpose, interpreted, dynamic programming language well known for its text processing capabilities. Perl is inspired by AWK, Smalltalk, LISP, C, C++, Unix Shell etc.

[http://search.cpan.org/perldoc/TAP TAP] - TAP stands for Test Anything Protocol. This is used to allow communication between unit tests and any automated testing framework

[http://search.cpan.org/perldoc/Test::Harness Test::Harness] - This is a standard test runner for PERL which leverages TAP parser for running various tests

[http://search.cpan.org/perldoc/Test::More Test::More] - Another testing framework that is famous for the testing utilities

[http://search.cpan.org/perldoc/Test::Class Test::Class] - This framework provides a simple way to create classes and objects for testing in the xUnit/JUnit Style

[http://search.cpan.org/perldoc/Test::Builder Test::Builder] - A module for making more testing modules

[http://search.cpan.org/perldoc/Test::Unit Test::Unit] (a.k.a. [http://perlunit.sourceforge.net/ PerlUnit]) - This framework supports unit testing in an object oriented development paradigm. This is derived from JUnit

[http://search.cpan.org/perldoc/Test::DBUnit Test::DBUnit] - Another xUnit based testing framework for testing database modules

[http://search.cpan.org/perldoc/Test::Able Test::Able] - This is an xUnit style testing framework inspired by Test::Class with

[http://search.cpan.org/perldoc/Moose Moose] . This framework was created to overcome the limitations of Test::Class and leverage the functions of Moose.

[http://www.c2.com/cgi/wiki?LectroTest LectroTest] - This is an automatic, specification-based testing tool for Perl. It is modeled after the QuickCheck module for the Haskell programming language.

[http://www.c2.com/cgi/wiki?PerlActor PerlActor] - This is a simple automated executable acceptance test framework for Perl

http://langworth.com/pub/perl_test_refcard.pdf - List of testing modules for PERL

==Ruby==
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is a dynamic, reflective objected oriented language. It has the syntax that was inspired by Perl and Small talk. It supports multiple programming paradigm. It is a single pass interpreted language.

[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit] - It is a ruby unit testing framework.

[http://rspec.info/ RSpec] – It is a behavior driven development framework for Ruby Programming language. It is inspired by JBehave

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] - It is a tool that can execute plain-text functional descriptions as automated tests.

==Scala==
[http://en.wikipedia.org/wiki/Scala_(programming_language) Scala] stands for "Scalable Language". Scala is a programming language that is designed to integrate the features of Object-orient programming and functional programming. Scala runs on JVM and is compatible with existing java programs.

[http://www.artima.com/scalatest/ ScalaTest] - is a traditional xUnit style testing framework

[http://code.google.com/p/scalacheck/ ScalaCheck], a library similar to Haskell's QuickCheck and is used for automated unit testing of Scala based application

[http://code.google.com/p/specs/ Specs] is a Behavior driven development library for Scala

[http://rehersal.sourceforge.net/ Rehersal] is another unit testing framework for Scala intended as an easier-to-use replacement for SUnit in the standard library

[http://code.google.com/p/scunit/ ScUnit] is an unit testing framework based on several Java testing and mocking frameworks like JUnit, TestNG,JBehave, EasyMock

==Smalltalk==
[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is an object oriented, dynamically typed language and is often considered as a pioneer for many other object oriented languages like Java, Python, Ruby etc.

[http://en.wikipedia.org/wiki/SUnit SUnit] - Unit Testing framework for Smalltalk. It is the original source of the xUnit desig

=References=

Below are the references for the terms that are used in this document.

http://en.wikipedia.org/wiki/Multi-paradigm_programming_language#Multi-paradigm_programming_language

http://en.wikipedia.org/wiki/Functional_programming

http://en.wikipedia.org/wiki/Procedural_programming

http://en.wikipedia.org/wiki/Reflection_(computer_science)

http://en.wikipedia.org/wiki/Metaprogramming

http://en.wikipedia.org/wiki/Object-oriented_programming

==Resources==

Below are the resources that would help the reader to jump start on the object oriented languages that are listed in this document

http://www.cplusplus.com/doc/tutorial

http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx

http://groovy.codehaus.org/Documentation

http://java.sun.com/new2java

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html

http://us2.php.net/tut.php

http://www.python.org/doc

http://www.perl.org/docs.html

http://www.ruby-lang.org/en/documentation

http://www.scala-lang.org/node/197

CSC/ECE 517 Fall 2009/wiki1b 12 testFrmwk

2009-09-29T13:53:09Z

Rvenkat: /* Resources */

The intent of this document is to list the popular testing frameworks for popular Object Oriented languages.

=What is a testing framework?=

Wikipedia defines a framework as "A basic conceptual structure used to solve a complex issue. Conceptually we can consider testing frameworks as a guidance, infrastructure, tool to facilitate testing. Below is a comprehensive list of popular testing frameworks for popular Object Oriented languages.

=Testing frameworks for object-oriented languages=

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is a very popular object oriented language. It is statically typed, free form and multi-paradigm programming language. The development of C++ began as an enhancement for C.

[http://aeryn.tigris.org/ Aeryn] - Aeryn is a C++ testing framework. It is primarily intended for unit testing. It is adaptable enough to handle integration testing and can be used for other forms of C++ testing.

[http://www.netbsd.org/~jmmv/atf/ ATF] : It was developed as a part of Google Summer of code 2007. It is a collection of libraries and utilities designed to ease unattended application testing in the hands of developers and end users of a specific piece of software.

[http://www.ipl.com/products/tools/pt400.uk.php Cantata++] : It provides ability to modify calls from software under test. It is a commercial tool.

[http://www.cfix-testing.org/unit-testing-framework/windows/ Cfix] : It is a unit testing framework for both C and C++. It is specialized for unmanaged Windows development. It supports the development of both user and kernel mode unit tests.

[http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page CppUnit] : It is unit testing framework. It started as a port of JUnit to C++.

[http://r2.ifs.hsr.ch/cute CUTE] : It is an eclipse plug-in for C++ unit testing.

[http://fctest.wildbearsoftware.com/ FCTest] : It is a lightweight, cross platform, framework for quickly generating x-unit tests in C/C++. The entire framework is available as a single header file.

[http://tut-framework.sourceforge.net/ TUT] : It is a small and portable unit test framework for C++. The inputs to it are based on templaets

[http://unittest-cpp.sourceforge.net/ UnitTest++]: It is a light weight unit testing framework for C++. It makes minimal use of advanced library and language features.

[http://www.visualassert.com/unit-testing-framework/ Visual Assert]: It is a visual studio plug-in. It is based on cfix testing framework.

==C#==
[http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#] is a object oriented language that has a syntax that is similar to C and C++. C# is a part of the .NET framework and it is compiled to Microsoft Intermediate Language(MSIL) which is similar to java byte code. MSIL allows C# to be platform independent.

[http://www.nunit.org/index.php NUnit] – NUnit is an opensource testing framework. It is ported from JUnit. NUnit brings XUnit to all .NET languages.

[http://research.microsoft.com/en-us/projects/Pex/ PEX] – It is an automated white box testing tool for .NET.

[http://www.csunit.org/ csUnit] – It is an open source testing tool for the .NET framework.

[http://msdn.microsoft.com/en-us/library/ms182469(VS.80).aspx MSTest] – MSTest is a unit testing framework that is developed by
Microsoft which is integrated Microsoft Visual Studio. It has a design that is similar to NUnit.

[http://code.google.com/p/mb-unit/ MbUnit]– provides advanced unit testing support with advanced fixtures. It is an extensible unit testing framework for .NET Framework that taken in and goes beyond xUnit pattern testing.

==Groovy==
[http://en.wikipedia.org/wiki/Groovy_(programming_language) Groovy] is a dynamic language built to run on Java Virtual machine. This language has additional features that are inspired by languages like python, Ruby and smalltalk. Groovy simplifies testing by providing unit test (using JUnit) and mock frameworks as part of the built in features.

[http://code.google.com/p/testngroove Test'N'Groove] - 'Test and Groove' framework is the integration of Groovy and TestNG frameworks.

[http://groovy.codehaus.org/Groovy+Mocks Groovy Mocks] - This framework is built in with Groovy and provides excellent support for mocking alternatives while testing Groovy code

[http://gmock.org Gmock] - This is a mocking framework for Groovy. Simple syntax of this framework makes it popular as it makes the tests more readable and concise

[http://www.easyb.org easyb] - This is a behavior driven development framework that can be used to test Groovy

[http://code.google.com/p/spock spock] - Spock is a testing and specification framework for Groovy applications also. This is popular as it has highly expressive specification language and it combines the best features of other tools like JUnit, jMock, and RSPec

==Java==
[http://en.wikipedia.org/wiki/Java_(software_platform) Java] is an object oriented language that derives most of its syntax from C and C++. It has a much simpler object oriented model when compared to C and C++. Java applications are compiled into byte codes and the byte code can be run on any JVM regardless of the underlying architecture.

[http://junit.sourceforge.net JUnit] – It is the most oldest and most popular java testing frameworks available, JUnit has become the de facto standard for unit testing.

[http://jtiger.org/ JTiger] - It is a JDK 1.5 annotation based testing framework that leverages many of the new features that JDK 1.5 introduced.

[http://testng.org/doc/download.html TestNG] – It is a combination of JUnit and NUnit but it also includes several new features that make it easier to use.

[http://jakarta.apache.org/cactus/downloads.html CACTUS] – It is a simple test framework for unit testing server side java cod

==LISP==

[http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] is one of oldest and a multi-paradigm, reflective programming language. The name is said to be derived from "List Processing" as the language features linked list as a major data structure. The language also features dynamic typing and functional programming support.

[http://www.ancar.org/CLUnit/docs/CLUnit.html CLUnit] is a unit test tool for defining and running unit tests for common LISP language

[http://common-lisp.net/project/lift LIFT] is another framework for testing LISP based applications. LIFT supports interactive testing and is inspired by SUnit and JUnit.

[http://www.cs.northwestern.edu/academics/courses/325/readings/lisp-unit.html LISPUnit] is a popular framework designed for beginners of LISP programming and has common LISP library that supports unit testing

[http://common-lisp.net/project/bese/FiveAM.html FiveAM] is a unit testing framework similar to LISP and does hierarchical, composable test suites

[http://common-lisp.net/project/stefil Stefil] features a more interactive approach to testing as it provides report on test failures and the conditions that caused the failure

==Objective C==

[http://en.wikipedia.org/wiki/Objective_c Objective C] is designed to provide C language , the full object oriented programming capabilities based on Smalltalk style messaging.

[http://sente.epfl.ch/software/ocunit OCUnit] is a XUnit style testing framework for testing Objective C language based applications.

[http://oops.se/objcunit ObjcUnit] is another testing framework based on JUnit, adapted for Objective C

[http://wincent.com/a/products/wotest WOTest] is an unit testing framework for Objective C which integrates fully with XCode

==PHP==

[http://en.wikipedia.org/wiki/Php PHP] is a general purpose scripting language which is widely used for web development

[http://phpunit.sourceforge.net PHPUnit] is a unit testing framework for PHP programming language based on JUnit framework

[http://www.simpletest.org SimpleTest] is an unit testing framework for PHP programming language and it supports mock objects which is used to regress the web-applications. This framework is based on JUnit/PHPUnit

[http://code.google.com/p/snaptest SnapTest] is a unit testing framework compliant with JUnit type of test harness and also provides test output that is complaint with TAP

==Python==
[http://en.wikipedia.org/wiki/Python_(programming_language) Python] is a general purpose high level programming language. It supports multiple programming paradigms. It is often used as a scripting language.

[http://www.python.org/doc/current/library/unittest.html PyUnit] – It is the standard unit testing framework module for python. It is the pythons version of JUnit. It is a part of the pythons standard library.

[http://docs.python.org/library/doctest.html Doctest] - It is a module included in Pthons programming language standard library that allows the easy generation of tests based on output from the standard Python interpreter shell.

[http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ Nose] - It is a unit test based testing framework for python that makes writing and running tests easier. It provides an alternate test discovery and running process for unit test.
Py.test – py.test is a command line tool to collect and run automated tests. It is a distributed testing tool.

==PERL==
[http://en.wikipedia.org/wiki/Perl Perl] is a high-level, general-purpose, interpreted, dynamic programming language well known for its text processing capabilities. Perl is inspired by AWK, Smalltalk, LISP, C, C++, Unix Shell etc.

[http://search.cpan.org/perldoc/TAP TAP] - TAP stands for Test Anything Protocol. This is used to allow communication between unit tests and any automated testing framework

[http://search.cpan.org/perldoc/Test::Harness Test::Harness] - This is a standard test runner for PERL which leverages TAP parser for running various tests

[http://search.cpan.org/perldoc/Test::More Test::More] - Another testing framework that is famous for the testing utilities

[http://search.cpan.org/perldoc/Test::Class Test::Class] - This framework provides a simple way to create classes and objects for testing in the xUnit/JUnit Style

[http://search.cpan.org/perldoc/Test::Builder Test::Builder] - A module for making more testing modules

[http://search.cpan.org/perldoc/Test::Unit Test::Unit] (a.k.a. [http://perlunit.sourceforge.net/ PerlUnit]) - This framework supports unit testing in an object oriented development paradigm. This is derived from JUnit

[http://search.cpan.org/perldoc/Test::DBUnit Test::DBUnit] - Another xUnit based testing framework for testing database modules

[http://search.cpan.org/perldoc/Test::Able Test::Able] - This is an xUnit style testing framework inspired by Test::Class with

[http://search.cpan.org/perldoc/Moose Moose] . This framework was created to overcome the limitations of Test::Class and leverage the functions of Moose.

[http://www.c2.com/cgi/wiki?LectroTest LectroTest] - This is an automatic, specification-based testing tool for Perl. It is modeled after the QuickCheck module for the Haskell programming language.

[http://www.c2.com/cgi/wiki?PerlActor PerlActor] - This is a simple automated executable acceptance test framework for Perl

http://langworth.com/pub/perl_test_refcard.pdf - List of testing modules for PERL

==Ruby==
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is a dynamic, reflective objected oriented language. It has the syntax that was inspired by Perl and Small talk. It supports multiple programming paradigm. It is a single pass interpreted language.

[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit] - It is a ruby unit testing framework.

[http://rspec.info/ RSpec] – It is a behavior driven development framework for Ruby Programming language. It is inspired by JBehave

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] - It is a tool that can execute plain-text functional descriptions as automated tests.

==Scala==
[http://en.wikipedia.org/wiki/Scala_(programming_language) Scala] stands for "Scalable Language". Scala is a programming language that is designed to integrate the features of Object-orient programming and functional programming. Scala runs on JVM and is compatible with existing java programs.

[http://www.artima.com/scalatest/ ScalaTest] - is a traditional xUnit style testing framework

[http://code.google.com/p/scalacheck/ ScalaCheck], a library similar to Haskell's QuickCheck and is used for automated unit testing of Scala based application

[http://code.google.com/p/specs/ Specs] is a Behavior driven development library for Scala

[http://rehersal.sourceforge.net/ Rehersal] is another unit testing framework for Scala intended as an easier-to-use replacement for SUnit in the standard library

[http://code.google.com/p/scunit/ ScUnit] is an unit testing framework based on several Java testing and mocking frameworks like JUnit, TestNG,JBehave, EasyMock

==Smalltalk==
[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is an object oriented, dynamically typed language and is often considered as a pioneer for many other object oriented languages like Java, Python, Ruby etc.

[http://en.wikipedia.org/wiki/SUnit SUnit] - Unit Testing framework for Smalltalk. It is the original source of the xUnit desig

=References=

Below are the references for the terms that are used in this document.

http://en.wikipedia.org/wiki/Multi-paradigm_programming_language#Multi-paradigm_programming_language
http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/Procedural_programming
http://en.wikipedia.org/wiki/Reflection_(computer_science)
http://en.wikipedia.org/wiki/Metaprogramming
http://en.wikipedia.org/wiki/Object-oriented_programming

==Resources==

Below are the resources that would help the reader to jump start on the object oriented languages that are listed in this document

http://www.cplusplus.com/doc/tutorial

http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx

http://groovy.codehaus.org/Documentation

http://java.sun.com/new2java

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html

http://us2.php.net/tut.php

http://www.python.org/doc

http://www.perl.org/docs.html

http://www.ruby-lang.org/en/documentation

http://www.scala-lang.org/node/197

CSC/ECE 517 Fall 2009/wiki1b 12 testFrmwk

2009-09-29T13:52:21Z

Rvenkat: /* External References */

The intent of this document is to list the popular testing frameworks for popular Object Oriented languages.

=What is a testing framework?=

Wikipedia defines a framework as "A basic conceptual structure used to solve a complex issue. Conceptually we can consider testing frameworks as a guidance, infrastructure, tool to facilitate testing. Below is a comprehensive list of popular testing frameworks for popular Object Oriented languages.

=Testing frameworks for object-oriented languages=

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is a very popular object oriented language. It is statically typed, free form and multi-paradigm programming language. The development of C++ began as an enhancement for C.

[http://aeryn.tigris.org/ Aeryn] - Aeryn is a C++ testing framework. It is primarily intended for unit testing. It is adaptable enough to handle integration testing and can be used for other forms of C++ testing.

[http://www.netbsd.org/~jmmv/atf/ ATF] : It was developed as a part of Google Summer of code 2007. It is a collection of libraries and utilities designed to ease unattended application testing in the hands of developers and end users of a specific piece of software.

[http://www.ipl.com/products/tools/pt400.uk.php Cantata++] : It provides ability to modify calls from software under test. It is a commercial tool.

[http://www.cfix-testing.org/unit-testing-framework/windows/ Cfix] : It is a unit testing framework for both C and C++. It is specialized for unmanaged Windows development. It supports the development of both user and kernel mode unit tests.

[http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page CppUnit] : It is unit testing framework. It started as a port of JUnit to C++.

[http://r2.ifs.hsr.ch/cute CUTE] : It is an eclipse plug-in for C++ unit testing.

[http://fctest.wildbearsoftware.com/ FCTest] : It is a lightweight, cross platform, framework for quickly generating x-unit tests in C/C++. The entire framework is available as a single header file.

[http://tut-framework.sourceforge.net/ TUT] : It is a small and portable unit test framework for C++. The inputs to it are based on templaets

[http://unittest-cpp.sourceforge.net/ UnitTest++]: It is a light weight unit testing framework for C++. It makes minimal use of advanced library and language features.

[http://www.visualassert.com/unit-testing-framework/ Visual Assert]: It is a visual studio plug-in. It is based on cfix testing framework.

==C#==
[http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#] is a object oriented language that has a syntax that is similar to C and C++. C# is a part of the .NET framework and it is compiled to Microsoft Intermediate Language(MSIL) which is similar to java byte code. MSIL allows C# to be platform independent.

[http://www.nunit.org/index.php NUnit] – NUnit is an opensource testing framework. It is ported from JUnit. NUnit brings XUnit to all .NET languages.

[http://research.microsoft.com/en-us/projects/Pex/ PEX] – It is an automated white box testing tool for .NET.

[http://www.csunit.org/ csUnit] – It is an open source testing tool for the .NET framework.

[http://msdn.microsoft.com/en-us/library/ms182469(VS.80).aspx MSTest] – MSTest is a unit testing framework that is developed by
Microsoft which is integrated Microsoft Visual Studio. It has a design that is similar to NUnit.

[http://code.google.com/p/mb-unit/ MbUnit]– provides advanced unit testing support with advanced fixtures. It is an extensible unit testing framework for .NET Framework that taken in and goes beyond xUnit pattern testing.

==Groovy==
[http://en.wikipedia.org/wiki/Groovy_(programming_language) Groovy] is a dynamic language built to run on Java Virtual machine. This language has additional features that are inspired by languages like python, Ruby and smalltalk. Groovy simplifies testing by providing unit test (using JUnit) and mock frameworks as part of the built in features.

[http://code.google.com/p/testngroove Test'N'Groove] - 'Test and Groove' framework is the integration of Groovy and TestNG frameworks.

[http://groovy.codehaus.org/Groovy+Mocks Groovy Mocks] - This framework is built in with Groovy and provides excellent support for mocking alternatives while testing Groovy code

[http://gmock.org Gmock] - This is a mocking framework for Groovy. Simple syntax of this framework makes it popular as it makes the tests more readable and concise

[http://www.easyb.org easyb] - This is a behavior driven development framework that can be used to test Groovy

[http://code.google.com/p/spock spock] - Spock is a testing and specification framework for Groovy applications also. This is popular as it has highly expressive specification language and it combines the best features of other tools like JUnit, jMock, and RSPec

==Java==
[http://en.wikipedia.org/wiki/Java_(software_platform) Java] is an object oriented language that derives most of its syntax from C and C++. It has a much simpler object oriented model when compared to C and C++. Java applications are compiled into byte codes and the byte code can be run on any JVM regardless of the underlying architecture.

[http://junit.sourceforge.net JUnit] – It is the most oldest and most popular java testing frameworks available, JUnit has become the de facto standard for unit testing.

[http://jtiger.org/ JTiger] - It is a JDK 1.5 annotation based testing framework that leverages many of the new features that JDK 1.5 introduced.

[http://testng.org/doc/download.html TestNG] – It is a combination of JUnit and NUnit but it also includes several new features that make it easier to use.

[http://jakarta.apache.org/cactus/downloads.html CACTUS] – It is a simple test framework for unit testing server side java cod

==LISP==

[http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] is one of oldest and a multi-paradigm, reflective programming language. The name is said to be derived from "List Processing" as the language features linked list as a major data structure. The language also features dynamic typing and functional programming support.

[http://www.ancar.org/CLUnit/docs/CLUnit.html CLUnit] is a unit test tool for defining and running unit tests for common LISP language

[http://common-lisp.net/project/lift LIFT] is another framework for testing LISP based applications. LIFT supports interactive testing and is inspired by SUnit and JUnit.

[http://www.cs.northwestern.edu/academics/courses/325/readings/lisp-unit.html LISPUnit] is a popular framework designed for beginners of LISP programming and has common LISP library that supports unit testing

[http://common-lisp.net/project/bese/FiveAM.html FiveAM] is a unit testing framework similar to LISP and does hierarchical, composable test suites

[http://common-lisp.net/project/stefil Stefil] features a more interactive approach to testing as it provides report on test failures and the conditions that caused the failure

==Objective C==

[http://en.wikipedia.org/wiki/Objective_c Objective C] is designed to provide C language , the full object oriented programming capabilities based on Smalltalk style messaging.

[http://sente.epfl.ch/software/ocunit OCUnit] is a XUnit style testing framework for testing Objective C language based applications.

[http://oops.se/objcunit ObjcUnit] is another testing framework based on JUnit, adapted for Objective C

[http://wincent.com/a/products/wotest WOTest] is an unit testing framework for Objective C which integrates fully with XCode

==PHP==

[http://en.wikipedia.org/wiki/Php PHP] is a general purpose scripting language which is widely used for web development

[http://phpunit.sourceforge.net PHPUnit] is a unit testing framework for PHP programming language based on JUnit framework

[http://www.simpletest.org SimpleTest] is an unit testing framework for PHP programming language and it supports mock objects which is used to regress the web-applications. This framework is based on JUnit/PHPUnit

[http://code.google.com/p/snaptest SnapTest] is a unit testing framework compliant with JUnit type of test harness and also provides test output that is complaint with TAP

==Python==
[http://en.wikipedia.org/wiki/Python_(programming_language) Python] is a general purpose high level programming language. It supports multiple programming paradigms. It is often used as a scripting language.

[http://www.python.org/doc/current/library/unittest.html PyUnit] – It is the standard unit testing framework module for python. It is the pythons version of JUnit. It is a part of the pythons standard library.

[http://docs.python.org/library/doctest.html Doctest] - It is a module included in Pthons programming language standard library that allows the easy generation of tests based on output from the standard Python interpreter shell.

[http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ Nose] - It is a unit test based testing framework for python that makes writing and running tests easier. It provides an alternate test discovery and running process for unit test.
Py.test – py.test is a command line tool to collect and run automated tests. It is a distributed testing tool.

==PERL==
[http://en.wikipedia.org/wiki/Perl Perl] is a high-level, general-purpose, interpreted, dynamic programming language well known for its text processing capabilities. Perl is inspired by AWK, Smalltalk, LISP, C, C++, Unix Shell etc.

[http://search.cpan.org/perldoc/TAP TAP] - TAP stands for Test Anything Protocol. This is used to allow communication between unit tests and any automated testing framework

[http://search.cpan.org/perldoc/Test::Harness Test::Harness] - This is a standard test runner for PERL which leverages TAP parser for running various tests

[http://search.cpan.org/perldoc/Test::More Test::More] - Another testing framework that is famous for the testing utilities

[http://search.cpan.org/perldoc/Test::Class Test::Class] - This framework provides a simple way to create classes and objects for testing in the xUnit/JUnit Style

[http://search.cpan.org/perldoc/Test::Builder Test::Builder] - A module for making more testing modules

[http://search.cpan.org/perldoc/Test::Unit Test::Unit] (a.k.a. [http://perlunit.sourceforge.net/ PerlUnit]) - This framework supports unit testing in an object oriented development paradigm. This is derived from JUnit

[http://search.cpan.org/perldoc/Test::DBUnit Test::DBUnit] - Another xUnit based testing framework for testing database modules

[http://search.cpan.org/perldoc/Test::Able Test::Able] - This is an xUnit style testing framework inspired by Test::Class with

[http://search.cpan.org/perldoc/Moose Moose] . This framework was created to overcome the limitations of Test::Class and leverage the functions of Moose.

[http://www.c2.com/cgi/wiki?LectroTest LectroTest] - This is an automatic, specification-based testing tool for Perl. It is modeled after the QuickCheck module for the Haskell programming language.

[http://www.c2.com/cgi/wiki?PerlActor PerlActor] - This is a simple automated executable acceptance test framework for Perl

http://langworth.com/pub/perl_test_refcard.pdf - List of testing modules for PERL

==Ruby==
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is a dynamic, reflective objected oriented language. It has the syntax that was inspired by Perl and Small talk. It supports multiple programming paradigm. It is a single pass interpreted language.

[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit] - It is a ruby unit testing framework.

[http://rspec.info/ RSpec] – It is a behavior driven development framework for Ruby Programming language. It is inspired by JBehave

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] - It is a tool that can execute plain-text functional descriptions as automated tests.

==Scala==
[http://en.wikipedia.org/wiki/Scala_(programming_language) Scala] stands for "Scalable Language". Scala is a programming language that is designed to integrate the features of Object-orient programming and functional programming. Scala runs on JVM and is compatible with existing java programs.

[http://www.artima.com/scalatest/ ScalaTest] - is a traditional xUnit style testing framework

[http://code.google.com/p/scalacheck/ ScalaCheck], a library similar to Haskell's QuickCheck and is used for automated unit testing of Scala based application

[http://code.google.com/p/specs/ Specs] is a Behavior driven development library for Scala

[http://rehersal.sourceforge.net/ Rehersal] is another unit testing framework for Scala intended as an easier-to-use replacement for SUnit in the standard library

[http://code.google.com/p/scunit/ ScUnit] is an unit testing framework based on several Java testing and mocking frameworks like JUnit, TestNG,JBehave, EasyMock

==Smalltalk==
[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is an object oriented, dynamically typed language and is often considered as a pioneer for many other object oriented languages like Java, Python, Ruby etc.

[http://en.wikipedia.org/wiki/SUnit SUnit] - Unit Testing framework for Smalltalk. It is the original source of the xUnit desig

=References=

Below are the references for the terms that are used in this document.

http://en.wikipedia.org/wiki/Multi-paradigm_programming_language#Multi-paradigm_programming_language
http://en.wikipedia.org/wiki/Functional_programming
http://en.wikipedia.org/wiki/Procedural_programming
http://en.wikipedia.org/wiki/Reflection_(computer_science)
http://en.wikipedia.org/wiki/Metaprogramming
http://en.wikipedia.org/wiki/Object-oriented_programming

==Resources==

Below are the resources that would help the reader to jump start on the object oriented languages that are listed in this document

http://www.cplusplus.com/doc/tutorial
http://msdn.microsoft.com/en-us/vcsharp/aa336809.aspx
http://groovy.codehaus.org/Documentation
http://java.sun.com/new2java/
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html
http://us2.php.net/tut.php
http://www.python.org/doc/
http://www.perl.org/docs.html
http://www.ruby-lang.org/en/documentation/
http://www.scala-lang.org/node/197

CSC/ECE 517 Fall 2009/wiki1b 12 testFrmwk

2009-09-29T13:51:37Z

Rvenkat: /* Smalltalk */

The intent of this document is to list the popular testing frameworks for popular Object Oriented languages.

=What is a testing framework?=

Wikipedia defines a framework as "A basic conceptual structure used to solve a complex issue. Conceptually we can consider testing frameworks as a guidance, infrastructure, tool to facilitate testing. Below is a comprehensive list of popular testing frameworks for popular Object Oriented languages.

=Testing frameworks for object-oriented languages=

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is a very popular object oriented language. It is statically typed, free form and multi-paradigm programming language. The development of C++ began as an enhancement for C.

[http://aeryn.tigris.org/ Aeryn] - Aeryn is a C++ testing framework. It is primarily intended for unit testing. It is adaptable enough to handle integration testing and can be used for other forms of C++ testing.

[http://www.netbsd.org/~jmmv/atf/ ATF] : It was developed as a part of Google Summer of code 2007. It is a collection of libraries and utilities designed to ease unattended application testing in the hands of developers and end users of a specific piece of software.

[http://www.ipl.com/products/tools/pt400.uk.php Cantata++] : It provides ability to modify calls from software under test. It is a commercial tool.

[http://www.cfix-testing.org/unit-testing-framework/windows/ Cfix] : It is a unit testing framework for both C and C++. It is specialized for unmanaged Windows development. It supports the development of both user and kernel mode unit tests.

[http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page CppUnit] : It is unit testing framework. It started as a port of JUnit to C++.

[http://r2.ifs.hsr.ch/cute CUTE] : It is an eclipse plug-in for C++ unit testing.

[http://fctest.wildbearsoftware.com/ FCTest] : It is a lightweight, cross platform, framework for quickly generating x-unit tests in C/C++. The entire framework is available as a single header file.

[http://tut-framework.sourceforge.net/ TUT] : It is a small and portable unit test framework for C++. The inputs to it are based on templaets

[http://unittest-cpp.sourceforge.net/ UnitTest++]: It is a light weight unit testing framework for C++. It makes minimal use of advanced library and language features.

[http://www.visualassert.com/unit-testing-framework/ Visual Assert]: It is a visual studio plug-in. It is based on cfix testing framework.

==C#==
[http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#] is a object oriented language that has a syntax that is similar to C and C++. C# is a part of the .NET framework and it is compiled to Microsoft Intermediate Language(MSIL) which is similar to java byte code. MSIL allows C# to be platform independent.

[http://www.nunit.org/index.php NUnit] – NUnit is an opensource testing framework. It is ported from JUnit. NUnit brings XUnit to all .NET languages.

[http://research.microsoft.com/en-us/projects/Pex/ PEX] – It is an automated white box testing tool for .NET.

[http://www.csunit.org/ csUnit] – It is an open source testing tool for the .NET framework.

[http://msdn.microsoft.com/en-us/library/ms182469(VS.80).aspx MSTest] – MSTest is a unit testing framework that is developed by
Microsoft which is integrated Microsoft Visual Studio. It has a design that is similar to NUnit.

[http://code.google.com/p/mb-unit/ MbUnit]– provides advanced unit testing support with advanced fixtures. It is an extensible unit testing framework for .NET Framework that taken in and goes beyond xUnit pattern testing.

==Groovy==
[http://en.wikipedia.org/wiki/Groovy_(programming_language) Groovy] is a dynamic language built to run on Java Virtual machine. This language has additional features that are inspired by languages like python, Ruby and smalltalk. Groovy simplifies testing by providing unit test (using JUnit) and mock frameworks as part of the built in features.

[http://code.google.com/p/testngroove Test'N'Groove] - 'Test and Groove' framework is the integration of Groovy and TestNG frameworks.

[http://groovy.codehaus.org/Groovy+Mocks Groovy Mocks] - This framework is built in with Groovy and provides excellent support for mocking alternatives while testing Groovy code

[http://gmock.org Gmock] - This is a mocking framework for Groovy. Simple syntax of this framework makes it popular as it makes the tests more readable and concise

[http://www.easyb.org easyb] - This is a behavior driven development framework that can be used to test Groovy

[http://code.google.com/p/spock spock] - Spock is a testing and specification framework for Groovy applications also. This is popular as it has highly expressive specification language and it combines the best features of other tools like JUnit, jMock, and RSPec

==Java==
[http://en.wikipedia.org/wiki/Java_(software_platform) Java] is an object oriented language that derives most of its syntax from C and C++. It has a much simpler object oriented model when compared to C and C++. Java applications are compiled into byte codes and the byte code can be run on any JVM regardless of the underlying architecture.

[http://junit.sourceforge.net JUnit] – It is the most oldest and most popular java testing frameworks available, JUnit has become the de facto standard for unit testing.

[http://jtiger.org/ JTiger] - It is a JDK 1.5 annotation based testing framework that leverages many of the new features that JDK 1.5 introduced.

[http://testng.org/doc/download.html TestNG] – It is a combination of JUnit and NUnit but it also includes several new features that make it easier to use.

[http://jakarta.apache.org/cactus/downloads.html CACTUS] – It is a simple test framework for unit testing server side java cod

==LISP==

[http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] is one of oldest and a multi-paradigm, reflective programming language. The name is said to be derived from "List Processing" as the language features linked list as a major data structure. The language also features dynamic typing and functional programming support.

[http://www.ancar.org/CLUnit/docs/CLUnit.html CLUnit] is a unit test tool for defining and running unit tests for common LISP language

[http://common-lisp.net/project/lift LIFT] is another framework for testing LISP based applications. LIFT supports interactive testing and is inspired by SUnit and JUnit.

[http://www.cs.northwestern.edu/academics/courses/325/readings/lisp-unit.html LISPUnit] is a popular framework designed for beginners of LISP programming and has common LISP library that supports unit testing

[http://common-lisp.net/project/bese/FiveAM.html FiveAM] is a unit testing framework similar to LISP and does hierarchical, composable test suites

[http://common-lisp.net/project/stefil Stefil] features a more interactive approach to testing as it provides report on test failures and the conditions that caused the failure

==Objective C==

[http://en.wikipedia.org/wiki/Objective_c Objective C] is designed to provide C language , the full object oriented programming capabilities based on Smalltalk style messaging.

[http://sente.epfl.ch/software/ocunit OCUnit] is a XUnit style testing framework for testing Objective C language based applications.

[http://oops.se/objcunit ObjcUnit] is another testing framework based on JUnit, adapted for Objective C

[http://wincent.com/a/products/wotest WOTest] is an unit testing framework for Objective C which integrates fully with XCode

==PHP==

[http://en.wikipedia.org/wiki/Php PHP] is a general purpose scripting language which is widely used for web development

[http://phpunit.sourceforge.net PHPUnit] is a unit testing framework for PHP programming language based on JUnit framework

[http://www.simpletest.org SimpleTest] is an unit testing framework for PHP programming language and it supports mock objects which is used to regress the web-applications. This framework is based on JUnit/PHPUnit

[http://code.google.com/p/snaptest SnapTest] is a unit testing framework compliant with JUnit type of test harness and also provides test output that is complaint with TAP

==Python==
[http://en.wikipedia.org/wiki/Python_(programming_language) Python] is a general purpose high level programming language. It supports multiple programming paradigms. It is often used as a scripting language.

[http://www.python.org/doc/current/library/unittest.html PyUnit] – It is the standard unit testing framework module for python. It is the pythons version of JUnit. It is a part of the pythons standard library.

[http://docs.python.org/library/doctest.html Doctest] - It is a module included in Pthons programming language standard library that allows the easy generation of tests based on output from the standard Python interpreter shell.

[http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ Nose] - It is a unit test based testing framework for python that makes writing and running tests easier. It provides an alternate test discovery and running process for unit test.
Py.test – py.test is a command line tool to collect and run automated tests. It is a distributed testing tool.

==PERL==
[http://en.wikipedia.org/wiki/Perl Perl] is a high-level, general-purpose, interpreted, dynamic programming language well known for its text processing capabilities. Perl is inspired by AWK, Smalltalk, LISP, C, C++, Unix Shell etc.

[http://search.cpan.org/perldoc/TAP TAP] - TAP stands for Test Anything Protocol. This is used to allow communication between unit tests and any automated testing framework

[http://search.cpan.org/perldoc/Test::Harness Test::Harness] - This is a standard test runner for PERL which leverages TAP parser for running various tests

[http://search.cpan.org/perldoc/Test::More Test::More] - Another testing framework that is famous for the testing utilities

[http://search.cpan.org/perldoc/Test::Class Test::Class] - This framework provides a simple way to create classes and objects for testing in the xUnit/JUnit Style

[http://search.cpan.org/perldoc/Test::Builder Test::Builder] - A module for making more testing modules

[http://search.cpan.org/perldoc/Test::Unit Test::Unit] (a.k.a. [http://perlunit.sourceforge.net/ PerlUnit]) - This framework supports unit testing in an object oriented development paradigm. This is derived from JUnit

[http://search.cpan.org/perldoc/Test::DBUnit Test::DBUnit] - Another xUnit based testing framework for testing database modules

[http://search.cpan.org/perldoc/Test::Able Test::Able] - This is an xUnit style testing framework inspired by Test::Class with

[http://search.cpan.org/perldoc/Moose Moose] . This framework was created to overcome the limitations of Test::Class and leverage the functions of Moose.

[http://www.c2.com/cgi/wiki?LectroTest LectroTest] - This is an automatic, specification-based testing tool for Perl. It is modeled after the QuickCheck module for the Haskell programming language.

[http://www.c2.com/cgi/wiki?PerlActor PerlActor] - This is a simple automated executable acceptance test framework for Perl

http://langworth.com/pub/perl_test_refcard.pdf - List of testing modules for PERL

==Ruby==
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is a dynamic, reflective objected oriented language. It has the syntax that was inspired by Perl and Small talk. It supports multiple programming paradigm. It is a single pass interpreted language.

[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit] - It is a ruby unit testing framework.

[http://rspec.info/ RSpec] – It is a behavior driven development framework for Ruby Programming language. It is inspired by JBehave

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] - It is a tool that can execute plain-text functional descriptions as automated tests.

==Scala==
[http://en.wikipedia.org/wiki/Scala_(programming_language) Scala] stands for "Scalable Language". Scala is a programming language that is designed to integrate the features of Object-orient programming and functional programming. Scala runs on JVM and is compatible with existing java programs.

[http://www.artima.com/scalatest/ ScalaTest] - is a traditional xUnit style testing framework

[http://code.google.com/p/scalacheck/ ScalaCheck], a library similar to Haskell's QuickCheck and is used for automated unit testing of Scala based application

[http://code.google.com/p/specs/ Specs] is a Behavior driven development library for Scala

[http://rehersal.sourceforge.net/ Rehersal] is another unit testing framework for Scala intended as an easier-to-use replacement for SUnit in the standard library

[http://code.google.com/p/scunit/ ScUnit] is an unit testing framework based on several Java testing and mocking frameworks like JUnit, TestNG,JBehave, EasyMock

==Smalltalk==
[http://en.wikipedia.org/wiki/Smalltalk Smalltalk] is an object oriented, dynamically typed language and is often considered as a pioneer for many other object oriented languages like Java, Python, Ruby etc.

[http://en.wikipedia.org/wiki/SUnit SUnit] - Unit Testing framework for Smalltalk. It is the original source of the xUnit desig

==External References==

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

http://www.c2.com/cgi/wiki?TestingFramework

http://groovy.codehaus.org/Documentation

http://www.xprogramming.com/testfram.htm

http://en.wikipedia.org/wiki/Objective-C

http://www.scala-lang.org/

http://scala.sygneca.com/

http://rehersal.sourceforge.net/

CSC/ECE 517 Fall 2009/wiki1b 12 testFrmwk

2009-09-29T05:50:22Z

Rvenkat: /* Scala */

The intent of this document is to list the popular testing frameworks for popular Object Oriented languages.

=What is a testing framework?=

Wikipedia defines a framework as "A basic conceptual structure used to solve a complex issue. Conceptually we can consider testing frameworks as a guidance, infrastructure, tool to facilitate testing. Below is a comprehensive list of popular testing frameworks for popular Object Oriented languages.

=Testing frameworks for object-oriented languages=

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is a very popular object oriented language. It is statically typed, free form and multi-paradigm programming language. The development of C++ began as an enhancement for C.

[http://aeryn.tigris.org/ Aeryn] - Aeryn is a C++ testing framework. It is primarily intended for unit testing. It is adaptable enough to handle integration testing and can be used for other forms of C++ testing.

[http://www.netbsd.org/~jmmv/atf/ ATF] : It was developed as a part of Google Summer of code 2007. It is a collection of libraries and utilities designed to ease unattended application testing in the hands of developers and end users of a specific piece of software.

[http://www.ipl.com/products/tools/pt400.uk.php Cantata++] : It provides ability to modify calls from software under test. It is a commercial tool.

[http://www.cfix-testing.org/unit-testing-framework/windows/ Cfix] : It is a unit testing framework for both C and C++. It is specialized for unmanaged Windows development. It supports the development of both user and kernel mode unit tests.

[http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page CppUnit] : It is unit testing framework. It started as a port of JUnit to C++.

[http://r2.ifs.hsr.ch/cute CUTE] : It is an eclipse plug-in for C++ unit testing.

[http://fctest.wildbearsoftware.com/ FCTest] : It is a lightweight, cross platform, framework for quickly generating x-unit tests in C/C++. The entire framework is available as a single header file.

[http://tut-framework.sourceforge.net/ TUT] : It is a small and portable unit test framework for C++. The inputs to it are based on templaets

[http://unittest-cpp.sourceforge.net/ UnitTest++]: It is a light weight unit testing framework for C++. It makes minimal use of advanced library and language features.

[http://www.visualassert.com/unit-testing-framework/ Visual Assert]: It is a visual studio plug-in. It is based on cfix testing framework.

==C#==
[http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#] is a object oriented language that has a syntax that is similar to C and C++. C# is a part of the .NET framework and it is compiled to Microsoft Intermediate Language(MSIL) which is similar to java byte code. MSIL allows C# to be platform independent.

[http://www.nunit.org/index.php NUnit] – NUnit is an opensource testing framework. It is ported from JUnit. NUnit brings XUnit to all .NET languages.

[http://research.microsoft.com/en-us/projects/Pex/ PEX] – It is an automated white box testing tool for .NET.

[http://www.csunit.org/ csUnit] – It is an open source testing tool for the .NET framework.

[http://msdn.microsoft.com/en-us/library/ms182469(VS.80).aspx MSTest] – MSTest is a unit testing framework that is developed by
Microsoft which is integrated Microsoft Visual Studio. It has a design that is similar to NUnit.

[http://code.google.com/p/mb-unit/ MbUnit]– provides advanced unit testing support with advanced fixtures. It is an extensible unit testing framework for .NET Framework that taken in and goes beyond xUnit pattern testing.

==Groovy==
[http://en.wikipedia.org/wiki/Groovy_(programming_language) Groovy] is a dynamic language built to run on Java Virtual machine. This language has additional features that are inspired by languages like python, Ruby and smalltalk. Groovy simplifies testing by providing unit test (using JUnit) and mock frameworks as part of the built in features.

[http://code.google.com/p/testngroove Test'N'Groove] - 'Test and Groove' framework is the integration of Groovy and TestNG frameworks.

[http://groovy.codehaus.org/Groovy+Mocks Groovy Mocks] - This framework is built in with Groovy and provides excellent support for mocking alternatives while testing Groovy code

[http://gmock.org Gmock] - This is a mocking framework for Groovy. Simple syntax of this framework makes it popular as it makes the tests more readable and concise

[http://www.easyb.org easyb] - This is a behavior driven development framework that can be used to test Groovy

[http://code.google.com/p/spock spock] - Spock is a testing and specification framework for Groovy applications also. This is popular as it has highly expressive specification language and it combines the best features of other tools like JUnit, jMock, and RSPec

==Java==
[http://en.wikipedia.org/wiki/Java_(software_platform) Java] is an object oriented language that derives most of its syntax from C and C++. It has a much simpler object oriented model when compared to C and C++. Java applications are compiled into byte codes and the byte code can be run on any JVM regardless of the underlying architecture.

[http://junit.sourceforge.net JUnit] – It is the most oldest and most popular java testing frameworks available, JUnit has become the de facto standard for unit testing.

[http://jtiger.org/ JTiger] - It is a JDK 1.5 annotation based testing framework that leverages many of the new features that JDK 1.5 introduced.

[http://testng.org/doc/download.html TestNG] – It is a combination of JUnit and NUnit but it also includes several new features that make it easier to use.

[http://jakarta.apache.org/cactus/downloads.html CACTUS] – It is a simple test framework for unit testing server side java cod

==LISP==

[http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] is one of oldest and a multi-paradigm, reflective programming language. The name is said to be derived from "List Processing" as the language features linked list as a major data structure. The language also features dynamic typing and functional programming support.

[http://www.ancar.org/CLUnit/docs/CLUnit.html CLUnit] is a unit test tool for defining and running unit tests for common LISP language

[http://common-lisp.net/project/lift LIFT] is another framework for testing LISP based applications. LIFT supports interactive testing and is inspired by SUnit and JUnit.

[http://www.cs.northwestern.edu/academics/courses/325/readings/lisp-unit.html LISPUnit] is a popular framework designed for beginners of LISP programming and has common LISP library that supports unit testing

[http://common-lisp.net/project/bese/FiveAM.html FiveAM] is a unit testing framework similar to LISP and does hierarchical, composable test suites

[http://common-lisp.net/project/stefil Stefil] features a more interactive approach to testing as it provides report on test failures and the conditions that caused the failure

==Objective C==

[http://en.wikipedia.org/wiki/Objective_c Objective C] is designed to provide C language , the full object oriented programming capabilities based on Smalltalk style messaging.

[http://sente.epfl.ch/software/ocunit OCUnit] is a XUnit style testing framework for testing Objective C language based applications.

[http://oops.se/objcunit ObjcUnit] is another testing framework based on JUnit, adapted for Objective C

[http://wincent.com/a/products/wotest WOTest] is an unit testing framework for Objective C which integrates fully with XCode

==PHP==

[http://en.wikipedia.org/wiki/Php PHP] is a general purpose scripting language which is widely used for web development

[http://phpunit.sourceforge.net PHPUnit] is a unit testing framework for PHP programming language based on JUnit framework

[http://www.simpletest.org SimpleTest] is an unit testing framework for PHP programming language and it supports mock objects which is used to regress the web-applications. This framework is based on JUnit/PHPUnit

[http://code.google.com/p/snaptest SnapTest] is a unit testing framework compliant with JUnit type of test harness and also provides test output that is complaint with TAP

==Python==
[http://en.wikipedia.org/wiki/Python_(programming_language) Python] is a general purpose high level programming language. It supports multiple programming paradigms. It is often used as a scripting language.

[http://www.python.org/doc/current/library/unittest.html PyUnit] – It is the standard unit testing framework module for python. It is the pythons version of JUnit. It is a part of the pythons standard library.

[http://docs.python.org/library/doctest.html Doctest] - It is a module included in Pthons programming language standard library that allows the easy generation of tests based on output from the standard Python interpreter shell.

[http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ Nose] - It is a unit test based testing framework for python that makes writing and running tests easier. It provides an alternate test discovery and running process for unit test.
Py.test – py.test is a command line tool to collect and run automated tests. It is a distributed testing tool.

==PERL==
[http://en.wikipedia.org/wiki/Perl Perl] is a high-level, general-purpose, interpreted, dynamic programming language well known for its text processing capabilities. Perl is inspired by AWK, Smalltalk, LISP, C, C++, Unix Shell etc.

[http://search.cpan.org/perldoc/TAP TAP] - TAP stands for Test Anything Protocol. This is used to allow communication between unit tests and any automated testing framework

[http://search.cpan.org/perldoc/Test::Harness Test::Harness] - This is a standard test runner for PERL which leverages TAP parser for running various tests

[http://search.cpan.org/perldoc/Test::More Test::More] - Another testing framework that is famous for the testing utilities

[http://search.cpan.org/perldoc/Test::Class Test::Class] - This framework provides a simple way to create classes and objects for testing in the xUnit/JUnit Style

[http://search.cpan.org/perldoc/Test::Builder Test::Builder] - A module for making more testing modules

[http://search.cpan.org/perldoc/Test::Unit Test::Unit] (a.k.a. [http://perlunit.sourceforge.net/ PerlUnit]) - This framework supports unit testing in an object oriented development paradigm. This is derived from JUnit

[http://search.cpan.org/perldoc/Test::DBUnit Test::DBUnit] - Another xUnit based testing framework for testing database modules

[http://search.cpan.org/perldoc/Test::Able Test::Able] - This is an xUnit style testing framework inspired by Test::Class with

[http://search.cpan.org/perldoc/Moose Moose] . This framework was created to overcome the limitations of Test::Class and leverage the functions of Moose.

[http://www.c2.com/cgi/wiki?LectroTest LectroTest] - This is an automatic, specification-based testing tool for Perl. It is modeled after the QuickCheck module for the Haskell programming language.

[http://www.c2.com/cgi/wiki?PerlActor PerlActor] - This is a simple automated executable acceptance test framework for Perl

http://langworth.com/pub/perl_test_refcard.pdf - List of testing modules for PERL

==Ruby==
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is a dynamic, reflective objected oriented language. It has the syntax that was inspired by Perl and Small talk. It supports multiple programming paradigm. It is a single pass interpreted language.

[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit] - It is a ruby unit testing framework.

[http://rspec.info/ RSpec] – It is a behavior driven development framework for Ruby Programming language. It is inspired by JBehave

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] - It is a tool that can execute plain-text functional descriptions as automated tests.

==Scala==
[http://en.wikipedia.org/wiki/Scala_(programming_language) Scala] stands for "Scalable Language". Scala is a programming language that is designed to integrate the features of Object-orient programming and functional programming. Scala runs on JVM and is compatible with existing java programs.

[http://www.artima.com/scalatest/ ScalaTest] - is a traditional xUnit style testing framework

[http://code.google.com/p/scalacheck/ ScalaCheck], a library similar to Haskell's QuickCheck and is used for automated unit testing of Scala based application

[http://code.google.com/p/specs/ Specs] is a Behavior driven development library for Scala

[http://rehersal.sourceforge.net/ Rehersal] is another unit testing framework for Scala intended as an easier-to-use replacement for SUnit in the standard library

[http://code.google.com/p/scunit/ ScUnit] is an unit testing framework based on several Java testing and mocking frameworks like JUnit, TestNG,JBehave, EasyMock

==Smalltalk==
Smalltalk is an object oriented, dynamically typed language and is often considered as a pioneer for many other object oriented languages like Java, Python, Ruby etc.

[http://en.wikipedia.org/wiki/SUnit SUnit] - Unit Testing framework for Smalltalk. It is the original source of the xUnit design.

==External References==

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

http://www.c2.com/cgi/wiki?TestingFramework

http://groovy.codehaus.org/Documentation

http://www.xprogramming.com/testfram.htm

http://en.wikipedia.org/wiki/Objective-C

http://www.scala-lang.org/

http://scala.sygneca.com/

http://rehersal.sourceforge.net/

CSC/ECE 517 Fall 2009/wiki1b 12 testFrmwk

2009-09-29T05:49:08Z

Rvenkat: /* Ruby */

The intent of this document is to list the popular testing frameworks for popular Object Oriented languages.

=What is a testing framework?=

Wikipedia defines a framework as "A basic conceptual structure used to solve a complex issue. Conceptually we can consider testing frameworks as a guidance, infrastructure, tool to facilitate testing. Below is a comprehensive list of popular testing frameworks for popular Object Oriented languages.

=Testing frameworks for object-oriented languages=

==C++==
[http://en.wikipedia.org/wiki/C%2B%2B C++] is a very popular object oriented language. It is statically typed, free form and multi-paradigm programming language. The development of C++ began as an enhancement for C.

[http://aeryn.tigris.org/ Aeryn] - Aeryn is a C++ testing framework. It is primarily intended for unit testing. It is adaptable enough to handle integration testing and can be used for other forms of C++ testing.

[http://www.netbsd.org/~jmmv/atf/ ATF] : It was developed as a part of Google Summer of code 2007. It is a collection of libraries and utilities designed to ease unattended application testing in the hands of developers and end users of a specific piece of software.

[http://www.ipl.com/products/tools/pt400.uk.php Cantata++] : It provides ability to modify calls from software under test. It is a commercial tool.

[http://www.cfix-testing.org/unit-testing-framework/windows/ Cfix] : It is a unit testing framework for both C and C++. It is specialized for unmanaged Windows development. It supports the development of both user and kernel mode unit tests.

[http://sourceforge.net/apps/mediawiki/cppunit/index.php?title=Main_Page CppUnit] : It is unit testing framework. It started as a port of JUnit to C++.

[http://r2.ifs.hsr.ch/cute CUTE] : It is an eclipse plug-in for C++ unit testing.

[http://fctest.wildbearsoftware.com/ FCTest] : It is a lightweight, cross platform, framework for quickly generating x-unit tests in C/C++. The entire framework is available as a single header file.

[http://tut-framework.sourceforge.net/ TUT] : It is a small and portable unit test framework for C++. The inputs to it are based on templaets

[http://unittest-cpp.sourceforge.net/ UnitTest++]: It is a light weight unit testing framework for C++. It makes minimal use of advanced library and language features.

[http://www.visualassert.com/unit-testing-framework/ Visual Assert]: It is a visual studio plug-in. It is based on cfix testing framework.

==C#==
[http://en.wikipedia.org/wiki/C_Sharp_(programming_language) C#] is a object oriented language that has a syntax that is similar to C and C++. C# is a part of the .NET framework and it is compiled to Microsoft Intermediate Language(MSIL) which is similar to java byte code. MSIL allows C# to be platform independent.

[http://www.nunit.org/index.php NUnit] – NUnit is an opensource testing framework. It is ported from JUnit. NUnit brings XUnit to all .NET languages.

[http://research.microsoft.com/en-us/projects/Pex/ PEX] – It is an automated white box testing tool for .NET.

[http://www.csunit.org/ csUnit] – It is an open source testing tool for the .NET framework.

[http://msdn.microsoft.com/en-us/library/ms182469(VS.80).aspx MSTest] – MSTest is a unit testing framework that is developed by
Microsoft which is integrated Microsoft Visual Studio. It has a design that is similar to NUnit.

[http://code.google.com/p/mb-unit/ MbUnit]– provides advanced unit testing support with advanced fixtures. It is an extensible unit testing framework for .NET Framework that taken in and goes beyond xUnit pattern testing.

==Groovy==
[http://en.wikipedia.org/wiki/Groovy_(programming_language) Groovy] is a dynamic language built to run on Java Virtual machine. This language has additional features that are inspired by languages like python, Ruby and smalltalk. Groovy simplifies testing by providing unit test (using JUnit) and mock frameworks as part of the built in features.

[http://code.google.com/p/testngroove Test'N'Groove] - 'Test and Groove' framework is the integration of Groovy and TestNG frameworks.

[http://groovy.codehaus.org/Groovy+Mocks Groovy Mocks] - This framework is built in with Groovy and provides excellent support for mocking alternatives while testing Groovy code

[http://gmock.org Gmock] - This is a mocking framework for Groovy. Simple syntax of this framework makes it popular as it makes the tests more readable and concise

[http://www.easyb.org easyb] - This is a behavior driven development framework that can be used to test Groovy

[http://code.google.com/p/spock spock] - Spock is a testing and specification framework for Groovy applications also. This is popular as it has highly expressive specification language and it combines the best features of other tools like JUnit, jMock, and RSPec

==Java==
[http://en.wikipedia.org/wiki/Java_(software_platform) Java] is an object oriented language that derives most of its syntax from C and C++. It has a much simpler object oriented model when compared to C and C++. Java applications are compiled into byte codes and the byte code can be run on any JVM regardless of the underlying architecture.

[http://junit.sourceforge.net JUnit] – It is the most oldest and most popular java testing frameworks available, JUnit has become the de facto standard for unit testing.

[http://jtiger.org/ JTiger] - It is a JDK 1.5 annotation based testing framework that leverages many of the new features that JDK 1.5 introduced.

[http://testng.org/doc/download.html TestNG] – It is a combination of JUnit and NUnit but it also includes several new features that make it easier to use.

[http://jakarta.apache.org/cactus/downloads.html CACTUS] – It is a simple test framework for unit testing server side java cod

==LISP==

[http://en.wikipedia.org/wiki/Lisp_(programming_language) LISP] is one of oldest and a multi-paradigm, reflective programming language. The name is said to be derived from "List Processing" as the language features linked list as a major data structure. The language also features dynamic typing and functional programming support.

[http://www.ancar.org/CLUnit/docs/CLUnit.html CLUnit] is a unit test tool for defining and running unit tests for common LISP language

[http://common-lisp.net/project/lift LIFT] is another framework for testing LISP based applications. LIFT supports interactive testing and is inspired by SUnit and JUnit.

[http://www.cs.northwestern.edu/academics/courses/325/readings/lisp-unit.html LISPUnit] is a popular framework designed for beginners of LISP programming and has common LISP library that supports unit testing

[http://common-lisp.net/project/bese/FiveAM.html FiveAM] is a unit testing framework similar to LISP and does hierarchical, composable test suites

[http://common-lisp.net/project/stefil Stefil] features a more interactive approach to testing as it provides report on test failures and the conditions that caused the failure

==Objective C==

[http://en.wikipedia.org/wiki/Objective_c Objective C] is designed to provide C language , the full object oriented programming capabilities based on Smalltalk style messaging.

[http://sente.epfl.ch/software/ocunit OCUnit] is a XUnit style testing framework for testing Objective C language based applications.

[http://oops.se/objcunit ObjcUnit] is another testing framework based on JUnit, adapted for Objective C

[http://wincent.com/a/products/wotest WOTest] is an unit testing framework for Objective C which integrates fully with XCode

==PHP==

[http://en.wikipedia.org/wiki/Php PHP] is a general purpose scripting language which is widely used for web development

[http://phpunit.sourceforge.net PHPUnit] is a unit testing framework for PHP programming language based on JUnit framework

[http://www.simpletest.org SimpleTest] is an unit testing framework for PHP programming language and it supports mock objects which is used to regress the web-applications. This framework is based on JUnit/PHPUnit

[http://code.google.com/p/snaptest SnapTest] is a unit testing framework compliant with JUnit type of test harness and also provides test output that is complaint with TAP

==Python==
[http://en.wikipedia.org/wiki/Python_(programming_language) Python] is a general purpose high level programming language. It supports multiple programming paradigms. It is often used as a scripting language.

[http://www.python.org/doc/current/library/unittest.html PyUnit] – It is the standard unit testing framework module for python. It is the pythons version of JUnit. It is a part of the pythons standard library.

[http://docs.python.org/library/doctest.html Doctest] - It is a module included in Pthons programming language standard library that allows the easy generation of tests based on output from the standard Python interpreter shell.

[http://somethingaboutorange.com/mrl/projects/nose/0.11.1/ Nose] - It is a unit test based testing framework for python that makes writing and running tests easier. It provides an alternate test discovery and running process for unit test.
Py.test – py.test is a command line tool to collect and run automated tests. It is a distributed testing tool.

==PERL==
[http://en.wikipedia.org/wiki/Perl Perl] is a high-level, general-purpose, interpreted, dynamic programming language well known for its text processing capabilities. Perl is inspired by AWK, Smalltalk, LISP, C, C++, Unix Shell etc.

[http://search.cpan.org/perldoc/TAP TAP] - TAP stands for Test Anything Protocol. This is used to allow communication between unit tests and any automated testing framework

[http://search.cpan.org/perldoc/Test::Harness Test::Harness] - This is a standard test runner for PERL which leverages TAP parser for running various tests

[http://search.cpan.org/perldoc/Test::More Test::More] - Another testing framework that is famous for the testing utilities

[http://search.cpan.org/perldoc/Test::Class Test::Class] - This framework provides a simple way to create classes and objects for testing in the xUnit/JUnit Style

[http://search.cpan.org/perldoc/Test::Builder Test::Builder] - A module for making more testing modules

[http://search.cpan.org/perldoc/Test::Unit Test::Unit] (a.k.a. [http://perlunit.sourceforge.net/ PerlUnit]) - This framework supports unit testing in an object oriented development paradigm. This is derived from JUnit

[http://search.cpan.org/perldoc/Test::DBUnit Test::DBUnit] - Another xUnit based testing framework for testing database modules

[http://search.cpan.org/perldoc/Test::Able Test::Able] - This is an xUnit style testing framework inspired by Test::Class with

[http://search.cpan.org/perldoc/Moose Moose] . This framework was created to overcome the limitations of Test::Class and leverage the functions of Moose.

[http://www.c2.com/cgi/wiki?LectroTest LectroTest] - This is an automatic, specification-based testing tool for Perl. It is modeled after the QuickCheck module for the Haskell programming language.

[http://www.c2.com/cgi/wiki?PerlActor PerlActor] - This is a simple automated executable acceptance test framework for Perl

http://langworth.com/pub/perl_test_refcard.pdf - List of testing modules for PERL

==Ruby==
[http://en.wikipedia.org/wiki/Ruby_(programming_language) Ruby] is a dynamic, reflective objected oriented language. It has the syntax that was inspired by Perl and Small talk. It supports multiple programming paradigm. It is a single pass interpreted language.

[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Test::Unit] - It is a ruby unit testing framework.

[http://rspec.info/ RSpec] – It is a behavior driven development framework for Ruby Programming language. It is inspired by JBehave

[http://wiki.github.com/aslakhellesoy/cucumber Cucumber] - It is a tool that can execute plain-text functional descriptions as automated tests.

==Scala==
Scala stands for "Scalable Language". Scala is a programming language that is designed to integrate the features of Object-orient programming and functional programming. Scala runs on JVM and is compatible with existing java programs.

[http://www.artima.com/scalatest/ ScalaTest] - is a traditional xUnit style testing framework

[http://code.google.com/p/scalacheck/ ScalaCheck], a library similar to Haskell's QuickCheck and is used for automated unit testing of Scala based application

[http://code.google.com/p/specs/ Specs] is a Behavior driven development library for Scala

[http://rehersal.sourceforge.net/ Rehersal] is another unit testing framework for Scala intended as an easier-to-use replacement for SUnit in the standard library

[http://code.google.com/p/scunit/ ScUnit] is an unit testing framework based on several Java testing and mocking frameworks like JUnit, TestNG,JBehave, EasyMock

==Smalltalk==
Smalltalk is an object oriented, dynamically typed language and is often considered as a pioneer for many other object oriented languages like Java, Python, Ruby etc.

[http://en.wikipedia.org/wiki/SUnit SUnit] - Unit Testing framework for Smalltalk. It is the original source of the xUnit design.

==External References==

http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks

http://www.c2.com/cgi/wiki?TestingFramework

http://groovy.codehaus.org/Documentation

http://www.xprogramming.com/testfram.htm

http://en.wikipedia.org/wiki/Objective-C

http://www.scala-lang.org/

http://scala.sygneca.com/

http://rehersal.sourceforge.net/