Irrumpe Microsoft en el Mercado de Soluciones CRM

DESARROLLO
EJECUTIVO
Buscan Salarios Óptimos en TI

El Futuro de los CIOs

SEGURIDAD
Ofrece IBM más Seguridad en Transacciones por Internet

Cómo Crear una Extranet B2B

La creación de una extranet que soporte la cadena de suministro de la empresa es una de los desafíos fundamentales para tomar ventaja en los negocios business to business. Aquí presentamos un modelo basado en el caso de un fabricante interconectado con sus proveedores.

Para crear un modelo ideal de extranet dedicada a soportar la cadena de suministro, se eligió el caso ficticio de un fabricante de máquinas. A partir de aquí, se simularon dos escenarios extranet comunes: un enlace con un proveedor de misión crítica (un suministrador de piezas) y otro con un proveedor menos fundamental para el negocio (un vendedor de material de oficina). Tres eran los objetivos: crear un enlace de red fiable tanto en hardware como en software, dar la seguridad apropiada y asegurar la integridad de los datos.

Conexiones de Red
¿Qué medio de soporte de las transacciones con un socio comercial es el mejor, una línea alquilada, Frame Relay o una VPN basada en Internet? La respuesta dependerá de la criticidad que ese enlace tenga para la empresa. En el caso elegido de una planta de fabricación parece claro que no disponer en el momento oportuno de las piezas necesarias podría traducirse en pérdidas significativas, a diferencia del impacto que provocaría una eventual falta de materiales de oficina.
Teniendo en cuenta lo anterior, para el enlace crítico se eligió un par de líneas alquiladas E-1 (2 Mbps) de dos operadores diferentes, lo que asegura una máxima disponibilidad. Para asegurarse un servicio continuado se probaron dos herramientas de balanceo de cargas, Microsoft Windows Load Balancing Service y Lightspeed Systems Total Control for E-Commerce IPMagic, para conmutar instantáneamente a la segunda línea cuando falle la primera. Ambas funcionaron perfectamente. Esta solución es cara en su conjunto, pero permite garantizar una fiabilidad del 99,9 por ciento.

Una alternativa más barata a la solución adoptada, también muy efectiva, consiste en contratar un par de enlaces Frame Relay a dos operadores diferentes. Sin embargo, se optó por las líneas arrendadas debido a que permitía utilizar hardware más sencillo. A pesar de los obvios ahorros de costos, se rechazó la idea de usar una red privada virtual (VPN) basada en Internet porque añadía complejidad en la gestión y mayores riegos de seguridad, al tiempo que proporciona un rendimiento poco fiable.

Para el enlace con los suministradores de material de oficina -menos crítico- la alternativa VPN sí resultaba adecuada, ya que si Internet falla el impacto sobre el negocio no sería fundamental. Así, se creó una VPN de bajo ancho de banda entre la empresa y sus suministradores.

Gestión de Enlaces
Establecer los niveles de servicio y decidir quiénes serían los responsables de monitorizar el enlace con las firmas de piezas fueron importantes pasos en el desarrollo del proyecto. Para mantener una fiabilidad del 99,9 por ciento, cada enlace E-2 se dedicó a soportar pedidos de piezas, sin correo electrónico ni voz sobre IP (VoIP). Debido a su fiabilidad y su fácil configuración, se eligió VitalSuite, de Lucent, para monitorizar la WAN.

La negociación con un socio comercial para soportar comunicaciones TCP/IP no debería ser un problema, dada la popularidad de estos protocolos, fácilmente encaminables. Con todo, se prefirió complicar algo más la experiencia de laboratorio, estipulando que el suministrador de componentes utilizara un AS/400 y la arquitectura SNA de IBM.

Para conseguir los objetivos iniciales, se concluyó que la mejor solución al problema que suponía utilizar niveles de transporte dispares era diseñar la aplicación con Advanced Program-to-Program Communications (APPC, también conocido como LU 6.2) para enviar y recibir transacciones. Y, a pesar de que se intentó por todos los medios complicar la situación, el diseño y administración del enlace APPC fue sencilla.

