 | |||
|
Wednesday May 29 2002 Web Services Architect Review One year on from its inception, Web Services Architect takes another look at Web Services, drawing on movements in the industry and valuable feedback from the people who matter the most - our audience. An update, if you will, to our view of Web Services. What do we mean by Web Services? Web Services is a term that has come to be used in many contexts, although most people tend to stick with one definition. Initially, Web Services meant services that were used over the Web (no surprise there), and was intended to encompass such things as applications distributed across the network, dynamically brought together at run-time. This was soon recognized as hopeful at best, misleading at worst. There was, nevertheless, interest after some of the initial hype died down, and people began to look rationally at what they could do. Web Services are in essence a collection of standards and protocols that allow us to make processing requests to remote systems by speaking a common, non-proprietary language and using common transport protocols (HTTP, SMTP). Problems Facing Web Services So, if Web Services are so great, why aren't more people using them? For one thing, a lot of the coverage that Web Services have received has clearly been hype - like the dynamic discovery of an entire application from distributed sources across the Internet. Another important reason why people aren't using Web Services more is that they are still a relatively new technology. One possible reason Web Services seem to have sprung up overnight is because they are one of the core elements of the new Microsoft .NET Framework strategy. The idea is that remote applications will use XML to communicate with central systems, leaving the developer free to write in the language that is best suited for the job in hand. Unfortunately, a lot of people aren't that interested in the first release of a Microsoft product, claiming that they'll wait until version 1.1 or 2.0 comes out - 'giving them time to iron out the bugs,' an attitude developed from experience of first release software seeming more like pre-release beta testing. What people think about Microsoft products tends to be symptomatic of the way they think about a lot of software. Few people are willing to take the risk of being the first on the wagon in case it doesn't go anywhere and they can't get off. Despite this, there is slowly increasing adoption of Web Services in the face of the key problems of workflow, quality of service, and most high profile of all, security. How do we combine a number of Web Services into one controlled workflow? Is there a means to link several Web Services into a coherent process? How can we be sure that the Web Services we subscribe to are going to provide what they say they will? Why, or how should we trust dynamically found Web Services to be confidential and secure? Security - the biggest stumbling block Without doubt, the main problem facing Web Services is security. This is true with all software, but since the rapidly growing technology area that is Web Services doesn't yet have dedicated security protocols and standards, it is a more glaring hole. It is, though, a hole that is being filled, with proposals to secure all levels of the communication being presented and submitted; Security Assertion Markup Language (SAML, http://www.saml.org/, or http://www.oasis-open.org/committees/security/), for transferring the security level (authorization and authentication), along with XML encryption and Public Key Infrastructure (PKI), which can be managed by XML Key Management Specification; the security of storage of documents in repositories such as UDDI registries is targeted by Extensible Access Control Markup Language (XACML, http://www.oasis-open.org/committees/xacml/). Interoperability The other main problem with Web Services at the moment are really little more than teething troubles caused by differences in implementations for dealing with the standards. It's faintly ironic that Web Services, often touted as the cheap and easy way in deal with integration and system interoperability should have interoperability problems of their own. Essentially, at this relatively early stage of development we have different vendors doing the same thing in different ways, each requiring a slightly different set of elements. As with security, though, this shouldn't be seen as a long-term problem. The amounts of money invested in Web Services technologies by IBM, Microsoft, and others, together with previously unprecedented levels of co-operation between these companies should bring the situation to a satisfactory conclusion - eliminating the interoperability problems by settling on one version of the standards. Where are they now? As we've seen, security is being addressed. WSDL is at 1.1 (http://www.w3.org/TR/wsdl, but see also http://www.w3.org/TR/ws-desc-reqs/ for information on Web Services Description requirements) SOAP at 1.1 (http://www.w3.org/TR/SOAP/, but see also http://www.w3.org/2000/xp/Group/ for information on XML Protocol, a potential replacement for SOAP), and there is a host of other specifications being primed or actually submitted for standards approval. UDDI is at an improved version 2.0 (http://www.uddi.org/), although how long it remains of interest as a viable means of discovering Web Services is yet to be seen. Web Services provide a relatively cheap and easy way to
integrate systems, be they internal enterprise applications or business
partner systems. For non-mission critical systems, it is possible to find
replacements for failed Web Services using the dynamic discovery process
of UDDI. Limited numbers of Web Services can be chained together using
WSFL (Web Services Flow Language, Where are they going? The harder task here is to see the future of Web Services. As the security issue is tackled and solved to greater satisfaction, Web Services will begin to move from within the enterprise (EAI) to between enterprises (B2B), and then into areas beyond the enterprise, realizing some of the promise of the early days. Two wrongs don't make a right There is often a tendency to react to an excess of hype with an excess of pessimism. What is really needed is pragmatism throughout, a realistic look at what is possible. The whole process works much better if people take the realistic approach from the start, saying, "Hey, these things are quite good for some things, but not so good for others. They've got great potential, but need a lot of work to realize that potential." We have recently seen a backlash in the community against the early levels of hype surrounding Web Services, which in many respects went too far. In essence, it has moved Web Services from the Peak of Hype to the Trough of Disillusionment, to borrow a term from Gartner. How long it will take them to climb onto the Plateau of Acceptance remains to be seen - hopefully it won't take long. Thoughts for the Future As the market matures, so do people's opinions of it; expectations are brought more into line with increasing technical ability. Further displays of what Web Services can do will reassure people that they are here to stay, and the imminent addition of rigorous security will assuage fears in that regard. The remaining issues to be dealt with are those of how we can trust that the Web Service will do what the publisher says. What guarantee is there of the level of service? What quality can we expect? Once these are ironed out, Web Services will be another tool in the box as architects and developers continue to provide solutions to enterprise computing needs. Keep up to date with all the new articles and features on
Web Services Architect: |
