Problem testing asynchronous web services? Try cloud!

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.”

More stories

Why we added new map tools to Netcool

I had the opportunity to visit a number of telecommunications clients using IBM Netcool over the last year. We frequently discussed the benefits of have a geographically mapped view of topology. Not just because it was nice “eye candy” in the Network Operations Center (NOC), but because it gives an important geographically-based view of network […]

Continue reading

How to streamline continuous delivery through better auditing

IT managers, does this sound familiar? Just when everything is running smoothly, you encounter the release management process in place for upgrading business applications in the production environment. You get an error notification in one of the workflows running the release management process. It can be especially frustrating when the error is coming from the […]

Continue reading

Want to see the latest from WebSphere Liberty? Join our webcast

We just released the latest release of WebSphere Liberty, It includes many new enhancements to its security, database management and overall performance. Interested in what’s new? Join our webcast on January 11, 2017. Why? Read on. I used to take time to reflect on the year behind me as the calendar year closed out, […]

Continue reading