La única dificultad real apareció a la hora de diseñar el diálogo automatizado para que fuera tolerante a fallas imprevistas en la conexión, de modo que siempre se asegurase que las órdenes de pedidos llegasen a su destino. La intención era considerar a cada grupo transaccional de mensajes como un átomo, es decir, que la aplicación procesara solamente transacciones completas. También fue sencillo configurar un par de routers Cisco 4700, uno en la planta de ensamblaje y otro en las instalaciones del suministrador de piezas, para comunicar los paquetes SNA a través del enlace WAN.

Se rechazó la idea de usar una base de datos relacional como interfaz entre la planta de fabricación y el suministrador de piezas. Aunque insertar órdenes y confirmaciones en una base de datos compartida no tiene complicaciones, cada socio podría necesitar enviar un trigger (aviso) por la WAN para alertar a la otra parte de la introducción de una orden o confirmación cada vez que se produjese.

¿Por qué no enviar la transacción entera en vez de sólo el trigger?
Siguiendo otro enfoque, los socios podrían sondear la base de datos periódicamente para detectar actividades nuevas no procesadas. Pero este método consume mucho ancho de banda. También se rechazó la utilización de replicación de bases de datos porque ambos socios comerciales necesitarían actualizar los datos y no podrían designar un único responsable de esta tarea.
El enlace SNA de la empresa con el AS/400 funcionó bien, pero se quiso investigar un método que pudiera reducir la tarea de los programadores de aplicaciones a la hora de hacer conexiones de redes. Después de todo, ellos no son expertos en redes. Así, se eligió contrastar el enlace SNA creado con Message Queue Server (MSMQ) de Microsoft y MQSeries de IBM.

Como estas herramientas garantizan la entrega de mensajes, resultan muy apropiadas para crear diálogos automatizados basados en transacciones; se encargan además de efectuar las conversiones entre los formatos de datos en función de las necesidades. Aunque ambas trabajaron bien y fueron fiables en el laboratorio, en general MQSeries proporcionó el mejor enlace de red entre los servidores Windows NT corporativos y el AS/400 del proveedor. Su establecimiento resultó más sencillo que el de MSMQ, sin requerir ningún tipo de administración adicional. Además, corre sobre múltiples sistemas operativos, mientras que MSMQ depende específicamente de NT.

Por el contrario, la utilización de MSMQ, integrado gratuitamente en Windows NT Server 4.0 Enterprise Edition y Windows 2000 Server, fue complicada, ya que exige la instalación y configuración de otros tres componentes: Microsoft Transaction Server, SNA Server y SQL Server. MSMQ almacena información sobre colas (pero no los mismos mensajes, que residen en ficheros mapeados en memoria) en SQL Server. Se decidió usar además el componente opcional COM Transaction Integrator (COMTI) for CICS, para proporcionar acceso transaccional al servidor AS/400 del proveedor de piezas. COMTI consiste en un conjunto de herramientas de desarrollo y servicios run-time que tratan las transacciones SNA y la lógica del negocio como componentes COM que corren en un entorno Windows DNA.

Transaction Server se dedicó a asegurar la integridad transaccional y a gestionar un conjunto de conexiones de base de datos. SNA Server estableció y mantuvo el enlace al AS/400. El resultado requirió un considerable esfuerzo de programación. Y lo que es más importante, desde una perspectiva de networking, el mantenimiento de MSMQ, Transaction Server, SNA Server y SQL Server requiere cuestiones administrativas adicionales. No obstante, ofrecen niveles elevados de rendimiento, robustez y fiabilidad.

Seguridad Garantizada
La falta de seguridad fue la principal desventaja de MQSeries. Se precisó asegurar que los datos que estaban fluyendo por el enlace eran encriptados, que las transacciones fueron autenticadas a medida que se originaban desde las fuentes autorizadas y que fuera verificada la integridad de los datos. Un producto de terceros, MQSecure, de Candle, proporcionó estas prestaciones a MQSeries. Por el contrario, bastaron las características de seguridad y las listas de control de acceso (ACL) incorporadas en MSMQ.

