7.3 A predeployment checklist for Web services

Despite the allure of being considered the latest and greatest in software development methodology and the fleeting fame of once having been hailed as the next big thing on the Web, one should never lose sight of the fact that Web services, in the end, are still nothing more than another incarnation of client/server technology. Consequently, though one may want to believe that things must be different and more difficult, in reality all of the deployment- and management- related issues that pertain to application scenarios involving Web services are no different from those that apply to any other client/server configuration. Distributed computing is not new, and the vanguard of today s systems can be traced back to the mid-1960s. The advent of PCs in 1981 accelerated the interest in client/server in relation to worldwide commerce, and to this end it is worth noting that IBM s SNA-based LU 6.2 advanced program-to-program communications (APPC) was introduced in 1982 for mainframe-to-PC applications around the same time that UNIX distributed computing was making a name for itself.

Control, or to be precise who controls what, is the one area where the Web-services picture differs , in general, from most previous client/server permutations . In the past the client/server model was typically used in what would now be referred to as intranet/extranet configurations. All the software, both on the clients and the servers, would be under the control of one entity. Though the computing was distributed, the control of the software was centralized. Web services offer an alternate model, though corporations at present are opting to ignore this Internet model and are yet again falling back on intranet/extranet deployments. What is important here is that the deployment- and management-related issue in relation to Web services is still the same as for other client/server implementations .

Prior to the emergence of the Web, client/server implementations enjoyed a star-crossed, checkered history. Hindsight has shown that the total reliance on standards contributed much to the success of the Web model. Web services set out to capitalize on that. So at least in the case of Web services, unlike with enterprise-level client/server solutions as recently as the early 1990s, one does not have to wrestle with network protocol (i.e., IPX, NetBIOS, SNA, TCP/IP, OSI) or network topology decisions. Web services, by definition and design, will be standards compliant and as such conform to a consistent networking profile. This means that network compatibility issues, for a change, will not require much debate. One should thus be able to quickly tick off the SOAP, WSDL, etc. related concerns and devote more attention to the other issues.

Given the client/server nature, there will always be two separate sides to be considered for all of the deployment- and management-related issues ” with overlap from both sides to cover the network interface as well. As discussed in the preceding sections, most enterprises will already have a firm handle on the issues pertaining to the calling application side, given that this is the driver s side of the equation. Enterprises will already have experience with selecting, deploying, maintaining, and managing applications. It is the external, outside-the-firewall Web-services aspect that will be alien ” and as such will demand attention. The issues, as with other client/server software, that one should focus on at this juncture include:

Pricing and licensing
Service-level agreement, which covers availability, performance, and scalability (e.g., one-second turnaround time, 20 transactions per minute, etc.)
Maintenance contract, which deals with how any problems with the software will be handled, including how problems will be reported and escalated, whether there will be a charge for problem resolution, testing of the fix, end-to-end change management, and so on
Liability protection, particularly against bad data, data interception by employees , unauthorized use of information, and use of unauthorized software (e.g., copyright violations)
Upgrade policy covering notifications, regression testing mechanisms, and cut-over procedures
Long- term indemnification, if applicable (e.g., source code deposited in escrow)
Platform selection
Assignability ”that is, options in the event of a merger or acquisition, and whether the software (i.e., the Web service) or the operation of that software can be sold to another party during the period of the contract
Privacy policy and guarantee
Security safeguards, including intrusion detection ( especially in the context of a platform being compromised)
Load balancing and failover configurations
Disaster recovery scenarios
Intellectual property issues and waivers
Marketing and publicity rights ”e.g., service providers wishing to publicize that so-and-so uses their xyz Web service
Management of the software covering change management, problem management, performance management, network management, and gateway (e.g., XML application firewall) management
Usage monitoring and reporting

Of these, the pricing and licensing of Web services are likely to prove to be the most intriguing. Way back when Web services were first being bandied around, there was an implication that many services would be available on a no-charge, freeware-type basis. This could still prove to be the case, though IT professionals have known from the start that most Web services they would wish to use or, conversely, offer to others are likely to have some cost and licensing associated with them. To this end, Microsoft s statement (reproduced here) as to how one can go about purchasing its trend-setting MapPoint Web service offers a glimpse of how the pricing model will evolve :

Customers purchase the MapPoint Web Service as an annual subscription direct from Microsoft. There are two primary licensing models:

Per user is for known user applications, such as within a call center or fleet tracking applications

Per transactions is for anonymous user applications, such as a Web site locator or travel portal

Pricing is dependent on the numbers of users and/or transactions you purchase. More information can be found on http://www.microsoft.com/mappoint/webservice/howtobuy.mspx .

Suffice to say that the pricing model for Web services is at present in an embryonic stage, with most people, quite rightly, still focusing their attention on the technical side of things. IBM, a major shaker and mover when it comes to Web services and a company that knows a thing or two about complex, usage-based pricing models, has to its credit already started publishing position papers about possible accounting and metering schemes for Web services. Microsoft is already espousing usage-based pricing. What is abundantly clear is that there will be a very wide spectrum, ranging from freeware to expensive, premium offerings coupled with many permutations, in the case of the nonfreeware offerings, as to how the pricing will be structured.

The pricing options available will definitely include one-time charge schemes, periodic licensing (e.g., monthly or yearly), and umpteen usage-based options. In addition, it is likely that there could be third-party Web services distributors ”though the inherent dynamic discovery capability of a Web service dilutes some of the potential value that can be offered by a distributor. In the case of Web services the main value that a distributor is likely to provide is that of handling the billing and collection. Indubitably, there will also be syndicated Web services. Figure 7.11 sets out to highlight some of the possible pricing models that will be available for Web services, depending on who is offering the service.

Figure 7.11: Some of the possible pricing models for Web services, depending on their source.

The implications of other items in the preceding list should be self-explanatory, but the management-related issues are elaborated below. As with security, how one would go about addressing each of the items in this list will depend and vary on a case-by-case basis. There are no hard-and-fast rules that will cover all instances. Remember that just because we are dealing with a new software methodology does not mean that the famous French adage plus a change, plus c est la meme chose (the more things change, the more they remain the same) ceases to apply. The software-related issues, such as failures, upgrades, change management, and intermittent slowdowns, will still be the same.