Language Description - Scenario-Based Specification

Chapter 5 Scenario-Based Specification

5.1 Language Description

We consider a Web services-based system consists of multiple interacting Web services and other subsystems such as client applications, databases, etc. For brevity we refer to the services and sub-systems as components that make up the system. Through some client applications, users can interact with the system during a session by issuing requests and receiving replies. Upon receiving a request, the system may initiate a chain of reactions involving a particular pattern of message exchanges among the constituent components. The message exchange pattern depends on the nature and content of the request as well as the current system state, and is not necessarily in a simple sequential order; that is, some exchanges may occur concurrently because the participating components each may has its own control flow.

Based on the system model above, we describe the behavior of the system using a collection of scenarios. Each scenario represents one particular message exchange pattern using example (but meaningful) messages. The syntax for each scenario is depicted in Figure 13, where we use informal but commonly used representation for syntax definition:

<role name="qname"

type="qname"?/>+

<seq>

EVENT+

</seq>

</scenario>

Figure 13. Syntax of scenarios

In our language, the definition of a scenario is divided into two parts. First the roles of participants in the scenario is declared, followed by a sequence of events each may indicate state change or an interaction between two participants. There are some basic types of events.

Figure 14 shows EVENT syntax in the scenario language.

EVENT :

Figure 14. EVENT syntax.

z Firstly, <call> and <endcall> are events representing service invocation and completion, and should occur in pairs.

z <state> declares the state of the participant and itself does not involve message exchanges. Note that a service responds to a request not only according to the nature of the request but also its current state. The name of the state is important since it is used as identifiers when combining multiple scenarios.

z <notify> represents asynchronous message notification and the caller do not wait for message receiver’s response.

z In contrast, <sync> represents a synchronization step and its objective is to align the execution progress of two participants. Note that although synchronization mechanisms is common among various concurrent programming languages and systems (e.g. join operations or rendezvous), their use is not common for ordinary Web services except for services that orchestrate other services (such as within a WS-BPEL workflow). As will become clear later, in our language <sync> is primarily for testing purpose and is considered outside the responsibility of ordinary Web services.

z Finally, in a complex choreography, a participant may initiate actions upon receiving a message. Normally all events following the message reception (by <call> or

<notify> from another participant) and originated from the participant are consider the actions to be taken by that participant (in the order specified), until the event that indicate the end (by <endcall> or other incoming events). In the case concurrent groups of actions need to be initiated, <thread> and <endthread> suit the purpose.

Figure 15. Scenario example

We expand the above-mentioned ordering goods choreography example in figure 15.

First, there are interactions of determining a price between a buyer and a seller, and then buyer send a synchronous signal to credit checker. After credit checker receives the synchronous signal, it notifies a message to the seller and then sends a synchronous signal to buyer similarly. The buyer decides to order the goods when a quote is acceptable, and the seller then must to checks the buyer credit rating. If the buyer credit rating is ok, the seller will responds order confirmation and then requests a delivery data from the shipper. Finally, the shipper informs the seller and the buyer of the delivery details.

To describe the scenario using our language, first roles should be defined. In this example, there are four roles in the choreography and each role has distinct name. As Figure 16, they are individually buyer, seller, creditchecker, and shipper.

Figure 16. Roles

In choreography, multiple interactions are integrated and combined among whole roles for communication. An interaction stands for information exchanged between two roles.

Figure 17 is the first interaction part of our example. The buyer sends request messages to the seller for quotes, and then the seller respond messages of prices. <state> and <endstate>

represent separately the seller initial state and end state of this interaction.

<seq>

</call>

</endcall>

Figure 17. Service invocation example

Figure 18 is an example of synchronization and notification. The buyer sends a synchronous signal to wake credit checker up. After the credit checker finishes <notify> event, it goes back a synchronous signal to the buyer.

</notify>

Figure 18. Synchronization and notification

The fragment below (Figure 19) is a thread example to illustrate active events. The seller has a sequence of active events which invokes the shipper and obtains its response between

<thread> and <endthread>.

</call>

</endcall>

Figure 19. Threads

The scenario language will assist us to design and analysis of system requirement. The language is capable of describing complex scenarios in choreography. A complete scenario description which uses our scenario language is shown in Figure 20.

<seq>

</call>

</endcall>

</notify>

</call>

</call>

</endcall>

</endcall>

</call>

</endcall>

</notify>

</seq>

</scenario>

Figure 20. Complete scenario

在文檔中一個以情境為基礎的網路服務測試架構 (頁 31-36)