In this chapter we describe a Web services testing framework called WST. Before describing the system architecture, we first describe the underlying service-oriented infrastructure WST is based on.
4.1 Service-Oriented Architecture
The WST framework is based a service-oriented architecture we have been developing that supports dynamic service customization and composition. As depicted in Figure 6, the overall architecture is modeled as a service space that consists of agents and services communicating with each other through some kinds of channels (e.g. sockets, RMI, or SOAP).
Agents are software entities that serve as intermediaries between users and services and may be equipped with GUIs. Services are network addressable software entities that function by processing requests through their interfaces. When processing requests a service may consult other services for assistance.
Figure 6. Our service-oriented architecture
Each service (instance) is associated with a service type. A service type describes the interface the service needs to implement. Service types are maintained in some registry services in a way similar to the UDDI registry in the Web Services architecture.
We distinguish a special class of services, called service containers, to host other non-container services and govern their definition, instantiation, customization, composition,
agent
service
container
user
channel container boundary manages
inter-container channel
and other lifecycle management. Specifically, a container is responsible of establishing suitable channels among the services it manages while respecting their requirements.
Inter-container collaboration is needed when connecting services across container boundaries.
In either case, service composition may involve complex, platform-specific managerial tasks such as setting up data or control flows properly.
We have implemented several channel types based on sockets and Java RMI, as well as containers supporting both. Currently, we are also developing an SOAP-based channel type and the corresponding container using the Axis Web service container. Because in our implementation all services have the same primary interface, that is, a single point of contact that receives, interprets, and returns XML messages from clients, creating new channel types is straightforward. Specifically, for each channel type we only need to implement a container and associated contexts (as Java classes) to shield the communication details from managed services.
4.2 WST Architecture
The WST architecture is depicted in Figure 7. In the framework there are three basic components, that is, service container, scenario manager, and testing manager. Both the scenario manager and the testing manager are also services hosted in a container.
The general usage of WST for WSD is as follows. Developers first develop and maintain scenarios thorough scenario manager during the requirements elicitation phase. In such a phase related requirement documentation and/or UML diagrams may also be created (use case diagrams, sequence diagrams, or other collaboration diagrams). Note that the design and creation of service types, can be done before, after, or in parallel to scenario development.
When the set of scenarios become sufficient, the developers can request the testing manager to simulate the scenarios through automatically generated testing drivers and stubs, and verify and validate the results that are produced during the simulation. Under the development plan, the developers may choose to implement part of the services with higher priority and perform timely testing in an incremental manner. The testing manager can replace the stubs with actual services and perform testing. Such process is repeated until all system is developed. We describe each of the system modules in the following sections.
4.3 Service Container
As mentioned, service containers host and manage other non-container services in our service-oriented architecture. Containers themselves are also services so that they are subject to the same basic responsibility and privileges like other services. As a result, clients can query and manipulate services (instances) through the container that hosts them. In our WST case, when executing tests, the testing manager can create required services automatically (test drivers and stubs), or use those hand-crafted services by developers that are already set up in the container.
4.4 Scenario Manager
A scenario is usually referred to as a sequence of interactions between the user and the system and is usually used in software requirement design and analysis phases in conjunction with use cases. A scenario describes a concrete set of interactions and is usually used as an example for illustrating common case (Figure 8). Scenarios enhance requirements elicitation and system understanding by describing the communication patterns between users and systems. In this thesis, however, we consider in a more general case in which a scenario is an example sequence of interactions between the user and possibly more than one internal entities of the system.
Figure 8. A scenario example
The scenario manager in the WST architecture is responsible of storing and classifying scenarios. It maintains data structures to enhance classification and search. For proper separation of concerns, scenarios are organized hierarchically (e.g. [Tsai02]). As the example scenario below shows (Figure 9), a scenario can include other scenarios in its specification;
hence increase the reusability and simplify scenarios design.
<scenario name="buy/orderGoods/orderGoodsSuccess">
<ref name="creditCheckSuccess" path="buy/creditCheck/creditCheckSuccess"/>
<role name="Seller" type="SellerType"/>
<role name="CreditChecker" type="CreditCheckerType"/>
...
<seq>
<state name="check" role="CreditChecker"/>
<call from="Seller" to="CreditChecker">
<customer name="Tom" id="001" expend="100"/>
</call>
...
<use scenario="creditCheckSuccess">
<role name="Seller" binding="Questioner">
<role name="CreditChecker" binding="VerifyAgency">
</use>
...
<endcall from="Seller" to="CreditChecker">
<credit rating="accept"/>
</endcall>
<endstate name="check" role="CreditChecker"/>
...
</seq>
</scenario>
Figure 9. The example using the scenario language
4.5 Testing Manager
Testing manager governs all the testing-related activities. When system developer hopes to use WST framework to test developing system, he/she can communicates with testing manager immediately. Testing manager contains two major components, namely the test case manager and the emulator manager.
In WST, a test case is in fact a test suite where multiple tests can be performed. An example test case is shown in Figure 10, which contains more than one scenario. In addition to the scenarios to be tested, the test case also binds the roles of the scenarios with corresponding service instances. As suggested in the example, different scenarios may exercise different
“collaboration paths” of the same choreography.
<testcase name="TestCaseExample">
<service name="BuyerService" instance="buyerService"/>
<service name="SellerService" instance="sellerService"/>
<service name="CreditCheckerService" instance="creditCheckerService"/>
<service name="ShipperService" instance="shipperService"/>
<scenario name="buy/creditCheck/creditCheckSuccess">
<role name="Seller" is="SellerService"/>
<role name="CreditChecker" is="CreditCheckerService"/>
</scenario>
...
<scenario name="buy/orderGoods/orderGoodsSuccess">
<role name="Buyer" is="BuyerService"/>
<role name="Seller" is="SellerService"/>
<role name="CreditChecker" is="CreditCheckerService"/>
<role name="Shipper" is="ShipperService"/>
</scenario>
</testcase>
Figure 10. A test case example
Test drivers and stubs that are essential during unit testing and integration testing. A driver simulates a client that calls the system under test or its subsystems/components. A test stub, on the other hand, simulates a component or subsystem that has not been developed yet.
In our framework, both drivers and stubs are supported uniformly by emulators. An emulator can act as both test driver and/or test stub. As mentioned, throughout a WSD process some of the services may be under construction and not available for testing. The WST framework
allows this situation and can use emulators to substitute unfinished roles or participants. At this time, the emulator acts a stub to receive messages or invoke other services. An emulator also can substitute a driver. It invokes roles or participants in sequence when it receives a starting message.
In WST, an emulator is generated automatically from multiple scenarios and is stored and classified by the emulator manager. Figure 11 is an example of emulator. The language for describing emulators will be further illustrated in the next section.
<emulator role="Seller">
<state name="driver">
<accept>
<run scenario="buy/creditCheck/creditCheckSuccess"/>
<actions>
<state name="buy/orderGoods/orderGoodsSuccess/quote">
<accept>
Figure 11. An emulator as both a test driver and stub
The emulator manager is capable of translating scenarios into emulators, and maintains their identities and storage. The test case manager maintains test cases that are created by developers. In short, a test case describes the set of scenarios to be tested and the set of system components, either emulators or actual implementations, in those scenarios. As a result, the main job of the testing manager becomes the execution and monitoring of test cases.
4.6 Testing Execution and Monitoring
WST can perform unit testing for individual services as well as integration testing for business processes. Unit testing helps system developers understand the semantics of individual services and verify their implementation. Integration testing help developers verify business processes for complicated collaborations or Web services choreography, and can assist Web Services-based application development across organizations boundaries.
WST will logs relative interactions in log files at the same time. Every role has own log file to record corresponding communications. Figure 12 is a log file of the role to illustrate messages and order of interactions. Our can analyze these log files to verify whether the processes of scenarios are correct or not.
in:
<?xml version="1.0" encoding="UTF-8"?>
<order goods="IBM" id="001" name="Tom" price="100"/>
call:
<?xml version="1.0" encoding="UTF-8"?>
<customer expend="100" id="001" name="Tom"/>
endcall:
<?xml version="1.0" encoding="UTF-8"?>
<credit rating="accept"/>
out:
<?xml version="1.0" encoding="UTF-8"?>
<orderStatus status="Confirmation"/>
…
Figure 12. An example of log files