7.6 QA: A time to recap and reflect

7.6 Q&A: A time to recap and reflect

	Q: Have corporations had a change of heart when it comes to Web services?
	Q: Is security an insurmountable issue when it comes to Web services?
	Q: Is adequate security technology currently available to make remotely invoked Web services viable ?
	Q: Is it possible to locate, evaluate, license, and start using a Web service, all on the fly, over the Web, similar to buying and downloading a virus protection subscription online, using a credit card?
	Q: What are digital certificates?
	Q: What is the role of SSL in relation to Web services?
	Q: What are the new security standards being developed for the Web-services arena?
	Q: Is it possible to have Web services that are not deployed on Java or .NET platforms?
	Q: What are the potential pricing models for Web services?
	Q: Is management going to be an impediment to the deployment and use of Web services?

Answers

	A: Yes and no. The technological underpinnings of Web services and their potential when it comes to developing new enterprise applications are essentially beyond reproach and are not in question. However, the overall climate of distrust and security- related paranoia that has permeated North America and Western Europe since 9/11, exacerbated by the unending attacks on security soft spots on Windows platforms, has had a marked impact on how corporations are currently opting to use Web services. Rather than pursuing applicable Web services that may be on offer on the Web from unknown third parties, corporations, for the time being at least, are electing instead to exploit Web-services technology as a new, standards-based component model for software being developed in-house or by trusted partners . In essence the use of Web services is being confined to intranets and extranets.
	A: No ”most certainly not. While one cannot downplay the need for stringent security in any Web services “related scenario, it is important to keep things in perspective and to objectively evaluate the security implications of using a particular service on a case-by-case basis. Concerns about security need to be proportional to the actual sensitivity of the data involved. Thus, one should not generalize matters in this instance. There will be many Web services that deal in relatively innocuous data ”for example, a weather service or even Microsoft s MapPoint Web Service for mapping applications. Some will argue that knowledge of even the invocation of an external Web service, irrespective of the data that was exchanged, may provide a competitor or hacker with some level of insight. Again, it all depends on the application. One should use Web services with portals ”particularly public portals. If such a portal routinely invokes Web services dealing with weather, mapping, horoscopes, stock indexes, and so on, one will be hard pressed to argue that knowledge that these Web services are being invoked would provide a competitor with significant intelligence ”even though some would counter that knowing the rate at which these services are being invoked could indicate the popularity of that portal. The point here, however, is that it is indeed possible to have scenarios involving remote Web services where security should not be the show-stopper ”with the caveat that one always does have the option of still using available and appropriate security measures such as authentication and encryption.
	A: By and large the answer to this has to be a resounding yes. At this juncture one should not lose sight of the fact that e-commerce continues to grow and that trillions of dollars worth of financial transactions, including online banking and online trading, take place over the Web on a daily basis. All of the technology used for these types of transactions, such as digital certificates, digital signatures, SSL, and two-factor authentication, are also available to be used in Web services “based applications. A big concern with Web services is that of rogue Web services, where this could be due to an unscrupulous provider or a compromised platform. However, similar rogue trader or rogue Web site scenarios are possible with e-commerce. One minimizes the danger of this by dealing with reputable sites. The same should apply to selecting Web-service providers. Provided you are dealing with a reputable service provider and are using all of the available and pertinent security technology (e.g., digital certificates, SSL) it is indeed feasible to use remotely invoked Web services ”particularly if one is dealing with data that is not ultrasensitive.
	A: Yes, this will indeed be possible. This on-the-fly , everything done across the Web, e-commerce-based model, facilitated by UDDI, was the initial and compelling vision for Web services. It was even going to be possible to do all of this programmatically with the UDDI APIs. This original software functionality on-tap, over the Web, paradigm will continue to prosper , and one might check to see that the oft-mentioned Microsoft MapPoint service does indeed pander to this. This model will be the only one of interest to a large portion of the software development community (i.e., the cottage-industry sector made up of talented individual programmers and those who are working for small firms). Large enterprises selecting best-of-breed Web services for mission-critical applications may only espouse this totally dynamic, all-electronic paradigm for Web-service evaluation when the software is being invoked from stringently partitioned test machines. Once they have located a promising service, the norm today is to revert to a traditional, big-ticket purchasing routine involving reference checks, credit checks, background checks, contracts, and so on.
	A: Digital certificates are electronic credentials issued by a trustworthy organization such as a large company or a security-specific entity such as VeriSign. A DC vouches for an individual s, a business s, or an application s identity and authority to conduct secure transactions over the Web. DCs are in essence the Internet equivalent of a travel passport. They are a universally accepted means of establishing one s identity and thus gaining entry to a protected resource. DCs are meant to replace traditional user IDs and passwords, which are not as secure or trustworthy. They are thus the preferred means for authenticating users and applications in today s Internet world.
	A: SSL, a client/server-based security mechanism developed by Web browser pioneer Netscape Communications in 1996, is the accepted and trusted basis for most of today s secure transactions across the Web. SSL is a Transport Layer (i.e., Layer 4) security protocol that works on a client/ server basis. It provides authentication, integrity, and data privacy for applications running above the TCP Layer (i.e., Layer 3). SSL uses digital certificates to authenticate the server and the client of a particular transaction. In the case of Web services, this authentication would be for an application and the Web service it intends to invoke. The authentication can be bidirectional (i.e., both the application and the Web service make sure that they are indeed talking to whom they think they are). Following a successful authentication, the SSL sets about negotiating a common encryption scheme acceptable both to the client and the server. SSL does not do the end-to-end data encryption. SSL relies on well-established industry standards (e.g., 168-bit triple DES) and commercial ciphers (e.g., RSA). What it does is negotiate an encryption scheme acceptable both to the server and the client ”and then invokes this mutually accepted encryption scheme for encrypting the data flowing between the client and the server. Thus, the security services provided by SSL in Web-services scenarios would involve bidirectional authentication via digital certificates, acceptable encryption scheme negotiation between the application and the Web service, and invoking the accepted encryption scheme to ensure that the data flowing between the application and the Web service is indeed encrypted and tamperproof on an end-to-end basis.
	A: There are a raft of new Web services “related security specifications being worked on. In some cases the goal of these specifications is to add XML support to existing technologies (e.g., XML Signature Syntax and Processing as well as XML Key Management Specification [XKMS]). In other cases the goal is to add security measures to SOAP (e.g., WS-Security, WS-Security Addendum, WS-Trust, etc.). A list of these security-related specifications can be found in Table 1.1. For the latest status of these specifications, as well as for news on any new security-related specifications, one should visit www.xmlweb.org.
	A: Yes, most certainly. Java and .NET are today s strategic and popular software development platforms, particularly in the corporate arena. Web services, though truly a technology of the twenty-first century, are not, however, confined to these two new software platforms. Web services can be deployed on any platform that offers an appropriate Web-oriented transport that a calling application is willing and able to support. Web services are programming language and platform independent ”as is the case for the applications that wish to invoke Web services. Thus, it is indeed possible to have Web-services scenarios that do not involve Java or .NET. C and C++ on UNIX and Linux platforms are obvious candidates for Web-services scenarios, as are traditional transaction processing systems such as IBM s CICS and BEA s Tuxedo.
	A: There will be a wide spectrum of pricing options for Web services, 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.
	A: No.