List of Figures

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

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.

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

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 applicationsfor example, e-commerce applicationsso 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.

Figure 1.4: Web services are totally platform independent, with no caveats, and as such it is possible for an application running on a Windows 2000 server, for example, to rely on functionality obtained from Web services running on vastly different platforms.

Figure 1.5: Given the total platform independence of Web services, it is even possible for applications running on different platforms to act as Web service users and providers to each other, at the same time.

Figure 1.6: Portlets, the individual window panes within an overall portal view.

Figure 1.7: Performing a search for weather services using Microsofts UDDI registry, where the first 7 of the 20 services found are displayed on the left-hand results tab.

Figure 1.8: Another search for weather services, this time using IBMs UDDI Business registry, which serves to illustrate that the UDDI register nodes will differ in their implementation details.

Figure 1.9: The generic Web services operational model introduced in Figure 1.2 is now extended to show where XML, SOAP, WSDL, and UDDI come into play.

Figure 1.10: Web services are a standardized, platform, and programming language independent mechanism for recycling software functionality.

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.

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 codedriven local information retrieval scheme; the second example is a generalized, media- agnostic messaging service.

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 NetManages OnWeb host integration product to create the JavaBeans and IBMs 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 Softwares 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.

Figure 1.15: A typical insurance company related business processcharacterized 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 processin this case the new insurance policy issuance process, courtesy of Siebel Systems, shown in Figure 1.15.

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

Figure 1.18: A screen shot related to testing a newly created Web service from IBMs WebSphere Studioone of the premier tools for developing, deploying, and using Web services.

Chapter 2: XMLThe Backbone of Web Services

Figure 2.1: Role of XML vis--vis the workings of a Web service.

Figure 2.2: A poem by William Wordsworth described using XML. Courtesy of Rutgers, State University of New Jersey (www.ceth.rutgers.edu).

Figure 2.3(a) A small and simple Excel spreadsheet.

Figure 2.3(b) The initial part of the XML document created by Excel to describe the spreadsheet shown in Figure 2.3(a).

Figure 2.4: A sample of some of the editing and proofreading marks (i.e., markup symbols) that were employed when a manuscript was being prepared for publishing in the pre-electronic era. Source: inkwelleditorial.com.

Figure 2.5: Actual example of a marked -up manuscript, in this case a book by Ellen Raskin, as shown on the University of WisconsinMadison Web site.

Figure 2.6: Example HTML code rendered by a Web browser.

Figure 2.7: A proposed DTD from the HR-XML Consortium for describing a persons name in XML form for HR applications, where the term #PCDATA refers to parsed character data, which is a fancy way of saying that this is a string of text. This and other DTDs and schema can be found at xml.org.

Figure 2.8: Microsofts XML Notepad showing its two-pane structure, where the left-hand pane maps out the XML structure, whereas the right-hand pane shows the values associated with the various XML elements.

Figure 2.9: An example of a WSDL definition of a Web service, in this case a Web service for airline reservation applications, as shown in the W3C specification for WSDL Version 1.2.

Chapter 3: Microsofts Web Services

Figure 3.1: One of Microsofts perspicacious depictions of Web services (see Web services model introduced in Figure 1.2).

Figure 3.2: The product packaging of Microsofts Visual J++ Release 6.0 offering.

Figure 3.3: An example from Microsoft of the highly visual, integrated development environment available with the Java-based Visual J++ software development tool.

Figure 3.4: Web servicesrelated 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.

Figure 3.5: The visual programming paradigm of Microsofts Visual BASIC software development environment with annotations by Professor Saul Greenberg, University of Calgary, Canada.

Figure 3.6: Part of the system requirements for Visual Studio .NET 2003 Web page from Microsofts 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.

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 .

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.

Figure 3.10: Microsofts depiction of .NET Framework as a sausage machine for churning out XML Web services.

Figure 3.11: Checking to see if the .NET Framework is installed on a Windows system using the standard Windows Add or Remove Programs control panel.

Figure 3.12: The high-level architecture of the .NET Framework, per Microsoft, which is made up of the Common Language Runtime (CLR) and a .NET Framework Class Library.

Figure 3.13: Minimum system requirements for all editions of Visual Studio .NET 2003, per Microsofts Web site.

Figure 3.14: Microsofts .NET Passport home page at www.passport.net, which talks about the free, single sign-on service, as well as the powerful security features that are there to protect ones profile information.

Chapter 4: Universal Description, Discovery, and Integration

Figure 4.1: The four key UDDI data structures, based on the model shown in various UDDI documents.

Figure 4.2: The four core and original UDDI data structures shown in Figure 4.1 extended to show the two additional structures that were introduced in the later versions of the UDDI specification.

