3.1 Motivation
We are interested in a picture larger than standards and mechanisms for service composition and coordination, that is, Web services-based software development (WSD). In a WSD project, the final system to be built consists of a number of services and other common components such as databases, client applications, legacy systems, etc. Each of the services may exist already or is under development, and may be developed and maintained by an external, independent organization or by the project development team themselves.
In this sense Web services are a special but interesting class of software components, and WSD is similar to component-based development (CBD) [Fredriksson99] [D'Souza98], where components fabricated by independent parties can be assembled by others in unforeseen manner. Thus many issues related to CBD, in particular the use of COTS components in a development project, will also occur in WSD. Still, there are some differences between components and services. Most importantly, components are often static, reusable units that can be purchased and become the buyer’s assets. On the other hand, services are autonomous and maintained by the owner, and service “singletons” are also common, such as geography map services offered by specific vendor (Yahoo! Map or Google Map). Configuration management in such a decentralized environment becomes critical to ensure the consistency and quality of the composition.
There are a number of roadblocks ahead towards the desirable open service market that also supports individual WSD projects without incurring excessive burden. To identify these obstacles, it is important to first characterize future development environment for WSD.
Unlike traditional software projects that are initiated and managed within an enterprise, in WSD projects services are independently developed and maintained, with their own problem domains and design considerations in mind. In such a decentralized environment, to harness the heterogeneity exhibited by these external services and tailor them for current project need, developers need to carefully study and validate the interfaces and related documents about these services. Although the interfaces can be defined formally using WSDL, the behavioral aspects described in the associated documents may not be as rigorous [McIlraith03]. Those documents may not contain sufficient information describing the services, or worse, they may contain misleading or out-dated information, either by mistake or due to the mismatch
between documents and service implementation (versions). In addition, during runtime whether a given service behaves as it claims it would may not be easy to determine. Such a
“trust problem” as presented in [Bertolino03] should be resolved for Web Services to be viable in the long run, but currently there is no suitable answer yet that are widely acceptable.
Another equally important issue about WSD is the control and management of the WSD process. Due to the decentralized nature of a WSD project, the manager may not have sufficient control over the whole development process. The matter becomes more complicated when considering that different services developed either in-house or externally may be under different phases of construction with different plans or rate of progress. Generally speaking, careful configuration management for WSD projects is necessary in this case. However, techniques and mechanisms to ensure the consistence of services being composed for a specific project, and at the same time not to compromise the evolution and improvement of individual services, remain a challenge to be answered.
Although we do not attempt to completely answer the WSD challenges discussed above, we do believe that by providing suitable mechanisms and tools, some of the problems can be relaxed. We propose to use scenarios as supplement information to describe the behavioral aspect of services. In short, a scenario describes a particular sequence of interactions between services and application instances using example messages. Unlike more comprehensive model-based specification techniques (e.g. Z) which attempt to describe software systems completely and mathematically, scenario-based specifications do not intend to cover all possible interaction sequences the system may exhibit. However, scenario-based approaches are more cost effective and easier to understand and to implement when compared to model-based specification techniques [Uchitel04].
Scenarios also fit nicely with common testing techniques [Tsai03b]. In fact, unit testing scripts can be regarded as simple scenarios in each of which there are only two entities: the client and the unit under testing. From this perspective, larger scenarios involving more than a couple of entities also provide useful information for integration testing. As test driven development has become one of the widely used development methodologies today, we believe infrastructure and tool support for service testing will be very beneficial for future WSD.
In addition to the scenario-based specification, we will also design and implement a
framework should generate appropriate test drivers and stubs to facilitate unit testing and integration testing, and should execute and monitor test cases in a distributed manner. Because one can choose to implement services incrementally and perform testing and obtain timely feedbacks, we believe our framework can be integrated in an overall WSD process nicely and contributes to its productivity.
In the next chapter we first describe a scenario-based framework that we designed and developed with the motivations above in mind. Within the framework users first design and create service types which specify service interfaces that actual services need to support and conform to. Services are developed implementing one or more service types previously defined, and can be combined to form larger services. In particular, a service type can be associated with a set of scenarios so that implementing services (possibly by different people or groups) need to conform to the semantic constraints imposed by the scenarios. In addition, scenarios involving multiple services or applications can also be created and stored. These scenarios specify possible collaboration patterns and can help developers understand the design ideas and usage information of related services.
3.2 Related Work
As WSD grows important, many testing tools and techniques are developed continuously.
The Web service testing framework and approaches proposed in [Tsai 02a] [Tsai 02b] and [Tsai03a] are some such examples. In particular, [Tsai02a] and [Tsai02b] propose to extend WSDL with information to facilitate testing, and to place supplement information such as test scripts for Web services inside UDDI so that verification can be performed when a Web service is checked in and out. Not surprisingly, the researchers developing the systems above also work on scenario-based modeling and testing framework for distributed (OO) systems [Tsai02c][Bai02] in a more general context.
The central idea of their work is similar to ours. With additional, testing-based or scenario-based information associated with Web services, users gain more insights into the behavior of the services. In addition, automated verification to some extent becomes possible.
However, their work essentially corresponds to unit testing in that scenarios and testing scripts are associated with individual Web services, and we are more interested in service choreography, especially when multiple participants are involved in potentially complex business processes. In fact, scenarios can coexist with and complement choreographies (e.g.
WS-CDL documents) and enhance their clarity yet permit easier test script generation.
Furthermore, we are also interested in integrating scenario-based specification techniques with the overall WSD process, in particular unit testing and integration testing, and more importantly in requirements elicitation. To achieve this goal, our specification language is simplified to facilitate automated test driver and stub generation.
In production of testing cases, Web Services use XML and SOAP to communicate on the internet; it is tedious to produce test cases for services. The data perturbation method proposed in [Offutt] makes use of grammar concepts to define message grammars. In the approach, real interaction messages are translated into test cases using date perturbation which works by modifying values in request messages and analyzing the response messages. It is intended that suitable test cases can be produced and web service testing can be proceeded easier and more automatic. However, [Offutt] focuses on peer-to-peer interactions and not provide further methods to support multilateral interactions. When facing more complex situations that, for example, are described as choreographies, the method needs to be extended.
[Optimyz] provides a Web Services choreography testing solution based on WS-BPEL.
After importing BPEL and WSDL files, user can start the business process testing which using the test data that can be specified using “Test Data Editor”. However, it is comparatively complicated and troublesome to specify each test data between Web services; especially, it requires a lot of participations. In comparison, our scenario-based approach is easier and can greatly reduce the efforts needed to design and implement testing strategies and save time for developing WSD processes.