1.3 When to implement Web services

With Web services, given their unique and incontrovertible value proposition as a Web-based software component methodology and the near-universal industry backing, there was never any question about if . It was always about when . That when, per all predictions as well as expectations, has come and gone, but among those actively involved in propagating Web services, the question of when (albeit sotto voce) still persists, even in late 2003.

A big part of the issue here, in terms of timing, is that Web services are an application development “ related technology, which is most applicable to the development of large corporate applications. Thus, the supply and demand dynamics of Web services, to a very large extent, were going to be influenced from the start by the overall vigor of the software industry. The depressing economic downturn that followed in the wake of the dot.com implosion, which was then further exacerbated by 9/11, could not have come at a worse time in terms of Web services. In essence, the software industry has been treading water since Y2K. This is the backdrop against which the when question has to be rethought and reanswered.

XML Web services in their current form can no longer, by any stretch of the imagination , be considered nascent. They were postulated in early 2000 and were being vociferously promoted by the summer of 2000. In addition, the key prerequisite enabling methodologies, in the form of SOAP, WSDL, and UDDI, as shown in Table 1.1, were formalized and in place by October 2000. Consequently, given current technology adoption trends, Web services, in theory, have been ready for prime-time usage since at least the latter part of 2002. IBM, Microsoft, Oracle, and BEA (just to mention the super heavyweights) have also been actively promoting them and offering viable Web services development solutions, most of which appear to have the word Studio in their title, for even longer.

Thus, one could, if one wishes, begin Web services “based initiatives right away ”without any further delay. Even a cursory search of the UDDI registries (e.g., IBM s or Microsoft s), as of the beginning of 2003, will show that there are plenty of Web services already available. Most of what is offered , however, is best characterized as yet being prototypical (of the hello World genre ) as opposed to representing sophisticated business logic functionality. In essence, it is safe to say that Web services have arrived (around 2003), though, as is to be expected, they are still in the early stages of growth.

How and when one decides to exploit Web services is unfortunately not as straightforward as one would think, based on all that has been said about them in the media over the last few years . The biggest problem here is that Web services by themselves are not a product. They are not a killer application in their own right. Thus, you cannot buy, market, or sell Web services per se. Web services are a methodology. Hence, what you can buy, market, or sell (not counting the inevitable consulting services) are as follows :

Software components that have been developed per the Web services model
Tools that facilitate the creation, deployment, adoption (i.e., integration and invocation), testing, and popularization (e.g., automated UDDI registry) of Web services “based software components
Applications that have been developed using best-of-breed , third-party Web services “based software components

This list also immediately highlights another pivotal issue related to the vexing when question. The timing of your entre onto the Web services stage will, and should, depend on what you intend to do with Web services ”keeping in mind that it is best to put the horse in front of the cart, rather than the other way around. Consequently, if your interest is in providing tools to facilitate the creation and use of Web services, you ideally need to be ahead of those who want to develop Web services, use Web services within applications they are developing, or acquire new applications that are heavily Web services “oriented.

Those who want to create tools should be at it now! That sector of the market is already in high gear, and, thanks to IBM, Microsoft, and BEA, there is already a wide selection of compelling and effective tools. Therefore, one should assume that much of the Web services “related activity in the 2003 “2006 time frame will and should revolve around the creation of business problem-solving Web services, but even this might get sidetracked to an extent while people await the solidification of some of the auxiliary standards associated with Web services, as listed in Table 1.1. From an enterprise standpoint, security- and management-related standards and practices will continue to be of particular issue, since mission-critical processes are likely to be the primary users of Web services.

Because of incessant virus and hacker threats, enterprises are understandably shy of any software technology that can in any way increase their potential vulnerability. Security concerns, essentially the same bugbear that has plagued the widespread adoption of so many other Web-related software ventures (e.g., e-business, Web-to-host, corporate portals), will again be a gating factor. Availability of solid security measures will dictate , more than anything else, as to when major enterprises will feel comfortable about adopting Web services. Thus, at this juncture it is worth looking at all of the various factors that have and will influence when the market will be ready to adopt and absorb Web services on a consistent and widespread basis.

1.3.1 The issues weighing down upon when

Though a few media columnists have been brave enough to express some doubts , Web services should not be summarily dismissed as mere marketing hype just because they have yet to live up to the enormous expectations that have surrounded them since their inception. There is no doubt that Web services have been slow in gaining real traction in real-life, enterprise-class production use despite the near-unprecedented push that they have received, without exception, from every quarter of the computer industry.

Although most saw 2002 as the year that Web services would begin to flourish, only a staggering amount of effort was expended by the supply side (i.e., vendor community) on defining and publicizing Web services “related standards, particularly in the security and business process orchestration fronts, rather than any real proliferation of mission-critical Web services. Despite these very public setbacks, Web services are, as stated earlier, very real, viable, and here to stay. Furthermore, they will be around for a very long time to come given the invaluable role they can play in application development, software reuse, and legacy modernization. The reason that one can make such unequivocal claims is that there are some valid and justifiable rationales that support why Web services have been slow in living up to their expectations.

