Article Preview
Top1. Introduction
Web services are being increasingly used to integrate enterprise systems, linking complex applications in large-scale organizations and supporting critical business-to-business interactions, where the typically heterogeneous environments frequently demand a strict definition of service interfaces and interaction patterns. In such heterogeneous scenarios, systems designers frequently opt for using web services technology, as it was created with the key goal of supporting the inter-operation between different systems, including systems built using different programming languages (Erl, 2005).
In a typical services environment a service provider announces its interface using a WSDL document that describes, in a programming language agnostic way, the operations available to the clients. In turn, clients make use of the interface description to understand how the service operations can be invoked (Curbera et al., 2002). Nowadays, developers do not need to implement all supporting code for generating services or invoking operations, as most web service frameworks (platforms for creating, deploying, and invoking web services) provide automatic code generation facilities and runtime support for invoking service operations (Hewitt, 2009). The problem is that, although web services are supported by machine independent protocols and have been designed with interoperability in mind, practice shows that it still is quite difficult to link distinct applications. This is especially true in complex and more heterogeneous scenarios, such as the ones frequently found in enterprise environments.
The interoperability of web services is an issue in which the Web Services Interoperability Organization (WS-I) (Web Services Interoperability Organization (WS-I), 2002) has been working for several years. However, practice shows that developers still struggle to deploy services that can fully inter-operate with client applications. In fact, developers many times create and deploy their web services expecting the underlying framework to provide full interoperability, which is not always the case. Our tests, presented later in the paper, confirm this scenario, showing that the inter-operation between different frameworks is not yet fully achieved and highlighting many cases where inter-operation is not possible.
A key problem is that, although efforts have been undertaken towards creating tools to test services (Eviware, 2011, WS-I, CrossCheck Networks), they appear to be quite limited, when it comes to interoperability testing. Among all tools, those provided by the WS-I Testing Tools Working Group (“WS-I,”) are definitely a step forward, but experience suggests that even WS-I compliant services may show interoperability issues. Thus, there is a clear need for a specialized approach for interoperability testing that helps developers conducting broader interoperability assessments, from a practical perspective.
We presented a tool for interoperability testing of web services in (Elia, Laranjeiro, & Vieira, 2014b). In (Elia, Laranjeiro, & Vieira, 2014c) and (Elia, Laranjeiro, & Vieira, 2014a) we have conducted experiments regarding part of the full inter-operation process (which in the end involves communication). In this paper we greatly extend the previous work, by having refined the approach and formalized key aspects, extended the approach to now include the exchange of messages between client and server, and by augmenting the tests and tool implementation to cover the approach extension and thus covering the whole inter-operation process.