Application Scenarios


A case can be made for using Web services in many types of applications, 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 application integration (EAI) applications.

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 (www.oasis-open.org) are creating standards for electronic commerce. ebXML (www.ebxml.org), 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 applications 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 applications by placing Web service fa ades for those applications 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 Application Integration

The more likely short-term candidate for Web services use is in the enterprise application integration (EAI) space. EAI is a solution to the problem of getting applications within an organization to communicate with each other. It converts the protocols and data formats that internal applications use. In many ways, this is the same problem Web services solve.

Vendors have created EAI products to solve the problem of communication between applications within an organization. These EAI product suites strive to solve three problems:

  • Wire protocol conversion

  • Data format transformation

  • Routing messages between systems

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 Figure 1.11, follows a "hub-and-spoke" model for application integration. That is, each application 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.

click to expand
Figure 1.11: The enterprise application 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 applications that reside on the mainframe. The CRM application 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 application 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 application. 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 application. 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 Figure 1.12. Instead of having a single point of failure using hub-and-spoke topology, Web services form a semi-lattice topology for application communication.

click to expand
Figure 1.12: The enterprise application 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 "service bus" paradigm similar to the EAI model.




Java Web Services Architecture
Java Web Services Architecture (The Morgan Kaufmann Series in Data Management Systems)
ISBN: 1558609008
EAN: 2147483647
Year: 2005
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net