November 19, 2013 | Written by: Rene D. Svendsen
Share this post:
The characteristics of asynchronous web services using multiple connections are that a consumer establishes a connection to a provider, issue a service request, the provider acknowledges the request was received (this part is optional), and then the connection between the participants is closed. Once the provider has completed processing, it will establish a new connection to the “ReplyTo” address, specified by the consumer in the original service request, send the response, and close the connection.
Asynchronous web services are typically used to build highly decoupled, highly scalable and fault tolerant systems. Hence, it is not uncommon to see this method used in mobile and polling solutions.
So, why is it more cumbersome and time consuming to establish a test environment for an asynchronous web service?
The challenge is in the second (response) connection being initiated by the provider to the consumer. This can cause the IT security department some headaches. Not so much in the production environment; true, they will need to maintain rules for the service connection to the “ReplyTo” address specified by the consumer, but that is nothing compared to the discussions you will engage in when you attempt to set up an external test environment that will allow your partners to test the new service.
Let’s say your in-house project test team wishes to use a workstation based test tool, such as SoapUI or IBM Rational Functional Tester.
Illustration 2 shows three different scenarios. The upper right and lower right solutions will work. The two on the left would not, as it would require a the provider in the unsecured network should be able to establish a connection to test workstation(s) on your, and your partners’, secure networks.
But, if you have partners who also need to test, they will face the same problems as you; that is, they will need to place a test workstation in a unsecured network.
Would it not be easier (and faster) if you could establish a set of test workstations, with permanent TCP/IP addresses, for your own testers and your partners externally to your (and your partners’) secure networks? This would eliminate a lot of discussion between you and your IT Security department, not to mention the partners’ network teams and their IT Security departments.
Join me @rdsvendsen on Twitter to discuss what benefits you see in your experiences, and your doubts about moving testing “into the clouds.”