Gartner defines application integration as “making independently designed application sys-tems work together.”The need for better-integrated applications is huge. Here are just a few examples from the public Internet and corporate networks:
n Forrester estimates that more than 50% of Fortune 1000 enterprises have over 50 legacy or packaged applications that need to be integrated—in spite of the func-tional and business needs.The opportunity cost of not integrating these applica-tions is huge.
n CIO Magazine’s Tech Poll recently showed that more than 85% of surveyed com-panies have an IT application backlog, weighed heavily toward integrating existing systems as opposed to buying new systems.
n Have you ever forgotten some of your passwords? If single sign-on (SSO) is broad-ly deployed, you won’t have to remember so many passwords.
23 The Web Service Opportunity
n Have you ever chosen not to buy from a Web site offering you the best terms because you didn’t have an account set up and you didn’t want to spend the time registering? If eWallets work broadly on the Web, this won’t be a problem.
n Email is the life blood of companies. Much relevant business information is sent and received through email, often outside the context of enterprise systems. A whole industry of companies has sprung up to address this lack of integration across multiple domains: sales automation, collaboration, resource planning, and so on.
n One large financial institution takes more than a week to process a change of address.The institution thinks that it can generate up to 10% more profit per cus-tomer if only it can process the change in less than 24 hours. It’s been trying for years to integrate several applications to do this without success.
End users, IT, and business executives want more integration and information leverage between the applications they use every day. IDC estimates that the size of the applica-tion integraapplica-tion software market in the United States is approaching $5 billion.The United States systems integration (consulting) market, at the same time, was about $38 billion. Most of that is pure labor (as opposed to hardware and software) cost, and much of it is spent on integrating systems as opposed to building new systems.Two things become clear from this analysis: First, the total market size for integration is tens of bil-lions for the United States alone. Second, services and not products account for the majority of that amount.
To harness the value potential of applications, we need much more integration.The only way to achieve this is to significantly lower the cost of integration across the board.
There is a problem, however:The low product-to-service ratio in the integration space puts a constraint on both the rate of growth of the market and the cost of integration projects. Screen scraping, data mapping, and building bridges between incompatible APIs aren’t scalable activities—they require trained personnel and a lot of time.When technol-ogy picks up its pace, IT services can’t keep up. Unless enterprises fundamentally change their dependence on integration services, they won’t be able to leverage the powerful trends in computing, storage, connectivity, and standardization. Nor will they be able to leverage the full value potential of integrated distributed applications. Companies will be stuck with integration backlogs that forever exceed their resources, both monetary and human.
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 accessi-ble by other applications running on different hardware platforms and written in differ-ent 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’ll be able to
develop the set of standards, technologies, and tools that will enable small and large busi-nesses to easily integrate systems internally; then they can mix and match the implemen-tation of various activities within a business process, maintaining the option to outsource any or all of these activities if doing so makes business sense.
B2B
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 manage-ment. B2B applications can be as simple as automated credit card validation or as com-plex 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)
g
applications to SOAP-enabled Web services in a matter of five years.Integration of Human Interaction with Systems: B2C
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 transi-tions, 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), but it’s very error prone.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’re 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 JavaBeans (EJBs). (We discuss how Web services work with EJBs in more detail in Chapter 7, “Web Services and J2EE.”) This is where the similarities end, however.
To customize backend logic, B2C applications use servlets or Java ServerPages (JSPs) hosted in a servlet engine. B2B applications customize their backends using straight Java code (often EJBs) 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 out-put, data is mixed together with formatting rules inside HTML pages.This is in marked
25