Mediante tecnología RC2 de RSA, los mensajes MQSeries protegidos por MQSecure fueron encriptados desde la aplicación fuente a la aplicación de destino. Los mensajes fueron completamente ininteligibles para el Sniffer utilizado y, como MQSecure encripta la porción ID de usuario de cada mensaje, fue imposible interceptar los falsos mensajes que se introdujeron en el cable. La autenticación de la fuente del mensaje realizada por MQSecure aseguró, además, la no repudiación. La validación del mensaje recibido aseguraba que estaba intacto.
MQSecure ofrece dos niveles de seguridad: "canal" y "aplicación". La primera protegió los datos sólo durante su viaje a través de la red; la segunda lo hace mientras residen en las colas de mensajes MQSeries. Se utilizaron ambos niveles en el laboratorio, a fin de asegurar de extremo a extremo las transacciones.
Con MSMQ de Microsoft, se utilizaron las características de seguridad y ACL de NT incorporadas en el producto, obteniendo un buen resultado. Los mensajes captados fueron ilegibles en el display de Sniffer y las colas de mensajes resultaron inaccesibles si no se introducen contraseñas e ID autorizados. Para crear colas de mensajes, asignar prioridades y monitorizar la entrega de los mensajes se utilizó Explorer sobre una máquina NT Server. Además, se configuró MSMQ para eventos de log, como rechazo de una contraseña o apertura de una cola, en el NT Server Security Log.

MSMQ utiliza Cripto API para encriptar y firmar digitalmente los mensajes en las colas. Al igual que la encriptación basada en RSA de MQSecure, Critpo API preservó la confidencialidad de las entradas de colas del mensaje, mientras que las firmas digitales evitaron el spoofing de mensajes falsificados. Para seleccionar las características de firma digital y encriptación sólo hay que hacer click en las hojas de propiedad mostradas por el Explorer de MSMQ.

MSMQ proporciona también lo que Microsoft llama Independent Clients, una facilidad de mensajería desencriptada y separada que se basa en las colas locales en lugar de la comunicación de la red. Si lo que se quiere es seguridad, lo mejor es olvidar esta característica.

Antes de comenzar a encriptar el enlace de red B2B con MSMQ o MQSecure, se vio gracias al Sniffer que el formato de los mensajes de la red podría dificultar la comprensión de sus contenidos. Los diálogos de transacciones propietarios y binarios diseñados resultaron más seguros que las conversaciones automatizadas basadas en XML. Para descodificar un mensaje binario, un hacker tendría que saber qué bytes de un mensaje pertenecen a qué campos de datos. Por el contrario, los diálogos basados en XML aparecían claramente legibles en el display del Sniffer. Es de destacar, por tanto, la gran seguridad que proporciona el middleware.

Para la extranet dedicada al suministro de material de oficina, se decidió no añadir seguridad adicional a la inherente a una VPN. Se usaron dispositivos Cisco Secure PIX 506 Firewall para crear enlaces VPN con los proveedores. Los algoritmos HMAC SHA1 de las unidades de Cisco proporcionaron adecuados servicios de encriptación y autenticación para los túneles de la red. Los equipos funcionaron además como cortafuegos entre la empresa e Internet.

Evitando Problemas
Durante el diseño del enlace con el proveedor de piezas, se procedió a identificar todos los puntos donde la red podría fallar a fin de dotarla de redundancia. Con un total de ocho routers y DSU/CSU, cuatro en cada sitio, se construyó un camino de datos de red redundante, utilizando un par de routers y DSU/CSU en standby en cada uno de los dos enlaces E-1. Para la interfaz con el suministrador de material de oficina, el mecanismo de respaldo se basó en dedicar VitalSuite para la monitorización de los enlaces E-1 y VPN, avisando cuando alguno de ellos fallaba.
A medida que se iban creando y probando los enlaces extranet, también se utilizaba VitalSuite para buscar problemas de rendimiento de las aplicaciones y para proporcionar datos referentes al nivel de uso con propósitos de planificación de capacidad. Los gráficos e informes de VitalSuite permitieron vigilar factores críticos como la utilización del ancho de banda y de la CPU del servidor. Sus prestaciones resultaron muy útiles tanto para las conexiones E-1 como VPN.
Evidentemente, no es lo mismo un entorno de laboratorio que un escenario real de producción, pero el modelo propuesto en estas páginas, abierto a las necesarias modificaciones y cambios que cada negocio exige, puede servir de referencia cuando la idea de construir una extranet B2B ya ronda en las cabezas de los responsables corporativos.

