Development Test procedure

We design two types of test procedures, i.e., connecting mode and debugging mode, for the proposed intermediary testing harness. The connecting mode verifies messages at their arrival, while the debugging mode verifies all the messages after the test procedure is over. Therefore, in the debugging mode test assertion steps are presented at end of test procedure, while in the connecting mode test assertion can be presented at any position.

V.4.2.1 Connecting mode

The connecting mode first verifies that an application (i.e., the driver application) conforms to implementation specifications and, if passed, dynamically verifies that the other application (i.e., the responder application) well interoperates with the driver application. This mode is desired when a tester (e.g., application developer) is not certain that the applications are implemented in accordance with specifications. In the other words, it defers the second loop of test until the driver application complies with the specifications. As shown in Figure V-9, a test case (of a one-cycle test) consists of two conformance cases. The second part is invoked only when the driver application passes, at least, the mandatory verification conditions in the first part. This mode is beneficial in such a case that the driver application is correct and the responder application is suspicious, because the developer needs only to repeat the second part with the same output message A instead of repeating the whole test procedure.

Figure V-9 Test procedure for the connecting mode

V.4.2.2 Debugging mode

For the one-cycle test, the debugging mode verifies both applications after a test is over, so that it has only TestAssertion steps at the end as shown in Figure V-10. The purpose of this mode is to identify the causes of interoperability problems, if any, with specification-compliant applications. That is, this test case is desired when both applications have already passed a set of conformance tests. This mode is likely to support a deferred test that verifies messages after monitoring for a while.

Figure V-10 Test procedure for the debugging mode

V.5.

Case Study

An illustrative case study is to verify secure messaging between web service applications. For secure messaging, an enterprise never sends a message without encryption, so that counter enterprises must be able to decipher the message. We consider two web services for this case study: one service prepares a SOAP message containing an order (i.e., Figure V-11.A) and encrypts the message body (i.e., Figure V-11.B), and the other service receives and decrypts the message (i.e., Figure V-11.C) to transfer it to its internal legacy system. For this test, both web services are configured according to the RAMP (Reliable Asynchronous Message Profile). The test scenario is as follows: 1) the testbed sends an unsigned plain SOAP message to the encryption web service, 2) the encryption web service returns a signed and encrypted message (according to the WS-Security policy in Table II-1) to the testbed, 3) the testbed verifies the encrypted message and transmits it to the decryption web service, 4) the decryption web service decodes and returns it to the testbed, and finally, 5) the testbed compares the decoded message with the original SOAP message. Figure V-11 succinctly illustrates parts of SOAP messages. The original SOAP message (A) encapsulates an order element (as its body) to be encoded in EncryptedData (i.e., CipherValue) as shown in the message (B). In addition, the decrypted message

(C) is same as the original message (A), except a list of namespaces. This shows the web services using the same security policy in Table. 1 are interoperable. If the encryption web service, for example, uses a different encryption algorithm, the testbed can neither identify ‘http://www.w3.org/- 2001/04/xmlenc-#aes128-cbc’ as the encryption algorithm in the message (B), nor correctly decode the encrypted message. On the other hand, if the decryption web service uses other algorithm, either the service fails to decode the message (B), or the returned message (C) is different from the original message (A). For these cases, the proposed testbed has correctly detected the problem sources, but KorBIT gives no clue about them. For the second case of incorrect encryption, a test case in the connecting mode can early detect the problem and prevent an interoperability problem from occurring before connecting two web services. However, this requires much more verification capabilities than the debugging mode does. Therefore, easy augmentation of testing, especially test assertions, is urgent

Table V-1 Example of WS-Security policy

Use Algorithm URI

Canonicalization http://www.w3.org/2001/01/xml-exc-c14n#

Signature http://www.w3.org/2000/09/xmldsig#rsa-sha1 Digest http://www.w3.org/2000/09/xmldsig#sha1 Signature http://www.w3.org/2001/04/xmlenc#aes128-cbc Key Encryption http://www.w3.org/2001/04/xmlenc#rsa-1_5

(A) Original SOAP message

<soap:Envelope …> … <soap:Body wsu:Id="Id-e13ec37a-03ec-4041-a5ef-313f43af91d2"> <order/> </soap:Body> </soap:Envelop>

(B) Encrypted SOAP message

<soap:Envelope …> … <soap:Body wsu:Id="Id-e13ec37a-03ec-4041-a5ef-313f43af91d2"> <EncryptedData …> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/> <CipherData><CipherValue> /Mt2HoerdxgyZMrXYoQbV9KEoT0N+L4f0YSLqxI0xfyipmolYK9lT … </CipherValue></CipherData> </EncryptedData> </soap:Body> </soap:Envelop>

(C) Decrypted SOAP message

<soap:Envelope …> … <soap:Body wsu:Id="Id-e13ec37a-03ec-4041-a5ef-313f43af91d2"> <order some-namespaces /> </soap:Body> </soap:Envelop>

Figure V-11 Exemplary SOAP message encryption and decryption

V.6.

Chapter Summary

This Chapter showed that ATF can be adaptively implemented for both the conformance and interoperability testing harnesses which are representative testing approach for B2B/B2C standards. And it presented a novel interoperability test harness that makes up for the weak points in the existing test frameworks. The proposed test harness advances the IIC (KorBIT implementation) interoperability test harness for effective verification and debugging of interoperability problems between B2B applications. For this purpose, the testbed successively executes separated output- and input-conformance tests. We also introduced two test procedures for the proposed interoperability test harness.

VI. CASE STUDY – INVENTORY VISIBILITY AND