FAQs: Application Servers and EAI Platforms
- How does HostBridge fit into a web services architecture?
- Can HostBridge be used with Novell eXtend (formerly Silverstream eXtend)?
- Does HostBridge work with application servers like WebSphere and WebLogic?
- Does HostBridge compete with Microsoft's COMTI?
- Can a .NET application communicate with HostBridge?
HostBridge allows other applications to invoke mainframe CICS transactions as web services. HostBridge accomplishes this with a two-step process. First, HostBridge changes the way CICS applications "speak." There are two basic typed of CICS applications: those that are terminal-oriented and those that are not. The terminal-oriented applications can be broken down further based upon how they manage the presentation interface: they either use CICS' Basic Mapping Support (BMS) or they do not. Thus, there are three common categories of CICS applications and none of them communicate in a manner that is compatible with Web Services standards such as XML. This is where HostBridge comes into play. HostBridge XML-enables existing CICS applications without requiring modification to the existing application and without using techniques like "screen scraping".
Second, HostBridge must change the way application can invoke CICS transactions. HostBridge accomplishes this through it's support for Simple Object Access Protocol (SOAP). As a result, a client, server or web-based application can invoke the services of an existing CICS application using standard SOAP messages and exchange data using XML.
Yes. eXtend, from Novell, is an eBusiness integration server that is very complementary to HostBridge. We recommend that customers consider using eXtend to automate access to CICS/BMS transactions via HostBridge. (Please refer also to the FAQ question “Can HostBridge be used to automate access to a sequence of CICS transactions?”)
Rather than trying to explain eXtend ourselves, we will let Novell do it in their own words:
eXtend is a family of products that [Novell] acquired in December 1999. The original developers of eXtend were GemLogic, Inc. The eXtend product family is specifically designed to help enterprises connect core business applications with trading partners and electronic marketplaces, thereby allowing transactions to be conducted across the Internet. eXtend is part of an emerging category of products known as eBusiness integration servers. The primary goal of these products is to permit enterprises to quickly and easily define the rules, events and processing flows necessary to integrate complex business systems. eXtend is designed to connect applications that pass information in XML format. eXtend also provides a growing suite of Enterprise Enablers that can be used to XML-enable many types of business applications.
eXtend consists of three primary products:
eXtend Designer - a highly visual design environment, targeted at business analysts and script-level programmers, that allows business information contained in XML documents to be rapidly integrated with other XML-formatted information. Any business applications that have been enabled for XML information exchange can be integrated using eXtend Designer. …
eXtend Enterprise Enablers (EEs) - a suite of adapters that provide XML-enablement services for applications running on a variety of enterprise platforms. For example, the EE for 3270 enables any host mainframe application using the 3270 block terminal protocol to receive XML-formatted requests and send XML-formatted responses. EEs install seamlessly into eXtend Designer and share all of Designer's visual/scripting features.
eXtend Server -a Java framework that runs in the context of J2EE application servers such as Novell Application Server and IBM WebSphere. eXtend Server directly exploits a variety of J2EE APIs including JDBC, Servlet, EJB, JSP, JTS, JNDI and JMS. In addition, eXtend Server leverages key application server features such as security, thread management, connection pooling, load balancing and failover.
For access to IBM CICS applications, eXtend provides two types of Enterprise Enablers (“EEs”). The first type of EE allows access to CICS “commarea” transactions using ECI. ECI is the CICS interface that allows access to "non-visual" applications (those that expect a parameter string as input, and return a parameter string as output, instead of a 3270 data stream). ECI is not used to access 3270 applications.
The second type of EE is for access to 3270-based applications. It provides the same functionality as a middle-tier Web-to-Host gateway, except that it is tightly integrated within the eXtend environment. Layered on top of a 3270 emulator, is a visual tool that allows the business analyst/programmer to define the screen navigation and screen scraping rules to be applied. Data elements extracted from the screen are returned to the Designer environment where they can be included in an XML document. The architecture/components of the 3270 EE can be illustrated as follows:
For non-CICS and non-BMS applications, terminal emulation and screen scraping techniques are the only way to access the application. However, for CICS/BMS applications, terminal emulation and screen scraping are inferior techniques compared to HostBridge.
HostBridge allow eXtend applications to securely access CICS/BMS applications and receive their output as a standard XML document -- not as a 3270 screen. Since the 3270 data stream, terminal emulation and screen scraping are totally eliminated, the resulting eXtend application is easier to implement, scales better and will not “break” when/if the host application changes.
Within eXtend, Enterprise Enablers are used to transform non-XML data sources into XML. And, since HostBridge replaces the use of 3270 with XML, an Enterprise Enabler is not required when using HostBridge. Instead, since HostBridge and the eXtend Designer abide by the same assumptions for how information is requested and received (i.e., HTTP and XML), they work together right out-of-the-box.
The following diagram summarizes our recommendation for when to use HostBridge and when to use eXtend Enterprise Enablers:
Information regarding eXtend was obtained from the SilverStream web site (December 2000).
HostBridge has been specifically designed to complement middle-tier application servers, such as those from IBM, BEA, WebMethods and Novell Many organizations that have a sizable investment in CICS applications are adopting middle-tier application servers for deployment of new applications. This usually creates a need to integrate the middle-tier applications with legacy applications running on a mainframe.
All of the “app server” vendors promote products that offer host application integration (which they refer to as “connectors”). Some have their own product(s); others provide host integration products through partnership with another vendor. App server vendors typically offer two types of connectors: (1) a connector that allows access to structured files or databases on the host, and (2) a connector that allows access to 3270 applications.
Database connectors can be used if an organization has already taken the necessary steps to structure its data so it is accessible via standardized database access techniques (e.g., SQL). Unfortunately, it is estimated that 80% of all corporate data is still not structured in this fashion. Instead, the only way to access much of the data on the mainframe is through a 3270 application. In this case, a database connector provides is of no value.
Almost without exception, the 3270 connectors marketed by application server vendors use screen scraping techniques “under the covers.” This means that someone, somehow, specifies the necessary information for the connector to logon to a 3270 application, navigate through a number of 3270 application screens, and extract information out of a screen buffer using row/column coordinates. For this reason, it is not uncommon for these connector to be somewhat integrated into the app server’s development environment. Why? Because you have to specify the screen scraping “instructions” some way and save them somewhere.
HostBridge is a 3270 connector that allows a middle-tier application to securely invoke a CICS transaction using HTTP and receive the transactions output as an XML document – without any screen scraping. HostBridge will work with any application server that allows an application to: (1) send an HTTP request, and (2) receive/process an XML document. All of the application servers mentioned above (and most others) include this support for HTTP and XML natively within the product. HostBridge can be used with any of them.
Not really. In fact, they can be quite complimentary. First, let's review what each product does:
- COM Transaction Integrator (COMTI) allows a COM object to invoke a remote CICS COMMAREA application (using the CICS ECI interface). COMTI does not allow access to terminal-oriented transactions - only COMMAREA applications.
- HostBridge XML-enables CICS transactions - regardless of whether they are terminal-oriented transactions or COMMAREA applications. HostBridge, itself, can be invoked using a COMMAREA interface, but this is not the only way to invoke HostBridge.
From these two statements we can draw a number of conclusions:
- Since the services of HostBridge can be invoked via a COMMAREA interface, HostBridge can be invoked via COMTI.
- HostBridge can allow a COMTI application to invoke a terminal-oriented transaction and receive its results as an XML document (not a terminal-oriented data stream).
- HostBridge can allow a COMTI application to invoke a COMMAREA transaction and receive its results as an XML document (not a buffer that must be decoded based upon a COBOL copybook).
- While the services of HostBridge can be invoked via a COMMAREA interface, this is not the only interface HostBridge support. Any client, server or web-based application running within a Microsoft environment can invoke the services of HostBridge using any other support transport method, such as HTTP/SOAP.
In the final analysis, the services of HostBridge can be invoked via COMTI, but COMTI is not required to invoke the services of HostBridge.
Absolutely! With HostBridge, creating a bi-directional link between .NET and CICS applications is simple.
Note that you also have some options for how your .NET server component communicates to HostBridge. For example, in one recent implementation, the customer decided to have the .NET server component communicate to HostBridge using simple HTTP requests that carry POST data (the input was non-XML). HostBridge responded with an XML document (which it always does). They chose this approach to optimize performance on the mainframe (since XML was not used for the data or the SOAP request, no inbound XML parsing had to be performed). In this case, the .NET server component expressed a web services interface to it's callers (but they weren't concerned about HostBridge expressing a web services interface to the .NET application). We have other customers who take the opposite approach (i.e., using a web services interface between the .NET component and HostBridge).
The design of HostBridge provides customers with flexibility based upon their unique functional and performance objectives.