|
Here are some of the topics covered in our FAQ.
How does HostBridge fit into a web services architecture?
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.
Can HostBridge be used with Novell
eXtend (formerly SilverStream eXtend)?
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.
In summary, 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).
Does HostBridge work with application
servers like WebSphere and WebLogic?
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.
Does HostBridge compete with Microsoft's COMTI?
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.
Can a .NET application communicate with 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.
|
