Hi all,
we’re trying to smoothly introduce a SOA stack in our environment, starting from exposing some ws with webMethods.

As the first step, we’re producing some WSDL file for some of our flow services. We have a standard three-level env arch (DEV-QA-PROD), and we will release 3 WDSL files, one for each env, so that our clients will be able to generate a java client from this WSDL.

The problem is: how to handle code quality check in this situation? I mean, the client generated for QA won’t be executed until the other env will be in QA, without test the generated code in DEV, and the same will happen in QA->PROD.

How do you solve this situation? We dont like to let only on ws (the PROD one) to be available for DEV/QA/PROD, but we’d rather have different ws (since they are on different IS) for every environment.

Thanks in adavance,
Sandro

Sandro, I’m not sure I understand the question. Are you trying to determine how to test the webM-hosted web service from the generated client, and you are concerned that you will have to test all three environments simultaneously? Can you provide more detail?

Sorry, I supposed to have it explained correctly what’s in my mind…

From wM point-of-view, I’m sure that the same service available in DEV will be in QA & PROD (since I’ll publish patch from DEV to QA and then to prod).

What I’m scared is the client POV (for example a Java application that will use my service): How can I garantee that the client generated for the PROD WSDL it’s working fine without testing it directly in PROD?

I can generate, all the 3 different clients (for DEV, QA & PROD) in DEV, and moving upwards, I’ll use the client for the right env, bu I can test it only in that env, not in the lower one… So I’ll arrive in PROD without testing the code!

Thanks,
Sandro

If I understand you correctly, the only difference between three WSDL files is the SOAP endpoint (URL). The service consumer would not typically regenerate code to invoke the service in each environment, but generate the code once in development, externalize the endpoint URL as a parameter and then promote the code to QA and PROD. The properties file containing the endpoint URL would be changed and deployed into each environment.

Some service consumers use a dynamic binding approach to generate code at runtime. There are many dangers to this approach and usually less than optimized performance. Of course, the additional challenge is that you can never be sure that code generated from a WSDL in one environment might be the same as that generated in another.

Lastly, you can’t count on your service consumers to test your web service-based interfaces for you. It is essential that you use one of the many web services / SOA testing tools available today such as those from Solstice Software, Mercury’s ServiceTest, ParaSoft’s SOATest, CrossCheck Network’s SOAPSonar or ITKO’s LISA.

HTH,

Mark

What Mark says.

Seriously, removing the endpoint from the wsdl is a reasonable mechanism (for either genericizing the client code, or for security purposes). This means the generated client must then have the endpoint added (via properties file as Mark suggests) - so the same code could be used to test in dev and qa, and then the endpoint changed for prod when ready for production use.

You’ll have to edit the WSDL manually to remove the endpoint URL or to replace it with some placeholder value.

An even better approach is to create your WSDL manually using a tool such as XML Spy Enterprise. That will allow you to create modular WSDL service descriptions that import XML schemas containing the request and response messages for each operation. You get nice, clean WSDL’s with names that you chose and which have a hope of meeting WS-I interoperability tests (unlike ones generated from IS).

Mark

To solve this issue we created a production DNS entry, then in our dev and test environments we use host file entries to override the DNS entry.

Hope that helps

what we did was we had the URL as one of the fields in the TPA. And our configuration management procedures consider TPA editing as updating any other id/pwd etc for production movement. I understand the same might not be true for you. So when you are packaging from one environment to the other you could change the values and package.