eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
This is a soup-to-nuts reference guide on all aspects of Web Services - where Web Services is a fast emerging set of Internet-specific middleware technology to further promote the growth of all aspects of e-business via standardization, collaboration and "franchising." This book is best characterized as an executive brief for IT and senior management rather than a nuts-and-bolts technical guide for portal implementers. Think of it as the "Cliffs Notes on Web Services." Given this audience, the book consistently focuses on business needs, value propositions, ROI, proven solutions and actual examples of current implementations. Each chapter also ends with a 10-item "Q&A" section that consolidates and summarizes the information discussed in the chapter. The book is illustrated with detailed technical diagrams, includes lots of arresting subtitles and contains many bullet lists and tables to facilitate (and encourage) productive skimming.
Decision makers - the intended readership for this book - gain increasing comfort and confidence as they get into the book that they are getting to see all facets of the issues, on a consistent basis, and that they will not be blind-sided at meetings by people asking 'difficult' questions. At the end of each chapter, Guruge summarizes and reinforces key points, allowing the reader to skim through the topics for crucial information. The book also leverages living outside resources and ensures that the readership always has ready and consistent access to any and all terms, definitions and concepts they might not be familiar with.
"Debate style" presentation, focusing repeatedly on pros-and-cons, e.g., .NET vs. Java, open vs. proprietary and buy vs. build
Author's trademark detailed architectural and network diagrams of portal implementations
Q&A section at end of each chapter
Product Details
| ISBN-13: | 9780080520957 |
|---|---|
| Publisher: | Elsevier Science |
| Publication date: | 04/08/2004 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 371 |
| File size: | 9 MB |
About the Author
Anura Gurugé is an independent technical consultant who specializes in all aspects of contemporary networking, corporate portals and Web services - particularly if they involve IBM host systems. He has first hand, in-depth experience in Web-to-host, SNA, Frame Relay, Token-Ring switching and ATM. He was the founder and Chairman of the SNA-Capable i·net Forum in 1997. He also teaches graduate and post-graduate computer technology and marketing at Southern New Hampshire University (SNHU) - Laconia/Gilford and Portsmouth campuses. He is the author of Corporate Portals Empowered with XML and Web Services (Digital Press, 2002). In addition, he has published over 320 articles. In a career spanning 29 years, he has held senior technical and marketing roles in IBM, ITT, Northern Telecom, Wang and BBN. His Web sites are: www.inet-guru.com and www.wownh.com.
Read an Excerpt
Web Services
Theory and PracticeBy Anura Gurugé
DIGITAL PRESS
Copyright © 2004 Elsevier Inc.All right reserved.
ISBN: 978-0-08-052095-7
Chapter One
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
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.
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.
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.
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
(Continues...)
Excerpted from Web Services by Anura Gurugé Copyright © 2004 by Elsevier Inc. . Excerpted by permission of DIGITAL PRESS. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
What?, Why—and When?; XML - The backbone of Web Services; Microsoft's Web Services; UDDI; SOAP; Java Web Services; Deploying and Managing Web Services; Living and Breathing Web Services; References & Bibliography; Acronyms; Glossary