Application Integration

Business Challenge

Many enterprises have turned to packaged applications as a solution to rapidly automating business processes. Packaged applications typically support a finite range of business processes, so most enterprises use more than one packaged application. However, to increase efficiency further through automation, enterprises must integrate these packaged applications with each other and with custom application. Typically, achieving such integration requires extensive custom consulting or expensive tools.

XML Benefit

XML provides the foundation for simplifying this process and includes the infrastructure for inputting and outputting structured documents. If applications could agree on the structure for a set of XML documents corresponding to common business entities and transactions, they could work together. The Open Applications Group has developed just such a set of formats, and a number of leading packaged application vendors , such as Oracle, Peoplesoft, and SAP, plan to support them.

XML also offers hope when it comes to avoiding incompatibilities between integration packages. Many vendors already offer solutions for integrating applications. Usually, they translate the internal data representation of each application into a common intermediate representation. Unfortunately, different products use different intermediate representations. Therefore, if two different organizations within an enterprise use different integration packages, they often have trouble making them communicate. Many recently released integration packages use XML as the intermediate format so the chances of making them work together is higher. In many cases, it may simply be a matter of writing the appropriate XSLT transforms.

Architecture

As Figure 7-4 shows, the application integration architecture involves one or more applications communicating over a network. When one application wants to access another application, it sends it an XML-formatted request over SOAP. The target application returns an XML-formatted value or even an entire business document. For applications that cannot natively exchange XML, an XML-enable integration package can act as a proxy. It receives XML requests on behalf of these applications and translates them into their native protocols. It performs the reverse translation for the returned information and for requests from the proprietary application to the XML-enabled applications. However, unlike two XML-enabled applications, those using a proxy can never communicate directly.

Figure 7-4. Application Integration Architecture

The applications shown in Figure 7-4 do not have to be in the same enterprise. You could just as easily integrate an Inventory Management application in one enterprise with an Order Fulfillment application in another enterprise. When inventory falls below a certain level for a given part, the Inventory Management application sends an XML document over the Internet to the Order Fulfillment application at the part supplier. The definition of XML formats for business entities and transactions has the potential to simplify the development of supply chain management applications greatly. Such a system crosses the line from application integration to business process orchestration when you add layers of policymaking and rule evaluation.

Key Features

Application integration demonstrates the usefulness of the human-machine duality of XML documents. Document exchange occurs primarily between applications. However, the documents they exchange represent business entities and transactions. Usually, when two applications exchange documents, these documents are primarily interesting only to the applications themselves . Many application integration applications, however, would be meaningful to business professionals if they were formatted with an XSL stylesheet. The ability of people to audit the machine interaction easily makes enterprises more comfortable with such arrangements and introduces a degree of robustness in the face of border cases where the automated exchange fails and people must get involved.

Development Process

In certain cases, packaged application vendors provide support for XML. In many cases, even though a packaged application doesn't directly support XML, an integration solution can translate native requests to XML requests. In these cases, you must test all the applications in question to ensure that they can exchange information using the exchange protocol. In some cases, you may need to enhance internally developed applications so that they can communicate with other applications using XML. In these cases, you have two primary tasks . First, you create a protocol engine that can format a document request, establish a remote connection to the server application, send the document request to the server, receive the server's response, and extract the interchange document. Second, you create a mapping layer that will translate the data contained in the interchange document into data structures that the application can process.

Schema Source

There are two types of schemas involved in application integration: protocol schemas and payload schemas. Protocol schemas describe the formats of messages on the wire. As discussed in Chapter 4, SOAP is quickly becoming the accepted standard for this format, but there are still some products that use other protocols. Payload schemas describe the formats for business entities or business actions. Because application integration commonly occurs between operational enterprise applications, enterprises with similar operations have similar interchange requirements. Therefore, consortiums within particular industries such as financial services, semiconductor manufacturing, or telecommunications are defining payload schemas. For integrating sophisticated or unique applications, these standard schemas may be insufficient, and you must design them yourself.

Document Life Cycle

An application creates a document in response to a specific request. It then returns the document to the requesting application, which consumes it by translating the information contained in the document into internal data structures. At this point, the document no longer exists unless explicitly saved for auditing. Of course, applications may process the individual data elements in the document and save the data to their own databases.