|
 MS HIS &
IBM HIS
-
Part
II
Putting HIS In Its Place Without
a Hissy Fit
Let's just
stick to the facts without the theatrics
Read
Part I
by
Anura Guruge
editor at
large, IT In-Depth
 Microsoft’s
Host Integration Server (HIS) 2004, as covered in
part I,
includes 5 distinct sets of functionality:
1.
SNA
gateway – which today boils down to a ‘tn’ server
2. SNA
transport over IP; i.e. Enterprise Extender (EE)
[a.k.a ‘HPR-over-IP’ where HPR can be thought of
as APPN+ or SNA++]
3. Application integration –
particularly in terms of host transaction representation in .NET
replete with support for 2-phase commit
4. Data integration; i.e. VSAM and
database access
5. Single Sign-On (SSO) enablement
However, as also stressed in
part I,
the ‘tn’-based SNA gateway continues to be the feature that is of
preeminent interest to most that are currently looking at HIS. Many
of these are in the throes of finally streamlining their
multiprotocol 1990s LANs and standardizing on IP-based networks –
with ‘tn’ as the means for
mainframe or
iSeries application access. With costs always being a
concern, they want a cost-effective, but solid, tn-server. On
paper, HIS 2004 fits this bill though security no doubt tends to be
a lurking concern given that it only runs on Windows servers.
Scalability, a major concern 5 years ago, is not as worrisome now
that we have Windows 2003 and much more powerful server hardware.
Nonetheless,
one may want to think, and then re-think again and again, whether
HIS is the appropriate, strategic option when it comes to ‘tn’
server functionality. The reason being that the move towards
total IP, at the expense of SNA backbones, has changed the entire
philosophy and dynamics related to SNA gateways.
 Janus
Like Gateways With Two Faces
To appreciate the profound change that has
occurred vis-à-vis SNA gateways one has to visualize the mechanics
of such gateways – which by the way are now all ‘tn’ server gateways
(as opposed to IPX, NetBIOS or ‘proprietary’). A ‘tn’ server, as with any
SNA
gateway, is but a protocol converter – in this case one that
converts between IP on one-side [i.e. the so called ‘downstream’
side] and
SNA
on the other [i.e. the ‘upstream’], as shown by the
diagram on the right. And this,
though often appearing somewhat trivial is the crux of why there has
been such a major change in how and where you place SNA gateways.
So just keep this in your mind: SNA on the
left-hand side, IP on the right-hand
side.
When we had SNA backbones, distributed or
remote SNA gateways, in the form of SNA-LAN gateways
(as
shown in the 2nd diagram) made
sense – since the network spoke SNA and the upstream side of the
gateway was SNA.
Bingo. It was in such configurations where MS
SNA Server
[the begetter of MS HIS] and Novell’s NetWare for
SAA [the original market leader] flourished. These gateways
were designed to emulate 3174 control units, where the 3174
 was the quintessential
