  |
 |
|
Plataforma de
Integración Host con Red Local,
Internet /
Intranet / Infovía |
|
Conectividad TCP/IP
en entornos AS/400
Para conseguirlo, profundizaremos en varios
aspectos:
• Cómo y por qué se ha convertido TCP/IP en el
estándar "abierto".
• La diferencia entre utilizar TCP/IP como una
solución de interoperabilidad, y utilizarlo como protocolo de red.
• Las diferencias de implementación entre la
perspectiva servidor de IBM, y la perspectiva cliente de Microsoft.
• La arquitectura y los pros y contras en cada
una de las tres estrategias de conectividad C/S bajo TCP/IP que hemos
detallado.
Con esta información podrá evaluar las
necesidades Cliente/Servidor bajo TCP/IP de su organización y determinar cuál
de las tres estrategias es más adaptable a su entorno.
El Transmission Control Protocol/Internet
Protocol
Originalmente, el TCP/IP se debió a la necesidad
de disponer de interoperabilidad entre tipos de sistemas distintos. Las bases
las fijó el Departamento de Defensa de los Estados Unidos (DOD) y se
desarrolló bajo la dirección de ARPA (Advanced Research Project
Agency). La implicación de organismos públicos en su nacimiento impulsaron
dos características que a largo plazo han sido determinantes y muy
beneficiosas:
• Todos los servicios y protocolos fundamentales
del TCP/IP son de dominio público. Cualquiera puede obtener sus
especificaciones e implementar a su vez sus propios servicios y
protocolos.
• A principios de los 80, el DOD decretó que
cualquier fabricante que quisiera vender al DOD debería soportar TCP/IP. Como
resultado, la práctica totalidad de los fabricantes implementaron (aunque
fuera de modo básico) TCP/IP en todos sus equipos.
Fuera de los imperativos del DOD, TCP/IP se
impuso como arquitectura de red para Internet y los sistemas Unix.
Desafortunadamente, a finales de los 70 y principios de los 80 la Internet no
estaba extendida entre los usuarios de Informática y Unix aún no estaba
considerado como un sistema empresarial viable. Estos factores retuvieron al
TCP/IP como una arquitectura destinada a un reducido sector durante mucho
tiempo.
Sin embargo, ¿cómo ha conseguido TCP/IP emerger
de las sombras y situarse como el estándar de los sistemas "abiertos"? Es
evidente que la transición no se ha producido en quince días y que ha sido el
resultado de una serie de desarrollos específicos.
A mediados de los 80s, Unix se mostró capaz de
ser utilizado en entornos empresariales. Al tiempo que se extendía, los
servicios y protocolos TCP/IP que permiten a Unix interoperar en un entorno
distribuido se hicieron más y más conocidos. La "comunidad empresarial" se dio
cuenta de algo que la comunidad universitaria y científica conocía desde hacía
años: TCP/IP había madurado en un espectro muy amplio de arquitecturas
contando con un gran número de servicios de comunicación e interoperabilidad.
De repente, las empresas se dieron cuenta de que
podían implementar servicios de comunicación e interacción primarios,
basándose en los servicios fundamentales de TCP/IP: emulación de terminal
(Telnet), transferencia de datos (FTP) y correo electrónico (SMTP). Con el
tiempo se fueron incorporando de nuevos: TN3270 para acceder a Mainframes en
modo terminal, SNMP (Simple Network Management Protocol) para gestión
de redes, LPR (Line Print Remote) para compartir impresoras y NFS
(Network File System) para compartir directorios y ficheros.
Debido al éxito del TCP/IP, el número de
servicios portados a entornos no-Unix empezó a aumentar. Cuando la atención
pasó de los servicios de interacción (Telnet, FTP, SMTP…) a los protocolos
subyacentes TCP, IP y UDP (User Datagram Protocol), la fascinación de la
industria informática con el TCP/IP se disparó. Los administradores de redes
se dieron cuenta de que podían construir redes para toda la compañía basadas
exclusivamente en TCP/IP; el resto de servicios no-TCP/IP no era problema,
puesto que podían tratarse como tráfico encapsulado. Los beneficios de
implementar TCP/IP como único protocolo de red son lo suficiente llamativos
como para no considerarlos:
• Es una solución de red absolutamente fiable y
probada. La red más grande y más concurrida del mundo (Internet) es una red
TCP/IP.
• Puede operar sobre distintos tipos de redes
como Ethernet/802.3, Token-Ring/802.5, FDDI, ATM, Frame Relay, X.25, así como
líneas convencionales (líneas conmutadas –RTC) y líneas telefónicas
dedicadas.
• Las redes TCP/IP son muy económicas de
construir, ampliar y mantener. El mercado, tanto software como hardware, es
muy amplio y competitivo, lo que revierte en unos precios muy
asequibles.
• TCP/IP es fácil de comprender y está respaldado
por montañas de material de consulta y legiones de consultores especializados.
A la vez que Internet se convertía en la
"vedette" de la industria informática, el TCP/IP se convertía en el protocolo
por defecto y en la solución de interoperabilidad más extendida. El hecho de
que Internet sea una red TCP/IP, aún hace más atractiva la opción, incluso en
organizaciones fielmente seguidoras de la solución de red SNA de
IBM.
Desde el punto de vista del consumidor, TCP/IP es
la tierra prometida de la interoperabilidad. Desde el del fabricante, una
auténtica pesadilla, porque echa por tierra la posibilidad de mantener equipos
y protocolos propietarios. De hecho, inicialmente muchos fabricantes
intentaron aportar a sus equipos suficientes servicios TCP/IP como para poder
ser considerado como tal, pero insuficientes para que la interoperabilidad
fuese una realidad. Recordemos, por ejemplo, su limitada implementación en el
AS/400 antes de la V2R3. La demanda de implementaciones completas que
permitiesen total interoperabilidad con servicios TCP/IP, siendo éste el único
protocolo de red, continuaba creciendo. Ante este clamor, ni IBM ni Microsoft
se quedaron con los brazos cruzados: captando el mensaje, ambas compañías
decidieron integrar TCP/IP en el diseño de sus soluciones de red. Sin embargo,
ante la pregunta: ¿Qué servicios TCP/IP debían implementarse? dieron una
respuesta diferente, clave en la comparación de sus
implementaciones.
TCP/IP sin Unix
Decidir los servicios TCP/IP a implementar es un
reto, porque en la mayoría de entornos Unix existen cientos de ellos.
Portarlos todos a un entorno no Unix es una utopía (por diversas razones,
incluyendo el factor tiempo y la falta de lenguajes compatibles), con lo que
la clave del éxito reside en saber cuáles de esos servicios deberían ser
migrados. Para facilitar la tarea, los servicios se dividen en dos categorías:
(1) servicios que soportan funciones de usuario final (por ejemplo,
transferencia de ficheros con FTP), y (2) servicios que ayudan a la
configuración y la gestión de redes TCP/IP (por ejemplo, asignación dinámica
de direcciones IP).
Aunque los servicios de usuario final son muy
importantes, sólo están orientados a conseguir interoperabilidad entre redes y
equipos de distintos fabricantes. Así, podemos arrancar una sesión Telnet
contra una computadora de otra empresa o utilizar FTP para transferir ficheros
(desde un super-computador a un PC). No obstante, los servicios de
configuración y gestión de la red, son muy significativos, ya que facilitan y
mejoran de forma espectacular las operaciones y el mantenimiento. Mirémoslo de
esta forma: si estamos utilizando TCP/IP en una red con PCs bajo Windows95, no
hace falta TCP/IP para transferir ficheros (se pueden compartir directorios),
pero es imprescindible para traducir los nombres de los PCs de Windows95 en
direcciones IP.
A la complejidad de la configuración y gestión de
la red se añade el problema de que un mismo servicio puede ser implementado de
distintas formas. Por ejemplo, los nombres IP pueden ser traducidos en
direcciones IP a través del DNS (Domain Name Server) o de un servidor
NIS (Network Information Service). De igual forma, la asignación de
direcciones IP a los distintos sistemas, se puede resolver de forma manual, o
con protocolos de asignación dinámica, tales como BOOTP, RARP (Reverse
Address Resolution Protocol), o DHCP (Dynamic Host Configuration
Protocol). La duplicación de servicios implica que compañías como
Microsoft o IBM no sólo tienen que escoger qué servicios implementar, sino qué
estilo de servicio implementar.
En este punto es donde podemos comprobar las
diferencias en la aproximación al TCP/IP por parte de Microsoft y por parte de
IBM en el AS/400. En particular:
• El AS/400 soporta resolución de direcciones a
través de un servidor DNS. Sin embargo el AS/400 no se puede comportar como un
DNS, sólo puede ser un cliente.
• Asimismo, la implementación de Microsoft sólo
es capaz de soportar resolución de nombres IP como cliente DNS; pero existe
software de terceros capaz de realizar funciones de servidor DNS en los
entornos de Windows para Trabajo en Grupo, Windows 95 y Windows NT.
• Microsoft también soporta WINS (Windows
Internet Namig Service), que implementa resolución de nombres IP para
servicios de red nativos de Microsoft (compartición de ficheros o directorios,
de impresoras, y acceso a aplicaciones). Microsoft incluye ambos componentes
WINS: cliente y servidor.
• El AS/400 no soporta ningún protocolo de
configuración dinámica de direcciones IP, la dirección IP ha de ser
configurada de forma manual para cada AS/400. Si utilizamos configuración
estática de direcciones IP tanto en el AS/400 como en el cliente, la
probabilidad de cometer errores de configuración y de conexión aumenta;
además, cada cambio que realicemos será más costoso.
• Microsoft soporta DHCP (Dynamic Host
Configuration Protocol) como medio para asignar dinámicamente direcciones
IP a sistemas en la red. Microsoft incorpora DHCP tanto para cliente como para
servidor.
Con estos condicionantes, es un tanto arduo
construir una red TCP/IP de cierta envergadura alrededor de un AS/400, ya que
éste carece de soporte para asignación dinámica de direcciones y no puede
comportarse como un servidor de nombres. Como el AS/400 no provee estos
servicios, la responsabilidad, o se desplaza a la configuración del extremo
opuesto, el escritorio (PC), o podemos incluir otros sistemas en la red que
desempeñen este papel (por ejemplo, sistemas Windows NT o sistemas Unix).
La implementación de Microsoft no padece las
mismas limitaciones que la implementación TCP/IP del AS/400. La asignación
dinámica de direcciones se soporta con DHCP, el servicio de nombres se puede
soportar con software DNS o con WINS. De esta forma se puede construir una
gran red TCP/IP con sólo la arquitectura de Microsoft, y sin necesidad de
otros sistemas.
La perspectiva del cliente
Cuando hablamos de conectividad entre PCs y el
AS/400 en una red TCP/IP, el foco se desplaza de los protocolos y servicios de
bajo nivel hacia los servicios de emulación y Cliente/Servidor necesarios.
Como ya adelantamos en la introducción, podemos optar por una de las tres
estrategias de conectividad TCP/IP disponibles:
• Ejeutar TCP/IP en el PC y en el AS/400 y
utilizar sus servicios nativos, tales como TN5250, FTP y LPR, para integrar el
PC con el AS/400.
• Tener TCP/IP tanto en el cliente como en el
servidor, y utilizar el producto AnyNet de IBM para encapsular el tráfico SNA
entre el clien te y el servidor a través de la red TCP/IP.
• Montar TCP/IP en el PC y dejar el AS/400 con su
SNA nativo, y utilizar Microsoft SNA Server para proveer de conexión de extre-
mo a extremo entre los PC y el AS/400.
Como es lógico, estas estrategias difieren
bastante y condicionan la implementación del TCP/IP.
Integración utilizando servicios TCP/IP
Nativos
Si instalamos TCP/IP tanto en el PC como en el
AS/400, podemos utilizar sus servicios nativos para integrar los dos entornos.
La única consideración a tener en cuenta es cómo implementar emulación de
terminal vía Telnet. Tenemos varias opciones:
• TELNET estándar. El software Telnet que viene
con la mayoría de los productos TCP/IP emula terminales de caracteres tales
como VT100 de Digital. Cuando el tráfico en modo carácter llega al AS/400,
éste debe (1) recibir cada carácter y enviar un eco a la vez que se teclea en
el terminal, (2) convertir la corriente de datos al formato 5250 y (3) proveer
mapeo de teclado, de forma que el usuario pueda acceder a las funciones
programadas (F1 a F24). El AS/400 no está especialmente bien dotado para estas
funciones y el resultado es un entorno de emulación que, aunque funciona en
términos técnicos, consume recursos de CPU y es extremadamente complejo de
utilizar.
• TN3270. Telnet 3270 fue desarrollado como un
servicio Telnet alternativo para Mainframes. Proporciona emulación de teclado
y servicio en modo bloque desde el mismo cliente, liberando al Mainframe de
realizar los trabajos de traducción. Se puede utilizar para conectarse al
AS/400 y tiene bastante mejor aspecto que el Telnet estándar. Aunque el AS/400
todavía tendría que traducir la corriente de datos 3270 en 5250 y mapear las
secuencias de ambos teclados. Como con el Telnet estándar, existe un consumo
innecesario de CPU. Aunque TN3270 provee un interfaz funcional, la gestión de
campos numéricos y del teclado resultan, como mínimo, toscas.
• TN5250. Telnet 5250 es al AS/400 lo que el
TN3270 es al Mainframe. TN5250 proporciona emulación 5250 y soporta casi todas
las funciones, atributos y secuencias de teclado. Como resultado, su aspecto
resulta natural e intuitivo, y el AS/400 no requiere programas residentes
especiales. TN5250 ha avanzado de tal forma que a la mayoría de los usuarios
de AS/400 les resulta imposible determinar la diferencia entre una emulación
TN5250 y una emulación 5250 nativa.
Casi todos los programas TCP/IP que incluyen un
cliente Telnet, incluyen un cliente TN3270, que también se puede bajar de
servidores FTP, encontrar como shareware e incluso en recopilaciones de CDs.
Sin embargo, el cliente TN5250 se mantiene como una opción comercial que
proporcionan compañías dedicadas a desarrollar software C/S para el entorno
AS/400 (por ejemplo, Attachmate, Eicon, Wall Data y
WRQ).
Ahora bien, tanto TN3270 como TN5250 sólo
facilitan emulación de sesión. No tenemos ni emulación de impresora ni
transferencia de ficheros. Si necesitamos esta funcionalidad tendremos que
utilizar protocolos tales como FTP para la transferencia de ficheros, o
LPD/LPR para la impresión (Figura 1). Desafortunadamente, FTP nos
proporciona un método interactivo de transferencia de ficheros sin opciones de
selección de campos o registros y sin posibilidad de convertir de tipo (la
conversión entre códigos ASCII –PC- y EBCDIC –AS/400- sí está garantizada).
Dadas estas limitaciones, en muchas ocasiones se realizan programas
adicionales que seleccionan datos en el AS/400, los dejan en un fichero de
impresión y es éste el que se transfiere.
LPD/LPR son programas que cooperan para imprimir.
LPR es el programa que inicia el proceso y envía el fichero a imprimir al
receptor (LPD). El AS/400 se comporta tanto como LPD como LPR y casi todos los
programas de PC también lo hacen. Con esta arquitectura, definimos una cola de
salida del AS/400 como una cola LPR que asociamos a una impresora de PC. El PC
que la soporta debe correr un programa residente LPD asociado. En la opción
contraria, imprimir en una impresora del AS/400, la función LPR del PC
presenta una cola LPD del AS/400 como si fuera una impresora de red. Como la
mayoría de implementaciones LPD/LPR (incluidas las del AS/400) no incluyen
emulación de impresora, el programa que envía la impresión debe formatear la
salida según el programa que la recibe.
Considerando todos estos componentes, un PC que
tuviese TN5250, FTP y LPD/LPR ofrecería un resultado satisfactorio para
usuarios con pocas exigencias. De ninguna manera obtendríamos los resultados
que se consiguen con CA/400. Por ejemplo, el TCP/IP nativo no soporta carpetas
compartidas, emulación de impresora, transferencia de ficheros con opciones,
colas de datos, text assist, ODBC/DRDA o las APIs del CA/400.
En todo entorno TCP/IP siempre aparecen temas
relacionados con la configuración y la gestión. En el AS/400 los clientes
TCP/IP no se configuran de forma tan sencilla como los SNA. Los dispositivos y
los controladores no se generan para un sistema cliente en especial; en lugar
de ello, todos los clientes comparten una misma definición TCP/IP de
controlador. Si un AS/400 necesita establecer contacto con un cliente
determinado, tiene que acceder a una tabla de direcciones IP o pedir ayuda a
un servidor de nombres (DNS).
Una última consideración a tener en cuenta es la
versión del sistema operativo: aunque en el AS/400 el TCP/IP esté disponible
desde la V1R2, no se ha incorporado a su sistema operativo hasta la V3R1 y el
rendimiento y consistencia no son iguales en todas las versiones. Para una
funcionalidad plena y para obtener buenos niveles de rendimiento, necesitamos
la V3R1 o superior. En los Mainframe de IBM, el TCP/IP se adquiere por
separado.
AnyNet de IBM
Si consideramos la estrategia AnyNet de IBM para
la conectividad entre AS/400 y PC, desaparecen varias de las limitaciones de
la aproximación tradicional en TCP/IP, ya que AnyNet permite ejecutar el
software Cliente/Servidor tradicional sobre la red TCP/IP. Por ejemplo,
podemos correr CA/400 sobre TCP/IP sin renunciar a ninguna de sus funciones.
En teoría, cualquier operación que se pueda ejecutar sobre una red SNA, puede
ser ejecutada sobre una red TCP/IP utilizando AnyNet.
La transformación del tráfico SNA al formato
TCP/IP se ejecuta al nivel de aplicación tanto en el servidor como en el
cliente (Figura 2). En el caso del CA/400, la transformación la
proporciona el programa router antes de entregar su tráfico a la red. En el
AS/400, la traducción tiene lugar antes de que las correspondientes rutinas de
servicio (p.e. carpetas compartidas) se hagan cargo de la información. Como la
traducción se produce a nivel de red, las aplicaciones y servicios de ambos
extremos no se enteran de que el tráfico ha pasado por una red TCP/IP,
viéndolo como puro SNA.
El proceso de traducción y encapsulación
utilizado por AnyNet deriva del Data Link Switching (DLSw), una técnica
utilizada por los routers para mover tráfico SNA sobre una red TCP/IP. Al
contrario que DLSw, AnyNet no requiere de ningún tipo de hardware adicional o
equipos de conectividad, ya que toda la traducción se produce entre el AS/400
y el cliente. Tampoco requiere que los clientes utilicen protocolo DLC
(Data Link Control) para acceder a la red; por el contrario, los clientes
utilizan TCP/IP nativo.
El proceso de encapsulación utilizado por AnyNet
es relativamente eficiente. Los campos, de hecho, se sacan de las cabeceras
SNA y se montan sobre cabeceras TCP/IP para reducir la sobrecarga de la red.
Desafortunadamente, como las cabeceras TCP/IP son mucho más largas, sigue
existiendo una penalización en la negociación.
Su mayor ventaja es que nos permite seguir
ejecutando las aplicaciones normales C/S que corrían sobre APPC en nuestra red
TCP/IP. Este pro, tiene sus contras. En particular, AnyNet tiene varias
limitaciones:
• AnyNet sólo está disponible el la V3R1 o
superiores de OS400.
• Los productos C/S deben estar preparados para
soportar AnyNet; no valen todos los que antes teníamos.
• Muchos clientes AnyNet aún no están migrados de
la plataforma de 16 bit a la plataforma de 32 bits de Windows 95 y Windows NT,
más potente y robusta.
• En una red AnyNet, las configuraciones no se
realizan de forma automática como en los entornos SNA: deben realizarse una a
una en el AS/400 o en el servidor DNS. Esta es una limitación propia de
cualquier red TCP/IP.
• La traducción entre TCP/IP y SNA consume
recursos de la CPU tanto del cliente como del AS/400. Los estudios realizados
prueban que un entorno operando con AnyNet, tiene un tiempo de respuesta y
operación más lento que en un entorno SNA puro.
Así las cosas, AnyNet es una buena opción en
aquellos entornos en los que tenemos CPU de sobra en el AS/400, OS/400 V3R1 y
redes TCP/IP con servicios DNS, y el presupuesto para migrar a productos que
soporten AnyNet. Las compañías que no se encuentren dentro de estos límites,
pueden encontrar las barreras un poco altas.
Gateway TCP/IP-SNA
La tercera estrategia para integrar AS/400 con
sistemas clientes en una red TCP/IP es utilizar un gateway como el Microsoft
SNA Server (Figura 3). SNA Server permite que la parte de los clientes
operen en un entorno nativo TCP/IP y el AS/400 en un entorno nativo SNA. Como
en el caso de AnyNet, los clientes no contemplan la complejidad de su red, y
de hecho se comportan como si estuvieran en una red SNA.
Microsoft SNA Server corre sobre la plataforma
Windows NT. Puede operar sobre procesadores Intel, ALPHA, MIPS y PowerPC
ofreciendo una gran variedad de alternativas de elección y de costes. No
requiere un sistema dedicado, ya que el mismo sistema Windows NT puede ser
utilizado como servidor de aplicaciones, de ficheros, de impresoras, de
correo, de bases de datos, o como servidor WEB, servidor DHCP, como servidor
DNS… Y además, se pueden instalar varios servidores SNA, de forma que la carga
se reparta entre ellos de forma automática y garanticen la conexión en caso de
que algún problema se produzca en alguna conexión.
SNA Server ofrece servicios de gateway entre el
cliente TCP/IP y la red SNA del AS/400, dando servicio sobre redes Token-Ring
o Ethernet. Entre las conexiones posibles encontramos conexiones LAN
(Token-Ring o Ethernet), SDLC, X.25, Internet, InfoVía o también
Twinaxial.
El tráfico entre el cliente y el servidor que
sale del cliente se enruta gracias a un módulo de software existente en el
cliente hasta el SNA Server. Este software se instala en lugar del CA/400 o
del router equivalente. Con SNA Server, tenemos cubiertos una gran variedad de
entornos como MS-DOS, Windows 3.X, Windows 95, Windows NT, OS/2, Macintosh y
UNIX. Al instalar SNA Server, no se precisa ningún cambio en las aplicaciones
C/S, ya que el SNA Server da, de forma transparente, un servicio de extremo a
extremo totalmente consistente.
El router de Microsoft es también el responsable
de traducir el tráfico SNA en TCP/IP. Una vez que el tráfico alcanza el SNA
Server, se traduce en formato SNA y se envía al AS/400 como tráfico normal de
red y por ello, éste no se ve penalizado por ningún proceso de
traducción.
La implementación de SNA Server es coherente y
está orientada a soluciones empresariales, ofreciendo numerosas
ventajas:
• Trabaja sobre cualquier versión de OS/400,
ofreciendo soporte consistente para todos los AS/400 de su entorno. Esto le
permite cambiar de versión a su ritmo.
• Lo soportan la mayoría de fabricantes de
software C/S para AS/400 como Andrew, Attachmate, Eicon, IBM, NetSoft, Wall
Data o WRQ. Por contra, no todas ellas ofrecen TN5250 o AnyNet.
• Soporta conexiones concurrentes a AS/400, S/38,
S/36 y Mainframes ya que se comporta como una PU 2.1 APPN LEN Node.
• Trabaja con MS-DOS, Windows 3.X, Windows 95,
Windows NT, OS/2, Macintosh y UNIX, soportando (en su última versión) hasta
5.000 usuarios concurrentes y 15.000 sesiones simultáneas.
• Coexiste con otros tipos de redes, permitiendo
conexiones concurrentes con el AS/400 de clientes bajo protocolos como
IPX/SPX, TCP/IP, Banyan Vines IP, NetBEUI y AppleTalk.
• Permite el acceso remoto vía RAS (Remote
Access Service) a los servidores Windows NT que aceptan todo tipo de
clientes, facilitando el acceso a través de Internet/InfoVía al AS/400 y
Mainframes.
• Aísla al AS/400 de la red TCP/IP, evitando
adoptar una seguridad extra y nueva, muy necesaria en los entornos TCP/IP. Es
más, SNA Server encripta la corriente de datos entre el cliente y el servidor
según el protocolo RC4 de la RSA, aumentando de forma significativa el nivel
de seguridad en la red.
• Soporta enlaces locales y remotos al AS/400.
Uno o varios servidores SNA pueden acceder a AS/400 locales, remotos o a ambos
tipos, permitiendo planificar la arquitectura de red con total comodidad. Las
conexiones soportadas por SNA Server incluyen twinaxial, Ethernet, Token-Ring,
SDLC, X.25, Internet e InfoVía.
• Puede interconectarse con otros servidores SNA
Server que se encuentren en oficinas remotas y regulen el tráfico desde uno o
más emplazamientos centrales. La conexión entre servidores SNA Server remotos
y locales se puede realizar a través de redes TCP/IP convencionales o la
propia Internet/InfoVía.
• Se puede instalar un gran número de servidores
SNA Server en una misma red y en un mismo dominio, para ofrecer backup,
balanceo de cargas, y tolerancia a fallos.
• Dado su intuitivo interface gráfico, su
utilización sólo requiere conocimientos del entorno. La administración se
puede centralizar y realizar desde un solo punto, ya sea desde dentro de la
red o desde un emplazamiento remoto (vía RAS, Internet, Intranet o Infovía)
mediante herramientas propias de Windows NT, como el Event Viewer, Event
Logger o el Performance Monitor.
• Las carpetas compartidas del AS/400 se pueden
representar como directorios del servidor Windows NT. Así si un usuario sólo
necesita acceso a las carpetas, no tenemos que darlo de alta en el AS/400 y
podemos administrar el acceso a las carpetas desde la misma seguridad de
Windows NT.
• Tenemos acceso al servidor DHCP de Windows NT
para asignar direcciones IP de forma dinámica. Esto elimina la necesidad de
manipular las direcciones IP a mano como en el caso de AnyNet.
• Se integra con todo el software de Windows NT.
Así podemos integrar correo IBM tal como OV/400 o OV/MVS o Memo con Exchange,
integrar bases de datos de AS/400 o Mainframe con Microsoft SQL Server y
enlazar programas y archivos desde el servidor Web.
• Ofrece todos los estándares abiertos de APIs,
ya que muchas de las aplicaciones de terceras compañías se apoyan en
ellas.
• Reduce la sobrecarga en comunicaciones del
AS/400 asociada al control de las conexiones cliente. Un AS/400 tiene que
estar enviando señales a sus clientes de forma continua en entornos SNA o
AnyNet. Esta actividad consume, además de memoria, recursos del procesador del
AS/400. En cambio, SNA Server reduce el número de controladores definidos y el
AS/400 sólo necesita controlar un SNA Server.
• Podemos hacer crecer nuestra instalación tanto
como queramos. SNA Server se puede apoyar en nuevas arquitecturas tales como
Procesamiento Paralelo o sistemas con 64 bits, como ALPHA.
Vemos pues que Microsoft SNA Server es una
plataforma fiable, potente y escalable, pero no es un software aislado, ya que
debe ser montado encima de una plataforma como es la de Windows NT. Por ello,
antes de instalar SNA Server, debemos instalar Windows NT. Pero dada la
potencia y la cantidad de posibilidades que aporta
Windows NT Server, ese (en principio)
prerequisito, se convierte en una gran ventaja que justifica sobradamente la
instalación de SNA Server en su organización.
La elección es suya
A largo plazo, las estrategias que adoptemos
pueden resultar de suma importancia y debemos tener en cuenta cuál es nuestro
entorno de trabajo. Si contamos con un reducido número de PCs que han de
integrarse en una red TCP/IP y tenemos el AS/400 en V3R1 o superior, las
opciones de TCP/IP puro o AnyNet pueden ser viables. En estos entornos, una
estrategia TCP/IP puede proveer de casi todos los servicios (FTP, LPD/LPR,
TN5250) sin aumentar el grado de complejidad. AnyNet nos proporcionará toda la
funcionalidad del entono SNA, pero sin embargo también es más compleja y
consume más recursos en el AS/400 y más ancho de banda en la red
local.
En el entorno de grandes redes, ni TCP/IP ni
AnyNet son buenas soluciones de conectividad en entornos AS/400. La
imposibilidad del AS/400 de participar en negociaciones de direcciones IP
dinámicas o de comportarse como servidor DNS limita su papel en
implementaciones de redes grandes. Además, no todos los fabricantes
implementan en sus soluciones TN5250 y AnyNet. Otro factor a tener en cuenta
es que ambas implementaciones no son viables en versiones del sistema
operativo anteriores al OS/400 V3R1. AnyNet simplemente no existía y TCP/IP no
ofrecía un rendimiento aceptable.
Por contra, Microsoft SNA Server se adapta a todo
tipo de redes TCP/IP, sin tener en cuenta su tamaño y complejidad ni el tipo
de cliente que se quiera conectar. Además, aprovechando la funcionalidad de
Windows NT Server junto con las de SNA Server, podemos crear soluciones de
acceso a entornos AS/400 de forma rápida y eficiente. Al disponer de servicios
como DHCP, WINS y DNS, la gestión se simplifica de forma importante. La
combinación de Windows NT Server y SNA Server supera claramente la capacidad
del AS/400 en solitario para enfrentarse a ese entorno
TCP/IP.
Adicionalmente, SNA Server puede resolver
problemas fuera del entorno de TCP/IP. Puede acceder en remoto, por Internet,
Intranet o Infovía, desde cualquier tipo de cliente y desde un entorno de
redes heterogéneo, conteniendo además de TCP/IP, IPX/SPX, Banyan Vines,
NetBEUI o NetBIOS. Resumiendo, SNA Server es una herramienta multipropósito
que ofrece una gran variedad de soluciones para la interoperabilidad entre los
clientes y el AS/400.
La mala noticia es que no existe una sola forma
de implementar redes TCP/IP. La buena noticia es que usted tiene tres opciones
distintas y que no está atado a la visión de un único fabricante. En el mundo
de la interoperabilidad, poder escoger es progreso.
|
Conectividad
TCP/IP en entornos AS/400
TCP/IP se ha
convertido en el estándar de los entornos "abiertos" de
comunicaciones.
Los líderes de la industria informática han
realizado verdaderos esfuerzos para
incorporarlo como parte nativa de sus productos. En particular,
citemos los de IBM para integrar TCP/IP dentro del OS/400, o los de
Microsoft para permitir que la comunicación entre redes con sistemas
operativos Windows Trabajo en Grupo, 95 y NT, sea TCP/IP. Como
consecuencia de estos y otros desarrollos, los protocolos propietarios
del pasado, han quedado ampliamente superados.
A pesar de que TCP/IP sea un
protocolo independiente del entorno y de los sistemas, implementarlo
para conexiones Cliente/Servidor (C/S) en el AS/400 tiene importantes
matices, puesto que se pueden emplear tres aproximaciones
distintas:
• Utilizar protocolos
nativos TN5250, FTP, LPD/LPR y el resto de servicios TCP/IP tanto en
los PC como en el AS/400.
• "Montar" el actual tráfico
SNA sobre TCP/IP mediante la opción AnyNet de IBM.
• O bien implementar un
gateway TCP/IP-SNA, como Microsoft SNA Server, para optimizar la
comunicación entre la red y el
AS/400.
La intención de este informe
especial es ayudarle a conocer la tecnología subyacente bajo el TCP/IP
y cómo se puede enfocar desde estas tres diferentes estrategias de
conectividad. |
Este informe especial ha sido desarrollado y
escrito de forma independiente de Microsoft.
® Duke Communications
International