Web Services is emerging as a new distributed computing platform on top of the Internet using standard protocols, and is attracting intensive research and development efforts from industry and academics. One main difference between Web Services and earlier distributed computing technologies is that Web Services uses XML as the standard message exchange format over Internet [W3C a]. Specifically, in the Web service architecture, Web services (or just services from now on) are autonomous software systems accepting XML-based requests from other services using standard SOAP protocol, whereas different services can be implemented using different technologies by different organizations or people. However, these services need to expose their interfaces through standard interface specification representation, i.e. WSDL, in order to achieve interoperability in an Internet scale. With services registered and advertised in public registries using standard protocols (e.g. UDDI), people can look for services they need and combine them to form complete distributed software systems.
Service-oriented architecture (SOA) is a more general term describing the main concepts behind Web Services. Within an SOA services are the basic building blocks that are network addressable, autonomous and independently maintained. Services can be composite so that a service or an application can be constructed by composing multiple smaller services. However, one can implement an SOA without using Web Services standards. In what follows, however, we do not make explicit distinction between Web Services and SOA as most points that will be discussed are general and applicable to both.
In this thesis we are concerned with Web services-based software development, or WSD, in the emerging global service market hinted previously. In a WSD project, the system to be constructed comprises a number of services that are developed and maintained by different service providers. There are a number of roadblocks ahead towards such a global service market vision; among the challenges for WSD is infrastructure and tool support for service composition, and the associated “trust problem” as indicated in [Bertolino03].
To better understand the issue, it should be noted that in a WSD project, each individual service concentrates on particular problem domain reflecting the owner’s expertise. In order to make effective use of a service, or to select among multiple competing services, the developer needs to examine the interfaces of the services respectively and study associated documents published by their corresponding service providers. Although the former, interface part can be
defined rigorously, the latter, semantic part is usually expressed as human-readable forms. The problem is that, the supplement documents may not contain sufficient information describing the services, or worse they may contain misleading materials, either by mistake or due to the mismatch between the documents and actual service implementation. In addition, during runtime whether a given service behaves as it claims to may not be easy to determine. These issues are extremely crucial for companies and developers to decide whether it is worthwhile for them to adopt Web Services or SOA technologies.
As mere interface specification is insufficient for WSD, recently there have been substantial efforts from many organizations and institutes put into creating standards for specifying desirable collaboration patterns among services. Notable examples include OASIS WS-BPEL [BPEL] and W3C CDL [CDL]. These service orchestration and choreography standards are especially important in business context, where it is common to involve multiple services and applications (interacting with end users) to carry out a business transaction in a predefined manner. Although these standards can help clarifying the behavioral implications of the participating services, they are essentially separated from the specification of the services themselves, and it is not always straightforward, nor complete, to understand and verify services based on interface and choreography specifications.
Another challenge faced by WSD is the management of the development process itself.
Although in a general sense developing service-based applications is not much different from normal software engineering process, and people have developed many large and complex distributed systems successfully. However, one main difference between WSD and others is that services are independently developed and maintained, and the manager of a WSD project may not have sufficient control over the entire 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, and with different plans or rate of progress. In summary, configuration management may become a major obstacle for WSD projects.
In this thesis we exploit the use of scenarios as supplement information to describe the behavioral aspect of services. In short, a scenario describes a particular sequence of interactions between service and application instances using example messages. Unlike more comprehensive, model-based specifications that attempt to describe software systems completely, scenario-based specification techniques in general do not attempt to cover all
possible interaction sequences that can occur for the system during runtime. However, model-based specification techniques often impose various forms of cost to some degree. In comparison, scenario-based approaches are more cost effective and easier to understand and implement.
Scenario-based specification technologies have another equally important benefit for WSD because they fit nicely with testing techniques. 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. Similarly, larger scenarios involving more entities also provide useful information for integration testing. As test driven development has become one of the widely used software development approaches today, we believe infrastructure and tool support for service testing will be very beneficial for future WSD.
In this thesis we design and develop a scenario-based framework for service specification and testing. Within the framework the user first designs and creates service types specifying service interfaces that actual services need to support and conform to. Services are developed implementing one or more service types, 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 teams) 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.
Furthermore, using the service type and scenario information, the framework can generate appropriate test drivers and stubs to facilitate unit testing and integration testing, and execute and monitor test cases in a distributed manner. Because one can choose to implement services incrementally, perform tests, and obtain timely feedbacks, we believe our framework can be integrated in an overall WSD process nicely and contributes to the overall productivity.
The rest of the thesis is organized as below. In chapter 2 we describe background related to Web Services and SOA as well as general software development issues for WSD. In chapter 3 we describe the motivation of our work and related scenario-based specification techniques, as well as related work on Web service specifications using scenarios. In chapter 4 we outline the architecture of our scenario-based specification and testing framework. In chapter 5 we describe further details about the scenario language and the generation of test drivers and stubs.
After some discussions about our approach in chapter 6, we conclude the thesis in chapter 7 with future work discussed.