FAQs: IBM Solutions
The list is by no means exhaustive, so please feel free to mail us questions about any topics we fail to cover here.
Here are some of the topics covered in our FAQ.
- Does IBM offer anything like HostBridge?
- Is IBM planning on including any XML capabilities within CICS?
- Which HTTP server should I use on the mainframe?
- Does the OS/390 Web Server include functionality that CICS Web Services does not?
- If I have MQSeries for OS/390, do I still need HostBridge?
- How does HostBridge compare to the XML support in new versions of COBOL?
- How does HostBridge compare to opening and extending legacy applications by "wrapping" COBOL applications in Java?
- What is CTG and how does it compare to HostBridge?
No. IBM offers many different products for 3270 application integration, but none of them do what HostBridge does. IBM’s primary product offerings for 3270 application integration are Host-on-Demand (HOD), Host Publisher and CICS Transaction Gateway (CTG). Support for all of these products has been incorporated within WebSphere.
Host On Demand provides Java-based terminal emulation along with its-Host Access Class Library (HACL). Essentially, HACL is a Java-based implementation of HLLAPI. It allows a Java application to “operate” a 3270 application using screen scraping techniques.
Host Publisher provides terminal emulation and screen scraping capabilities for 3270, 5250, VT-based applications. It also provides Java Database Connectivity (JDBC) and access to other Java applications. Host Publisher can consolidate multiple data sources and create the appearance of a single composite application or Web page. Host Publisher can generate either HTML or XML.
IBM has added, or will be adding, XML support within CICS in a number of areas.
During 2000, IBM announced the XML Toolkit for OS/390. Although the Java implementation of this does work under CICS, it performs poorly. IBM’s intention is to enhance this toolkit with parsers that work effectively under CICS (although it may not be based on the Xerces parser). Whenever IBM makes an efficient parser available under CICS, HostBridge will use it.
In March 2000, IBM made available a beta version of an XML feature for CICS Transaction Gateway (CTG). This feature allowed a remote program to invoke a CICS COMMAREA transaction using XML (essentially, an XML to ECI gateway). IBM terminated the beta program at the end of 2000, and has not announced future plans. It is reasonable to expect that IBM will add a permanent feature to CTG that allow it to accept XML requests and map them to CICS ECI calls. Note that such a feature will NOT facilitate access to terminal-oriented applications. (ECI is the CICS interface that allows access to "non-visual" applications -- those applications that emit a parameter string as output, instead of a 3270 data stream.
IBM has publicly stated their intention to ship a “LINKable 3270 Bridge” in CICS TS 2.2. This feature will support the ADS/ADSD data stream interface (with some enhancements) that is currently implemented by 3270 Bridge. Essentially, this feature extends the services of 3270 Bridge across a CICS LINKable boundary and allows a middle-tier program to invoke an application using 3270 Bridge. Note, however, that the inputs and outputs will not be XML. Thus, this feature will not be competitive to HostBridge; instead, it will create the opportunity to port HostBridge to a middle-tier server as a CICS Gateway application.
IBM currently offers two host-based HTTP servers. CICS Web Services (CWS) is delivered as part of CICS TS 1.2, or later, and includes an integrated HTTP server. Rather than entering the CICS environment directly through CWS, you can also enter through the OS/390 Web Server (Domino GO). The OS/390 Web Server runs on the UNIX System Services (USS) platform and can also provide secure access to CICS services. Both HTTP servers rely upon the MVS TCP/IP protocol stack for network connectivity.
When IBM first released CICS TS 1.3, CWS required that certain user exits be implemented in order for CWS to be as secure as the OS/390 Web Server. These exits could be implemented by either installation personnel or by third-party software that used CWS’ services (HostBridge implemented these user exits). These simple exits worked with CWS to provide the same level of security as the OS/390 Web Server.
IBM, however, is regularly enhancing CICS TS 1.3 and CWS through the service channel via APAR’s. And, with APAR PQ36169, IBM has significantly enhanced the security features of CWS. This APAR causes the CICS integrated HTTP server to implement/enforce all security processes prior to any third-party software, such as HostBridge, receiving control. The need for user exits to complement CWS has been eliminated, and the native level of security supported by both IBM host-based HTTP servers is the same.
HostBridge will work with either CICS Web Services or the OS/390 Web Server. Given the simplicity of deploying CICS Web Services, we suggest that organizations use CWS’s integrated HTTP server for initial testing with HostBridge. The choice between CWS and the OS/390 Web Server should be based upon which tool best meets the organization’s production requirements.
Yes. For example, OS/390 Web Server supports filtering and redirection. However, the question must be asked as to whether these features are important when using HostBridge.
HostBridge has been designed to complement middle-tier application servers, such as those from IBM and BEA. Organizations typically deploy such application servers behind their firewall. In this case, HostBridge would be behind the application server, which is behind the firewall. It is therefore hard to imagine why an organization would want to filter or redirect HTTP requests sent from the application server to HostBridge. Instead, an organization would want the most efficient possible path between the middle-tier application server and the CICS transaction. The combination of HostBridge and CICS Web Services does just that.
If you want to do what HostBridge does, absolutely!
Let's first clarify what each product does. HostBridge is a patented software product that XML-enables CICS BMS transactions. MQSeries does NOT provide this capability. MQSeries is a transport mechanism. And to HostBridge, there is no difference between HTTP and MQSeries, or any other transport mechanism. They are just that – transport.
MQSeries for OS/390 does include a capability that allows a non-CICS program to request the invocation of a CICS 3270 or BMS transaction. This capability is provided as part of the MQ CICS Bridge, discussed further below. While it may appear on the surface that this is like HostBridge, it isn't!
To use this facility, the non-CICS program must express its request using proprietary and complex data structures. The output from the CICS transaction is also returned using proprietary, and even more complex, data structures. The question then becomes: Is it really desirable to embed logic in a non-CICS application to process proprietary CICS data structures and 3270 data streams? We think the obvious answer is "no." Even if you were willing to do so, you would soon discover that certain types of BMS applications are not supported (e.g., those that use the SEND MAP MAPONLY command), and certain crucial information is not delivered to the non-CICS program (e.g., the original field attributes within BMS map).
HostBridge resolves all these issues. HostBridge allows a non-CICS program to request the invocation of the CICS BMS transaction, and receive its output, using standard XML documents. As a result, the non-CICS program does NOT have to encode and decode proprietary data structures or 3270 data streams. With HostBridge, the non-CICS program uses the simple and standard XML-handling facilities provided by all development environments.
So, if you have MQSeries for OS/390 do you still need HostBridge? You certainly do if you want to integrate non-CICS programs with CICS BMS transactions using open standards like XML! The bottom line is that HostBridge and MQSeries are very complimentary. MQSeries doesn't do what HostBridge does, and HostBridge doesn't do what MQSeries does. Together they are a very good fit.
Deciding on which tool to use for XML-enabling CICS applications depends on whether you want to use an adapter to allow your existing applications to read/write XML or if you want to re-engineer your applications and hand-code a new interface to support XML. HostBridge XML-enables existing BMS based applications without reengineering. With Enterprise COBOL, you have to alter the application to process XML and generate it. CICS applications compiled using the new version of COBOL will be able to accept inbound XML messages and transform the information from XML to COBOL data structures. However, compiled applications do not generate outbound XML documents without reengineering them to generate the XML on their own. This means that as you make changes to your applications you must also make changes to the XML interface to correctly present the data to remote applications. You will also need to develop your own XML schemas to provide a blueprint that allows middle-tier web developers to interact with the CICS application.
HostBridge supports both inbound and outbound XML, requires no changes to CICS applications, and all data returned to remote applications conforms to a fixed schema so that web developers know how to interact with the CICS application. Because HostBridge produces the XML documents at run-time, changes to the CICS applications automatically appear in the XML documents so you do not have to make changes to an XML interface after each change to a 3270 screen.
For customers with existing CICS BMS applications, HostBridge is a better choice. For customer who are writing new CICS applications, the XML capabilities in COBOL v3 provide an set of tools that allow you to include native XML handling.
There are many different concepts and components floating around these days that may assist in the integration of existing CICS applications with non-CICS applications. The landscape can be very confusing. First, let's clarify what each component is, and is not.
- HostBridge is a software product that XML-enables existing CICS BMS transactions. With HostBridge, any transaction that uses BMS to interact with a terminal can be XML-enabled automatically. HostBridge does this without requiring modification to your existing applications. HostBridge changes the way the BMS transaction "speaks", replacing 3270 data streams with XML.
- XML is a platform independent way of expressing structured data. XML is not a programming language.
- Java is a programming language -- no more; no less. Conceptually, wrapping a COBOL program with a Java program is no different than wrapping a PL/I program with a COBOL program. Wrapping a program written in one language with a program written in another language does not change the functionality of the underlying program. It just makes it easier to invoke it from a program written in the other language.
- The phrase "Web Services" describes a methodology for allowing one program to invoke the services of another. The methodology is implemented by three key protocols: SOAP, UDDI and WSDL. These protocols allow a "consumer" program to invoke the services of a "service" program without knowing in advance where it exists or how to invoke it. Note that SOAP, UDDI and WSDL make extensive use of XML to express data in a structured manner.
Would wrapping a COBOL BMS transaction in Java do what HostBridge does?
No, because wrapping one program with another does nothing to change the functionality of the underlying program.
Will growth in the use of Java replace the use of XML? No, because they are totally different. Java is a programming language and XML is a "data language." Note that Java programs designed to integrate with other programs usually makes extensive use of XML to exchange data.
Would accessing a COBOL BMS transaction as a web service do what HostBridge does?
No, because changing the way you invoke a program does nothing to change its functionality. Besides, a BMS transaction cannot be invoked natively as a web service.
Will the growth of Web Services cause HostBridge to be a non-factor?
Absolutely not --HostBridge is actually the key piece that allows an existing CICS BMS transaction to be invoked AS a web service!
The bottom line is that the use of HostBridge, XML, Java and web services are complementary, not competitive! HostBridge will XML-enable you existing CICS BMS transactions and allow them to be invoked (perhaps by a Java program) as a web service. Each component and technology plays a vital part in creating an infrastructure that encompasses your past, present and future IT investments.
We currently have customers doing this exact thing with HostBridge. They have build Java business level objects. These provide high level business functions such as 'Get Account Status'. Behind this functional interface, the Java application may use JDBC to retrieve it from a database or use HostBridge to retrieve it from a CICS application. Since Java supports XML and HTTP very well, this makes it an ideal tool for working with HostBridge.
CICS Transaction Gateway (CTG) is an IBM software product that runs on a middle-tier platform (usually). It supports two primary interfaces to CICS transactions: ECI and EPI.
- EPI is a terminal emulation interface, like HLLAPI. It allows a program on the server to interact with a CICS terminal-oriented transaction using terminal emulation and "screen scraping" techniques.
- ECI is an interface that allows a program on the server to interact with a CICS COMMAREA transaction.
HostBridge does not require CTG. However, if a customer wants to use CTG as their gateway into the mainframe then the ECI interface can communicate between a program on the middle-tier server and HostBridge. (HostBridge supports a COMMAREA interface.) The only scenario in which CTG would be required would be if a customer wants to use SNA as the communication protocol to the mainframe. This is actually why CTG came into being, but it is a very rare situation these days.
Under no circumstances do we use the EPI interface (HostBridge is all about eradicating screen scraping, not using it!)
The bottom line is that HostBridge and CTG are not competitive, and can be complementary. Thus, you can't really say that one is superior to another. HostBridge XML-enables CICS BMS transactions. CTG does not. The only case in which CTG is required with HostBridge is if the customer wants to use SNA between the middle tier and the mainframe. In all other cases CTG is unnecessary when using HostBridge.