Before enabling your Web service for public access, you should test it by building test clients to access it. To begin writing a client, you need the WSDL file. When you define an OpenEdge Web service in ProxyGen, you can select an option to have ProxyGen generate a test WSDL file. You should build your initial test clients using only the information provided in the WSDL. Starting from this information enables you to identify what other documentation users who are building clients without intimate knowledge of your application might need.
Here are three common examples of how client toolkits work:
Microsoft® Visual Studio — Adds a Web Reference that points to the WSDL to your .NET project. Visual Studio creates proxy code from the WSDL and stores the proxies in a References file. When you reference the Web service in your code, Visual Studio offers these proxy objects as appropriate. See Developing a .NET Client to Consume OpenEdge SOAP Web Services for detailed information on creating .NET for OpenEdge Web services.
Apache® Axis — Runs the WSDL2Java command on the WSDL. The command generates the proxy code in several packages in the current directory. See Developing a Java Client to Consume OpenEdge SOAP Web Services for detailed information on creating Java clients for OpenEdge Web services.
OpenEdge — Uses the WSDL Analyzer. The WSDL Analyzer outputs a series of HTML pages with sample code for invoking the Web service's operations.
Caution: You should test a Web service by deploying it to a WSA instance that is isolated from the intended client domain. This allows you to enable the Web service for access by clients doing preproduction testing without making it visible and "live" to production clients. Once testing is complete, you can redeploy or import the Web service to the context of the production WSA instance.