3.1 The real and not-so-real issues
3.1 The real and not-so-real issues
The key issues that really need to be considered in the Microsoft versus non-Microsoft debate vis--vis Web services can be categorized as follows :
-
Nature of the software being developed, given that a Web service is like a cake in that your feelings about it will vary significantly on whether your role is limited to making it or eating it
-
The applicability of platform independence, since Microsoft solutions tend to be Windows specific
-
Security ” especially since Microsoft muddied the waters at the outset by trying to juxtapose its Passport initiative with Web services
-
Scalability, which, if crucial, is one of the legitimate factors that can influence the choice of platform decision
-
Resilience, given that programmers appreciate that any time or steps saved during the development phase can be totally overshadowed by the time that can be expended trying to debug, rectify, and regression test unstable software
-
Freedom of choice if one does not want to be locked into the solution set of one particular vendor, whether Microsoft, IBM, or Sun
When talking about Web services “related software development, it is sometimes easy to lose sight of the fact that there are two very distinct and different sides to this. Web services “ related software development, as highlighted in Figure 3.4, embraces both:
-
The creation of reusable Web services
-
The consumption of previously created Web services
Figure 3.4: Web services “related software development is always a two-prong operation, with the creation of the Web services being a very separate exercise from that of developing the applications that use them.
From a software development perspective, these are very different endeavors ”as diverse as chalk and cheese. Web services, as stated in Microsoft s own definition and shown in Figure 3.1, are small, reusable applications that are XML based. Web services, in essence, are software widgets. They are components . On the other hand, applications that are built using one or more Web services are, by implication alone, expected to be larger and more complex than a typical Web service. The whole point of having Web services is to simplify and expedite the development of sophisticated, feature-rich, problem-solving applications.
It is indeed possible to have nested Web services, where one Web service invokes other Web services from other external parties to obtain functionality that it requires. This, however, is unlikely to be widely adopted for relatively obvious performance, security, and commercial considerations, given that with Web services you are dealing with dynamic, run-time invocation of functionality, as opposed to an embedded software “oriented software component model. Unless there is a watertight means for total disclosure upfront, and WSDL in its current form alone may not be adequate for this, a person who elects to call a Web service to obtain a certain function may not be comfortable to find out that that Web service in turn is going out to other Web services behind the scene.
Suffice to say that such nested calls, if they involve multiple undisclosed entities, could be a potential can of worms. For the discussions at hand, it is adequate to categorize such nested services based just on the number of nested calls involved. If a Web service only has one or two calls to other external Web services, for the sake of the issues here, it could still be treated as a large Web service. If, however, a Web service has many calls to other external Web services, it starts to cross over the boundary and should be thought of more as an application ”rather than a single Web service.
There is meant to be a definite subset-superset, component-system relationship between a Web service and the application that uses it. The Web service is a subset (or component), whereas the end application is the larger, total picture. The end application, as the system in this case, is a superset of the Web services invoked by it. Consequently, it is fairly easy to appreciate that the needs of programmers developing Web services are likely to be different from those developing the applications that will be using Web services.
Thus, one cannot look at Web services “related software development as a single, homogeneous continuum that spans both the creation and consumption aspects. Instead, what we have are two disjointed , decoupled endeavors ”each with its own unique set of goals and requirements. This distinction is vital when trying to objectively evaluate the Java versus decaf debate, given that one could be better for creating Web services, whereas the other is more suited for developing the larger applications that will be using Web services. Immediately it is possible to envisage win-win scenarios involving both methodologies, which could even prove to be synergistic.
At this juncture, however, it would be useful to characterize some of the key differences between Web services and the applications that use them, as well as to categorize the motives that will spur the development of Web services. Table 3.1 address the former, whereas Table 3.2 tackles the latter relative to corporations and individuals.
| Web Service | Application Using WebServices | |
|---|---|---|
| Purpose: | Reusable, commodity component | Address an overall business or entertainment need |
| Typical size in terms of code length: | Small | Medium/large |
| Functionality: | One specific function | Multifunction |
| Typically developed by: | Individual or 2 “4 people | Team of programmers |
| Complexity (in general): | Relatively simple | Relatively complex |
| Development time frame: | Days | Months |
| Corporations | Individuals |
|---|---|
|
|
The bottom line here is that it is a fallacy to assume that Web services and the applications that intend to use them are or will be birds of the same feather. Instead, they are likely to be (one could even say that they really should be) very different entities ”developed by different types of people, with very different motivations and software development requirements. This plays to Microsoft s advantage. Given this distinct dichotomy , one could develop Web services using Microsoft tools ”in particular, the new .NET solution set ”without immediately confronting the challenge that Microsoft-based solutions are not appropriate for use in large data center “ related scenarios. The reason is that a given Web service could have many different takers ”all of them not necessarily wanting to use that Web service in a large-scale, mission-critical application being developed for a Fortune 500 corporation. However, the contention that a Web service deployed on a Windows server may not be rugged enough for use by enterprise-class applications may still have some justification in certain situations, as will be discussed shortly.
3.1.1 No real glory in making it complicated
By now, especially after the characterizations depicted in Tables 3.1 and 3.2, it has to be clear that Web services, in general, are supposed to be compact, self-contained pieces of software. It is tempting to also add the word slick to this description, though this, alas, is not a mandatory prerequisite, though one would like to think that this indeed is likely to be the case much of the time. Agility is the other word ”one could even say theme ” that should come to mind, especially as one gets more and more exposure to Web services. Everything about a Web service is supposed to be quick, nimble , and, above all, easy. These agility-related attributes thus apply not just to the use of a Web service, but equally so to the development of a Web service.
Somebody planning to, or tasked with, developing a Web service should not typically view this as being a major, long-drawn-out project. Developing a Web service is meant to be a relatively quick and easy endeavor. A couple of metaphors at this juncture should help reinforce this key point. A Web service, to use an analogy, is not meant to be a novel. It is not even supposed to be a 50-page short story. Instead, it is meant to be a set of paragraphs. In this analogy, the novel will be one of the new applications that makes use of the Web service. This analogy should provide a fairly accurate handle as to the level of effort and time commitment one should associate with the development of a Web service. If it takes more than a couple of weeks to create, then it could likely be more than a Web service. The metric for measuring the time required to develop an average Web service really has to be days rather than anything larger. It may also help to think of Web services as the TV dinners of the software industry ”with ease of preparation, quick results, and fast gratification being the keywords here.
Developing typical Web services is thus meant to be a small project. It is not meant to take a long time, and it is expected to be relatively easy to complete. This is good for Microsoft and .NET. The flip side of the Microsoft in the data center argument now comes into play ”more or less by default. If Microsoft solutions are not industrial strength for enterprise-level deployment, then they must at least be easy to create and deploy. The rationale for this is that one has to believe that Microsoft software must have some redeeming attributes, given that Microsoft as a company serves more software users, by far, than any other company.
In essence, the not industrial strength gibes, by implication, tend to convey the perception that Microsoft solutions have to be less complex, less cumbersome, and, in general, lighter. It makes Microsoft s approach feel more user friendly, more approachable, and less intimidating ”exactly the type of approach you would want if you were looking for a way to develop a small piece of software without expending too much time, effort, and money ”so this leads to a definite schism . The non-Microsoft camp, in particular IBM, comes across as being heavy duty, somewhat involved, and complicated. Microsoft, on the other hand, can now revel in being light and easy, and, to Microsoft s delight, there are tens of thousands of programmers, if not more, who will heartily concur with this sentiment.
To be fair to all sides, the popularity and effectiveness of Microsoft s software development solutions are not just a perception issue, or, for that matter, one that is even subjective . Microsoft s visual family of programming tools, now exemplified by Visual Studio .NET 2003, has a huge, faithful, and avid following. Visual BASIC (Figure 3.5), introduced in 1991 after Microsoft obtained the underlying technology from Alan Cooper in 1988, struck a chord, especially with noncorporate programmers. BASIC, ever since its inception at Dartmouth College in the mid-1960s, had enjoyed an unblemished reputation for ease of use, convenience, and user friendliness. BASIC, even when available in compilable as opposed to interpretive mode, was, however, never considered as a serious contender to the likes of COBOL, FORTRAN, PL/I, and C when it came to developing large, mission-critical applications. BASIC was more for the casual and entertainment (e.g., DOS games for the initial PCs) market.
Figure 3.5: The visual programming paradigm of Microsoft s Visual BASIC software development environment with annotations by Professor Saul Greenberg, University of Calgary, Canada.
With Visual BASIC (VB) Microsoft changed some of the ground rules as to the applicability of BASIC. VB was integrated with the then emerging Windows. VB enabled programmers to quickly and easily create Windows-compatible, event-driven (e.g., clicking a button) graphical user interfaces (GUIs). VB was thus a quick and obvious way to develop true Windows applications as opposed to clunky DOS applications. VB was compelling to programmers trying to capitalize on the fast-breaking Windows wave, particularly if they were working with modest budgets and aggressive schedules. The ensuing rapid embracement of VB by a large segment of the programming community, further bolstered by a whole new legion of VB-inspired freelance programmers, gave VB credibility and respectability. The mainly for kids stigma factor associated with BASIC was dissipated by the sheer weight of numbers , both in terms of VB-qualified programmers as well as VB-based applications on the market.
VB, however, was only the beginning. Since then, there has been Visual C, which has since evolved into Visual C++ and Visual C#. There has also been Microsoft s popular COM- and Active X “based object-oriented methodology, as well as the heavily used Active Server Pages (ASP) scripting scheme for developing server-side software for dynamic Web applications. The hard and cold facts are irrefutable. VB, Visual C++, COM/ActiveX, and ASP are not just popular; they border on being ubiquitous. Whether one likes it or not, much of what makes up today s Web, whether Web content, Web applications, Web servers, or Web browsers, have some Microsoft connection.
Given this presence and popularity, Microsoft s influence and role when it comes to the development of future Web services is already assured. That is beyond debate. It has already happened . Microsoft s Visual Studio .NET, with its integrated support for VB and Visual C#, has from day one been explicitly targeted as a premier tool for developing XML Web services. Programmers who have been relying on Microsoft tools in the past are apt to look at Visual Studio .NET before evaluating other development schemes. However, it should be noted that Visual Studio .NET per se is not a prerequisite for developing XML Web services. You could develop them using older Visual C++ or VB products.
All of today s highly visual software development studio suites, whether from Microsoft, IBM, BEA, Sun, Oracle, or the open-source eclipse.org Consortium, go out of their way to facilitate the development of Web services. However, the reality here is that the compact, small project nature of developing a typical Web service nonetheless still plays to all of Microsoft s advantages vis--vis software development. The key ones here are, however, worth enumerating, given that it is sometimes easy to forget exactly what they are since they can be so obvious as to be transparent. Some of the key issues that will favor Microsoft, when programmers have to consider options for developing new Web services include the following:
-
Despite what one may feel about Microsoft, particularly in regard to software resilience (e.g., blue screen of death with most versions of Windows, including NT) and cost (e.g., new version of Office), Microsoft, thanks to its inescapable presence on desktops, still falls into the category of the known devil .
-
Again, thanks to Windows, Internet Explorer, and Office, Microsoft and its offerings come across as being approachable ”particularly in terms of downloading the necessary tools from Microsoft and trying them out on a Windows machine.
-
Software developed with Microsoft tools can be quickly, easily, and inexpensively debugged and tested on commodity Windows platforms.
-
VB and Visual C++ have a reputation for delivering fast results.
-
It is difficult to feel isolated or be stranded high and dry during the development, debug, or deployment process, since no-charge, near instantaneous tips, help, and encouragement are available online, 24/7, from a large and committed fraternity of knowledgeable and experienced like-minded practitioners from around the world who frequent a number of very active bulletin boards .
-
There is a vast network of practical online resources, including sample code, much of it on a no-charge basis, available from Microsoft, other companies, and individuals to help one get started on a development project.
-
Given that many well-known software packages only work on Windows-based server platforms, or are initially released just for Windows with UNIX support only available much later, one cannot be easily ostracized for developing a Windows-specific solution ”especially since Web services, by definition, are platform agnostic .
Thus, the bottom line here is that Microsoft tools, in particular the .NET repertoire , will continue to play a major role when it comes to the development and deployment of Web services. That really is incontrovertible. The one big downside, however, of using Microsoft development tools, including Visual Studio .NET 2003, is the lack of platform latitude. Software developed using most Microsoft development tools can typically only be deployed on Microsoft Windows platforms. Figure 3.6, which is a screen shot of Microsoft s System Requirements for Visual Studio .NET 2003 Web page, shows that the only operating systems supported by Microsoft for the deployment of applications created by Visual Studio .NET 2003 just happen to be various flavors of Windows.
Figure 3.6: Part of the system requirements for Visual Studio .NET 2003 Web page from Microsoft s Web site showing that applications developed using this tool set can only be deployed on Windows platforms. Highlighting, in the form of the vertical bar, was added by the author.
3.1.2 Mounting the platform ”gingerly
The platform independence of Web services, as repeatedly stressed at the beginning of this book, is truly bona fide, universal, and without exception or caveats. This is so because Web services operate by exchanging XML documents on a run-time basis. XML, as should be now clear, is a simple methodology based entirely on the use of documents consisting of plain text. Platform independence and programming language independence are two of XML s primary precepts. Consequently, the platform independence of Web services is not just restricted to one side of the requester-provider model.
Web services can be deployed on any platform, as can the applications that rely on the functionality provided by Web services. It is always any-to-any. There are no interoperability limitations or unacceptable permutations . There are also no mandated optimum permutations, though there will be those who claim that UNIX/Linux to UNIX/Linux, mainframe to UNIX/Linux, mainframe to iSeries, iSeries to iSeries, or iSeries to UNIX/ Linux pairings are unlikely to give any cause for concern when it comes to performance, security, reliability, or scalability. The XML-oriented operation model employed by Web services also dictates that there are no requirements or restrictions as to how Web services or the applications that use them are developed. Since all data exchange takes place in the form of XML documents, there are no programming language “, database-, or file format “ related interoperability issues.
Given this background, one has to be very careful and have plausible justification prior to claiming that some platforms may not be as good as others when it comes to hosting (i.e., running) Web services. Note that the keyword is that of hosting Web services (i.e., the platform on which a Web service is to be deployed). The platform issues for the applications that will use Web services are invariably very different and are dictated by a separate set of criteria. However, in order to establish a baseline for the ensuing discussion, Table 3.3 sets out some of the key platform-related factors as they apply to Web services and the applications that use them.
| Web Service | Application Using Web Services | |
|---|---|---|
| Likely to be a replacement for an existing (legacy) piece of software: | No | Yes |
| Relative size (i.e., code length or memory requirements): | Likely to be small | Likely to be large |
| Reliance on backbone services (e.g., database, directory, messaging): | Limited, if any | Significant |
| Potential consumption of computing resources (i.e., processor cycles, memory, I/O): | Likely to be low (per instance) | Likely to be high |
| Likely to be mission-critical: | No | Yes |
| Size of potential target audience known in advance: | No | In general, yes ”even when targeted for public access over the Web |
| Need for scalability: | Unknown | Likely to be a concern |
| Developed with specific response time expectations: | No | Yes |
| Culled from a legacy, mission-critical application: | Possible | No |
| Importance of platform resilience: | Of some concern | Likely to be very high |
| Importance of security: | High | High |
| Ability to dictate need for a new, more powerful server platform: | Limited | High |
| Ability to justify higher server costs because of mission criticality or number of users for the server: | Limited, if any | High |
| Importance of potential portability between diverse platforms: | Unlikely to be a major concern in general | Likely to be a concern |
In general, the platform preference and selection for the application side will occur independent of any consideration being given to the intended use of Web services. That is perfectly legitimate and acceptable ”as it should be. The application is the driving force in this instance. It is the goal. Web services are but enablers. The tail should not wag the dog ”and in this instance, the application is very much the dog. Consequently, any Web services “related platform issues per se should not influence the platform or platforms targeted for a Web service invoking application. Thus, it is really business as usual on the application side when it comes to platform-related issues.
Typically the platform(s) for an application is preordained by a number of set-in-concrete factors. If the application is being developed for use by just one company (e.g., a large Fortune 1000 company), then the platform preferences of that company, both existing and those targeted for the future, will be the deciding factor. If it is a large company that has relied on mainframes for much of its IT needs for the last 3 decades, and the new application is to replace a 25-year-old mission-critical application running on those mainframes, then the chances are that the new application will be targeted, at least initially, to be mainframe-compliant. This is where Java is such a boon. Developing the application in Java is likely to cover all bases ” current as well as future.
A Java application can be easily hosted on a mainframe, UNIX/Linux, iSeries, or even a Windows platform. It will even adroitly accommodate any plans to migrate some of the mainframe workload to Linux server images running on a mainframe. Thus, for this type of corporate application, Java would appear to be the optimum choice, with C++ being the second choice if performance is paramount ”given that a C++ application could also be ported to any of these applications, albeit with the need for it to be first recompiled on that platform.
Then there are the applications that are developed, by enterprises or individuals, so that they can be sold, leased, or given to others ”where the recipients could be commercial corporations, noncommercial organizations, or individuals. This is the trillion-dollar application software market. The platform issues in this instance are obviously more convoluted and complicated. First, there is the pivotal issue as to whether the application is for the client side or the server side. The ongoing popularity of mobile clients (e.g., intelligent cell phones, PDAs, Pocket PCs, and tablets) and thin clients (e.g., Windows 2000 Terminal Services, Citrix solutions, or Web browser “based access), however, starts to blur this client-side versus server-side demarcation , as does the whole concept of Web server “resident Web applications.
Figure 3.7 illustrates the overall thin-client model postulated by Windows 2000 Terminal Services, whereas Figure 3.8 shows the contemporary application delivery architecture advocated by Citrix Systems. With thin-client solutions, in essence what you end up with are client-side applications that nonetheless execute on a server, as opposed to the actual client.
Figure 3.7: The overall architecture of the compelling thin-client solution available with Windows 2000 Terminal Services, which obviates the expense and effort of having to install and maintain Windows applications on individual desktops.
Figure 3.8: The latest thin-client application delivery architecture postulated by Citrix Systems showing how client applications running on a Citrix server can be conveniently accessed by a wide range of legacy, desktop, terminal, kiosk, Web, and wireless clients.
The traditional desktop client market, irrespective of whether it is enterprise or home related, is dominated by Windows. Linux could start changing this down the road ”and it is salutary to note that it is possible to easily port UNIX/Linux applications to run on the Mac OS X (and later) platform. The issue here is relatively simple. Applications being developed for the traditional desktop client market are invariably going to favor Windows, at least for the foreseeable future, given that this is the predominant market. The availability of Windows subsets for mobile devices (e.g., Windows CE), in particular, a feature-rich version of Windows XP for PC tablet platforms, is likely to make a Windows-oriented decision even more compelling.
Things, however, are more complicated on the server side ”given that there are at least four major and widely used server platforms ”namely, UNIX, Linux, Windows, and iSeries (ne AS/400). Fortunately, there is a distinct market stratification that helps provide a first cut as to which platforms will be of relevance to which types of applications. Though enterprises of all sizes and shapes use Windows server platforms, the larger enterprises invariably also rely on other server platforms (e.g., UNIX) for some or all of their crucial IT functions ”with the Windows server being used in the main for file/print server and departmental applications.
On the other hand, smaller businesses and organizations (e.g., restaurants , convenience stores, small professional firms, and health-care practices) tend to rely entirely on Windows platforms, so much so that Microsoft even runs print ads for its Windows 2003 server that state: You need UNIX-level performance and reliability. You don t have a UNIX-level budget. Thus, in essence, the primary target market for a given server-side application more or less steers the platform decision one way or another.
Windows will continue to be the preferred platform for applications designed for small businesses and organizations. Though applications written in Java could be made to work on Windows platforms, many software developers will see this as an unnecessary (and costly) exercise if the application is meant to be just for Windows. They will further argue that developing these applications in Java will make them less efficient ”possibly even sluggish . In marked contrast, platform flexibility becomes a big issue when an application is being developed for use by mid- to large-size enterprises ” hence, the preference for Java or C++ for this class of application.
The bottom line here is that the platform selection issue for applications that will be using Web services will invariably be made independent of any concern as to (or possibly even any thought given to) where the requisite Web services will actually be located. To be fair, in most cases developers might not even know exactly what Web services they want to use until they are much further into the actual software development process. Remember that finding and sourcing necessary Web services, using a combination of UDDI and WSDL at a minimum, is meant to be easy, dynamic, and flexible. Furthermore, developers are likely to ditch certain Web services and look for alternatives if they are not satisfied with the functionality or integrity of a particular Web service.
However, the issue here is that the platform being used by a Web service could, in some circumstances, have an impact on the calling application. In effect, the platform selection for an application could get undermined, unintentionally, by the platforms being used by the Web services being invoked by that application.
3.1.3 Ease of development, however, is not everything
To cut to the chase, the underlying concern here has to do with Web services that are to be deployed on Windows platforms. The preceding discussions should have demonstrated, irrefutably, that Microsoft development tools, in particular the Visual Studio .NET, VB, Visual C++, and Visual J++ offerings, will play a major role in the foreseeable future when it comes to the creation of Web services. Individuals, as well as small to medium-size enterprises, are likely to opt for a Microsoft scheme as their weapon of choice when thinking about developing a new Web service. These Web services will end up being deployed on Windows server platforms. This is because software, including Web services, created using Microsoft s development tools tends to be Window-specific. Furthermore, other developers may opt, justifiably, to have their Web services deployed on a Windows platform, even if they are not using a Microsoft development scheme, given that Windows platforms are ubiquitous, inexpensive, and are always within easy reach.
Consequently, Windows, incontrovertibly, will be a dominant platform on which Web services are hosted. There is even a possibility that in the 2004 “2007 time frame roughly half of the Web services (if not more) made available via the global UDDI Registry are running on Windows platforms. This predilection vis--vis Windows could have potential ramifications ” and that is the real nub of this issue.
The concern here relates to Windows-resident Web services being invoked by applications running on a non-Windows platform. This is not an interoperability issue. The genuine platform-independent, any-to-any principle of Web services mandates that applications running on non-Windows platforms should be able to profitably make use of Web services running on Windows platforms. Moreover, an application should not even have to care about which platform a Web service it is invoking is executing on. It should be transparent and immaterial. However, the reality is that there could be a potential expectation mismatch if an application explicitly developed to run on a non-Windows platform ends up relying on one or more Web services running on a Windows server (e.g., a mainframe application invoking a Web service running on a Windows NT server).
The potential mismatch here pertains to four extremely key factors, namely:
-
Security vis--vis platform vulnerability
-
Reliability and resilience of the platform
-
Performance attributes of the platform as it relates to being able to quickly service a large number of requests within acceptable response time criteria
-
Scalability of the platform when it comes to adroitly accommodating increasing workloads
The problem here is that Windows servers, particularly Windows NT and the earlier versions of Windows 2000, are invariably at a disadvantage relative to these four factors when matched up against UNIX, mainframe, and even iSeries platforms. Thus, the question becomes whether a Web service running on a Windows platform could compromise the integrity and performance of a mission-critical application running on an enterprise-class server. To put it more graphically, could using a Web service running on a $2,500 Windows server potentially damage the credibility of a million-dollar application running on a $1,800,000 top-end UNIX server with 24 processors and 64 GB of memory?
The answer, alas, has to be: Yes, it could.
This is where the Windows is still not ready for the enterprise-class data center argument comes in. Windows 2003, available as of June 2003 and explicitly developed to cogently address the exacting data center needs of large enterprises, may start to change this ”but this has yet to be demonstrated. In the meantime, it is only fair to say that Windows platforms are invariably not in the same class when it comes to security vulnerability, high-end performance, high availability, and scalability as the more expensive UNIX and mainframe solutions. That is the rub. Figure 3.9 depicts the four, somewhat intertwined, factors of any server platform running Web services, but in this case, Windows platforms in particular, that could prove to be a source of concern if their operational characteristics are significantly inferior to those of the platforms hosting the applications invoking the Web services.
Figure 3.9: These four key factors of a server platform dictate the desirability of that platform as a host for Web services, since exposure in any one of these areas can undermine the value of the Web service vis--vis applications running on other platforms with significantly better operational characteristics.
Over the last few years the security vulnerability of Windows platforms, particularly those exposed to the Internet and running Microsoft s IIS Web server or e-mail server, has been a major concern to enterprises around the world. The ubiquity of these servers, coupled with the fact that it is easy and inexpensive to obtain one for experimentation, has meant that most hackers invariably opt for Windows as their favorite, and in most cases only, platform to seek and attack.
Think about it. It is not that easy or practical to fire up a mainframe in your one-bedroom apartment so that you can poke around looking for software vulnerabilities (e.g., buffer overflow processing or profile flipping ) that could be exploited for nefarious purposes, and savvy hackers usually do not like the risk of snooping around and trying blatantly suspicious programming activities on data center computers ”which, moreover, are harder to gain unauthorized access to in the first place. Thus, it is much more convenient and safer to pore over a Windows server, which can be installed on any halfway-decent PC, and determine ways to attack other similar Windows platforms.
On the whole, Windows platforms to date have been a fertile field for hackers and the creators of viruses. They have found and exploited numerous ”in many cases profound ”security holes. The resulting security breaches have been far-reaching, disturbing , and costly. They have repeatedly disrupted e-commerce and e-business activities and caused millions to lose sleep over the potential loss of their credit card information. It reached a point when influential IT analyst firms started issuing high-priority alerts to their large corporate customers, advising them to migrate away from Windows server platforms ”especially in the case of servers being used for Internet-related endeavors.
Consequently, most IT professionals at medium to large enterprises now tend to be somewhat leery of Windows NT and Windows 2000 servers ” particularly if they are conversant with other server platforms. With Windows 2003 Microsoft promises to provide significantly tighter security, but it will take quite some time, with zero violations during that time, before people will feel that they are not at some risk if they start using an Internet-connected Windows platform. The bottom line here is that IT professionals used to dealing with UNIX, mainframe, or iSeries platforms will, justifiably, be anxious about having to rely on Web services running on a Windows platform.
A rogue, unscrupulous Web service could do untold damage. It could put viruses to shame when it comes to stealth, cunningness, and potency. A rogue Web service masquerading as a bona fide service can in effect commit hard-to-detect, white- collar crime in the context of IT processing. It can be the ultimate Trojan horse. The Web services of concern here are not those offering innocuous functions such as weather reports , zip code location, shipping charge calculation, or flight availability look-up. Given that any and all data sent back from a Web service have to be in the form of an XML document (i.e., a text file), a Web service cannot infiltrate the calling system by sending back a virus or worm. To put it another way, a Web service cannot send back an executable piece of code that can damage or compromise the calling system. The danger has to do with sensitive information being sent to a rogue or compromised Web service.
The most obvious example here would be credit card information. Let us assume that a Web service that has to do with some form of credit card processing is not what it claims to be ”or is being run on a Windows server that has been infiltrated and compromised by a hacker. Now you have a situation where sensitive information is being sent out, unbeknownst, to an unsafe destination. The nature and threat of this danger are easy to see and really do not need much further elaboration.
Microsoft unintentionally further muddied the whole security landscape vis--vis Web services running on Windows platforms by trying to associate its single sign-on authentication system, Passport, with Web services. Passport is essentially a digital wallet system to obviate the need for the same user to be repeatedly authenticated by different service providers ”particularly in the context of e-commerce, private portals, or subscription-based Web pages. It predates the advent of Web services and really is totally independent and orthogonal to Web services. Nonetheless, in early 2001, when Microsoft was trying to promote the then-fledgling concept of Web services to the public at large, it bandied about Passport as an enabler for Web services prior to the subsequent efforts of one of the potential authentication schemes for Web services.
Just as with the Windows servers, as well as the other Microsoft Webrelated servers, hackers (and security experts) have probed and tested Passport and found it to be more porous than it really should have been ”particularly given that toward the end of 2001 more than 200 million Web users had signed on to avail themselves of Passport s single sign-on convenience. Disquieting security flaws continue to be unearthed, with a major flaw discovered in the spring of 2003 that would enable a hacker to change the password of a Passport account and gain access to that account! The digital wallet aspect of Passport (i.e., a supposedly secure repository for maintaining credit card information needed for e-commerce) meant that the credit card information stored in their Passport wallets by unsuspecting Passport users could have been stolen. The security vulnerabilities found in Passport, which was meant to be a security-enhancing service, were another major, highly visible, and embarrassing black eye to Microsoft.
Although slow response times and unreliability are not as catastrophic as security flaws, one should now be able to easily extrapolate how a Web service running on a sluggish, crash-prone platform could undermine the delivery goals of a mission-critical application running on a high-power, high-availability system. This whole issue can be summed up by saying that there is not much point in implementing a high-volume, 10,000 concurrent user, mission-critical application on a zero downtime mainframe claimed to deliver a 99.999% uptime if this application relies on making constant calls to a Web service running on a Windows server that needs to be rebooted three times a week.
3.1.4 Circumventing the Windows server issue
If you are in any way concerned about Web services that are deployed on Windows platforms, the first thing that you have to do is determine whether applications that are being developed within your purview need access to such Web services. This is something that will have to be done on a case-by-case basis ”each time your developers identify a function that is best addressed using an externally sourced Web service (unless, of course, you obtain all of the required Web services from just a few previously qualified and selected vendors and you know beforehand that they do not deploy any of their Web services on Windows platforms).
Typically an application developer will have to contact the Web service provider to ascertain the platform on which a particular Web service will be offered. As in the case with those offering Web site hosting, there could be scenarios where a Web service provider may offer the same service on different platforms ”possibly with a price differential between them ”but the bottom line here is that explicit contact with the service provider is invariably going to be the best way to establish on which platform a particular Web service is deployed ”and what options there may be in terms of having that service offered on another platform.
When dealing with Web services for mission-critical applications, it would not be amiss to start thinking about service-level agreements (SLAs) ”similar to what large corporations would have with their telecommunications provider and ISP to ensure that they receive a guaranteed minimum level of service. The use of Web services has not yet reached a point where this concept of SLAs is being widely bandied about, even though IBM has already done some pioneering work on this front relative to its Web Services Management Middleware project. One can, however, definitely see an emerging call for such SLA-based guarantees when it comes to mission-critical scenarios.
Sluggish or unreliable Web services could definitely result in lost opportunity costs (e.g., loss of business) in the context of mission-critical applications. Consequently, it makes sense to ensure that a Web service provider is willing to guarantee some level of performance and uptime ”albeit at a cost. This would thus be the ideal mechanism and framework through which to ascertain the platform on which a Web service is being offered. It can also serve as a good litmus test to determine the service provider s level of confidence and commitment vis--vis that Web service.
The ideal workaround, if having a key Web service running on a Windows server is a concern, whether for security, performance, reliability, or scalability, would be to have the option of porting that Web service to a different platform. This, however, is the problem. Web services developed using Microsoft s popular software development tools, particularly the now heavily promoted Visual Studio .NET, tend to be Windows-specific. Some of these Web services, especially if developed using Microsoft s Java (i.e., Visual J++), C#, or C++, could conceivably be ported to other platforms by extracting the basic source code and recompiling it using a non-Microsoft compiler ”provided that the Web service is not too heavily dependent on Windows-specific software technology such as Microsoft s COM components. However, such porting will by nature necessitate some level of rework of the original software. If the Web service is heavily reliant on Windows-specific content, rework may not be feasible or practical.
Another option that could be considered at this juncture is the overall ROI of rewriting the necessary Web service in-house, such that it can be deployed on a non-Windows platform. Though this would appear to go against the grain of gainfully reusing functionality developed by others, it has two hard-to-ignore virtues. The first, of course, is that it eliminates the concern about using a Windows-based Web service. The second is that the new software component developed in-house, being a Web service, could be marketed for profit to other enterprises that may also feel queasy about using a Windows-based service. If there are insufficient resources in-house to develop the necessary Web services, a variation on this theme is to find a contract software house, a consultant, or an application development company that would undertake the development as a revenue-generating proposition.
If porting to another platform or rewriting the Web service is not possible or justifiable, another alternative would be to acquire the rights to the Web service from its provider and deploy it in-house (i.e., behind the corporate firewall, so to speak) on a secure Windows 2003 server. At least this will enable you to have some level of control over performance, scalability, and hopefully also reliability.
The bottom line here is that those involved with mission-critical applications are justified in wanting to make sure that a Web service running on a Windows platform will not compromise the operational characteristics of their offering. However, the issues involved are not black and white. There are many shades of gray. Much depends on the exact circumstances of the calling application relative to that of the Web service. This section has addressed as many of these as possible and tried to put them all into perspective. There will be a lot of Web services that are only available on Windows servers. Do not dismiss all of them out-of-hand. Evaluate those that are of interest to you, on a case-by-case basis, and consider whether a service-level agreement might provide you with the assurances you need.
![Web Services[c] Theory and Practice](/icons/blank_book.jpg "Web Services[c] Theory and Practice"){kind=icon}