|
Here are some of the topics covered in our FAQ.
Does IBM offer anything like 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.
CTG supports two interfaces: ECI (External Communications
Interface) and EPI (External Presentation Interface).
EPI is an interface defined by CICS that allows a program
to programmatically operate a 3270 application using
screen scraping techniques. ECI allows a program to invoke
a non-3270 CICS transaction as though it were a remote
subroutine or procedure (ECI is similar to RPC in a TCP/IP
environment).
Is IBM planning on including any XML
capabilities within CICS?
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.
Which HTTP server should I use on the
mainframe?
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.
Does the OS/390 Web Server include functionality
that CICS Web Services does not?
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 I have MQSeries for OS/390, do I
still need HostBridge?
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.
How does HostBridge compare to the XML
support in new versions of COBOL?
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.
How does HostBridge compare to opening
and extending legacy applications by "wrapping"
COBOL applications in Java?
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.
What is CTG and how does it compare
to 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.
|
