Previous Section Next Section

The Web Service Opportunity

The Web services approach is an application integration concept; it is a set of technologies that provides access to business functionality, such as purchase order processing. Often, the business functionality already exists in the form of legacy transaction processing systems, existing Web applications, Enterprise Java Beans, and so on. Web services technology is about access and application integration; it is not an implementation technology.

Organizations use Web services technology in two broad categories: Enterprise Application Integration (EAI) graphics/book.gif and business-to-business (B2B) graphics/book.gif partner integration over the Internet. In either of these categories, Web services can range in sophistication from simple request response functions such as a credit card check to very complicated multi-party, multi-stage long-running business transactions such as a supply configuration and order system. Web services can be invoked by PC-based programs, mainframe systems, Web browsers, or even small mobile devices such as cell phones or personal digital assistants (PDAs).

Regardless of the application, Web services will be used for systems integration: flexible, loosely-coupled systems integration yielding systems that can be decomposed and recomposed to reflect changes in the business.

Enterprise Application Integration

Enterprise Application Integration is still a field where large consulting companies command multimillion dollar contracts to help their clients deal with a mess of applications that were never meant to interoperate.

The state of the art within many enterprise systems remains that of large, monolithic application "silos." These systems are often extremely difficult to change, let alone integrate with other systems. These applications often define unique data formats, and sometimes (for historical, often performance-related reasons) even define their own communications protocols. Furthermore, many systems, particularly in large organizations, can exist on multiple different platform technologies. Interoperability between systems is a significant challenge. In many organizations, particularly organizations that result from a merger of two previously independent companies, IT integration costs can seriously impact the financial health of the company.

The Web services approach offers an attractive set of technologies by which existing legacy systems can be wrappered as Web services and made available for integration with other systems within the organization. Applications exposed as Web services are accessible by other applications running on different hardware platforms and written in different programming languages. Using this approach, the complexity of these systems can be encapsulated behind industry-standard XML protocols. Pair-wise system integration projects can be replaced with one-to-many systems interactions based on Web services. The promise of higher-level interoperability initiatives is that over time we will be able to develop the set of standards, technologies, and tools that will enable small and large businesses all over the world to easily integrate systems internally, and then mix and match the implementation of various activities within a business process, maintaining the option to, at any time, choose to outsource any or all of these activities if doing so makes business sense.

For many organizations, their first implementations using Web services technology will be internal application integration, because that is the biggest problem for them to address with IT. Flexible systems will yield flexible business models. Flexible business models will yield organizations better able to adapt to changes in the business environment.


Another key driver behind the rise of Web services is the continuing evolution of B2B computing. B2B computing is about integrating the business systems of two or more companies to support cross-enterprise business processes such as supply chain management. Some industry pundits claim that supply chain integration will be the killer application of Web services, particularly as a result of the standardization of common industry formats for XML and Web services related to supply chain business processes. B2B applications can be as simple as automated credit card validation or as complex as the full automation of the multi-billion- dollar supply chain of a Fortune 100 company. The challenges of building B2B applications combined with their huge market potential drove rapid innovation that has taken the industry from simple business-to-consumer (B2C) graphics/book.gif applications to SOAP-enabled Web services in a matter of five years.

B2C, B2B, and Web services

Online HTML-based applications are consumer-oriented. The classic example of a B2C Web application is the Amazon book search. To access this functionality, a human being needs to use a Web browser to navigate the company's site through multiple page transitions, input information using Web forms, submit them, and get the results back in human-readable form. The only way to automate this process is to simulate how a human uses the system. Doing so involves reverse-engineering the Web application to see how it moves data between pages, passing the data automatically from page to page, and, finally, parsing any data contained in the response HTML of pages. This screen-scraping approach was popular in the early years of the Web (1995–97). It is very error prone. Any changes in the Web application—even changes that are completely UI-centric and do not change the data being passed back and forth—can break screen-scraping applications. These problems are compounded because most of these applications do not properly separate presentation from application processing logic. The only true way to integrate applications on the Web is to use a B2B-focused solution.

Because B2B applications are designed to have other applications as their clients, they are fundamentally different from B2C applications. Table 1.1 summarizes some of these differences for Java applications. Both types of application are unrestricted as to the type of backend they can use—typically, Java classes or Enterprise Java Beans (EJBs). (We discuss how Web services work with EJBs in more detail in Chapter 5, "Using SOAP for e-Business.") This is where the similarities end, however. To customize backend logic, B2C applications use servlets or Java Server Pages (JSPs) that are hosted in a servlet engine. B2B applications customize their backends using straight Java code (often EJBs) that is hosted inside a Web service engine. B2C applications communicate with a browser over HTTP. B2B applications can use any of the open Internet protocols such as HTTP, SMTP, or FTP, or proprietary networks such as EDI. B2C applications handle data over the straight HTTP protocol. Input comes as GET parameters (on the URL/query string) or as POST parameters from Web forms. Only strings can be exchanged. Any other datatypes, even numbers, need to be encoded as strings. For output, data is mixed together with formatting rules inside HTML pages. This is in marked contrast with B2B applications that use XML for both data input and output. XML is perfect for B2B computing because it is programming language- and platform-neutral, it can represent arbitrary data structures, it is easy to process, and it can be validated independently of its processing. B2C applications need to have some UI (typically HTML, although some have used Java applets) because their clients are humans. B2B applications have no UI because their clients are other applications.

Table 1.1. Comparing B2C and B2B Java Applications
Area B2C application B2B application
Backend logic Java classes and EJBs Java classes and EJBs
Custom logic Servlets and JSPs Web service engine
Communication protocol HTTP HTTP, SMTP, FTP, TCP/IP, EDI, JMS, RMI/IIOP…
Data input HTTP GET/POST parameters XML
Data output HTML XML
UI HTML + script N/A
Client Human behind a browser Software application

    Previous Section Next Section