Imaginando la Realidad
Usando VisualBasic y la base de datos relacional Oracle Version 8i, junto con una combinación de Active Server Pages, el servidor de aplicaciones WebLogic 5.0 de BEA Systems y código Java 1.1.7B, se desarrollaron las partes servidor y cliente de los dos entornos extranet B2B. Cuando crecieron las necesidades, se utilizaron herramientas de desarrollo adicionales, como Visual C++.

Las herramientas de software de red que soportaron las aplicaciones fueron MQSeries y APPC (Advanced Program-to-Program Communications), de IBM; MQSecure, de Candle; Windows Load Balancing Service, Transaction Server, SNA Server, SQL Server, Message Queue Server y COM Transaction Integrator for CICS de Microsoft, Lightspeed Systems Total Control for E-commerce IPMagic; y VitalSuite, de Lucent.

El primer escenario simulaba un entorno gestionado por software de compras bajo demanda de material de oficina. Los proveedores de este tipo de productos trabajaban con Windows e Intel, como la empresa ficticia. La base de datos de inventario de ésta contenía alrededor de 100 items, con múltiples proveedores para cada uno de ellos.

Para el suministro de piezas, el plan especificaba que el proveedor utilizase un AS/400 corriendo OS/400, pero en el laboratorio se empleó Communications Manager/2 (CM/2) sobre OS/2 Warp para actuar como el lado AS/400 de las sesiones SNA LU 6.2 de la empresa. Mirando los mensajes SNA que cruzaban el cable no se podría decir de qué clase de computador procedían.

Entorno de Red
Los componentes servidor de la empresa ficticia corrieron sobre un NT Server 4.0 (Service Pack 5), usando tres computadores Gateway 2000 NS-8000 con procesadores duales Pentium II a 333-MHz, 512 MB de RAM y tres discos RAID-5 SCSI de 9 GB. El software cliente estaba formado por una mezcla de 30 plataformas NT Workstation 4.0, Windows 2000 Professional, Windows 98, OS/2 Warp 4.0 y Macintosh System 8. Tres redes locales Fast Ethernet a 100 Mbps, enlazadas por líneas arrendadas, Frame Relay y VPN, conectaban los servidores y clientes. Cada enlace WAN disponía de routers Cisco 4700 y DSU/CSU WANsuite 5160 de VeriLink.

En cada escenario extranet, se creó un entorno de cumplimiento de órdenes B2B, envío y recepción de pedidos, entregas y transacciones de facturas. Cada proveedor de material de oficina respondía a los pedidos de la empresa con mensajes de confirmación y, periódicamente, de facturas.

El segundo y más crítico entorno era el de compras de piezas bajo demanda. Permitió, de forma automatizada, pedir componentes, planificar entregas, consultar los stocks, alertar a la planta de producción de la escasez de algunas piezas y recibir facturas. Se experimentó con diálogos de propio diseño y con diálogos basados en XML, considerando las ventajas respectivas que aportan a la hora de personalizar las relaciones comerciales automatizadas para cumplir las necesidades concretas del negocio en cuanto a pedidos y entregas.

También se examinó el tráfico de la red mediante el software Sniffer de Network Associates Sniffer al objeto de detectar el tamaño de los paquetes, las densidades del tráfico, el nivel de utilización de la red y los intervalos de tiempo entre peticiones y respuestas.

OTRAS NOTAS EN ESTA SECCION Algunas Veces Sólo los Sistemas Laser o los Satélites Funcionarán Anuncia 3Com Solución de Comunicaciones Unificada Anuncia Cisco Sistema de Protección Contra Invasores Apuesta Enterasys por el Sector Educativo Añade CommWorks Capacidad de Soporte de Seguridad CALEA Avanza IBM en la Fabricación de Productos Electrónicos Flexibles Construyendo la Banda Ancha en los Negocios Encriptación, un Sueño Difícil Estudian Posibilidades de las Redes Locales Impulsarán el Desarrollo de Profesionales de Redes Incorpora la SEC de Veracruz Tecnología IP Las WLAN 802.11b Abren el Mercado Libera 3Com Solución Multilocalidades Ofrece Enterasys Dos Nuevos Switches Preparan una DWDM Metropolitana Para uso Generalizado Reconocen Labor de Centros de Recuperación Siguiendo Cada Uno de sus Movimientos Solución Para Mejorar la Administración de la Red