SNA controller.
So much so that these gateways were even known as “PU Controller”
gateways given that 3x74s were (albeit incorrectly)
thought of as
SNA physical units (PUs).
In the mid-1990s, as
shown
in the 4 quadrant evolution diagram below,
most corporations, irrespective of their prior affiliation with SNA,
started to move towards router-based IP backbones. The router
vendors, led by Cisco but who in those days also included IBM, 3Com,
Bay and CrossComm, cognizant of the importance of SNA, catered for
SNA/APPN traffic via LAN bridging [e.g. source-route] as well as
data link switching [DLSw]. Both these techniques permitted SNA/APPN
traffic to be easily (and even transparently) transferred across IP
backbones. Consequently there was really no need to make any
changes to the SNA configurations, including the use of distributed
SNA gateways.
‘tn’ and Web-to-host Changed Everything
Today ‘tn’,
which is universally supported by traditional fat clients [e.g.
Attachmate’s EXTRA!], applet-based ‘thin-clients [e.g. IBM’s
HoD] and host-to-HTML host publishers [e.g. Farabi HostFront],
is incontrovertibly the protocol of choice, around the world, for
accessing SNA
applications running on mainframes or iSeries machines. The days of
PC SNA emulators using NetBIOS or IPX to interact with SNA gateways
is long gone.
With ‘tn’ (and IP backbones) distributed
gateways do not make sense. Period.
IP, which is used to encapsulate the 3270 or
5250 data stream, is the native protocol used by ‘tn’ between the
gateway [i.e. ‘tn’ server] and the remote clients.
In other
words, ‘tn’ is a bona fide
TCP/IP ‘application’. With ‘tn’ there is no need for bridging
or DLSw. You can use straight
TCP/IP between
all the remote clients and the ‘tn’ server – and furthermore avail
yourself to all the joys of IP, such as automatic re-routing and QoS
etc.
To use a distributed ‘tn’ server that speaks
SNA ‘upstream’, in the context of an IP backbone, is ludicrous.
There is nothing to be gained. Why deal with SNA at the remote end
points when there is absolutely no need to do so.
So distributed gateways are dead.
Today, with ‘tn’ you have no option but to
consider, centralized ‘tn’ servers – ideally in the data center.
This is even true if you have multiple data
centers. You can have ‘tn’ servers at each and use IP addressing at
the client, in the form of multiple icons if need be, to select the
different servers depending on the location of the application being
accessed.
Forget Enterprise Extender (EE)
EE is the major new feature in HIS 2004 –
following the long hiatus between HIS 2000 and 2004 (during which MS
decimated the resources allocated to HIS). EE, as SNA/APPN routing
(as opposed to transport) over IP, does in theory, permit the
continued use of distributed SNA gateways. But that is crazy.
There is no technical merit, whatsoever, for using EE to route
3270/5250 traffic to/from distributed ‘tn’ servers. Think about it.
Yes, we still
have mission-critical, native SNA devices at remote locations – in
particular ATMs,
POS systems and banking equipment. These native
SNA devices
cannot use ‘tn’. They don’t talk IP in any way, shape or form. So
one can postulate that EE is a good way to support such native
SNA
devices – and Microsoft will tell you that having HIS 2004 in each
of the remote sites is the way to do this.
But invariably there is no need for EE if you
already have DLSw -- or if your routers support DLSw.
There are only two, increasingly esoteric,
scenarios where EE will prove to be better than DLSw. These are:
1.
EE will
support SNA
class-of-service (COS) based end-to-end traffic priority across
the network
[especially if you have OS/2 based SNA LU 6.2
applications]
2. EE will support APPN/HPR
network node oriented end-to-end routing across a network with
multiple APPN/HPR ‘end nodes’
If you do not
have a requirement for
COS or
SNA routing forget EE. Stick to DLSw.
None of this
stuff or recommendations are new. I have consistently maintained
this stance since 1995 – and you can, for a start, find these same
recommendations in my 1996 and 1999 books (not to mention my other
writings in places like “TCP/SNA
Update”).
So once again you are being dissuaded from
using HIS 2004 in a distributed configuration.
The Data Center Gateway
So now the
question becomes whether you want to think about using HIS 2004 as your
data center ‘tn’ server. You should think about it but ask yourself
why you would opt for a MS ‘tn’ gateway when you could get a better
deal with IBM’s
HIS – on Windows 2003 to boot.
At this juncture the platform issue becomes a
joke.
You can’t claim you prefer HIS 2004 because it
works with Windows 2003.
So does IBM’s Comm. Server.
If you have iSeries applications you will need
an external, ‘tn’ server. If so, Windows 2003 is obviously an
option. But with Comm. Server you can also think of Linux or AIX,
with their significantly better reputation for security and
scalability.
In the case of mainframes you have another
inescapable option. A mainframe resident ‘tn’ server, in particular
Comm. Server for z/OS. My preference for this gateway is well known,
and I do not have to go into the details here.
See my old White Paper which still holds true.
The claims that a mainframe resident ‘tn’
server wastes precious mainframe cycles is true but one has to
realistically weigh the pros and cons of this. As I have pointed
out in my
White Paper, in the overall scheme of things, a
mainframe ‘tn’ server uses about as much cycles, comparatively, as
the additional gas consumed by a car stereo. So unless you are one
of those rare individuals that saves gas by not using their car
stereo, you shouldn’t be that overly concerned about the
exploitation of mainframe ‘tn’ servers. Remember it is all about
mission-criticality and as such what we are looking for is
performance, resilience, scalability and security.
There are
other technical reasons such as
IBM’s
strategic Queued Direct Input/Output (QDIO) support across
the OSA-Express adapters – the new way to attach networks to
mainframes. QDIO does not support SNA or APPN. It only supports
IP. This provides added impetus to having an inboard ‘tn’ server
(and I won’t even bother to talk about why it is counter-productive
to even think about using EE with an external ‘tn’ server just so as
to be able to use QDIO).
The bottom line
With ‘tn’,
distributed gateways are passé. It only makes sense to have
centralized, data center ‘tn’ servers. EE is not a justification
for distributed ‘tn’ gateways. Unless you have a bona fide need for
SNA CoS or routing, you should not bother with EE. Instead use DLSw.
IBM’s Comm. Server supports Windows 2003 as well as Linux, AIX, z/OS and
z/Linux. So you have a straight apples-to-apples choice. If you
want a Windows 2003 gateway it does not have to be HIS 2004. If you
only have mainframes you really should consider a mainframe resident
gateway, even the z/Linux option if you are not running z/OS.
If YOU are a
Big Iron Club member (of good
standing) and would like more detailed, customized analysis, data
or comments drop me an e-mail. |
