Article Preview
TopIntroduction
Quality-of-Service (QoS) features such as security and reliability are brought to the Web Services world by the so-called WS-* standards. WS-Security 1.1 (OASIS, 2006) and WS-ReliableMessaging 1.2 (OASIS, 2009a) are prominent representatives of WS-* standards that define data formats and processing instructions for extending the SOAP (Gudgin, Hadley, Mendelsohn, Moreau, Nielsen, Karmarkar, & Lafon, 2007) messages that implement Web Services exchanges. For example, an XML Signature tag together with SignedInfo, SignatureValue and KeyInfo tags would have to be inserted into the SOAP Header tag to provide integrity protection. For convenience, a Web Services developer is not supposed to ‘manually’ insert all that information into SOAP messages. Instead, Web Services Security Policy 1.3 (WS-Sec-Pol; OASIS, 2009b) and Web Services Reliable Messaging Policy Assertion 1.2 (WS-RM-Pol; OASIS, 2009c) can be used to extend the WSDL definition of a Web service with assertions that instruct the Web Services stack implementations (WS stack in the following) in use to apply WS-Sec and WS-RM features to the SOAP message exchanges. This policy-based realization of QoS features for Web Services has been postulated in several publications (Martino & Bertino, 2009; Gruschka et al., 2006, 2007; Curbera et al., 2008; Khalaf et al., 2006; Nezhad et al., 2006; Menzel, Warschofsky, & Meinel, 2010) and promises better interoperability than letting all Web Services developers implement QoS features their own way.
On November 10th 2010, the Web Services Interoperability Organization (WS-I) released a press announcement (Cassidy, 2011). This announcement followed the release of new versions of WS-I’s core deliverables, most notably the Basic Security Profile (BSP) (WS-I, 2010a) and Reliable Secure Profile (RSP) (WS-I, 2010b) in 2010. WS-I profiles are the core deliverables of WS-I and document “[..] clarifications, refinements, interpretations and amplifications of those specifications which promote interoperability” (WS-I, 2010b). The main target of BSP and RSP are WS-Sec and WS-RM. As WS-I promotes interoperability and has declared its standardization work to be completed, this means that Web Services adopters should be able to rely on the interoperable implementation of Web Services security and reliability features which are pivotal for Web Services according to Nezhad et al. (2006) and Moser et al. (2007). However, WS-Sec and WS-RM as well as WS-Sec-Pol and WS-RM-Pol are highly complex specifications so that interoperability across WS stacks does not come easy. Consistently, Martino and Bertino (2009) stress that “although one of the main purposes of the standard [i.e., a WS security standard] is to guarantee the interoperability between different platforms, it might be necessary to test it on the field.”
This paper investigates in how far WS-I’s work has led to interoperability across WS stacks regarding the implementation of WS-Sec(-Pol) and WS-RM(-Pol) and whether real-world functionality is available. In order to operationalize the question whether or not a Web Services adopter can rely on interoperability between different WS stacks, we use two ‘optimistic’ hypotheses:
H1:The overwhelming majority of WS-Sec-Pol/WS-RM-Pol features are implemented by Web Services stacks;
H2:Out of those WS-Sec-Pol/WS-RM-Pol features implemented by two platforms, the overwhelming majority is implemented in an interoperable manner.