A case can be made for using Web services in many types of apps, ranging from home appliances to video games, because Web services can be implemented to solve many different types of problems. However, Web services are getting the most attention from organizations building business-to-business and enterprise app integration (EAI) apps.

Business-to-Business

The most widely talked-about use for Web services is business-to-business transactions. Web services enables business-to-business communication across the Internet or on private networks. Businesses are forming and joining "trusted partner" organizations, in which members agree on external semantic standards for messaging. Web services are a set of specifications that provide interoperability for these trading communities. Organizations such as OASIS () are creating standards for electronic commerce. ebXML (), a set of specifications for XML messages in electronic commerce, is jointly sponsored by OASIS and UN/CEFACT. RosettaNet is another consortium of companies that provide XML specifications for electronic commerce. Prior to the ebXML and RosettaNet specifications, electronic data interchange (EDI) was the standard for electronic business. EDI was expensive to implement and is still a fairly closed system. The networks were usually private, and the data formats were mostly proprietary, specific to an industry, and sometimes particular to a pair of trading partners. The conventions used by standards such as ebXML allow developers to build apps based on common structures and syntax for messaging across all industries. Many industries form consortiums to define messaging formats specific to their industry. For example, the ACORD group provides specifications for messaging related to the insurance industry. IFX provides standards related to the banking industry. Hundreds of consortiums, some active and some not, set standards for nearly any industry imaginable. Web services do not by themselves provide business-process collaboration capabilities. Standards such as ebXML provide a basis for complex message interactions between organizations, enabling trading partners to participate in open and complex business processes. Also, the ebXML group has standardized common services, such as exceptions, security, and notification of failure. These larger infrastructure requirements would not be possible without new external and independent semantic standards for managing them.

Through the convergence of the Internet, Web services, and messaging standards, organizations can conduct electronic business in a standard and open way. They can leverage existing apps by placing Web service façades for those apps on the Internet to perform electronic business. However, because of a concern for security and a slow standards process, progress in this area is slow.

Enterprise app Integration

The more likely short-term candidate for Web services use is in the enterprise app integration (EAI) space. EAI is a solution to the problem of getting apps within an organization to communicate with each other. It converts the protocols and data formats that internal apps use. In many ways, this is the same problem Web services solve. Vendors have created EAI products to solve the problem of communication between apps within an organization. These EAI product suites strive to solve three problems:

Typical EAI products deliver tools that adapt one protocol to another or that provide a single standard for interoperability. The typical EAI solution, shown in ScreenShot, follows a "hub-and-spoke" model for app integration. That is, each app that needs to communicate with another must first send the message to the EAI hub, which transforms and routes the message to the recipient on behalf of the sender.

The enterprise app integration hub-and-spoke topology.

Some products allow the sender and receiver to use different protocols. For instance, upon purchasing a customer relationship management (CRM) system, an organization needs to populate data for that system from legacy COBOL apps that reside on the mainframe. The CRM app can use a standard middleware protocol, such as IBM's MQSeries, to communicate with the EAI hub, or it may choose a different protocol, such as HTTP. The EAI hub will accept the message over multiple protocol types, transform the message into a format that a COBOL app understands, and route the message to the host system. All viable EAI vendors are adding Web services support to their products. This will allow the EAI products to route Web services messages to other data formats and protocols. EAI solutions have several drawbacks. They are expensive, and they externalize many business rules outside the app. Typical EAI products have specialized languages to describe the rules for data transformation and routing. The rules for data transformation use data tables and have specific knowledge about the data formats. Some EAI products, if not managed correctly, can house a major part of the business rules for an app. The hub-and-spoke model for communication makes integration and management of an EAI solution easier, but it introduces a single point of failure that leaves many systems vulnerable. The single-point-of-failure problem has been mitigated in EAI products by providing hot backup and clustering features. However, a rule corruption problem, a bad version upgrade, or some other catastrophe could bring down an entire enterprise that relies on the EAI solution. Web services solve some of these problems. The business logic is not externalized. The logic for transforming the data into a format the service understands is close to the service. Finally, Web services do not follow the hub-and-spoke model. Each connection from Web service consumer to Web service producer is a direct connection, with no third-party involvement. Therefore, problems are localized to individual services, which allows other services to function normally. In addition, instead of using EAI solutions for protocol and data format translations, systems communicate directly with each other over Web services, as shown in ScreenShot. Instead of having a single point of failure using hub-and-spoke topology, Web services form a semi-lattice topology for app communication.

The enterprise app integration Web services topology.

Newer vendor products are emerging to manage Web services in an enterprise. These products provide message routing, orchestration, and service management. Some of these products implement a "" paradigm similar to the EAI model.