The necessary technical infrastructure for Web services, in the form of XML, WSDL, SOAP, and UDDI, is in place and beyond reproach. The key issues, as such, have nothing to do with the underlying technology. Instead, all of the real impediments, in one way or another, relate to what it takes to make Web services mission critical and secure for enterprise usage. A good analogy here, which can, furthermore, be dramatically used to great effect in corporate meeting settings, is that of Russian-built commercial airliners such as those from Ilyushin or Tupolev (Figure 1.17). What makes North American and European travelers somewhat uneasy about these aircraft, which on the whole have a respectable track record in terms of airworthiness, is not their fundamental aerodynamic or propulsion capabilities, but the apparently haphazard nature of their passenger safety (e.g., oxygen masks) and passenger comfort “related equipment. Ditto for Web services. You cannot question their ability to fly. What is at issue is whether the cabin will remain pressurized during the flight.

Figure 1.17: A Russian Ilyushin IL-96-300 jetliner is a great analogy to the factors slowing down the widespread adoption of Web services.

With this Russian aircraft analogy in mind, the key auxiliary concerns that are currently slowing down the widespread adoption of Web services are as follows:

Security and integrity
Reliability (including guaranteed delivery of input/output)
Performance and scalability
Manageability
Pricing model
Ongoing support and updates

All of these issues, most of which are somewhat self-explanatory once they have been enumerated, will continue to be discussed in the remainder of this book. Security, as already mentioned, is the big issue. As reusable pieces of business logic, sourced and invoked over the Web, Web services have the potential to be the ultimate in Trojan horse “ type threats ”even taking into account that the Web services code is executed, remotely, on a third-party server.

The first and biggest concern when it comes to security is making sure that the provider of a Web service is honorable and genuine and is really who he or she claims to be ” especially if you intend to be dealing with sensitive data. Although it will not be disastrous if you send a zip code to a bogus organization masquerading as a provider of a weather forecast Web service, it would be a totally different matter if you were sending credit card information to a credit card authorization Web service that has been compromised or is being run by two teenagers out of an apartment in Azerbaijan.

Then there is the whole issue as to what happens to the information you have shared with a Web service. What rights, explicit and implicit, does a provider of a Web service have when it comes to storing, analyzing, and, above all, exploiting (e.g., selling) information that has been sent to the Web service? This opens up a whole Pandora s box of issues. Today we worry about the information that portals (e.g., Amazon) automatically and transparently extract from visitors via what is referred to, euphemistically, as collaborative filtering. The scope for this type of intrusion in the case of Web services is equally high ”and more insidious. Thus, there is an obvious need to determine that Web services are not unscrupulous, and the problem here is that scruples, in today s world, come in many shades of gray.

Securing the privacy of the information flowing to and from Web services, though a major concern, is not, fortunately, a real issue. Proven solutions such as SSL-based encryption will work and are more than adequate for the time being, but, alas, there are other problems. Think of the various buffer overflow “ type vulnerabilities that have been exploited in Windows NT systems and some Web servers. Web services, at least in theory, can take such threats to a whole new dimension. Related to this is the possibility of denial-of-service attacks propagated through the Web services connections ”especially because SOAP-based WS traffic typically is configured to flow through ports 80 and 443 ”that is, standard HTTP and SSL-encrypted traffic flows, respectively, for Web servers. All in all, it is not surprising that IT professionals are very anxious to ensure that all of the security-related issues pertaining to Web services are securely nailed down before they commit to this methodology.

The good news is that, as shown in Table 1.1, there is much activity taking place on the security front. There is even a forum ”namely, XML Web Services Security (XWSS) (http://www.xwss.org) ”to act as a central clearinghouse for all Web services “related security issues. It is definitely worth visiting this forum to get acclimatized to what is happening in this fast-evolving arena. Consequently, there is considerable belief that by mid-2004 there will be adequate security measures to enable enterprises to evaluate Web services from certified and credible sources with a significant level of confidence and trust.

As with any other type of new software methodology, IT professionals, understandably, have nagging concerns about the reliability, performance, scalability, and manageability of Web services. These concerns are exacerbated by the fact that many of those who intend to offer Web services are likely to be previously unknown entities. Also, there is the whole issue of platform independence, which in this context could be a negative, given that it enables Web service providers the option of using underpowered and possibly unreliable platforms. Obviously, there is nothing in the Web services standards per se that say that these software components have to be any different from other software in any of these crucial areas! To assume that Web services will somehow miraculously break the mold when it comes to all the standard RAS issues (i.e., reliability, availability, and serviceability) that have hounded software for the last 4 decades would be a case of taking optimism to unheard of heights. In terms of these RAS issues, a new Web service, at best, is not going to be that different from a new release of Netscape for the Mac. Diligence, testing, and vigilance are thus going to be essential when evaluating and integrating new Web services.

Pricing and the mechanism for ongoing support are other areas that have yet to be adequately addressed. The pricing model for Web services at present is in its embryonic stage. What is abundantly clear already is that there will be a very wide spectrum of pricing schemes, ranging from freeware to expensive, premium offerings. In addition, in the case of the nonfreeware offerings, there will invariably be many permutations 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 service distributors ”though the inherent dynamic discovery capability of Web services dilutes some of the potential value that can be offered by a distributor.