With the introduction of Visual Studio .NET, consuming Web services in applications is easier than ever. You can employ Web services in any of three scenarios: as a means to share functionality across your corporation, as a means for existing business partners to integrate more readily with each other's systems, or as a means to gain functionality or content that would be prohibitive to build and maintain internally. For Web services falling into the third category, new levels of due diligence and risk assessment are necessary when you assess third-party Web services. This article offers 14 key issues you should explore when deciding whether use third-party Web services (see Table 1).

In the pre-Web-services world, if your component vendor went out of business, you could continue to use the last version of its DLL, JavaBean, or data-access tool. Today, if the Web services vendor goes out of business, your application (and business) could follow closely behind. With Web services, you're not only banking on the functionality the serviced components provide, but you also have major dependencies on the vendor's network infrastructure, staffing, security, and versioning/deployment, and on its business model's financial viability. These additional dependencies in effect change the relationship between customer and vendor to that of integrated business partners and make it crucial to examine closely any vendor whose Web services your organization is considering.

#1 Make Sure You're Compatible
Although compatibility is improving rapidly, you might still encounter some incompatibility between certain Web service server implementations. These incompatibilities occur between different OSs and particular toolsets. Early in the history of Web services, incompatibilities caused some issues, particularly between early versions of the Microsoft Simple Object Access Protocol (SOAP) Toolkit and Apache clients. Although that isn't likely tto be an issue today, if you experience an incompatibility with your development or target platform, you might not need to investigate further, because changing your toolset or target platform isn't usually an option. Ask the vendor to confirm that your OS and toolset/development language are supported, and to provide working sample applications that prove compatibility.

#2 Do a Background Check
Examine the Web service vendor's background. If the company sold DLLs in the past and is repackaging them as Web services, you need to question the Web service's quality. Determine if the Web service is a quick repackaging of a DLL, or if the software was rewritten and designed as a scalable Web service. You should also ask if it's part of an n-tier design created to run under COM+ or WebSphere. This is particularly important because a Web service intended to support a significant request load will need to be tied into a transaction server. Web services need to be designed to scale effectively; simply repackaging existing components can cause the service to buckle under even a modest request volume.