There are solutions on the market that support COMMAREA, BMS, and non-BMS transactions all through a single adapter. Because most shops have a mix of application types, companies should look for this kind of adapter to avoid multiple software licenses and additional training on how to integrate the different application types within your organization.
Companies wanting to integrate IMS DC applications will most likely need to use gateway methods. While IMS applications usually separate application data and presentation logic, IMS DC does not provide generic facilities that allow an adapter to capture application data before it is sent and converted to XML/SOAP. Thus, the only other viable solution is to reengineer the application or use a gateway to access the application from a middle tier. A myriad of tools, including Novell’s eXtend (formerly SilverStream) or SEAGULL’s Transidiom, are able to make 3270 screens available to other applications as Web services.
In the adapter and gateway examples shown in Figures 5 and 6, we focus on using Web services with visual (terminal- oriented) applications because they are typically more difficult to integrate than non-visual applications.
Adapter Model for Web Services
Adapters allow you to transform your legacy applications into Web services without requiring the use of additional hardware, without changes to the legacy application and without falling back upon brittle techniques such as screen scraping as the enhanced access method. Compared to gateways, adapters yield better performance by running on the host and more reliable operation due to the elimination of the many layers data must pass through due to screen scraping. Adapters also provide access to application information such as status and error codes. This information is lost when data is sent to a terminal emulation technology such as a 3270-emulation client or Front-End Programming Interface (FEPI).
Figure 5 shows the basic model for accessing legacy applications as Web services directly through adapter technologies. This figure illustrates a Web services architecture: a Provider that supplies the Web service, a Requester that uses a Web service, and a Broker that finds Providers for Requesters. In this model, the legacy application is the Provider. The following steps represent how to find and use a Web service adapter (steps 1 through 3 are optional):
1. The Provider uploads a WSDL specification to publish its Web service with a Broker. 2. The Requester (usually a Java or .NET application) queries the Broker for a Web service by name or category. 3. The Broker selects a Provider and returns the Provider information to the Requester. 4. The Requester uses the information from the Broker to format and send a SOAP message to the Provider. 5. The Provider returns a SOAP/XML response to the Requester with the legacy application data enclosed.
Gateway Model for Web Services
Unlike adapters, gateways typically run on a physical or logical middle tier. Where gateways run is important because there are so few options for accessing the host from middle-tier servers, which means gateways usually involve some form of screen scraping. When gateways communicate with terminal-oriented legacy applications, they open a terminal session with the legacy application, send a request to the application, receive the terminal datastream, convert the contents to XML, and ship the XML document to the requester. (A variation of the gateway model is to use FEPI on the mainframe instead of a middle-tier terminal emulation client. This simply moves the middle tier onto the mainframe.)