 | |||
|
Wednesday October 3 2001 Where are Web Services Today Establishing Trust in Web Services As the hype surrounding Web Services shows few signs of relenting, people are beginning to ask more searching questions. In this age of rapid communications, particularly apparent in discussion sites and articles posted across the Internet, there are many aspects of Web Services under question:
There are dozens of other questions, key among these, perhaps, is: "Can we really trust Web Services to deliver?" Thus far, there are two main types of answer: the 'ultra positive new dawn of computing' camp, and the 'ask us again in 18 months' camp. Answers from the first camp tend to gloss over the limitations of Web Services, where answers from the latter tend to do little other than say that Web Services will take another 18 to 24 months to mature and leave it at that. In this article, we hope to steer the middle course and treat the subject clearly and in a balanced manner. In order to answer this key question, though, we first need to understand what we are asking. Can we Really Trust Web Services to Deliver? As we focus our attention, we can see two questions emerge, both tightly bound to each other. The first is "Will Web Services deliver?" and the second is "Can we trust Web Services?" As with most questions, a little research is required to answer these interwoven points, so let's start with whether Web Services will deliver. Will Web Services Deliver? Without much doubt, we can say that Web Services will deliver, and indeed are already delivering, although we need to be clear on what is being delivered. As with any new technology, in order to evaluate its likely success, we need to look at what it does, and how it does it. What, then, are Web Services? Essentially, Web Services work by sending messages from one application to another. These messages are formatted using SOAP (Simple Object Access Protocol), an XML language, and contain simple processing information, such as the program to run, along with any parameters. Once the called program has run, it returns the resulting information in another SOAP message, which the calling program will decode and have the answer. It's a bit like playing chess by post - you send your moves to your opponent, who replies with their moves. There are a few other aspects to using Web Services, which correspond to steps you take when using a new application for your computer. Here are the steps:
Thus, we can expose existing application functionality as Web Services, or, which is perhaps better, design and produce functionality for the express purpose of publishing it as a Web Service. In the former case, we would need to provide a wrapper to translate incoming calls from SOAP, and outgoing information into SOAP; with the latter, we would be able to streamline the functionality to deal with the messages itself. In terms of what subscribers can see of your application, they're limited to the contents of the WSDL file that provides an interface. Unless you've done something wrong and expose the wrong parts of your application, there is no need to worry that you are exposing your internal system operations. Securing the messages to and from the subscriber, though, is another matter, as we shall see shortly. In seeing how Web Services work, we can also identify their essential limitations - they are invoked through messages that take time to travel from sender to receiver. Because of this, Web Services lend themselves well to tasks that only require contact to start them, or are not reliant on rapid response rates - you couldn't drive a car at high speed using Web Services, but you could perhaps fly a rocket into space. Using Web Services to acquire anything more than raw data is asking for heavy performance penalties and disappointment. Can we Trust Web Services? So much for the actual Web Service itself, what about the steps needed to use it? As we outlined earlier, we first have to find the service we want, and work out how to use it. This process can be a thorny problem, with trust being a particularly important issue to resolve. Yes, I can find a company that can provide the processing I want for my accounts, exposed as a Web Service; Yes, I can work out how to invoke the service; What I don't get from the UDDI registry and WSDL files is who the people I'm dealing with really are. All I get is an outline and contact details - the Web Service itself won't tell me any more about them. The situation is similar from the other end - a company decides to expose some of its internal application as Web Services. They create the necessary files for the UDDI registry, write the WSDL file to explain how their Web Service works, and then wait. But then who among the potential users will the company trust? What is to prevent, say, an international drugs cartel from using a legitimate banking Web Service to launder their money? What if I developed a neat little program that provides some processing that a lot of people will need, will anyone want to use my Web Service? Will I want them to use it? Will I know who is using it? I might want to publish a Web Service that provides something that is legal where I live, but not legal in other countries - how then will I know who is using it, and how can I trust that they are not breaking the law where they live? The issues of trust and security are tightly bound in the minds of consumers - let's take a look at online banking as an example. I would trust, say, the HSBC to conduct my online banking in a secure and responsible manner, because they have a massive physical network of banks and have been in the financial market since 1865. On the other hand, I probably wouldn't entrust my current account or my savings to "Escobar and Noriega Online Accounts", a newly launched initiative with no obvious connections to any legitimate business. The point here is that as Web Services begin to get a foothold in electronic business, critical (expensive) services will probably be limited to extensions of pre existing business relationships with already trusted companies, leaving non-critical (cheap) Web Services in the domain of casual or unknown publishers. How can two companies establish a relationship of trust in order to share Web Services? They have to meet in order to agree other types of relationship, and so they would almost certainly want to do the same for a Web Service relationship. UDDI, WSDL, and SOAP say nothing about this. Thus, although it would be possible to find a Web Service to use just by flicking through a UDDI registry, the chances of it being used immediately are fairly slim. We come back to the point just made - critical Web Services will initially be found in the context of existing business relationships. Security - Establishing Trust in Web Services So, we establish a trusting relationship with our Web Service provider or subscriber, but they aren't the only parties we need to trust. We also need to trust a great many other people, most of whom we will never meet. In short, we need to be able to trust both everyone responsible for the communication networks we use to pass our SOAP messages around, and everyone else who uses the same network. This is where security comes in. We have to look at how to prevent malicious or unauthorized use, how to provide visibility and monitoring, and how to coordinate security policy with partners, and there are only a few solutions available as yet. XKMS (XML Key Management Specification), currently under consideration by the World Wide Web Consortium (W3C), seeks to provide some key based security; XML Signature, in a similar position with the W3C, is aiming to provide a means to create a secure signature in XML, to represent a given company; SAML (Security Assertion Markup Language) is an existing security standard for exchanging authentication and authorization information, based on XML. If you don't want to implement so many standards (most of which aren't yet mature enough to be really called standards), you could always rely on a Web Services Network to provide your security. Grand Central provide one such offering, which encompasses the three aspects of securing Web Services outlined earlier; Flamenco Networks also has a Web Service Network for you to secure your Web Services exchanges with partners. Whether using the XML based security measures raw, or taking advantage of security features built in to Web Services networks, you still need to be speaking the same language as your potential partners in the Web Services world - great as a Web Services network may be, it's no good if your partner is a part of it as well. A third solution to the security issue is the use of Microsoft's Passport. Although Passport, an integral part of .NET My Services formerly HailStorm, supports the Kerberos 5.0 standard, it does so in a non-standard way by embedding the username in the returned certificate. Passport, Microsoft's universal digital identification document, only provides authentication of user credentials - if you wanted to support different users with different levels of authorization, you would have to find some other solution. Newly emerging is The Liberty Project (http://www.projectliberty.org/), an industry consortium composed of Sun, NTT DoCoMo, Nokia, and the Apache Software Foundation among others. This seems to be a direct competitor to Passport and .Net My Services, based on open standards and participated in by many companies. Why Use Web Services Having looked at how Web Services work, we can use this knowledge to provide a list of capabilities from the perspective of the consumer:
Some of these points may not be immediately apparent from the little we have said about how Web Services work, so we should allow a little explanation before moving on to look at the drawbacks. The seamless embedding of functionality refers to the fact that with Web Services, we can pull information from across the world into our local application, without the user ever knowing where it comes from. Thus, for example, in a bank we have a spreadsheet with foreign exchange rates in several cells; these rates are updated every ten minutes, although the user neither knows nor needs to know that it comes via a Web Service from Reuters (say). The other points all arise from the same basic fact - Web Services can be tailored to provide very specific functionality. In the case of a company infrastructure, the service can be hosted in a central location and 'tapped into' from offices across the country. This means that an accounts package need only be developed once for the company, perhaps by external contractors chosen from among many, thus saving development time and money. This will also reduce the expenditure on support and administration for the software, since it only runs in one location. As well as the technical capabilities of Web Services, there are several important business reasons why their use could be applicable:
Other Limitations to Web Services As we said at the beginning of the article, we aim to present a balanced view of Web Services. With this in mind, let us briefly examine some of the limitations Web Services presently face:
Web Services will only be a viable option for a business if it can find developers to produce the necessary code - this may mean either in house talent, which may not be up to the task, or external contractors, who may be too expensive for some operations. Assuming that a company can find the code, it then has to find the right services, either to subscribe to or to publish. It may be that the Web Services needs of a company are too esoteric for general provision, and they might not be able to find a company who can provide the level of customization required. Web Services may not be the answer if the company has such niche requirements. This problem of matching requirements begs the question "What sort of Web Services should we provide - generic or custom?" There is no right answer to this question - it depends on the nature of the Web Services you will publish. Some services lend themselves to generic purposes, such as accounting services, where others have a much smaller market. Also, if you have a service application that you wish to expose as a Web Service, how much of do you expose? How much of the new application that you are building should rely on Web Services? The granularity of Web Services depends to some extent on what the application is designed for One of perhaps the more important limitations to Web Services is the continuity of supply. How can you guarantee that your Web Service will continue to be available? What degree of 'downtime' is acceptable? How long should the response take? These questions can be addressed, to some extent, by rigorous service agreements, which would need to be checked up on to ensure the quality of service. Some brokerages offer services whereby they measure the reliability of Web Services. Conclusion We have seen how Web Services work, built on a network of XML languages, and looked at some of the problems facing Web Services and how they can be overcome. Ultimately, Web Services look set to stay, and the longer they are around the more sophisticated they will become. Web Services as they stand are limited to little more than raw data exchange, although as we become more adept at manipulating this data, we will see more exciting Web Services. Similar articles: Keep up to date with all the new articles and features on
Web Services Architect: |