Figure 4.3: The Web-based user interface to SAPs UBR node.

Figure 4.4: The UDDI information content per the telephone directory model.

Figure 4.5: Correlating the UDDI telephone directory model with UDDIs four core data structures.

Figure 4.6: A simplified and rationalized version of the original How UDDI V1 Works model postulated by UDDI.org in September 2000.

Figure 4.7: Post-2003 UDDI scenarios, where the UBR will be complemented by affiliated private and semiprivate UDDI Registries.

Figure 4.8: The businessEntity structure, as defined in the UDDI V2.03 Data Structures Specification, in relatively easy-to-follow XML schema notation, showing which elements or attributes are required (i.e., use=required), those that can be repeated (i.e., maxOccurs=unbounded), and those that are optional (i.e., minOccurs=0).

Figure 4.9: The business provider information for IBM, as it appears in Microsofts UBR node, illustrating how data maintained in a businessEntity structure, as shown in Figure 4.8, get utilized. The long, hexadecimal Provider Key, which appears near the middle of the Web page, corresponds to the unique business key identifier for this entry. Also note the tabs for services, contacts, identifiers, categories, and discovery URLs, which correspond directly to elements within the businessEntity structure. The Name entry, which appears after the first blocked-out horizontal bar, in this instance, only has one entry and that is in English, as denoted by the (en). It would have been possible to have multiple entries here.

Figure 4.10: The D-U-N-S, nine-digit identification for IBM shown in the Identifiers tab as it appears within IBMs entry at Microsofts UBR node.

Figure 4.11: The start of the 170 categorizations IBM lists for the services and products it offers using a combination of NAICS and UNSPSC codes. On the other hand, Microsoft, uncharacteristically self-effacing, only lists one categorythat being the NAICS 51121 code for a software publisher.

Figure 4.12: A businessEntity presentation for another service provider, in this case for Anura Guruge, as displayed on IBMs UBR node, showing the 32-digit hexadecimal key for this entry. Compare this presentation with how Microsoft displays businessEntity information, shown in Figure 4.9, and note that although IBM just refers to the UDDI key as the key, Microsoft calls it the Provider Key and uses lowercase to display the hexadecimal code, whereas IBM opts for the more traditional uppercase.

Figure 4.13: BusinessEntity display for IBM, at IBMs UBR node, confirming that the UUID key for this entry is exactly the same as that shown in Microsofts UBR node, per Figure 4.9, with IBM, however, displaying the hexadecimal digits in uppercase versus the lowercase depiction preferred by Microsoft. Also note that IBMs presentation includes the business description, as well as the categorizations (i.e., Business Locator[s]), and that these categorizations are listed in the same order shown in Figure 4.11.

Figure 4.14: The Web services stack showing the basic relationship between the various Web services enabling technologies and UDDI.

Figure 4.15: NTT Communications Japanese-centric UBR node.

Figure 4.16: The Register tab on the OASIS UDDI front page, which will take you to a page that shows how to access one of the UBR nodes.

Chapter 5: SOAP

Figure 5.1: SOAPs modus operandi. It is transport and network independent and always works application to application, application to Web service, Web service to Web service in sender-receiver mode, where a SOAP node can act as both a sender and a receiver since most SOAP interactions work via some form of request-response exchange.

Figure 5.2: Some of the possible SOAP node/endpoint configurations. The terms endpoint and node are essentially interchangeable when it comes to SOAP. The former was popular in the early days of SOAP, though SOAP 1.2 tends to emphasize the latter.

Figure 5.3: SOAPs transport-independent stack, realized via the protocol binding layer, shown here in its generic form (on top) as well as with some popular implementational options.

Figure 5.4: An example of an actual SOAP fault message, in this case indicating the failure to process an RPC request, as shown in the SOAP 1.2 Primer, illustrating the possible use of fault codes, a fault reason, and a detailed description of the fault.

Figure 5.5: The overall structure of a SOAP message highlighting that the entire message is made up of a SOAP envelope that consists of an optional header and a mandatory body, which contains the actual payload.

Figure 5.6: Example of a representative and complete SOAP messagein this case a travel reservation example, as included in the SOAP 1.2 Primer.

Figure 5.7: The composition of a real SOAP messagein this case the eOrder message used at the start of this chapter.

Figure 5.8: The contents of http://www.w3.org/2003/05/soap-envelope showing the formal specification of all the elements and attributes that can occur within a valid SOAP message.

Figure 5.9: IBMs high-level description of its highly promoted, Java-oriented, WebSphere Studio Application Developer, showing the built-in support for SOAP and other Web services related protocols.

Chapter 6: Java and Web Services

Figure 6.1: Platform independence la Web services is different from the genuine software portability across platforms offered by Java.

