Chapter 5 Scenario-Based Specification
5.2 Stub and Driver Generation
The syntax of the scenario language is designed to be as simple as possible, so that the choreography among participants is just a sequence of events. However, the sequence is interpreted differently from the perspective of each individual service. In particular, a service only concerns the events that directly involve the service itself and discard the rest, which is what the semantics of the scenario language is based on.
Specifically, based on a collection of scenarios, we can approximate each component using an emulator. As depicted in Figure 21, an emulator consists of multiple states, and each state is further divided into multiple sections each corresponding to one distinct input message.
Each such section, which we refer to as action block, in turn contains a sequence of actions.
State
Figure 21. Structure of an emulator
The abstract syntax for emulator construct is shown Figure 22. Actions include several various elements and these are listed in Figure 23.
<emulator>
z <call> represents a normal procedural invocation: when performing a call action the
input message, and wait for response message which in turn is checked against the expected output message in the <call> action.
z <return> action represents the end of the invocation originated from the input message that started the action block.
z <changeState> action will change the state of the emulator.
z <notify> action send a message to the target participant without waiting for reply.
z <thread> and <endthread> occur in pairs with actions enclosed in between (however
<thread> and <endthread> cannot be nested further). As the names suggest, the sequence of actions within a thread is executed in order, but different threads can execute concurrently.
z <wait> lets the emulator wait until a <wakeup> message from the expected participant arrives.
Emulators have straightforward operational semantics. An emulator can be in one of the designated states. Upon receiving an input message, the emulator looks up the corresponding
action block identified by the input message, perform the actions one by one, and finally may change to a new state. The structure of an action block is illustrated in Figure 24.
Figure 24. Action structure
Emulators are combination of test stubs and test drivers that are commonly used for integration testing. When testing a large system that consists of multiple subsystems, instead of developing all subsystems completely and then performing a “big-bang” integration testing, more incremental integration testing strategies are often used, so that each subsystem can be developed concurrently, possibly with different priorities and timelines. During integration testing, to test a given subsystem, a test driver is needed to drive the interaction with the system under test. If the subsystem is yet to be developed, a test stub is created and used instead to simulate its behavior. Ideally, the stub should appear indistinguishable from the actual subsystem.
To simulate test drivers, we distinguish a special state, i.e. “driver” state, from other states in an emulator. The action block for the “driver” state is consider the driver part of the
spontaneously without waiting for an input message. Figure 25 is an emulator example to contain a stub and a driver. When state name is “driver”, state sections are stored relative information of drivers. Or else they are stored some interactions of a stub.
<emulator role="Seller">
<state name="driver">
<accept>
<run scenario="buy/creditCheck/creditCheckSuccess"/>
<actions>
<call to="CreditChecker">
<customer name="Tom" id="001" expend="100"/>
<credit rating="accept"/>
<changeState name="buy/orderGoods/orderGoodsSuccess/order"/>
</actions>
With the operational semantics of the emulator language outlined above, the semantics of our scenario language is defined via an unambiguous mapping from a set of scenarios to a set of emulators (Figure 26). Scenarios describe the whole interactions among for all roles or participants. But the job of an emulator is to serve as the application driver or to substitute an unfinished role or participant. We can collect relative scenarios and integrate events of a particular role to generate a corresponding emulator.
Figure 26. An emulator is generated by multiple scenarios
The semantics of our scenario-based specification language is completed when the semantics of emulators is defined and the translation from a set of scenarios to a set of emulators is defined. Figure 27 outlines the algorithm in pseudo code that performs such a mapping.
Algorithm:
in: S : scenario set role : role name
out: E : configuration of emulator
func genEmulator (S : scenario set, role : role name) {
E = empty
for each scenario s in S {
st : current state
ac: action block of current state
istack: put intput and return, initiate is empty cstack: put call and endcall, initiate is empty temp: store ac point temporarily when thread
for each event e in s such that roleName = role, to = role, or from = role {
case e = state(name, role) :
if ac is null then E.append(st) st = (s, name)
case e = state(name, role, s', st') :
if ac is not null E.append(st)
ac = st.createActionBlock(msg)
case e = sync(from, role) : if st = null then begin st = (driver)
ac = st.createActionBlock(s.name) end
ac.append(wait, from)
case e = sync(role, to) : ac.append(wakeup, to)
case e = thread(role) : tmp = ac
ac = createThreadBlock()
case e = endthread(role) : threadBolck = ac ac = tmp
ac.append(threadBlock) }
E.append(st) }
return E }
Figure 27. Enumerator generation from scenarios
Chapter 6 System Design and Implementation
We outline the design of our system and some details about implementation in this chapter. As mentioned in chapter 4, WST is a testing framework for Web services consists of three basic components: service container, scenario manager, testing manager. In Figure 28 we outline our system implementation. When a system developer requests testing manager to test or verify for a business process, testing manager will respectively collect related information from service container, scenario manager, test case manager, and emulator manager, and then execute the testing processes and verify the results based on the generated log files.
Figure 28. Overview of our system implementation
Service-related information can be obtained from the service container. It includes several components. Figure 29 shows the class diagram of the service container in our system.
z ServiceTypes: A service type is just the service interface to describe functionality of service role. A ServiceTypes stores and manages these service types and supports corresponding queries.
z ServiceInstances: A service instance is a real Web service which can be invoked by client or other Web service. When service instances finish developing, it will be managed by a ServiceInstances object.
Testing
z Services: ServiceContainer can deploy instances of ServiceInstances to publish services which are managed by Services. In other word, Services control services which have been deployed.
+deploy()
<<介面>>
IServiceContainer
ServiceContainer
ServiceInstances +getInstance()
<<介面>>
IServiceInstances
Services +getService()
<<介面>>
IServices
+getServiceType()
<<介面>>
IServiceTypes
ServiceTypes
<<interface>>
<<interface>>
<<interface>>
<<interface>>
Figure 29. Service container class diagram
Scenario manager is used to store and classify scenarios. Figure 30 below is the class diagram containing classes related to scenario management. A Scenarios object is itself a service hosted in a container to manage scenarios described in our scenario-based specification language.
Figure 30. Scenarios class diagram
Testing manager controls activities related to testing. When system developer hopes use WST framework to test developing system, he can communicates with testing manager
immediately. Testing manager contains two sub-components, namely test case manager and
Figure 31. Testing Manager class diagram
Figure 31 is the class diagram for testing manager. In the diagram, TestCases and Emulators are also services hosted as containers and classify and manage TestCase and Emulator object.s With TestCases and Emulators, it is easy to acquire testing essential information and execute verification.
z TestCases: A TestCase structure is a test suite. Besides recording testing scenarios, it also binds scenario roles and corresponding service instances. We can acquire particular TestCase by getTestCase() and increase new TestCase by addTestCase() method.
z Emulators: An Emulator is generated from multiple scenarios and stored and classified by Emulators. Emulators is similar to TestCases. We can acquire particular Emulator by getEmulator() and increase new Emulator by addEmulator() method.
Besides TestCases and Emulators, TestingProcesses is responsible of managing individual testing processes. When application developer executes testing for a test case, TestingProcesses will create a new process which uses ID as its identification and operate
runTest() method (Figure 32). In other words, our WST system can test or verify for multiple test cases at the same time and let whole testing systems are more forceful.
Figure 32. Testing processes
WST can assist Web Services-based application development across organizations boundaries. For repeatable functionality, it will quote the same scenario specification to reduce complexity greatly. Due to the assistance of the WST, application system developer can focus on the system integration based on interface. It also can reduce coupling between web services to lessen further unnecessary mistakes and save developing time.
Testing Manager
Testing
Processes Processes
Process n Process 1
Process 2 runTest()
‧
‧
‧
Chapter 7 Discussion and Conclusion
The development of WST is an ongoing process. Currently we focus primary on the core scenario management and testing facilities. However, it should be noted that the long-term goal is, as we have also pointed out, to integrate our framework in the overall WSD process.
There are many benefits when using WST. First, scenarios are straightforward to understand.
They can be used in conjunction with UML use cases and sequence diagrams to help the requirements elicitation phase.
More importantly, since scenarios can be executed immediately, requirement analysts can gain more timely and interactive feedbacks. With further tool support, a simulating
“prototype” can be constructed the minute when scenarios are created. Hence it is possible to use WST to also facilitate prototyping. From this perspective, future development in near team is not only to develop convenient scenario editors similar to UML sequence diagram editors, but also to develop interpreters that can interpret scenarios and present users with graphical user interfaces simulating the look and feel of the application.
The capability of WST to generate test drivers and stubs as emulators also facilitate rapid and incremental development cycles. The developers can choose to implement a (small) subset of services of the overall system and can test them immediately. For example, if the developers want to verify or test choreography which has been implemented by WS-BPEL, scenarios can be created in parallel to describe interaction behaviors among multiple Web services, and emulators generated automatically from multiple scenarios to substitute incomplete or unfinished Web services. Although it is necessary to transform the interface of emulators into standard Web service interface, which is not implemented yet, the implementation is not too involving. Finally, the overall system is driven to achieve verification or testing by the driver.
Our objective has been to exploit the use of scenarios for Web service specification and Web services-based system testing. To achieve the goal we have focused equally on both theoretical and practical aspects. From practical perspective, it is desirable that our approach can be applied to actual development process for real-world Web services. From theoretical perspective, the language should bear rigid syntax and semantics and permit numerous verification and validation techniques.
From practical perspective, the major issue is that there are currently multiple standards for Web services choreography under construction. Since there is no common agreement about how services are composed dynamically, let alone how they can be synchronize to enable correct concurrent testing, creating a public Web service testing framework that is universally applicable seems impossible. The issue is apparent when we consider complicated choreography scenarios involving multiple services each is not necessarily “memory-less.”
One possibility is to employ coordination mechanisms such as WS-Coordination [IBM a][IBM b] proposed by IBM, Microsoft, and BEA can be used to provide consistency and automatic coordination [Alonso04]. Therefore, our approach does not attempt to build such a system but limits the scope to WSD projects where member service providers agree on technical issues such as how services are instantiated, managed, and composed.
From theoretical perspective, developing a complete analytical framework covering all language constructs of WS-BPEL or WS-CDL is beyond the scope of this study, because both standards are quite complex. In contrast, our proposal permits straightforward emulator generation and simulation. Furthermore, the complexity of verification and validate will also be lower. However, our bias towards ease of implementation and analysis also poses a barrier when applying our work to practical situations, because there are Web services that can not be easily modeled using our scenario-based language. This issue is resolved, similar to above, by limiting our scope to those Web services whose behavior can be approximated nicely by emulators.
In summary, as modern software development methodologies pay more attention to practices such as use case driven, test first development, rapid prototyping, incremental and iterative planning (agile methods), we believe WST become very relevant for the emerging WSD wave. We have proposed a scenario-based specification language for Web services and a corresponding concurrent testing framework. We showed that scenarios can be used as supplement information to otherwise syntax-only interface specification language, i.e., WSDL, thus can provide a cost-effective approach to behavioral specification compared to either natural language or formal model-based approaches. More importantly, the design of the syntax and semantics of our scenario-based language permit automated test generation, including test drivers and stubs, in a straightforward way that not only increases the understandability of the language but also makes implementation less burdensome. Similar to integration testing that is commonly used in software development process, our scenario-based
specification and testing approach can be an important contribution to Web service-based development where decentralization is the norm.
References
[WSA] Web Services Activity, W3C. http://www.w3.org/2002/ws/
[W3C a] W3C, “Web Services”, http://www.w3.org/DesignIssues/WebServices.html [W3C b] W3C, “Web Services Architecture Usage Scenarios”,
http://www.w3.org/TR/ws-arch-scenarios/
[W3C c] W3C, “Web Services Choreography Requirements 1.0”, http://www.w3.org/TR/ws-chor-reqs/
[IBM a] IBM WS-Coordination, “Web Services Coordination (WS-Coordination) ”, http://www-128.ibm.com/developerworks/library/specification/ws-tx/
[IBM b] IBM, “Transactions in the world of Web services”,
http://www-128.ibm.com/developerworks/library/ws-wstx1/index.html [SOAP] W3C, “SOAP Version 1.2”, http://www.w3.org/TR/soap12-part0/
[WSDL] W3C, “Web Services Definition Language”, http://www.w3.org/TR/wsdl20/
[UDDI a] OASIS, “Universal Description, Discovery, and Integration (UDDI)”, http://www.uddi.org
[UDDI b] OASIS, UDDI Version 3.0, “UDDI Version 3 Features List”, http://www.uddi.org/pubs/uddi_v3_features.htm
[BPEL] OASIS WS-BPEL, “Web Services Business Process Execution Language”,
http://www.oasis-open.org/committees/download.php/10347/wsbpel-specification-draft-120 204.htm
[CDL] W3C, “Web Services Choreography Description Language Version 1.0”, http://www.w3.org/TR/ws-cdl-10/
[Bertolino03] Antonia Bertolino, Andrea Polini, “A Framework for Component Deployment Testing”, Proceedings of IEEE Software Engineering, 2003, pp. 221-231.
[Fredriksson99] Andreas Fredriksson, “Component Based Systems Development--basic concepts”, 1999.
[Tsai02a] W. T. Tsai, R. Paul, Y. Wang, C. Fan, and D. Wang, “Extending WSDL to Facilitate Web Services Testing”, Proc. of IEEE HASE, 2002, pp. 171-172.
[Tsai02b] W. T. Tsai, R. Paul, W. Song, and Z. Cao, “Coyote: An XML-Based Framework for Web Services Testing”, Proc. of IEEE HASE, 2002, pp. 173-174.
[Tsai03a] W. T. Tsai, R. Paul, Z. Cao, L.Yu, A.Saimi, and B. Xiao, “Verification of Web Services Using an Enhanced UDDI Server”, Proc. of IEEE WORDS, 2003.
[Tsai03b] W. T. Tsai, L. Yu, A. Saimi, and R. Paul, “Scenario-Based Object-Oriented Test Frameworks for Testing Distributed Systems”, Proc. of IEEE Future Trend of Distributed Computing Systems, 2003.
[Bai01 a] Xiaoying Bai, W. T. Tsai, Ray Paul, Techeng Shen, and Bing Li, “Distributed End-to-End Testing Management”, Proceedings of IEEE EDOC, 2001, pp. 140-151.
[Bai01 b] W. T. Tsai, Xiaoying Bai, Ray Paul, Weiguang Shao, Vishal Aganval, “End-To-End Integration Testing Design”, IEEE COMPSAC, 2001, pp. 166-171.
[Bai02] X. Bai, W. T. Tsai, R. Paul, K. Feng, and L. Yu, “Scenario-Based Modeling And Its Applications”, Proc. of IEEE WORDS 2002, pp. 140-151.
[Offutt04] Jeff Offutt and Wuzhi Xu, “Generating test cases for web services using data perturbation”, Proceedings of ACM SIGSOFT SEN, 2004.
[Optimyz] Optimyz, “WebServiceTester: Comprehensive Web Service Testing Solution”, http://www.webservices.org/index.php/ws/content/view/full/42225
[Alonso04] Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju, “Web Services Concepts, Architectures and Applications”, 2004
[Bruegge03] Bernd Bruegge and Allen H. Dutoit, “Object-Oriented Software Engineering”, 2003.
[Paletz03] Chris Paletz “Web Services Orchestration. A review of emerging technologies, tools and standards”, Hewllett Packard White Paper, January 2003.
[D'Souza98] Desmond Francis D'Souza and Alan Cameron Wills, “Objects, components, and frameworks with UML: the catalysis approach”, 1998.
[Uchitel04] Sebastian Uchitel, Jeff Kramer, and Jeff Magee, “Incremental Elaboration of Scenario-Based Specifications and Behavior Models Using Implied Scenarios“, ACM Transactions on Software Engineering and Methodology (TOSEM), 2004, pp. 37-85.
[Kulvatunyou03] Boonsrem (Serm) Kulvatunyou, Nened Ivezic, Monica Martin, Albert T.
Jones, “A Business-to-Business Interoperability Testbed - An Overview”, Proceedings of ACM the 5th ICEC, 2003, pp. 195-204.
[McIlraith03] Sheila A. McIlraith and David L. Martin, “Bringing Semantics to Web Services”, IEEE Intelligent Systems, pp. 90-93, January-February, 2003.
[Miller03] Tim Miller, Paul Strooper, “A Framework and Tool Support for the Systematic Testing of Model-Based Specifications”, ACM TOSEM, 2003, pp. 409-439.
[Stocks93] P. A. Stocks, D. A. Carrington, “Test Templates A Specification-based Testing Framework”, Proceedings of IEEE Software Engineering, 1993, pp. 405-414.
[Ulrich99b] Andreas W. Ulrich, Peter Zimmerer, Gunther Chrobok-Diening, “Test Architectures for Testing Distributed Systems”, Quality Week, 1999.