News Stay informed about the latest enterprise technology news and product updates.

Top 10 tips for trusted Web services

Third party collaborations increase dependency and risk. Microsoft seems to have learnt this lesson the hard way, as they back off plans to become the ultimate intermediary. But in the same week where we can all observe Web services concepts gaining real momentum, there are really important lessons on how to get the benefits from web services without the pitfalls. You have to implement system designs that deliver trust. We provide 10 tips on best practices in trusted services.

Analyst Commentary
Top 10 tips for trusted Web services

There have been huge numbers of Web service related press releases and stories this week from all manner of companies, including platform vendors, package vendors, EAI and other ISVs, and perhaps more interestingly, a number of end-user organizations announcing their Web service strategies. There is no doubt now that Web services are here to stay.

Is Microsoft backing away from consumer WS?
Yet over the past week, the newswires have also been humming with the story that Microsoft has quietly dropped its plans for MyServices, the appropriately stormy project, code-named Hailstorm, that was planned to provide a wide array of Web based personal services ranging from single Web sign-on through personal data storage.

Although there has been no official comment from Microsoft, informed sources indicate this is fact. However there is much confusion over exactly what this means, and whether the new strategy is simply to provide a platform for others to offer the common personal services, or whether there is some element of a Microsoft (probably MSN) operational role, as a peer partner with many other federated partners. Whilst we hate to say "we told you so", it gives us no pleasure to point to our reports published last April where we told Microsoft that there were fundamental issues with data protection, federation and service level commitments.

Third parties increase dependency and risk
The issue is that in this early stage of Web services, there is insufficient trust, not just in Microsoft although that is a significant factor, but in third party roles in important transactions. Life is difficult enough without creating complexities and dependencies that are almost certainly going to degrade service levels. Companies don't want to involve third parties that not only create a service level risk, but also create a potential barrier to acceptance that will impact the all important supplier customer relationship.

Of course much has been made of Microsoft's ability to use its power to leverage its role of intermediary and even the stored personal data. And despite vigorous denials and assurances the major corporations are clearly in no mood to embrace high risk concepts.

This is really the core issue, and it is not new. The ASP market largely failed because potential customers chose increased cost in preference to increased external dependency and loss of control. So how do you, and indeed Microsoft and all the other Web service platform providers make it work this time? Because, make no mistake whatever you read, this wasn't just about Microsoft. All the Web service providers face the same issues, and their revenues are impacted equally by enterprises unwillingness to embrace new concepts and technologies.

Finding practical strategies
The answer is that Web services are an evolving concept and everyone needs to adopt practices that reflect the practical situation. Also remember that Web services can be used in a huge range of applications, (see the CBDi Pattern Catalog) and it makes sense to choose those that you can control. Further it is really important to differentiate between the proximity of the relationship between provider and consumer. This is one of the key factors that determine the trust model required. The "system" design is going to be very different between known, trusted partners and anonymous parties.


1. Start thinking services. Expose service level designs and interfaces with relevant publishing and discovery mechanisms. "Web" services will follow naturally.

2. Focus on integration benefits. To achieve maximum benefit for minimum risk, work to reduce the complexity of custom (protocol and semantic) adaptors and implement service level interfaces that will be more easily adaptable to changing circumstances.

3. Use Web services internally to achieve the flexibility and choice that comes from service based systems. Whilst trust issues don't go away entirely, it is undoubtedly easier to control the overall integrity behind the firewall, or within existing trust mechanisms. Prepare for when the time is right for external use.

4. Understand the difference between a) known and trusted, b) ad-hoc and c) anonymous providers and consumers. Be prepared to put temporary proprietary protocols in place with close partners where it is easier for you to reach agreement.

5. Assume Web services do NOT have 100% availability. Classify Web services by availability requirement. Implement pragmatic backup strategy by class of service. Remember the result is likely to be superior to what you do today. If not, don't do it.

6. Where the service requires it, provide suppliers/customers/partners with alternative services that are dynamically switchable. Alternatively plan for degraded services if possible or at least graceful degradation. Contract with duplicate services where non-availability would hurt.

7. Provide customers/partners/suppliers with back up systems as appropriate choosing between the expensive real time mirroring backup systems and cheap periodic publish and subscribe systems.

8. Include service level guarantees with the "product" contract as part of the business deal.

9. Concentrate the operational platform for (external) collaborating services on a common ASP platform that can provide common SLA's.

10. Remember that intermediaries are often better placed to provide reliable, trusted services than end-user organizations. Specialist intermediaries are fundamentally set up to offer service guarantees to others. End users are not.

In our various reports on trust, we have emphasized the importance of viewing trust in a holistic fashion - trust includes security but also integrity and reliability. It is a natural response to uncertainty to increase the levels of control that your own organization exerts. Yet in the case of services the counter intuitive answer may often be preferable.

We infer that Microsoft's decision on MyServices is actually a difficult, but sensible response to practical reality. Whilst they may consider that they are perfectly capable of delivering the quality of service necessary to establish trust, right now potential service collaborators and consumers do not yet have the confidence to incorporate even trusted third parties in their business critical processes. With time and good experience that will happen, but we need to undergo a collective learning experience before then, at both a generic and the specific brand level.

Web services are not a "one size fits all" solution. In fact finding good "system" designs that capitalize on the opportunity whilst delivering trusted services will mean considerable compromise. But as always, for the brave there are great opportunities.

Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.

For More Information:

  • Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
  • Visit our Best Web Links for Web Services for hand-picked resources by our editors.
  • Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
  • Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.