ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
If you have the resources (i.e., time, money, and patience) during a testing phase, try to push the limits of Web services in the context of your own organization. This means, for example, that you set up a pilot or trial program where users must connect with the Internet, fire up a Web-services-based application, have it find the UDDI service with the appropriate Web service, load it, and then run it — all within a period of time in which the user doesn’t begin to twiddle her thumbs and think about how she’s going to complain to the support group. Push this envelope; don’t just massage it with simple programs and cozy situations. An aggressive testing posture is necessary because there are weaknesses in both the theory and the protocols behind Web services that must be uncovered if they will affect applications.
Here are some questions we feel deserve close scrutiny and careful planning:
- What parts of existing programs lend themselves to a Web service? Not all applications should be part of a distributed scenario — especially those that require tight security or are relevant to a single campus.
- Where is the data involved? Most Web services must tap into or contain data. This is not always easy to arrange in a far-flung distributed application environment.
- Where and how would you list a Web service with a UDDI server? Access to appropriate servers, which may need to be your own, can be critical for some Web services (and also part of the performance issues).
- Are there potential bottlenecks in the performance of your Web services? Performance may be a major issue if user download is lengthy or coordination of multiple services is required.
- Will you charge for the Web service, and if so, how will the money be collected?
- What security issues are involved? Most standards in this particular area are still on the drawing board.
