Chapter 1: Web Services: What, Why, and Where?


What s in a name? That which we call a rose by any other name would smell as sweet.

”Shakespeare

Overview

Web services are modular, self-contained applications or application logic developed per a set of open standards. That much is immutable and indubitable. There is even concurrence of this application-centric viewpoint from the World Wide Web Consortium (W3C) (http://www.w3.org), the ultimate ratifiers of Web- related interoperability standards and in effect the godparents of Web services. W3C now has a definition, albeit in draft form, of Web services, within the emerging Web Services Architecture specification, which states categorically that a Web service is indeed a software system. This stake in the ground from W3C goes a long way toward helping rationalize prior conflicting views on exactly what constitutes a Web service, though it is only fair to note that this decisive description was formulated 2 years after the advent of Web services.

A Web service, however, is typically not meant to be a full-blown, feature-rich application in its own right ”even though, there are no restrictions as to how long, big, or complex a Web service can or should be. First, a Web service does not necessarily have to possess a user interface. This alone runs counter to most people s concept of what constitutes an application. Consequently, a Web service, though it needs to be characterized as an application for technical integrity, is better thought of as a mini-application, possibly even an application segment, or better still as an application enabler .

Some other terms that may also be used to convey the true essence of a Web service are as follows :

  • Subroutine

  • Software building block

  • Reusable object

  • Software component

  • Chunk of business logic

  • Entry (or member) from a software library

  • Remote procedure (or even possibly remote procedure call)

  • Business process representation

The absence of terms pertaining to protocols, software services, or middleware in the previous list (such as a reference to SOAP or WSDL) is intentional, as opposed to being an omission or anomaly. A few examples of what Web services can be, at this juncture, should help clarify the choice of terminology that has been used so far. It will also permit the discussion of why a Web service is not necessarily a middleware service in the traditional sense to be deferred until a bit later. Here are some quintessential examples of the type of functions that can and should be provided by a Web service:

  • Credit card authorization

  • International currency converter (e.g., U.S. dollars to U.K. pounds )

  • Purchase or VAT tax calculator

  • Stock quote provider

  • Package delivery status locator

  • Shipping rate calculator

  • Customized search capability

  • Local weather bug

  • Driving directions between two places

  • Insurance rate quote provision (e.g., auto insurance)

  • Personalized horoscope readings

  • Local traffic report updates

  • Airline flight schedules between designated cities

  • Specialized user authentication techniques (e.g., two-factor authentication, as with RSA s SecurID system)

  • Customer warranty status lookup

  • A specialized purchase order processing mechanism between two companies

  • Personnel (e.g., service technicians or equipment installers ) dispatch scheduling per a workflow management scheme

A picture is worth a thousand words at this point. Figure 1.1 illustrates how a future Web application could make use of Web services. This hypothetical Web application is intended to provide a wish you were there vacation planning and vacation reservation function. To achieve this objective, this application is shown gainfully exploiting multiple Web services, from disparate sources, to synthesize a highly compelling, very up-to-date, full-function, and seamless user experience. The rich and topical functionality, available in the form of Web services from third parties, ensures that this application can be flexible, extensible, easily modifiable, and, above all, highly effective.

click to expand
Figure 1.1: A hypothetical, very persuasive, wish you were there multimedia vacation planning and vacation reservation application that relies heavily on software functionality obtained in the form of Web services from diverse sources.

Rather than trying to create and maintain all the software required by such an application, Web services enable the application developers to pick and choose, at will, proven, best-of-breed utility functions from around the Web ”and easily plug them into their applications. This is the crux of what Web services are all about. Web services elegantly and systematically extend the potential sources for remotely invocable software components to now include the Web.

All the excitement about Web services revolves around this Web-centric value proposition. The reach and diversity of the Web is obviously incomparable when it comes to a 24/7 super-mall for software components. The Web is already awash in software of every conceivable type, and Web services provides a formal mechanism by which some, if not much, of this existing functionality can be repackaged, formally publicized, and then profitably reused. Moreover, the software talent pool available via the Web, both commercial and altruistic, is unprecedented and beguiling .

With Web services, the Web can become a mouthwatering, veritable software smorgasbord for application developers ”hence, the basis of the name: Web services (i.e., software services for applications obtained over the Web). In exactly the same way that the Web has now become the undisputed, must check first source for merchandise and services, whether it be rare Alexandrite gems from Sri Lanka, first editions of John Irving, or ocean-view hotel rooms in Newport, Rhode Island, with Web services the Web becomes a primary source for modular software. Thanks to Web services, you can now develop new Web applications, relatively quickly, that consist of software components from multiple, diverse sources that have been dynamically assembled and loosely coupled together. Figure 1.2 sets out to present a generic view of what Web services are all about (i.e., the concept of Web applications that rely heavily on remotely invoked software functionality from third parties). It is, however, worth keeping in mind that Web services could also be gainfully used on an intranet basis (i.e., within a single enterprise) without recourse to the Web.

click to expand
Figure 1.2: Generic view of what Web services are all about ”which is the concept of applications being able to readily invoke required software functionality across the Web.

The pick-and-choose and plug-and-play of Web services are only possible because of standards ”in particular, XML (i.e., the eXtensible Markup Language). XML is a platform, programming language and markup language independent scheme for sharing data in an unambiguous and consistent manner. It is, however, the underlying basis for Web services, so much so that within some technical circles today s Web services are referred to as XML Web services .

Web services operate by interchanging data that is in the form of XML. The reliance on XML-based data is the fundamental premise of Web services. To be even more precise, it should be noted that the data interchange is done using XML documents. Thus, the input parameters to a Web service are in the form of an XML document. The output of a Web service will also always be an XML document.

Though a Web service is a software component, XML per se is not a software component, a programming language, or even a scheme in any way associated with programming or software. Nor is it an enhancement or replacement for HyperText Markup Language (HTML), the format control standard for contemporary Web pages. Instead, XML is a meta-markup language for documents ”in particular, documents containing structured information. Most documents have some level of structure in that the information they contain is invariably made up of content (e.g., text and graphics) and context (e.g., headings, tables, captions). XML s forte is its ability to clearly, cleanly, and consistently describe the context and meaning of the data vis--vis that document.

XML enables all types of information to be exchanged across disparate systems in an easier and better manner than was possible in the past. XML provides data from disparate applications and platforms with a standardized interchange format. This is the pivotal XML capability that is leveraged by Web services. With XML it does not matter whether the data were produced by a proprietary application and were originally structured in a manner that could only be interpreted by that application. XML thus becomes a standard way to describe structured data irrespective of whether these data belong to a spreadsheet, an electronic address book, a customer relationship management (CRM) application, an operating system configuration file, a financial transaction, or to a technical drawing. Web services would not be possible if not for the universal, no strings, no caveats, any-application-to-any-other-application data interchange capability made possible by XML.

XML permits data to be shared. Web services extend this to permit software functionality, in particular existing business logic, to be shared and reused when it comes to application development. This software interoperability is realized through the exchange of XML documents. Let us take as an example a package tracking application as offered by the likes of FedEx, UPS, and the U.S. Postal Service, where Figure 1.3 shows the heavily used FedEx tracking system. The applicability and appeal of such a tracking function vis--vis e-commerce, supply chain management (SCM), or even some CRM applications are intuitive. Nonetheless, in the absence of Web services (or similar), embedding existing tracking functionality (e.g., the FedEx service) into other applications is not being practical. Instead, most e-commerce applications provide a tracking number and a clickable hot link to the tracking function of the shipper being used.

click to expand
Figure 1.3: The package tracking function on the FedEx portal, which debuted way back in 1994. A package tracking function such as this, or from another source, is an ideal candidate to be made into a Web service that can then be dynamically invoked by other applications ”for example, e-commerce applications ”so that users can continue to log on to that application to check the status of their shipments rather than having to link or be redirected to another site to gain access to the tracking functionality.

This approach works, and works well, but has various drawbacks ”the primary one being that the e-commerce application is relinquishing the user to another site. This runs counter to the concept of keeping a customer captive and captivated. From an e-commerce standpoint it is the equivalent of a store clerk telling a customer who inquires about gift wrap options that he or she needs to go to another store to get that done. If package tracking functionality from the various vendors were available as Web services, then the e-commerce, SCM, and CRM applications could have them neatly integrated within the applications and thereby obviate the need to redirect users to other Web sites. Web services enable applications to offer additional value-added functionality via the seamless integration of third-party software components.

The bottom line here is that Web services can simplify the application development process. This potential simplification can be exploited to realize, at a minimum:

  1. Marked compression of application development schedules ” with a commensurate reduction in development costs.

  2. Specialized and customized niche applications, which would have been difficult to cost-justify in the past.

  3. Additional value-added functionality within applications without incurring the dreaded penalty of prolonged development schedules.

  4. Quick updates to application functionality to reflect changing circumstances (e.g., activation of new tax regulations), since the necessary changes will be made to the various affected Web services by their providers, obviating the need for the application support team to identify and implement all the changes. On this note it is worth reflecting that the Y2K application conversion extravaganza would have been considerably easier, less expensive, and more low-key if these legacy applications had been developed using dynamically invoked third-party software functionality via something similar to Web services, rather than being all-inclusive monoliths.

  5. Faster application testing and certification, since the functions being provided by the Web services will, at least in theory, have already been field- tested and proven.

  6. More reliable and resilient applications immediately, since the use of proven, best-of-breed third-party Web services for some of the functionality minimizes the amount of brand-new , in-house developed code content within an application

These factors can have a very positive influence on sacrosanct corporate criteria, such as competitiveness , productivity, profitability, and even the bottom line. Furthermore, the applicability of Web services is not restricted to companies or individuals developing software. Any company that owns its own suite of applications, irrespective of their type, nature, and vintage , can consider offering some of the software functionality embodied in these applications as Web services. Thus, Web services are a way that Fortune 5000 companies that have spent small fortunes developing their own mission-critical applications over the last 3 decades can now reap additional ROI from these highly proven pieces of software. Hence, large corporations with in-house application development teams could end up being both consumers and providers of Web services.

This is why there is so much fuss and excitement about Web services. Web services usher application development into a new, highly Web-centric era. Web services provide a formal and systematic framework whereby the reach of the Web can be leveraged to promote and foster software reuse.




Web Services[c] Theory and Practice
Web Services[c] Theory and Practice
ISBN: 1555582826
EAN: N/A
Year: 2006
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net