Conversations

Chapter 8, "Advanced Control Development," introduced the concept of a conversation. When you want an application to have stateful interactions, you need a conversation. In the game of blackjack, for example, the dealer and one or more players are dealt cards. The point of the game is to get as close as possible to a score of 21 without going over. Of course, there are additional rules, but the concept is simple enough: You are dealt a card, as is the dealer and other players, and you continue to take "hits" (that is, additional cards) until you "bust" (that is, exceed 21) or the dealer busts. This entire process takes place during a conversation. A stateful interaction occurs whenever you have at least two method calls, and the second and subsequent call assumes that a previous call has taken place.

Web services can be made conversational by setting a method call's phase. Figure 9.5 shows the state diagram for a conversational Web service. Initially, a method starts a conversation (the start phase), and zero or more methods can continue the conversation (the continue phase). Eventually, a method ends the conversation (the end phase).

Figure 9.5. A state diagram of a conversational Web service.

Figure 9.6 shows a simple blackjack Web service that supports a number of conversational methods. Figure 9.7 shows the phase property of a selected method.

Figure 9.6. A conversational Web service.

Figure 9.7. Phase property of a conversational method.

Conversational methods are annotated as shown here:

 * @jws:conversation phase="start  continue  finish" 

During the various methods of a conversation, the Web service's state is serialized when each conversational method or callback handler completes successfully. If a conversational method throws an exception, state is not saved to backing store. You can force the conversational state to be stored regardless of whether a exception is thrown by wrapping the entire contents of a method call within a try / catch block. Listing 9.2 shows an example of ignoring exceptions for the purpose of continuing a conversation.

CONVERSATION STATE AND SERIALIZATION

Conversation state is persisted between method calls to a backing store by using standard Java serialization. Therefore, all control member variables must be of a serializable type. Additionally, complex variables , such as those defined by classes, and any controls used by conversations must also implement the serializable interface. You can avoid this constraint by marking a variable as transient; however, its state won't be persisted and might be lost in the event of an error or system crash.

Listing 9.2. A Method That Ignores Exceptions

 /**      * @common:operation      * @jws:conversation phase="start"      */     public int newHand() {         try {            playerHand = getCard();            return playerHand;        } catch (Exception e) {            // perhaps log the exception            // but don't re-throw        } }