Application Integration

Application integration is critical to organizations large and small because information integration is so fundamentally important. When organizations integrate all their applications that deal with customers (CRM, ERP, accounting, billing), they are trying to create a single view of all the information about those customers. When they integrate all their trading partners into a single supply chain, they are attempting to create a holistic view of their entire supply chain and all the information that describes their trading processes. This kind of information integration is fundamental to the business process. Rarely does a business process (product development, product marketing, product manufacturing, product ordering, product fulfillment, customer relationships, partner relationships, financials, and so on) utilize one and only one source of information (an application). It is because business processes cross application boundaries and even enterprise boundaries that Web services are needed to create those bridges.

Application integration is hard because systems were not designed with the same data structures, protocols, or even the same vocabulary for describing the items they manipulate. Applications were built at different times by different vendors using different technologies. However, many of these different applications need to communicate to perform certain functions. This is where XML comes in. It makes information easy to interchange and therefore easier to integrate.

The glue used to communicate from one application to another has traditionally been called middleware . Middleware has never been pervasive and was always very expensive. Rarely has anyone ever tried to use middleware between enterprises because simply using it within a single enterprise's boundaries is hard enough. SOAP is a critical step in taking XML messages toward being Web services middleware. In one of its modes, SOAP makes XML into a request/response paradigm that is published via WSDL. Web services are becoming pervasive because they are middleware based on the Web, and the Web is pervasive.

B2B Business Process Integration

Business processes don't stop at your company's firewall. Just as internal application integration is partly motivated by the need to break down application barriers, inter-organization business processes motivate B2B application integration. A driving need to integrate across organizations comes from management of supply chains and demand chains with trading partners. Traditional middleware could never be employed to solve this need because it never worked across the Internet.

The good news is that the Internet is pervasive. Most Internet communication occurs via text (for example, HTML is text, email is text), and virtually all applications have some form of text interface. XML is text-based and is designed to make business information transportable and self-describing . XML, plus the fact that all vendors support Web services, has moved us closer to solving the heterogeneous communication problems of different languages, different platforms, and different applications than any middleware technology of the past.

For these reasons, Web services technology is built on XML and Web technologies, which makes it the first middleware that can address the B2B business process integration challenge.

Portals

On the Internet and within intranets , portals are the entry point for customers into a site. Portals have been growing in utility and importance for some time as a way to aggregate information and applications into a single site that is accessible by browsers. Portals as major business models have been common for years . Amazon.com, Yahoo!, and Orbitz are all fundamentally portals. They pull information from their partners' repositories into a single site that consumers with browsers visit to buy books, music, and consumer goods; plan trips; and the like. Most of these major Web e-commerce companies built their portals long before Web services standards existed. They effectively built Web services to integrate all their information content using home-grown approaches. Companies trying to do what they have done now can do it much more cheaply and easily and remain much more interoperable by using the new Web services standards.

Companies are rapidly turning their corporate intranets into portals to provide a wide range of company- related information and services to employees, shareholders, and partners. One type of service they are providing employees is a unified benefits information resource. To make that a complete service, the 401k information from third-party providers must be integrated into the corporate portal. That is a perfect use for secured Web services that bring the employees ' 401k account information into the corporate benefits portal by accessing the external services of the 401k provider.

Integrated customer information is so much the lifeblood of all companies that both customer relationship management (CRM) and customer information portals have represented large corporate investments for many years. Naturally, because Web services are less expensive and less complex than any previous form of middleware, they have been brought to bear on this common need.

Service-Oriented Architectures

In a service-oriented architecture (SOA), the interface is completely separated from the implementation. The software is provided strictly as a service that does not have to be downloaded and installed. SOA promotes reuse and sharing of services by numerous applications and even by different organizations. People describe an "SOA nirvana" when all systems are built as SOA and all applications are composite ”built by stitching together several useful shared service components into powerful applications. Many people look to Web services to bring us to this SOA nirvana ^[3] .

^[3] In an SOA, UDDI will have a strong, meaningful role.

The idea of services as being a powerful computing paradigm is not new. A service is an application that can be consumed by software as opposed to a human at a browser. It is software that does work for other software. It is how RPC mechanisms work. This was the premise of the client/server computing revolution of the early '90s. In this model, the server provided the service.

The benefits of a service-oriented architecture are legion. The complexities of a software system are hidden behind its interface. A complex software system becomes a simpler black box defined only by its external interface. The service so constructed becomes a shared resource that can support many applications.

Web services combine the concept of software-as-a-service with the ubiquity and connectedness of the Web. This is what makes Web services so compelling and so exciting: They create a Web API. We are talking about building applications with a broadly accepted standard API based on Web technologies. Web services enable you to wrap legacy applications with this Web API and turn them into shared services. Now these applications can be integrated with other applications and with trading partners. Previously inaccessible information resident in these legacy applications can be brought out to portals and combined with other application information and all made accessible to any user with a browser. Any application can be modified to provide this type of Web API and therefore can be integrated with any other application, allowing you to use the entire Web for application-to-application integration. This, then, is the power of Web services.

Definition of Web Services

A good working definition of a Web service, then, is an application that provides a Web API. The API enables the software resource to act as a service. Being a Web API means that this service is accessible at an Internet URI. Further, an API supports application integration, so a Web API allows application-to-application integration using XML over Web protocols and infrastructure. All the security and trust issues of being part of the open Web infrastructure will concern us. All the information security and message security issues inherent in sending messages from one network point to another will concern us. All the authorization and authority security issues inherent in middleware that performs RPCs will concern us. Now, let's cover some security basics to build a foundation for our deeper discussions in later chapters.