domingo, 19 de diciembre de 2010

GOOGLE APP ENGINE

¿Qué es Google App Engine?


Google App Engine te permite ejecutar tus aplicaciones web en la infraestructura de Google. Las aplicaciones App Engine son fáciles de crear, mantener y actualizar al ir aumentando el tráfico y las necesidades de almacenamiento de datos. Con App Engine, no necesitarás utilizar ningún servidor: sólo tendrás que subir tu aplicación para que tus usuarios puedan empezar a utilizarla.

Puedes proporcionar a tu aplicación tu propio nombre de dominio (como por ejemplo http://www.example.com/) a través de Google Apps. También puedes proporcionar a tu aplicación un nombre gratuito del dominio appspot.com. Podrás compartir tu aplicación con todo el mundo o limitar el acceso a los miembros de tu organización.

Google App Engine admite aplicaciones escritas en varios lenguajes de programación. Gracias al entorno de tiempo de ejecución Java de App Engine puedes crear tu aplicación a través de tecnologías Java estándar, que incluyen JVM, servlets Java y el lenguaje de programación Java o cualquier otro lenguaje que utilice un intérprete o compilador basado en JVM como, por ejemplo, JavaScript o Ruby. App Engine también ofrece un entorno de tiempo de ejecución Python dedicado, que incluye un rápido interprete Python y la biblioteca estándar Python. Los entornos de tiempo de ejecución Java y Python se generan para garantizar que tu aplicación se ejecuta de forma rápida, segura y sin interferencias de otras aplicaciones en el sistema.

Con App Engine, sólo pagas lo que utilizas. No existen costes de configuración ni tarifas recurrentes. Los recursos que utiliza tu aplicación, como por ejemplo el almacenamiento y el ancho de banda, se miden por gigabytes y se facturan según competitivas tarifas. Controlas la cantidad máxima de recursos que consume tu aplicación, de modo que siempre permanezcan dentro de tu presupuesto.

Puedes empezar a utilizar App Engine de forma totalmente gratuita. Todas las aplicaciones pueden utilizar hasta 500 MB de almacenamiento y suficiente CPU y ancho de banda como para permitir un servicio eficaz de la aplicación de alrededor de 5 millones de visitas a la página al mes, totalmente gratuitas. Cuando habilitas la facturación para tu aplicación, se incrementan tus límites gratuitos y sólo pagas aquellos recursos que utilices por encima de los niveles gratuitos.

El Entorno de Aplicación


Google App Engine permite desarrollar fácilmente aplicaciones que se ejecuten de forma fiable, incluso con pesadas cargas de trabajo y grandes cantidades de datos. App Engine incluye las siguientes funciones:

* servidor web dinámico, totalmente compatible con las tecnologías web más comunes,
* almacenamiento permanente con funciones de consulta, orden y transacciones,
* escalado automático y balanceo de carga,
* API para autenticar usuarios y enviar correo electrónico a través de las cuentas de Google,
* un completo entorno de desarrollo local que simula Google App Engine en tu equipo,
* tareas programadas para activar eventos en momentos determinados y en intervalos regulares.

Tu aplicación se puede ejecutar en uno de los dos entornos de tiempo de ejecución: el entorno Java y el entorno Python. Cada entorno proporciona protocolos estándar y tecnologías comunes para el desarrollo de aplicaciones web.

La zona de pruebas


Las aplicaciones se ejecutan en un entorno seguro que proporciona acceso limitado al sistema operativo subyacente. Estas limitaciones permiten a App Engine distribuir solicitudes web de la aplicación en varios servidores e iniciar y detener los servidores según las demandas del tráfico. La zona de pruebas aísla la aplicación en su propio entorno seguro de confianza, totalmente independiente del hardware, el sistema operativo y la ubicación física del servidor web.

Algunos ejemplos de las limitaciones del entorno seguro de la zona de pruebas son:

* Una aplicación sólo podrá acceder a otros equipos de Internet a través de los servicios de correo electrónico y extracción de URL proporcionados. Otros equipos sólo se podrán conectar a la aplicación mediante solicitudes HTTP (o HTTPS) en los puertos estándar.
* Una aplicación no podrá escribir en el sistema de archivos. Una aplicación podrá leer archivos, pero sólo aquéllos subidos con el código de la aplicación. La aplicación deberá utilizar el almacén de datos de App Engine, Memcache u otros servicios para todos los datos que permanezcan entre las solicitudes.
* El código de aplicación sólo se ejecuta en respuesta a una solicitud web o a una tarea cron y debe devolver datos de respuesta en un período de 30 segundos en cualquier caso. Un controlador de solicitudes no podrá generar un subproceso ni ejecutar código después de haber enviado la respuesta.

El entorno de tiempo de ejecución Java


Puedes desarrollar tu aplicación para el entorno de tiempo de ejecución Java a través de herramientas de desarrollo web Java y de estándares del API comunes. Tu aplicación interactúa con el entorno a través del estándar Java Servlet y puede utilizar tecnologías de aplicación web comunes como por ejemplo JavaServer Pages (JSP).

El entorno de tiempo de ejecución Java utiliza Java 6. El kit de desarrollo de software (SDK) Java de App Engine admite las aplicaciones de desarrollo que utilizan tanto Java 5 como 6.

El entorno incluye la plataforma 6 de entorno de tiempo de ejecución Java (JRE) SE y bibliotecas. Las restricciones del entorno de la zona de pruebas se implementan en JVM. Una aplicación puede utilizar cualquier código de bytes de JVM o función de biblioteca, siempre que no exceda las restricciones de la zona de pruebas. Por ejemplo, si un código de bytes intenta abrir un conector o escribir en un archivo, aparece una excepción de tiempo de ejecución.

Tu aplicación accede a la mayoría de los servicios de App Engine a través de las API estándar de Java. Para el almacén de datos de App Engine, el SDK Java incluye implementaciones de la interfaz de Objetos de datos Java (JDO) y de la interfaz del API de persistencia de Java (JPA). Tu aplicación puede utilizar el API JavaMail para enviar mensajes de correo electrónico con el servicio de correo electrónico de App Engine. Las API HTTP java.net acceden al servicio de extracción de URL de App Engine. App Engine también incluye las API de nivel inferior para sus servicios para implementar adaptadores adicionales o para su uso directo desde la aplicación. Consulta la documentación sobre las API delalmacén de datos, Memcache, la extracción de URL, el correo, las imágenes y las cuentas de Google.

Normalmente, los desarrolladores de Java utilizan el lenguaje de programación Java y las API para implementar aplicaciones web para JVM. Gracias al uso de intérpretes o de compiladores compatibles con JVM, también puedes utilizar otros lenguajes para desarrollar aplicaciones web como, por ejemplo, JavaScript, Ruby o Scala.

Para obtener más información sobre el entorno de tiempo de ejecución Java, consulta la sección El entorno de tiempo de ejecución Java.

El entorno de tiempo de ejecución Python


Gracias al entorno de tiempo de ejecución Python, puedes implementar tu aplicación a través del lenguaje de programación Python y ejecutarla en un intérprete de Python optimizado. App Engine incluye varias API y herramientas para el desarrollo de aplicaciones web de Python, así como un API de modelado de datos detallados, un framework de aplicaciones web fácil de utilizar y herramientas para administrar y acceder a tus datos de la aplicación. También puedes beneficiarte de una amplia variedad de frameworks y bibliotecas avanzados para el desarrollo de aplicaciones web de Python, como por ejemplo Django.

El entorno de tiempo de ejecución Python utiliza la versión 2.5.2. de Python. Estamos teniendo en cuenta una compatibilidad adicional con Python 3 para futuras versiones.

El entorno Python incluye la biblioteca estándar de Python. Por supuesto, no todas las funciones de biblioteca se pueden ejecutar en el entorno de la zona de pruebas. Por ejemplo, una llamada a un método que intenta abrir un conector o escribir en un archivo generará una excepción. Para comodidad del usuario, se han inhabilitado varios módulos de la biblioteca estándar cuyas funciones son incompatibles con el entorno de tiempo de ejecución y el código que los importe generará un error.

El código de aplicación escrito para el entorno Python se debe escribir exclusivamente en Python. Las extensiones escritas en lenguaje C no son compatibles.

El entorno Python proporciona varias API Python para servicios de almacén de datos, cuentas de Google, extracción de URL y correo electrónico. App Engine también ofrece un sencillo framework para aplicaciones web Python denominado webapp que te permitirá empezar a crear aplicaciones fácilmente.

Puedes subir otras bibliotecas de terceros con tu aplicación, siempre que estén implementadas únicamente en Python y no requieran ningún módulo incompatible de la biblioteca estándar.

Para obtener más información sobre el entorno de tiempo de ejecución Python, consulta la sección El entorno de tiempo de ejecución Python.

El almacén de datos


App Engine proporciona un potente servicio de almacenamiento de datos distribuido que incluye un motor de búsqueda y transacciones. A medida que el servidor web distribuido crece con el tráfico, el almacén de datos distribuido crece con los datos.

El almacén de datos de App Engine no es como una base de datos relacional tradicional. Los objetos de datos, o "entidades", disponen de un tipo y un conjunto de propiedades. Las consultas pueden recuperar entidades de un tipo determinado filtradas y ordenadas según los valores de las propiedades. Los valores de las propiedades pueden ser de cualquiera de los tipos de valores de propiedades admitidos.

Las entidades del almacén de datos son carecen de esquema. Tu código de aplicación se encarga de proporcionar y de respetar la estructura de las entidades de datos. Las interfaces JDO/JPA de Java y la interfaz del almacén de datos de Python incluyen características para aplicar y respetar la estructura de tu aplicación. Tu aplicación también puede acceder al almacén de datos de forma directa para aplicar mucho o poco la estructura que necesite.

El almacén de datos es muy consistente y utiliza el control de concurrencia optimista. Una entidad se actualizará si se intenta realizar una transacción un número determinado de veces y otros procesos están intentando actualizar la misma entidad al mismo tiempo. Tu aplicación puede ejecutar varias operaciones de almacén de datos en una única transacción, que se ejecutarán con o sin éxito, garantizando así la integridad de tus datos.

El almacén de datos implementa transacciones en su red distribuida mediante "grupos de entidades". Una transacción manipula entidades de un único grupo. Las entidades del mismo grupo se almacenan juntas para ejecutar las transacciones eficazmente. Tu aplicación puede asignar entidades a grupos al crear las entidades.

Cuentas de Google


App Engine admite la integración de una aplicación con Cuentas de Google para la autenticación de los usuarios. Tu aplicación puede permitir a un usuario acceder con una cuenta de Google y tener acceso a la dirección de correo electrónico y el nombre de visualización asociados a la cuenta. Las cuentas de Google permiten que el usuario pueda empezar a utilizar la aplicación de una forma más rápida, ya que no tiene que crear una cuenta nueva. También te ahorran el esfuerzo de implementar un sistema de cuentas de usuario sólo para tu aplicación.

Si estás ejecutando tu aplicación con Google Apps, podrás utilizar las mismas funciones con los miembros de tu organización y las cuentas de Google Apps.

El API de usuarios también puede indicar a la aplicación si el usuario actual es un administrador registrado de la aplicación. Esto facilitará la implementación de áreas exclusivas de administradores en tu sitio.

Para obtener más información sobre la integración con las cuentas de Google, consulta la referencia del API de usuarios.

Servicios de App Engine


App Engine proporciona una gran variedad de servicios que te permitirán realizar operaciones comunes al gestionar tu aplicación. Se incluyen las siguientes API para acceder a estos servicios:

Extracción de URL
Las aplicaciones pueden acceder a recursos en Internet, como servicios web u otros datos, mediante el servicio de extracción de URL de App Engine. El servicio de extracción de URL recupera recursos web mediante la misma infraestructura de alta velocidad de Google que recupera páginas web para muchos otros productos de Google.

Correo
Las aplicaciones pueden enviar mensajes de correo electrónico mediante el servicio de correo de App Engine. El servicio de correo utiliza la infraestructura de Google para enviar mensajes de correo electrónico.

Memcache
El servicio Memcache proporciona a tu aplicación el servicio de memoria caché de valores-claves de alto rendimiento accesible desde varias instancias de tu aplicación. Memcache resulta útil para los datos que no necesitan las funciones de persistencia y transacciones del almacén de datos, como los datos temporales o los datos copiados del almacén de datos en la caché para un acceso a gran velocidad.

Manipulación de imágenes
El servicio de imágenes permite a tu aplicación manipular imágenes. Con esta API, podrás recortar, rotar o ajustar el tamaño de imágenes en formato JPEG o PNG.

Tareas programadas
El servicio Cron te permite programar tareas que se van a ejecutar en intervalos regulares. Para obtener más información, consulta la documentación sobre el servicio Cron de Python o de Java.

Flujo de Trabajo de Desarrollo


Los kits de desarrollo de software de App Engine (SDK) para Java y Python incluyen una aplicación de servidor web que emula todos los servicios de App Engine de tu equipo local. Cada SDK incluye todas las API y bibliotecas disponibles en App Engine. El servidor web también simula el entorno seguro de la zona de pruebas, incluyendo las verificaciones con respecto a los intentos de acceso a los recursos del sistema inhabilitados en el entorno de tiempo de ejecución de App Engine.

Cada SDK también incluye una herramienta para subir tu aplicación a App Engine. Una vez que hayas creado el código de tu aplicación, los archivos estáticos y los archivos de configuración, ejecuta la herramienta para subir los datos. La herramienta te pedirá que introduzcas tu dirección de correo electrónico y contraseña de Google.

Cuando crees una nueva compilación importante de una aplicación que ya se esté ejecutando en App Engine, podrás subirla como una nueva versión. La antigua versión seguirá disponible para los usuarios hasta que cambies a la nueva versión. Puedes probar la nueva versión en App Engine mientras aún se esté ejecutando la antigua.

El SDK Java se ejecuta en cualquier plataforma con Java 5 o Java 6. El SDK está disponible en forma de archivo Zip. Si utilizas el entorno de desarrollo Eclipse, puedes utilizar el complemento de Google para Eclipse para crear, probar y subir aplicaciones de App Engine. El SDK también incluye herramientas de línea de comandos para ejecutar el servidor de desarrollo y subir tu aplicación.

El SDK Python se implementa exclusivamente en Python y se ejecuta en cualquier plataforma que disponga de Python 2.5, como Windows, Mac OS X y Linux. El SDK está disponible en forma de archivo Zip y los instaladores están disponibles para Windows y Mac OS X.

La consola de administración es una interfaz basada en web que permite administrar las aplicaciones que ejecutas en App Engine. Puedes utilizarla para crear nuevas aplicaciones, configurar nombres de dominio, cambiar la versión disponible de tu aplicación, examinar los registros de error y acceso y buscar el almacén de datos de una aplicación.

Cuotas y Límites


Crear una aplicación en App Engine no sólo resulta fácil. ¡Además es gratis! Puedes crear una cuenta y publicar una aplicación que la gente podrá utilizar inmediatamente sin ningún coste ni obligación. Una aplicación de una cuenta gratuita dispone de hasta 500 MB de espacio y admite hasta 5 millones de visitas mensuales. Cuando lo desees, puedes habilitar la facturación, establecer un presupuesto diario máximo y asignar tu presupuesto para cada recurso de acuerdo con tus necesidades.

Puedes registrar hasta 10 aplicaciones por cuenta de desarrollador.

Cada aplicación asigna recursos dentro de límites o "cuotas". Una cuota determina la cantidad que una aplicación puede utilizar un recurso concreto durante un día del calendario. En un futuro próximo, podrás ajustar alguna de estas cuotas mediante la adquisición de recursos adicionales.

Algunas funciones imponen límites no relacionados con cuotas para proteger la estabilidad del sistema. Por ejemplo, cuando una aplicación se ejecuta para atender una solicitud web, debe emitir una respuesta en 30 segundos. Si la aplicación tarda demasiado, se finaliza el proceso y el servidor devuelve un código de error al usuario. El tiempo de espera de la solicitud es dinámico y se puede reducir si un controlador de solicitudes consume el tiempo de espera con frecuencia para conservar recursos.

Otro ejemplo de un límite de servicio es el número de resultados devuelto por una consulta. Una consulta puede devolver como máximo 1.000 resultados. Las consultas que deberían devolver más resultados sólo devuelven el máximo. En este caso, no es probable que una solicitud que realiza este tipo de consulta devuelva una solicitud antes de agotar el tiempo de espera, pero el límite se mantendrá para conservar los recursos del almacén de datos.

Los intentos de socavar o abusar de las cuotas, como utilizar aplicaciones en varias cuentas que trabajen conjuntamente, infringen las Condiciones del servicio y podrían ser motivo de la inhabilitación o el cierre de las cuentas.

Para ver una lista de cuotas y una explicación acerca del sistema de cuotas, incluyendo las cuotas que pueden verse incrementadas mediante la habilitación de la facturación, consulta la sección Cuotas.
sábado, 18 de diciembre de 2010

CLOUD COMPUTING - COMPUTACION EN NUBE

Definición de la IEEE:


Es un paradigma de computación nueva cuyo objetivo es proporcionar información fiable, personalizada, así como de calidad de servicio, garantizada en entornos informáticos dinámicos para los usuarios finales.

Definición de NIST (National Institute of Standarts and Tecnology -USA-)


Computación en nube es un modelo que permite un cómodo acceso, red bajo demanda, a un grupo compartido de recursos informáticos configurables por ejemplo, redes, servidores, almacenamiento, aplicaciones y servicios que pueden ser rápidamente proveídos y puestos con un mínimo de esfuerzo en gestión para proveer servicios de interacción.


Conceptos clave


Vale la pena resaltar la relación estrecha que existe con el término Xaas (cualquier cosa como servicio – anything as a service) donde existe un enfoque de relación más con servicios dispuestos en Internet que instalados locamente.
  • Bajo esta perspectiva vale la pena observar tres instancias en que podríamos dividir Xaas:

Software como servicio – Saas (Software as a Service ):


Forma de distribución de software en el cual se puede acceder de forma descentralizada desde cualquier lugar con unos requerimientos de instalación mínimos o inexistentes, casos claros en este aspecto son Google Apps y Zoho Apps enfocados a brindar herramientas ofimáticas y de gestión, o Aviary, enfocada a brindar programas de diseños gráfico y multimedia.

Infraestructura como servicio – Iaas (Infrastructure as a Service):


Modelo que se enfoca en la presentación de servicios remotos como almacenamiento, procesamiento, bases de datos y transferencia de datos. Servicios que pueden ser escalados en cualquier momento según las necesidades del cliente. Algunas de las empresas enfocadas a este modelo son Webservice de Amazon o Google Apps Marketplace entre otras.

Plataforma como servicio – Paas (Platform as a Service):


La plataforma como servicio se enfoca principalmente a grupos de desarrolladores donde una empresa brinda un ambiente tecnológico específico para desarrollar sus proyectos, despreocupándose en buena medida por los aspectos de hardware y software a nivel de sistemas operativo y configuraciones básicas. Este modelo es conocido como virtualización de servidores. Entre los casos más representativos se encuentra Google App Engine Zoho Creator y recientemente Windows Azure
  • En la nube se pueden tener tres tipos de “tipologías” que pueden ser identificadas según el tipo de acceso, tipo de usuarios y contratación, estas pueden alojar los conceptos anteriormente descritos, entre las tipologías de nube se tiene:
Nubes públicas: Estas son uno de los casos más comunes al momento de hacer uso de la computación en nube, aquí intervienen terceros que brindan servicios de Saas, Iass y Pass a los usuarios. Estas pueden tener un modelo gratuito, en algunas oportunidades, o pagado en otras, todo dependiendo del servicio que se brinde. Uno de los casos más comunes en el uso de Saas en esta “tipología” consiste en el sistema Google Apps para universidades y algunas otras instituciones educativas, en este caso Google brinda su plataforma de correo y una suite de ofimática de manera gratuita a estas instituciones. Sin embargo las condiciones del servicio cambian cuando la cantidad de correos permitidos y almacenamiento gratuito llega aún límite específico, teniendo que, después de esta instancia, la empresa debe pagar por la prestación del servicio de acuerdo a modelos de facturación en prepago.

Nubes privadas: Las nubes privadas son implementaciones propias de las empresas, en este caso, la misma empresa se encarga de la implementación tecnológica, los gastos de mantenimiento así como de la seguridad y disponibilidad de los datos. Sus funciones están enfocadas a un grupo de usuarios que requieran uno o más servicios. Con el fin de ejemplificar este tipo de nube, imaginemos que una institución universitaria ha realizado cierta inversión tecnológica para que el departamento de contabilidad haga uso de aplicativos de software sin tenerlos instalados en sus computadores (Saas). Por otro lado, en este tipo de nube, se podría brindar al departamento de admisiones de la institución una cantidad de procesamiento mayor al comúnmente usado en periodos de registro académico de estudiantes (Iaas). Otra aplicación de nube privada podría ser brindar un ambiente tecnológico en una aplicación específica para que los estudiantes de un curso de programación, por ejemplo, pudieran realizar sus ensayos en un ambiente real (Paas). En todos los anteriores casos la nube privada estaría solo dispuesta para el uso de los miembros de la institución.

Nubes híbridas: Se habla de nubes híbridas cuando un tercero brinda un servicio de apoyo a una empresa en algunos de sus modelos. Tomando el ejemplo de la institución universitaria, esta podría contratar un servicio Iaas de un tercero con el fin de brindar garantías de disponibilidad en el momento de la realización de exámenes en un momento definido.
Con el fin de mejorar la conceptualización que se esta realizando vale la pena resaltar los públicos a los que pudiera estar enfocado cada uno de los modelos de computación en la nube en el esquema Xaas:

Iaas: Éste modelo estaría más enfocado a empresas que desean soportar plataforma como servicio o software como servicio al interior de la misma.

Paas: Enfocada a equipo de desarrolladores o empresas con el fin de hacer uso de un ambiente tecnológico listo evitando implementaciones costosas del mismo.

Saas: Modelo enfocado en el usuario final, siendo en este caso todos los usuarios que requieren del uso de un software desde cualquier lugar.

Definición

.
Partiendo de las reflexiones generadas sobre diferentes aspectos de la computación en la Nube en la educación en la clase de Tecnologías Emergentes (2010), se llego a la siguiente definición:
Plataforma altamente escalable que elimina limitantes actuales a nivel de recursos de hardware y software, permitiendo el diseño de estrategias didácticas que utilizan recursos en Internet y que contribuyen a los procesos de enseñanza y aprendizaje por medio de herramientas de fácil manejo; La nube potencia la igualdad de acceso a recursos, fomenta el trabajo colaborativo y estimula la innovación por medio de robustas aplicaciones web fáciles de utilizar.

Realidades y Fortalezas


Una de las realidades dadas en los últimos tiempos es el uso común de computación en la nube por parte de las instituciones educativas en sus sistemas de correo electrónico y procesamiento de textos (Cantu, 2009), frente a este aspecto podemos resaltar casos como los de la Universidad Católica o la Universidad Central de Colombia que evidencian este hecho, donde los estudiantes poseen herramientas ofimáticas como Google Docs.
En otra instancia coincidiendo con las perspectivas de Martin y Hoover (2008), el crecimiento constante del mercado de la computación en nube permite a las instituciones educativas un modelo ideal para elegir proveedores que se ajusten a sus necesidades, de esta forma las instituciones no queda atadas a un solo proveedor, pues en la actualidad encontrando opciones como las ofrecidas por Amazon http://aws.amazon.com/, IBM https://www.ibm.com/developerworks/university/academicinitiative/ , Google /apps/intl/es/business/index.html, entre otras.
Casos como el de la Fundación Germán Sánchez (IBM, 2010), dejan claras las ventajas de la computación en la nube en la actualidad, donde se puede destacar el uso de plataformas desde cualquier dispositivo de computo, la eliminación de procedimientos técnicos por parte de los estudiantes y docentes gracias a la disponibilidad de la plataforma, así como propiciar el trabajo colaborativo de forma descentralizada por parte de los actores del proceso de enseñanza-aprendizaje.
Una de las fortalezas generada por la computación en la nube, se encuentra centrada a la democratización de acceso, en donde podemos resaltar que un joven en un lugar apartado del mundo con pocos recursos de hardware, puede contar con los mismos entornos computacionales de un joven de una universidad privilegiada (Anderson, 2010); solamente es necesaria una conexión a internet para hacer uso de este beneficio ayudando así a minimizar la brecha digital.
Se puede concluir en esta instancia, que la computación en la nube permite centrar a las instituciones educativas y a sus actores en los objetivos principales de su quehacer institucional, dando como resultado una mejora en los procesos de enseñanza y aprendizaje, trasladando así las preocupaciones técnicas y tecnológicas a personas expertas en el tema.

Debilidades


La responsabilidad sobre el fenómeno de la computación en la nube no ha sido estudiada de forma rigurosa por las instituciones educativas, desaprovechándose todas las potencialidades y usos novedosos que ofrece este concepto en el contexto educativo (Woolsey, 2008); teniendo en cuenta la anterior afirmación, es importante reflexionar acerca del desconocimiento del concepto por parte de los individuos que toman decisiones en las instituciones educativas y de cómo el omitir las ventajas y desventajas que brinda la computación en la nube, puede ir en detrimento de la mejora de los ambientes educativos y administrativos de las instituciones (Tecnologías emergentes, 2010).
viernes, 17 de diciembre de 2010

WEB SERVICES - SERVICIOS WEB

¿Qué son los Servicios Web?


Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su complejidad a la hora de dar una adecuada definición que englobe todo lo que son e implican. Una posible sería hablar de ellos como un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web.

¿Para qué sirven?


Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar.

¿Cómo funcionan?


El siguiente gráfico muestra cómo interactúa un conjunto de Servicios Web:



Según el ejemplo del gráfico, un usuario (que juega el papel de cliente dentro de los Servicios Web), a través de una aplicación, solicita información sobre un viaje que desea realizar haciendo una petición a una agencia de viajes que ofrece sus servicios a través de Internet. La agencia de viajes ofrecerá a su cliente (usuario) la información requerida. Para proporcionar al cliente la información que necesita, esta agencia de viajes solicita a su vez información a otros recursos (otros Servicios Web) en relación con el hotel y la compañía aérea. La agencia de viajes obtendrá información de estos recursos, lo que la convierte a su vez en cliente de esos otros Servicios Web que le van a proporcionar la información solicitada sobre el hotel y la línea aérea. Por último, el usuario realizará el pago del viaje a través de la agencia de viajes que servirá de intermediario entre el usuario y el servicio Web que gestionará el pago.

En todo este proceso intervienen una serie de tecnologías que hacen posible esta circulación de información. Por un lado, estaría SOAP (Protocolo Simple de Acceso a Objetos). Se trata de un protocolo basado en XML, que permite la interacción entre varios dispositivos y que tiene la capacidad de transmitir información compleja. Los datos pueden ser transmitidos a través de HTTP , SMTP , etc. SOAP especifica el formato de los mensajes. El mensaje SOAP está compuesto por un envelope (sobre), cuya estructura está formada por los siguientes elementos: header (cabecera) y body (cuerpo).


Para optimizar el rendimiento de las aplicaciones basadas en Servicios Web, se han desarrollado tecnologías complementarias a SOAP, que agilizan el envío de los mensajes (MTOM) y los recursos que se transmiten en esos mensajes (SOAP-RRSHB).

Por otro lado, WSDL (Lenguaje de Descripción de Servicios Web), permite que un servicio y un cliente establezcan un acuerdo en lo que se refiere a los detalles de transporte de mensajes y su contenido, a través de un documento procesable por dispositivos. WSDL representa una especie de contrato entre el proveedor y el que solicita. WSDL especifica la sintaxis y los mecanismos de intercambio de mensajes.

Durante la evolución de las necesidades de las aplicaciones basadas en Servicios Web de las grandes organizaciones, se han desarrollado mecanismos que permiten enriquecer las descripciones de las operaciones que realizan sus servicios mediante anotaciones semánticas y con directivas que definen el comportamiento. Esto permitiría encontrar los Servicios Web que mejor se adapten a los objetivos deseados. Además, ante la complejidad de los procesos de las grandes aplicaciones empresariales, existe una tecnología que permite una definición de estos procesos mediante la composición de varios Servicios Web individuales, lo que se conoce como coreografía.

Ejemplos


A continuación se muestra el código que se utilizaría para solicitar un viaje:

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
 <env:Header>
 <m:reserva xmlns:m="http://empresaviajes.ejemplo.org/reserva" 
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
      env:mustUnderstand="true">

   <m:referencia>
      uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d
   </m:referencia>
   <m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
  </m:reserva>
  <n:pasajero xmlns:n="http://miempresa.ejemplo.com/empleados"
      env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
      env:mustUnderstand="true">

   <n:nombre>Pepe Ejemplo</n:nombre>
  </n:pasajero>
 </env:Header>
<env:Body>
  <p:itinerario
    xmlns:p="http://empresaviajes.ejemplo.org/reserva/viaje">
   <p:ida>

     <p:salida>Nueva York</p:salida>
     <p:llegada>Los Angeles</p:llegada>
     <p:fechaSalida>2001-12-14</p:fechasalida>
     <p:horaSalida>última hora de la tarde</p:horaSalida>

     <p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
   </p:ida>
   <p:vuelta>
     <p:salida>Los Angeles</p:salida>
     <p:llegada>Nueva York</p:llegada>

     <p:fechaSalida>2001-12-20</p:fechaSalida>
     <p:horaSalida>media-mañana</p:horaSalida>
     <p:preferenciaAsiento/>
   </p:vuelta>
  </p:itinerario>

  <q:alojamiento
   xmlns:q="http://empresaviajes.example.org/reserva/hoteles">
   <q:preferencia>ninguna</q:preferencia>
  </q:alojamiento>
 </env:Body>
</env:Envelope>
INTRODUCCIÓN
 
Esta interesante metodología la planteó consultor suizo Alexander Osterwalder.
La metodología de innovación y diseño incluye un Lienzo (Canvas) con 9 elementos que parten de determinar la Oferta de valor frente a la Segmentación de clientes de la empresa u organización. De ahí se clarifican los Canales de distribución y la Relaciones. Todos estos determinan los Beneficios e ingresos. Enseguida se especifican los Recursos y las Actividades esenciales, que determinan los Costos más importantes. Finalmente se determinan las Alianzas necesarias para operar.
La propuesta de trabajo es muy dinámica, con el trabajo de grupos interdisciplinarios que combinan habilidades analíticas con pensamiento creativo a lo que Osterwalder llama Pensamiento de diseño. Se insta a los grupos a trabajar frente al lienzo pegado en la pared al tiempo que se representan en post-its las ideas con dibujos y un mínimo de palabras. 
La metodología se puede utilizar lo mismo para diseñar un nuevo negocio o una nueva línea de negocio dentro de una empresa u organización que para mejorar o hacer evolucionar un modelo de negocio en operación.

LOS 9 BLOQUES DEL CANVAS

1.  Segmento de clientes: El objetivo es de agrupar a nuestros clientes con características homogéneas en segmentos definidos y describir sus necesidades, averiguar información geográfica y demográfica, gustos, etc. Después, nos ocuparemos de ubicar a  los clientes actuales en  los diferentes segmentos para finalmente tener alguna estadística y crecimiento potencial de cada grupo.  


2.  Propuesta  de  Valor:  El  objetivo  es  de  definir  el  valor  creado  para  cada Segmento  de clientes describiendo  los productos y  servicios que  se ofrecen a  cada uno. Para  cada propuesta de valor hay que añadir el producto o servicio más importante y el nivel de servicio. Estas primeras dos partes son el núclue del modelo de negocio


3. Canales de Distribución: Para cada producto o servicio que hemos identificado en el paso anterior hay que definir el canal de su distribución adecuado, añadiendo como información el ratio de éxito del canal y la eficiencia de su costo.


4.  Relaciones con clientes: Aquí  identificamos cuáles recursos de tiempo y monetarios utilizamos para mantenernos  en  contacto  con nuestros  clientes. Por  lo  general,  si un producto o  servicio  tiene un costo alto entonces los clientes esperan tener una relación más cercana con nuestra empresa.

5.  Flujos  de  ingresos:  Este  paso  tiene  como  objetivo  identificar  que  aportación monetaria  hace  cada grupo,  y  además  de  donde  vienen  las  entradas  (ventas,  comisiones,  licencias,  etc.).  Así  podremos tener una visión global de cuáles grupos son más rentables y cuáles no.

6.  Recursos  claves:  Después  de  haber  trabajado  con  los  clientes,  tenemos  que  centrarnos  en  la empresa, para ello debemos utilizar los datos obtenidos anteriormente, seleccionamos  la propuesta de valor más importante y la relacionamos con el segmento de clientes, los canales de distribución, las relaciones  con  los  clientes, y  los  flujos de  ingreso para  saber  cuáles  son  los  recursos  clave que intervienen  para  que  la  empresa  tenga  la  capacidad  de  entregar  su  oferta  o  propuesta  de  valor.
Repetimos esta operación para cada propuesta de valor.

7.  Actividades  claves: Utilizando  la propuesta  de  valor más  importante,  los canales  de  distribución y las relaciones  con  los  clientes,  definimos  las  actividades  necesarias  para  entregar  nuestra  oferta. 

Repetimos esta operación para cada propuesta de valor. 


8.  Red  de  Asociados:  En  este  apartado  describimos  a  nuestros  proveedores,  socios,  y  asociados  con quienes  trabajamos  para  que  la  empresa  funcione.  ¿Qué  tan  importantes  son?  ¿Podemos reemplazarlos? ¿Se pueden convertir en competidores?

9.  Costo  de  la  estructura:  Aquí  especificamos  los  costos  de  la  empresa  empezando  con  el más  alto (marketing, R&D, CRM, producción, etc.). Luego  relacionamos cada costo con  los bloques definidos anteriormente, evitando generar demasiada complejidad. Posiblemente,  intentamos seguir el rastro de cada costo en relación con cada segmento de cliente para analizar las ganancias.
 

 
La siguiente presentación muestra de manera más didáctica lo que Alexander Osterwalder nos plantea:

miércoles, 1 de diciembre de 2010

DEL COMERCIO ELECTRONICO AL E-BUSINESS

Introducción
Las empresas visionarias de hoy en día están estableciendo nuevas reglas en sus industrias a través de nuevos modelos de negocios que aprovechan la tecnología, nuevos procesos interempresariales y operaciones integradas para enfrentar las cambiantes necesidades del cliente. Dichas empresas se han dado cuenta de que la siguiente ola de innovación enfocada al cliente requiere de una integración de procesos, aplicaciones y sistemas a una escala sin precedentes y en todas las áreas del negocio. a esta integración la llamamos e-business.

Diferencia entre el Comercio Electrónico y el E-Business
Definimos al comercio electrónico como comprar y vender a través de medios digitales. El e-business, además de abarcar al comercio electrónico, incluye las aplicaciones de usuario y servidor que constituyen el motor de los negocios modernos. El e-business no se trata sólo de transacciones de comercio electrónico; implica ademas la redefinición de los viejos modelos de negocios, con ayuda de la tecnología, para maximizar el valor del cliente. El e-business es la estrategia global y el comercio electrónico es una faceta muy importante del e-business. El E-Commerce es el subconjunto de E-Business. El e-busineess conecta los sistemas críticos de negocio directamente a los clientes, empleados, proveedores y socios comerciales, utilizando Intranets, Extranets, las tecnologías de comercio electrónico, aplicaciones de colaborativas,y la Web.
 
Reglas del E-Business
Regla 1:
LA TECNOLOGIA YA NO ES UN ELEMENTO ADICIONAL EN LA CREACION DE LA ESTRATEGIA DE NEGOCIOS, SINO UNA CAUSA E IMPULSO MISMOS.
Desde la aparición de la computación, el comercio electrónico representa el reto más significativo para el modelo de negocios. Si bien la computadora automatiza las tareas e incrementa la velocidad de los negocios, no ha alterado, en lo fundamental, las bases de éstos; el comercio electrónico sí lo ha hecho. Si cualquier entidad de la cadena de valor empieza a hacer negocios electrónicamente, las demás compañías que formen parte de esa cadena de valor deben seguir la misma tendencia, o corren el riesgo de ser desplazadas. Por lo tanto, replantear y rediseñar el modelo de negocios no es una de las muchas opciones que se presentan a los directivos de una empresa: es el primer paso para prosperar, e incluso sobrevivir; en la era de la información.
El primer paso para ver de una manera diferente es comprender que el e-business tiene que ver con una transformación estructural. Tenemos que tener en cuenta que el valor no se encuentra en los activos intangibles, como los productos, sino en los intangibles, como la marca, la relación con el cliente, la integración de la cadena de abastecimiento y la adición de activos de información claves.

Regla 2:
LA CAPACIDAD DE OPTIMIZAR LA ESTRUCTURA Y CONTROLAR EL FLUJO DE INFORMACION ES MUCHO MAS IMPORTANTE Y REDITUABLE QUE EL DESPLAZAMIENTO Y MANUFACTURA DE PRODUCTOS FISICOS.
Esta regla representa el principal motor de la transformación estructural. El mayor reto que enfrentan las compañias en la actualidad es ajustarse al cambio incesante para sostener el crecimiento. El cambio constante significa que las empresas deben asumir una sana inconformidad respecto al estado de las cosas, desarrollar la capacidad de detectar tendencias emergentes antes que la competencia, tomar decisiones con rapidez y ser lo seficientemente ágiles para crear nuevos modelos de negocios. En otras palabras, para prosperar, las compañías necesitan prevalecer en un estado de transformación constante.
Regla 3:
LA INCAPACIDAD DE DESHACERSE DE UN MODELO DE NEGOCIOS DOMINANTE Y OBSOLETO, PROVOCA CON FRECUENCIA EL FRACASO EN LOS NEGOCIOS.
Hoy en día, se sabe que la supervivencia de una compañía depende de su capacidad de anticipar, medir y dar prontas respuesta a las demandas cambiantes del cliente. Muchas empresas han buscado refugio en la subcontratacion(outsourcing) para poder manejar el cambio dinámico. La subcontratación está cambiando la naturaleza de la realación y los fabricantes de equipo original (OEM). En el pasado actuaban por separado, pero en la actualidad están más relacionados. ¿Por qué? Si el objetivo es complacer a los clientes, la mejor relación para ambas partes es comportarse como una compañía solida, única e integrada.
Los nuevos participantes del e-business utilizan frecuentemente las alianzas de subcontratación como un modelo de negocios para posicionarse en el mercado al competir contra un líder. A esta estrategia suele llamársele GBF(get big fast o crecer con rapidez). Esta nueva generación de alianzas de subcontratación recibe diversos nombres, entre ellos: comunidades, agrupaciones y coaliciones de e-business. 
Si bien las estrategias exitosas difieren ampliamente entre las distintas industrias, todas tienen algo en común: buscan anular las ventajas del líder, a través de la subcontratación, y crear rápidamente un prestigio, que es la tener economías de escala, un aprendizaje acumulativo y acceso preferencial a proveedores o canales.
Regla 4:
LA META DE LOS NUEVOS MODELOS DE NEGOCIOS ES CREAR ALIANZAS FLEXIBLES DE SUBCONTRATACION ENTRE LAS COMPAÑIAS, NO SOLO PARA REDUCIR LOS COSTOS, SINO TAMBIEN PARA QUE LOS CLIENTES QUEDEN COMPLETAMENTE SATISFECHOS.
Esta tendencia vuelve muy vulnerables a todos los líderes del mercado, en especial a los distribuidores, quienes estan en riesgo, porque los nuevos intermediarios en línea son capaces de duplicar su modelo de negocios a un costo muy bajo. Los acuerdos complejos de subcontratación ya no son opcionales: representan la única vía por la cual las compañías pueden obtener mayores beneficios. En la actualidad las empresas estan implementando nuevos modelos de negocios: desintegración y reintegración.
La desintegración permite a las compañías separar los medios(productos) del fin(las necesidades del cliente).
La reintegración permite a los negocios crear un esquema que optimice la cadena de valor en su totalidad. El objetivo de la reintegración es reducir los costos o resaltar la diferencia
Pasos de la desintegración y la reintegración:
  1. Cuestionar las definiciones tradicionales de valor. Los cliente quieren que las compañías con las que hacen negocios mejoren continuamente en la rapidez, la comodidad, la personalización y el precio.
  2. Definir el valor en términos de la experiencia total del cliente.Las empresas necesitan innovar la experiencia total del cliente. La capacidad de optimizar la experiencia de principio a fin representa una solución completa y coloca a las compañías visionarias en una categoria aparte.
  3. Establecer un corriente de valor de principio a fin. Para crear el futuro, una compañía debe ser capaz de establecer la corriente de valor completa, de principio a fin, concepto que no es totalmente nuevo. Los directivos con experiencia saben cómo redefinir los modelos y procesos de negocios cuando implementan nuevas formas de valor. Lo que es diferente en este nuevo ambiente es el uso extenso de agrupaciones sinérgicas, ecosistemas de negocios, coaliciones, redes de cooperacion o esquemas de subcontratación para crear corrientes de valo de principio a fin. Las comunidades de e-business (EBCs), como se conoce a estas redes de relaciones, enlazan negocios, clientes y proveedores para crear una entidad de negocios única.
  4. Integrar procesos de principio a fin. Crear las bases de una nueva tecno-empresa enfocada al cliente. Generar la integración de procesos de principio a fin no es tan fácil como parece. Esta integración demanda un reajuste de las aplicaciones para desarrollar una infraestructura integrada de servicios de apoyo qe permita a los procesos fluir libremente.
Regla 5:
EL COMERCIO ELECTRONICO PERMITE A LAS COMPAÑIAS ESCUCHAR A SUS CLIENTES Y CONVERTIRSE EN "EL MAS BARATO", "EL MAS CONOCIDO" O "EL MEJOR".
Ser "el más barato" no es sinónimo de ser inferior. Se refiere a un formato enfocado a ofrecer un buen precio, para lo cual se han eliminado muchos de lo costos de inventario y distribución.
Con "el más conocido", los clientes saben lo que obtienen. Coca-cola es un gran ejemplo de una marca conocida.  
Se "el mejor" implica renovar los procesos de servicio de manera constante, transformar una compañía facilmente y establecer relaciones amistosas con los clientes y proveedores. 
 

Regla 6:
NO UTILICE LA TECNOLOGIA SOLO PARA CREAR EL PRODUCTO. UTILICELA PARA INNOVAR, AMENIZAR Y MEJORAR LA EXPERIENCIA TOTAL DEL PRODUCTO, DESDE LA SELECCION Y EL PEDIDO HASTA LA ENTREGA Y EL SERVICIO.
Amazon.com ha emprendido iniciativas revolucionarias en la experiencia del cliente a través de su itnerfaz de usuario. El diseño y los vínculo de Amazon.com son lógicos, intuitivos y, sobre todo, amenos.
A medida que el ambiente de los negocios adquiere características electrónicas, las compañías deberían pensar como Amazon.com, en el sentido de enfocarse más a las experiencias y expectativas del cliente. Proporcionar una experiencia satisfactoria tanto en la interfaz como en los servicios de apoyo es una capacidad difícil de desarrollar en el e-business.

Regla 7:
EL MODELO DE NEGOCIOS DEL FUTURO SE BASA CADA VEZ MAS EN MODELOS RECONFIGURABLES DE COMUNIDADES DE E-BUSINESS PARA SATISFACER MEJOR LAS NECESIDADES DEL CLIENTE
Por ejemplo, Amazon.com, CarPoint de Microsoft, E*TRADE y otras compañías nuevas de comercio electrónico sin esencialmente EBCs complejas, conformadas con el propósito exclusivo de organizar y fortalecer relaciones entre empresas para crear un valor de principio a fin par el consumidor. La competencia ya no se da entre compañías, sino en tre EBCs.



Regla 8:
LA DIFICIL TAREA QUE TIENE LA GERENCIA ES CONJUNTAR LAS ESTRATEGIAS, LOS PROCESOS Y LAS APLICACIONES DE NEGOCIOS RAPIDA, CORRECTA Y SIMULTANEAMENTE. ES INDISPENSABLE TENER UN LIDERAZGO FUERTE.
Como la flexibilidad en los negocios es lo que marca el rumbo de la evolución del e-business, uno de los mayores retos para un líder es comprender de manera clara cómo funcionan los canales de distribución de productos y servicios. Los líderes tambien deben comprender que el concepto de e-business abarca el modelo de negocios de una compañía en su totalidad.
jueves, 23 de septiembre de 2010

PARALLEL SYSPLEX

1. ¿Qué es Sysplex?
Sysplex es un conjunto de sistemas z/OS que cooperan, usando ciertos productos de hardware y software, para
procesar la carga de trabajo. Sus características estan ligadas a su potencia de crecimiento mejorada y también a su nivel de alta disponibilidad.


2. ¿Qué es Parallel Sysplex?
Es un clúster de mainframes que funcionan como un solo sistema, normalmente usando z/OS. Un Sysplex Paralelo combina compartición de datos (usando Copia Remota Punto a Punto) y computación paralela para compartir carga, rendimiento y alta disponibilidad en un cluster de hasta 32 computadores.

2.1. Características
  • Comparte datos entre múltiples sistemas.
  • Acceso directo concurrente de lectura/escritura a datos compartidos desde todos los nodos de procesamiento.
  • Esta tecnología no afecta la performance.
  • Se puede distribuir las transacciones y consultas para la ejecución en paralelo, basado en la capacidad disponible, y no restringido a un único nodo.
  • Capacidad de realizar balanceo de hardware y mantenimiento de software de una manera sin interrupciones; esto permite a las empresas poner en práctica la función crítica del negocio y reaccionar a un rápido crecimiento sin afectar a la disponibilidad de los clientes.  

2.2. Algunos ejemplos de un Clúster de Parallel Sysplex correctamente configurado:
  • A los componentes de hardware y software les proporcionan la concurrencia para facilitar el mantenimiento sin interrupciones, en zSeries la Capacity Upgrade on Demand permite la capacidad de transformación o el acoplamiento para ser añadidos, por un motor a la vez, sin interrumpir las cargas de trabajo del cliente.
  • En los subsistemas DASD que emplean las tecnologías de imagen de discos o RAID ayudan a proteger contra la pérdida de datos y aprovechar las tecnologías para permitir que se realizen las copias de seguridad en un punto en el tiempo, sin necesidad de aplicaciones de apagado.
  • En tecnologías de red que ofrecen funciones como VTAM ® Generic Resources, Sesiones Persistentes Multi-nodo, dirección virtual IP, y el distribuidor Sysplex proporcionan conexiones de red tolerante a fallos.
  • En subsistemas de I/O soportan múltiples rutas dinámicas de conmutación de I/O para evitar la pérdida de acceso a datos y el rendimiento mejorado.
  • En z/OS y OS/390, los componentes de software permiten a las nuevas versiones de software coexistir con menores niveles de ese componente de software para facilitar el mantenimiento del material rodante.
  • En las aplicaciones empresariales que son "la habilitación de compartimiento de datos" y el clonado a través de servidores permiten el equilibrio de carga de trabajo y evitan la pérdida de disponibilidad de las aplicaciones en el caso de un corte de luz.
  • Los procesos operacionales y de recuperación son totalmente automatizados y transparentes a los usuarios, esto reduce o elimina la necesidad de intervención humana.
     3. Beneficios:
    • Disponibilidad continua 
    • Capacidad 
    • Balanceo Dinámico de Carga de Trabajo
    • Facilidad de uso 
    • Única imagen de sistema 
    • Crecimiento sin interrupción 
    • Compatibilidad de aplicaciones
    3.1. Disponibilidad Continua
    • Dentro de un cluster de Parallel Sysplex, se puede  construir un ambiente sin un punto único de falla
    • Componente similar de un sistema pueden asumir responsabilidades de recupero por recursos tomados por el componente que falló.
    • Alternativamente, el subsistema que falla puede re-arrancarse automáticamente manteniendo la salud de todos los sistemas.
    • En un parallel sysplex es posible que la pérdida de un servidor sea transparente a la aplicación y que la carga  de éste sea distribuída automáticamente con mínima degradación de performance.
    • Cada sistema sigue siendo individual.
    • Las actualizaciones de software se pueden hacer de a un sistema por vez, de acuerdo con las necesidades del negocio
    3.2. Capacidad
    • El parallel sysplex es escalable desde 2 hasta 32 sistemas.
    • Puede ser una mezcla de servidores que soporten parallel sysplex.
    3.3 Balanceo Dinámico de Carga de Trabajo
    • El cluster de parallel sysplex se puede considerar como un único recurso lógico para los usuarios finales y las aplicaciones de negocio.
    • La carga de trabajo se puede distribuir dinámicamente a nodos con capacidad disponible.
    • Balanceo de carga además permite ejecución de diversas aplicaciones mientras se mantiene el tiempo de respuesta, elemento crítico en los negocios
    3.4. Fácil de Usar

    • z/OS Workload Manager
      – Administra la carga del Sysplex a una política
    • Sysplex Failure Manager 
    • – Especifica acciones de detección de fallas y su recuperación.
    • Automatic Restart Manager
    • – Rápida recuperación de subsistemas crítico.
    • Cloning and symbolics
    • – Usado para replicar aplicaciones a través de los nodo.
    3.5. Imagen de Sistema Único
    • El Sysplex debería aparecer como una única imagen al operador, usuario final, administrador de base
      de datos, Operaciones, System Programmers.
    • Unico punto de control.
    • Imagen única persistente a través de fallas.
    3.6. Crecimiento Sin Interrupción
    • Es un requisito que los cambios, tales como las nuevas aplicaciones, software o de hardware pueden ser introducidos sin interrupciones y que sean capaces de coexistir con los actuales niveles en el Parallel Sysplex.
    • En el soporte de cambios compatibles, los componentes de hardware y software de la solución Sysplex paralelo permitirá la coexistencia de dos niveles, es decir, nivel N y el nivel N +1. Esto significa, por ejemplo, que ningún producto de software de IBM hará un cambio que no puede ser tolerada por la versión anterior.

    3.7. Compatibilidad de Aplicaciones
    • Escalabilidad
    • Integración de aplicaciones viejas con nuevas cargas de trabajo, como servicios web.
    • Con un Sysplex existente, hay muy poco trabajo de infraestructura necesario para una nueva aplicación. La infraestructura existente puede incluso usarse sin la necesidad de un nuevo servidor
    4. Elementos
    Los elementos más importantes en un Sysplex Paralelo son:
    • Hardware de Coupling Facility para permitir a varios procesadores compartir, cachear, actualizar y balancear acceso de datos.
    • Un Sysplex Timer o un Protocolo de servidor de tiempo (STP por sus siglas en inglés) para sincronizar los relojes de todos los miembros
    • Cableado de calidad, redundante y de alta velocidad.
    • Software (sistema operativo y, normalmente, middleware como por ejemplo DB2 o IMS).


       
      martes, 20 de julio de 2010

      INTRODUCCION AL MAINFRAME

      Alcances
      - Un mainframe es un sistema de computación utilizado en negocios para almacenar bases de datos comerciales,
      servidores de transacciones y aplicaciones, que requieren un alto grado de seguridad y disponibilidad que comúnmente no se encuentra en máquinas de menor escala.
      - El poder de un mainframe provee velocidad y capacidad de computación, permitiéndole desarrollar grandes volúmenes de procesamiento.
      - El mainframe puede procesar grandes cantidades de tareas de diferentes tipos y en distintas zonas horarias.
      - La mayoría de las compañías de Fortune 1000 usan mainframes.
      – El 60% de la información disponible en Internet está almacenada en computadoras mainframe.

      ¿Por qué usar mainframes?
      – Procesamiento de transacciones a gran escala, por ejemplo miles de transacciones por segundo.
      – Soporta miles de usuarios y aplicaciones
      – Acceso simultáneo a los recursos
      – Terabytes de información en bases de datos
      – Comunicaciones de grandes anchos de banda.


      Arquitectura Evolutiva



      Características de los Sistemas Mainframe
      RAS (Confiabilidad, Disponibilidad, Servicio)
      En un Mainframe, los componentes de hardware y software son de alta calidad y tienen la capacidad de auto-diagnóstico y auto-reparación. Aunque alguno de sus componentes falle, un mainframe está el 99,9999% del tiempo disponible.
      Seguridad.
      Como sabemos Uno de los recursos más valiosos de una empresa son sus datos. Estos datos críticos deben ser
      administrados de forma segura y controlada, y que simultáneamente estén a disposición de usuarios autorizados. El mainframe proporciona un sistema muy seguro para el procesamiento de un gran número de aplicaciones heterogéneas en el acceso de datos críticos.
      Escalabilidad.
      Los Mainframes exhiben características de escalabilidad de hardware y software, con la capacidad de ejecutar múltiples copias del software del sistema operativo como una entidad única, a esto se le conoce como Sysplex.
      Control Centralizado.
      Manejo de Cargas de Trabajo.
      a)Procesamiento por lotes Batch: Son trabajos planificados, que se ejecutan sin la interacción del usuario.
      Pueden consistir en la ejecución de cientos o miles de Jobs encadenados, siguiendo una secuencia preestablecida. El tiempo de respuesta no es importante (pueden tardar horas en finalizar), ya que son tareas muy pesadas. Se suelen ejecutar por la noche, cuando la CPU está más libre de trabajo. Tienen grandes cantidades de datos (terabytes) tanto de entrada, como de salida para procesar o almacenar información. Ejemplos: copias de seguridad, balances de contabilidad, cierre de cuentas… etc.

      b)Procesamiento de transacciones Online: El OLPT (Online Transaction Processing), ocurre con la interacción del usuario. El tiempo de respuesta es muy importante, normalmente, es de menos de un segundo. Estas operaciones mueven pequeñas cantidades de datos, tanto de entrada como de salida. Las aplicaciones críticas de una empresa funcionan de este modo, por tanto, la interfaz transaccional para el usuario, debe de estar permanentemente disponible. Ejemplos: sacar dinero de un cajero, reservar un billete de avión, comprar con la tarjeta de crédito… etc.

      Particionado/Virtualización.
      Compatibilidad Continua.
      Arquitectura Evolutiva.
      Compatibilidad de Aplicaciones, complejidad, variedad.
      Potencia para miles de usuarios.

      Roles en el Mundo del Mainframe
      - Desarrollador de aplicaciones
      - Analista de Control de Producción
      - Operador
      - Programador de Sistema
      - Administrador de Sistema
      - Usuario Final...


      Sistemas Operativos Mainframe
      - z/OS
      - z/VM
      - VSE
      - Linux para zSeries
      - z/TPF

      z/OS
      o Es el SO más utilizado
      o El uso de espacios de direcciones en z / OS tiene muchas ventajas: Aislamiento de las áreas privadas en espacios de direcciones diferentes, proporcionadas para la seguridad del sistema, sin embargo, cada espacio de direcciones también proporciona un espacio común que es accesible a cada espacio de direcciones.
      o El sistema está diseñado para preservar la integridad de los datos, independientemente de cuán grande es la población de usuarios podría ser. z / OS impide a los usuarios de acceder o modificar cualquier objeto en el sistema, incluyendo los datos del usuario
      o El sistema está diseñado para administrar un gran número de trabajos por lotes concurrentes, sin necesidad de que el cliente gestione externamente el balance de la carga o la integridad problemas que de otro modo podrían producirse por el uso simultáneo y en conflicto de un determinado conjunto de datos.
      o El diseño de seguridad se extiende a las funciones del sistema, así como archivos simples. La seguridad puede ser incorporada en las aplicaciones, recursos y perfiles de usuario.
      o El sistema permite múltiples subsistemas de comunicaciones al mismo tiempo, permitiendo una flexibilidad inusual en el funcionamiento de diferentes aplicaciones de comunicaciones orientadas al mismo tiempo.
      o El sistema proporciona amplios niveles de recuperación de software. Las interfaces del sistema permiten a los programas de aplicación proporcionar sus propias capas de la recuperación.
      o El sistema está diseñado para manejar cargas de trabajo de forma rutinaria muy dispares, con equilibrio automático de los recursos para satisfacer las necesidades de producción establecidas por el administrador del sistema.

      z/VM
      o Es un sistema operativo orientado a la virtualización.
      o Tiene dos componentes básicos: un programa de control (PC), que es el encargado de crear las máquinas virtuales utilizando recursos reales del sistema. Y El segundo componente es el CMS (Conversational Monitor System), que proporciona la interfaz al usuario.

      z/VSE
      o Es utilizado para mainframes más pequeños. Algunos de estos clientes eventualmente migran a z / OS cuando crecen más allá de la capacidad de z / VSE.
      o Es similar a z/OS, pero más pequeño y menos complejo.
      o Está dirigido a todos los clientes que utilizan VSE/ESA
      o Es un sistema operativo centrado en la interoperatividad (intercambio de procesos y datos entre sistemas heterogéneos)
      1. Aplicaciones: La Interfaz Entre Redes

      1.1 Modelo OSI y Modelo TCP/IP
      El modelo de interconexión de sistemas abiertos es una representación abstracta en capas, creada como guía para el diseño del protocolo de red. El modelo OSI divide el proceso de networking en diferentes capas lógicas, cada una de las cuales tiene una funcionalidad única y a la cual se le asignan protocolos y servicios específicos.
      En este modelo, la información se pasa de una capa a otra, comenzando en la capa de aplicación en el host de transmisión, siguiendo por la jerarquía hacia la capa física y pasando por el canal de comunicaciones al host de destino, donde la información vuelve a la jerarquía y termina en la capa de aplicación.
      La capa de aplicación, la séptima capa, es la capa superior de los modelos OSI y TCP/IP. Es la capa que proporciona la interfaz entre las aplicaciones que utilizamos para comunicarnos y la red subyacente en la cual se transmiten los mensajes. Los protocolos de capa de aplicación se utilizan para intercambiar los datos entre los programas que se ejecutan en los hosts de origen y destino. Existen muchos protocolos de capa de aplicación y siempre se desarrollan protocolos nuevos.

      Aunque el grupo de protocolos TCP/IP se desarrolló antes de la definición del modelo OSI, la funcionalidad de los protocolos de la capa de aplicación de TCP/IP se adaptan aproximadamente a la estructura de las tres capas superiores del modelo OSI. Capas de aplicación, presentación y sesión.
      La mayoría de los protocolos de la capa de aplicación de TCP/IP se desarrollaron antes de la aparición de computadoras personales, interfaces del usuario gráficas y objetos multimedia. Como resultado, estos protocolos implementan muy poco de la funcionalidad que es especifica en las capas de presentación y sesión del modelo OSI.

      La Capa de Presentación
      La capa de presentación tiene tres funciones principales:

      - Codificación y conversión de datos de la capa de aplicación para garantizar que los datos del dispositivo de origen se puedan interpretar por la aplicación adecuada en el dispositivo de destino.
      - Compresión de los datos de forma que los pueda descomprimir el dispositivo de destino.
      - Encriptación de los datos para la transmisión y la encriptación de los mismos cuando lleguen a su destino.

      Generalmente, las implementaciones de la capa de presentación no están relacionadas con un stack de protocolos en particular. Los estándares para videos y gráficos son algunos ejemplos. Dentro de los estándares más conocidos para video encontramos QuickTime y el Grupo de expertos en películas (MPEG). QuickTime es una especificación de Apple Computer para audio y video, y MPEG es un estándar para la codificación y compresión de videos.
      Dentro de los formatos de imagen gráfica más conocidos encontramos el Formato de intercambio gráfico (GIF), Grupo de expertos en fotografía (JPEG) y Formato de archivo de imagen etiquetada (TIFF). GIF y JPEG son estándares de compresión y codificación para imágenes gráficas, y TIFF es un formato de codificación estándar para imágenes gráficas.

      La Capa de Sesión
      Como lo indica el nombre de la capa de sesión, las funciones en esta capa crean y mantienen diálogos entre las aplicaciones de origen y destino. La capa de sesión maneja el intercambio de información para iniciar los diálogos y mantenerlos activos, y para reiniciar sesiones que se interrumpieron o desactivaron durante un periodo de tiempo prolongado.
      La mayoría de las aplicaciones, como los exploradores Web o los clientes de correo electrónico, incorporan la funcionalidad de las Capas 5, 6 y 7 del modelo OSI.


      Los protocolos de capa de aplicación de TCP/IP más conocidos son aquéllos que proporcionan intercambio de la información del usuario. Estos protocolos especifican la información de control y formato necesaria para muchas de las funciones de comunicación de Internet más comunes. Algunos de los protocolos TCP/IP son:
      - El Protocolo servicio de nombres de dominio (DNS, Domain Name Service) se utiliza para resolver nombres de Internet para direcciones IP.
      - El Protocolo de transferencia de hipertexto (HTTP, Hypertext Transfer Protocol) se utiliza para transferir archivos que forman las páginas Web de la World Wide Web.
      - El Protocolo simple de transferencia de correo (SMTP) se utiliza para la transferencia de mensajes de correo y adjuntos.
      - Telnet, un protocolo de emulación de terminal, se utiliza para proporcionar acceso remoto a servidores y a dispositivos de red.
      - El Protocolo de transferencia de archivos (FTP) se utiliza para la transferencia de archivos interactiva entre sistemas.

      Los protocolos en la suite de TCP/IP los definen generalmente las Solicitudes de comentarios (RFC). El Grupo de trabajo de ingeniería de Internet mantiene las RFC como los estándares para la suite de TCP/IP.


      1.2 Software de la Capa de Aplicación
      Las funciones asociadas con los protocolos de la capa de aplicación permiten a la red humana comunicarse con la red de datos subyacente. Cuando abrimos un explorador Web o una ventana de mensajería instantánea se inicia una aplicación, y el programa se coloca en la memoria del dispositivo donde se ejecuta. Cada programa ejecutable cargado a un dispositivo se denomina proceso.
      Dentro de la capa de aplicación, existen dos formas de procesos o programas de software que proporcionan acceso a la red: aplicaciones y servicios.

      Aplicaciones Reconocidas por la Red
      Las aplicaciones son los programas de software que utiliza la gente para comunicarse a través de la red.. Algunas aplicaciones de usuario final son reconocidas por la red, lo cual significa que implementan los protocolos de la capa de aplicación y pueden comunicarse directamente con las capas inferiores del stack de protocolos. Los clientes de correo electrónico y los exploradores Web son ejemplos de este tipo de aplicaciones.

      Servicios de la Capa de Aplicación
      Otros programas pueden necesitar la ayuda de los servicios de la capa de aplicación para utilizar los recursos de la red, como transferencia de archivos o cola de impresión en la red. Aunque son transparentes para el usuario, estos servicios son los programas que se comunican con la red y preparan los datos para la transferencia. Diferentes tipos de datos, ya sea texto, gráfico o video, requieren de diversos servicios de red para asegurarse de que estén bien preparados para procesar las funciones de las capas inferiores del modelo OSI.
      Cada servicio de red o aplicación utiliza protocolos que definen los estándares y formatos de datos a utilizarse. Sin protocolos, la red de datos no tendría una manera común de formatear y direccionar los datos. Es necesario familiarizarse con los protocolos subyacentes que rigen la operación de los diferentes servicios de red para entender su función.

      1.3. Funciones del Protocolo de la Capa de Aplicación
      Los protocolos de la capa de aplicación los utilizan tanto los dispositivos de origen como de destino durante una sesión de comunicación. Los protocolos de la capa de aplicación que se implementaron en los hosts de origen y destino deben coincidir para que las comunicaciones tengan éxito.
      Los protocolos establecen reglas consistentes para el intercambio de datos entre aplicaciones y servicios cargados en los dispositivos participantes. Los protocolos especifican cómo se estructuran los datos dentro de los mensajes y los tipos de mensajes que se envían entre origen y destino. Estos mensajes pueden ser solicitudes de servicios, acuses de recibo, mensajes de datos, mensajes de estado o mensajes de error. Los protocolos también definen los diálogos de mensajes, asegurando que un mensaje enviado encuentre la respuesta esperada y se invoquen los servicios correspondientes cuando se realiza la transferencia de datos.
      Muchos tipos de aplicaciones diferentes se comunican a través de las redes de datos. Por lo tanto, los servicios de la capa de aplicación deben implementar protocolos múltiples para proporcionar la variedad deseada de experiencias de comunicación. Cada protocolo tiene un fin específico y contiene las características requeridas para cumplir con dicho propósito. Deben seguirse los detalles del protocolo correspondiente a cada capa, así las funciones en una capa se comunican correctamente con los servicios en la capa inferior.
      Las aplicaciones y los servicios también pueden utilizar protocolos múltiples durante el curso de una comunicación simple. Un protocolo puede especificar cómo se establece la conexión de redes y otro describir el proceso para la transferencia de datos cuando el mensaje se pasa a la siguiente capa inferior.

      Resumiendo:
      En general los protocolos de la capa de aplicación proporcionan las reglas para la comunicación entre las aplicaciones. Y son las siguientes:
      - Define los procesos en cada uno de los extremos de la comunicación.
      - Define los tipos de mensajes.
      - Define la sintaxis de los mensajes.
      - Define el significado de los campos de información.
      - Define la forma en que se envían los mensajes y la respuesta esperada.
      - Define la interacción con la próxima capa inferior.


      2. Toma de Medidas para las Aplicaciones y Servicios

      2.1. El Modelo Cliente-Servidor
      Cuando la gente intenta acceder a información en sus dispositivos, ya sean éstos una computadora personal o portátil, un PDA, un teléfono celular o cualquier otro dispositivo conectado a la red, los datos pueden no estar físicamente almacenados en sus dispositivos. Si así fuera, se debe solicitar permiso al dispositivo que contiene los datos para acceder a esa información.
      En el modelo cliente/servidor, el dispositivo que solicita información se denomina cliente y el dispositivo que responde a la solicitud se denomina servidor. Los procesos de cliente y servidor se consideran una parte de la capa de aplicación. El cliente comienza el intercambio solicitando los datos al servidor, quien responde enviando uno o más streams de datos al cliente. Los protocolos de la capa de aplicación describen el formato de las solicitudes y respuestas entre clientes y servidores. Además de la transferencia real de datos, este intercambio puede requerir de información adicional, como la autenticación del usuario y la identificación de un archivo de datos a transferir.
      Un ejemplo de una red cliente-servidor es un entorno corporativo donde los empleados utilizan un servidor de correo electrónico de la empresa para enviar, recibir y almacenar correos electrónicos. El cliente de correo electrónico en la computadora de un empleado emite una solicitud al servidor de correo electrónico para un mensaje no leído. El servidor responde enviando al cliente el correo electrónico solicitado.
      Aunque los datos se describen generalmente como el flujo del servidor al cliente, algunos datos fluyen siempre del cliente al servidor. El flujo de datos puede ser el mismo en ambas direcciones, o inclusive puede ser mayor en la dirección que va del cliente al servidor. Por ejemplo, un cliente puede transferir un archivo al servidor con fines de almacenamiento. La transferencia de datos de un cliente a un servidor se denomina cargar y de datos de un servidor a un cliente se conoce como descarga.

      2.2. Servidores
      En un contexto general de redes, cualquier dispositivo que responde a una solicitud de aplicaciones de cliente funciona como un servidor. Un servidor generalmente es una computadora que contiene información para ser compartida con muchos sistemas de cliente. Por ejemplo, páginas Web, documentos, bases de datos, imágenes, archivos de audio y video pueden almacenarse en un servidor y enviarse a los clientes que lo solicitan. En otros casos, como una impresora de red, el servidor de impresión envía al cliente solicitudes para la impresora que se especifica.
      Los diferentes tipos de aplicaciones de servidor pueden tener diferentes requisitos para el acceso del cliente. Algunos servidores pueden requerir de autenticación de la información de cuenta del usuario para verificar si el usuario tiene permiso para acceder a los datos solicitados o para utilizar una operación en particular. Dichos servidores deben contar con una lista central de cuentas de usuarios y autorizaciones, o permisos (para operaciones y acceso a datos) otorgados a cada usuario. Cuando se utiliza un cliente FTP, por ejemplo, si usted pide cargar datos al servidor FTP, se le puede dar permiso para escribir en su carpeta personal, pero no para leer otros archivos del sitio.
      En una red cliente-servidor, el servidor ejecuta un servicio o proceso, a veces denominado daemon. Al igual que la mayoría de los servicios, los demonios generalmente se ejecutan en segundo plano y no se encuentran bajo control directo del usuario. Los demonios se describen como servidores que "escuchan" una solicitud del cliente porque están programados para responder cada vez que el servidor recibe una solicitud para el servicio proporcionado por el demonio. Cuando un demonio "escucha" la solicitud de un cliente, intercambia los mensajes adecuados con el cliente, según lo requerido por su protocolo, y procede a enviar los datos solicitados en el formato correspondiente.

      2.3. Servicios y Protocolos de la Capa de Aplicación
      Una sola aplicación puede emplear diferentes servicios de la capa de aplicación, así lo que aparece para el usuario como una solicitud para una página Web puede, de hecho, equivaler a docenas de solicitudes individuales. Y, para cada solicitud, pueden ejecutarse múltiples procesos. Por ejemplo, un cliente puede necesitar de diversos procesos individuales para formular sólo una solicitud al servidor.
      Además, los servidores generalmente tienen múltiples clientes que solicitan información al mismo tiempo. Por ejemplo, un servidor Telnet puede tener varios clientes que requieren conectarse a él. Estas solicitudes individuales del cliente pueden manejarse en forma simultánea y separada para que la red sea exitosa. Los servicios y procesos de la capa de aplicación dependen del soporte de las funciones de la capa inferior para administrar en forma exitosa las múltiples conversaciones.

      2.4. Redes y Aplicaciones Punto a Punto (P2P)

      El modelo punto a punto
      Además del modelo cliente-servidor para networking, existe también un modelo punto a punto. Las redes punto a punto tienen dos formas distintivas: diseño de redes punto a punto y aplicaciones punto a punto (P2P). Ambas formas tienen características similares, pero en la práctica son muy diferentes.

      Redes punto a punto
      En una red punto a punto, dos o más computadoras están conectadas por medio de una red y pueden compartir recursos (como impresoras y archivos) sin tener un servidor dedicado. Cada dispositivo final conectado (conocido como punto) puede funcionar como un servidor o como un cliente. Una computadora puede asumir la función de servidor para una transacción mientras funciona en forma simultánea como cliente para otra transacción. Las funciones de cliente y servidor se establecen por solicitud.
      Una red doméstica sencilla con dos computadoras conectadas compartiendo una impresora es un ejemplo de una red punto a punto. Cada persona puede configurar su computadora para compartir archivos, habilitar juegos en red o compartir una conexión de Internet. Otro ejemplo sobre la funcionalidad de la red punto a punto son dos computadoras conectadas a una gran red que utilizan aplicaciones de software para compartir recursos entre ellas a través de la red.
      A diferencia del modelo cliente-servidor, que utiliza servidores dedicados, las redes punto a punto descentralizan los recursos en una red. En lugar de ubicar información para compartir en los servidores dedicados, la información puede colocarse en cualquier parte de un dispositivo conectado. La mayoría de los sistemas operativos actuales admiten compartir archivos e impresoras sin requerir software del servidor adicional. Debido a que las redes punto a punto generalmente no utilizan cuentas de usuarios centralizadas, permisos ni monitores, es difícil implementar las políticas de acceso y seguridad en las redes que contienen mayor cantidad de computadoras. Se deben establecer cuentas de usuario y derechos de acceso en forma individual para cada dispositivo.

      Aplicaciones Punto a Punto
      Una aplicación punto a punto (P2P), a diferencia de una red punto a punto, permite a un dispositivo actuar como cliente o como servidor dentro de la misma comunicación. En este modelo, cada cliente es un servidor y cada servidor es un cliente. Ambos pueden iniciar una comunicación y se consideran iguales en el proceso de comunicación. Sin embargo, las aplicaciones punto a punto requieren que cada dispositivo final proporcione una interfaz de usuario y ejecute un servicio en segundo plano. Cuando inicia una aplicación punto a punto específica, ésta invoca la interfaz de usuario requerida y los servicios en segundo plano. Después de eso, los dispositivos se pueden comunicar directamente.
      Algunas aplicaciones P2P utilizan un sistema híbrido donde se descentraliza el intercambio de recursos, pero los índices que apuntan a las ubicaciones de los recursos están almacenados en un directorio centralizado. En un sistema híbrido, cada punto accede a un servidor de índice para alcanzar la ubicación de un recurso almacenado en otro punto. El servidor de índice también puede ayudar a conectar dos puntos, pero una vez conectados, la comunicación se lleva a cabo entre los dos puntos sin comunicación adicional al servidor de índice.
      Las aplicaciones punto a punto pueden utilizarse en las redes punto a punto, en redes cliente-servidor y en Internet.

      3. Ejemplos de Servicios y Protocolos de la Capa de Aplicación

      3.1. Protocolos y Servicios DNS
      Ahora que tenemos una mejor comprensión de cómo las aplicaciones proporcionan una interfaz para el usuario y acceso a la red, veremos algunos protocolos específicos utilizados comúnmente.
      La capa de transporte utiliza un esquema de direccionamiento llamado número de puerto. Los números de puerto identifican las aplicaciones y los servicios de la capa de aplicación que son el origen y el destino de los datos. Los programas del servidor generalmente utilizan números de puerto predefinidos comúnmente conocidos por los clientes. Mientras examinamos los diferentes servicios y protocolos de la capa de aplicación de TCP/IP, nos referiremos a los números de puerto TCP y UDP normalmente asociados con estos servicios. Algunos de estos servicios son:
      - Sistema de nombres de dominios (DNS) - TCP/UDP puerto 53
      - Protocolo de transferencia de hipertexto (HTTP) - TCP puerto 80
      - Protocolo simple de transferencia de correo (SMTP) - TCP puerto 25
      - Protocolo de oficina de correos (POP) - TCP puerto 110
      - Telnet - TCP puerto 23
      - Protocolo de configuración dinámica de host - UDP puertos 67 y 68
      - Protocolo de transferencia de archivos (FTP) - TCP puertos 20 y 21

      DNS
      En las redes de datos, los dispositivos se etiquetan con una dirección IP numérica, de manera que pueden participar en el envío y la recepción de mensajes de la red. Sin embargo, la mayoría de las personas pasan mucho tiempo tratando de recordar estas direcciones numéricas. Por lo tanto, los nombres de dominios se crearon para convertir las direcciones numéricas en un nombre sencillo y reconocible.
      En Internet, estos nombres de dominio, tales como www.trujillosoft.com, son mucho más fáciles de recordar para la gente que algo como 198.133.219.25, el cual es la dirección numérica actual para ese servidor. Además, si Trujillosoft decide cambiar la dirección numérica, es transparente para el usuario, ya que el nombre de dominio seguirá siendo www.trujillosoft.com. La nueva dirección simplemente estará enlazada con el nombre de dominio existente y la conectividad se mantendrá. Cuando las redes eran pequeñas, resultaba fácil mantener la asignación entre los nombres de dominios y las direcciones que representaban. Sin embargo, a medida que las redes y el número de dispositivos comenzó a crecer, el sistema manual dejó de ser práctico.
      El Sistema de nombres de dominios (DNS) se creó para que el nombre del dominio busque soluciones para estas redes. DNS utiliza un conjunto distribuido de servidores para resolver los nombres asociados con estas direcciones numéricas.
      El protocolo DNS define un servicio automatizado que coincide con nombres de recursos que tienen la dirección de red numérica solicitada. Incluye las consultas sobre formato, las respuestas y los formatos de datos. Las comunicaciones del protocolo DNS utilizan un formato simple llamado mensaje. Este formato de mensaje se utiliza para todos los tipos de solicitudes de clientes y respuestas del servidor, mensajes de error y para la transferencia de información de registro de recursos entre servidores.
      DNS es un servicio cliente-servidor; sin embargo, difiere de los otros servicios cliente-servidor que estamos examinando. Mientras otros servicios utilizan un cliente que es una aplicación (como un explorador Web o un cliente de correo electrónico), el cliente DNS ejecuta un servicio por sí mismo. El cliente DNS, a veces denominado resolución DNS, admite la resolución de nombres para otras aplicaciones de red y servicios que lo necesiten.
      Al configurar un dispositivo de red, generalmente proporcionamos una o más direcciones del servidor DNS que el cliente DNS puede utilizar para la resolución de nombres. En general, el proveedor de servicios de Internet provee las direcciones para utilizar con los servidores DNS. Cuando la aplicación del usuario pide conectarse a un dispositivo remoto por nombre, el cliente DNS solicitante consulta uno de estos servidores de denominación para resolver el nombre para una dirección numérica.
      Los sistemas operativos computacionales también cuentan con una herramienta llamada nslookup que permite que el usuario consulte de forma manual los servidores de nombres para resolver un nombre de host dado. Esta utilidad también puede utilizarse para solucionar los problemas de resolución de nombres y verificar el estado actual de los servidores de nombres.
      Un servidor DNS proporciona la resolución de nombres utilizando el demonio de nombres que generalmente se llama named (se pronuncia name-dee).
      El servidor DNS almacena diferentes tipos de registros de recursos utilizados para resolver nombres. Estos registros contienen el nombre, la dirección y el tipo de registro.
      Algunos de estos tipos de registros son:

      - A: una dirección de dispositivo final
      - NS: un servidor de nombre autoritativo
      - CNAME: el nombre canónico (o Nombre de dominio completamente calificado) para un alias que se utiliza cuando varios servicios tienen una dirección de red única, pero cada servicio tiene su propia entrada en el DNS
      - MX: registro de intercambio de correos; asigna un nombre de dominio a una lista de servidores de intercambio de correos para ese dominio

      Cuando un cliente hace una consulta, el proceso "nombrado" del servidor busca primero en sus propios registros para ver si puede resolver el nombre. Si no puede resolverlo con sus registros almacenados, contacta a otros servidores para hacerlo.
      La solicitud puede pasar a lo largo de cierta cantidad de servidores, lo cual puede tomar más tiempo y consumir banda ancha. Una vez que se encuentra una coincidencia y se devuelve al servidor solicitante original, el servidor almacena temporalmente en la caché la dirección numerada que coincide con el nombre.
      Si vuelve a solicitarse ese mismo nombre, el primer servidor puede regresar la dirección utilizando el valor almacenado en el caché de nombres. El almacenamiento en caché reduce el tráfico de la red de datos de consultas DNS y las cargas de trabajo de los servidores más altos de la jerarquía. El servicio del cliente DNS en las PC de Windows optimiza el rendimiento de la resolución de nombres DNS almacenando previamente los nombres resueltos en la memoria. El comando ipconfig /displaydns muestra todas las entradas DNS en caché en un sistema informático con Windows XP o 2000.

      El sistema de nombres de dominios utiliza un sistema jerárquico para crear una base de datos y así proporcionar una resolución de nombres. La jerarquía es similar a un árbol invertido con la raíz en la parte superior y las ramas por debajo.
      En la parte superior de la jerarquía, los servidores raíz mantienen registros sobre cómo alcanzar los servidores de dominio de nivel superior, los cuales a su vez tienen registros que apuntan a los servidores de dominio de nivel secundario y así sucesivamente.
      Los diferentes dominios de primer nivel representan el tipo de organización o el país de origen. Entre los ejemplos de dominios del nivel superior se encuentran:

      .au: Australia
      .co: Colombia
      .com: una empresa o industria
      .jp: Japón
      .org: una organización sin fines de lucro

      Después de los dominios del nivel superior, se encuentran los nombres de los dominios de segundo nivel y debajo de estos hay otros dominios de nivel inferior.
      Cada nombre de dominio es una ruta hacia este árbol invertido que comienza de la raíz.
      El DNS depende de una jerarquía de servidores descentralizados para almacenar y mantener estos registros de recursos. Los registros de recursos enumeran nombres de dominios que el servidor puede resolver y servidores alternativos que también pueden procesar solicitudes. Si un servidor dado tiene registros de recursos que corresponden a su nivel en la jerarquía de dominios, se dice que es autoritativo para dichos registros.

      3.2. Servicio WWW y HTTP
      Cuando se escribe una dirección Web (o URL) en un explorador de Internet, el explorador establece una conexión con el servicio Web del servidor que utiliza el protocolo HTTP. URL (o Localizador Uniforme de Recursos) y URI (Identificador Uniforme de Recursos) son los nombres que la mayoría de las personas asocian con las direcciones Web.
      El URL http://www.trujillosoft.com/index.html es un ejemplo que se refiere a un recurso específico, una página Web llamada index.html en un servidor identificado como trujillosoft.com.
      Los exploradores Web son las aplicaciones cliente que utilizan nuestras computadoras para conectarse a la World Wide Web y acceder a recursos almacenados en un servidor Web. Al igual que con la mayoría de los procesos de servidores, el servidor Web funciona como un servicio básico y genera diferentes tipos de archivos disponibles.
      Para acceder al contenido, los clientes Web realizan conexiones al servidor y solicitan los recursos deseados. El servidor responde con el recurso y, al recibirlo, el explorador interpreta los datos y los presenta al usuario.
      Los buscadores pueden interpretar y presentar muchos tipos de datos, como texto sin cifrar o Lenguaje de marcas de hipertexto (HTML, el lenguaje en el que se crean las páginas Web). Otros tipos de datos, sin embargo, requieren de otro servicio o programa. Generalmente se les conoce como plug-ins o complementos. Para ayudar al explorador a determinar qué tipo de archivo está recibiendo, el servidor especifica qué clase de datos contiene el archivo.
      Para comprender mejor cómo interactúan el explorador Web y el cliente Web, podemos analizar cómo se abre una página Web en un explorador. Para este ejemplo, utilizaremos la dirección URL: http://www.trujillosoft.com/web-server.htm.
      Primero, el explorador interpreta las tres partes del URL:
      1. http (el protocolo o esquema)
      2. www.trujillosoft.com (el nombre del servidor)
      3. web-server.htm (el nombre de archivo específico solicitado).
      Después, el explorador verifica con un servidor de nombres para convertir a www.trujillosoft.com en una dirección numérica que utilizará para conectarse con el servidor. Al utilizar los requerimientos del protocolo HTTP, el explorador envía una solicitud GET al servidor y pide el archivo web-server.htm. El servidor, a su vez, envía al explorador el código HTML de esta página Web. Finalmente, el explorador descifra el código HTML y da formato a la página para la ventana del explorador.
      El protocolo de transferencia de hipertexto (HTTP), uno de los protocolos del grupo TCP/IP, se desarrolló en sus comienzos para publicar y recuperar las páginas HTML, y en la actualidad se utiliza para sistemas de información distribuidos y de colaboración. HTTP se utiliza a través de la World Wide Web para transferencia de datos y es uno de los protocolos de aplicación más utilizados.
      HTTP especifica un protocolo de solicitud/respuesta. Cuando un cliente, generalmente un explorador Web, envía un mensaje de solicitud a un servidor, el protocolo HTTP define los tipos de mensajes que el cliente utiliza para solicitar la página Web y envía los tipos de mensajes que el servidor utiliza para responder. Los tres tipos de mensajes comunes son GET, POST y PUT.
      GET es una solicitud de datos por parte del cliente. Un explorador Web envía el mensaje GET para solicitar las páginas desde un servidor Web.
      POST y PUT se utilizan para enviar mensajes que cargan datos en el servidor Web. Por ejemplo, cuando el usuario ingresa información en un formato incluido en una página Web, POST incluye la información en el mensaje enviado al servidor.
      PUT carga los recursos o el contenido en el servidor Web.
      Aunque es muy flexible, HTTP no es un protocolo seguro. Los mensajes POST cargan información al servidor en un texto sin formato que se puede interceptar y leer. De forma similar, las respuestas del servidor, generalmente páginas HTML, también se descifran.
      Para una comunicación segura a través de Internet, se utiliza el protocolo HTTP seguro (HTTPS) para acceder o subir información al servidor Web. HTTPS puede utilizar autenticación y encriptación para asegurar los datos cuando viajan entre el cliente y el servidor. HTTPS especifica reglas adicionales para pasar los datos entre la capa de aplicación y la capa de transporte.

      3.3. Servicios de Correo Electrónico y Protocolos SMTP/POP
      Correo electrónico, el servidor de red más conocido, ha revolucionado la manera en que nos comunicamos, por su simpleza y velocidad. Inclusive para ejecutarse en una computadora o en otro dispositivo, los correos electrónicos requieren de diversos servicios y aplicaciones. Dos ejemplos de protocolos de capa de aplicación son el Protocolo de oficina de correos (POP) y el Protocolo simple de transferencia de correo (SMTP), que aparecen en la figura. Como con el HTTP, estos protocolos definen los procesos de cliente-servidor.
      Cuando la gente redacta mensajes de correo electrónico, generalmente utilizan una aplicación llamada Agente de usuario de correo (MUA), o un cliente de correo electrónico. MUA permite enviar los mensajes y colocar los recibidos en el buzón del cliente; ambos procesos son diferentes.
      Para recibir correos electrónicos desde un servidor de correo, el cliente de correo electrónico puede utilizar un POP. Al enviar un correo electrónico desde un cliente o un servidor se utilizan formatos de mensajes y cadenas de comando definidas por el protocolo SMTP. En general, un cliente de correo electrónico proporciona la funcionalidad de ambos protocolos dentro de una aplicación.
      Los clientes envían correo electrónico a un servidor mediante SMTP y reciben correo electrónico mediante POP3.


      Procesos del Servidor de Correo Electrónico: MTA y MDA
      El servidor de correo electrónico utiliza dos procesos independientes:

      - Agente de transferencia de correo (MTA)
      - Agente de entrega de correo (MDA)

      El proceso Agente de transferencia de correo (MTA) se utiliza para enviar correo electrónico. Como se muestra en la figura, el MTA recibe mensajes desde el MUA u otro MTA en otro servidor de correo electrónico. Según el encabezado del mensaje, determina cómo debe reenviarse un mensaje para llegar al destino. Si el correo está dirigido a un usuario cuyo buzón está en el servidor local, el correo se pasa al MDA. Si el correo es para un usuario que no está en el servidor local, el MTA enruta el correo electrónico al MTA en el servidor correspondiente.
      El proceso de agente de transferencia de correo rige el manejo de correo electrónico entre servidores.


      En la siguiente figura, vemos que el Agente de entrega de correo (MDA) acepta una parte del correo electrónico desde un Agente de transferencia de correo (MTA) y realiza el envío real. El MDA recibe todo el correo entrante desde el MTA y lo coloca en los buzones de los usuarios correspondientes. El MDA también puede resolver temas de entrega final, como análisis de virus, correo no deseado filtrado y manejo de acuses de recibo. La mayoría de las comunicaciones de correo electrónico utilizan las aplicaciones MUA, MTA y MDA. Sin embargo, hay otras alternativas para el envío de correo electrónico.
      Un cliente puede estar conectado a un sistema de correo electrónico corporativo, como Lotus Notes de IBM, Groupwise de Novell o Exchange de Microsoft. Estos sistemas con frecuencia tienen su propio formato interno de correo electrónico, y sus clientes generalmente se comunican con el servidor de correo electrónico mediante un protocolo propietario. El servidor envía o recibe correo electrónico por medio de Internet a través del gateway de correo de Internet del producto, el cual realiza cualquier reformateo necesario.
      Como segunda alternativa, las computadoras que no tienen un MUA pueden conectarse a un servicio de correo en un explorador Web para así recuperar y enviar mensajes. Algunas computadoras pueden ejecutar su propio MTA y administrar correos electrónicos de dominio interno. Si, por ejemplo, dos personas que trabajan para la misma empresa intercambian correos electrónicos entre ellos utilizando un protocolo propietario, los mensajes pueden permanecer completamente dentro del sistema de correos corporativo de la empresa.
      El proceso de agente de entrega de correo rige la entrega de correo electrónico mediante servidores y clientes.


      Como se mencionó anteriormente, los correos electrónicos pueden utilizar los protocolos POP y SMTP (vea la figura para saber cómo funcionan). POP y POP3 (Protocolo de oficina de correos v.3) son protocolos de envío de correo entrante y protocolos cliente-servidor típicos. Envían correos electrónicos desde el servidor correspondiente al cliente (MUA). El MDA escucha cuando un cliente se conecta a un servidor. Una vez establecida la conexión, el servidor puede enviar el correo electrónico al cliente.
      El Protocolo simple de transferencia de correo (SMTP), por el contrario, rige la transferencia de correos salientes desde el cliente emisor al servidor de correos (MDA), así como también el transporte de correos entre servidores de correo electrónico (MTA). SMTP permite transportar correos por las redes de datos entre diferentes tipos de software de cliente y servidor, y hace posible el intercambio de correos en Internet.
      El formato de mensajes del protocolo SMTP utiliza un conjunto rígido de comandos y respuestas. Estos comandos dan soporte a los procedimientos que se utilizan en el SMTP, como inicio de sesión, transacción de correo, envío de correo, verificación de nombres de buzones de correo, expansión de listas de correo e intercambios de apertura y cierre.
      Algunos de los comandos que se especifican en el protocolo SMTP son:
      - HELO: identifica el proceso del cliente SMTP para el proceso del servidor SMTP
      - EHLO: es una nueva versión del HELO, que incluye extensiones de servicios
      - MAIL FROM: identifica el emisor
      - RCPT TO: identifica el receptor
      - DATA: identifica el cuerpo del mensaje



      3.4. FTP
      El Protocolo de transferencia de archivos (FTP) es otro protocolo de la capa de aplicación de uso común. El FTP se desarrolló para permitir las transferencias de archivos entre un cliente y un servidor. Un cliente FTP es una aplicación que se ejecuta en una computadora y que carga y descarga archivos de un servidor que ejecuta el demonio FTP (FTPd).
      El FTP necesita dos conexiones entre el cliente y el servidor para transferir archivos de forma exitosa: una para comandos y respuestas, otra para la transferencia real de archivos.
      El cliente establece la primera conexión con el servidor en TCP puerto 21. Esta conexión se utiliza para controlar el tráfico, que consiste en comandos del cliente y respuestas del servidor.
      El cliente establece la segunda conexión con el servidor en TCP puerto 20. Esta conexión es para la transferencia real de archivos y se crea cada vez que se transfiere un archivo.
      La transferencia de archivos puede producirse en ambas direcciones. El cliente puede descargar (bajar) un archivo desde el servidor o el cliente puede cargar (subir) un archivo en el servidor.


      3.5. DHCP
      El servicio del Protocolo de configuración dinámica de host (DHCP) permite a los dispositivos de una red obtener direcciones IP y otra información de un servidor DHCP. Este servicio automatiza la asignación de direcciones IP, máscaras de subred, gateway y otros parámetros de networking del IP.
      DHCP permite a un host obtener una dirección IP de forma dinámica cuando se conecta a la red. Se realiza el contacto con el servidor de DHCP y se solicita una dirección. El servidor DHCP elige una dirección del rango configurado llamado pool y la asigna ("alquila") para el host por un tiempo establecido.
      En redes locales más grandes, o donde los usuarios cambien con frecuencia, se prefiere el DHCP. Los nuevos usuarios llegan con computadoras portátiles y necesitan una conexión. Otros tienen nuevas estaciones de trabajo que necesitan conexión. En lugar de que el administrador de red asigne direcciones IP para cada estación de trabajo, es más eficaz que las direcciones IP se asignen automáticamente mediante el DHCP.
      Las direcciones distribuidas por DHCP no se asignan de forma permanente a los hosts, sino que sólo se alquilan por un periodo de tiempo. Si el host se apaga o se desconecta de la red, la dirección regresa al pool para volver a utilizarse. Esto es especialmente útil para los usuarios móviles que entran y salen de la red. Los usuarios pueden moverse libremente desde una ubicación a otra y volver a establecer las conexiones de red. El host puede obtener una dirección IP cuando se conecte el hardware, ya sea por cables o por LAN inalámbrica.
      DHCP le permite el acceso a Internet por medio de Internet utilizando zonas de cobertura inalámbrica en aeropuertos o cafeterías. Una vez que ingresa al área, el cliente de DHCP de la computadora portátil contacta al servidor de DHCP mediante una conexión inalámbrica. El servidor de DHCP asigna una dirección IP a la computadora portátil.
      Con las redes domésticas, el servidor de DHCP se ubica en el ISP y un host de la red doméstica recibe la configuración IP directamente desde el ISP.
      DHCP puede representar un riesgo a la seguridad porque cualquier dispositivo conectado a la red puede recibir una dirección. Este riesgo hace que la seguridad física sea un factor importante al determinar si se utiliza el direccionamiento dinámico o manual.
      Ambos direccionamientos tienen su lugar en los diseños de red. Muchas redes utilizan tanto el direccionamiento estático como el DHCP. DHCP se utiliza para hosts de propósitos generales, como los dispositivos de usuario final, y las direcciones fijas se utilizan para dispositivos de red como gateways, switches, servidores e impresoras.
      Sin DHCP los usuarios tiene que ingresar manualmente la dirección IP, la máscara de subred y otras configuraciones para poder unirse a la red. El servidor de DHCP mantiene un pool de las direcciones IP y alquila una dirección a cualquier cliente habilitado por DHCP cuando el cliente está activado. Debido a que las direcciones IP son dinámicas (alquiladas) en lugar de estáticas (asignadas en forma permanente), las direcciones en desuso regresan automáticamente al pool para volver a asignarse. Cuando un dispositivo configurado por DHCP se inicia o conecta a la red, el cliente envía un paquete DESCUBRIMIENTO de DHCP para identificar cualquier servidor de DHCP disponible en la red. Un servidor de DHCP responde con una OFERTA DE DHCP, la cual cual es un mensaje de oferta de alquiler con información asignada de dirección IP, máscara de subred, servidor DNS y gateway predeterminado, así como la duración del alquiler.
      El cliente puede recibir múltiples paquetes de OFERTA DE DHCP si hay más de un servidor de DHCP en la red local, así que debe elegir entre ellos y enviar un paquete de SOLICITUD DE DHCP que identifique el servidor explícito y la oferta de alquiler que el cliente acepta. Un cliente puede elegir solicitar una dirección previamente asignada por el servidor.
      Teniendo en cuenta que la dirección IP solicitada por el cliente, u ofrecida por el servidor, aún es válida, el servidor devolverá un mensaje ACK DHCP que le informa al cliente que finalizó el alquiler. Si la oferta ya no es válida, quizás debido al tiempo o que a otro cliente se le asignó el alquiler, el servidor seleccionado responderá con un mensaje NAK DHCP (acuse de recibo negativo). Si un mensaje NAK DHCP se devuelve, entonces el proceso de selección debe volver a comenzar con la transmisión de un mensaje nuevo de DESCUBRIMIENTO DE DHCP.
      Una vez que el cliente tenga el alquiler, se debe renovar mediante otro mensaje de SOLICITUD DE DHCP, antes de que termine el alquiler.
      El servidor de DHCP asegura que las direcciones IP sean únicas (una dirección IP no se puede asignar a dos dispositivos de red diferentes de forma simultánea). Usar DHCP permite a los administradores de red volver a configurar fácilmente las direcciones IP del cliente sin tener que realizar cambios a los clientes en forma manual. La mayoría de los proveedores de Internet utilizan DHCP para asignar direcciones a los clientes que no necesitan una dirección estática.

      3.6. Protocolo SMB y Servicios para Compartir Archivos
      El Bloque de mensajes del servidor (SMB) es un protocolo cliente-servidor para compartir archivos. IBM desarrolló el Bloque de mensajes del servidor (SMB) a fines de la década de los 80 para describir la estructura de recursos de red compartidos, como directorios, archivos, impresoras y puertos seriales. Es un protocolo de solicitud-respuesta. A diferencia del protocolo para compartir archivos respaldado por FTP, los clientes establecen una conexión a largo plazo con los servidores. Una vez establecida la conexión, el usuario del cliente puede acceder a los recursos en el servidor como si el recurso fuera local para el host del cliente.
      El intercambio de archivos SMB y los servicios de impresión se han transformado en el pilar de networking de Microsoft. Con la presentación de la serie Windows 2000 del software, Microsoft cambió la estructura subyacente para el uso del SMB. En versiones anteriores de los productos de Microsoft, los servicios de SMB utilizaron un protocolo que no es TCP/IP para implementar la resolución de nombres. Comenzando con Windows 2000, todos los productos subsiguientes de Microsoft utilizan denominación DNS. Esto permite que los protocolos TCP/IP den soporte directamente al intercambio de recursos SMB.
      Los sistemas operativos LINUX y UNIX también proporcionan un método de intercambio de recursos con redes de Microsoft mediante una versión del SMB llamado SAMBA. Los sistemas operativos Macintosh de Apple también admiten recursos compartidos por medio del protocolo SMB.
      El protocolo SMB describe el acceso al sistema de archivos y la manera en que los clientes hacen solicitudes de archivos. Además describe la comunicación entre procesos del protocolo SMB. Todos los mensajes SMB comparten un mismo formato. Este formato utiliza un encabezado de tamaño fijo seguido por un parámetro de tamaño variable y un componente de datos.
      Los mensajes de SMB pueden:
      - Iniciar, autenticar y terminar sesiones
      - Controlar el acceso a los archivos y a la impresora
      - Autorizar una aplicación para enviar o recibir mensajes para o de otro dispositivo

      3.7. Protocolo Gnutella y Servicios P2P
      Aprendimos acerca del FTP y del SMB como formas de obtener archivos, aquí presentamos otro protocolo de aplicación. Compartir archivos en Internet se ha transformado en algo muy popular. Con las aplicaciones P2P basadas en el protocolo Gnutella, las personas pueden colocar archivos en sus discos rígidos para que otros los descarguen. El software del cliente compatible con Gnutella permite a los usuarios conectarse con los servicios Gnutella en Internet y ubicar y acceder a los recursos compartidos por otros pares Gnutella.
      Muchas aplicaciones del cliente están disponibles para acceder en la red Gnutella, entre ellas: BearShare, Gnucleus, LimeWire, Morpheus, WinMX y XoloX (consulte una captura de pantalla de LimeWire en la figura). Mientras que el Foro de desarrolladores de Gnutella mantiene el protocolo básico, los proveedores de las aplicaciones generalmente desarrollan extensiones para lograr que el protocolo funcione mejor en dichas aplicaciones.
      Muchas de las aplicaciones P2P no utilizan una base de datos central para registrar todos los archivos disponibles en los puntos. Por el contrario, los dispositivos en la red se indican entre ellos qué archivos están disponibles cuando hay una consulta, y utilizan el protocolo Gnutella y los servicios para respaldar los recursos ubicados.
      Cuando un usuario se conecta a un servicio Gnutella, las aplicaciones del cliente buscan otros nodos Gnutella para conectarse. Estos nodos manejan las consultas para las ubicaciones de los recursos y responden a dichas solicitudes. Además, gobiernan los mensajes de control que ayudan al servicio a descubrir otros nodos. Las verdaderas transferencias de archivos generalmente dependen de los servicios HTTP.
      El protocolo Gnutella define 5 tipos de paquetes diferentes:
      - ping: para el descubrimiento del dispositivo
      - pong: como respuesta a un ping
      - query: para encontrar un archivo
      - query hit: como respuesta a una consulta
      - push: como una solicitud de descarga

      3.8. Protocolo y Servicios Telnet
      Mucho antes de que existieran las computadoras de escritorio con interfaces gráficas sofisticadas, las personas utilizaban sistemas basados en textos que eran simplemente terminales conectadas físicamente a una computadora central. Una vez que las redes estaban disponibles, las personas necesitaban acceder en forma remota a los sistemas informáticos de la misma manera en que lo hacían con las terminales conectadas directamente.
      Telnet se desarrolló para satisfacer esta necesidad. Telnet se remonta a principios de la década de los 70 y se encuentra entre los servicios y protocolos de capa de aplicación más antiguo dentro del grupo TCP/IP. Telnet proporciona un método estándar de emulación de dispositivos de terminal con base en texto en la red de datos. El protocolo y el software del cliente que implementa son conocidos como Telnet.
      De un modo adecuado, una conexión que utiliza Telnet se llama sesión o conexión de terminal virtual (VTY). En lugar de utilizar un dispositivo físico para conectarse al servidor, Telnet utiliza software para crear un dispositivo virtual que proporcione las mismas características de una sesión de terminal con acceso a la interfaz de línea de comandos (CLI) del servidor.
      Para admitir conexiones del cliente a Telnet, el servidor ejecuta un servicio llamado demonio de Telnet. Se establece una conexión de terminal virtual desde un dispositivo final utilizando una aplicación del cliente Telnet. La mayoría de los sistemas operativos incluye un cliente de Telnet de la capa de aplicación. Telnet puede ejecutarse desde el indicador del sistema en una PC de Microsoft Windows. Otras aplicaciones de terminal comunes que ejecutan clientes Telnet son HyperTerminal, Minicom y TeraTerm.
      Una vez establecida una conexión Telnet, los usuarios pueden realizar cualquier función autorizada en el servidor, como si utilizaran una sesión de línea de comandos en el servidor mismo. Si están autorizados, pueden iniciar y detener procesos, configurar el dispositivo e inclusive apagar el sistema.
      Telnet es un protocolo cliente-servidor y especifica cómo se establece y se termina una sesión VTY. Además proporciona la sintaxis y el orden de los comandos utilizados para iniciar la sesión Telnet, así como también los comandos de control que pueden ejecutarse durante una sesión. Cada comando Telnet consiste en por lo menos dos bytes. El primer byte es un caracter especial denominado Interpretar como comando (IAC). Como su nombre lo indica, el IAC define el byte siguiente como un comando en lugar de un texto.
      Algunas muestras de comandos del protocolo Telnet incluyen:

      - Are You There (AYT): permite al usuario solicitar que aparezca algo en la pantalla de la terminal para indiciar que la sesión VTY está activa.

      - Erase Line (EL): elimina todo el texto de la línea actual.

      - Interrupt Process (IP): suspende, interrumpe, aborta o termina el proceso al cual se conectó la terminal virtual. Por ejemplo, si un usuario inició un programa en el servidor Telnet por medio de VTY, puede enviar un comando IP para detener el programa.

      Aunque el protocolo Telnet admite autenticación de usuario, no admite el transporte de datos encriptados. Todos los datos intercambiados durante una sesión Telnet se transporta como texto sin formato por la red. Esto significa que los datos se pueden intercepter y entender fácilmente.
      Si la seguridad es un problema, el Protocolo shell seguro (SSH) ofrece un método seguro y alternativo para acceder al servidor. SSH proporciona la estructura para un inicio de sesión remoto seguro y otros servicios de red seguros. Además, proporciona mayor autenticación que Telnet y admite el transporte de datos de sesión con la autenticación. Como una mejor práctica, los profesionales de red deberían utilizar siempre SSH en lugar de Telnet, cada vez que sea posible.
      Copyright © 2014 Trujillo - Perú