compatible protocols such as HTTP, SMTP, or FTP. Because of the widespread adoption of these protocols and formats such as XML, we expect Web Services to address many of the requirements for interoperability across independent processing environments and domains. Web Services can overcome differences in platforms, development lan- guages, and architectures, allowing organizations to perform processing tasks cooper- atively. Using XML and SOAP, systems from different domains with independent environments, different architectures, and different platforms can engage in a distrib- uted endeavor to address business needs.
Distributed Computing
Pressures to share information and cooperatively share processing lead to the notion of distributed processing. Traditional distributed processing models assume that there is a common environment or architecture between cooperating entities. When both par- ties try to accomplish a processing task using J2EE or COM+, a common architecture exists for the invocation of operations or sharing of data. This makes it relatively easy to connect applications. While a common architecture does not guarantee interoper- ability, it makes it easier to achieve.
Web Services
C H A P T E R
It isn’t always possible for all the participants in distributed processing activities to use the same architecture and processing environment. When processing must be spread across organizations, their architectures, platforms, and development languages are likely to be different. Complications arising from mismatches in environments can exist between companies and can even exist between departments or divisions within the same company. An organization with a large investment in an existing infrastruc- ture cannot afford to change its architecture and processing capabilities, even if suc- cessful distributed processing depends on it. And, if one organization is willing to make the change to accommodate another organization, there are probably other groups it needs to work with that can’t make such an all-encompassing change. As a result, it’s unlikely that organizations will be able to use a common environment.
Current processing architectures are single domain, but multitiered. That is, the pro- cessing load within a domain is spread among several systems, each handling a well- defined portion of a transaction. The systems can work sequentially or in parallel. A common division of responsibility is to have a front-end processor that handles data presentation and user interaction, a middle tier that is responsible for implementing business logic, and a back-end system that may be a data repository or a mainframe that performs batch processing.
A logical extension of multitiered processing is multidomain processing. A process- ing domain is a computing facility under the control of a single organization. A domain may include many computers and utilize different processing architectures. A depart- ment or a division within a company may control a domain, or a domain may be under the control of a company. Within a large company, there may be an accounting domain and a purchasing domain. We want the accounting system to know of purchases occur- ring in the purchasing system so that the bills can be paid automatically. Between com- panies, it may be desirable for a purchasing system to request bids from and send purchase orders to vendors’ systems.
Multidomain processing is generally very difficult to implement because of the dis- parate platforms, environments, and languages in different domains.
One notable attempt at achieving multidomain processing is Electronic Data Inter- change (EDI). EDI is a standard format for exchanging financial or commercial infor- mation. Two versions of EDI are in use. They are Accredited Standards Committee (ASC) X12 and the International Standards Organization’s Electronic Data Interchange for Administration, Commerce, and Transport (EDIFACT). The latter standard is often referred to as UN/EDIFACT, since it was originally developed by a United Nations working party.
With EDI, a company can transmit a purchase order to its vendor. Banks use EDI to send funds transfer information to financial clearinghouses. Value-added networks are used to transfer the EDI messages. EDI has existed since about 1980, and it has been used successfully by many companies.
By dealing with the structure and format of data exchanged, EDI frees each party to the transaction from the requirement for a uniform computing environment. So long as the sender can construct the correct message, it does not matter what platform, operat- ing system, or application created the message. Likewise, on the receiving side, so long as the receiver can parse the message, identify the elements of interest, and process them appropriately, the processing environment at the receiver’s end is of no conse- quence. The transaction has been processed by two loosely coupled systems located in two separate domains.
There are several reasons why EDI is not used more widely. EDI messages are rigid. The data is not self-defining, and it is presented in a prescribed order with a fixed rep- resentation. This rigid structure often needs modification when users discover needs that cannot be accommodated by the existing fields. However, EDI’s rigidity makes changes, such as adding new fields, difficult to implement. This leads to a multitude of vendor- and customer-specific implementations.
Another reason for EDI’s limited acceptance is that specialized software is required, which can be very expensive. EDI documents are often transferred via specialized, value added networks, increasing cost and support requirements. Implementing EDI can be very costly, and a company needs a very compelling reason before choosing to adopt it.