Portal-Oriented B2B Application Integration
Portals have become the primary mechanism by which B2B application integration is being accomplished. In this article, EAI expert David S. Linthicum discusses the basic concepts of portal-oriented B2B Application Integration.
Portal-oriented B2B application integration allows us to view a multitude of systems—both internal enterprise systems and external, trading community systems—through a single user interface or application. Portal-oriented B2B application integration benefits us through avoiding the back-end integration problem altogether; it extends the user interface of each system to a common user interface (aggregated user interface), most often a Web browser. As a result, it integrates all participating systems through the browser, although the applications are not directly integrated within or between the enterprises.
Portals have become so common, and so much has been written about them that we will cover just the basic concepts here. The important point to remember in the context of B2B application integration is that portals have become the primary mechanism by which B2B application integration is being accomplished. Whether that is good, bad, or indifferent doesn't really matter. This is simply the way it is. The reach of internal enterprise systems has been extended to trading partners by utilizing the familiar Web browser interface.
Portals by Example
An example of portal-oriented B2B application integration is an automobile parts supplier who wants to begin selling parts to retail stores (B2B) using a portal. This portal would allow the retail stores to access catalog information, place orders, and track orders over the Web. Currently, the parts supplier leverages SAP as its preferred inventory control system, and a custom-built mainframe application written in COBOL/DB2 serves as its sales order system. Information from each system is required for the B2B portal, and the portal users need to update those back-end systems as well.
To create a portal, the parts supplier must first design the portal application, including the user interface and application behavior, as well as determine which information contained within the back-end systems (SAP and the mainframe) needs to be shared with the portal application. The portal application requires a traditional analysis-and-design life cycle and a local database. This portal application must be capable of controlling user interaction, capturing and processing errors, and controlling the transaction from the user interface all the way to the back-end systems.
Although you can employ many types of enabling technologies when creating portals, most portals are built using application servers. Application servers provide the interface development environments (IDEs) for designing the user interface, a programming environment to define application behavior, and back-end connectors to move information in and out of back-end systems, including SAP and mainframe systems. Although not integrating the application directly, the portal externalizes the information to the trading partner—in this case, the owner of a retail auto parts store—and also updates the back-end systems—in this case, with orders placed by the store owner or perhaps with the status of existing orders.
Other examples of portals include entire trading communities that are integrated with a single portal application. As many as a dozen companies may provide real-time information for a portal, and hundreds of companies may use that portal, B2B, to purchase goods and services from many companies at the same time. The same type of architecture and enabling technology applies in this case; however, the number of systems integrated with the portal application greatly increases.