1.2 Why there is a need for Web services
1.2 Why there is a need for Web services
It is safe to say without any fear of contradiction, if one wants to cut to the chase, that Web services transform everything to do with applications. Furthermore, this bold assertion, bereft of any qualifiers, caveats, or verbs relative to the term applications , is not mere hyperbole. Web services really do positively impact everything associated with applications ”both on the supply and demand side. Anybody and everybody who is exposed to software, in whatever role, whether as an application user , developer, financier, portal visitor, salesperson, or sustainer, will enjoy some tangible benefits made possible by Web services ”hence, all the hoopla about Web services. Web services go beyond just changing the paradigm when it comes to applications. Web services are truly iconoclastic!
Though one can think of Web services as being an application development “specific methodology, this is far from being the whole picture. Web services also have a very productive role to play when it comes to existing applications. This is particularly the case when it comes to the so-called mission-critical applications that sustain the operations of medium- to large-scale commercial, academic, and research enterprises . Web services enable problem-solving logic from existing applications to be reused. Web services are thus a way to recycle software.
Web services are a standardized, universal, and sure-fire mechanism for isolating, capturing, and modularizing software functionality so that it can be easily reused ”with alacrity. Thus, Web services, in effect, can make application owners into application software moguls! Therefore, one cannot just say that Web services only transform the application development process. Web services, instead, also transform application ownership ”in a hitherto unprecedented manner. To emphasize this key bilateral feature of Web services, Figure 1.10 highlights the software recycling aspect of Web services, while Table 1.2 shows the primary advantages that can be accrued by software providers and software owners through the availability of Web services.
Figure 1.10: Web services are a standardized, platform, and programming language “ independent mechanism for recycling software functionality.
| Supply Side | Demand Side | |
|---|---|---|
| New Application Developers:
| Owners of Previously Developed Applications:
| Enterprise Class Application Consumers:
|
| ||
In addition to its both sides can win capability, the impact of Web services is also not restricted to any one particular type or class of application. Though at first blush it is easy to assume that large enterprise class applications (e.g., ERP, CRM, and so forth) are likely to be the main benefactors and thus consumers of Web services, this is not necessarily the case. Down the road, most new applications, whether they be for single-user desktop productivity or multiuser, pan-enterprise, transaction processing, are likely to rely on one or more Web services. This will certainly be the case with Web-related applications, in particular e-business suites and portal- related applications. Portals, as mentioned earlier in the context of the WSRP specification, are likely to be major and pioneering consumers of Web services.
1.2.1 Why Web services complement portals
A portal is a Web-based, easy-to-use, transaction-oriented, focal point of access to a diverse range of content, services, resources, and applications. MSN, Yahoo!, Lycos, Excite, AOL, Netscape, and iVillage are all examples of portals ”or, to be more precise, public Internet portals. FedEx.com, Schwab.com, Citi.com, AA.com, and CNN.com, on the other hand, are examples of corporate portals, whereas PBS.org, Dartmouth.edu, and IRS.gov are examples of service-oriented noncorporate portals.
A corporate portal differs from a static, home-page Web site in two fundamental ways: personalization and transactional capability. A homepage Web site does not make any attempts to identify and distinguish its visitors. All visitors are treated equally and have access to the same set of content and services. A portal, on the other hand, even if it is a public Internet portal, tries to identify each and every visitor so that it can try to provide a personalized experience. Thus, the content, applications, and services available via a portal, especially corporate portals, will in most cases be tailored and personalized to meet the exact demands of specific users or user groups. Portals will identify users (i.e., visitors ) either via an authentication process (i.e., a user-ID/password exchange) or via an automated self-describing scheme involving some kind of cookie (or applet) technology.
Portals, and in particular corporate portals, also enable authorized users to conduct bidirectional, self-service transactions ”for example, query account balances , make payments using credit cards or electronic checks, order goods or services, check the status of an order delivery, and so forth. Portals, with their powerful personalization capabilities, have proved to be an extremely economical, efficacious, and efficient means for dealing with clients . Corporations, irrespective of their size , have realized unequivocally that portals, at a minimum, can increase their reach, reduce operational costs, expedite customer service, bolster customer loyalty, and enhance competitiveness. Corporate portals can, at a stroke, simplify, streamline, and speed up all client-to-corporate interactions. A portal, in effect, is a fully automated, Web-based emulation of a highly proficient, well-motivated call-center operation devoid of on-hold delays, annoying voice response prompts, and incompetence . Consequently, the deployment and usage of portals are on the ascent, and the Web is now studded with heavily used portals.
Portals, given their transactional nature, thrive on functionality. Whereas compelling content is the key to a successful static, home-page Web site, the popularity of a portal, whether public or corporate, is largely contingent on the services it offers (i.e., its functionality). Portal users want features that enable them to get things done quickly (e.g., pay bills, sell options, check bank balances, book vacations , and so forth). They also want to be edified, gratified, and entertained ”so much so, that one could easily extend that adage about never being able to be too rich or too thin to also say that a portal can never have enough functionality. Dedicated portal users will always be able to clearly articulate additional functionality that would enhance their visits to a portal. Consequently, portal providers, as well as the developers of portal software, are continually looking at ways to expedite and simplify the process of adding new functionality to portals. Given this pressing need, Web services have indeed been a hugely welcome panacea.
Web services, as a Web-centric, component-oriented software technology, are an obvious and easy way to add functionality to portals. Their platform and programming language independence further enhances their appeal in this respect, given that UNIX/Linux, Windows NT/2000, and iSeries machines are all popular platforms for portal deployment, with some large corporate portals even being hosted on IBM mainframes. The growing reliance on portlets (or similar mechanisms) within portal architectures and offerings further simplifies Web service integration, as discussed earlier. (Microsoft s Web parts , Plumtree Software s gadgets, and SAP s iVews are some of the other terms used to describe portlet-like constructs in the context of portals.)
In a portlet-based portal each application, service, and utility (e.g., search function) will be associated with a specific portlet. Consequently, each application, service, and utility can be developed, maintained , and updated independently. Within this framework it is easy to see how the functionality being provided by a portlet could be delivered using one or more Web services. Figure 1.11 highlights the potentially very powerful, synergistic, and symbiotic relationship between portlets (or equivalents) and Web services. This figure also helps to demonstrate that the Web services to portlet relationship may be one-to-one (i.e., a portlet relies on a single Web service) or many-to-one (i.e., a portlet synthesizes functionality obtained from multiple Web services). It is also worth noting that it would also be possible (and even normal) for a particular Web service (e.g., a currency or metric unit converter) to be used by multiple portlets within the same portal view.
Figure 1.11: The possibilities of using Web services to provide content and services for portals are immense and hard to ignore. Here we see just a few examples using a personalized Lycos public Internet portal. It highlights how individual portlets making up a portal view can be driven by one or more Web services working in the background.
Portlets provide modularization and function isolation. Web services, in turn , provide modular, self-contained, remotely invoked software functionality. Furthermore, the software functionality available in the form of Web services will be totally standards compliant and will work on any platform irrespective of the portal server software being used. In addition, the software functionality being provided by a Web service can easily be modified or upgraded on the fly without any changes whatsoever to the portal application, the portal server, or even the portlet per se. This is the beauty of bringing together Web services and portlets. It provides a near-perfect, foolproof mechanism for conveniently obtaining portal functionality via a highly standardized outsourcing model.
Rather than trying to develop functionality in-house or obtain specific functionality by purchasing a software package, portal providers can now start thinking about a powerful, best-of-breed, mix-and-match, software component “oriented solution model based on Web services. Consequently, it should not come as a surprise that portal server providers in general are extremely supportive of Web services ”with market leaders Oracle and IBM going out of their way to demonstrate how Web services can enhance portals. To this end, Figure 1.12 shows a Web page from Oracle showing sample applications of how Web services can be integrated into a portal, with the first example being of a zip code “driven Web service that delivers various local information feeds in real time, such as current weather and time.
Figure 1.12: A Web page from Oracle that sets out to demonstrate how Web services can be easily integrated with its market-leading portal server offering by showing various sample applications, with the first one shown being a zip code “driven local information retrieval scheme; the second example is a generalized, media- agnostic messaging service.
The bottom line in this instance is that portals can be considered to be the killer application for Web services. This bodes well for the eventual success of Web services because portal deployment, as well as overall portal usage, is on the ascent. Most mid-size to large-size enterprises now realize that portals are an optimum, very low-cost, far-reaching way to interact with customers, prospects, employees , partners , and investors, whether it be to deliver information, provide transactional services, communicate with them, or collaborate with them in real time (e.g., Web-based Webex -type conferencing). Within this context it is also important to note that portals have also become the preferred vehicle through which enterprises want to deliver new e-business applications. Portals, in addition to offering unprecedented total global reach via the Internet, also offer proven security, user authentication, personalization, usage tracking, and change management. Portals thus make the whole process of new application rollout that much easier, efficient, and efficacious. Therefore, portals are also playing a key role in promoting the deployment of new e-business applications ”another acknowledged growth area for Web services.
1.2.2 Why Web services are galvanizing legacy modernization
When it comes to Web services, legacy modernization is at the other end of the spectrum from where portals fit into the picture. Portals represent the consumption side of Web services. Legacy modernization, in the main, has to do with the supply side. Portals, in this context, are all about new applications (and portlets) obtaining requisite functionality by invoking Web services. Legacy modernization, on the other hand, is about using Web services to capture and expose existing business-critical functionality. This functionality would be located within proven mission-critical applications.
Web services thus enable existing and highly proven business logic to be gainfully reused within new applications. Interestingly, portal applications happen to be prime candidates for reusing functionality culled from existing mission-critical applications ”given that portals are becoming the preferred corporate mechanism for hosting new applications. Modernization as such, in this context, refers to the creation of new applications based on functionality found in legacy applications.
It is now widely accepted within IT technical circles that much of the proven, highly valuable , business-critical functionality that is still embodied within decades-old legacy applications needs to be converted over the next few years into Web services. This is especially true when it comes to the $20 trillion worth of IBM mainframe and AS/400 applications that were known as SNA applications ”where SNA, which stands for IBM s once-legendary Systems Network Architecture, represented the networking scheme used by these applications to serve large populations of online users. So, to paraphrase that adage about old soldiers, one can now say, without really any fear of contradiction, that old SNA applications, though now over 20 years in age, never die ”they just fade away to become Web services.
Web services provide a standards-based mechanism whereby timeless legacy software functionality, which has been in daily production use since the 1980s, can be profitably reused when developing new applications in 2004 or beyond. This is what legacy modernization is all about. Legacy modernization is possible without Web services. However, Web services make it that much more structured and sanitized. Web services, in effect, legitimize the rationale and the expense of legacy modernization.
Legacy applications, as previously mentioned, are prime candidates to be sources of Web services ”as opposed to consumers of Web services. An application that relies on software functionality provided by a Web service can be thought of as a Web service consumer. Though there is nothing technical that precludes existing legacy applications from becoming Web service consumers, this, however, is unlikely to be the case in practice. A legacy application will only need to become a Web service consumer if one is thinking of extending its current functionality to include capabilities best obtained in the form of Web services.
Web service consumption by legacy applications, in the end, boils down to the economics and practicality of modifying and extending applications that in many cases were developed even before the advent of the PC. Most of these applications were written in COBOL, BAL, PL/I, or possibly even FORTRAN. Rather than trying to modify the code of these applications (which is what many enterprises had to do to accommodate Y2K), a better way to extend their functionality would be in terms of what is known as host integration . Host integration, a technology that evolved from host access and Web-to-host, can be thought of as a precursor to legacy modernization.
Since at least 1999, host integration was always positioned as the final frontier of the Web-to-host repertoire of solutions, where Web-to-host dealt with how applications running on mainframes, IBM AS/400s, and other mini-computers (including UNIX servers) could be accessed using Web technology. Applet-based terminal emulation, as with IBM s Java-based Host On-Demand product, was one way to realize Web-to-host. Another approach was to rely on 3270/5250-to-HTML conversion (e.g., Hummingbird s e-Gateway), which enabled cost-effective Web browser “based access to existing SNA applications running on mainframes or AS/400s.
Host integration went to the next step and talked about how existing SNA applications can complement new Web applications. It was all about reusing the proven software functionality found within SNA applications. Web services provide the ideal mechanism for this software reuse scenario ”hence, the now-close interplay between SNA applications, host integration, and Web services. Figures 1.13 and 1.14 illustrate different host integration scenarios and show how Web services will come into play vis--vis host integration in the future. However, after all the monies that were expended on the Y2K conversion, most IT organizations are reluctant to make any more large-scale extensions to decades-old legacy applications. Consequently, legacy applications are unlikely to be major consumers of Web services.
Figure 1.13: A typical host integration scenario, in this instance for a portal application that is to be realized with JavaBeans and JSP portlets, using NetManage s OnWeb host integration product to create the JavaBeans and IBM s WebSphere Portal Server to run the JavaBeans bearing JSPs and invoke the necessary host transactions via OnWeb at run time. In the future the legacy application functionality could be provided in the form of Web services rather than JavaBeans using this same overall setup.
Figure 1.14: Another host integration scenario, in this case showing Seagull Software s Transidiom offering, which happened to be the first product of this genre to support Web services vis--vis host integration. Transidiom allows legacy business logic that is captured in the form of its proprietary WSP definitions to be used by new applications in the form of Web services.
On the other hand, legacy applications (and in particular SNA applications) are veritable smorgasbords when it comes to pertinent business logic that can be packaged for reuse as Web services. This also ties in with the very hot and strategic interest in business process integration and enterprise process management.
1.2.3 Why Web services impinge on business processes
The lifeblood of any enterprise is its business processes. Processes are what make any business tick. It is these processes that shape and sustain a business. They are the internal nervous system of an enterprise that makes sure that things get done. It is processes that differentiate businesses that are engaged in the same line of business. The success of a business is shaped to a large extent by the efficacy and efficiency of the processes it employs. Processes even influence the vision of a corporation.
Let us use an insurance company as an easy-to-visualize example (Figure 1.15). In an insurance company there will be multiple processes that relate to the issuance, updating, and canceling of customer policies. Though there may be some processes, and especially subprocesses, that are manual, these days most insurance companies, in most countries , would rely on automated (i.e., computerized) processes for much of their mission-critical operations. Consequently, each automated business process will typically involve the invocation of multiple applications or the use of one integrated application that performs multiple tasks . Figure 1.16 uses a new policy issuance process that is likely to be employed by a typical insurance company to show the overall subprocess-oriented composition of a business process and how these subprocesses are likely to be handled by different applications.
Figure 1.15: A typical insurance company “related business process ”characterized here by CRM heavyweight Siebel Systems. It depicts a generalized new policy issuance process. Note that it involves six applications, including the call-center application.
Figure 1.16: Associating Web services with subprocesses that make up a process ”in this case the new insurance policy issuance process, courtesy of Siebel Systems, shown in Figure 1.15.
Automated business processes are thus made possible by applications. Business applications (and in particular mission-critical legacy applications) therefore embody umpteen proven and critical business processes. Trying to accurately reproduce these processes in new software can be a difficult, arduous, and risky endeavor, since even the slightest deviance from the original (e.g., even the way that numbers are rounded at the sixth decimal point) could significantly alter the desired end result. Thus, the existing software representation of these processes has intrinsic value. This is the software equivalent of knowledge. Web services provide an ideal mechanism for profitably reusing these process-related software assets. Figure 1.16 highlights this capability by taking the new policy issuance process shown in Figure 1.15 and showing how some of the subprocesses can be associated with Web services ”either in terms of consumption or resale.
With Web services, business processes can be isolated, neatly packaged, and readily marketed for use by new in-house applications being developed (as in legacy modernization) ”or even by other companies. On the flip side, Web services also now become the obvious way by which to source required process-related functionality when developing new applications. Web services, moreover, as previously discussed, are totally platform independent, so there are no real issues whatsoever about whether an application being developed to run on a particular set of platforms will be able to use Web services culled from legacy applications that are running on a different set of systems.
Web services provide those involved with business process software with an elegant, platform-independent, distributed computing mechanism based on remote invocation. With Web services, the process-related software functionality that is being reused, rather than being cut and pasted from the old application to the new, continues to run on a host platform and interacts with the new application in terms of dynamic (XML-based) I/O calls. Furthermore, thanks to Web services, the functionality of business process “ related applications can be significantly enhanced without requiring any changes whatsoever to the source code of the original application. Rather than adding new code to the existing application, you can create new code based on Web services that run as separate software instances and interact with the original application at run time.
![Web Services[c] Theory and Practice](/icons/blank_book.jpg "Web Services[c] Theory and Practice"){kind=icon}