Figure 6.2: The significance and relevance of Java to an enterprise is usually related to the size of the enterprise.

Figure 6.3: Screen shot of the Internet Options for Microsofts Internet Explorer (IE) 6.0 showing the reference to Microsofts version of the virtual machine for running Java including mention of a JIT compiler.

Figure 6.4: The cross-platform portability of Java is realized by first having all Java programs compiled into a platform-independent bytecode and then using interpreters within the Java virtual machine on a specific platform to interpret the bytecode.

Figure 6.5: A picture of a Java-based smart card from the java.sun.com Web site.

Figure 6.6: The concept of a Java platform, consisting of a JVM and a Java API, on a specific computing platform.

Figure 6.7: Suns depiction of the three Java 2 editions, J2EE (at left), J2SE, and J2ME, and how they stack up against each other.

Figure 6.8: Suns representation of a possible J2EE-based n - tier model, highlighting the component-oriented nature of J2EE as well as the fact that in such a model it is possible to have Java on both the client and server sides.

Figure 6.9: The Java application model divides enterprise applications into components , containers, and connectors.

Figure 6.10: The J2EE platform per Sun showing how it provides a set of standard services built upon the basic services provided with J2SE.

Figure 6.11: The key features of the latest WebSphere Application Server V5.0.2, per IBM.

Figure 6.12: Some of the key features of the latest BEA WebLogic Server 8.1 per BEA.

Figure 6.13(a) A representative screen shot from IBMs WebSphere Studio Application Developer, highlighting its highly visual, drag-and-drop software development paradigmin this instance, manipulating EJBs.

Figure 6.13(b) Another screen shot from IBMs WebSphere Studio Application Developer, in this case showing the dynamic creation of a user interface for a Java application using JSPs.

Figure 6.14: Creating JSPs with BEAs WebLogic Workshop.

Figure 6.15: High-level architecture of IBMs Java-based host integration product, WebSphere Host Publisher (at the V3.5 level), showing where EJBs, JSPs, XML, and the WebSphere Application Server come into play.

Figure 6.16: A screen shot of Suns Java Desktop, replete with productivity software akin to those offered by Microsoft Office, which is now being positioned as an obvious, cost-competitive, and secure alternative to Windows.

Chapter 7: Deploying and Managing Web Services

Figure 7.1: While the original Web-services model envisaged Web services being freely invoked across the Internet, the current corporate preference is the intranet/extranet model.

Figure 7.2: Areas where security in a Web-service configuration may be compromised.

Figure 7.3: Using a Web-services gateway to act as an XML application-level firewall between the calling application inside the corporate firewall and an externally invoked Web service.

Figure 7.4: All of the Web servicesrelated entities that need to be protected to guarantee adequate end-to-end security.

Figure 7.5: Details of digital certificate usage shown by Microsoft's Internet Explorerin this case, for a secure, authenticated connection with the Charles Schwab portal.

Figure 7.6: One of VeriSign's public-key infrastructure (PKI)-based digital certificate solutions.

Figure 7.7: RSA's Keon, one of several products now available that would enable a company to act as a certificate authority (CA).

Figure 7.8: The overall big-picture depiction of the dual-key concept of public-key cryptography.

Figure 7.9: The locked padlock signifying a secure SSL connectionin this instance, for online banking with the Meredith Village Savings Bank in New Hampshirealong with a superimposed browser properties window showing that SSL 3.0 with encryption is in use.

Figure 7.10: High-level view of the process involved in setting up a secure SSL connection between a Web server and a Web browser user. This process is the same for secure SSL connections between other client/server pairs, including an application and a Web service.

Figure 7.11: Some of the possible pricing models for Web services, depending on their source.

Figure 7.12: Key features of Suns Management Center 3.5, which includes Change Manager and Service Availability Manager.

Figure 7.13: A composite of material from Computer Associates Web site showing its perspective on system management. Keep in mind that CA has a long and respected track record in the management arena.

Figure 7.14: AmberPoints overview of its Web servicesspecific management solution.

Figure 7.15: The magnifying glass icons in this diagram signify the Web servicesrelated entities that need to be monitored and managed with the new application model.

Figure 7.16: The concept of a management portal, as exemplified by CAs Unicenter Management Portal.

Chapter 8: Taking Stock of Web Services

Figure 8.1: Googles much sought after search capability, now spanning in excess of 3 billion Web documents, is now available as a bona fide Web service that supports SOAP and WSDL.

Figure 8.2: amazon.com, eager to stimulate interest in Web services and to promote its own powerful brand name, now offers the catalog, search, and e-commerce features of its redoubtable portal in the form of genuine XML Web services.

Figure 8.3: Web services extend the hitherto primarily interactive, people-driven Web experience to now include programmatic access involving applications and software components.